New Node-RED Velbus palette in development (V0.7.3)

For developers
1

Hello everyone

I have been talked into giving AI programming a go and thought I’d give it a meaty project to get started with.

As Gert sold his Velbus home some years ago, the NodeRed Velbus palette is in need of an overhaul.

So… Why not let some AI coder loose on that to see what it can do.

Do any of you fancy testing out what it’s created so far and give some feedback?

There are help files in place which should get you up and running quickly.

If you’re not comfortable side loading a palette into a NodeRed instance, please wait until I’ve made it a full public feature.

But… If you are happy and you know how to tar a palette into the right folder and restart NodeRed…

I’d love to get your feedback

Download the TarBall here

http://velbus.co.uk/dl/node-red/velbus/node-red-contrib-velbus-2026.tar.gz

Example help file for the V1 Relay node

#########

velbus-relay

For V1 relays only

Interprets Velbus relay module packets and encodes commands.

Configuration

Bridge

Select or create a velbus-bridge config node.

Address

Module address in hex (e.g. 01, 0A). No 0x prefix needed.
(Drop down list of discovered and supported modules coming soon)

Start channel / Channel count

Filter which channels this node handles. Default: all 4 channels.

Module type

Leave blank — auto-detected from bus scan. Fill in only if module is offline at startup.

Output 1 — State / Events

Emitted on every relay state change (from 0xFB and 0x00 packets).

{
  topic:          "relay_status",
  address:        "0x01",
  module:         "VMB4RYLD-10",
  channel:        1,
  channelBit:     "0x01",
  state:          "on",          // off | on | timer_running | forced_on | forced_off | inhibited
  mode:           "on",
  timerRemaining: 0,
  ledState:       "on",          // off | on | slow_blink | fast_blink | very_fast_blink
  timestamp:      1719100000000
}

Also emits module_online and relay_switched topics.

Output 2 — Warnings

Emitted when a channel is in forced_on, forced_off or inhibited state.

Input — Commands

{
  channel:  1,           // 1-based channel number
  cmd:      "on",        // see command list below
  duration: 30           // seconds (timer/forced/inhibit commands only; -1 = permanent)
}

Commands:

  • on
  • off
  • toggle
  • timer
  • interval_timer
  • forced_on
  • forced_off
  • cancel_forced_on
  • cancel_forced_off
  • inhibit
  • cancel_inhibit
  • status

###########

velbus-relay-20

Interprets Velbus V2 (-20 series) relay module packets and encodes commands.

Supports:

  • VMB4RYLD-20
  • VMB4RYNO-20
  • VMB1RYS-20

For original series relay modules (VMB4RYLD, VMB4RYNO-10, VMB1RYS etc.) use the velbus-relay node instead.

Configuration

Name override

Leave blank — the node retrieves the module name from VelbusLink automatically. Only fill in if you want to override it.

Bridge

Select or create a velbus-bridge config node.

Address

Module address in hex (e.g. 01). No 0x prefix needed.
(Drop down list if discovered and supported modules coming soon)

Start channel / Channel count

Filter which channels this node handles.

Output 1 — State / Events

Emitted on every relay state change. V2 modules send one packet covering all channels simultaneously.

{
  topic:          "relay_status",
  address:        "0x01",
  module:         "Living Room",
  channel:        1,
  state:          "on",   // off | on | timer_running | forced_on | forced_off | inhibited
  on:             true,
  inhibited:      false,
  forcedOn:       false,
  forcedOff:      false,
  programDisabled: false,
  timerRunning:   false,
  alarmProgram:   { program:0, alarm1:false, ... },
  timestamp:      1719100000000
}

Also emits module_online and relay_switched topics.

Output 2 — Warnings

Emitted when a channel is in forced_off or inhibited state, and on firmware incompatibility.

Input — Commands

{
  channel:  1,        // 1-8, or "all"/0/255 for all channels
  cmd:      "on",     // see list below
  duration: 30        // seconds (timer/forced/inhibit only; -1 = permanent)
}

Commands:

  • on
  • off
  • toggle
  • timer
  • interval_timer
  • forced_on
  • forced_off
  • cancel_forced_on
  • cancel_forced_off
  • inhibit
  • cancel_inhibit
  • status

Firmware check

On startup the node checks the module’s memory map version. If incompatible, the node turns red and blocks all commands.
Check the Node-RED log for details.

1 Like
2

node-red-contrib-velbus-2026 — Development Changelog

Author: Stuart Hanlon, MDAR Limited (UK Velbus distributor)
GitHub: To be decided
npm: node-red-contrib-velbus-2026
Status: Active development — real hardware tested on live client installations

