node-red-contrib-velbus-2026 0.10.2 → 0.10.4

package/CHANGELOG_FORUM.md

@@ -29,6 +29,84 @@ separate duplicate-table bugs took to fully resolve.
 
 ---
 
+## v0.10.4 — 09/07/2026
+
+### README.md — fixed real staleness, now publicly visible on the Flow Library
+
+- **Prompted by successfully getting listed on the Node-RED Flow Library**
+  (`flows.nodered.org/node/node-red-contrib-velbus-2026`) — checked the
+  rendered page and found the displayed README was genuinely stale, not a
+  caching artifact: `velbus-glass-panel` still said "26 types" (actually 29),
+  `velbus-button` still listed only the original 6 types (actually 12, plus
+  lock/unlock/status/naming capability added since), `velbus-sensor` didn't
+  mention `VMB6IN` or the new generic analogue reading, `velbus-clock`
+  didn't mention sunrise/sunset, and the tarball install example still
+  hardcoded `v0.8.1`.
+- **Root cause:** `README.md` was fixed once, early on, during initial npm
+  publish prep — then never touched again despite `HANDOVER.md` and
+  `CHANGELOG_FORUM.md` being kept scrupulously current through every
+  subsequent change. This is the user-facing document (visible on both npm
+  and the Flow Library), arguably more consequential to get right than the
+  developer-facing ones, and it drifted the most.
+- **Fixed the specific staleness, and the root cause of it recurring:**
+  the hardcoded tarball version number is now written as `vX.Y.Z` with an
+  explanatory note, rather than a literal version that will go stale again
+  next release exactly as it did this time.
+- Added pointers to `HANDOVER.md`, `CHANGELOG_FORUM.md`, and
+  `coverage-roadmap.md` — none of which were linked from `README.md` at all
+  before, despite being genuinely useful to anyone landing on the repo.
+- Also confirmed, while investigating: the earlier concern about Node-RED's
+  post-2022 scoped-package naming policy did **not** block Flow Library
+  approval — this package is listed successfully under its original
+  unscoped name.
+
+---
+
+## v0.10.3 — 09/07/2026
+
+### velbus-glass-panel — VMBEL edge colour control (set_edge_color)
+
+- **Prompted by Stuart asking whether edge LED colours on `VMBEL` panels
+  could be controlled, or whether a raw-packet escape-hatch node (like the
+  original palette had) was needed instead.** Confirmed a real, well-defined
+  live-bus command exists — no raw-packet node needed for this case.
+- **Scope deliberately split, per explicit decision:** `COMMAND_SET_PB_
+  BACKLIGHT` (`0xD4`) covers two different operations distinguished only by
+  DLC — "Set Custom Color" (`DLC=6`, *defines* a custom RGB palette slot)
+  and "Set Edge Color" (`DLC=4`, *applies* an already-defined colour).
+  Only the latter is implemented: defining new custom colours is
+  commissioning-time configuration, staying in VelbusLink's domain, same
+  reasoning as `VMB4LEDPWM-20`'s grouping mode and Program Step read/write
+  elsewhere in this project. See `HANDOVER.md` section 7.8b for the full
+  byte layout.
+- **`hasEdgeLed` gated to the confirmed `VMBEL` family only** (12 of 29
+  glass panel types: `VMBEL1/2/4`, `VMBELO`, `VMBELPIR`, `VMBEL2PIR`, and
+  their `-20` siblings) — `VMBGP`-family panels have only a single-colour
+  front LED per button, genuinely different hardware, not just a missing
+  feature. Verified the command is byte-for-byte identical across every
+  `VMBEL` sub-family protocol PDF before implementing once. One vestigial
+  "Edge color inhibited" status bit found in `VMBGP1-20/2-20/4-20`'s own
+  `0xED` — confirmed as inherited documentation cruft, not evidence of real
+  edge-colour hardware on those panels.
+- New `set_edge_color` command: `layers` (background/continuous/slow_blink/
+  fast_blink, any combination), `edges` (left/top/right/bottom, any
+  combination), `page` (1-8 or "all"), `palette` (default/custom), `index`
+  (0-31), `priority` (custom only), `blink`. Sending to a non-`VMBEL` panel
+  warns clearly and sends nothing, matching the established per-type
+  gating pattern used throughout this palette.
+- Housekeeping: removed a stale "`VMBKP` has no node at all" entry from
+  `HANDOVER.md`'s known-open-issues — that was resolved back in v0.10.0
+  when `VMBKP` was folded into `velbus-button`, but the issue list was
+  never updated to reflect it.
+
+Verified via the mock-RED harness: default palette, custom palette with
+priority and blink flag, all-defaults shorthand, and rejection on a
+non-`VMBEL` type — every case with hand-checked checksums and manually
+verified bitfield encoding, not just visual review. Not yet sent to a real
+bus.
+
+---
+
 ## v0.10.2 — 09/07/2026
 
 ### velbus-sensor — VMB4AN generic analogue reading (channels 9-12)

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.10.2, 19 nodes, published on npm.**
+Current state at time of writing: **v0.10.4, 19 nodes, published on npm.**
 
 ---
 
