node-red-contrib-velbus-2026 0.8.1 → 0.9.1

package/CHANGELOG_FORUM.md

@@ -14,6 +14,87 @@ All feedback via GitHub issues, with examples and debug captures where possible.
 
 ---
 
+## v0.9.1 — 08/07/2026
+
+### Address validation bug — 12 of 19 node types, any address ≥100 decimal
+
+- **Reported by Stuart:** adding a velbus-sensor node and selecting VMB4AN
+  from the scan dropdown showed a red "not configured correctly" triangle
+  no matter what was selected.
+- **Root cause:** every node using the `address` field (as opposed to
+  `moduleAddr`, used by relay/dimmer nodes, which were unaffected) validated
+  it against `/^(0x)?[0-9a-fA-F]{1,2}$/` — a pattern that only ever made
+  sense if `address` were stored as a 1-2 character hex string. But
+  `oneditsave` on every one of these nodes stores it as a plain decimal
+  **number** instead (`parseInt(...)`). Since regex `.test()` coerces its
+  argument to a string first, any address whose decimal representation is
+  1-2 digits (1-99) happened to accidentally still match — every digit
+  0-9 is also a valid hex character — masking the bug for low addresses.
+  Any address **100 or higher** (`0x64`+) produces a 3-digit decimal string,
+  which cannot match a `{1,2}`-length pattern, so validation always failed.
+  100-254 is a very ordinary real-world address range — this was a live,
+  fully user-facing bug, not an edge case.
+- **Affected nodes (12):** velbus-blind, velbus-blind-s, velbus-blind-20,
+  velbus-button, velbus-energy, velbus-glass-panel, velbus-meteo,
+  velbus-pir, velbus-pir-20, velbus-sensor, velbus-sensor-20,
+  velbus-thermostat. Confirmed relay/dimmer/relay-20/dimmer-20 (which use
+  `moduleAddr`, no custom validate function) and velbus-clock (no fixed
+  address at all) were never affected.
+- **Fix:** replaced the regex with a direct numeric range check
+  (`parseInt(v)` between 1 and 254 inclusive) — correct regardless of
+  whether the stored value is a number, a decimal string, or a legacy hex
+  string (`parseInt` auto-detects a `0x` prefix), so old saved flows keep
+  working unchanged.
+- Verified: syntax-checked the extracted JS from all 12 files, and
+  confirmed the corrected logic against the actual failing range (50/80/99
+  → true both before and after; 100/150/254 → **false before, true after**;
+  0/255/empty/non-numeric → false, correctly rejected as invalid addresses
+  both before and after).
+
+---
+
+## v0.9.0 — 08/07/2026
+
+### velbus-energy — new node (19th node), VMBPSUMNGR-20
+
+- **Closes the last "not yet built" item on the module registry** —
+  VMBPSUMNGR-20 (0x04), the power-supply-manager module, following the same
+  V2 architectural pattern as `velbus-sensor-20` (firmware/type check, name
+  auto-retrieval, standard startup RTR).
+- Handles: `0xED` module status (PSU load %ages, alarm bitmasks, shared
+  program/clock-alarm/sunrise/sunset byte), `0x00` real-time alarm events
+  (arrives via primary address as one bitmask, via sub-address1 as a second
+  bitmask — same command, discriminated by source address, merged into
+  running alarm state so a partial update never discards the other half),
+  `0xA1` warranty counter (31-bit hours-in-operation + expired flag, packed
+  across 4 bytes), `0xA2` PSU load status (mode + 3 load percentages), `0xA3`
+  PSU values (wattage/voltage/amperage per rail, one message per PSU/PSUOut).
+- **Does not reimplement the shared V2 "system" commands** (real-time clock,
+  date, DST, sunrise/sunset, clock alarm) present throughout this PDF —
+  `velbus-clock` already owns broadcasting those; duplicating them here
+  would just be dead weight.
+- **Two real errors found in Velbus's own protocol PDF while implementing
+  this, both documented in the node's source comments:**
+  - The document header reads "VMB8IN-20 PROTOCOL" throughout — an
+    un-retitled template artifact from a different module's document.
+  - The `0xA3` (PSU values status) section labels three different byte
+    positions all as "DATABYTE6" (voltage high, amperage high, amperage
+    low) — internally inconsistent with its own stated 8-byte length.
+    Reconstructed from the byte count as DATABYTE5/6 = voltage hi/lo,
+    DATABYTE7/8 = amperage hi/lo. Same category as the temperature-divisor
+    and build-number-mislabelling issues already known elsewhere in this
+    project — worth remembering if re-checking against the source PDF.
+- Verified with the mock-RED harness: every packet type (module type
+  identification, both alarm bitmask sources, module status, warranty
+  counter, PSU load, PSU values, name assembly across all three name-part
+  commands) exercised with hand-checked checksums; outgoing commands
+  (`get_status`, `get_warranty`, `get_name`) checksum-verified by hand
+  against the actual bytes produced. **Not yet sent to a real bus** — no
+  VMBPSUMNGR-20 has been confirmed present on a scanned bus yet (see the
+  handover's outstanding-verification notes).
+
+---
+
 ## v0.8.1 — 07/07/2026
 
 ### velbus-clock — set_alarm command (global + local, one command)