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 logged, not written; what happens when the brain or hub goes away. Since 9.8.9 it also says where the planner and its Control screen fit.

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 it has heard nothing from the hub for more 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 (for review only) 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. Hub firmware 8.5.0.0 can let the brain own an output, but no output has been handed over: the hub's own control still runs the room.

Alongside, the brain's planner works out a plan for each class of device and keeps the reason. You can read the reasons in the Why panel on Today; the Kit model screen under Settings › Advanced shows the model it works from. The Who is in charge screen, also under Settings › Advanced, lists each class and who is in charge of it, with a one-tap way back to the old behaviour.

A timed run (Run for a while on a device tile, or Run it now on a device's page) is sent to a device only when the new engine switches that kind of device. Otherwise the receipt reads Planned only, nothing was sent, and the hub's own control carries on. Nothing is shown as on until the device's own reading confirms it.

The hub keeps running its wired fans and dimmed lamps from its own sensors and its own clock, inside its hard limits. The four Sonoff plugs are switched by the brain, so the hub cannot hold them: each starts OFF at power-on and switches itself OFF when it has not heard from the brain for its grace time (heater 60 seconds, heat mat and humidifier 90 seconds, dehumidifier 4 minutes). A Tuya plug holds its last state when the brain stops, which is why a Tuya plug is never trusted with a heater. The hub's hard limits and each plug's grace time are set out on When the brain stops: the hub and the plugs. 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 hub-dimmed 4×8 lamp and the fans are on the hub, so they stop with it.

If the hub reconnects while manual takeover is on, the brain holds off for the hold timeout (Settings › System › Failover › Hold timeout after reconnect, 15 minutes by default) and does not re-assert Want. When the timeout ends while the takeover is still on, the state becomes PENDING RE-ASSERT: Want re-asserts as soon as you clear the takeover by handing the devices back. Operator takeover is always temporary by design.

Related: The planner: what it decides and why and Who is in charge and rolling back.

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