If anyone is interested, after many days and I dread to think how many AI Tokens, Claude.ai has managed to take @jeroends VelServ C++ code and adapted it for ESP32S3 with PoE Micro-Python.
The result is a Velbus TCP server or TCP client / bridge, with the added bonus of a SYSlog client reporting on the health of the gateway and the CANbus health.
If you’re interested, I’m happy to share the .bin to push into the same hardware I’ve used.
Have a good read of this User Guide for more information and example use cases.
###########
Velbus CAN Gateway — User Guide
Firmware version: 0.8.3
Hardware: M5Stack AtomS3 Lite + Atomic PoE Base + M5Stack Unit CAN (CA-IS3050G)
What this device does
The gateway sits between a physical Velbus CAN bus and your network. It speaks
plain TCP on a configurable port (default 6000), using the same wire format
as velbus-tcp / velserv, so applications like VelbusLink, openHAB, HomeAssistant, Control4 & OpenRemote can connect to it
exactly as they would to a serial or USB Velbus interface — except over the
network instead of a cable.
It also runs a small web portal (port 80) for configuration, and shows status
on four onboard RGB LEDs.
Architecture: two roles, never both at once
The gateway can operate in one of two modes, chosen from a single dropdown in
the web portal:
- Server mode — the gateway runs its own Velbus TCP server. VelbusLink
(or any other Velbus TCP client) connects directly to it. - Bridge mode — the gateway runs no server at all. Instead it connects
out, as a client, to a Velbus TCP server running elsewhere.
These are mutually exclusive by design, matching how the reference Velbus TCP
tool (velserv) itself works — a single instance is either a server or a
client, never both. A unit in Bridge mode does not run a Velbus TCP server
of its own; its web portal remains available as normal.
Both patterns are supported and tested:
- Gateway to gateway. A unit in Bridge mode can connect directly to
another unit running in Server mode. This is confirmed working, and is
the simplest way to join two Velbus segments with no PC involved. - Gateway to a PC-based server. A unit in Bridge mode can equally
connect out to a Velbus TCP server running on a PC (velserv,
velbus-tcp, a Node-RED flow, and so on). This is the pattern to choose
when you want several segments merged into one unified view — the PC
becomes the aggregation point, with each gateway feeding it.
The rule of thumb: for two segments, gateway-to-gateway is simplest; for
three or more, or where you want a single point of management and
logging, put a PC-based server at the centre and run every gateway as a
Bridge client into it.
Why the roles are kept separate
- A gateway is either serving or bridging, never both. This matches
the reference implementation and keeps each unit’s behaviour easy to
reason about — you always know which end of a connection a given unit
is. - Security and isolation. Splitting server and edge roles also gives you
a real, useful security boundary — see the multi-tenant example below.
Use case examples
1. Standalone site — Server mode only
A single building with one Velbus network and no need to connect to
anything else. One gateway, in Server mode, is all you need. VelbusLink
connects straight to it.
[VelbusLink] <-- TCP --> [Gateway: Server mode] <-- CAN --> [Velbus modules]
2. Large site with a central server — Bridge mode as edge extension
A larger installation — several separate physical Velbus runs (different
floors, wings, or outbuildings) that should all appear as one single
network to VelbusLink. Each AtomS3 Lite gateway sits at the edge of its
own local Velbus segment, in Bridge mode, and connects out to one
central PC-based Velbus TCP server. VelbusLink connects only to that
central server, and sees every module on every segment as if they were all
on one bus.
[Gateway A: Bridge] --\
\
[Gateway B: Bridge] -----> [PC: velserv / Node-RED] <-- TCP --> [VelbusLink]
/
[Gateway C: Bridge] --/
This is the pattern to use whenever you want a genuinely unified network
view across several physical CAN segments — the merging logic lives in one
place, on a machine with plenty of capacity for connections, logging and
storage.
For just two segments you don’t need the PC at all: put one gateway in
Server mode and point the other at it in Bridge mode (see the architecture
section above). The central-server pattern earns its place from three
segments upward, or wherever you want a single point of management.
This is also exactly where syslog reporting earns its keep — with
several edge gateways all quietly bridging in the background, enabling
syslog on each one gives you a single place to see every unit’s heartbeat,
CAN faults, and connection status, without needing to open each gateway’s
own web portal individually to check.
3. Multi-tenant site (e.g. a hotel) — Server mode per suite, deliberately not bridged
This is a case where you deliberately do not want every network merged
into one. In a hotel, each guest suite might have its own Velbus network and
its own gateway, each left in plain Server mode, standalone, with no
bridge to anywhere else.
Suite 101: [Gateway: Server mode] <-- CAN --> [Velbus modules, Suite 101]
Suite 102: [Gateway: Server mode] <-- CAN --> [Velbus modules, Suite 102]
Suite 103: [Gateway: Server mode] <-- CAN --> [Velbus modules, Suite 103]
If wider building-level control or monitoring is genuinely needed, a
Node-RED instance can selectively connect out to specific suites’ gateways
and handle any cross-suite logic itself, entirely under your control —
rather than the gateways bridging directly to one another.
Why this matters: if a guest in Suite 101 were to somehow interfere with
or compromise their in-room gateway, there is no direct network path from
that gateway into any other suite’s Velbus network — because it was never
bridged to one. Each suite’s gateway is its own island. Compare this to a
design where every gateway bridges directly to every other one: a single
compromised edge device would then have a direct path to the whole
building’s Velbus network. Keeping suites in isolated Server mode, and only
selectively connecting them via a controlled Node-RED instance if and when
building-wide logic is genuinely needed, keeps that blast radius contained
to the one device an intruder can actually reach.
Worked example: a fully-populated suite with a VMBPSUMNGR-20
Take Suite 101 above and add Velbus’s own power supply manager,
VMBPSUMNGR-20, to that suite’s segment — a realistic setup for a
higher-spec installation. That single module reports, per PSU rail:
- Load percentage
- Live wattage, voltage, and amperage
- A running hours-in-service counter, checked against a 10-year
(87,660-hour) design life, with an expired flag - PSU and warranty alarm status
Combine that with what the gateway itself already reports over its
isolated syslog channel — CAN bus-off/error-passive events, TCP client
connect/disconnect, bridge connect/disconnect, periodic heartbeats — and
a single suite’s segment now gives a central monitoring point a genuinely
rich picture without ever breaching the isolation boundary between
suites:
Suite 101 segment reports (via gateway's isolated WiFi syslog channel):
- Gateway alive, uptime, CAN bus speed
- CAN bus health (any fault immediately, not just on heartbeat)
- VMBPSUMNGR-20: PSU1/PSU2 voltage, current, load %, hours in service
- VMBPSUMNGR-20: warranty/alarm status (is this PSU approaching end of life?)
- Gateway's own network path status (still isolated from other suites)
None of this requires bridging Suite 101’s Velbus network to any other
suite — the health data travels out over syslog, entirely separate from
the CAN/Velbus data itself staying properly isolated.
The pitch, for hotel and apartment designers
Every room, its own island. One dashboard, every room’s health.
Segment isolation isn’t a compromise here — it’s the whole point. Each
suite’s Velbus network is deliberately never bridged to any other, so a
compromised or misbehaving device in one room can never reach another
guest’s network. At the same time, every gateway reports its own health
— CAN bus status over a network path that’s independent. With Velbus power supply voltage and current, hours-in-service
against a 10-year design life, accessible over
the wired Ethernet it’s also using, so a damaged cable or a dead
switch port doesn’t silence the alarm along with the data.For building management, that adds up to a single central view of
every room’s system health, with per-suite logins giving individual
guests or unit owners visibility into only their own space — security
and oversight, without compromise on either side.
Central management software — what’s actually available today
The pitch above assumes a central system that can hold many isolated
segments’ data while giving each one its own sandboxed view — worth
being precise about which platforms genuinely do this natively, since
the three most commonly discussed options handle it quite differently.
Home Assistant and openHAB are fundamentally single-site tools. Each
is designed to run as one instance managing one home or building.
Getting a combined, multi-site view is a bolt-on pattern, not a built-in
feature — Home Assistant’s community remote_homeassistant integration,
for example, works by having one “central” instance poll each remote
instance and pull its states in, and openHAB users solve the same problem
the same way (a central instance periodically checking each site’s own
instance). Neither platform has a native concept of a fully isolated,
separately-logged-in tenant view the way this hotel/apartment scenario
calls for — a combined dashboard built this way tends to show everything
it’s polled, not a sandboxed slice per tenant.
OpenRemote is architected differently, as a genuinely central
multi-tenant platform. Its core concept, Realms, gives each
tenant — each hotel suite, each apartment — full data and user isolation
from every other realm within one running platform: their own users,
their own dashboard, their own branding if wanted, with no way to see
another realm’s data. A superuser can see across every realm at once for
management purposes, while each tenant only ever sees their own. This is
built into the open-source core, not a paid add-on. OpenRemote also has
built-in Velbus protocol support already.
This isn’t theoretical — OpenRemote’s own published case studies include
almost exactly this scenario. Block61, a residential building
project, gives individual tenants their own app and login with full
control over their own home, while the building owner uses the same
platform’s default manager view to monitor every unit’s systems for
maintenance — precisely the “central oversight, per-tenant sandbox” model
described above. (OpenRemote is itself headquartered in Eindhoven, where
Block61 and another of their published projects, Strijp-S smart
lighting, are both based.)
| Home Assistant / openHAB | OpenRemote | |
|---|---|---|
| Typical deployment | One instance per site/room | One central platform for all sites |
| Multi-site view | Bolt-on polling integration | Native (Realms) |
| Per-tenant isolated login | Not a built-in concept | Built-in, core feature |
| Central admin overview | Aggregated from polled instances | Native superuser view across all realms |
| Native Velbus support | Via community bindings/integrations | Built-in protocol agent |
For a scenario where genuine per-tenant data isolation and a real
central management overview are both hard requirements — not just
nice-to-haves — OpenRemote’s realm model is a more direct architectural
fit than assembling one out of per-site Home Assistant/openHAB instances
and a polling layer.
Getting started
-
Wire the CAN Unit to either:
- The AtomS3 Lite Grove port (default), or
- The Atomic PoE Base solder pads
You choose which one in the web portal — see CAN Bus settings
below. No need to touch the firmware or recompile for this. -
Power the gateway via PoE (if using the Atomic PoE Base) or USB.
-
Find its IP address. On first boot with Ethernet connected, the
gateway gets an address via DHCP. If you have a serial monitor connected
(115200 baud), the IP address, web portal PIN, and CAN pin assignment are
all printed clearly at boot — see Serial monitor at boot.Without a serial monitor, check your router’s DHCP client list for a
device namedvelbus-gw-xx(or whatever you’ve renamed it to). -
Open the web portal at
http://<gateway-ip>/and log in with the PIN
(default:1234— change this, see Device settings). -
Choose Server or Bridge mode — see Operating Mode
below, and pick whichever matches your use case from the examples above. -
Set the CAN bus mode. On first boot, CAN is deliberately left
stopped until you tell it what speed to run at — see
Bus speed detection wizard. -
In Server mode, point VelbusLink (or your software of choice) at the
gateway’s IP and port (default6000). In Bridge mode, the gateway
connects outward on its own — point VelbusLink at the central PC-based
server instead, not at the gateway.
Web portal
Reachable at http://<gateway-ip>/. Protected by a PIN (not a username).
Operating Mode
A single dropdown at the top of the CAN Bus section:
- Server — serve VelbusLink locally. The gateway runs its own Velbus TCP
server. Shows the TCP Server port field. - Bridge — connect out to another Velbus TCP server. The gateway runs
no server of its own at all, and instead connects out as a client to a
remote Velbus TCP server (see use case 2 above). Shows the Remote host
and Remote port fields instead.
Only the fields relevant to the selected mode are shown — switching the
dropdown reveals/hides them immediately, no page reload needed. Saving
restarts the gateway to apply the change.
CAN Bus
- Which port is the CAN Unit on? — Choose “AtomS3 Lite Grove port” or
“Atomic PoE Base”, matching wherever you’ve physically connected the CAN
Unit. Saving this restarts the gateway and applies the correct pins
automatically — you never need to know or enter GPIO numbers. - Mode —
Auto-detect,V1 - 16K6 (fixed),V2 speed (fixed), or
CAN FD (fixed).- Auto-detect leaves the CAN interface stopped until you run the
detection wizard. This avoids a crash
that occurs if the CAN driver starts with no bus physically connected. - V1 is the original Velbus speed (16,666 bps) and is correct for
almost all existing Velbus installations, including networks that mix
old and new module generations. Per Velbus themselves, the higher V2.0
speed is only used automatically across an entire installation if
absolutely no older hardware is present anywhere on that same physical
bus — so even an all-new-generation network may still run at 16.6K. - V2 and CAN FD speeds are configurable but not yet confirmed
against real Velbus V2.0-only hardware — treat as experimental until
tested on a genuinely V2.0-only network.
- Auto-detect leaves the CAN interface stopped until you run the
- V1 / V2 / CAN FD Speed (bps) — the actual bit rate used for each mode.
Only change these if you know the exact speed your network requires. - Enable CAN FD — leave off unless you specifically have CAN FD hardware.
TCP Server (Server mode only)
- Port — the port VelbusLink (or other software) connects to. Default
6000. No authentication or encryption on this connection — treat the
gateway as living on a trusted network, not exposed to the internet.
Bridge Settings (Bridge mode only)
- Remote host — the IP address of the PC-based Velbus TCP server this
gateway should connect out to. - Remote port — the port that server is listening on (matches its own
configuration, commonly6000).
Network
- WiFi SSID / Password — optional fallback if Ethernet isn’t available.
Ethernet is the primary and recommended connection method. If Ethernet
hardware isn’t detected at boot, the gateway waits up to 15 seconds for
WiFi to associate before continuing startup.
Diagnostics
- Enable debug logging — turns on detailed per-packet tracing, visible
at/log(see below) and over serial if connected. Leave this off
during normal operation — every logged line is time not spent handling
real Velbus traffic, and on a busy bus this can cause dropped frames.
Only turn it on when actively troubleshooting, and turn it back off
afterwards.
Device
- Device name — shown in DHCP client lists and on the login page.
- PIN (4–8 digits) — the web portal access code. Change this from the
default. Leave blank when saving other settings to keep the current PIN.
Syslog
Optional remote monitoring — lets any gateway (Server or Bridge mode) send
plain UDP syslog messages to a central server, so you don’t need to
individually check each unit’s own /log page to know its health.
- Enable syslog reporting — off by default.
- Server address — the destination syslog server’s IP address. Only a
literal IP is supported, not a hostname (avoids any dependency on DNS
being configured/reachable, same reasoning as the Bridge mode connection). - Server port — default
514, the standard syslog port. - Minimum interval between transmissions (seconds) — how often routine
heartbeat messages are sent. This does not apply to faults or
connection events — see the table below. - Only send heartbeats when CAN bus is dormant — if ticked, routine
heartbeats are skipped unless the CAN bus has been quiet for at least
750ms. Fault and connection messages are never affected by this setting.
What gets sent, and when:
| Message type | Timing |
|---|---|
| Heartbeat (“alive, uptime, CAN speed…”) | Respects the minimum interval, and the dormant-only setting if ticked |
| CAN bus-off / recovered / error-passive | Always sent immediately, ignoring both settings above |
| CAN bus errors (bit/stuff/form/ACK) | Summarized and sent every 2 seconds while occurring, rather than one message per error |
| TCP client connect/disconnect (Server mode) | Always sent immediately |
| Bridge connect/disconnect (Bridge mode) | Always sent immediately |
The reasoning: routine status updates can wait and repeat harmlessly, but
knowing the moment a fault occurs, a client disconnects, or the bridge
itself drops its connection to the central server is important enough to
never be delayed.
Design notes, in case the behaviour looks unusual:
- No timestamps are included in the messages — this device has no
clock (no RTC, no NTP sync), deliberately, to avoid the same
WiFi/lwIPconfigTime()problems encountered on an earlier project.
Your syslog server will stamp each message with its own arrival time,
which is normal, accepted practice. - No authentication — this is plain, unencrypted UDP, the same trust
model as the TCP connection and the web portal. Suitable for a trusted
internal network only. - UDP, not TCP, is deliberate — it’s fire-and-forget by design. A
syslog server being briefly unreachable will never block or slow down
CAN processing, unlike a TCP-based reporting connection would.
Send Test button — sends one test message immediately, using whichever
syslog settings are currently saved (not unsaved changes still sitting in
the form — save first if you’ve just changed the server address). In
addition, the gateway automatically sends four test messages a few hundred
milliseconds apart shortly after every boot, regardless of whether anyone
ever presses the button — a safety net given the web portal can
occasionally become unresponsive.
Syslog transport — which network path reporting uses
Set under Syslog → Transport. This is an installer choice, and it
matters more than it first appears: a gateway that reports faults over the
same wired link that just failed cannot report that fault.
| Setting | Behaviour | When to choose it |
|---|---|---|
| Auto (default) | Reports over Ethernet while the wired link is healthy. If the Ethernet link drops, the gateway automatically raises WiFi and continues reporting over it. Returns to Ethernet when the link is restored. | Almost all installations. Keeps everything on the wired network until the moment it can’t be. |
| WiFi only | Always reports over WiFi, from boot, regardless of Ethernet. A permanently independent path. | Where reporting must never share a path with the data it monitors, and a detection delay is unacceptable. |
| Ethernet only | Never brings WiFi up under any circumstances. If the wired link fails, reporting simply stops. | Sites with no WiFi coverage, or where policy forbids a second radio. |
Auto and WiFi modes need a WiFi SSID configured under Network. If none
is set, the gateway logs that syslog wanted WiFi and carries on without it
— it will never bring up a radio you haven’t configured.
Why Auto is the default, and the useful side effect. Under Auto the
gateway stays entirely on the wired network while that network is
healthy — nothing extra is exposed, and the radio stays off. It only
reaches for WiFi at the point the wired path has already failed, which is
exactly when you need it most.
There’s a second benefit worth designing your monitoring around: a
gateway raising its WiFi is itself an alertable event. Your wireless
infrastructure will see a new association from a device that normally
never appears on WiFi at all. That gives a network engineer an early
warning of a wired-path failure that is completely independent of the
syslog message it’s carrying — a second, separate signal for the same
fault. Worth setting an alert on.
Detection timing. The Ethernet link is polled every 2 seconds with a
5-second debounce, so a brief switch renegotiation or cable reseat won’t
cause a flap. A genuine failure therefore takes a few seconds to trigger
the WiFi raise, plus normal WiFi association time. If that gap is
unacceptable for a given site, use WiFi only, which has no detection
delay because the path is already up.
Note for anyone who saw earlier documentation: previous versions of
this guide stated that syslog had to be routed over WiFi, because an
active syslog socket could not coexist with the Velbus TCP server on
Ethernet. That was a real problem, but it was caused by a library setting
limiting the gateway to just two network sockets in total. That limit has
been corrected — syslog now works normally over Ethernet alongside a full
complement of Velbus clients, and the transport is a free choice rather
than a workaround.
Bus Speed Detection Wizard
A guided, on-screen process: click Start Listening, then press any
button or operate any device on the physical Velbus bus. The gateway
listens at 16.6K first, and if nothing is heard within the timeout, tries
the configured V2 speed. Once it detects clean traffic, confirm and save —
this sets the CAN mode to whichever speed was detected and restarts the
gateway.
Log viewer (/log)
Shows the last 60 log lines, kept in memory (not written to flash). Useful
for a quick look at recent connection events and (if debug mode is on)
packet-level detail, without needing a serial cable connected.
Serial monitor at boot
If you have a USB cable connected and a serial monitor open (115200 baud),
the gateway prints, in order:
======== VelbusCANGateway 0.3.1 =======
[INIT] Serial OK
[INIT] NeoPixel init done
[INIT] Starting LittleFS...
[INIT] Config loaded. debug=0 canMode=v1
[INIT] Creating CAN TX queue...
[INIT] Starting Ethernet...
[ETH] IP: 192.168.x.x
[INIT] Starting Velbus TCP server... (Server mode)
-- or --
[INIT] Bridge (client) mode — Velbus TCP server disabled (Bridge mode)
[INIT] Starting web server applet...
IP Address is: 192.168.x.x
***** Web portal access PIN is: 1234 *****
CAN TX pin is: GPIO2, RX pin is: GPIO1 (grove)
[CAN] Running @ 16666 bps
[INIT] Setup complete
In Bridge mode, this is followed by connection attempts to the configured
remote server:
[BRIDGE] Connecting to 192.168.x.x:6000...
[BRIDGE] Connect OK
After boot completes, serial output stops entirely (a banner confirms
this), even for CAN traffic. This is deliberate — every serial print costs
time that could otherwise go to reading the next Velbus frame off the bus,
and on a busy network this risks dropping packets. If you need to see live
traffic for troubleshooting, use debug mode (via the web portal) and
the /log page instead of the serial monitor.
Note: the boot output includes the web portal PIN in plain text. This
is convenient for initial setup but means anyone with a serial monitor
connected to the device can read the access code. Bear this in mind if
you hand a unit to someone else while USB is still connected.
LED status indicator
Four onboard RGB LEDs show gateway state at a glance:
| LED behaviour | Meaning |
|---|---|
| Solid RED | Booting |
| Flashing RED | Fault — CAN error, or no bus connected |
| Slow pulse WHITE | Bus speed detection wizard running |
| Slow pulse GREEN | CAN running, no TCP clients connected (Server mode) |
| Steady GREEN | CAN running, one or more TCP clients connected (Server mode) |
| Bright GREEN flash | Live CAN bus activity (flashes briefly over whichever state above is active) |
| Solid BLUE | WiFi AP config mode active |
| Fast ORANGE flash | Syslog was automatically disabled after repeated send failures — check the syslog server address and port in the portal. Clears on next reboot. |
Physical button
Located on the AtomS3 Lite body.
-
Long press (3 seconds) — toggles WiFi AP config mode on/off. This is
the way back in if you’ve lost network access to the gateway: join its
own WiFi hotspot (SSIDVelbusGW, passwordvelbus123) and browse to
the address it reports on the serial monitor, normally
http://192.168.4.1. The full config portal is served over the hotspot,
exactly as it is over Ethernet — so you can correct a wrong operating
mode, a wrong bridge address, or anything else that locked you out.The LED goes solid blue while AP mode is active.
-
Press again (long press) to exit AP mode, or use Logout in the web
portal, which also exits AP mode automatically.
Known limitations / things still being worked on
- No TLS/encryption on the TCP connection (port 6000) or the web portal.
Suitable for a trusted local network; not intended to be exposed directly
to the internet. - Maximum four simultaneous Velbus TCP clients. This is a deliberate
hard cap, sized to the gateway’s available network sockets alongside the
web portal and syslog. Four covers the intended use comfortably (for
example: two VelbusLink instances, Node-RED, and a bridged second
gateway — a combination confirmed working). A fifth client is cleanly
refused; it does not disturb the existing four. - V2 and CAN FD speeds are placeholders, not yet confirmed against real
Velbus V2.0 hardware. V1 (16.6K) is correct for effectively all current
installations. - Syslog delivery is best-effort (UDP), not guaranteed. A message can
occasionally be lost in transit — a deliberate trade-off, so that syslog
reporting can never block or slow down CAN processing. Everything sent
over syslog also still appears in the local/logpage and Serial
output regardless. - WiFi-only syslog transport keeps the radio on permanently, which
means slightly more power draw and heat in a sealed enclosure, and
requires WiFi coverage wherever the gateways are mounted. The default
Auto transport avoids both, at the cost of a few seconds’ detection
delay before it switches over. - A shared WiFi network for syslog is a shared path. If several
otherwise-isolated gateways all report over one SSID, that WiFi touches
every unit. The traffic is outbound UDP monitoring only, so exposure is
small — but it is worth being deliberate about, particularly in
multi-tenant installations where the wired networks are deliberately
kept separate. - The WiFi AP config password (
velbus123) is fixed in firmware, not
configurable via the portal, and is the same on every unit running this
firmware. Anyone who knows it can join a unit’s AP hotspot while it’s
active. Worth keeping in mind for how you physically deploy units — the
hotspot is only active while explicitly toggled on via long-press.
Quick troubleshooting
VelbusLink connects but sees no traffic (Server mode):
- Check CAN wiring matches the port selected in CAN Bus → Which port is
the CAN Unit on? - Check CAN_H/CAN_L aren’t reversed at the screw terminal.
- Confirm CAN mode isn’t stuck on “Auto-detect” with no bus ever detected —
run the detection wizard.
Bridge mode won’t connect:
- Check the remote host/port in Bridge Settings carefully for typos.
Only a literal IP address is accepted, not a hostname. - Confirm the target really is listening: another gateway in Server
mode, or a PC-based Velbus TCP server. - Check the boot log /
/logpage for[BRIDGE] Connect OKorFAILED. - Repeated
Connect FAILEDwith a roughly 1.6-second gap between attempts
usually means the target address isn’t answering at all on the network —
check the IP is right and the machine is reachable.
A client won’t connect (Server mode):
- Check how many are already connected. The cap is four; a fifth is
refused. The/logpage shows current connections. - Note that VelbusLink briefly opens two connections each time it
connects, so it can momentarily use more than one slot.
Web portal unreachable:
- Confirm the gateway has an IP (check your router’s DHCP list, or connect
serial and check boot output). - Long-press the button to bring up the WiFi AP (
VelbusGW, password
velbus123) and browse tohttp://192.168.4.1. The full portal is
served over the hotspot, so this works even with Ethernet completely
disconnected.
The gateway has unexpectedly appeared on WiFi:
- Under the default Auto transport this is intentional and is a
warning sign: it means the gateway lost its Ethernet link and raised
WiFi so it could keep reporting. Check the wired path — cable, patch
lead, switch port, PoE injector. - The serial/
/logoutput records it as
[WiFi] *** RAISED FOR SYSLOG ***followed by[ETH] Link DOWN. - If you don’t want this behaviour at all, set Syslog → Transport to
Ethernet only.
Syslog isn’t arriving / the LED is flashing orange fast:
- The gateway disables syslog automatically after repeated send failures,
to protect normal operation. The orange flash is that indication. - Check the server address and port in the portal, confirm something is
actually listening on that UDP port, then re-enable syslog and save.
Forgotten PIN:
- Reconnect via serial and power-cycle the gateway — the PIN is printed at
boot.
… As tempting as that is…