More open alternatives to KNX?

In progress of building a house and have been investigating home automation ecosystems. Broadly my requirements are, in order of priority:

  1. Wired or mostly wired for core functionality (e.g. I don’t care if blinds stop working once in a while but lighting, heating and HVAC must be rock stable);
  2. Must be decentralized (i.e. no cloud; I’ll have a home server, but would rather things continue working when that inevitably goes down too);
  3. Either cheap or extensible with proper planning.

And so KNX appears to be like a good option, but it isn’t cheap. What really doesn’t sit right with me about KNX, though, is the encrypted component database and proprietary Windows-only tools. Seems like a weird place to spend some inconvenience points at. Especially given that I’m a software engineer and tinkerer by profession, so I will definitely want to fiddle with the automation extensively and craft my own components too.

As thus, are there any alternatives to KNX that are more open to tinkerers?


If this isn’t an invitation for me to bang on about how amazing Velbus is then I don’t know what is. :smile:

If you search this forum for Velbus, you’ll see plenty of my cheerleading for it, as well as plenty of good news stories from other people.

While the binding is still a work in progress, the current .jar version file is pretty amazing. (As opposed to the version that gets installed from the OH bindings repository, which is still good, but missing lots of good things)

There is also lots of support available in the Velbus forum, but don’t be put off by the lack new threads, this is because the stuff just works.

1 Like

KNX is the only wired, at least somewhat open system. It’s well-defined and you have a choice of vendors. The only annoying thing (beyond pricing) is the habitude to make money with licensing and certifications only to electrician “experts” (duh!), depriving the public of specifications and documentation, leading to a need to use a proprietary admin software to setup the system.
Then again, you won’t need that any more once you equipped your devices with addresses and OH gets in charge of control.
The remainder of systems on the market, albeit often cheaper, are proprietary. Only interoperable with themselves, so you have to buy everything from that vendor, with all the other risks associated to proprietary systems (lack of bugfixing and support, hidden cost on expansions/upgrades, vendor to abandon products or to go out of business etc etc).

What’s the physical medium used for Velbus? Wasn’t able to find information on that. An ideal answer here would link to a specification that includes a description of a protocol used over that medium.

Also, are there any other vendors who produce velbus-compatible hardware? A fair amount of value proposition for KNX is that your preferred manufacturer can go bankrupt, pivot into beer making or whatever else it wants and you still would be able to buy compatible components from somebody else.


If these are deal breakers for you, then Velbus isn’t the answer you’re looking for.

Other answers you’re looking for can be found in these links —


Part 1: Hardware and Cabling

Part 2: Configuration

Specific technical documentation is available via links at the bottom of each module page, including a FULL protocol use explanation for that module.

The protocol is fully documented, which is why it’s been incorporated into OH and other platforms. (To differing levels)

Well, they aren’t necessarily deal-breakers, but it will necessitate looking into velleman more deeply, which is a different kind of pain in the back end.

1 Like

I’m certain the effort now will pay off.

Prior planning and preparation etc etc

If there are any questions you have about Velbus, please feel free to ask, either here, or via a PM.

I’ve been planning to play around with Velbus over the winter and so was looking to obtain a set of few basic modules or perhaps even the starter pack (though the latter seems just tad a bit too pricey for an experiment).

Alas, any attempts to get to a list of distributors eventually end up at which turns out to be a black-hole so far – I have failed to receive a response to any sort of query made through it.

So I took it upon myself to find some any sellers and so far I have managed to find:

Alas anything British is out of question (with the impeding doom of Brexit) and getting stuff shipped from Belgium appears to be an exercise in futility, even with me being fairly flexible in locations where I am willing to ship to (Lithuania, Poland, Germany in that order of preference)

Are distributors really that scarce? Am I using the contact form wrong? How do people obtain these parts outside of Belgium and UK, if at all possible?

Quick question…

Why haven’t you asked me if I can arrange a delivery?

Let me know which modules would you like and I’ll see what I can do.

Thanks for the PM, I’ll see what I can do for you.


A quick update.

