Smart Home Architecture: Mermaid Flowchart

Smart Home System Architecture flowchart diagram

About Source

A smart home system architecture shows how consumer IoT devices — smart bulbs, thermostats, door locks, cameras, and sensors — connect through a local hub and cloud platform to end-user control surfaces including mobile apps, web dashboards, and voice assistants.

Smart home systems must simultaneously satisfy two competing requirements: low-latency local control (turning on a light should not require a round trip to the internet) and remote accessibility (controlling the same light from anywhere in the world). Good architecture achieves both by maintaining a local hub that handles device communication on the LAN, while replicating state to a cloud platform for remote access and third-party integrations.

Devices connect to the hub using short-range radio protocols: Zigbee and Z-Wave for battery-powered sensors and switches, Wi-Fi for cameras and smart plugs, and Matter (over Thread or Wi-Fi) for newer interoperable devices. The hub maintains a device registry mapping logical names to physical addresses, and a state store holding the last-known state of every device.

The hub syncs state to the cloud platform continuously. When a user opens a mobile app, it connects to the cloud via WebSocket or REST to read current state and send commands. Commands flow cloud → hub → device. If the hub is on the same LAN as the device and the mobile app is also on-LAN, the app can optionally issue commands directly to the hub, bypassing the cloud for sub-100 ms latency.

Voice assistants (Alexa, Google Home, Siri) integrate via OAuth-protected cloud APIs. The assistant platform sends an intent to the smart home cloud, which translates it into a device command and routes it through the hub. Automations — if door opens after 10 PM, turn on hallway light — run as rules on the hub (for reliability during cloud outages) or as cloud functions. For authentication patterns, see IoT Device Authentication. For command delivery mechanics, see IoT Command Control Flow. For the gateway layer, see IoT Gateway Architecture.

Frequently asked questions

A smart home system architecture describes how consumer IoT devices — lights, thermostats, locks, cameras, and sensors — connect through a local hub and cloud platform to control surfaces such as mobile apps and voice assistants. The architecture must deliver low-latency local control and remote accessibility simultaneously, which requires maintaining state both on the hub and in the cloud.

Devices connect to a local hub using short-range protocols such as Zigbee, Z-Wave, Wi-Fi, or Matter. The hub maintains a device registry and state store, syncing continuously to a cloud platform. Mobile apps and voice assistants interact with the cloud via REST or WebSocket APIs, sending commands that flow cloud → hub → device. When the mobile app is on the same LAN as the hub, it can optionally communicate directly for sub-100 ms response times.

Run automations on the hub when reliability during internet outages is important — a "motion detected after midnight: turn on lights" rule must fire even if the WAN is down. Run automations in the cloud when they depend on external data (weather, calendar events, third-party integrations) or when complex logic exceeds the hub's processing capacity. Many systems run critical safety automations on the hub and convenience automations in the cloud.

Common mistakes include making all device control depend on cloud connectivity, so a brief internet outage disables local control entirely. Others are storing device credentials in the mobile app rather than the cloud, selecting a proprietary hub protocol that limits future device compatibility, and neglecting to handle the case where hub and cloud state diverge during a disconnection period.

mermaid

flowchart TD
    subgraph Devices[Smart Home Devices]
        Bulb[Smart bulb\nZigbee]
        Thermostat[Thermostat\nZ-Wave]
        Lock[Door lock\nZ-Wave]
        Camera[IP camera\nWi-Fi]
        Sensor[Door / motion sensor\nZigbee]
    end

    subgraph Hub[Local Smart Home Hub]
        Registry[Device registry]
        StateStore[Local state store]
        Automation[Automation engine\nLocal rules]
        Broker[Local MQTT broker]
    end

    Devices -->|Zigbee / Z-Wave / Wi-Fi| Hub
    Hub -->|HTTPS sync| Cloud[Smart Home Cloud Platform]
    Cloud -->|Push state| Hub

    subgraph Controls[User Control Surfaces]
        MobileApp[Mobile app]
        WebUI[Web dashboard]
        Voice[Voice assistant\nAlexa / Google]
    end

    MobileApp -->|REST / WebSocket| Cloud
    WebUI -->|REST| Cloud
    Voice -->|OAuth API intent| Cloud
    MobileApp -->|Direct LAN command| Hub

    Cloud -->|Command routing| Hub
    Hub -->|Device command| Devices
    Automation -->|Trigger command| Broker
    Broker --> Devices

Smart Home System Architecture

Frequently asked questions