I just started a re-setup of 2.x with KNX2 and have some trouble with physical KNX addresses for my things. From my previous setup I still maintained only the item configurations with group address assignments. So for the new setup I wanted to do everything nice and clean and configure physical things with the corresponding channels. However, the KNX devices are always marked as
offline while the channel communication works.
About my KNX setup I have a documentation where I think I can find the physical address of the actors, but whenever I configure the address, the device is claimed to be offline:
I deduced that e.g.
01.01.004 is the physicial address of the actor and tried to use it for my thing configuration (both as
1.1.4) but it’s always offline.
That said, if I leave out the address the thing is marked
online in PaperUI and I can configure channels and items which work nicely.
Is there something I’m doing wrong? Or is this just how KNX2 is supposed to work? Or maybe does my router not support contacting the devices by physical address?
I’d really like to use the
fetch mechanism to let the binding discover channels automatically (if that is what it’s supposed to do).
Disclaimer: I’m a long-term 1.x user, migrated my setup to 2.x and it’s still running successfully with the migrated config. Recently I decided to do a re-setup with all the shiny new features and especially KNX2. I’m totally not into the electrician part of KNX and it’s setup, but have a programmer background.
Thanks in advance for any hint!
P.S.: I have a
.knxproj export of my setup, but of course no ETS license (and no windows machine). So if the documentation I have does not contain the physical addresses I’m looking for, there might be a chance to get it from there …
Well, 1.1.4 should be the individual address (i.e. physikalische Adresse in german) of the actuator. How did you configure the bridge? Maybe you configured a wrong individual address for the gateway?
Thanks for coming back to me and thanks for clarifying the correct term for individual address.
The problem is, that I don’t know the individual address of my router, therefore I left it blank to
I looked through the entire documentation but did not find any object that sounds like it could be the router. Is there a way to find our the individual address?
Thanks in advance!
In fact, you don’t need an individual address for the router but you have to use an unused individual address. setting it to 0.0.0 should suffice, though you won’t be able to create a dummy device in ETS to get better logs (i.e. named device instead of pure individual address)
Are you using a knx/IP router or a knx/IP gateway?
I’m sad, the PDF docs I have about the installation don’t tell anything about the type of bridge. I just looked up the original offer of the electrician which days “KNX IP- Router”. In the control box it looks like this:
But that is probably not very helpful, right?
Maybe it’s possible to extract some more info from the ETS file (
.knxproj is ETS, right?)? Maybe even without ETS, because I don’t have that?
Thanks a lot for your support,
Woops, thanks for the reminder. Edited my original post.
Hm. I’m not sure about the .knxproj file, to be honest, I never used one of those yet
But you could open the casing (if not sealed) carefully to see the whole IP Router, this should reveal the exact type.
As the only issue is the wrong offline message, I doubt the effort is worth it.
In question of individual addresses of devices, there might be another option to get additional informations, that is to set knx2 addon’s logging to DEBUG. There will be plenty of information after that step, you will see the whole knx bus communication, even GA not set in openHAB will be logged. Of course this will fill up the openhab.log…
the .knxproj file is a project export of the ETS-software. I do not think, there is a chance, to read the content with any other software.
Concerning your initial issue of defining things for individual KNX-devices: As I understand the documentation of the KNX-binding https://www.openhab.org/addons/bindings/knx/ (look under “device Things”) you essentially need ONE physical KNX device address, that openHAB can check if the bus is online.
At the end of this paragraph the documentation talks of “experimental features”, so I think actually this is not really usable.
Effectively, in a KNX environment the physical device addresses are used by ETS to e.g. program devices. They are not necessary for “functional communication”.
Functional communication is exclusively done via KNX group addresses.
As described in the documentation, there are only two device physical addresses necessary:
- one for that one “poll-device” to check if the KNX-bus is online. It is important, that a device is selected, that responds to read attempts (some older KNX-devices don’t)
- and the second for the KNX-IP-gateway.
But for this physical address in the bridge definition section it is very important to use 0.0.0, so that openHAB automatically decides which address to use.
This is because the KNX-IP-gateways usually support several tunnels from IP to KNX, each represented by a physical device address on the KNX side.
BUT: the KNX-IP-gateways assign these addresses on a first-come-first-serve base, so if there is more than one of the tunnels in use, the address assigned to openHAB may change!
In my configuration this happens e.g. when ETS software is active and then openHAB boots and connects. I had an extensive learning curve to recognize this
Thanks for your input! I found a friend who onws ETS to extract me some more docs from our setup. Among other interesting stuff he sent me screenshots of the router configuration and I think this contains the root cause of my problem:
If I interpret it correctly, the router filters all individual messages (is that the correct translated term?) in & out from/to LAN.
That said, I could ask the friend to help me change that setting in order to get better integration with OpenHAB. Do you think there is a general risk (like security) in allowing this kind of communication?
maybe it helps to download the manual of the router first, to see, what effects the changing of configuration will have …
Yes, filtering is definitely the root cause. That’s why simple knx/IP Gateways with Tunnel Mode are so much less work…