Hey, I’m trying to connect to KNX devices from Home Assistant, but the KNX network is on a different ip subnet (and different VLAN – so not the default eth interface). I can’t figure out how to configure the integration to discover those devices. Help?
Home Assistant: on 192.168.8.200 / 255.255.255.0
KNX devices: on 192.168.0.x / 255.255.255.0 VLAN id 1100
I have confirmed the host is able to communicate on both networks, but HA says “Retrying setup: No usable KNX/IP device found.” when trying to configure KNX, regardless of whether I use Automatic or Routing mode.
Probably neither will work because of Multicast not being able to work across the different networks.
You can select a network interface to be used (if you have multiple on your HA host) by setting its IP address in the local IP field - maybe that helps.
Otherwise use tunnelling.
Where do I get to do that? The “Manual confguration” guide points at the web interface, which only allows me to edit the KNX addressing. While there’s discussion of a knx: section in configuration.yaml, the integration’s configuration actually exists in the database?
For those following, the host has a single Ethernet port, but presents two interfaces, one of them being the VLAN interface with a different subnet and VLAN id. The switch and routing devices are where the KNX network are isolated from the network which has browser access. For the purposes of Home Assistant, it might as well be two physically different Ethernet cables into the host.
Thank you! I will have to try that. On my 2022.11.0 install that field isn’t visible until I choose “next” from the tunneling initial dialog, and I guess I mis-interpreted what the “IP address of the KNX/IP tunneling device.” description meant. Going to debug this further later today and report back.
The Local IP field did get me forward, thank you. HA is able to connect to the KNX gateway in Tunneling mode, but doesn’t reach it in Routing mode, nor does Automatic/Discovery work. Not sure why. I can see on the wire now that HA’s routing mode datagrams go to the Multicast address, but nothing comes back.
This network is actually quite a beast and probably not one HA is designed for – there are 40 separate gateways for 40 units with separate power distributions. I was hoping discovery would pick them up but as it stands, it looks like I can only connect to one “group” at a time.
Nor have I yet figured out how to reach the power relays/meters behind the gateway - there’s apparently a lot I don’t yet understand about how KNX networks work. But at least I’m making some steps!
Hm… where did you see the routing multicast packets?
If you are sure they reach the routers then maybe their filter tables just didn’t match and they dropped the telegram. You would have to set a proper IA and add a dummy in ETS, connect GAs and update the routers filter tables.
I’m now running a test/debug instance on my laptop (Mac) and had Wireshark listening to the interface. In tunneling mode I can see KNX/IP datagrams going back and forth but if I try Automatic or Routing, there’s only the packets out from my computer, nothing coming back. MacOS Firewall was off during the tests so it shouldn’t be that, and Wireshark sees a lot of completely unrelated chatter, including multicast, on the non-VLAN interface where all the general purpose traffic is.
I’m a complete neophyte wrt KNX, but quite well versed on the IP side of things - and I know next to nothing about the actual KNX install. What I do know are the IP addresses of the ABB IPS/S2.1 KNX gateways and that there should be mutliple relay/meters behind each.
I didn’t, but I haven’t got a lot of time to dig deeper. I suspect the HA KNX integration is built from completely different assumptions than what’s going on in this network – I have a separate KNX gateway in each of several apartments, and the same or similar devices (electric relays/meters, water meters, etc) behind each gateway at the same addresses. Not sure HA is equipped to deal with that at all. But in addition, I couldn’t really get it to speak to just one of those gateways, either, so even if I don’t try to manage the entire installation, discovery isn’t doing what I would expect.
KNX is just weird, and I have little documentation I am able to understand at all.
Oh, well, this would be a show-stopper. HA doesn’t support multiple KNX connections… so it would need an IP backbone where all these measurements can be sent to from individual group addresses.
Yep, figured as much when peeked at the source code. Still, it doesn’t explain why I’m not discovering any of the devices when connecting to just one of the gateways (each is at its own IP address).
The HA Knx integration can only “discover” gateways - as in “find their IP addresses and best fitting configuration” for setting up the connection.
All Knx entities have to be defined in yaml.
Ah, ok, then I had understood that wrong. KNXmap is able to find the devices, so I imagined that HA’s KNX integration could discover them as well and configure entities automatically - and was confused why that wasn’t happening.
Oh interesting. Never heard of that.
From having a peek I think it only finds devices by individual address, but it won’t find group address configurations like used DPT and device/entity association (I also think that is not really possible in knx).
And this is where my lack of detailed KNX understanding will shine through. I don’t really know what the difference between a group address and a device address is… Sort of groping in the dark here.
A device has one unique individual address IA (eg. 1.0.34). This is used for every message (telegram) as source address. It is also used as destination address when configuring the device itself (mostly from ETS). This is called point-to-point communication.
In regualr operation (eg. sensors sending new values) devices are not addressed directly. Every value is sent as a broadcast with a group address (GA) as destination. Every device on the bus (or line if couplers are involved) receives that telegram and reacts accordingly if it has any association with that group address.
Group addresses are assigned to group objects of a device in ETS. They use different notation - eg. 3/4/32 (note the / instead of .).
The ETS project file holds these associations. Devices only know their part of the game - they don’t know about other devices, only what GAs they shall send to or react to.