This palette is a ground-up rewrite for modern Node-RED (v3+/v5) with full
V2.0 (-20 series) module support. It replaces the abandoned node-red-contrib-velbus
palette (gertst, last updated 2020).

Testers welcome — particularly anyone with hardware not listed as confirmed below.
All feedback via GitHub issues, with examples and debug captures where possible.

v0.6.0 — 28/06/2026

Package rename and npm publication prep

  • Package renamed from node-red-contrib-velbus2 to node-red-contrib-velbus-2026
  • Version bumped to 0.6.0 for first public release
  • package.json updated with full npm publication metadata:
    • keywords: node-red, velbus, building-automation, home-automation, smart-home, relay, dimmer
    • repository, bugs, homepage all pointing to GitHub
    • author: Stuart Hanlon, MDAR Limited
    • license: MIT
  • README.md added — module list, quick start, confirmed hardware, contributing guide
  • LICENSE added — MIT
  • Disclaimer added to all 17 node HTML help sections:
    “Generated with Claude.ai — in need of extensive field testing before commercial
    deployment. Presented as-is, use beyond testing at your own risk. File issues on GitHub.”

Handover document

  • Complete ground-up rewrite of velbus2_master_handover.md
  • Now 970 lines, supersedes all previous baseline files
  • Added Appendix A: Virtual Module Kit (parked — new module set: VMB1RYS/VMB7IN,
    VMB1RYNO, VMB4DC, VMB4AN)
  • Added Appendix B: npm publication steps, GitHub repo creation walkthrough,
    disclaimer text for help files

v0.5.8 — 27/06/2026

velbus-blind-20 (new node)

  • V2 blind/shutter motor controller — VMB2BLE-20 (0x61)
  • Full V2 redesign: CAN FD support, 8-byte 0xFF with properties byte,
    firmware check on startup, channel name auto-retrieval
  • 0xEC status packet completely restructured vs BLS/BLE series — both
    channels packed into a single packet using nibble encoding rather than
    separate per-channel packets. Status, position, lock state, and auto mode
    are all dual-nibble fields.
  • Channel identifier in commands: plain integer 1, 2, or 0xFF for all — not
    a bit value as in BLS/BLE series
  • Position 0-100%, full lock/force/inhibit set, auto modes, sunrise/sunset
  • Additional commands vs BLS/BLE: enable_program (0xB2), disable_program (0xB1)
  • Note: 0xFFFFFF (permanent) NOT allowed for up/down timeout on this module —
    maximum is 0xFFFFFE. Permanent allowed for lock/force/inhibit duration.
  • Input commands: stop, up, down, position, lock, unlock,
    forced_up, cancel_forced_up, forced_down, cancel_forced_down,
    inhibit, cancel_inhibit, inhibit_preset_up, inhibit_preset_down,
    auto_mode, enable_program, disable_program, get_status, get_name

velbus-scan corrections (from official Velbus module ID list)

The following type byte assignments were wrong and have been corrected:

Type Was Now
0x0C VMBRSUSB VMB1TS (temperature sensor)
0x18 VMBUSBIP VMB2PBN (2-button panel with night mode)
0x1C VMB4PB REMOVED — 0x1C not in official list
0x20 VMB6PB-20 VMBGP4 (4-button glass panel) — added to glass-panel-types.js
0x40 (missing) VMBUSBIP (moved from 0x18)
0x44 (missing) VMB4PB (added)
0x4C (missing) VMB6PB-20 (added)

velbus-button node suggestion updated: now covers 0x18 (VMB2PBN, 2ch),
0x44 (VMB4PB, 4ch), 0x4C (VMB6PB-20, 6ch). Previous incorrect 0x1C and
0x20 entries removed.

VMBGP4 (0x20) added as 26th type in lib/glass-panel-types.js.

lib/blind-types-20.js (new)

  • Type registry for V2 blind series: VMB2BLE-20

v0.5.7 — 27/06/2026

velbus-blind (new node)

  • Original series blind/shutter motor controllers — VMB1BL (0x03), VMB2BL (0x09)
  • Early modules: 5-byte 0xFF response (no serial number), dip-switch timeout
    setting, no position feedback, no lock/force/inhibit
  • VMB1BL: 1 channel, fixed channel byte 0x03, local push button events mixed
    into 0x00 bitmask alongside relay events
  • VMB2BL: 2 channels, packed bitmask channel encoding (ch1=0x03, ch2=0x0C),
    local push button events included in 0x00
  • Stop/up/down commands only. Timeout 0=dip switch, 0xFFFFFF=permanent
  • Input commands: stop, up (with timeout), down (with timeout),
    get_status, get_name
  • Address dropdown filters to VMB1BL/VMB2BL types from scan results

