VelbusLink on linux/macos

[PrzemoF]

I did some homework and looks like currently there is no VelbusLink version for linux/macos. I consider that a shame 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.

[MDAR]

@PrzemoF

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.

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)

[pdhoogh]

Docker is the answer.

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

[PrzemoF]

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

Lutris settings:

[VEL524]

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.

[PrzemoF]

I got it nailed!

1. Add used to group dialout to allow using USB.

sudo usermod -a -G dialout [username]

2. 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

3. 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

4. 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:

[MDAR]

@PrzemoF

USB not working yet, so I can’t test anything else now.

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

[PrzemoF]

Thank you! I got it (mostly) working 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

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

[PrzemoF]

I’ll send a PM - thanks!

[MDAR]

@PrzemoF

How do you use text file to configure the system? The xlp file is a text, but it doesn’t

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.

[MDAR]

@PrzemoF

Is it safe to connect a new device to live bus?

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.

[PrzemoF]

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.

[nagisa]

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. ↩︎

[Golfy]

Thanks @nagisa !
I was feeling very uncompetent with multiples tries on Wine, Bottles, Lutris… I’ve the same message. It’s very disappointing to be OS dependant like this

[PrzemoF]

Can you share the solution? Maybe it can be scripted? I’m OK with compiling and that kind of stuff on linux, but I know nothing about windows installers, etc.
From your description I understand we could make script to :

1. download the original binary
2. decomplile
3. modify the code with awk/sed/python/perl whatever is needed
4. recompile

P.S. Sharing the script should be legal, we would not share the recompiled binary.

[MDAR]

Please don’t put too much effort into this.

There is a platform agnostic solution in the pipe line, but it won’t be ready for a year or so.

[nagisa]

@PrzemoF

Can you share the solution? Maybe it can be scripted?

I won’t spend time on this again, but the gist is:

1. Find that one fork of innoextract that has support for the new-enough version of innosetup stuff and extract the installer with it;
2. rg {autopf}and remove instances of this occurring (and/or replace with C:\Program Files or something);
3. Use iscc to find it barfs on locale files;
4. Work some mv and cp magic to make up some locale files;
5. Use iscc again.

As said above, I wouldn’t really bother too much with it as velbuslink nowadays doesn’t work well with Wine anyway.

[PrzemoF]

OK, thank you! I’ll try to do something, but without putting too much effort

[PrzemoF]

innoextract compiled from source, no problem. I do not see anything that looks like autopf yet.

[pdhoogh]

It should be a Velbus supported solution. People are moving away from Windows. I have, Linux Mint is my daily driver. I need to go back to Windows for photo and video editing, but my plan is to run MacOS in a VM and use the MacOS versions of these. As long as there is no Linux version. Luckily, Da Vinci Resolve has a native Linux version. I will NEVER yield to Win11. So Velbus is soon going to be the only reason I’ll be going back to Windows. And as soon as you stop supporting Win10 I won´t be able to use Velbus Link any more. That is a big downer for me.