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

package/CHANGELOG_FORUM.md

@@ -14,6 +14,75 @@ All feedback via GitHub issues, with examples and debug captures where possible.
 
 ---
 
+## v0.9.3 — 09/07/2026
+
+### velbus-scan — VMBGPOD still showed "unknown_0x28" after the v0.9.2 fix
+
+- **Reported by Stuart:** re-ran a scan against v0.9.2 pulled fresh from npm,
+  `VMBGPOD` still showed as `unknown_0x28`.
+- **Root cause:** `velbus-scan.js` has its **own, third, independent copy**
+  of the type table — `ALL_TYPES`, `NODE_SUGGESTION`, and `MODULE_CHANNELS`
+  — entirely separate from `lib/glass-panel-types.js` (used by
+  `velbus-glass-panel` at runtime) and the duplicate list inside
+  `velbus-glass-panel.html` (used for the editor dropdown), both already
+  fixed in v0.9.2. The v0.9.2 fix genuinely worked for the glass-panel node
+  itself; the bus scanner simply had no idea `VMBGPOD` existed, since it
+  never reads either of the other two files at all.
+- **This is now the third type table found in this codebase.** Searched
+  exhaustively this time (`grep -rln "VMBGPO'"` across the whole `nodes/`
+  and `lib/` tree) rather than assume these three are the only ones — they
+  are, confirmed by the search coming back with exactly these three files
+  and no others.
+- Added `0x28: 'VMBGPOD'` to all three tables in `velbus-scan.js`.
+- **Verified end-to-end this time, not just by inspecting the table.** Built
+  a full mock-harness test that triggers a real scan, feeds a simulated
+  `0xFF` response for `VMBGPOD` (using the exact build/serial from Stuart's
+  own scan output), and confirms the emitted `module_found` payload reports
+  `"module":"VMBGPOD"`, the correct suggested node, and the correct channel
+  count — not just that the table lookup would theoretically work.
+- **Worth remembering for any future module type addition:** check all
+  three of `lib/<family>-types[-20].js`, the corresponding node's own
+  `.html` (editor dropdown), and `velbus-scan.js` (bus-wide discovery).
+  Missing any one of the three produces a real, user-visible symptom in a
+  different part of the palette than wherever the fix was actually made —
+  exactly what happened here.
+
+---
+
+## v0.9.2 — 09/07/2026
+
+### velbus-glass-panel — VMBGPOD (0x28) registry gap fixed
+
+- **Found by Stuart:** scanning his own home installation showed `unknown_0x28`
+  for three real modules — the palette had never included this type at all.
+- **Real-world significance:** per the VLP training dataset analysed earlier
+  in this project, VMBGPOD is one of the **most common** glass panel types
+  in the field (978 occurrences, second only to VMB4RYLD and VMBDMI-R) — a
+  genuine, consequential gap, not an edge case. Only its V2 sibling
+  (`VMBGPOD-2`, 0x3D) had ever been added.
+- Added to both `lib/glass-panel-types.js` (server-side) and the duplicate
+  type list in `velbus-glass-panel.html` (editor-side dropdown/display) —
+  confirmed both needed updating, not just one.
+- **Confirmed from protocol_vmbgpod.pdf:** OLED display present; no
+  open-collector commands anywhere in the document (distinct from `VMBGPO`,
+  0x21, a different product despite the similar name — that one does have
+  OC support).
+- **One real mistake caught and corrected before shipping:** first pass
+  copied the channel count (32) from `VMBGPO` on the assumption it was the
+  closest sibling. Cross-checking the editor's own duplicate type list
+  before finalising showed `VMBGPOD-2` — the *actual* V2 sibling of this
+  same product line — lists 4 channels, not 32. Corrected to 4. Worth
+  remembering: when modelling a new registry entry on an existing one,
+  check for a same-name generational sibling before assuming the
+  closest-looking name is the right reference.
+- Also identified in the same scan, **not yet added:** `VMBKP` (0x42,
+  "Keypad interface module") — a substantial 28-page protocol with its own
+  per-channel LED control layer, genuinely new territory rather than a
+  quick registry addition. Flagged for separate scoping, same approach as
+  velbus-energy before it was built.
+
+---
+
 ## v0.9.1 — 08/07/2026
 
 ### Address validation bug — 12 of 19 node types, any address ≥100 decimal