velbus-blind-s (new node)

  • Full-featured BLS/BLE series — VMB1BLS (0x2E), VMB2BLE (0x1D),
    VMB2BLE-10 (0x4A)
  • 7-byte 0xFF with serial number and memory map version
  • Position feedback (0-100%): 0=fully up, 100=fully down
  • Lock/unlock (0x1A/0x1B — unique command bytes to blind family)
  • Forced up (0x12) / forced down (0x14) — note: same bytes as relay forced-off/on
    but inverted direction semantics in blind context
  • Full inhibit set: inhibit, inhibit_preset_up, inhibit_preset_down,
    cancel_inhibit
  • Auto modes (1-3), sunrise/sunset, real-time clock
  • VMB2BLE-10 confirmed protocol-identical to VMB2BLE — only structural difference
    is 8-byte 0xFF (with terminator byte vs 7-byte). Handled by same node.
  • No local push button events in 0x00 (relay events only, unlike VMB1BL/VMB2BL)
  • Two outputs: relay events on output 1, full 0xEC status on output 2
  • Input commands: stop, up, down, position, lock, unlock,
    forced_up, cancel_forced_up, forced_down, cancel_forced_down,
    inhibit, cancel_inhibit, inhibit_preset_up, inhibit_preset_down,
    auto_mode, get_status, get_name

lib/blind-types.js (new)

  • Type registry for original series blind modules: VMB1BL, VMB2BL
  • channelMasks: packed bitmask per channel for 0xEC and commands

lib/blind-types-s.js (new)

  • Type registry for BLS/BLE series: VMB1BLS, VMB2BLE, VMB2BLE-10
  • channelBits: clean bit encoding (ch1=0x01, ch2=0x02)

v0.5.6 — 27/06/2026

velbus-meteo (new node)

  • Weather station node for VMBMETEO (0x31)
  • Output 1: alarm events (0x00) and module status (0xED)
  • Output 2: temperature (0xE6), rain/light/wind (0xA9), sensor text (0xAC)
  • 8 configurable alarm outputs via bitmask — alarm conditions (wind speed,
    rainfall, light levels) configured in VelbusLink, fired as 0x00 events
  • 0xA9 carries rain (×0.1 mm/h), light (lux), wind (×0.1 km/h) as three
    16-bit values in one packet — emitted with engineering units applied
  • 0xAC sensor text: same command byte as OLED memo on glass panels but
    completely different meaning — formatted sensor value string from module
  • 0xF0/F1/F2 alarm channel names use bitmask in DB2 (not channel number)
  • Auto-send interval: values 5-9 = percentage-change thresholds, not fixed seconds
  • Input commands: get_status, get_temp, get_meteo (sensor: rain/light/wind/all),
    get_alarm_name (channel 1-8), test_on, test_off

velbus-sensor (new node)

  • Original series configurable input node — VMB7IN (0x22), VMB4AN (0x32)
  • Output 1: channel events (0x00) and module status (0xED)
  • Output 2: pulse counter data (VMB7IN only — 0xBE)
  • VMB7IN: 8 digital input channels + pulse counter on channels 1-4
    • All 8 channels produce 0x00 press/release/long-press events regardless of
      input type (contact closure, alarm threshold — configured in VelbusLink)
    • Counter: 32-bit pulse count + period in ms between last two pulses
    • Engineering units must be calculated in flow using pulsesPerUnit and periodMs
    • Power (W) = 3,600,000,000 / (periodMs × pulsesPerUnit)
  • VMB4AN: 16 logical channels across 3 groups (architecture defined; groups 2
    and 3 deferred to follow-up session pending hardware availability)
  • Channel names use bitmask in DB2 of 0xF0/F1/F2
  • Lock/unlock use bitmask in DB2
  • Input commands: get_status, get_counter (channels bitmask + interval),
    reset_counter (channel 1-4), load_counter (channel + value), get_name
  • Note: VMB7IN 0xED PDF states DLC=5 but lists 7 fields — implementation
    treats as 7 bytes. Verify against real hardware.

