Who decides what — hub vs brain

The authority split: hub-owned safety and demand, brain-owned targets, tasks, rules and the Sonoff driver; why demand proposals are shadow mode; what happens when the brain or hub goes away.

Authority: the brain proposes; the hub refuses or clamps. Every write from the brain goes through hub controls with native min, max and step. If the hub does not accept a value you see not applied — still X (reason).

• Setpoints and modes through the control service (targets, photoperiod, stage presets, 2×4 climate mode, takeover flags when you ask). With brain-owned stage presets on, a stage change writes the five 4×8 targets and a 4×8 temperature band of the setpoint ±1.5 °C, so the temperature alert follows the stage.
• Zigbee tasks (appliance OOS, banners, lamp plugs) and Tuya switches, including the opt-in Safety cut-off: when a smoke, gas or CO alarm trips it takes the heater and heat mat out of service with their relays forced off and holds the lamp plugs off, by default until you release it.
• Automation rule actions (cut-outs, operator-owned switches, clamped setpoints).
• The Sonoff appliance driver: mirrors the hub's demand switches to the in-service plugs every 2 seconds, and forces every relay OFF when the hub reading is older than 45 seconds. A task, rule or safety cut-off that takes a seat out of service forces that seat's relay OFF.

The hub's *_demand switches belong to its Full Auto ladder. The brain's decision loop logs its demand proposals (shadow mode) and does not write them, because:

1. A brain write would be re-asserted by the hub on its next tick. That is a fight, not control.
2. The loop only proposes demand on; there is no demand off, so real writes would latch appliances on with nothing to release them.
3. The brain already acts where it owns the surface (setpoints, tasks, rules, the Sonoff driver).

The honest wording on the desks is brain proposes, hub applies. A brain-owned demand mode is a firmware change tracked as a feature, not a flag.

The hub keeps the room on its ladder from the last targets. The Sonoff plugs keep following hub demand as long as the hub is alive (the driver is on the brain, so with the brain down the plugs hold their last command — which is why a Tuya plug is never trusted with a heater). The dashboard is unavailable. A brain restart drops the Pi hotspot briefly; fleet devices rejoin within about two minutes, so expect a short fleet-offline window on every deploy.

The brain raises hub not reporting (critical after 3 minutes), stops judging frozen readings, and the Sonoff driver forces every relay OFF after the 45-second stale horizon. The 2×4 lamp and fans are on the hub, so they stop with it.

If the hub reconnects while manual takeover is on, the brain records a reconnect override with a 15-minute TTL (Settings › System › Failover › Hub override TTL) and does not re-assert Want. When the TTL fires while takeover is still on, the state becomes pending re-assert: Want re-asserts as soon as you turn takeover off. Operator takeover is always temporary by design.

Guide contents  ·  How it works  ·  Troubleshooting  ·  Digital Stealth Care

DSC-Brain user guide · Who decides what — hub vs brain · this page is edited on the site; the Notion original was retired after the mirror