Keep user-configured reporting when a device is reconfigured after a definition version change

Open
  • Is something wrong?
#33,651 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
22/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
backend

Research direction

The reconfigure trigger is in lib/extension/configure.ts, where a device is reconfigured when definition.version differs from the stored meta.configured. Read how the reporting/configure request handler persists or drops user-set reporting, and check #4321 and #32001 for the intended behaviour. Any fix needs a maintainer decision on persistence or a per-device override in devices.yaml, so this is not ready for a first contribution.

Written by the indexing model from the issue text.

Description

Is your feature request related to a problem? Please describe

After updating Zigbee2MQTT from 2.14.2 to 2.14.3, all my SONOFF S60ZBTPF plugs (12 devices) were silently reconfigured on startup and lost the reporting configuration I had set in the frontend (Reporting tab).

Cause, as far as I can read the code: lib/extension/configure.ts (2.14.3, lines 109–114) reconfigures a device when definition.version differs from the stored meta.configured. zigbee-herdsman-converters 26.125.0 added version "0.0.1" to the S60ZBTPF definition (26.115.1 had none), so every S60 was reconfigured and got the converter defaults again (acCurrentPowerValue 10 / 65000 / 1 instead of my 30 / 3600 / 500).

Impact: the plugs went back to reporting power every 10 s with a 0.01 W threshold. In Home Assistant this added about 66,000 state rows per day and the recorder database grew by roughly 10 % within two weeks. Nothing told me that my settings had been replaced; I only found it by investigating the database growth. One plug (an oven) has deliberately faster reporting for a safety automation; that was replaced as well.

I understand from #4321 and #32001 that reconfiguring on a definition change is intended and that reporting set via the API is not persisted. This request is about not losing user intent silently.

Describe the solution you'd like

One of these, in order of preference:

  1. Persist reporting set via bridge/request/device/reporting/configure or the Reporting tab (per device, endpoint, cluster, attribute) and re-apply it after configure has run.
  2. A per-device option (e.g. in devices.yaml) with reporting overrides that configure applies after the converter defaults.
  3. At minimum, log a warning and publish an event when a reconfigure replaces reporting that differs from the converter defaults, so users notice.
Describe alternatives you've considered

I now run a Home Assistant automation that hourly reads the reporting via bridge/request/device/reporting/read and writes my values back via reporting/configure when they differ. It works, but every user with custom reporting would need such a workaround.

Additional context

Zigbee2MQTT 2.14.3 (add-on 2.14.3-1), zigbee-herdsman-converters 26.125.0, Home Assistant OS, SONOFF S60ZBTPF firmware 2.1.3. Related: #4321, #32001.

Dominant language
TypeScript
Stars
15.8k
Forks
2.1k
Avg merge
1d 6h
Merged PRs (30d)
38

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Koenkk/zigbee2mqtt

All issues in Koenkk/zigbee2mqtt

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.