Hi Bart.
Are you using the free / demo version?
It is most certainly in the Pro version.
Cheers,
Stuart
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.
Greetings,
Bart
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 
Hello again 
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 
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).
Jeroen
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,
Stuart
MDAR Ltd
Hi
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?
Cheers,
Stuart
Hi,
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.
@jeroends
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
Solution/workaround:
- 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ā¦
Thanks!
Jan
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,
Thanks!
Will definitely test with a different USB cable.
Hope this will solve the issueā¦
I will let you know!
FYI
The above mentioned ASUSTOR packages are ready:
velserv_1.5_x86-64.apk
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 ?
https://groups.google.com/forum/m/#!forum/openremotecommunity
Many thanks,
Stuart
FYI
https://groups.google.com/forum/?nomobile=true#!topic/openremotecommunity/fu66o4XBxW0
Hope this proves useful!
Kind regards,
Jan
1 Like
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,
Stuart
Hi @MDAR,
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.
Thanks!
Jan
Jan,
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.