I’m told that the Lithuanian distributor should be getting in touch with you soon.

I’ve also queried via that distributor wasn’t being shown in the Velbus sales page.

Good luck,


Well this got me interested, anything CANBUS based allows for very easy tinkering and robust DIY nodes.
@MDAR you seem quite knowledgeable about Velbus, I hope you don’t mind me asking some questions :slight_smile:
Is the full communication protocol publicly available?
Is any communication encrypted?
Does it use some standard high-level protocol, custom one or is it raw single frame messaging?
Based on the 255 addresses with 8 channels each it sounds like it uses 11-bit addresses, is this correct?
If so it would be very cool, then I could use the same bus for extended id communication between my own nodes.
Is the home center capable of configuring nodes or is the logic happening in the home center module?
I’m assuming OpenHAB connects through the home center, is the OpenHAB binding able to configure nodes on the bus or is this only possible through the configuration module and vmb1us/rs?

HI Carl

Very kind words indeed.

I’m as knowledgeable as needed for a distributor and configurator :slight_smile:

One tiny detail before we go any further, although Velbus is “based” on CanBus, it’s not strictly CanBus, so I shouldn’t think you can throw other data on to the bus without being very careful.

Yes, while Velbus are the only company to develop and manufacture Velbus hardware, the protocol is publicly available so that any “Third Party” can develop software to monitor and interact with the hardware.

The links to the GitHub repository can be found on here

Strictly speaking … no.

If you connect directly to the bus via USB or RS232, you’ll get unrestircted access to the packets.

Linux App - VelServ, Windows PB_Server and Velbus’ own Ubuntu SNAP TCP server provide these packets over a TCP connection.

You’ve lost me a bit here, as you clearly know more about this subject than I do.

Every Velbus protocol document starts with an explanation of the packet structure, so I’m sure that will answer your question much better than ever I can.

I wouldn’t recommend it, but… if you are comfortable inserting packets onto the bus and picking them up the other end, then maybe…

HomeCenter is one of those “Third Party” software platforms that connects to Velbus over a USB interface.

It does provide a TCP connection for VelbusLink to connect to, but that connection is encrypted. For which I have no idea how to unlock.

(Think of HomeCenter as an alternative to openHAB2, but without the openness and functionality)

“Normally” operational Logic is contained within the Velbus modules, each listening to bus events and acting accordingly.

This table of Velbus actions might help explain a bit more -

For example -

0201. Dim up/down


Single button control, combining 0204. Dim up and 0207. Dim down. Each time the initiator closes or is pressed, the dimming direction will be opposite from the last one the subject channel has used.

If duration is different from continuous, the dimming channel will be switched off after the timer expires. The timer starts to run as soon as the initiator is released or when the dimming channel reaches 100%.

What “Configuration Module” ?
Do you mean the VMB1RSUB interface module?

That is “only” a USB interface device, so that computers can access the BUS.

Ideally, Velbus modules are configured using the “free” VelbusLink (Windows) software.

Once you’ve got the modules doing what you want, you can then add in openHAB2 to monitor and interact with the Velbus kit.

For example.

Every Velbus glass panel has a very capable HVAC thermostat on board, so you’d use VelbusLink to setup the appropirate actions to control your heating and cooling system.

openHAB2 can then read the current temperature and change the state of the Thermostat, or the current setpoint, change heating or cooling operating mode, change the setpoints of the 8 Thermostat Modes.

Likewise with the other Velbus modules.

Velbus can operate quite happily without a cloud connection or any external software, so HomeCenter, openHAB2, OpenRemote, Cytech Comfort Alarm Panels, Home Assistant, Bezonia { and so the list goes on… } can give a user an extra layer of control, or be used to link an event within Velbus to “A.N. Other” brand device.

Which is what I think openHAB2 does really well.

As a wise man once said,

“Let openHAB2 control the thermostat, not BE the thermostat”

That said…

There are companies out there that use Velbus hardware and don’t use VelbusLink to configure them, other than setting base address’.
They provide a central (software) controller that makes all the decisions.

