KNX - Reading statuses became unreliable

Add-ons Bindings
,
1

Hi,
I’m experiencing the strangest thing with my KNX binding. In short: not all status updates on the KNX bus are picked up by OpenHAB, while sending commands via OpenHAB to KNX is 100% reliable. So when I flip a KNX switch in my house so Sonos would start playing: that often doesn’t work (KNX->OpenHAB). However, switching on/off a KNX controlled light via OpenHAB always works (OpenHAB->KNX).

The longer story:
Last Friday my Intel NUC arrived. I decided to carve out my OH from my Synology, because in several circumstances the Synology became a bit underpowered (e.g. when playing Plex I sometimes had a 5sec delay between something triggering OH and OH actually acting upon it). I installed Ubunto 16 (LTS), OpenHabian and some other HO related stuff (InfluxDB,…). That all went surprisingly smooth. I had my OH migrated in no time.

On Saturday I noticed that OH sometimes didn’t pick up commands coming from the KNX bus (all other bindings seem to be unaffected). At that’s strange, because all the settings/items/… were migrated. So what works on my old OH installation should work on the new one, right?

This is my knx.cfg (that has worked flawlessly for like 8 months untill Friday):

ip=224.0.23.12
busaddr=1.0.2
ignorelocalevents=true
type=ROUTER
port=3671
localIp=192.168.3.24
autoReconnectPeriod=10

The only value I changes was to replace the value in localIp (my Intel NUC obviously has another IP then my Synology).

Some other things I tried:

  • I made sure that the OH installation was off on my Synology so it would not interfere. I even rebooted my Synology to make sure it didn’t keep any open connections with my Gira KNX-IP router.
  • I also rebooted my Gira KNX-IP router (I don’t use KNXd);

Some KNX devices are sending temperature updates every minute. So normally an entry would exist for that in my events.log. I noticed last night that there were indeed “gaps” (no temperature updates). Sometimes the gap was only five minutes, but the longest gap was about an hour.

Honestly, I’m pulling my hair out right now. I don’t know where to begin to look…

2

try to identify (roughly) the “area” where the root-cause can be found…

options:

  1. Networking (check stuff like:)
  • ethernet cables between NUC, GIRA and switch
  • network statistics on NUC (dropped packets, ping, etc)
  • multicast tests
  1. KNXnet (check stuff like:)
  • KNX Bus overload
  • GIRA filtering telegrams?
  • monitor the Bus with ETS
  1. OH2
  • enable TRACE logs (both binding and transport)
  • try another PA in knx.cfg
  • check knx.config
  • check system load

It’s strange that some telegrams make it to OH2 and some don’t… Or… all of them make it and OH2 is not processing all of them…

3

Hi Dim,

Thanks a lot for your input.

I’ve spend a lot of time analyzing the problem, I even reinstalled OH (keeping my old files somewhere). But I’m pretty sure I have solved the problem now.

Eventually, it was related to multicast.
My Synology is plugged in directly to a switch. My new Intel NUC was not, it was plugged to a Netgear R7000 router, which I had set up in bridge mode. My assumption was that it would just pass on multicasts, but it did not. Or more specifically: it often did not. And that’s why it took me a while to troubleshoot. I was assuming that if my network would block multicasts, it would always block multicasts.

As soon as I plugged in my Intel NUC elswhere, the problems were gone. :slight_smile:

Thanks!

1 Like