intergration with Velbus - Free to ALL


Hi Bart.

Are you using the free / demo version?

It is most certainly in the Pro version.



Ah indeed, I’m not using the designer version, since i can’t find velbus among the other predefined manufacturers.
Signed up now, awaiting the activation mail.



I finally got around to test this and after quite some problems i did get it to work with controller v2.5.0.

With v2.6.0_beta i was constantly getting the “Could not load commandBuilder class: org.openremote.controller.protocol.velbus.VelbusCommandBuilder” in boot.log
When i downgraded the controller i also updated and upgraded my rpi, so that may have something to do with it, need to do some more testing here.
What controller versions are you using btw?

Anyway, i got a relay and a dimmer working (with switch & slider) so i’m pretty pleased :smiley:


Hello again :slight_smile:

I’m very glad that you’re getting some results with OpenRemote and Velbus.

Just wait until you start investigating the possibilities with Thermostat functions :wink:

For your reference, I have a number of machines running OpenRemote controllers, with various core Linux OS versions, but they all use OpenRemote-Controller-Pro-V2.5.0.

I should do some testing with V2.6.0 beta, but I just don’t have the time right now.

If your interested, my machines are :-

Samsung N150 1.6Ghz Single Core netbooks
BeagleBone Black 1.0Ghz Single Core SBCs
ODroid XU4 1.0Ghz Octo-Core SBC (curiously no faster than the BeagleBones)

FYI, I originally tried Windows 7 home starter on the Samsung Netbooks, which worked well but were noticeably slower than Ubuntu 16 LTE headless server Linux OS on the same machines.


Hello MDAR,

do you have any idea when or if the older velbus modules will be supported? My installation does only have the older modules (runs since 2008).



Hi @jeroends

Thanks for following this topic and providing your VelServ TCP server to the community.

As I’m sure you’re aware, the older modules use very different memory maps compared to the 2nd generation modules.

It’s not impossible to add the older modules, just a lot more involved than the new ones, which is why it hasn’t been done so far.

The situation is that MDAR Ltd formally pays a commercial programmer to do this work, so until we are in a situation where it is essential for a commercial project, we don’t have any plans to make Velbus within OpenRemote compatible with the older modules.

That said, as I’ve suggested in previous posts, we are all willing and keen to add these modules, it’s simply a matter of funding the programming time.

Would you be willing to provide a list of the modules you’d like to see added so we could cost the work.
(The other important issue is that we don’t have access to older modules to test with)

I hope you understand the difficult position we’re in.

Please send me a direct message if you’d like to take this conversation further.

Best wishes,




I’ve got some interesting news for you…

I’ve been authorised to offer a limited amount of people a very cost effective upgrade price, if you want to swap out 1st generation modules for 2nd generation or integrated modules, for the sole purpose of creating an OpenRemote compatible Velbus system.

For reference, we’re added support for the VMB1TS to make life a little easier.

Does this help you at all?





Just started to experiment a bit with OpenRemote - using a NAS (Asustor) as gateway.

First and foremost: got it to work - quite easily.
@jeroends @MDAR - kudos

To me it’s just a small hobby project - will see where/when it ends…

In order to keep everything alive as best as possible, I’m planning to create Asustor packages for both the velserv ‘gateway server’ and the OpenRemote Controller.

All in all, creating these packages doesn’t seem to be too difficult - just a bit tedious.
I created a first velserv_1.5_x86-64.apk which does the job.

I did encounter 1 issue: re-starting the velserv sometimes results in the usb (serial) device not being accessible anymore: dmesg error message:
cdc_acm 1-2:1.0: failed to set dtr/rts


  • stop the velserv process
  • disconnect the usb cable
  • wait
  • re-connect
  • verify whether the Velbus usb device is re-connected (lsusb) and
  • start the velserv once more

dmesg log:

usb 1-2: USB disconnect, device number 3

usb 1-2: new full-speed USB device number 5 using xhci_hcd
usb 1-2: New USB device found, idVendor=10cf, idProduct=0b1b
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-2: Product: VMB1USB Velbus USB interface
usb 1-2: Manufacturer: Velleman Projects
cdc_acm 1-2:1.0: ttyACM0: USB ACM device

Does this issue ring a bell?
I did find quite some references on the internet related to similar issues, but didn’t dig deeper.

Any info would be appreciated…



Hey Jan, this idd ring a bell.

A few years ago I had a problem with a bad USB cable running through the electricity closet and causing emi problems on the USB (thats what the driver stated). This was causing a half disconnect, in this I mean, the system thought the interface was connected (ttyacm was alive) but there was no data traffic possible.
In the end I enede up writing a script checking for a defined module, if I couldn’t reach that module I re-enumerated the usb modules (event) and then the interface came back alive.

The problem went away using another USB cable so I never searched for another solution.


Hi @jeroends,

Will definitely test with a different USB cable.
Hope this will solve the issue…

I will let you know!



The above mentioned ASUSTOR packages are ready:
openremote-controller_2.6.0 beta3_any.apk

Actually, both were quite easy to create as it’s not required to take care of any ‘upgrade’ aspects.
Whenever a newer version needs to be installed, the previous version can just be deleted.

Definitely true in the context of the velserv, but I assume this is also valid in the context of the OpenRemote Controller: whenever a new version is deployed, your OpenRemote Designer workspace needs to be synced once more, and that should cover it…
Well, that’s at least my experience so far.



Thanks for all this information.

As I’m sure this would be really useful to anyone who is going to work with OpenRemote, could you put this information on the Google Groups OpenRemote page ?!forum/openremotecommunity

Many thanks,


Hi @MDAR, @jeroends,


Hope this proves useful!

Kind regards,


Good morning @jan_b

Thanks for putting that post on the Google site.

Just one tiny observation, Velbus has been supported in OpenRemote Pro for a couple of years now, with the very latest Jar file used in the stable version (OpenRemote V2.5) and the beta version (V2.6).

This information might be useful if you discover any issues with the beta version.

Good luck,




Yes, true - I thought the V2.6 beta automatically included the latest Velbus integration (and that’s what I was trying to explain), but upon a short review it’s not even the latest 1.3.1 but still a 1.3.0.

I’ll try to clarify this on the Google forum too.

A stable OpenRemote-Controller V2.5 with Velbus 1.3.1 would’ve made more sense.



a smal remark. The story I mentionned was about myself having an usb bus that locked up due a bad usb cable.
When you disconnect the cable without closing the bus, meaning, velserv still has the ttyacm0 open, a new interface (mostly ttyacm1, or higher) will be created because ttyacm0 is still open.
I used the script in the link to recreate the interface after trouble. Maybe it 's an idea to create a script checking an interface on the bus who you know it’s there. If that’s not reachable after for ex 3 times, than there most be a problem an the script can be executed.

script: velbus This script was used on a redhat system so it could be that it needs to be adjusted to be used on a debian system.