@@ -300,7 +300,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 29 glass panel types (original + V2), buttons/OLED/PIR/open-collector as applicable per type |
+| `velbus-glass-panel` | Velbus (inputs) | All 29 glass panel types (original + V2), buttons/OLED/PIR/open-collector as applicable per type. `VMBEL` family only (12 of the 29 types): `set_edge_color` applies an already-defined colour across layer/edge/page combinations — deliberately not palette *definition*, which stays in VelbusLink |
 | `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) | 12 types across original and V2 series (VMB8PB, VMB8PBU, VMB6PBN, VMB2PBN, VMB4PB, VMB6PB-20, VMB8IR, VMB4PD, VMB4RF, VMBRFR8S, VMBVP01, VMBKP, VMBIN) — plain button events for all; lock/unlock and richer status decode for the 8 types confirmed to support them; fixed semantic channel labels for VMBVP01 (DoorBird) |
 | `velbus-pir` | Velbus (inputs) | Original-series PIR: VMBPIRO-10, VMBPIRM, VMBPIRC, VMBPIRO |
@@ -606,6 +606,45 @@ body[3-5] = 24-bit raw value, MSB first
   (period mode: 0x000000 = short-circuited, 0xFFFFFF = open-circuit)
 ```
 
+### 7.8b `0xD4` — one command byte, two very different operations, `VMBEL` family only
+
+`COMMAND_SET_PB_BACKLIGHT` (`0xD4`) covers **two genuinely different commands**,
+distinguished only by `DLC` (data length), confirmed identical across every
+`VMBEL` sub-family protocol PDF checked (`VMBEL1/2/4`, `VMBELO`, `VMBELPIR`,
+and their `-20` siblings):
+
+- **"Set Custom Color" (`DLC=6`)** — *defines* one of 32 custom colour
+  palette slots as an actual RGB (or white+saturation) value:
+  `[0xD4, paletteIndex(0-31), rgbOrWhiteFlag+saturation, red, green, blue]`.
+  **Deliberately not implemented** — defining new custom colours is
+  commissioning-time configuration, and per an explicit decision, stays in
+  VelbusLink's domain. Same reasoning as `VMB4LEDPWM-20`'s grouping mode and
+  Program Step read/write elsewhere in this project.
+- **"Set Edge Color" (`DLC=4`)** — *applies* an already-defined colour
+  (default palette, or a custom slot VelbusLink has already programmed)
+  across a chosen combination of layer/edge/page. This one **is**
+  implemented (`velbus-glass-panel`'s `set_edge_color` command) — a
+  genuine live/runtime action, not palette editing:
+  ```
+  body[0] = 0xD4
+  body[1] = layer bitmask (bit0=background, bit1=continuous-feedback,
+            bit2=slow-blink-feedback, bit3=fast-blink-feedback) + bit7
+            (0=default palette, 1=custom palette)
+  body[2] = edge bitmask (bit0=left, bit1=top, bit2=right, bit3=bottom) +
+            page nibble (bits4-7: 0-7=pages 1-8, 8-15=all pages — the
+            protocol PDF states the entire 1000-1111 range means "all",
+            not just one value)
+  body[3] = blink flag (bit7) + priority (bits5-6, custom palette only:
+            01=low, 10=mid, 11=high) + palette index (bits0-4, 0-31)
+  ```
+  **Gated to `hasEdgeLed` types only** — the `VMBEL` family, confirmed
+  `VMBGP`-family panels genuinely lack this (they have a single-colour
+  front LED per button, not side-firing edge lighting — a real hardware
+  difference, not just a missing feature). One vestigial "Edge color
+  inhibited" status *bit* appears in `VMBGP1-20/2-20/4-20`'s `0xED` module
+  status — almost certainly inherited from shared documentation with the
+  `VMBEL` family, not evidence those panels have real edge-colour hardware.
+
 ### 7.9 Thermostat commands — always to the primary address
 ```
 0xDB = comfort mode, 0xDC = day mode, 0xDD = night mode, 0xDE = safe mode
@@ -889,15 +928,6 @@ 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) — confirmed present at address `0xFD`, a real
-  module on a real bus, not a hypothetical. 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

package/README.md

@@ -52,8 +52,11 @@ npm install node-red-contrib-velbus-2026
 Via local tarball:
 ```bash
 cd ~/.node-red
-npm install /path/to/node-red-contrib-velbus-2026_v0.8.1.tar.gz
+npm install /path/to/node-red-contrib-velbus-2026_vX.Y.Z.tar.gz
 ```
+(replace `X.Y.Z` with whichever version tarball you have — deliberately not
+hardcoded here, since a literal version number in this file has gone stale
+every single time it's been written one before)
 
 ---
 
@@ -68,13 +71,13 @@ npm install /path/to/node-red-contrib-velbus-2026_v0.8.1.tar.gz
 ### Inputs (teal)
 | Node | Modules |
 |---|---|
-| `velbus-glass-panel` | All VMBEL and VMBGP variants — 26 types including OLED, PIR, and original series. Thermostat, LED control, open collector. |
+| `velbus-glass-panel` | All VMBEL and VMBGP variants — 29 types including OLED, PIR, and original series. Thermostat, LED control, open collector. `VMBEL` family only: edge colour control (`set_edge_color`) — applies an already-defined colour across layer/edge/page combinations; defining new custom colours stays in VelbusLink. |
 | `velbus-thermostat` | Dedicated thermostat node for all glass panel modules. |
-| `velbus-button` | VMB8PB, VMB8PBU, VMB6PBN, VMB2PBN, VMB4PB, VMB6PB-20 |
+| `velbus-button` | 12 types across original and V2 series: VMB8PB, VMB8PBU, VMB6PBN, VMB2PBN, VMB4PB, VMB6PB-20, VMB8IR, VMB4PD, VMB4RF, VMBRFR8S, VMBVP01, VMBKP, VMBIN. Lock/unlock and richer status decode where the specific type supports it (not universal); named channels in event output; fixed semantic labels for VMBVP01 (DoorBird). |
 | `velbus-pir` | VMBPIRM, VMBPIRC, VMBPIRO, VMBPIRO-10 |
 | `velbus-pir-20` | VMBPIR-20, VMBPIRO-20 |
 | `velbus-meteo` | VMBMETEO — wind, rain, light, temperature, alarm outputs |
-| `velbus-sensor` | VMB7IN (8 digital inputs + 4 pulse counters), VMB4AN (16-channel analogue/alarm) |
+| `velbus-sensor` | VMB7IN (8 digital inputs + 4 pulse counters), VMB4AN (channels 1-8 alarm outputs + generic analogue reading on channels 9-12 — mode-aware but deliberately no engineering-unit conversion), VMB6IN (6 digital inputs) |
 | `velbus-sensor-20` | VMB8IN-20 (8 digital + 24 alarm channels via subaddresses, energy counters) |
 
 ### Outputs (blue)
@@ -87,7 +90,7 @@ npm install /path/to/node-red-contrib-velbus-2026_v0.8.1.tar.gz
 | `velbus-blind` | VMB1BL, VMB2BL — original series, stop/up/down only |
 | `velbus-blind-s` | VMB1BLS, VMB2BLE, VMB2BLE-10 — full position, lock, force, inhibit |
 | `velbus-blind-20` | VMB2BLE-20 — V2 series with CAN FD support |
-| `velbus-clock` | No fixed module — broadcasts time/date/DST to bus address `0x00`, plus global/local clock alarm (V2 series only) |
+| `velbus-clock` | No fixed module — broadcasts time/date/DST to bus address `0x00`, plus global/local clock alarm and sunrise/sunset enable (V2 series only) |
 | `velbus-energy` | VMBPSUMNGR-20 — power supply manager: PSU load, live wattage/voltage/amperage, warranty counter, PSU alarms (V2 series only) |
 
 ---
@@ -122,6 +125,21 @@ at `/velbus`.
 
 Tested on a live 18-module installation including VMBEL4, VMBELO, VMBELPIR,
 VMBPIR-20, VMB1RYS, and VMB8DC-20. CAN FD modules confirmed working.
+`VMBGPOD` specifically confirmed against two real panels on a separate
+installation, after an earlier gap where it showed as `unknown` in a scan.
+
+---
+
+## Further documentation
+
+- [`HANDOVER.md`](https://github.com/MDAR/node-red-contrib-velbus-2026/blob/main/HANDOVER.md) —
+  comprehensive technical reference for developing this palette: architecture, protocol
+  quirks found the hard way, per-node testing status, and known open issues. Written to
+  assume no prior context.
+- [`CHANGELOG_FORUM.md`](https://github.com/MDAR/node-red-contrib-velbus-2026/blob/main/CHANGELOG_FORUM.md) —
+  full version-by-version development history, including *why* things changed, not just what.
+- [`coverage-roadmap.md`](https://github.com/MDAR/node-red-contrib-velbus-2026/blob/main/coverage-roadmap.md) —
+  every Velbus module type and feature considered for this palette, what's in scope, and why.
 
 ---
 

package/coverage-roadmap.md

@@ -0,0 +1,186 @@
+# Coverage Roadmap — Rationalized 09/July/2026
+
+**STATUS: Implemented in v0.10.0 (09/July/2026).** Everything marked "confirmed
+and ready to build" below has been built, tested, and shipped — including
+the type-byte fixes and real protocol divergences caught along the way (see
+`CHANGELOG_FORUM.md` v0.10.0 for the full list). The two genuinely deferred
+items (dimmer family, bus error counter) and the OLED stretch goal are now
+tracked directly in `HANDOVER.md` section 13 going forward — this document
+remains as the record of the original rationalization discussion, not the
+place to look for current status.
+
+Synthesized from a full pass over every Velbus module type and feature not yet
+covered by this palette. Organized by what actually needs to happen, not by the
+order it came up in discussion.
+
+---
+
+## 1. New types to add to existing nodes' registries
+
+No new nodes required — each of these is a straightforward registry addition
+to a node that already exists and already handles this exact command family.
+
+| Type | Module | Target node | Note |
+|---|---|---|---|
+| 0x07 | VMB1DM | `velbus-dimmer` | Old, likely rare in the field, minimal effort |
+| 0x14 | VMBDME | `velbus-dimmer` | |
+| 0x0F | VMB1LED | `velbus-dimmer` | Confirmed via protocol PDF: "PWM LED strip dimmer module" — genuinely dimmer-family, not a separate concept |
+| 0x0A | VMB8IR | `velbus-button` | Confirmed — just a button-event module |
+| 0x0B | VMB4PD | `velbus-button` | Reclassified from "not supported" — confirmed as a 4-button interface |
+| 0x1A | VMB4RF | `velbus-button` | Presents 8 button events to the bus, nothing more |
+| 0x30 | VMBRFR8S | `velbus-button` | Same mechanism as VMB4RF |
+| 0x33 | VMBVP01 | `velbus-button` | DoorBird video intercom OEM module — 8 button events |
+| 0x42 | VMBKP | `velbus-button` | Already agreed — plus lock/unlock and richer status decode (section 3) |
+| 0x43 | VMBIN | `velbus-button` | Single-channel input, EOL but real installed base |
+| 0x05 | VMB6IN | `velbus-sensor` | Sibling of VMB7IN |
+| 0x3E | VMBGP4PIR-2 | `velbus-glass-panel` | Original-series-2 sibling of the -20 already covered |
+| 0x25 | VMBGPTC | `velbus-glass-panel` | Confirmed — shares its actual protocol PDF with VMBGPO (0x21), genuine glass-panel sibling |
+
+**Resolved — `VMB1TC`/`VMB1TS`: out of scope, not "super easy."** Checked the
+actual protocol: `VMB1TC` has its own distinct command vocabulary ("Sensor
+zone number," "sensor time statistics request," "lock/unlock sensor local
+control") that doesn't overlay onto the existing `velbus-thermostat` decode —
+this would be real new command handling, not a registry entry. Per the
+stated condition, this stays out of scope. Nothing in Velbus is genuinely
+wireless (confirmed) other than 433MHz/IR modules, which translate to the
+bus rather than living on it — so no "W"-variant type IDs to separately track.
+
+**Resolved — `VMBLCDWB` (0x13):** confirmed as a pre-glass-panel thermostat
+controller (Velleman product page: 4-button control with LCD display, 32
+functions, time/date backup). Out of scope, name-only in section 2.
+
+---
+
+## 2. Scan-table "see it, don't support it" additions
+
+Named correctly in a scan (not `unknown_0xNN`), explicit "Not supported" note
+in place of a suggested node — no live node built.
+
+| Type | Module | Note |
+|---|---|---|
+| 0x45 / 0x5A | VMBDALI / VMBDALI-20 | Real prevalence (12 VLP projects) but DALI is its own protocol layer beyond the gateway — explicit "Not supported" label requested |
+| 0x13 | VMBLCDWB | Pre-glass-panel thermostat controller (4-button + LCD + time/date backup) — confirmed out of scope, name only |
+| 0x3F | VMCM3 | Custom corporate-client module, function unknown — name only |
+| 0x39 / 0x5B / 0x60 | VMBSIG / VMBSIG-20 / VMBSIG-21 | Custom HomeAssistant-based master clock, not interactable — already named in the scanner; **worth aligning to the same explicit "Not supported" note style as VMBDALI for consistency**, rather than leaving these as a bare name with no note at all |
+| 0x40 | VMBUSBIP | Already correctly handled as-is — no use in this context beyond potentially being what the bridge itself connects to |
+
+---
+
+## 3. Feature additions to existing nodes
+
+- **`velbus-clock`: add sunrise/sunset enable/disable (`0xAE`)** — part of the
+  same shared system block as time/date/DST/alarm, genuinely missing.
+- **`velbus-button`: lock/unlock (`0x12`/`0x13`) + richer `0xED` status decode**
+  (locked/enabled/inverted/program-selection) — already agreed, applies as a
+  general button-family capability, not scoped to VMBKP alone.
+- **`velbus-button`: surface channel names in the event output** — using the
+  existing `0xF0`/`0xF1`/`0xF2` pattern, so named-channel modules (VMBKP, and
+  potentially others) show real names, not just channel numbers, while every
+  existing numbered-only setup keeps working unchanged.
+
+- **Bus error counter (`0xDA`) — resolved design, scoped as a follow-up, not
+  built today.** Confirmed genuinely useful, but explicitly framed as an edge
+  case: "the once in a blue moon bus error message will clear itself within
+  a second or two — including it in normal payload traffic will cause
+  confusion." Resolved design: every node that registers for its own address
+  already receives every packet addressed to it, including an unsolicited
+  `0xDA` broadcast if one occurs — so no new "request" command is needed, just
+  passive decoding. Add `0xDA` handling to every existing node, emitting
+  **only on the secondary output** (never mixed into the main status payload
+  on output 1), and **only when at least one counter is non-zero** — silent
+  during normal operation, so it never appears unless there's genuinely
+  something to see. Nodes that currently only have a single output would need
+  a second one added. **Scoped as its own follow-up given it touches most or
+  all existing nodes — not part of today's build.**
+
+---
+
+## 4. Deferred — logged as a stretch goal, not being built now
+
+- **OLED image writing** (pushing a custom B&W 1-bit bitmap to an OLED glass
+  panel) — genuine use case raised (swapping in a different-language greeting
+  for a visitor without opening VelbusLink). **Confirmed: no solid reason to
+  build it now** — parked in `HANDOVER.md` as an explicit stretch goal rather
+  than an open question.
+
+**Resolved — calibration data:** no concrete current need. Stays out of
+scope alongside generic memory read/write, parked for if/when a real need
+comes up rather than built speculatively.
+
+---
+
+## 5. Confirmed out of scope — no action
+
+- **Generic memory read/write** — the foundation Program Step would sit on;
+  out of scope as a consequence of Program Step being out of scope.
+- **Program Step read/write** — explicitly parked pending VelbusLink's own
+  Delphi rewrite; a strong candidate to become its own separate project
+  rather than living in this palette at all.
+- **Cross-module "linked" LED control** — out of scope.
+- **IR learn-and-replay, reframed correctly:** this was mischaracterized in
+  the original list — it isn't third-party IR code learning at all. The
+  glass-panel IR variants simply respond to Velbus-defined HEX codes and
+  present them as button events (up to 32), with codes 33-39 specifically
+  translated into heating temperature mode changes that `velbus-thermostat`
+  would see. Genuinely out of scope as a project, but worth remembering this
+  detail if the IR-capable glass panel variants (`VMBGPOD_IR` etc.) ever get
+  addressed — the 33-39 range needs the same special handling as any other
+  thermostat mode change, not treatment as plain numbered buttons.
+- **DALI bridging** — out of scope, name-only per section 2.
+- **Signum integration** — out of scope, name-only per section 2.
+
+---
+
+## 6. VMB4AN — groups 2/3 parked, large commitment
+
+**Status: parked 09/07/2026, not scoped for near-term work.** `velbus-sensor`
+currently only implements Group 1 of VMB4AN's three functional groups (alarm
+outputs, channels 1-8, via the standard `0x00` button-style event — the same
+path VMB7IN uses). The `isVMB4AN` flag already in the code is a placeholder
+that's never actually consumed anywhere.
+
+- **Group 2 — sensor inputs (channels 9-12).** Each channel supports 4
+  configurable operating modes (voltage 0-10V / current 4-20mA / resistance
+  PT100-1000 / period measurement), 4 presets (safe/night/day/comfort — same
+  naming as thermostat presets), a sleep timer, and configurable auto-send
+  behaviour (fixed interval, or threshold-based at 3.125%/6.25%/12.5%/25%
+  change). Reading a value and reading full settings are two separate
+  packets (`0xEA` status, `0xE8`+`0xE9` two-part settings, confirmed from
+  `protocol_vmb4an.pdf`).
+- **Group 3 — analog outputs (channels 13-16).** Effectively a full dimmer
+  control surface bolted onto VMB4AN — same command bytes as `velbus-dimmer`
+  itself (`0x07` set value, `0x11` restore last value), percentage or 12-bit
+  precision, timer/forced-on/inhibit, even reusing `0xB8` for its status
+  (same byte as `VMBDMI`'s dimmer status — no real conflict, different
+  module addresses, just worth knowing Velbus reuses this byte across
+  contexts). **Deprioritized further:** not yet configurable natively in
+  VelbusLink, so unlikely to appear in any real installation regardless of
+  whether this palette supports it — low priority until that changes.
+- **Comparable in size to `velbus-energy`** — a genuine second build, not a
+  quick addition. Revisit if/when there's a concrete need.
+
+---
+
+## 7. Final scope — everything below is confirmed and ready to build
+
+**New registry entries** (sections 1 and 2 above) — 13 types added to
+existing nodes' registries, 5 types added as scan-visible "not supported"
+entries, no new nodes required for any of it.
+
+**Feature additions to existing nodes:**
+- `velbus-clock`: sunrise/sunset enable/disable (`0xAE`)
+- `velbus-button`: lock/unlock (`0x12`/`0x13`), richer `0xED` status decode,
+  channel names surfaced in event output
+
+**Explicitly deferred to a later session, design already settled:**
+- Bus error counter (`0xDA`) — touches most/all existing nodes, scoped above
+
+**Confirmed out of scope, no action ever:**
+- Generic memory read/write, calibration data (no concrete need), Program
+  Step read/write, cross-module linked LED control, IR learn-and-replay (as
+  a feature — though see the 33-39 thermostat-mode detail above if the
+  IR-capable glass panel variants ever get addressed), DALI bridging, Signum
+  integration, `VMB1TC`/`VMB1TS` (genuinely not "easy"), `VMBLCDWB`.
+
+**Logged as a stretch goal in `HANDOVER.md`, not built now:**
+- OLED image writing

package/lib/glass-panel-types.js

@@ -140,6 +140,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: false,
     hasPir: false,
     hasOc: true,        // Confirmed: VMBEL1/2/4 protocol PDF ed2 Nov 2024
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     minMapVer: 2,
     series: 'original',
   },
@@ -149,6 +150,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: false,
     hasPir: false,
     hasOc: true,        // Confirmed: VMBEL1/2/4 protocol PDF ed2 Nov 2024
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     minMapVer: 2,
     series: 'original',
   },
@@ -158,6 +160,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: false,
     hasPir: false,
     hasOc: true,        // Confirmed: VMBEL1/2/4 protocol PDF ed2 Nov 2024
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     minMapVer: 2,
     series: 'original',
   },
@@ -167,6 +170,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: true,
     hasPir: false,
     hasOc: true,        // OLED/output variant — OC confirmed by protocol family
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     minMapVer: 4,
     series: 'original',
   },
@@ -176,6 +180,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: false,
     hasPir: true,
     hasOc: true,        // PIR variant of VMBEL family — OC present
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     pirChannels: {
       1: 'button1', 2: 'button2', 3: 'button3', 4: 'button4',
       5: 'virtual',  6: 'dark',    7: 'light',   8: 'motion',
@@ -225,6 +230,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: false,
     hasPir: true,
     hasOc: true,        // PIR variant of VMBEL family — OC present
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     pirChannels: {
       1: 'button1', 2: 'button2',
       3: 'virtual',  4: 'dark',    5: 'light',   6: 'motion',
@@ -241,6 +247,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: false,
     hasPir: false,
     hasOc: true,        // Confirmed: VMBEL1/2/4 protocol PDF ed2 Nov 2024 covers -20 variants
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     minMapVer: null,
     series: 'v2',
   },
@@ -250,6 +257,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: false,
     hasPir: false,
     hasOc: true,        // Confirmed: VMBEL1/2/4 protocol PDF ed2 Nov 2024 covers -20 variants
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     minMapVer: null,
     series: 'v2',
   },
@@ -259,6 +267,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: false,
     hasPir: false,
     hasOc: true,        // Confirmed: VMBEL1/2/4 protocol PDF ed2 Nov 2024 covers -20 variants
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     minMapVer: null,
     series: 'v2',
   },
@@ -268,6 +277,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: true,
     hasPir: false,
     hasOc: true,        // OLED/output variant — OC confirmed by protocol family
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     minMapVer: null,
     series: 'v2',
   },
@@ -277,6 +287,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: false,
     hasPir: true,
     hasOc: true,        // PIR variant of VMBEL family — OC present
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     pirChannels: {
       1: 'button1', 2: 'button2', 3: 'button3', 4: 'button4',
       5: 'virtual',  6: 'dark',    7: 'light',   8: 'motion',
@@ -326,6 +337,7 @@ const GLASS_PANEL_TYPES = {
     hasOled: false,
     hasPir: true,
     hasOc: true,        // PIR variant of VMBEL family — OC present
+    hasEdgeLed: true,  // VMBEL family confirmed - own protocol PDF has 'Set Edge Color' (0xD4)
     pirChannels: {
       1: 'button1', 2: 'button2',
       3: 'virtual',  4: 'dark',    5: 'light',   6: 'motion',

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

@@ -316,6 +316,56 @@
     <dt><code>{ "cmd": "led_set", "channel": 1 }</code></dt>
     <dd>Control button LED. Commands: <code>led_set</code>, <code>led_clear</code>, <code>led_slow</code>, <code>led_fast</code>, <code>led_vfast</code>.</dd>
 
+    <dt><code>set_edge_color</code> — <strong>VMBEL family only</strong> (VMBEL1/2/4, VMBELO,
+    VMBELPIR, and their -20 siblings — not VMBGP-family panels, which have only a
+    single-colour front LED per button, not side-firing edge lighting)</dt>
+    <dd>
+      Applies an <em>already-defined</em> colour — the module's default palette, or a
+      custom slot VelbusLink has already programmed — across a chosen combination of
+      layer(s), edge(s), and button page. <strong>Does not define new custom colours</strong> —
+      that stays in VelbusLink; this node only ever applies/switches between colours that
+      already exist on the module.
+      <pre>
+{ "cmd": "set_edge_color", "index": 5 }
+// Simplest form — every field below is optional and defaults as shown.
+// Applies default palette colour #5 to the background layer, all four
+// edges, all button pages.
+
+{ "cmd": "set_edge_color",
+  "layers": ["background", "continuous"],
+  "edges": ["left", "top", "right", "bottom"],
+  "page": 1,
+  "palette": "default",
+  "index": 5 }
+// Same as above but explicit — background AND continuous-feedback layers,
+// all edges, button page 1 only.
+
+{ "cmd": "set_edge_color",
+  "layers": ["fast_blink"],
+  "edges": ["left"],
+  "page": "all",
+  "palette": "custom",
+  "index": 12,
+  "priority": "high",
+  "blink": true }
+// Custom palette slot #12 (must already be programmed via VelbusLink),
+// applied only to the fast-blink-feedback layer, left edge only, every
+// button page, at highest override priority, with the blink flag set.
+      </pre>
+      <table style="width:100%; font-size:0.85em; border-collapse:collapse; margin-top:4px;">
+        <tr style="text-align:left; border-bottom:1px solid #ccc;"><th>Field</th><th>Values</th><th>Default if omitted</th></tr>
+        <tr><td><code>layers</code></td><td>array, any of: <code>background</code>, <code>continuous</code>, <code>slow_blink</code>, <code>fast_blink</code></td><td><code>["background"]</code></td></tr>
+        <tr><td><code>edges</code></td><td>array, any of: <code>left</code>, <code>top</code>, <code>right</code>, <code>bottom</code></td><td>all four</td></tr>
+        <tr><td><code>page</code></td><td><code>1</code>-<code>8</code>, or <code>"all"</code></td><td><code>"all"</code></td></tr>
+        <tr><td><code>palette</code></td><td><code>"default"</code> or <code>"custom"</code></td><td><code>"default"</code></td></tr>
+        <tr><td><code>index</code></td><td><code>0</code>-<code>31</code> (which palette slot to apply)</td><td><code>0</code></td></tr>
+        <tr><td><code>priority</code></td><td><code>"low"</code>/<code>"mid"</code>/<code>"high"</code> — <em>custom palette only</em>, ignored for default</td><td><code>"low"</code></td></tr>
+        <tr><td><code>blink</code></td><td><code>true</code>/<code>false</code></td><td><code>false</code></td></tr>
+      </table>
+      <p>Sending this to a non-VMBEL panel (e.g. VMBGP2) sends nothing and logs a clear
+      warning rather than silently failing.</p>
+    </dd>
+
     <dt><code>{ "cmd": "output_on" }</code> / <code>"output_off"</code></dt>
     <dd>Open collector output on/off.</dd>
 

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

@@ -38,6 +38,33 @@ const LED_CMD = {
   led_vfast: 0xF9,
 };
 
+// ─────────────────────────────────────────────────────────────────────────────
+// Edge colour constants — VMBEL family only (hasEdgeLed), confirmed identical
+// byte layout across every VMBEL sub-family protocol PDF checked (VMBEL1/2/4,
+// VMBELO, VMBELPIR, and their -20 siblings). Command byte 0xD4
+// (COMMAND_SET_PB_BACKLIGHT) is shared with 'Set Custom Color' (defining new
+// custom RGB palette entries) — deliberately NOT implemented here. Defining
+// custom colours is commissioning-time configuration and stays in
+// VelbusLink's domain, same reasoning as VMB4LEDPWM-20's grouping mode and
+// Program Step read/write elsewhere in this project. Only 'Set Edge Color'
+// (applying an already-defined colour — default palette, or a custom slot
+// VelbusLink has already programmed) is in scope: a genuine live/runtime
+// action, not palette editing.
+// ─────────────────────────────────────────────────────────────────────────────
+const EDGE_LAYER_BITS = {
+  background:  0x01,
+  continuous:  0x02,
+  slow_blink:  0x04,
+  fast_blink:  0x08,
+};
+const EDGE_SIDE_BITS = {
+  left:   0x01,
+  top:    0x02,
+  right:  0x04,
+  bottom: 0x08,
+};
+const EDGE_PRIORITY = { low: 0x01, mid: 0x02, high: 0x03 };
+
 // ─────────────────────────────────────────────────────────────────────────────
 // Channel bitmask helpers
 // ─────────────────────────────────────────────────────────────────────────────
@@ -91,6 +118,7 @@ module.exports = function(RED) {
     const typeDesc = (node.typeId !== null) ? (GLASS_PANEL_TYPES[node.typeId] || null) : null;
     const hasOled  = typeDesc ? typeDesc.hasOled  : false;
     const hasPir   = typeDesc ? typeDesc.hasPir   : false;
+    const hasEdgeLed = typeDesc ? !!typeDesc.hasEdgeLed : false;
     const hasOc    = typeDesc ? !!typeDesc.hasOc  : false;
     const pirCh    = typeDesc ? (typeDesc.pirChannels || {}) : {};
 
@@ -421,6 +449,50 @@ module.exports = function(RED) {
         return;
       }
 
+      // ── Set edge colour (VMBEL family only) ─────────────────────────────
+      // Applies an already-defined colour (default palette, or a custom
+      // slot VelbusLink has already programmed) across a chosen combination
+      // of layer(s), edge(s), and button page. Does NOT define new custom
+      // colours — that stays in VelbusLink, see the constants comment above.
+      if (cmd === 'set_edge_color') {
+        if (!hasEdgeLed) {
+          node.warn('velbus-glass-panel: ' + (typeDesc ? typeDesc.name : 'this module type') +
+            ' has no edge lighting (VMBEL family only) — sending nothing.');
+          return;
+        }
+
+        const layers = Array.isArray(msg.payload.layers) ? msg.payload.layers : ['background'];
+        const edges  = Array.isArray(msg.payload.edges)  ? msg.payload.edges  : ['left', 'top', 'right', 'bottom'];
+        const palette = msg.payload.palette === 'custom' ? 'custom' : 'default';
+        const index  = Math.max(0, Math.min(31, parseInt(msg.payload.index) || 0));
+        const blink  = !!msg.payload.blink;
+
+        let db2 = 0;
+        for (const l of layers) db2 |= (EDGE_LAYER_BITS[l] || 0);
+        if (palette === 'custom') db2 |= 0x80;
+
+        let db3 = 0;
+        for (const e of edges) db3 |= (EDGE_SIDE_BITS[e] || 0);
+        // Page: 1-8 map to nibble 0-7; 'all' (or omitted) uses 0xF, matching
+        // the protocol's own stated range (1000xxxx through 1111xxxx all
+        // mean "all pages" — 0xF is simply the clearest, most explicit value
+        // in that range to use).
+        const page = msg.payload.page;
+        const pageNibble = (page === undefined || page === 'all')
+          ? 0x0F
+          : Math.max(0, Math.min(7, parseInt(page) - 1));
+        db3 |= (pageNibble << 4) & 0xF0;
+
+        let db4 = index & 0x1F;
+        if (blink) db4 |= 0x80;
+        if (palette === 'custom') {
+          db4 |= (EDGE_PRIORITY[msg.payload.priority] || EDGE_PRIORITY.low) << 5;
+        }
+
+        node.bridge.send(pkt(0xFB, node.address, [0xD4, db2, db3, db4]));
+        return;
+      }
+
       // ── Open collector output ──────────────────────────────────────────
       if (cmd === 'output_on') {
         // COMMAND_SWITCH_RELAY_ON (0x02), channel byte = don't care (0xFF)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "node-red-contrib-velbus-2026",
-  "version": "0.10.2",
+  "version": "0.10.4",
   "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",