velbus-sensor-20 (new node)

  • V2 series configurable input node — VMB8IN-20 (0x4E)
  • Output 1: channel events (0x00) and module status (0xED)
  • Output 2: energy counter data (0xA4)
  • Up to 32 digital input channels: 8 on primary address, 24 via 3 subaddresses
    (channels 9-16, 17-24, 25-32). Bridge routes subaddress packets to primary
    node listener transparently.
  • 0x00 channel event payload includes sourceAddress field to distinguish
    primary from subaddress events
  • 0xED from primary (8 bytes): full status including normal/inverted, auto-send
  • 0xED from subaddress (5 bytes): alarm status, enabled, locked, prog-disabled
  • 0xA4 energy counter: 20-bit power in Watts + 32-bit energy in Wh/litres/ml
    (counter type set in VelbusLink — same packet format for all)
  • Firmware check on startup (3-stage: type → map version → pass)
  • Module name auto-retrieved from VelbusLink on startup
  • Lock/unlock use channel number (1-32, 0xFF for all) — V2 style
  • Channel names use channel number in DB2
  • Input commands: get_status, get_counter (channels bitmask + interval),
    load_counter (channel + value), lock, unlock, get_name

velbus-scan corrections

  • VMB7IN (0x22) added to ALL_TYPES, NODE_SUGGESTION (velbus-sensor), MODULE_CHANNELS (8ch)
  • VMB8IN-20 (0x4E) added — type byte was previously unknown
  • VMBMETEO (0x31) now has node suggestion: velbus-meteo
  • VMB4AN (0x32) node suggestion updated: velbus-sensor
  • VMB2BLE (0x1D), VMB2BLE-10 (0x4A), VMB2BLE-20 (0x61) relabelled from
    incorrect ‘BLE (Bluetooth)’ to ‘blind (motor controller)’ — these are
    single/dual channel reversible AC motor controllers for roller shutters
    and blinds. VMB = Velbus Motor Blind. No Bluetooth involved.

lib/sensor-types.js (new)

  • Type registry for original series sensor modules: VMB7IN, VMB4AN
  • Flags: hasCounter, hasAnalogue, lockStyle, nameStyle, counterCh

lib/sensor-types-20.js (new)

  • Type registry for V2 sensor modules: VMB8IN-20
  • Flags: hasCounter, lockStyle, nameStyle, alarmCh (subaddress alarm channels)

v0.5.5 — 27/06/2026

velbus-pir (new node)

  • Original and -10 series PIR modules — VMBPIRM (0x2A), VMBPIRC (0x2B),
    VMBPIRO (0x2C), VMBPIRO-10 (0x23)
  • Output 1: channel events, module status, light value
  • Output 2: temperature and settings — VMBPIRO and VMBPIRO-10 only
  • Channel bitmask model: bits 0-5 = dark/light/motion1/ldMotion1/motion2/ldMotion2.
    VMBPIRM and VMBPIRC add bit6=absence. VMBPIRO and VMBPIRO-10 add
    bit6=lowTempAlarm / bit7=highTempAlarm instead.
  • Lock/unlock/enable/disable program commands use channel bitmask in DB2
  • 0xE8 temperature settings: compact 7-byte format (calibration offset, gain,
    low alarm, high alarm, zone, auto-send interval)
  • Input commands: get_status, get_light (with optional auto-send interval),
    get_temp, get_temp_settings, test_on, test_off
  • Address dropdown filters to PIR original/-10 types from scan results
  • Note: VMBPIRM has a light sensor (required for dark/light output logic) but
    its PDF does not list raw lux value as bus-accessible. Node handles 0xA9
    if received; get_light command sent regardless.

velbus-pir-20 (new node)

  • V2 series PIR modules — VMBPIR-20 (0x4D), VMBPIRO-20 (0x59)
  • Output 1: channel events, module status, light value
  • Output 2: temperature and settings — VMBPIRO-20 only
  • VMBPIR-20: 7 channels (dark/light/motion1/ldMotion1/motion2/ldMotion2/absence)
  • VMBPIRO-20: 6 lockable channels + bits 6-7 = lowTempAlarm/highTempAlarm
    (temperature alarm bits appear in 0x00 and 0xED but are not lockable)
  • Lock/unlock commands use channel number (1-N, 0xFF for all) — not bitmask
  • Firmware check on startup (3-stage: type → map version → pass)
  • Module name auto-retrieved from VelbusLink on startup
  • CAN FD flag decoded from 0xFF properties byte
  • 0xE8 on VMBPIRO-20: multi-part glass-panel-style format inherited from
    thermostat firmware; only calibration and alarm fields in part 1 are meaningful
  • Input commands: get_status, get_light, get_temp, get_temp_settings,
    lock (channel + duration), unlock (channel), test_on, test_off

velbus-scan

  • VMBPIRM (0x2A), VMBPIRC (0x2B), VMBPIRO (0x2C), VMBPIRO-10 (0x23) added
    to ALL_TYPES, NODE_SUGGESTION, and MODULE_CHANNELS
  • velbus-pir suggested for all four original/-10 types

