VelbusLink on linux/macos

I did some homework and looks like currently there is no VelbusLink version for linux/macos. I consider that a shame :slight_smile: as one of the things that pushed me from KNX to Velbus was that KNX requires running windows + using proprietary ETS stuff.

I’m a hobbyist software developer (linux kernel contributor, FreeCAD (*) + some other stuff) and I’d be happy to offer my time for free to help to create VelbusLink that we could compile on linux. I’m not windows/mac specialist, but I assume once we have open source code we would find someone to work on that part.

I’m not expecting that it’ll happen over night, but I’d love to start discussion how we can make VelbusLink for linux reality. What toolkit/language would be preferred by the current team that is writing VelbusLink for windows? What software licence should be used? I assume external contributors wouldn’t have to sign an NDA due to the nature of the project, but potentially, depending on licence they might need to sign some contributor agreement. Is code migration considered, or a start from scratch (my preferred option)?
Again, I’m not expecting a massive progress, but setting some frames would allow to try to gather a team of potential contributors/testers.

(*) FreeCAD supports windows/linux and mac, so I have access to vast team knowledge about writing code that supports 3 systems.

I’m told there is a plan to move Velbuslink to an agnostic programming language so that it can be compiled for other OS.

However I’m sure you’re aware that is a major undertaking.

Hopefully one of the core Velbus team will be in touch directly with you and discuss it further.

If…

UK contractors come to me / us to buy hardware & they only have a MAC, I give them a cheap Windows laptop (subject to their order value)

2 Likes

Docker is the answer.

Instead of a Windows Exec, VelbusLink could be a docker module. That should be agnostic and stable enough.

I have VelbusLink working on fedora linux under WINE / Lutris :heart_eyes:
USB not working yet, so I can’t test anything else now.


Lutris settings:

There are some other topics around this on the forum. It should definitely be possible to run this through Wine, but we don’t actively support that.

Protocol documentation is available from: GitHub - velbus/moduleprotocol: Protocol manuals for Velbus modules
Packet documentation is available from: GitHub - velbus/packetprotocol: Velbus packet protocol

The Signum also has an API available which is documented in the Signum itself.

For a rewrite, since we are backwards compatible, it takes time for us to get there.
We’re looking for web technologies that can be optionally embedded within a multi-platform technology such as Electron, Maui or Tauri.

If you look around on Github, you may find open-source libraries that alread speak the Velbus Protocol.

2 Likes

:heart_eyes: I got it nailed!

  1. Add used to group dialout to allow using USB.
sudo usermod -a -G dialout [username]
  1. Connect the velbus gatewaty. Check the system sees it:
$ lsusb | grep Vel
Bus 001 Device 010: ID 10cf:0b1b Velleman Components, Inc. VMB1USB Velbus USB interface

  1. Check what’s the name of the port under wine:
$ ls -asl ~/.wine/dosdevices/ | grep tty
4 lrwxrwxrwx. 1 przemo przemo  12 04-21 13:30 com33 -> /dev/ttyACM0
  1. Start VelbusLink form lutris (installator file WIP, but the setting as per screenshots in the OP. When the program asks for post type whatever you got in point 4 above. In my case it was com33

There are some visual glitches, but it’s workable:

1 Like

Your welcome to connect via a TCP port to a model here, if you want to test Velbuslink functionality from within Wine.

1 Like

Thank you! I got it (mostly) working :slight_smile: How do you use text file to configure the system? The xlp file is a text, but it doesn’t looks like editing it is a good idea :slight_smile:

P.S. Is it safe to connect a new device to live bus?

I’ll send a PM - thanks!

I think there is a little confusion.

Velbus modules can only be commissioned using Velbuslink.

When I spoke of text files, I was referring to openHAB.

1 Like

That very much depends on your approach.

Clearly, if we apply strict electrical safety rules, then “please power down and isolate everything”

However

If you’re only talking about connecting a module to the bus, then yes, it’s fine, as long as you observe all the normal precautions.

Glass panels are plug and socketed for exactly this reason.

1 Like

lutris-0.5.17 on fedora. I don’t know how to export/import settings into lutris
Edit: It works for me, but I’m struggling with a fresh install of VelbusLink
VelbusLinks works, but there are some visual artefacts.










The more recent installers won’t work due to “could not expand {autopf}”. After some experiments the only way I figured how to work-around that was to decompile the installer[1], modify the innosetup configuration to remove the reference to this variable and recompile the installer again. It is also necessary to create some files for translation strings as the decompilation isn’t exactly lossless.

That said, I’m also seeing visual artifacts. What worked best for me is to use bottles with soda-7.0 runtime and to enable Gamescope. With it the main window renders okay (unlike in sway, where there’s a white opaque window in front of the rendered window behind, just like reported here), but there are still problems with various popup windows. These visual artifacts are likely an unfortunate interaction between the UI library that velbuslink uses and wine, so it isn’t likely that developers at velleman will be able to do much to address this even if they wanted. It would be neat to know what is the library that they are using, though.

Any wine versions past 7.0 series will abort with an assertion in font rendering which I had reported here: https://bugs.winehq.org/show_bug.cgi?id=55518.

Unfortunately, that makes setting up a minimal windows VM roughly the only reasonable option if you want to run velbuslink today.


  1. this is a challenge on its own, as very recent version of inno are used to package velbus and decompilers need to be updated routinely for the more recent versions; and both innounp and innoextract unfortunatelly stopped keeping up. I was able to find some fork out there, but it will likely become outdated soon as well. ↩︎

1 Like