It’s not an approach I would use / suggest, but it works for them.

I know of one chap (who uses openHAB2) that only has Velbus glass panels as user interfaces around his home and has other hardware for controlling lights etc.
He is very happy with his setup.

There are other people who have fully functioning Velbus installations, who only use openHAB2 to expose the assets to Alexa and Google. (without any kind of UI from openHAB2)

All of the above is why I really like the combination of Velbus and openHAB2.

If you have any more questions, please don’t hesitate to ask.

Likewise, if you’d like a remote connection to a Velbus demo kit, send me a PM and I’ll give you the details.

Best wishes,


Thank you for your extensive answer!

Well in the transport layer you can either stick to standard formats or get shut down :wink:
Here everything is handled by the canbus hardware and if you try to deviate you will generate errors and your controller will shut itself down.
All Velbus modules I checked so far are using standard 11-bit addressing so there is no problem also using the bus for extended 29-bit address communication, according to the standard 11-bit will always have priority so there is no risk of affecting the Velbus installation.
Velbus uses two bits for priority, 8 for the address and the last one is unused, this is not standard, but it is still within standard (that is, 11-bit identifier).

So it would seem custom, but mostly raw :slight_smile:

Yes this is where I found it, thank you :smiley:
Also I must applaud Velbus on how well documented the modules protocols are and how detailed the feedback from the modules is!

How does this work electrically? Does the panel have a relay for signaling a heat source or would is talk to a relay somewhere else on the bus?
It all sounds very nice, especially since I could quite easily add my own sensing and input modules.

I’m starting to regret I just got a Tado system for my summerhouse :sweat_smile:

As far as off-the-shelf components go, I don’t believe panels currently offered have built-in relays. You’ll need a separate relay or get tinkerin’.

Hello :slight_smile:

Once again, thank you for your kind words.

I’ll pass your comment about the documentation back to the team.
It’s always good to hear the effort is well received.

Simonas is (on the whole) correct.

Until the development of the new edge lit glass panels, any physical connection to a device (contact closure, 24v / 240v supply, 0~10v or triac dimming) would be done by one of the Velbus output modules.

For example, a minimum setup might be a Glass panel for user interaction and thermostat, with 2 relay channels. (From whichever output modules you select)

One channel for a light, the other for a heating circuit (be it an actuator or an electric heater).

However, all the new edge lit panels have a tiny 3 pin connector on the rear.

This supplies

  • Bus 0v
  • Bus +ve (~15v)
  • Low Signal output (0v switched)

I’ve got this happily triggering a little Arduino compatible relay.

For situations where someone wants to control a local light or heating circuit.

This output can be treated as a totally separate channel within Velbus.

As for your choice for your summer house…
“Ain’t that always the way”



It’s very possible to use a simple rule or NodeRed flow to map the status of the Thermostat “Heater” channel (for example) to a third party output device.

I know of a situation where a Velbus owner had multiple Velbus glass panels in a room, but no heating circuit.

The simplest solution was to use a cheap TP-Link ‘smart socket’ to switch an electric heater and just map it to one of the Velbus thermostats.

I have been shown another alternative that I’ve missed until now. Out in the plain sight there are modbus-based industrial PLCs and ecosystems around them. You won’t find them by looking for home automation because they aren’t marketed as such…

The components seem cheaper than anything else I’ve seen at the cost of the system being lower-level compared to the likes of KNX or Velbus and perhaps slightly more difficult to expand?

Has anybody experience deploying both such PLCs and either KNX or Velbus? Any opinions on how they compare to the others?

I have Modbus deployed, in a warehouse environment. Primarily occupancy detection and automated lighting inside and out, with enviro & security monitoring as bonus.
No PLCs at all, just digi I/O modules. openHAB provides the smarts.

“difficult to expand”? Not really. The building IP provides a campus network, cheap TCP gateways provide more localized serial services to potentially hundreds of devices.

I would not use this as the core of a domestic setup - simply because dimmers are not readily available. Simple to add as required for on/off interfacing to just about anything though.