[KNX] No connection to bus after server restart (router mode)

Expected Behavior

If OpenHAB starts it should correctly connect to the KNX bus and update all items with the current state, even after a full server restart. I never experienced this issue while using the KNX 1 binding.

Current Behavior

Weird but true story… After a restart of my server (Windows Server 2012), OpenHAB is not able to connect to the KNX bus correctly. Polling, reading and writing data always fails. Restarting the KNX binding does not help (bundle:restart org.openhab.binding.knx). If I launch ETS5, which is also installed on the server and I open the “Bus”-tab (below), so that it discovers the available connections, and restart the bundle after that, it connects correctly. Everything is up and running afterwards.

My interface is configured as follows: Bridge knx:ip:MDTIP "MDT IP Interface" [ type="ROUTER", localIp="192.168.50.100", readingPause=50, responseTimeout=10, readRetriesLimit=3, autoReconnectPeriod=1, localSourceAddr="1.2.1" ]

I included some notes on my actions in the log file. I marked them with short lines of dashes (--------------). Log file: KNXIssue.txt

Steps to Reproduce

1. Restart complete server (Windows Server 2012).

Your Environment

• OS: Windows Server 2012
• OpenHAB: 2.4.0-SNAPSHOT build 1422

[lewie]

@AngelosF,

2. The NIC has multicasting off by default and it is enabled when ETS is fired up.

Normally, multicasting always is enabled at your NIC. There are many other standards that uses multicasting over other multicast IPs. UPnP/DLNA for example, uses multicasting for streaming Media (239.255.255.250).

[lewie]

Sorry to continue his discussion but I find it interesting 😃

@AngelosF, absolutely no problem! Had to look twice already. Fatally confused localIp and ipAddress. 😭

I thought that using localIp with type=“ROUTER” allows the user to configure the local interface to be used for multicasting (as you mentioned, useful when using multiple Router Networks)

Yes localIp is used, if you have two or more Network Interfaces, then you can determine with which interface the KNX binding should communicate. If localIp is not set, the binding uses the primary Ipv4 host address. It does not matter if KNX Binding is configured for ROUTER or TUNNEL mode. See here

I saw also that your third example (with localIp set but no ipAddress that was not supposed to work) actually worked for Frederic. I haven’t tested this scenario on my system yet. I would expect that it will work (since ipAddress defaults to 224.0.23.12).

You are right, that was just wrong! Thanks for the hint. I have corrected this in my upper comment and replaced the localIp variable with ipAddress. And explaned the full Story with an example of parallel multiple Router KNX Networks.

Also, in the docs: https://www.openhab.org/addons/bindings/knx/#ip-gateway, localIp is described as the Network address of the local host and that it defaults to the primary interface address (it doesn’t specify if this applies only to TUNNEL). Maybe we need to update the docs if this is overwritten by the ipAddress when using ROUTER.

I have not expressed myself exactly, nothing will be overwritten… The documentation is correct. I have explained it in the upper comment more accurate and correct

Regarding the filtering table: I was always under the impression that by default a KNX Router will NOT route telegrams between IP & BUS (either direction) if set to filter and the filtering table is not configured properly (e.g. using a dummy application). Maybe I am wrong (but then… what would be the role of the filtering function?)

You are right, unless specifically directed to forward everything, the ROUTER only forwards the addresses used in the ETS project.

forward everything - ROUTER forwards everything. block - ROUTER blocks everything. filter - ROUTER builds a internal filter table based on addresses used and connected in your ETS project. Here you need a dummy application for addresses which should be forwarded but not connected in ETS.