lib/pir-types.js (new)

  • Type registry for original/-10 PIR series: hasTempSensor, lockStyle,
    channel name arrays, minMapVer, series

lib/pir-types-20.js (new)

  • Type registry for V2 PIR series: hasTempSensor, lockStyle, channel maps,
    bitmask arrays (for 0x00/0xED parsing), minMapVer, series

v0.5.4 — 27/06/2026

Protocol parser corrections (velbus-glass-panel, velbus-thermostat)

A systematic body-indexing error was present in all glass-panel and thermostat
packet handlers. parsePkt() returns body[] where body[0] is DATABYTE1 —
the command byte — and data starts at body[1]. All handlers have been
corrected.

  • 0xEA thermostat status — format was incorrectly implemented as 16-bit
    integers divided by 100. Correct format per protocol PDFs: signed single bytes
    at 0.5° resolution for temperature values, with operating mode, output status,
    and sleep timer as separate fields. Mode (comfort/day/night/safe), heater/cooler
    direction, and active outputs (heating, cooling, boost) now correctly decoded.
  • 0xE6 current temperature — format corrected to 16-bit signed value divided
    by 16 (0.0625° resolution), not divided by 100.
  • 0xE8 temperature settings — format corrected to signed single bytes at 0.5°
    resolution. Payload now includes current, comfort, day, night, safe
    heating presets.
  • 0xED module status — full structured parse implemented. DATABYTE4 correctly
    decoded: open collector on/off, OC locked, OC program disabled, temperature
    sensor program disabled, edge colour inhibited. Locked and programme-disabled
    channel bitmasks now correctly extracted from DATABYTE5 and DATABYTE6.
  • 0xF0/F1/F2 name parts — command and channel-number bytes now stripped before
    storing; 0xFF padding filtered in name assembly alongside null bytes.
  • 0xA9, 0xAC, 0xBE — body indices corrected.

Open collector output

  • output_timer command fixed — duration is 24-bit (3 bytes), not 16-bit.
    Supports up to ~194 days; 0xFFFFFF = permanently on.
  • 0xED handler now emits OC state in the status payload for modules with a
    confirmed open collector output:
    { "type": "status", ..., "output": { "on": true, "locked": false, "programDisabled": false } }
  • hasOc flag added to all 25 types in lib/glass-panel-types.js. OC confirmed
    from PDF for the full VMBEL family (original and -20) and VMBGPO/-20. OC
    absent from VMBGP1-2/2-2/4-2 per protocol PDF. Remaining GP types pending
    hardware verification (UK, post July 2026).

velbus-glass-panel

  • Button output payload now includes on boolean — true when any channel is
    pressed or long-pressed.

velbus-thermostat

  • Spurious on field removed from 0xEA, 0xE6, 0xE8 and 0xED payloads.
    thermostatOn in the thermostat payload is the correct state field.
  • Temperature and settings payloads do not carry an on field.

v0.5.3 — 27/06/2026

Payload and type table cleanup

  • Button output on boolean added to velbus-glass-panel 0x00 handler (was
    present in velbus-button but missing from glass panel).
  • Config dialog address dropdowns fixed across all three affected nodes
    (velbus-glass-panel, velbus-thermostat, velbus-button) — endpoint returns
    { modules: [...], count: N } and dialogs were operating on the wrapper object
    instead of modules.
  • lib/glass-panel-types.js: VMBGP1 (0x1E, 1ch) and VMBGP2 (0x1F, 2ch) added
    — 23 → 25 types.
  • velbus-scan NODE_SUGGESTION and MODULE_CHANNELS updated for 0x1E and 0x1F.

v0.5.2 — 27/06/2026

velbus-button (new node)

  • Pure button/input node — press, release, long-press events on 0x00
  • Supports VMB8PB, VMB8PBU, VMB6PBN, VMB4PB (original series) and VMB6PB-20 (V2)
  • Also suitable for glass panel sub-addresses when button events need separate wiring
  • Address dropdown filters to button module types; channel count auto-populated from scan
  • Output: { type: "button", on: true, pressed: [1,3], released: [], longPressed: [] }
  • on is true when any channel is pressed or long-pressed

velbus-glass-panel improvements

  • heat_mode and cool_mode commands added (0xE0 / 0xDF)
  • Name auto-retrieval on startup — module name from VelbusLink populates status bar automatically

velbus-thermostat improvements

  • Name auto-retrieval on startup — same as glass-panel

velbus-scan

  • Button module types added to NODE_SUGGESTION

