¶ Data Flow & Decision Logic
How data moves through the system and the logic behind automated climate decisions.
¶ Data Flow Overview
PlantUML source
¶ Data Types
| Type | Source | Destination | Frequency |
|---|---|---|---|
| Temperature reading | Climate Sensor | Central Unit → Cloud | Every 60 s |
| Humidity reading | Climate Sensor | Central Unit → Cloud | Every 60 s |
| CO₂ level | Climate Sensor | Central Unit → Cloud | Every 60 s |
| Valve position | Thermostat | Central Unit → Cloud | On change |
| Window state | Window Sensor | Central Unit | On change |
| Leak event | Leak Sensor | Central Unit → Cloud | Immediately |
| User command | Mobile/Web App | Cloud → Central Unit | On demand |
¶ Decision Logic
¶ Local (Central Unit)
The Central Unit evaluates rules independently of cloud connectivity.
IF room_temperature < target_setpoint - hysteresis
AND window_state == CLOSED
AND schedule.active == TRUE
THEN thermostat.open_valve()
ELSE thermostat.close_valve()
Priorities (highest → lowest):
- Safety overrides (leak detected, CO₂ threshold exceeded)
- Manual user command (local or remote)
- Active schedule
- Eco / away mode
- Default setpoint
¶ Cloud-side
The cloud layer handles cross-room optimization, user-defined automations, and AI-assisted suggestions.
- Energy optimization — reduce heating in unused rooms
- Presence detection — adjust setpoints based on user location
- Predictive heating — pre-heat rooms before scheduled events
- Anomaly alerts — notify user of unusual patterns
¶ Event Bus
All internal messages follow a topic-based MQTT structure:
ecozy/{home_id}/{device_id}/telemetry # sensor data
ecozy/{home_id}/{device_id}/command # control commands
ecozy/{home_id}/{device_id}/status # device state
ecozy/{home_id}/events # system-wide events