docs(zigbee2mqtt): correct and trim the WS90 debounce comment

The value is unchanged and correct; the comment committed alongside it in #559 was neither accurate nor the right place for most of what it said. Accuracy. It cited the device's ZCL reporting configuration as the bound, reading minRepIntval 10 as "the station updates every 10s". minRepIntval is not a cadence: with maxRepIntval 3600 and a reportable change set, the ZCL reporting model gives periodic reports at the MAXIMUM interval — once an hour — plus change-driven reports each held back so it lands no sooner than 10s after the previous. It is a hold-off on change-triggered reports and says nothing about the gap between reports of different attributes, which is what a debounce window sees. The bound that applies is the documented transmit interval — readings every 2s, transmitted every 8.8s — against Z2M's documented rule not to set debounce above the sensor's update interval. Shelly's knowledge base rounds the same figure to 9s. It also claimed the window had to exceed 1s because "the recovery burst straddles a second boundary", inferred from log lines stamped 11:42:11 and 11:42:12. Those are second-resolution timestamps and cannot distinguish 10ms from 900ms. No lower bound was ever established. Length. The rest was commit-message material sitting in a config file: justification for the chosen value, gap-distribution and run-length measurements, and notes reconciling my own earlier misreadings. Comments state facts about the system, not the history of arriving at them. What remains is what the device does, what debounce does to it, and the constraint on the value — 41 lines down to 13. Verified before writing: post-debounce frames arrive complete (all 22 fields, no partials) at a settled ~10s cadence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merge pull request 'feat(zigbee2mqtt): 2.13.0 and debounce the WS90 report burst' (#559 ) from worktree-z2m-2.13.0-ws90-debounce into master
2026-08-23 22:39:20 +02:00 · 2026-08-23 20:06:50 +00:00 · 2026-08-23 22:03:17 +02:00 · 2026-08-21 21:42:10 +00:00
3 changed files with 22 additions and 3 deletions
@@ -84,7 +84,7 @@ spec:
          env:
            - name: DB_URI
              valueFrom:
-                secretKeyRef: { name: ha-pg-app, key: fqdn-uri }
+                secretKeyRef: {name: ha-pg-app, key: fqdn-uri}
          volumeMounts:
            - name: config
              mountPath: /config
@@ -96,7 +96,7 @@ spec:
              memory: 32Mi
      containers:
        - name: home-assistant
-          image: ghcr.io/home-assistant/home-assistant:2026.8.2 # {"$imagepolicy": "flux-system:home-assistant"}
+          image: ghcr.io/home-assistant/home-assistant:2026.8.3 # {"$imagepolicy": "flux-system:home-assistant"}
          env:
            - name: TZ
              value: Europe/Berlin
@@ -176,3 +176,22 @@ data:
        friendly_name: Treppenhaus Haustür Schalter 1
      '0x001788010b00d011':
        friendly_name: Treppenhaus Haustür Schalter 2
+      # Ecowitt WS90 weather station. Joined after the ZHA-mirrored block above
+      # was written, hence listed apart from it.
+      #
+      # The station transmits every 8.8s, as a burst of seven per-cluster ZCL
+      # frames; Z2M publishes its full cumulative state once per frame. debounce
+      # merges a burst into one publish carrying the last value per attribute,
+      # and must stay below the transmit interval — a window that never sees
+      # silence never flushes.
+      #
+      # The firmware drops all readings to zero for a few seconds every few
+      # days. Merged, that surfaces as a single all-zero frame; unmerged, the
+      # zeros spread across the seven frames and none of them is individually
+      # distinguishable from a valid reading.
+      #
+      # Z2M reads this only at startup (requiresRestart), and this file is
+      # SEED-ONLY per the header — the running instance takes it from its PVC.
+      '0xc02cedfffe958f40':
+        friendly_name: Wetterstation
+        debounce: 2
@@ -158,7 +158,7 @@ spec:
          # Pinned tag. No Flux image-automation marker yet (unlike mosquitto) —
          # add an infrastructure/image-automation/zigbee2mqtt.yaml policy as a
          # follow-up if desired; pinned-and-manual is fine for the initial cutover.
-          image: ghcr.io/koenkk/zigbee2mqtt:2.12.1
+          image: ghcr.io/koenkk/zigbee2mqtt:2.13.0
          imagePullPolicy: IfNotPresent
          env:
            - name: TZ
