pti/blubgo
Watch
1
0
Fork
You've already forked blubgo
 0
Code Issues 7 Pull requests Projects Releases Packages Wiki Activity Actions

Study sensor reports in 0.3 °C steps: tune its zigbee2mqtt reporting #15

New issue
Open
opened 2026-10-29 11:36:43 +01:00 by pti · 0 comments
pti commented 2026-10-29 11:36:43 +01:00
Owner

Problem

The study sensor (zigbee2mqtt/buros_boven, battery powered) reports in coarse steps:

  • a new report only when the temperature changed by about 0.3 °C, otherwise
  • a heartbeat about every 30 minutes.

2026-10-29 warm-up: reports at 09:24, 09:30, 09:37, 09:44, 09:52, 10:00, in steps of 0.31 °C. After switch-off: 10:09, 10:25, 10:30, 11:00.

The steps are as large as the predicted overrun (about 0.5 °C), so they matter for control:

  • Rise rate: estimated from a staircase. It is fine at 2.3 °C/h but poorly defined at slow rises.
  • Switch-off: the anticipation can only act when a report arrives.
  • Peak: a 0.2 °C drop or a levelled-off temperature shows up at least one report late.
  • Delay: after the heater switched on at 09:00, the first reported rise came at 09:24. How much of that is the room and how much is the 0.3 °C threshold is unknown.

To do

  • Look up the device model in zigbee2mqtt and whether it supports reporting configuration (Reporting tab: msTemperatureMeasurement / measuredValue).
  • If it does, set the minimum reportable change to 0.1 °C (10 in centi-degrees). Keep the minimum interval at 1 min or more and the maximum interval at about 10–15 min, so the battery lasts.
  • Watch the battery level for a few weeks after the change.
  • If it does not support it, consider a mains-powered or better-reporting sensor for the study.

The same applies to sensors added from the web UI (#13).

## Problem The study sensor (`zigbee2mqtt/buros_boven`, battery powered) reports in coarse steps: - a new report only when the temperature changed by about 0.3 °C, otherwise - a heartbeat about every 30 minutes. 2026-10-29 warm-up: reports at 09:24, 09:30, 09:37, 09:44, 09:52, 10:00, in steps of 0.31 °C. After switch-off: 10:09, 10:25, 10:30, 11:00. The steps are as large as the predicted overrun (about 0.5 °C), so they matter for control: - **Rise rate:** estimated from a staircase. It is fine at 2.3 °C/h but poorly defined at slow rises. - **Switch-off:** the anticipation can only act when a report arrives. - **Peak:** a 0.2 °C drop or a levelled-off temperature shows up at least one report late. - **Delay:** after the heater switched on at 09:00, the first reported rise came at 09:24. How much of that is the room and how much is the 0.3 °C threshold is unknown. ## To do - Look up the device model in zigbee2mqtt and whether it supports reporting configuration (Reporting tab: `msTemperatureMeasurement` / `measuredValue`). - If it does, set the minimum reportable change to 0.1 °C (10 in centi-degrees). Keep the minimum interval at 1 min or more and the maximum interval at about 10–15 min, so the battery lasts. - Watch the battery level for a few weeks after the change. - If it does not support it, consider a mains-powered or better-reporting sensor for the study. The same applies to sensors added from the web UI (#13).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v0.11
v0.10
v0.9
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#15
No description provided.