KNX Binding Startup Issues and Solutions

I’ve encountered an issue with the KNX2 binding in OpenHAB where it doesn’t always start up correctly. Here’s what I’ve observed and how I’ve managed to resolve it.

Problem Description:
When OpenHAB starts, the KNX2 binding occasionally doesn’t initialize properly. The logs show errors related to unresolved channel types and NullPointerExceptions. This seems to happen sporadically—sometimes it works on startup, other times it doesn’t.

Error Logs:
plaintext
2019-04-07 00:08:01.376 [ERROR] [.thing.internal.GenericThingProvider] - Channel type knx:number could not be resolved.
2019-04-07 00:08:01.376 [ERROR] [.thing.internal.GenericThingProvider] - Channel type knx:contact could not be resolved.

java.lang.NullPointerException: null at org.openhab.binding.knx.internal.handler.DeviceThingHandler.initialize(DeviceThingHandler.java:85)

Solution and Workaround:
After some experimentation, I found that manually reloading the knx.things configuration file resolves the issue. Here’s what I do:

  1. Reload Configuration:

    • Navigate to the OpenHAB Paper UI.
    • Go to Configuration > Things.
    • Click on the KNX bridge or device.
    • Select Reload Configuration.
  2. Logs After Reload:

    • The logs show that the knx.things file is reloaded:
      plaintext
      2019-04-07 00:18:01.120 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘knx.things’
      2019-04-07 00:18:02.235 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model ‘knx.things’

    • After this, the KNX binding works as expected.

Possible Cause:
It appears that the KNX things/items are loaded before the KNX2 binding is fully initialized. This race condition might be due to the order in which components start up. Reloading the configuration ensures that the binding is ready before the devices are processed.

Preventive Measures:
While I haven’t found a permanent fix yet, I’ve implemented a workaround:

  • I set up a cron job to reload the KNX configuration periodically. This helps prevent the issue from recurring.

Conclusion:
While the KNX2 binding is generally reliable, this startup issue can be frustrating. By reloading the configuration, I’ve been able to maintain consistent operation. If anyone has encountered similar issues or knows of a more permanent solution, I’d love to hear about it!

Happy automating! :rocket: