Well, to be honest, I had always problems with knx1 in OH2, and recently my OH1.8 Installation stopped working, so I updated my OH2.5 test environment which was running ok for months to use all my rules.
For me, knx1 was rock stable on OH1.x, but a nightmare in OH2.x. It’S far better with a current knx2 version in OH2.5, but it’s still not as stable as knx1 in OH1.x.
I have to restart openHAB every time I use VSCode because rules tend to stop working after some hours - seems related to LSP. And sometimes I have no idea at all, why knx2 loses contact to the bus (but this is a rare event, maybe once a month…)
A few months ago I started working on Auto-Discovery for KNX as part of my Work on the Apache PLC4X Project. Currently all of this work is being done in the PLC4Go (Golang version) of the KNX driver, but I’m planning on bringing these changes to the Java version as well (90% of our code is generated anyway)
What I have working so far, is to auto-detect any KNX gateways in your home network. It then is able to connect to these and do an active scan of your KNX networks and hereby finds the KNX addresses of any KNX device in your network. It also reads the manufacturer id and application version which helps to identify the type of device.
Today I finished a first working POC of something that connects to a given KNX device and extracts the group addresses as well as the communication objects these Group addresses are bound to. (Everything without needing an ETS project file or secondary export)
Still trying to find a way to also get the datatype of the communication object/group address but generally making good progress here.
So I think if you folks are interested in this, I could need some help with testing this stuff with real world hardware (Most of my installation is Gira, with a bunch of Merten touchscreens … so not a very extensive sample). Also coming up with a PLC4X Open-Hab binding might be something we could work on together.
Great work! The only issue I see is that you might not get all the addresses. There are many non transmitting group objects, that do not respond to a read request. Moreover there are even non communicating group objects (that do not even send an ACK). Can you please explain how you are scanning the Knx bus?
Nevertheless, I am willing to help, just tell me how.
For devices that didn’t work, do a WireShark recording of what ETS does when you select: “Bus/Geräteinfo” with “Lese Gruppenkommunikations-Teil” enabled.
Actively help by joining the team and helping with the coding.
@george.erhan Of course will we not be able to do everything for all devices, but I am sure we’ll find solutions for most issues and it’s not about providing a perfect solution, but one that’s better than the existing and to improve that over time. And I think I can even read the non transmitting group addresses, even if they are attached to things like read-only com objects. I’m not passively listening to traffic, I’m actively reading the devices group-addresss tables as well as the association-tables and perhaps soon even the com-object-tables (Where possible).
The detection of KNX gateways is done via KNX’ boadcast discovery mechanism. If your gateway doesn’t support that, you can always directly connect to that by providing the ip/host-name in the connection-string.
The detection of the KNX devices is implemented by sending connect requests to all potential knx addresses (But we have means for limiting the scan range). If we get a successful response, there’s a device available.
If we now found a device, I currently read the group-address-table and the association table to find out which com-objects are bound to which group-address. Here I’m currently implementing multiple inspection profiles as depending on the device-descriptor the process is different (but similar). This is specially where I could need help as I only have a small subset of available KNX devices and device profiles.
Oh … and I forgot the probably most important way to contribute without even having to code:
Provide knowledge and insights … this probably is the most important way to contribute.
I’m currently working on implementing protocol drivers for dozens of different protocols on 3-4 different programming languages, therefore I can’t study each protocol spec into the detail they probably deserve.
In order to execute it, you should probably only need to checkout the develop branch of our repo, install Go, go into the plc4go/examples/discovery directory and run:
go run hello_world_plc4go_knx_discovery.go
Currently I found out that some devices from ABB seem to be misbehaving a bit and am working on workarounds. But the more devices/types of devices we test this on the quicker we have something solid to work with.
Ah … and yeah … we could use people to help with developing an OpenHab integration Module. I have absolutely no experience with OpenHab.
… As complete silence has come after me asking for your help … editing my last answer:
This work sounds very interesting, I have a large number of KNX devices so thought I would test your program against it, but the GitHub link is not longer active. I would be interested in doing the OpenHab side of the integration if this is still something you are interested in.
Hey @Chris_Deere,
I work with Apache PLC4X in other areas. Location of file have changed to:
Let me know if you’re able to build and run go binary. Depending on the way you would like to get this integrated with OH we could get a friendly output from precompiled executable or port whole discovery logic to Java.
Thank you for the quick reply. The build went fine, but I could not connect to my KNX gateway via VPN. A networking issue I am sure. I will try agin tomorrow when I am at the same site.