v0.5.1 — 27/06/2026

velbus-thermostat (new node)

  • Dedicated thermostat node — clean separation from glass panel button events
  • Targets primary module address — all commands go to base address, not thermostat sub-address
  • Commands: comfort, day, night, safe (mode switch with optional sleepTime), set_temp, get_thermostat
  • set_temp: pointer (0=comfort/1=day/2=night/3=safe) + temp (float °C)
  • Output 1: { type, currentTemp, targetTemp, mode, heaterMode, heating, cooling, boostMode, thermostatOn }
  • Output 2: { type, current, min, max }
  • Can coexist on same address as velbus-glass-panel — bridge fans out to all registered listeners

Palette groups

  • Velbus (inputs) — teal #3A8C8C: velbus-scan, velbus-glass-panel, velbus-thermostat
  • Velbus (outputs) — blue #4A90D9: velbus-relay, velbus-relay-20, velbus-dimmer, velbus-dimmer-20

v0.5.0 — 27/06/2026

velbus-glass-panel (new node)

  • Single node covers entire VMBEL / VMBGP glass panel family — 23 module types, original and V2
  • Output 1 — Buttons: press, release, long-press per channel
  • Output 2 — Status/thermostat: module status (0xED), thermostat (0xEA), temperature (0xE6)
  • Output 3 — Name parts: VelbusLink module name on request
  • OLED extras (memo text, counter, display page) emitted on OLED-capable types only
  • PIR channel semantic labels (button1-4, virtual, dark, light, motion) on PIR variants
  • Thermostat rx/tx included — velbus-thermostat node also available for dedicated thermostat wiring
  • LED control: led_set, led_clear, led_slow, led_fast, led_vfast
  • Open collector: output_on, output_off, output_timer
  • Config dialog: dropdown filters to glass panel types, channel count auto-populated
  • lib/glass-panel-types.js — standalone type registry (hasOled, hasPir, hasOc, pirChannels, channels, minMapVer)

velbus-scan corrections

  • 0x55 corrected from VMB8IN-20 to VMBGP2-20 (collision resolved from protocol PDFs)
  • 0x3A/3B/3C corrected to VMBGP1/2/4-2 original series (not -20)
  • 0x21 corrected to VMBGPO
  • All 23 glass panel types added to NODE_SUGGESTION and MODULE_CHANNELS

v0.4.3 — 27/06/2026

Address dropdowns in all config dialogs

  • velbus-relay, velbus-relay-20, velbus-dimmer, velbus-dimmer-20 config
    dialogs now show a dropdown of discovered modules from the most recent scan
  • Dropdown filters by node type — relay dialog shows only relay modules, dimmer
    dialog shows only dimmer modules, etc.
  • Each option shows: address, module type, build number, map version
  • Falls back to plain text input if no scan has been run yet
  • Manual entry always available at the bottom of the dropdown
  • Run a velbus-scan node once — all subsequent config dialogs benefit automatically

velbus-bridge

  • storeScanResults() / getScanResults() API added
  • RED.httpAdmin endpoint registered: GET /velbus/scan-results?bridge={nodeId}
    — serves scan results as JSON to config dialog dropdowns

velbus-scan

  • Calls bridge.storeScanResults() on scan completion

v0.4.2 — 27/06/2026

velbus-scan bugfix

  • Duplicate 0x2D key in ALL_TYPES registry — VMBIN was silently overwritten
    by VMBPIRO. Fixed as VMBIN/VMBPIRO pending PDF confirmation of whether they
    share a type byte or are distinct.

v0.4.1 — 27/06/2026

velbus-relay payload correction

  • mode field removed from relay_status payload — was an unnecessary duplicate of state
  • on boolean added to relay_status payload (was missing from original series node)
    • on: true when state is on, timer_running or forced_on
    • on: false for all other states

v0.4.0 — 27/06/2026

