Omnilink driver in OpenHab2 stops receiving changes

I have noticed that after many hours (but always less than a day) - the Omnilink driver will stop receiving and processing updates from the omni panel.
I am using the 1.9 snapshot driver.
I see log messages just stop after a while.
These are the last messages I see in the log:

2017-01-16 03:09:04.381 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - Received Status Notification ObjectStatus ( )
2017-01-16 03:09:04.381 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - updateDeviceStatus 385 class com.digitaldan.jomnilinkII.MessageTypes.statuses.UnitStatus
2017-01-16 03:09:04.382 [DEBUG] [binding.omnilink.internal.model.Unit] - Unit state 0
2017-01-16 03:09:04.382 [DEBUG] [binding.omnilink.internal.model.Unit] - updating percent type 0

That was over 4 hours ago. Many HLC lights have been turned on and off since then.

I can see a connection existing between the openhab server and the omni panel:

netstat -an | grep 10.0.0.80
tcp6       0      0 10.0.0.16:36884         10.0.0.80:4369          ESTABLISHED

I forced a thread dump. I don’t see anything abnormal at a quick glance. Here are the associated entries:

Thread 31829: (state = BLOCKED)

  • java.lang.Thread.sleep(long) @bci=0 (Compiled frame; information may be imprecise)
  • com.digitaldan.jomnilinkII.Connection$ConnectionWatchdog.run() @bci=78 (Interpreted frame)

Thread 31827: (state = IN_NATIVE)

  • java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte, int, int, int) @bci=0 (Compiled frame; information may be imprecise)
  • java.net.SocketInputStream.socketRead(java.io.FileDescriptor, byte, int, int, int) @bci=8, line=116 (Compiled frame)
  • java.net.SocketInputStream.read(byte, int, int, int) @bci=79, line=170 (Compiled frame)
  • java.net.SocketInputStream.read(byte, int, int) @bci=11, line=141 (Compiled frame)
  • java.net.SocketInputStream.read() @bci=23, line=223 (Compiled frame)
  • java.io.DataInputStream.readUnsignedShort() @bci=4, line=337 (Compiled frame)
  • com.digitaldan.jomnilinkII.Connection.readBytesEncrypted2() @bci=58 (Compiled frame)
  • com.digitaldan.jomnilinkII.Connection.run() @bci=15 (Compiled frame)

Thread 31826: (state = BLOCKED)

  • java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
  • org.openhab.binding.omnilink.internal.OmniLinkBinding$OmniConnectionThread.run() @bci=313, line=444 (Interpreted frame)

Anyone else run into this?

I think I found the cause of the error.

I recompiled and turned on debug for the jominlink library, I then manually started openhab so I could enable stdout/stderr to go to a file rather than /dev/null.
I found this in the log.

Exception in thread "NotificationHandlerThread" readBytesEncrypted2: Omni message Length 17
java.lang.ClassCastException: com.digitaldan.jomnilinkII.MessageTypes.AudioSourceStatus cannot be cast to com.digitaldan.jomnilinkII.MessageTypes.OtherEventNotifications
at com.digitaldan.jomnilinkII.Connection$NotificationHandler.run(Unknown Source)

Looking at the code here that sort of exception is not caught in the notification thread. So the thread just dies. I also see that this code hasn’t been touched in over three years.

@digitaldan couple of questions:
(1) Do you want a PR to fix this?
(2) If so, is there a target java version for this library? I think the notification elements could be handled with less code / end user synchronization if we can be java 1.5 and up.
(3) While I can easily catch the exception so the thread doesn’t die, its not immediately obvious what we should be doing with the AudioSourceStatus message type and why this is only causing a failure now. Any ideas on that?

Edit: Ignore question #2, the code is obviously already java 1.5 and up - uses the enhanced for loop… Not enough coffee before posting.

(1) Do you want a PR to fix this?

Yes please!

its not immediately obvious what we should be doing with the AudioSourceStatus message type

I have no idea, I wrote that library MANY years ago ( so pleas don’t judge :slight_smile: ) and have not owned a omni system now for a few years. But PR’s are certainly welcome!

@digitaldan to close the loop here…

I opened a PR a few days ago. Been running with the new version since a day before I opened the PR. This version appears to have fixed the defect I encountered.