Author	SHA1	Message	Date
claude-botandClaude Opus 5	87c6f1235c	docs(zigbee2mqtt): correct and trim the WS90 debounce comment ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details The value is unchanged and correct; the comment committed alongside it in #559 was neither accurate nor the right place for most of what it said. Accuracy. It cited the device's ZCL reporting configuration as the bound, reading minRepIntval 10 as "the station updates every 10s". minRepIntval is not a cadence: with maxRepIntval 3600 and a reportable change set, the ZCL reporting model gives periodic reports at the MAXIMUM interval — once an hour — plus change-driven reports each held back so it lands no sooner than 10s after the previous. It is a hold-off on change-triggered reports and says nothing about the gap between reports of different attributes, which is what a debounce window sees. The bound that applies is the documented transmit interval — readings every 2s, transmitted every 8.8s — against Z2M's documented rule not to set debounce above the sensor's update interval. Shelly's knowledge base rounds the same figure to 9s. It also claimed the window had to exceed 1s because "the recovery burst straddles a second boundary", inferred from log lines stamped 11:42:11 and 11:42:12. Those are second-resolution timestamps and cannot distinguish 10ms from 900ms. No lower bound was ever established. Length. The rest was commit-message material sitting in a config file: justification for the chosen value, gap-distribution and run-length measurements, and notes reconciling my own earlier misreadings. Comments state facts about the system, not the history of arriving at them. What remains is what the device does, what debounce does to it, and the constraint on the value — 41 lines down to 13. Verified before writing: post-debounce frames arrive complete (all 22 fields, no partials) at a settled ~10s cadence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 22:39:20 +02:00
k.renner	1ce3f449d4	Merge pull request 'feat(zigbee2mqtt): 2.13.0 and debounce the WS90 report burst' (#559 ) from worktree-z2m-2.13.0-ws90-debounce into master ci/woodpecker/cron/issue-fix Pipeline was successful Details ci/woodpecker/cron/alert-monitor Pipeline was successful Details Reviewed-on: k.renner/homelab#559	2026-08-23 20:06:50 +00:00
claude-botandClaude Opus 5	91e55d3b56	feat(zigbee2mqtt): 2.13.0 and debounce the WS90 report burst ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details Two changes to the Wetterstation (Ecowitt WS90, 0xc02cedfffe958f40), both aimed at the station's recurring zero-drop glitch. 2.13.0 carries zigbee-herdsman-converters#12748, which discards the ZCL non-value markers (0xffff / 0xff / 0xffffff) the WS90 emits when a reading is unavailable. Without it those markers are scaled and published as measurements — the 6553 m/s gust readings in Koenkk/zigbee2mqtt#31048. The release also recovers the rain rate after a counter reset, which is the same lifetime-counter dip that packages/wetterstation.yaml compensates for on the Home Assistant side. Its only breaking change is dropping Node.js 20 for bare-metal installs; the container ships its own runtime. The amd64 manifest was verified pullable before this commit. debounce: 2 addresses the part 2.13.0 does not fix. Koenkk/zigbee2mqtt#31048 is still open, and the author of #12748 states explicitly that it does not cover the zero drops: "a zero can be a real reading for these attributes, only the all-bits-set markers are provably invalid." The station reports as a burst of seven per-cluster ZCL frames and Z2M publishes its full cumulative state once per frame, so one device report becomes seven MQTT messages. During a glitch the zeros appear progressively across those seven, which is what makes the corruption unrecognisable downstream: an intermediate frame carrying {"temperature":0,"humidity":92, "pressure":96.9} is internally consistent (Z2M recomputes dew_point from the false temperature) and cannot be told apart from a legitimate winter reading. Merging the burst yields a single frame with the all-zero signature, which a consumer can reject. The window is bounded on both sides. Above: the device's own reporting configuration sets minRepIntval 10 / maxRepIntval 3600 on all seven WS90 clusters (1024/1026/1027/1029 and 0xfc01/0xfc02/0xfc03), so no attribute repeats inside 10s. Below: the recovery burst straddles a second boundary, so 1s splits it and emits a partial frame. Staggering was checked rather than assumed — the 10s floor is per attribute, and nine attributes report across those clusters, so a trailing-edge timer could in principle keep resetting and never flush. Over 6h the longest unbroken chain of sub-2s gaps was 5, bounding worst-case deferral under ~10s. The device is also absent from the seeded device list, which predates it joining, so this adds the friendly_name too. NOTE: this file is seed-only. A running Z2M owns its configuration.yaml on the PVC, so this does not change the live instance — it only makes a fresh PVC come up correctly. debounce is requiresRestart, so applying it live needs the option set on the running instance and a restart; the image bump supplies the restart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 22:03:17 +02:00
security-bot	287cce7d1a	chore(image-automation): bump ghcr.io/home-assistant/home-assistant:2026.8.3 ci/woodpecker/cron/update-all Pipeline failed Details ci/woodpecker/cron/e2e Pipeline was successful Details ci/woodpecker/cron/security-scan Pipeline was successful Details ci/woodpecker/cron/issue-fix Pipeline was successful Details ci/woodpecker/cron/alert-monitor Pipeline was successful Details Updates managed by image-automation-controller.	2026-08-21 21:42:10 +00:00