I’m considering migrating from openHAB to Homey, but KNX support is crucial for me as I have over 60 KNX devices.
As a senior software developer, I plan to invest in creating missing plugins for devices like my Sonance amplifier, Syr water softener, and Resol VBUS once I make the switch.
In openHAB, the KNX binding offers these features. Which ones are also supported in the Homey KNX plugin?
Splitting the write group address from the read group address
Ability to listen on multiple group addresses
Control of RGBW lights (KNX to DMX)
Support for different addresses for relative and absolute dimming within one device
Polling of KNX sensors that don’t support periodic announcements, such as temperature and light sensors
I just did that migration, and I am not happy. (I actually worked on the KNX Binding for openHAB, but got frustrated with the complexity of the setup in general)
Unlike ZWave, Zigbee or Bluetooth, it is not possible to create custom KNX applications for Homey. Which means you have to make due with what is already there. i.e. I have a thermostat that accepts only a difference between a basevalue and the actual setpoint - which means I have multiple KNX devices that I am putting in a hidden zone, and then using flows to make it all work. Not ideal.
Additionally the KNX connection seems to be very unstable. It is based on KNX/IP and not like my KNX on openHAB which was wired directly to the bus (very stable and quick)
All in all I would not recommend Homey for KNX installations as it stands right now.
Hmm…
Perhaps we could develop our own community version of the plugin using this library as a foundation? This way, we can incorporate additional device types.
The library also emphasizes its focus on robust, self-correcting connections: README-resilience.md
I wish they open sourced that addin. KNX is so specific and they people who use it usually use extensively and in a complex manner. And are usually people who can do a lot.
I have tried to reach the KNX dev on slack and through support, so far no luck.
I am against doing a community replacement, simply due to the double work and compatibility issues that would arise. Also I think the official app actually uses that npm package.
The second approach is what they have done already, sort of generic devices that do one thing, however that would require assembling multiple devices for one physical device (such as a thermostat that has humidity sensor and door/window sensor) also some physical devices does not work in any generic way - i.e. a thermostat that supports changing a setpoint difference from a base value, but outputs the combined value.
Third approach is to do what is done for z-wave and zigbee, basically making very specific “brand name” devices that fit exactly to a physical device
Fourth ( and maybe as an add-on to the other ones) a way to send data directly to the bus via flows and then have the capability to create complex devices via flows (pain in the ass if you have a lot of complex devices)
I am personally leaning towards the “brand name” way.
I believe many vendors produce similar products. A combination of the second and third approaches might be best. However, products can be configured in various ways. For example, a 16-relay actuator can be set up as 16 relays or as a combination of 6 roller shutters and 4 relays, or even some analog sensor inputs that function as relays. Therefore, we need building blocks or a configurable number of inputs and outputs of a specific type? But what is the advantage of combining these into one device?
Relative or absolute dimmers and thermostats could be different generic types?
I’m glad to hear that you are working on expanding KNX. 80% of my house runs on KNX, in addition to solar, heating, HUE, etc. It would be really important to have motion sensors, window and door contacts, and measurements for electricity and air quality. I can’t program myself, but I would be happy to assist with testing.
Thanks in advance!
Status so far is that Homey is engaging and accepting PR’s that is very good news. The first major feature improvement that I am working on is flow cards for sending and receiving telegrams. I realized a lot of my personal specialized use cases would I rather cover in flows that create very specific devices for.
Right now I am testing how to create a specific device for the Vimar Touch Thermostat, the logic will end up being very specific so I find it hard to make a generalized device.
It’s a good day