node-red-contrib-velbus-2026 0.10.1 → 0.10.3

package/CHANGELOG_FORUM.md

@@ -29,6 +29,98 @@ separate duplicate-table bugs took to fully resolve.
 
 ---
 
+## 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)
+
+- **Prompted by Stuart noticing `isVMB4AN` was defined but never used** —
+  confirmed the sensor-input channels (Group 2 of VMB4AN's three functional
+  groups) produced literally no output at all beforehand; the packet
+  carrying that data wasn't handled anywhere in the file.
+- **Real trap found and avoided:** the obviously-named `0xEA`
+  ("sensor status") packet does **not** carry a value at all — it's
+  operating-mode/sleep-timer/auto-send configuration only. The actual
+  reading lives in a separate, easy-to-miss packet earlier in the protocol
+  document: `0xA9` (`COMMAND_SENSOR_RAW_DATA`, "Transmit the sensor raw
+  value"), genuinely standalone with no need to cross-reference anything
+  else. Also confirmed `0xE8`/`0xE9` ("sensor settings") is preset
+  *configuration* storage, not a live value either — three different
+  packets that could each plausibly have been mistaken for "the reading."
+- Deliberately generic, per explicit preference: emits `{ type: "analogue",
+  channel, mode, raw }` with no engineering-unit conversion attempted —
+  `mode` (voltage/current/resistance/period) and the PDF's resolution
+  table are exposed in the node's help so conversion can happen in the flow
+  instead.
+- New `get_analogue` input command (`0xE5`, request-a-reading-now) — uses
+  the protocol's own "auto-send config byte = 0" option to request a value
+  without side-effecting the module's existing auto-send schedule.
+  **Priority byte corrected during verification:** the protocol PDF
+  explicitly states "SID10-SID9 = 11 (lowest priority)" for this specific
+  command — `0xFB`, not the `0xF8` most other commands in this file use.
+  Checked directly rather than assumed, since this is the one place it
+  genuinely differs from the file's established convention.
+- Both confirmed absent from `VMB7IN`'s own protocol PDF before wiring
+  in — this file's switch statement handles both module types together,
+  so a collision would misfire for `VMB7IN` modules if either byte had
+  been reused there.
+- **Full Group 2 configuration (presets, mode-switching, sleep time,
+  offset, auto-send interval config) and all of Group 3 (analog outputs)
+  remain parked** — see `coverage-roadmap.md` section 6. This is
+  deliberately just the minimal reading piece, not the full feature.
+
+Verified via the mock-RED harness: voltage/period modes, both period
+special-value cases (`0x000000` short-circuit, `0xFFFFFF` open-circuit),
+`VMB7IN` isolation confirmed (same bytes produce no output on that type),
+`get_analogue` checksum hand-verified, correctly rejected on non-VMB4AN
+types. Not yet sent to a real bus.
+
+---
+
 ## v0.10.1 — 09/07/2026
 
 ### Two critical bugs found on real hardware — velbus-dimmer and velbus-glass-panel

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.1, 19 nodes, published on npm.**
+Current state at time of writing: **v0.10.3, 19 nodes, published on npm.**
 
 ---
 
@@ -300,13 +300,13 @@ 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 |
 | `velbus-pir-20` | Velbus (inputs) | V2 PIR: VMBPIR-20, VMBPIRO-20 |
 | `velbus-meteo` | Velbus (inputs) | Weather station: VMBMETEO |
-| `velbus-sensor` | Velbus (inputs) | Original-series input/analogue: VMB7IN, VMB4AN, VMB6IN |
+| `velbus-sensor` | Velbus (inputs) | Original-series input/analogue: VMB7IN, VMB4AN (channels 1-8 alarm outputs + generic analogue reading on channels 9-12; full sensor/preset config and analog outputs on channels 13-16 remain parked), VMB6IN |
 | `velbus-sensor-20` | Velbus (inputs) | V2 input: VMB8IN-20 |
 | `velbus-blind` | Velbus (outputs) | VMB1BL, VMB2BL |
 | `velbus-blind-s` | Velbus (outputs) | VMB1BLS, VMB2BLE, VMB2BLE-10 |
@@ -589,6 +589,62 @@ Address assignment: allow 500ms, then rescan to confirm the new address took eff
 not the right trigger for an automatic write-back, both for the EEPROM-wear reason above
 and because it risks a feedback loop. Reads have no such constraint and are always safe.
 
+### 7.8a `VMB4AN` — three similar-sounding packets, only one has the actual value
+
+A real trap, worth remembering for any future work on this module's
+sensor channels (9-12): `0xEA` ("sensor status") sounds like it should be
+the reading, but it's operating-mode/sleep-timer/auto-send configuration
+only — no value field at all. `0xE8`/`0xE9` ("sensor settings") sounds
+promising too, but that's stored preset *configuration*, not a live
+reading. The actual value lives in `0xA9` (`COMMAND_SENSOR_RAW_DATA`,
+labelled "Transmit the sensor raw value" in the PDF) — a completely
+standalone packet with no need to cross-reference either of the other two.
+```
+body[0] = 0xA9, body[1] = channel (9-12)
+body[2] = operating mode (00=voltage, 01=current, 10=resistance, 11=period)
+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
@@ -872,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/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/nodes/velbus-sensor/velbus-sensor.html

@@ -137,12 +137,24 @@
   "enabled": [1,2,3,4,5,6,7,8], "locked": [], "progDisabled": [],
   "program": "summer", "alarms": { "alarm1Active": false, "alarm2Active": false } }</pre>
 
-  <h3>Output 2 — Counter data (VMB7IN only)</h3>
+  <h3>Output 2 — Counter data (VMB7IN) / Analogue readings (VMB4AN)</h3>
   <pre>{ "type": "counter", "channel": 1, "count": 12345,
   "pulsesPerUnit": 1000, "periodMs": 3600, "overflow": false }</pre>
   <p>Engineering units: calculate in flow using pulsesPerUnit and periodMs.</p>
   <p>Power (W) = 3,600,000,000 / (periodMs × pulsesPerUnit)</p>
 
+  <p>VMB4AN sensor channels (9-12) — deliberately generic, no engineering-unit
+  conversion attempted here (mode-aware scaling, presets, and sleep-timer
+  configuration are a larger, separately-scoped piece of work — see
+  <code>coverage-roadmap.md</code>):</p>
+  <pre>{ "type": "analogue", "channel": 9, "mode": "voltage", "raw": 12345 }</pre>
+  <p><code>mode</code> is <code>"voltage"</code> (0-10V, 0.25mV/count),
+  <code>"current"</code> (4-20mA, 5µA/count), <code>"resistance"</code>
+  (PT100/PT1000/Ni1000, 0.25Ω/count), or <code>"period"</code> (0.5µs/count —
+  <code>raw</code> of <code>0</code> means short-circuited, <code>16777215</code>
+  means open-circuit). Apply the resolution yourself in the flow, e.g.
+  <code>volts = raw * 0.00025</code> for voltage mode.</p>
+
   <h3>Input commands</h3>
   <dl>
     <dt><code>{ "cmd": "get_status" }</code></dt><dd>Request module status.</dd>
@@ -150,6 +162,10 @@
     <dd>Request counter (VMB7IN). channels=bitmask of ch1-4 (default 15=all). interval=0 no change.</dd>
     <dt><code>{ "cmd": "reset_counter", "channel": 1 }</code></dt><dd>Reset pulse counter to zero.</dd>
     <dt><code>{ "cmd": "load_counter", "channel": 1, "value": 12345 }</code></dt><dd>Load counter with preset value (build 1426+).</dd>
+    <dt><code>{ "cmd": "get_analogue", "channel": 9 }</code></dt>
+    <dd>Request an analogue reading now (VMB4AN, channel 9-12). Doesn't change
+    the module's own auto-send interval configuration — it already sends
+    readings on its own schedule; this just asks for one immediately.</dd>
     <dt><code>{ "cmd": "get_name", "channel": 1 }</code></dt><dd>Request channel name from VelbusLink.</dd>
   </dl>
 </script>

package/nodes/velbus-sensor/velbus-sensor.js

@@ -172,6 +172,34 @@ module.exports = function(RED) {
           break;
         }
 
+        // ── 0xA9  Sensor raw value (VMB4AN channels 9-12 only) ────────────
+        // Confirmed from protocol_vmb4an.pdf, "Transmit the sensor raw
+        // value" — a genuinely standalone packet (COMMAND_SENSOR_RAW_DATA),
+        // not to be confused with 0xEA "sensor status" (that one carries
+        // operating mode / sleep timer / auto-send config, no actual value
+        // at all — a real trap if you assume "status" means "reading").
+        // body[0]=0xA9, body[1]=channel(9-12), body[2]=operating mode,
+        // body[3-5]=24-bit raw value (upper/high/low, MSB first).
+        // Deliberately generic per Stuart's own preference — engineering-
+        // unit conversion (voltage/current/resistance/period) is left to
+        // the flow, not attempted here. The PDF's resolution table (e.g.
+        // 0.25mV/count for voltage) is available in this node's help if
+        // conversion is ever wanted downstream.
+        case 0xA9: {
+          if (!isVMB4AN) return;
+          if (body.length < 6) return;
+
+          const channel  = body[1];
+          const modeCode = body[2] & 0x03;
+          const mode     = ['voltage', 'current', 'resistance', 'period'][modeCode];
+          const raw      = (body[3] << 16) | (body[4] << 8) | body[5];
+
+          const payload = { type: 'analogue', channel, mode, raw };
+
+          node.send([null, { payload }]);
+          break;
+        }
+
         // ── 0xF0/F1/F2  Channel name parts ───────────────────────────────
         case 0xF0:
         case 0xF1:
@@ -222,6 +250,25 @@ module.exports = function(RED) {
         return;
       }
 
+      // Request an analogue reading now — VMB4AN channels 9-12 only.
+      // DATABYTE3=0 explicitly means "don't change the auto-send interval
+      // config" per the protocol PDF — this just asks for a value without
+      // side effects on the module's existing auto-send behaviour.
+      // Priority: protocol PDF explicitly states "SID10-SID9 = 11 (lowest
+      // priority)" for this specific command — 0xFB, not the 0xF8 used by
+      // most other commands in this file. Checked directly rather than
+      // assumed, since this is the one place it genuinely differs.
+      if (cmd === 'get_analogue') {
+        if (!isVMB4AN) { node.warn('velbus-sensor: this module has no analogue sensor channels'); return; }
+        const ch = parseInt(msg.payload.channel);
+        if (!ch || ch < 9 || ch > 12) {
+          node.warn('velbus-sensor: get_analogue requires "channel": 9-12');
+          return;
+        }
+        node.bridge.send(pkt(0xFB, node.address, [0xE5, ch, 0x00]));
+        return;
+      }
+
       // Load counter — DB2=channel number (0-3), DB3=don't care, DB4-7=32-bit value
       if (cmd === 'load_counter') {
         if (!hasCounter) { node.warn('velbus-sensor: this module has no pulse counter'); return; }

package/package.json

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