Velbus and the CANBus standard

How closely does Velbus follow the CANBus standard (ISO 11898-1) ?

The reason I ask is that I have some legacy control modules that communicate over CANBus and I’m looking at reprogramming them to work on a Velbus network.

The ISO standard shows a Differential Return to Zero bit stuffed physical layer with a the link layer having 4 fields (see below) that differ from the protocol shown at the Velbus github page.

Does this mean I ignore the built in CANBus controller, or is the Velbus 6 Bytes + N sent as a part of the data field using some type of a multi part message ?


ISO 11898-1 defines the following parts of a CANBus message:

  1. the Arbitration Field, which determines the priority of the message when two or more nodes are contending for the bus. The Arbitration Field contains:
  • For CAN 2.0A, an 11-bit Identifier and one bit, the RTR bit, which is dominant for data frames.
  • For CAN 2.0B, a 29-bit Identifier (which also contains two recessive bits: SRR and IDE) and the RTR bit.
  1. the Data Field, which contains zero to eight bytes of data.
  2. the CRC Field, which contains a 15-bit checksum calculated on most parts of the message. This checksum is used for error detection.
  3. an Acknowledgement Slot; any CAN controller that has been able to correctly receive the message sends an Acknowledgement bit at the end of each message.


There are a few people doing their own funky things on top of Velbus.

Have a search of the forum, you’ll find a few.


1 Like

Pretty closely to CAN2.0A.
Those four fields are used the same way. Velbus packs it’s ID and priority bits onto the same 11-bit identifier. Smaller 8-bit Velbus address appears shifted but is completely compatible.

You do need to do the proper CAN CRC (hardware controllers will do this for you and you effectively never see the CRC at all). And your DO need to do the ACK when receiving (a hardware controller will do this for you also).

Watch out for bit rate timing… if you are too far off then you may just occasionally drop bits only when you have several successive 1s or 0s which can make it hard to see what is going on.

I have managed to get several CANBUS controllers talking to Velbus fairly easily :-

  1. cheap MCP2515 SPI-bus modules
  2. ESP32 WROOM, DEVkit4, S2, and S3.
  3. STM32 F103 and F072 (the F072 can even do USB device at the same time)
  4. A custom pure-software implementation on 8-bit Arduinos. (Not complete but working OK).

The MCP2515 boards with an Arduino are a very easy way to start and get your head around everything. Try starting with listen-only attached to a working velbus test-rig with eg. just a pushbutton and a relay or dimmer.
I had a little bit of trouble with common ESP32 WROOM modules because they only just support the low baud rate but folks on here helped me out. The S2 and S3 versions were fine though.

My software version on Arduino does not passive sync on bit/frame starts when it is not sending or receiving on a busy bus. ie. it starts its bit timing arbitrarily when you TX rather than syncing with whatever arbitration frames are starting at the same time. I think that is just an inevitable software limitation that older Velbus nodes probably have too. It should not matter unless the bus is very busy in which case the only consequence is that a higher priority transmit cannot so easily override a lower priority one starting at the same time. You can still mostly detect busy-collisions and back down though.

As mentioned above, Velbus receivers DO use the ACK field so if your receiver is the only device on the bus and you do not send an ACK the Velbus transmitter will retry some dozens of times. Just watch out for that one if you try to run your receiver in listen-only mode and there are no other receiving devices to send the ACK.

Other than that it’s just a matter of adjusting the bit timing a little since 16K6 is not a standard CAN bit rate. Datasheets for the various controllers will have info on this but they all seem to be pretty similar. Most software libraries use tables for this so you can just add another entry to the table.

There is lots of CAN info on the net but the original Bosch Protocol Standard is a very clear and useful reference and is readily available from NXP(ex Freescale), just google for BCANPSV2.PDF. That doc fairly easy to read side-by-side with a datasheet for your choice of controller.

You can not only transmit and receive Velbus but of course once on the bus it is also very easy to use the connection between your own nodes to send your own custom data that velbus will ignore… so I can use the Velbus cable to send my own data all over my house :slight_smile:

What I have NOT tried to do (but user matthijsfh on here has done, with STM32) is to emulate an existing Velbus device. So my attempts are not recognised and programmed by VelbusLink, I just set them up hardcoded in my firmware.


Thanks for those links. I can now see that Velbus is a higher level protocol sitting on top of the CANbus, in a similar way to how CANopen sits above the Physical/Link layers of the bus.

It is nice to know that the system is open enough that some custom devices can be included. How would they be configured though - is there an API for the Velbus link software, or instructions on how to add custom devices ?

I have previously worked with LonWorks which provided specs on device definition files (*.xif) that contained the details of the device capabilities and binding options. This allowed the configuration software to present the correct options at setup time. See

1 Like

That’s useful - thanks. From some of the other links I’ve been sent I can see that internally those values are mapped across to the CANbus bit stream that the controller sends to the network.


No, that’s never going to be possible.

While Velbuslink is fabulous, you can’t add your own modules to it.


Because every module transmits updates and status’ to the bus, you only need program your own things to react or send an instruction.

You can’t configure Velbus modules to react to your homebrew kit, because Velbuslink doesn’t know about them.

Unless you do something like adding a virtual module in Velbuslink and configure with that.

I’ve never tried this, but it might work … Maybe

You can’t configure Velbus modules to react to your homebrew kit,
because Velbuslink doesn’t know about them.

It is fairly easy to make a homebrew custom module generate or respond to button presses.
So as long as you have a velbus input module (like a VMB8PBU for example) in the system then you can have a custom module generate those same 8 different button presses. So you can sort of still use velbuslink to program things to respond.

I have hundreds of spare (unused) pushbuttons in my system because every lightswitch has an 8-button encoder in it, even if I only use 2 or 4 pushbuttons from it. So I can still use VelbusLink to set things up for the other unused buttons and then have my own hardware also generate those same button presses.

But otherwise yes, unless you try emulate an existing velbus module then you have to just set the inputs and outputs in your firmware… VelbusLink won’t connect them up to things for you.

The commands that the Velbus V1 modules use are all published and decently documented. And VelbusLink has a log window where you can see the commands on the bus. Most real Velbus modules actually generate and respond to quite a lot of commands though (eg. the pushbuttons also respond to LED commands and the dimmers can send them commands to set their LEDs into various states to indicate what is going on). VelbusLink hooks all these things up by telling them about each other. That does not stop you making something that JUST generates pushbutton signals or JUST responds to pushbutton signals. You do not have to do all the other stuff if you only want something simple.

It’s been fun to play with just for learning CAN, but I note that the last time I actually wanted to do something custom on Velbus I ended up just connecting an arduino directly to a spare VMB8PBU so it can generate 8 different button presses and I can still set everything up in VelbusLink.

Unless you do something like adding a virtual module in Velbuslink and configure with that.

Oh! Yes, that seems to work, at least it does for virtual pushbuttons… ie. you add an input device that is not really there and then configure things to respond to that. And they work!
You do get warnings that “There are undetected modules in this project. Have you already scanned?” but otherwise it does seem to work.