How apurboislam/iot-home-automation works
1. What this repo is
- This is a single-device firmware project for a NodeMCU ESP8266 that connects to Blynk Cloud and controls up to 4 relay-driven appliances. There is no separate backend server; the device firmware is the product.
2. Top-level runtime
- The Arduino sketch BlynkEdgent_ESP8266.ino is the entrypoint.
- The rest of the .h files are supporting modules that split the firmware into provisioning, state handling, OTA, UI feedback, and configuration storage.
3. Core application boundary
- The main boundary is between:
- Blynk mobile app / Blynk Cloud on one side
- ESP8266 firmware + relay hardware on the other
- The cloud/app sends device commands over Wi‑Fi using Blynk virtual pins, and the firmware translates those commands into GPIO relay actions.
4. Cloud control model
- The README defines the Blynk mapping:
- V1–V4 control the four relays
- V0 is used for state memory / sync behavior
- This means the firmware is stateful and expects cloud synchronization, not just one-way button pushes.
5. Hardware control layer
- The physical outputs are the relay pins mapped to ESP8266 GPIOs:
- D1 → IN1
- D2 → IN2
- D3 → IN3
- D4 → IN4
- The firmware’s job is to keep these outputs aligned with the cloud state and restore them after reconnects or reboot.
6. Provisioning and onboarding
- BlynkEdgent.h and ConfigMode.h indicate use of Blynk’s Edgent-style onboarding flow.
- This likely covers initial Wi‑Fi setup, device discovery, and pairing with the Blynk app without hardcoding a network from the start.
7. Persistent configuration
- ConfigStore.h and Settings.h separate device configuration from live runtime state.
- The architecture suggests storing template/device settings and Wi‑Fi/Blynk-related data so the device can survive resets and reconnect consistently.
8. Runtime state machine
- BlynkState.h implies an explicit firmware state machine for device lifecycle management.
- Typical states in this architecture are: boot, connect Wi‑Fi, connect Blynk, configuration mode, and normal operation.
9. OTA update path
- OTA.h shows the firmware is OTA-ready.
- Updates are part of the device lifecycle, meaning the system is designed to receive new firmware without a physical USB reflash, which matters for deployed home automation devices.
10. User feedback and diagnostics
- Indicator.h, Console.h, and ResetButton.h cover local device interaction:
- visual status indication
- serial/debug console output
- physical reset/provisioning button handling
- These modules provide the local control plane separate from the cloud control plane.
11. Data flow summary
- Command path: Blynk app → Blynk Cloud → Wi‑Fi → ESP8266 firmware → GPIO relay pins → appliances
- State path: relay/state changes → firmware state tracking → Blynk sync / cloud state memory
- Setup path: physical reset / first boot → configuration mode → Wi‑Fi + Blynk provisioning
12. Build and artifacts
- The build/esp8266.esp8266.nodemcuv2/ directory contains compiled outputs (.bin, .elf, .map), which are generated artifacts for the ESP8266 target and not part of the logical runtime architecture.
13. Architectural takeaway
- This repo is a modular embedded firmware system with three major concerns:
- connectivity and provisioning
- relay control and state sync
- OTA / lifecycle management
- For a diagram, the cleanest representation is an ESP8266 device node with internal modules around a Blynk/Edgent communication core and four relay outputs to home appliances.
Main entry points: BlynkEdgent_ESP8266.ino Main sketch · BlynkEdgent.h Edgent core · BlynkState.h State machine · ConfigStore.h Config store
Components 16
External
Cloud, app, and local physical environment around the device
- Blynk app · User interface for controlling the device and viewing state.
- Blynk Cloud · Remote command, sync, and device connectivity layer.
- Wi‑Fi · Connectivity path between the ESP8266 and Blynk services.
Firmware
ESP8266 runtime modules and lifecycle logic
- Main sketch · Arduino firmware entrypoint that wires the modules together.
BlynkEdgent_ESP8266.ino - Edgent core · Blynk Edgent bootstrap and device integration logic.
BlynkEdgent.h - State machine · Explicit firmware lifecycle control for boot, connect, config, and run states.
BlynkState.h - Config mode · Wi‑Fi and device onboarding flow used during setup or recovery.
ConfigMode.h - Config store · Storage for device configuration and reconnectable settings.
ConfigStore.h - Settings · Structured configuration values used by runtime and provisioning code.
Settings.h - OTA update · Over-the-air firmware update path for deployed devices.
OTA.h - Indicator · Local visual status feedback for connection and lifecycle state.
Indicator.h - Console · Serial/debug output for runtime diagnostics and troubleshooting.
Console.h - Reset button · Button handling for reset and provisioning triggers.
ResetButton.h
Hardware
On-device outputs and physical controls
- Relay control · Translates synced device state into relay on/off actions.
- Relays · Four relay-driven outputs mapped to ESP8266 GPIO pins D1 to D4.
- Appliances · Connected home devices switched by the relay outputs.
Connections 16
- Blynk app → Blynk Cloud: commands · User actions are sent through the Blynk cloud backend.
- Blynk Cloud → Wi‑Fi: transport · Cloud interaction reaches the device over the network.
- Wi‑Fi → Edgent core: connects · Network connectivity enables the firmware to reach Blynk services.
- Main sketch → Edgent core: boots · The main sketch initializes the Edgent integration.
- Main sketch → State machine: drives · Startup and runtime execution are governed by the lifecycle state machine.
- Edgent core → Config mode: onboards · Edgent handles first-time setup and recovery provisioning.
- Edgent core → Config store: persists · Device configuration is loaded and saved through the config store.
- Config store → Settings: loads · Persisted values are materialized into runtime settings.
- State machine → Indicator: signals · Lifecycle state is reflected in local indicators.
- State machine → Console: logs · State transitions and diagnostics are emitted to the console.
- Reset button → Config mode: triggers · Physical reset or provisioning actions can enter configuration mode.
- Blynk Cloud → Main sketch: virtual pins · V0 to V4 device state and relay commands are delivered to the firmware.
- Main sketch → Relay control: maps state · Cloud-synced device state is converted into relay actions.
- Relay control → Relays: drives · GPIO control energizes the relay outputs.
- Relays → Appliances: switches · Relays control the attached home appliances.
- Main sketch → OTA update: updates · Firmware lifecycle includes over-the-air update handling.