Let occupants disable a room sensor in the web UI #12
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
The control temperature uses
minaggregation on purpose: being too cold matters more than being too warm, so the coldest room sensor decides. That only works when every room sensor is at a spot someone is using. When the occupants are away from a spot for a longer time (e.g. a desk not used for a few weeks), they should be able to disable its sensor in the web UI, so an empty cold corner doesn't drive the heater.The immediate trigger is a second study sensor at a desk that is being powered again.
Terms are in GLOSSARY.md (Sensors): room sensor, disabled sensor, always-enabled sensor, offline sensor.
Decisions
override_untilon manual overrides) can come later.always_enabled: trueon the DS1820) and has no toggle in the UI. Any other room sensor can be disabled. So there is always a control temperature, and there's no "can't disable the last sensor" rule.minit only takes over when the other sensors are disabled or offline, and then the rooms run somewhat cold. It is the right fallback anyway: wired, read every few seconds, and independent of batteries, Zigbee and the broker.Implementation notes
temperature.Sensor.Enabledalready exists and makesIsHealthyfalse, so the aggregator already leaves disabled sensors out. The service sets every sensor to enabled at startup (internal/application/thermostat_service.go).always_enabled, a sensor-changes history table (migration), restoring the latest state per sensor at startup, an enable/disable endpoint that refuses always-enabled sensors, and the toggle on the dashboard's sensor list.IsHealthyalong the glossary (enabled and online).Checklist
always_enabled, set on the bathroom DS1820 inconfigs/config.yaml.blubconfigs/config.yaml.blub