New nodes

  • velbus-dimmer-20 — V2.0 series dimmer and output modules

    • Supports VMB2DC-20 (2ch, 0-10V), VMB8DC-20 (8ch, 0-10V), VMB4LEDPWM-20 (4ch, PWM LED)
    • 0xEE bitmask status parser (on/inhibited/forcedOn/forcedOff/programDisabled/error per channel)
    • 0xA5 dim level packets — raw 0-254 value plus calculated percentage
    • Spontaneous 0x00 dim level broadcasts handled
    • dimCurve field in every payload (linear or exponential)
    • outputType field (0-10V or PWM)
    • on boolean: true when level > 0 and not forced off or inhibited
    • Commands: set (by raw level 0-254 or percent 0-100), on, off,
      restore, timer, scene (0-15), forced_on, forced_off,
      cancel_forced_on, cancel_forced_off, inhibit, cancel_inhibit, status
    • fadeMode on set commands: 0=direct, 1=rate, 2=time
    • Live tested on VMB8DC-20 at Toulouse client site ✓

  • velbus-dimmer — Original series dimmer modules (pre V2.0)

    • Supports VMBDMI (1ch), VMBDMI-R (1ch), VMB4DC (4ch)
    • 0xB8 status parser — 0-100% native scale (original series)
    • Thermal status decoded for VMBDMI/VMBDMI-R: tempBand, loadType, error
    • VMB4DC uses bitmask channel model; VMBDMI/R use fixed single channel
    • dimspeed parameter (seconds) on set/on/off/restore commands
    • Commands: set, on, off, restore, stop, timer, forced_on,
      forced_off, cancel_forced_on, cancel_forced_off, inhibit,
      cancel_inhibit, status

Notes

  • VMB2DC-20 and VMB8DC-20 output a 0-10V control voltage — they do not carry
    mains load. They drive third-party dimmer packs, actuators, or any 0-10V
    compatible device. VMB4LEDPWM-20 outputs PWM for direct LED control.
  • DALI references in VMB2DC-20/VMB8DC-20/VMB4LEDPWM-20 PDFs are documentation
    bleed-over from the shared VMBDALI codebase and are not implemented.

v0.3.10 — 26/06/2026

velbus-scan improvements

  • Scan order reversed (0xFE→0x01) — higher addresses confirmed present first
  • Recursive setTimeout replaces flat loop — more reliable on constrained hardware
  • Collect window extended to 8000ms
  • Output 2 fires module_found immediately on each discovery
  • 0x4D correctly identified as VMBPIR-20 (confirmed on Toulouse hardware)
  • NODE_SUGGESTION extended to cover PIR and glass panel module types

velbus-bridge improvements

  • Scan lock mechanism: lockScan() / unlockScan()
  • Interpreter node startup RTRs queued during active scan, flushed 1/second after

velbus-relay / velbus-relay-20

  • Startup RTR passed with startup=true flag — correctly queued during scan

v0.3.0 — 25/06/2026

New nodes

  • velbus-relay-20 — V2.0 series relay modules

    • Supports VMB4RYLD-20, VMB4RYNO-20, VMB1RYS-20
    • Correct V2.0 0xFB bitmask parser — one packet = full module state
    • All bitmask fields in payload: on/inhibited/forcedOn/forcedOff/programDisabled/timerRunning
    • Channel number commands (1-8 or 0xFF for all) — not bitmask
    • alarmProgram decoded in every status payload
    • canFD flag from 0xFF properties byte

  • velbus-scan — Bus scanner

    • RTR to every address (0x01–0xFE), collects 0xFF responses
    • Output 1: scan_complete with full module array
    • Output 2: module_found per discovered module
    • Each result: address, typeId, module name, serial, build, memoryMapVersion,
      canFD, suggestedNode, subaddresses
    • Configurable RTR delay (default 75ms) and collect window

velbus-bridge improvements

  • Passive 0xB0 subaddress handler
  • Subaddress packets transparently routed to primary node
  • Commands always sent to primary address only

velbus-relay improvements

  • VMB4RYLD-20 and VMB4RYNO-20 removed from original series registry
  • 3-stage firmware check on 0xFF
  • Module name auto-retrieval via 0xEF/0xF0/0xF1/0xF2
  • Status bar: VelbusLink name + address
  • Hard block on firmware incompatibility or unknown type

v0.2.0 — 25/06/2026

New nodes

  • velbus-bridge (config node)

    • Persistent TCP connection with auto-reconnect (5s)
    • TLS and auth key support (python-velbustcp)
    • Address-based packet dispatch
    • 'all' listener for scanner

  • velbus-relay — Original series relay modules

    • Supports VMB1RY, VMB4RY, VMB4RYLD, VMB4RYNO, VMB1RYNO, VMB1RYNOS,
      VMB1RYS, VMB4RYLD-10, VMB4RYNO-10
    • 0xFB per-channel status parser
    • Commands: on, off, toggle, timer, forced_on, forced_off,
      cancel_forced_on, cancel_forced_off, inhibit, cancel_inhibit, status

Confirmed hardware (live testing)

All testing on real installations via TCP gateway (velbus-tcp snap, port 6000).

