openhab-addons: [knx] Not reconnecting after send failure

The problem is not the disconnect (if it happens only once or twice a week), the problem is that the binding is not properly re-connecting. I have improved this process, but it‘s still waiting for merging.

@J-N-K, @grouchal, @sceppi, @cguedel,

in many versions, configurations and environments I use the KNX binding almost daily.

The KNX 2 binding is not yet perfect and has a few pitfalls, but it can run stable in almost all cases. In any case, it is similarly robust as the KNX 1.x binding was!

The following rules of conduct have led most constellations to success:

1.) In principle, the query of the actuator parameters should be omitted if possible. This feature is in no case necessary in any configuration, it is currently not used at all to tune GAs with openHAB.

After many discussions and hundreds of tests, it turns out that some actuators do not like to be queried regularly. If such a device is in the KNX bus, its unruly behaviour disturbs the whole bus and the openHAB KNX binding can be forced to reconnect or even give up after (usually 3) attempts. So comment out the parameter “address”, “fetch” and “pingInterval” in the Thing configuration if possible! It is best to omit this parameter from the beginning.

For orientation, if you absolutely want to arrange your GAs by actuators instead of by functionality or place of use, the value can remain there. (It should be mentioned here, but basically the KNX bus is organized via the GAs and abstracted from the actuator. This is one of the core concepts of the KNX bus and of such a bus in general.)

My opinion is: The query of the actuators is extremely confusing for most users, because they think that the logic of the KNX bus is structured like this, but this is wrong. The order by actuator is detrimental at this point because it is basically only a feature for absolute special applications. Or later used to make autodiscovery of the KNX bus possible in the background.

2.) The connection problem is aggravated with the parameter “autoReconnectPeriod”. If this parameter is set too short (<60 sec, depending on the number of addresses to be read out), the binding starts with a new loop and gets entangled, regardless of whether it is still being read out or not. An unfavorable but often observed misconfiguration then leads to the binding breaking off and no longer connecting. (We may have to investigate this and catch it in newer versions)

3.) Do not set “ipAddress” in ROUTER mode and only set “localIp” if two network cards are present and only if problems occur. Both are very special parameters which the normal user does not need.

I’m also writing this for the many users who might get a little too much respect for the KNX binding as a result of the discussion. The following configuration pattern should be sufficient for almost all users:

//PATTERN ROUTER DEFAULT
Bridge knx:ip:bridge [ 
    type="ROUTER",
    autoReconnectPeriod=60 //optional I would set always
] {
    Thing device knx_device "knx_device_name" @ "knx_device_group_in_paperui" [ 
        //readInterval=3600 //optional only used if reading values are present
    ] {
        ...
    }
}

//PATTERN TUNNEL DEFAULT
Bridge knx:ip:bridge [ 
    type="TUNNEL",
    ipAddress="192.168.0.111",
    autoReconnectPeriod=60 //optional I would set always
] {
    Thing device knx_device "knx_device_name" @ "knx_device_group_in_paperui" [ 
        //readInterval=3600 //optional only used if reading values are present
    ] {
        ...
    }
}

That’s it, less is more!

Because the topic is close to my heart, I am of course debugging and working out improvements for further versions. If you want you can send me a private message and we will do a remote session.

@lewie : First impression after running the knx2.0 binding for 24hrs is that this seems to have fixed it. Let’s see what the next days show, but my feeling is that it’s fully functional again now. Thanks a lot! Note: would suggest to add this ‘best practice’ to the knx binding manual on https://www.openhab.org/addons/bindings/knx/

**Update after a few days: Confirm that this solution has fully stabilized my knx2 binding and disconnects no longer occur!