MODULE 5
Smart Lighting Home Automation System
IoT-based Intelligent Lighting using Django Framework
Overview
What is RESTful API?
- Server (Backend - Django): processes the request.
- IoT Hardware (Raspberry Pi + Sensors): performs
the real action.
RESTful API in Smart Lighting System
Example:
1. User clicks Auto Mode on the web app.
2. App sends request → Django updates mode in the database.
3. Raspberry Pi reads it → checks LDR → turns light ON/OFF.
4. App checks again → gets reply: 'Auto'.
Key URLs:
Understanding LDR (Light Dependent Resistor)
Simple meaning: The LDR acts as the 'eyes' of your smart lighting system.
Figure 9.1 – Deployment Design of Home Automation IoT System
This diagram presents the overall architecture of the Smart Lighting Home Automation IoT system. It illustrates how the local Django-based application, REST APIs, database, and IoT hardware components communicate with each other within the local and cloud layers.
Overview of the Deployment Design
Figure 9.1 illustrates the deployment architecture of the Smart Lighting Home Automation IoT System. The architecture is organized into two domains: the Local environment and the Cloud environment. The Local environment performs all the real-time data processing, decision-making, and device control operations, while the Cloud environment is an optional extension designed for scalability and remote data analytics. This structure enables modular design, allowing the system to function independently within a home environment and later expand to cloud-based monitoring if required.
Local Layer Description
The Local layer forms the operational core of the smart home automation system. It includes components that directly handle user input, data processing, control logic, and hardware communication. This layer ensures that even without internet connectivity, the system can continue to operate efficiently. All critical operations, such as reading sensor data, controlling light states, and managing automation, occur locally, ensuring low latency and reliable performance for real-time applications.
Application and REST Communication
At the top of the Local layer lies the Application or App, which is a Django-based web interface. It allows the user to monitor the system and control lighting behavior remotely through any web browser. Communication between the App and the backend services is handled using RESTful APIs, which ensure lightweight and efficient data transfer. The REST communication uses standard HTTP methods such as GET and PUT to send or receive information related to system state and mode configuration.
Database Management
The Database is a central component responsible for storing and managing system information. It maintains records of the operational mode (Auto or Manual) and the light’s ON or OFF state. Whenever a user makes a change through the web interface, the data is updated in the database. The Controller Service periodically retrieves data from the database to make informed decisions about system behavior. Thus, the database acts as the synchronization hub that connects the software layer to the physical IoT devices.
Controller Service Functionality
The Controller Service acts as the brain of the system, interpreting data and controlling the devices accordingly. It continuously monitors both user inputs and environmental sensor readings. In Auto mode, the controller uses light sensor data to determine whether to turn the light ON or OFF depending on the ambient brightness. In Manual mode, it simply follows the user’s command as received from the web interface. The Controller Service ensures that automation and manual control coexist without conflict, maintaining system consistency.
Resource and Device Layers
The Resource and Device layers represent the physical part of the system. The Resource layer provides a software abstraction that allows the controller to communicate with various hardware components in a standardized way. The Device layer includes tangible IoT elements such as sensors, relays, and lights. When a command is issued from the controller, the Resource layer converts it into electrical signals that the devices understand. This flow of commands and feedback completes the interaction loop between digital logic and physical hardware.
Monitoring Node Operations
The Monitoring Node serves as the analytical unit of the Local layer. It continuously observes system operations, records data, and performs performance analysis. It helps in detecting anomalies, logging sensor values, and ensuring overall system reliability. The data stored by the monitoring node can later be used to improve system performance, perform predictive analysis, or integrate with higher-level AI-based optimization algorithms.
Cloud Layer Role and Future Integration
The Cloud layer is intentionally depicted as an extension point in the architecture. Although the current implementation functions locally, the cloud can be used for advanced functionalities such as data analytics, remote monitoring, and centralized control. Integrating cloud services would allow users to access their home automation data from anywhere and apply machine learning for intelligent decision-making. This hybrid design ensures that the system remains scalable, flexible, and future-ready.
Summary of Deployment Architecture
In summary, the deployment design represents a well-structured integration of software and hardware components. The Local layer ensures autonomous, real-time control, while the Cloud layer offers long-term scalability. Data flows seamlessly from the user interface to the database, through the controller, and finally to the devices, with feedback maintained by the monitoring node. This layered and modular structure makes the system efficient, reliable, and adaptable to various smart home scenarios.
Figure 9.2 – Mode Service Specification
Introduction to Mode Service
Following the deployment design of the Smart Home Automation IoT System, Figure 9.2 explains the Mode Service specification. This REST-based service manages the system’s operational behavior by switching between Auto and Manual modes. It allows seamless interaction between the user interface, backend database, and IoT devices, ensuring synchronized control of lighting operations.
Structure of the Mode Service
At the center of the service specification lies the Mode Service component. It is defined as a RESTful web service that communicates through HTTP requests. This service provides an organized way to read and update the system’s mode configuration, maintaining consistent data exchange between the Django web app and controller logic.
Input Specification
The Input component, labeled ‘Set Mode: Auto/Manual’, represents user commands sent through the web interface. When a user changes the operational mode, an HTTP PUT request is generated. This request is sent to the Mode Service endpoint, where the database is updated with the new mode value. The ‘has Input’ relation indicates that the service actively receives mode-setting data from users or controllers.
Output Specification
The Output component, labeled ‘Current Mode: Auto/Manual’, represents the system’s feedback mechanism. When a GET request is received, the Mode Service fetches the current operational mode from the database and returns it to the user interface. This ensures transparency, allowing users to confirm whether the system is functioning in Auto or Manual mode.
Service Endpoint Definition
The Endpoint shown in the diagram defines the communication path for the Mode Service. It specifies the URL ‘/home/mode/’ and uses the HTTP protocol for communication. This endpoint acts as a bridge between the client-side web app and the backend service, enabling both local and remote access through Django’s REST framework.
Functional Role of the Mode Service
The Mode Service governs how the home automation system behaves under different conditions. In Auto mode, the controller autonomously manages light operation using sensor inputs. In Manual mode, user commands take priority, overriding automation. This service ensures dynamic adaptability, allowing users to maintain full control while enabling automation when required.
Integration and Summary
The Mode Service works alongside the State Service and Controller Service to provide a complete automation framework. While the Mode Service defines how the system should operate, the State Service manages what the system is currently doing. Both interact through the Controller Service, ensuring synchronized actions. Figure 9.2 thus demonstrates the modular and flexible design of the home automation IoT system’s service architecture.
Figure 9.3 – State Service Specification
Introduction to State Service Specification
Figure 9.3 illustrates the State Service, an integral RESTful component of the Smart Home Automation IoT System. While the Mode Service governs whether the system operates in Auto or Manual mode, the State Service directly manages the light’s ON/OFF operation. It ensures seamless synchronization between the web interface, backend database, and IoT devices by providing REST API endpoints for state management.
Purpose of the State Service
Service Structure
Input Specification
Output Specification
Service Endpoint Definition
Functional Role in the Automation System
Integration and Summary
Figure 9.4 – Web Application Interface
Figure 9.5 – Hardware Schematic Diagram
Introduction to Figure 9.5 – Schematic Diagram
Figure 9.5 illustrates the schematic diagram of the Smart Home Automation IoT System, showing how the controller device, sensor, and actuator are interconnected. This figure presents the physical hardware implementation that supports the automation cycle of sensing, processing, and action within the smart lighting framework.
Hardware Overview
The system is built around a Raspberry Pi board, which serves as the primary processing unit. The Raspberry Pi manages sensor inputs, user commands, and actuator control signals through its GPIO pins. It communicates with the Django-based web application to synchronize lighting operations with RESTful services over a local or remote network connection.
Sensor Integration
The schematic includes a light-dependent resistor (LDR) sensor connected to the Raspberry Pi via an analog-to-digital converter (ADC). The LDR measures the ambient light intensity in the environment. In Auto Mode, when the light level falls below a certain threshold, the Raspberry Pi interprets this input and triggers the relay to turn ON the light. When sufficient light is detected, the system turns it OFF automatically.
Actuator and Relay Circuit
The actuator is represented by a relay module that acts as a switch between the Raspberry Pi and the lighting appliance. Since the Raspberry Pi operates at low voltage, the relay safely manages high-voltage circuits. The relay receives digital signals from the Raspberry Pi and toggles the light ON or OFF, enabling the controller to perform real-world actions based on logic or user input.
Breadboard Wiring and Circuit Design
The breadboard in the schematic diagram demonstrates how all components are physically connected without soldering. Power and ground lines from the Raspberry Pi supply voltage to the sensor and relay modules. Signal connections link the GPIO pins to the ADC and the relay inputs, allowing two-way communication between hardware and software layers. This modular setup enables easy reconfiguration and future expansion.
Operational Flow
Hardware–Software Integration
Summary of the Schematic Diagram
Figure 9.6 – Controller Service
Introduction to Figure 9.6 – Controller Service
Service Description
Input Specification
Schedule Specification
Output Specification
Endpoint Specification
Functional Operation
Integration and Summary
Smart Lighting Home Automation — Code
Django REST APIs + Raspberry Pi Controller
models.py — Code
models.py
The Home model defines a minimal single-table representation used to coordinate the global operational mode and the instantaneous light state for the entire smart lighting system. The 'mode' attribute is a short character field intended to store values such as 'Auto' or 'Manual' which dictate whether the controller acts autonomously based on sensor inputs or defers to remote user commands. The 'state' attribute similarly holds textual markers such as 'On' or 'Off' to capture the present physical condition of the lighting actuator. Choosing a single row model simplifies synchronization across system actors the web front-end, the Raspberry Pi controller, and any monitoring nodes by providing a shared authoritative source. In deployment, ensure that exactly one Home instance exists; use get_or_create during initialization and include model constraints or explicit validation to restrict accepted values. This approach leverages Django's ORM for safe transactional updates, readable queries, and avoids direct SQL, thus reducing the risk of injection and improving maintainability.
serializers.py — Code
serializers.py
The HomeSerializer is a Django REST framework construct that provides bi-directional conversion between Django model instances and JSON payloads consumed by clients. By declaring a ModelSerializer tied to the Home model and explicitly enumerating the 'mode' and 'state' fields, the API benefits from automatic field generation, input validation, and a single place to apply transformation rules. When the endpoint returns data, this serializer produces JSON such as {'mode':'Auto','state':'Off'}; when receiving PUT requests, it parses the incoming JSON, validates types and required fields, and prepares a cleaned Python object suitable for assignment and persistence. Using serializers is superior to manual JSON handling because it centralizes validation logic, supports custom validators, and integrates smoothly with DRF's view classes and error reporting. For stricter behavior, add choice validators to enforce allowed values and descriptive error messages for invalid inputs.
views.py — Mode API (Code)
views.py — Mode API (Paragraph Explanation)
This function-based view implements a concise REST endpoint responsible for reading and modifying the operational mode of the system. On entry, the code uses get_or_create to guarantee the presence of a canonical Home row; this defensive pattern prevents AttributeError exceptions when the database is empty and establishes sensible defaults. For GET requests, the view serializes the Home instance into JSON using the HomeSerializer and returns the structured representation to requesting clients such as the web dashboard or IoT controller. For PUT requests, the endpoint constructs a serializer instance with the existing model and the incoming request data, enabling field-level validation and partial updates. Calling is_valid with raise_exception ensures that invalid payloads produce clear HTTP 400 responses with useful diagnostics rather than silent failures. Finally, save persists allowed changes atomically. This implementation balances robustness and clarity by centralizing validation in serializers and preserving simple HTTP semantics for consumers.
views.py — State API (Code)
views.py — State API
urls.py — Code
urls.py
The URL configuration maps clear, semantic HTTP endpoints to the view functions implementing the API. Using path strings such as 'home/mode/' and 'home/state/' produces human-readable routes which are easy to recall when wiring the front-end JavaScript or the Raspberry Pi controller. Naming routes (name='home-mode') allows reverse URL lookups within Django templates and improves testability. In larger systems, these patterns should be included under an API namespace and versioned (for example '/api/v1/home/mode/') to support backward-compatible changes. Additionally, route protection via DRF authentication classes and permission decorators should be applied at this level to prevent unauthorized writes when the service is exposed beyond a trusted local network.
frontend.js — AJAX PUT Mode (Code)
frontend.js
The JavaScript routine demonstrates a minimal interaction pattern from the browser to the REST endpoint. By performing a fetch PUT request with a JSON body containing the mode field, the front-end updates server-side state that in turn will be observed by the IoT controller. The function includes basic promise chaining to parse the JSON response and to log outcomes for debugging; in production replace console logs with user-facing notifications and error handling that updates UI state. Consider CSRF considerations for same-origin deployments: use DRF's token authentication or include CSRF headers when appropriate. Also, apply UI locking or optimistic updates to prevent duplicate requests and ensure the user receives immediate feedback while the network call completes.
controller.py — Raspberry Pi Loop (Code)
else:� requests.put('http://<server>/home/state/', json={'state':'Off'})� relay.off()� else:� s = requests.get('http://<server>/home/state/').json().get('state')� if s == 'On':� relay.on()� else:� relay.off()� except Exception as e:� # log and continue� print('Controller error', e)� time.sleep(5)
controller.py
The Raspberry Pi controller script is the operational bridge between cloud-hosted application state and the on-site hardware. Running as a continuously executing loop it periodically polls the Mode endpoint to discover whether it should act autonomously. In Auto mode the controller samples the analog LDR value via an ADC and compares it to a calibrated threshold; when the measured illumination falls below the threshold it signals the State endpoint and switches the relay on to energize the light. In Manual mode it instead fetches the authoritative 'state' from the server and drives the relay accordingly, allowing remote operator commands to take precedence. The code includes basic exception handling to ensure transient network or hardware issues do not halt execution. For reliability in production, add robust retry logic, exponential backoff, persisting local state to survive restarts, and consider replacing polling with a push-based protocol such as MQTT to reduce latency and network traffic.
adc_and_ldr — Code (Wiring/Read)
adc_and_ldr
Reading an LDR requires an analog-to-digital converter because Raspberry Pi's GPIO pins are digital only. The common pattern is to place the LDR in a voltage divider with a fixed resistor and connect the midpoint to an ADC such as the MCP3008, which communicates via SPI. The ADC returns a numeric range (for example 0-1023) proportional to the voltage and therefore to the ambient light intensity. The controller should compute a calibrated threshold empirically by sampling the sensor at representative light conditions and possibly applying smoothing via moving average to suppress noise and transient fluctuations from flicker or shadows. Storing threshold values in configuration rather than using hardcoded constants improves maintainability and allows per-deployment tuning. In environments where light gradients matter, consider using multiple sensors and simple aggregation to reduce false triggers.
relay_safety — Code (Notes)
relay_safety
Switching mains loads introduces real safety obligations. Always select a relay or contactor with voltage and current ratings exceeding anticipated loads and incorporate protective components such as snubber circuits, flyback diodes, and opto-isolation where appropriate. Use a transistor driver or a certified relay module to prevent direct current draw from GPIO pins; many relay boards include the necessary driver circuitry and optical isolation. Ensure that AC mains wiring is installed by a qualified electrician, that connections are insulated and strain-relieved, and that the low-voltage side is physically separated from mains conductors. Consider adding fuses, residual current devices (RCD), and surge protection for a production-grade installation. Document safety steps clearly in the project report and include prominent warnings in any distributed code or lab instructions.