Add Zigbee temperature sensors from the web UI, discovered via zigbee2mqtt #13

Open
opened 2026-10-28 16:46:28 +01:00 by pti · 0 comments
Owner

Follows #12 (occupants enable and disable room sensors).

Why

Adding a Zigbee temperature sensor now means editing configs/config.yaml.blub and redeploying. zigbee2mqtt already publishes what each paired device measures, so blub can offer the temperature sensors it finds and let the occupants add one from the web UI.

How

  • Subscribe to the retained zigbee2mqtt/bridge/devices (base topic configurable). It lists every paired device with its IEEE address, friendly name, model, description and exposes.
  • Offer every device that exposes a numeric temperature and is not a room sensor yet.
  • Adding one subscribes to its topic at runtime: no restart. The MQTT client already supports subscribing while running and resubscribes after a reconnect.

Decisions

  1. Added sensors live in the recorded history. "Sensor added" and "sensor removed" go into sensor_history next to enable/disable, and are replayed at startup (see "State across restarts" in CLAUDE.md). The YAML config keeps the hardware sensors (the bathroom DS1820 with always_enabled) and the MQTT connection. A sensor added in the UI can be removed in the UI; a configured sensor cannot.
  2. A sensor's identity is the device's IEEE address, and its topic is looked up from bridge/devices. Renaming a device in zigbee2mqtt then neither breaks the sensor nor splits its history. (Configured sensors keep their IDs, e.g. buros_sensor.)
  3. Adding asks for the device, a name, and a timeout defaulting to 35 min. That suits sleepy battery sensors, which report every 30 min when the temperature is steady. Weight and location keep their defaults (min aggregation ignores the weight). A new sensor shows Offline until its first report, which can take up to 30 minutes.
  4. Anyone on the LAN can add or remove sensors, like enabling and disabling; the web UI has no login.
  5. Built after #12 is deployed. The second study sensor at a desk can be the first one added this way instead of through the config.

Open questions

  • Removing a sensor: keep its readings (recommended, for #8) and only stop subscribing.
  • Devices that leave the network or disappear from bridge/devices: keep the sensor, which goes Offline by its timeout.
  • Whether to show battery level and link quality from the device's messages on the sensor card.

Checklist

  • Read and parse bridge/devices; list devices exposing temperature that are not room sensors
  • Record "sensor added/removed" in sensor_history (migration) and replay at startup, creating MQTT sensor adapters at runtime
  • Resolve the topic by IEEE address, following renames
  • Web UI: discovered devices with an Add form (name, timeout); Remove on UI-added sensors
  • Check against the real device list on the broker
Follows #12 (occupants enable and disable room sensors). ## Why Adding a Zigbee temperature sensor now means editing `configs/config.yaml.blub` and redeploying. zigbee2mqtt already publishes what each paired device measures, so blub can offer the temperature sensors it finds and let the occupants add one from the web UI. ## How - Subscribe to the retained `zigbee2mqtt/bridge/devices` (base topic configurable). It lists every paired device with its IEEE address, friendly name, model, description and `exposes`. - Offer every device that exposes a numeric `temperature` and is not a room sensor yet. - Adding one subscribes to its topic at runtime: no restart. The MQTT client already supports subscribing while running and resubscribes after a reconnect. ## Decisions 1. **Added sensors live in the recorded history.** "Sensor added" and "sensor removed" go into `sensor_history` next to enable/disable, and are replayed at startup (see "State across restarts" in CLAUDE.md). The YAML config keeps the hardware sensors (the bathroom DS1820 with `always_enabled`) and the MQTT connection. A sensor added in the UI can be removed in the UI; a configured sensor cannot. 2. **A sensor's identity is the device's IEEE address**, and its topic is looked up from `bridge/devices`. Renaming a device in zigbee2mqtt then neither breaks the sensor nor splits its history. (Configured sensors keep their IDs, e.g. `buros_sensor`.) 3. **Adding asks for the device, a name, and a timeout defaulting to 35 min.** That suits sleepy battery sensors, which report every 30 min when the temperature is steady. Weight and location keep their defaults (`min` aggregation ignores the weight). A new sensor shows Offline until its first report, which can take up to 30 minutes. 4. **Anyone on the LAN can add or remove sensors**, like enabling and disabling; the web UI has no login. 5. **Built after #12 is deployed.** The second study sensor at a desk can be the first one added this way instead of through the config. ## Open questions - Removing a sensor: keep its readings (recommended, for #8) and only stop subscribing. - Devices that leave the network or disappear from `bridge/devices`: keep the sensor, which goes Offline by its timeout. - Whether to show battery level and link quality from the device's messages on the sensor card. ## Checklist - [ ] Read and parse `bridge/devices`; list devices exposing temperature that are not room sensors - [ ] Record "sensor added/removed" in `sensor_history` (migration) and replay at startup, creating MQTT sensor adapters at runtime - [ ] Resolve the topic by IEEE address, following renames - [ ] Web UI: discovered devices with an Add form (name, timeout); Remove on UI-added sensors - [ ] Check against the real device list on the broker
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
pti/blubgo#13
No description provided.