zigbee2mqtt: apply WS90 reporting config via external converter #1092

2026-10-01T10:01:29Z

claude-bot commented

2026-10-01 10:01:29 +00:00

The WS90 reporting configuration (zigbee2mqtt-ws90-reporting.md) only lived on the device and in database.db. Every interview or device/configure reset it to the converter defaults, and zero frames came back (2026-09-25..29).

New external converter zigbee2mqtt-ws90-converter.js: the built-in WS90 definition plus a configure step that sets the ten documented reporting values. version: ws90-reporting-1 makes Z2M reconfigure the device once after load.
seed-data copies converters from the new ConfigMap zigbee2mqtt-external-converters into /app/data/external_converters on every start. Not mounted, because Z2M writes a temp copy into that directory while loading (dist/extension/externalJS.js).
Reporting doc updated.

Tested in the running pod (no state change) against a mocked device: the definition is picked over the built-in one, and configure ends with the ten documented values (5/3600/…, Shelly clusters with manufacturerCode 5264). Kustomize build + server dry-run: ok.

Merging restarts Z2M (deployment change). After rollout: expect Successfully configured 'Wetterstation' (definition vws90-reporting-1) in the log and min=5 in database.db.

🤖 Generated with Claude Code

The WS90 reporting configuration (`zigbee2mqtt-ws90-reporting.md`) only lived on the device and in `database.db`. Every interview or `device/configure` reset it to the converter defaults, and zero frames came back (2026-09-25..29). - New external converter `zigbee2mqtt-ws90-converter.js`: the built-in WS90 definition plus a configure step that sets the ten documented reporting values. `version: ws90-reporting-1` makes Z2M reconfigure the device once after load. - `seed-data` copies converters from the new ConfigMap `zigbee2mqtt-external-converters` into `/app/data/external_converters` on every start. Not mounted, because Z2M writes a temp copy into that directory while loading (`dist/extension/externalJS.js`). - Reporting doc updated. Tested in the running pod (no state change) against a mocked device: the definition is picked over the built-in one, and configure ends with the ten documented values (`5/3600/…`, Shelly clusters with manufacturerCode 5264). Kustomize build + server dry-run: ok. Merging restarts Z2M (deployment change). After rollout: expect `Successfully configured 'Wetterstation' (definition vws90-reporting-1)` in the log and min=5 in `database.db`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-10-01 10:01:30 +00:00

zigbee2mqtt: apply WS90 reporting config via external converter

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

ci/woodpecker/pr/ci-manifests-test Pipeline failed

Details

025423b342

The WS90 reporting configuration (zigbee2mqtt-ws90-reporting.md) only
lived on the device and in database.db; every interview or
device/configure reset it to the converter defaults (2026-09-24..28,
zero frames recurred).

New external converter extends the built-in WS90 definition with a
configure step that sets the documented values. Its version
(ws90-reporting-1) makes Z2M reconfigure the device once after load.
seed-data copies converters from a ConfigMap into
/app/data/external_converters on every start; not mounted because Z2M
writes a temp copy into that directory while loading.

Tested in the running pod against a mocked device: the definition is
picked over the built-in one, and configure ends with the ten
documented reporting values.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

claude-bot commented

2026-10-01 10:01:34 +00:00

Requested by the owner (2026-10-01) in a direct session; the owner merges this directly.

review-bot reviewed

2026-10-01 10:05:10 +00:00

review-bot left a comment

🤖 Automated review — model claude-sonnet-5 (complexity: normal), commit 025423b342680dccedfd2624e56c24523cae96f9.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

This PR fixes the WS90 weather-station reporting config getting reset on every Z2M configure by shipping a new external converter (zigbee2mqtt-ws90-converter.js) that extends the built-in WS90 definition with the ten documented reporting values, and wires it into the Z2M pod via a new ConfigMap copied into /app/data/external_converters on every pod start. The mechanics (ConfigMap generator, init-container copy-not-mount, volume wiring) are consistent with the rest of the file and the stated rationale (Z2M writes a temp file into that directory while loading a converter, which a read-only mount would reject) is plausible and matches the PR's own testing notes. No blocking issues found; one doc inconsistency is worth fixing before merge.

🟡 Suggestions

