Qubino ZMNHBD1 Flush 2 not reporting separate switches

I’m sure it must be somewhere in that log :wink:
Here’s a shorter one containing only one association action:
https://dl.dvelop.nl/oh2/associate-fail.log

Thanks - I’ll take a look. One thing I did notice in one log you sent was the binding seemed to generate a lot of associaiton update requests, but at it was at the start of the log I wasn’t sure what triggered it… Maybe this is related, but I’ll take a look tonight.

I suspect the issue is the way the remove works - I updated the SET to always use the multi-instance version of the command but forgot to update the REMOVE command - I’ll do that later and hopefully it will resolve the issue.

Hi @chris, sorry testing took some time since the Eclipse repo was down.
It seems your fix didn’t change anything.
Here’s a new log: https://dl.dvelop.nl/oh2/associate-fail2.log2

I’m getting an error that this log doesn’t exist.

The requested URL /oh2/associate-fail2.log2 was not found on this server.

Whoops, scratch that last ‘2’: https://dl.dvelop.nl/oh2/associate-fail2.log

Ok - everything looks ok in the log, but the REMOVE command isn’t working. I think the issue might be a bit more fundamental in that I’m using endpoint 0 which isn’t actually allowed for multi-instance (according to the doc I’ve just read). So, it seems that the device can accept endpoint 0 in the SET, but not the REMOVE (which is a bit strange!).

I need to have a think about how to handle this properly…

On a different note, what UI are you using? Is it HABmin (I think not but just checking as it’s sending a lot of updates that aren’t necessary I think)?

I’m using HABmin indeed. The logs shows an update of the main controller association, but I also removed 6 (I think) other associations in other groups to the controller. I put those there when testing and now they can’t be removed anymore. Not a problem though, since updates are coming through :slight_smile:

Ah - ok. I thought you’d just done a single setting so I was a bit surprised to see so many :slight_smile:

FYI I’m going to merge this change into the master today, so hopefully you’ll be able to use the current snapshots again.

I’ve not looked further at why the remove doesn’t work though…

Cool, thanks. that works. However, something seems to be off. I’m getting stacktraces now and then:

2016-08-21 20:04:45.127 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2. {}
java.lang.ArrayIndexOutOfBoundsException: 3
    at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.isSecurityNonceReportMessage(ZWaveSecurityCommandClass.java:1067)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.SerialMessage$SerialMessageComparator.compare(SerialMessage.java:692)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.SerialMessage$SerialMessageComparator.compare(SerialMessage.java:1)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at java.util.concurrent.PriorityBlockingQueue.siftUpUsingComparator(PriorityBlockingQueue.java:374)[:1.8.0_101]
    at java.util.concurrent.PriorityBlockingQueue.offer(PriorityBlockingQueue.java:491)[:1.8.0_101]
    at java.util.concurrent.PriorityBlockingQueue.add(PriorityBlockingQueue.java:463)[:1.8.0_101]
    at org.openhab.binding.zwave.internal.protocol.ZWaveController.enqueue(ZWaveController.java:520)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.sendMessage(ZWaveNodeInitStageAdvancer.java:260)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.advanceNodeStage(ZWaveNodeInitStageAdvancer.java:306)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.handleNodeQueue(ZWaveNodeInitStageAdvancer.java:230)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.ZWaveIncomingEvent(ZWaveNodeInitStageAdvancer.java:1288)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:541)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:244)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:208)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7(ZWaveController.java:202)[11:org.openhab.binding.zwave:2.0.0.201608211748]
    at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1288)[11:org.openhab.binding.zwave:2.0.0.201608211748]

Doesn’t seem to break any functionality for now. I don’t have a debug log, let me know if you need it.

This change should have been the same as commenting out the code that I think you removed so a debug log would be good. Thanks.

I pulled some more changes you merged lately, my guess is it’s something unrelated to my problem.
Anyway, I’ll produce a log tomorrow evening.

Hmm, I just created a build with the latest commits and everything seems fine so far. No more stacktraces and the Qubino’s work as expected. Only remaining issue is the association removal.

Now that sounds better ;).

I’ll take a look at the association removal at some point soon for sure.