package/HANDOVER.md

@@ -6,7 +6,7 @@ you're a new contributor, a new maintainer, or an AI assistant starting a fresh
 with no memory of previous work — this document should be sufficient on its own, together
 with the source code in this repository, to continue development competently.
 
-Current state at time of writing: **v0.9.0, 19 nodes, published on npm.**
+Current state at time of writing: **v0.9.3, 19 nodes, published on npm.**
 
 ---
 
@@ -106,7 +106,7 @@ lib/                       Shared code — protocol utilities and per-module-fam
   dimmer-types.js            Original-series dimmer module type registry
   dimmer-types-20.js         V2 dimmer module type registry (incl. LED grouping mode / Device
                              Type table for VMB4LEDPWM-20)
-  glass-panel-types.js       All 26 glass panel module types in one registry (hasOled/hasPir/
+  glass-panel-types.js       All 27 glass panel module types in one registry (hasOled/hasPir/
                              hasOc/minMapVer flags per type)
   pir-types.js / pir-types-20.js       PIR sensor module type registries
   sensor-types.js / sensor-types-20.js Sensor/meteo module type registries
@@ -144,6 +144,24 @@ boilerplate (bridge lookup, packet registration, status bar handling, firmware c
 V2 nodes) is consistent across every node and easy to get subtly wrong if rebuilt from
 scratch.
 
+**Adding or fixing a module type touches three separate files, not one — confirmed
+the hard way (v0.9.2 → v0.9.3).** A module type used to exist in exactly one place per
+node family; it doesn't. Check all three every time:
+1. `lib/<family>-types[-20].js` — used by the actual node at runtime (`velbus-glass-panel`,
+   `velbus-sensor`, etc.)
+2. The corresponding node's own `.html` file — a **separate, duplicate** copy used only
+   to populate the editor's address dropdown and type hint. Not read by the running node
+   at all.
+3. `nodes/velbus-scan/velbus-scan.js` — has its **own, third, entirely independent** copy
+   (`ALL_TYPES`, `NODE_SUGGESTION`, `MODULE_CHANNELS`), used only for bus-discovery
+   reporting. Doesn't read either of the other two files.
+
+Missing any one of the three produces a real, user-visible symptom in a *different* part
+of the palette than wherever the fix actually needs to happen — a scan reporting
+`unknown_0x28` while the glass-panel node itself handles that type perfectly correctly,
+for instance. When in doubt, `grep -rln "<ModuleName>'" nodes/ lib/` to find every file
+that mentions a given type by name, rather than assume you've found all the copies.
+
 ---
 
 ## 4. Architecture overview
@@ -266,7 +284,7 @@ or a string before assuming the parsing logic itself is wrong.
 | `velbus-relay-20` | Velbus (outputs) | V2 relays: VMB1RYS-20, VMB4RYLD-20, VMB4RYNO-20 |
 | `velbus-dimmer` | Velbus (outputs) | Original-series dimmers: VMBDMI, VMBDMI-R, VMB4DC |
 | `velbus-dimmer-20` | Velbus (outputs) | V2 dimmers: VMB2DC-20, VMB8DC-20, VMB4LEDPWM-20 (incl. RGB/RGBW grouping mode) |
-| `velbus-glass-panel` | Velbus (inputs) | All 26 glass panel types (original + V2), buttons/OLED/PIR/open-collector as applicable per type |
+| `velbus-glass-panel` | Velbus (inputs) | All 27 glass panel types (original + V2), buttons/OLED/PIR/open-collector as applicable per type |
 | `velbus-thermostat` | Velbus (inputs) | Thermostat function on any glass panel module that has one — same address as the corresponding glass-panel node, coexists without conflict |
 | `velbus-button` | Velbus (inputs) | Dedicated push-button modules: VMB8PB, VMB8PBU, VMB6PBN, VMB2PBN, VMB4PB, VMB6PB-20 |
 | `velbus-pir` | Velbus (inputs) | Original-series PIR: VMBPIRO-10, VMBPIRM, VMBPIRC, VMBPIRO |
@@ -323,13 +341,14 @@ blue (`#4A90D9`).
 | 0x44 | VMB4PB | velbus-button |
 | 0x4C | VMB6PB-20 | velbus-button |
 
-### Glass panels (all → velbus-glass-panel, 26 types)
+### Glass panels (all → velbus-glass-panel, 27 types)
 | Type byte | Module | OLED | PIR | Open collector | Min. map version |
 |---|---|---|---|---|---|
 | 0x1E | VMBGP1 | no | no | unconfirmed¹ | — |
 | 0x1F | VMBGP2 | no | no | unconfirmed¹ | — |
 | 0x20 | VMBGP4 | no | no | unconfirmed¹ | — |
 | 0x21 | VMBGPO | yes | no | yes | 2 |
+| 0x28 | VMBGPOD | yes | no | no | — |
 | 0x2D | VMBGP4PIR | no | yes | unconfirmed¹ | — |
 | 0x34 | VMBEL1 | no | no | yes | 2 |
 | 0x35 | VMBEL2 | no | no | yes | 2 |
@@ -602,7 +621,7 @@ about why in the commit message.
 
 - **Generational split.** Nodes generally split at the V2.0 boundary — one node for
   original-series, a separate node for V2. **Exceptions:** `velbus-glass-panel` (one
-  node covers all 26 types, both generations, via the type registry's per-type flags
+  node covers all 27 types, both generations, via the type registry's per-type flags
   rather than a code-level split), `velbus-thermostat` (covers the thermostat function
   on any glass panel type), `velbus-meteo` (only one generation exists), and the blind
   family (`velbus-blind` / `velbus-blind-s` / `velbus-blind-20`, split by actual protocol
@@ -770,6 +789,14 @@ orientation at the time of writing:
 
 ## 13. Known open issues
 
+- **`VMBKP` (0x42, "Keypad interface module") has no node at all.** Found scanning a
+  real installation (Stuart's home) alongside the `VMBGPOD` gap below — a genuinely new
+  module type, not yet scoped. Its protocol PDF (`protocol_vmbkp.pdf`, 28 pages) is
+  substantial: channel status, module status, and a full per-channel LED control layer
+  (clear/set/slow-blink/fast-blink/very-fast-blink), similar in spirit to `velbus-button`
+  but with LED feedback control `velbus-button` doesn't have. This needs the same
+  "how much work would this involve" scoping pass `velbus-energy` got before it was
+  built, not a quick bolt-on to an existing node.
 - **Open-collector support** on several glass panel types (marked "unconfirmed" in the
   registry in section 6) has not been verified against real hardware — the protocol PDFs
   are ambiguous or silent on some of these. Sending `0x01`/`0x02`/`0x03` open-collector
@@ -885,6 +912,10 @@ git push --tags
   exceptions — see section 4.3 if this isn't already second nature.
 - **Numbers are always numbers in payloads, never strings.**
 - **`results.modules`, not `results`,** when reading the scan endpoint.
+- **A module type lives in three separate files, not one** (per-node `lib/` registry,
+  that node's own `.html` dropdown copy, and `velbus-scan.js`'s independent copy) —
+  see section 3 for the full explanation. Missing one produces a symptom in a
+  different part of the palette than wherever the type was actually added.
 - **Thermostat commands go to the primary address only,** never a subaddress.
 - **Respect the 20ms minimum between `0xFC` writes** on original-series modules — this
   is real EEPROM wear, not an arbitrary rate limit.

package/lib/glass-panel-types.js

@@ -61,6 +61,30 @@ const GLASS_PANEL_TYPES = {
     minMapVer: 2,
     series: 'original',
   },
+  0x28: {
+    name: 'VMBGPOD',
+    // Added 09/07/2026 — found as "unknown_0x28" scanning a real installation.
+    // One of the most common glass panel types in the field (978 occurrences
+    // across the VLP training dataset analysed earlier in this project,
+    // second only to VMB4RYLD and VMBDMI-R) — a genuine gap, not an edge case.
+    // Source: protocol_vmbgpod.pdf (ed.6, 04/12/2024), "Touch panel with Oled
+    // display". Distinct from VMBGPO (0x21) despite similar naming/features —
+    // VMBGPOD's protocol PDF has no open-collector command at all (checked:
+    // no "collector" or "channel 18"-style pattern anywhere in the document),
+    // whereas VMBGPO's family confirms OC support. These are NOT the same
+    // hardware feature set despite the name similarity.
+    // channels: 4, matched against VMBGPOD-2 (0x3D) — the correct sibling,
+    // being the V2 version of this SAME product line. (First attempt at this
+    // entry wrongly copied VMBGPO's 32 — a different product that just
+    // happens to have a similar name. Caught by cross-checking the editor's
+    // own duplicate type list before finalising, not from the PDF directly.)
+    channels: 4,
+    hasOled: true,
+    hasPir: false,
+    hasOc: false,       // confirmed: no OC commands anywhere in this PDF
+    minMapVer: null,    // not found stated in this PDF
+    series: 'original',
+  },
   0x2D: {
     name: 'VMBGP4PIR',
     channels: 8,

package/nodes/velbus-glass-panel/velbus-glass-panel.html

@@ -6,6 +6,7 @@
     0x1E: { name: 'VMBGP1',       channels:  1, oled: false, pir: false, series: 'original' },
     0x1F: { name: 'VMBGP2',       channels:  2, oled: false, pir: false, series: 'original' },
     0x21: { name: 'VMBGPO',       channels: 32, oled: true,  pir: false, series: 'original' },
+    0x28: { name: 'VMBGPOD',      channels:  4, oled: true,  pir: false, series: 'original' },
     0x2D: { name: 'VMBGP4PIR',    channels:  8, oled: false, pir: true,  series: 'original' },
     0x34: { name: 'VMBEL1',       channels:  1, oled: false, pir: false, series: 'original' },
     0x35: { name: 'VMBEL2',       channels:  2, oled: false, pir: false, series: 'original' },

package/nodes/velbus-scan/velbus-scan.js

@@ -21,6 +21,7 @@ const ALL_TYPES = {
   // Glass panels - original
   0x1E: 'VMBGP1',      0x1F: 'VMBGP2',      0x20: 'VMBGP4',
   0x21: 'VMBGPO',      0x2D: 'VMBGP4PIR',
+  0x28: 'VMBGPOD',
   0x34: 'VMBEL1',      0x35: 'VMBEL2',        0x36: 'VMBEL4',
   0x37: 'VMBELO',      0x38: 'VMBELPIR',      0x39: 'VMBSIG',
   0x47: 'VMBEL2PIR',
@@ -78,6 +79,7 @@ const NODE_SUGGESTION = {
   // Glass panels - all via single node
   0x1E: 'velbus-glass-panel', 0x1F: 'velbus-glass-panel', 0x20: 'velbus-glass-panel',
   0x21: 'velbus-glass-panel', 0x2D: 'velbus-glass-panel',
+  0x28: 'velbus-glass-panel',
   0x34: 'velbus-glass-panel', 0x35: 'velbus-glass-panel', 0x36: 'velbus-glass-panel',
   0x37: 'velbus-glass-panel', 0x38: 'velbus-glass-panel', 0x47: 'velbus-glass-panel',
   0x3A: 'velbus-glass-panel', 0x3B: 'velbus-glass-panel', 0x3C: 'velbus-glass-panel',
@@ -114,6 +116,7 @@ const MODULE_CHANNELS = {
   // Glass panels - original
   0x1E: 1,  0x1F: 2,  0x20: 4,
   0x21: 32, 0x2D: 8,
+  0x28: 4,
   0x34: 1,  0x35: 2,  0x36: 4,
   0x37: 4,  0x38: 8,  0x47: 6,
   0x3A: 1,  0x3B: 2,  0x3C: 4,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "node-red-contrib-velbus-2026",
-  "version": "0.9.1",
+  "version": "0.9.3",
   "description": "Node-RED palette for Velbus building automation \u2014 relay, dimmer, glass panel, PIR, blind, sensor, meteo, clock nodes. Original and V2 (-20) series.",
   "keywords": [
     "node-red",