kubernetes/apps/home-assistant/zigbee2mqtt-config.yaml:182-187 — this comment block (pre-existing, not touched by the diff) still says the WS90 reporting config "is lost whenever Z2M re-runs configure on the device, and a fresh PVC will not have it" because "Z2M has no settings field for it." That is now false once this PR merges: with the converter loaded, configure re-applies the documented values instead of losing them, and a fresh PVC picks up the converter from the ConfigMap too (the init container copies it unconditionally, unlike the PVC-seeded configuration.yaml/coordinator_backup.json). zigbee2mqtt-ws90-reporting.md was correctly updated to reflect this, but this comment — a second copy of the same claim — was missed and now directly contradicts it. Worth updating so there isn't a third, drifting copy of this fact (the reporting doc already asks you to keep two in sync: the table and REPORTING).
kubernetes/apps/home-assistant/zigbee2mqtt-deployment.yaml:139-141 — cp /external-converters/*.js /app/data/external_converters/ copies forward but never removes stale files. If a converter is ever renamed or deleted from kustomization.yaml's zigbee2mqtt-external-converters generator, the old file left behind on the PVC keeps being picked up by Z2M's directory auto-load on every future start (nothing here or in the ConfigMap removes it). Not a problem today with a single converter file, but it's a latent trap for the next change in this area — consider clearing the destination directory (e.g. rm -f /app/data/external_converters/*.js) before the copy.

Tests

No automated tests exist for this repo's GitOps YAML/JS, consistent with the rest of the codebase. The PR body describes manual verification (pod testing against a mocked device, kustomize build + server dry-run) which is the right level of diligence for this kind of change; the actual device-facing behavior (built-in definition overridden, configure produces the ten documented values) can only be confirmed post-rollout as the PR body itself notes.

Recommendation

Looks reasonable — no blocking issues; comments above are optional (though the stale doc comment is worth fixing before merge to avoid two documents actively disagreeing).

🤖 **Automated review** — model `claude-sonnet-5` (complexity: normal), commit `025423b342680dccedfd2624e56c24523cae96f9`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary This PR fixes the WS90 weather-station reporting config getting reset on every Z2M `configure` by shipping a new external converter (`zigbee2mqtt-ws90-converter.js`) that extends the built-in WS90 definition with the ten documented reporting values, and wires it into the Z2M pod via a new ConfigMap copied into `/app/data/external_converters` on every pod start. The mechanics (ConfigMap generator, init-container copy-not-mount, volume wiring) are consistent with the rest of the file and the stated rationale (Z2M writes a temp file into that directory while loading a converter, which a read-only mount would reject) is plausible and matches the PR's own testing notes. No blocking issues found; one doc inconsistency is worth fixing before merge. ## 🟡 Suggestions - `kubernetes/apps/home-assistant/zigbee2mqtt-config.yaml:182-187` — this comment block (pre-existing, not touched by the diff) still says the WS90 reporting config "is lost whenever Z2M re-runs `configure` on the device, and a fresh PVC will not have it" because "Z2M has no settings field for it." That is now false once this PR merges: with the converter loaded, `configure` re-applies the documented values instead of losing them, and a fresh PVC picks up the converter from the ConfigMap too (the init container copies it unconditionally, unlike the PVC-seeded `configuration.yaml`/`coordinator_backup.json`). `zigbee2mqtt-ws90-reporting.md` was correctly updated to reflect this, but this comment — a second copy of the same claim — was missed and now directly contradicts it. Worth updating so there isn't a third, drifting copy of this fact (the reporting doc already asks you to keep two in sync: the table and `REPORTING`). - `kubernetes/apps/home-assistant/zigbee2mqtt-deployment.yaml:139-141` — `cp /external-converters/*.js /app/data/external_converters/` copies forward but never removes stale files. If a converter is ever renamed or deleted from `kustomization.yaml`'s `zigbee2mqtt-external-converters` generator, the old file left behind on the PVC keeps being picked up by Z2M's directory auto-load on every future start (nothing here or in the ConfigMap removes it). Not a problem today with a single converter file, but it's a latent trap for the next change in this area — consider clearing the destination directory (e.g. `rm -f /app/data/external_converters/*.js`) before the copy. ## Tests No automated tests exist for this repo's GitOps YAML/JS, consistent with the rest of the codebase. The PR body describes manual verification (pod testing against a mocked device, `kustomize build` + server dry-run) which is the right level of diligence for this kind of change; the actual device-facing behavior (built-in definition overridden, configure produces the ten documented values) can only be confirmed post-rollout as the PR body itself notes. ## Recommendation Looks reasonable — no blocking issues; comments above are optional (though the stale doc comment is worth fixing before merge to avoid two documents actively disagreeing).

k.renner merged commit 9ea9cd67c5 into master

2026-10-01 10:40:54 +00:00

k.renner referenced this issue from a commit

2026-10-01 10:40:54 +00:00

Merge pull request 'zigbee2mqtt: apply WS90 reporting config via external converter' (#1092) from z2m-ws90-converter into master

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#1092