Module Type Site Status
VMB1RYS 0x41 Toulouse FR ✓ map v0, build 3654
VMBEL1 0x34 Toulouse FR ✓ map v2, build 3433
VMBEL4 0x36 Toulouse FR ✓ map v2, build 3433 (×5 units)
VMBELO 0x37 Toulouse FR ✓ map v4, build 3821, CAN FD
VMBELPIR 0x38 Toulouse FR ✓ map v2, build 3433
VMBPIR-20 0x4D Toulouse FR ✓ map v1, build 3640, CAN FD (×2 units)
VMB8DC-20 0x4B Toulouse FR ✓ live tested, multiple channels confirmed
VMB4RYNO-20 0x27 Toulouse FR ✓ present on site (address TBC)

Not yet tested (hardware available, nodes not yet built):
VMBELO thermostat, VMB4AN, VMBGP series, VMBIN, VMB2BLE

Payload standards

All nodes follow consistent payload conventions:

Relay:

{ "state": "on", "on": true, "timerRemaining": 0, "ledState": "off" }

Dimmer:

{ "state": "on", "on": true, "level": 187, "percent": 73.6 }

Button / glass panel buttons:

{ "type": "button", "on": true, "pressed": [1, 3], "released": [], "longPressed": [] }

Thermostat status:

{ "type": "thermostat", "currentTemp": 21.5, "targetTemp": 22.0, "mode": "comfort",
  "heaterMode": true, "heating": false, "cooling": false, "boostMode": false, "thermostatOn": true }

Temperature:

{ "type": "temperature", "current": 21.5, "min": 15.0, "max": 30.0 }

Glass panel module status:

{ "type": "status", "locked": [], "thermostatProgram": "manual",
  "alarms": { "alarm1Active": false, "alarm2Active": false, "selected": 0 },
  "output": { "on": false, "locked": false, "programDisabled": false } }

output field only present on modules with a confirmed open collector output.

on is always a boolean where present. state is always a human-readable string.
Numbers are always numbers — never strings of numbers.
Temperature and settings payloads do not carry an on field.

Roadmap

Planned (PDFs needed):

  • velbus-energy — VMBPSUMNGR-20 (0x04). PDF needed.

Pending hardware verification (UK, post July 2026):

  • Open collector presence on VMBGP1/2/4 original and VMBGP-20 series
  • VMBPIRM raw light value bus accessibility (0xA9 / 0xAA)
  • VMB7IN 0xED actual byte count (PDF lists 7 fields but states DLC=5)

The Cunning Plan — VelbusLink as ground truth:
Build a Node-RED flow that responds to a VelbusLink bus scan with all
unknown module type bytes simultaneously, using address = type byte.
VelbusLink displays correct names and writes them to the VLP project file.
Run on return to UK (Northampton, post July 2026).

Unknown type bytes to sweep (sample): 0x03 VMB1BL (old), 0x05 VMB6IN,
0x07 VMB1DM, 0x09 VMB2BL (old), 0x0A VMB8IR, 0x0B VMB4PD, 0x0C VMB1TS,
0x0E VMB1TC, 0x0F VMB1LED, 0x14 VMBDME, 0x25 VMBGPTC, 0x28 VMBGPOD,
0x53 (VMBBEL1PIR-20?), 0x5C (VMBBEL2PIR-20 / VMBEL4PIR-20 conflict),
and others.

Not planned:

  • velbus-dali — out of scope

Installation (pre-npm-publish)

cd /mnt/dietpi_userdata/node-red   # or ~/.node-red
npm install /path/to/node-red-contrib-velbus2
dietpi-services restart node-red   # or: node-red-restart

Tested on Node-RED v5.0, Node.js 18+, DietPi (Odroid C4).
Gateway: velbus-tcp snap (port 6000) or python-velbustcp (port 27015).

Workflow: Drop velbus-scan node → run once → all config dialogs show
address dropdowns populated with discovered modules.

s scan with all
unknown module type bytes simultaneously, using address = type byte.
VelbusLink displays correct names and writes them to the VLP project file.
Run on return to UK (Northampton, post July 2026).

Unknown type bytes to sweep (sample): 0x03 VMB1BL (old), 0x05 VMB6IN,
0x07 VMB1DM, 0x09 VMB2BL (old), 0x0A VMB8IR, 0x0B VMB4PD, 0x0C VMB1TS,
0x0E VMB1TC, 0x0F VMB1LED, 0x14 VMBDME, 0x25 VMBGPTC, 0x28 VMBGPOD,
0x53 (VMBBEL1PIR-20?), 0x5C (VMBBEL2PIR-20 / VMBEL4PIR-20 conflict),
and others.

Not planned:

  • velbus-dali — out of scope

Installation (pre-npm-publish)

cd /mnt/dietpi_userdat