Develop a Functional Smart System Prototype
This lesson guides you through the complete lifecycle of developing a smart system prototype: requirements analysis, system design, implementation, testing, and iterative refinement.
Prototype Development Lifecycle
| Phase | Activity | Example (Smart Irrigator) |
|---|---|---|
| Phase 1: Requirements | Define what the system must do. Identify stakeholders, use cases, success criteria. | Water when soil < 30%, stop at 70%, log to cloud, alert on pump fault. |
| Phase 2: System design | Select components, define architecture, design state machine, plan MQTT topics. | Sensor: capacitive soil. Actuator: solenoid via relay. Protocol: MQTT. Cloud: ThingsBoard. |
| Phase 3: Implementation | Build hardware, write firmware, configure cloud platform, develop dashboards. | Wire ESP32 + sensor + relay. Upload firmware. Create ThingsBoard device + dashboard. |
| Phase 4: Testing | Verify each subsystem independently, then test the integrated system. Document results. | Unit test: sensor reads correctly. Integration test: pump activates at correct threshold. System test: cloud receives data. |
| Phase 5: Refinement | Analyse test results, identify gaps, improve. Repeat until acceptance criteria are met. | Soil sensor gives noisy readings → add rolling average. False pump activations → add hysteresis. |
Prototype 1: Smart Environmental Monitor with Auto-Response
System Requirements
- Monitor temperature (DHT22), humidity (DHT22), and ambient light (LDR) continuously.
- Automatically activate a fan relay if temperature exceeds 30°C (hysteresis off at 26°C).
- Activate a buzzer alert if humidity exceeds 80%.
- Control LED brightness proportionally to inverse light level (auto night light).
- Publish all sensor readings and system state to ThingsBoard every 15 seconds.
- Receive RPC commands from ThingsBoard to manually override fan and buzzer.
- Log all state transitions to Serial Monitor with timestamp (from NTP).
- Operate correctly even when Wi-Fi or cloud is unavailable (local autonomy).
Hardware Connections
| Component | GPIO | Purpose |
|---|---|---|
| DHT22 DATA | GPIO 4 | Temperature + humidity |
| LDR | GPIO 34 (ADC1) | Light level (with 10 kΩ pull-down to GND) |
| Fan relay IN | GPIO 16 | HIGH = relay on = fan ON |
| Buzzer | GPIO 17 | Active buzzer: HIGH = on |
| LED (PWM) | GPIO 18 | Auto brightness (0–255) |
| Status LED | GPIO 2 (onboard) | Blinks during cloud publish |
Complete Firmware — Smart Environmental Monitor
ThingsBoard Dashboard for the Smart System
| Widget | Configuration | Layout note |
|---|---|---|
| Temperature gauge | Radial gauge, key: temperature, range 0–50°C. Colour zones: green 0–28, yellow 28–32, red 32+. | Row 1 (most important) |
| Humidity gauge | Radial gauge, key: humidity, range 0–100%. Colour zones: green 30–70, yellow 70–80, red 80+. | Row 1 |
| Light trend chart | Time-series chart, keys: light_raw + brightness. Last 30 minutes. Dual-axis if needed. | Row 2 |
| System status table | Latest Values table showing: fan_state, buzz_state, override, rssi. | Row 2 |
| Alarm widget | Alarms table: configure alarm rules for temp > 32 and hum > 80. | Row 3 |
| Fan switch | Control switch widget: calls setFan RPC with {state: true/false}. | Row 3 — control panel |
| Buzzer button | RPC button widget: calls setBuzzer RPC. | Row 3 — control panel |
| Clear overrides | RPC button: calls clearOverrides to return to automatic mode. | Row 3 — control panel |
Testing the Prototype
Unit Testing — Each Component Separately
| Test | Verification steps |
|---|---|
| Sensor test | Verify DHT22 reads make sense. Compare to reference thermometer. Apply isnan() check. Verify LDR responds to light changes. |
| Actuator test | Manually drive FAN_PIN, BUZZ_PIN, LED_PIN via Serial commands. Confirm correct electrical response. Check fan relay clicks audibly. |
| Wi-Fi test | Verify connection, NTP sync, and IP address in Serial Monitor. |
| MQTT test | Verify MQTT connect succeeds. Use MQTT Explorer to confirm telemetry arrives at broker. Confirm RPC subscription active. |
| Cloud test | Verify ThingsBoard Latest Telemetry updates with correct values. Confirm all 8 telemetry keys appear. |
Integration Testing — Full System
| Test scenario | Expected result |
|---|---|
| Temperature trigger | Cover DHT22 with your hand to raise temperature above 30°C. Verify fan relay activates within one read cycle (3 s). Verify ThingsBoard fan_state changes to 1. |
| Humidity trigger | Breathe on the DHT22 to raise humidity above 80%. Verify buzzer activates. Verify ThingsBoard logs the buzz_state change. |
| Manual override | Click Fan ON button in dashboard. Verify fan activates regardless of temperature. Cover DHT22 — fan should stay on despite any automation logic. |
| Clear override | Click Clear Overrides. Verify automation logic resumes. Fan should turn off if temperature is below threshold. |
| Offline test | Disable Wi-Fi router. Verify device continues reading sensors and activating actuators based on local thresholds. Re-enable Wi-Fi. Verify reconnection and data resumes. |
| Sensor failure test | Disconnect DHT22 DATA pin. Verify device prints ‘Sensor error’ but does not crash. Verify actuators maintain last state (not reset to off). |
Performance Metrics and Refinement
| Metric | What to measure | Targets and fixes |
|---|---|---|
| Response latency | Time from threshold breach to actuator activation. | Target: < 10 s. If > 30 s: reduce READ_INTERVAL. |
| Publish success rate | Count of MQTT publishes vs successful deliveries. | Target: > 95%. If lower: check Wi-Fi RSSI and broker connection. |
| Sensor accuracy | Compare DHT22 readings to a calibrated reference. | Offset > 2°C: apply calibration constant in firmware. |
| False activations | Count fan or buzzer activations that do not correspond to real events. | If high: widen hysteresis gap or add rolling average to sensor reads. |
| Cloud data gaps | Time periods with no telemetry in ThingsBoard history. | If gaps > 30 s: investigate connection drops. Add offline buffering. |
| Power consumption | Measure current draw in normal operation vs peak (fan + buzzer). | If > expected: add ESP32 deep sleep between readings for battery-powered versions. |


