OH2 Z-Wave refactoring and testing... and SECURITY

Mike_Bagdanoff · October 22, 2017, 3:33pm

Just had a device die with a completely dead battery, though the logs were showing 100% like most other devices on my system. It was an aeotec dry contact sensor.

chris · October 22, 2017, 3:40pm

I’m not sure what response you’re expecting? If the device is reporting 100%, then the binding can’t do much about that . Or do you mean the device was reporting a low number but the binding was still saying 100%?

Matt77 · October 23, 2017, 3:56am

[quote=“Matt77, post:1848, topic:21653, full:true”]

HI, hmm wondering what im doing wrong then.
already excluded and re-included it.

but i have strange things in my log, including entries like “Node dead” or “Is currently marked as failed by the controller!”.
but with the non Security binding its working.
i also noticed that all my battery devices are showing as " node is not comunicating with controller" in habmin. haven’t hat that with the “non security” binding.

Hi @chris, do you have any suggestion for me what the problem could be with the door/window sensor?
after some additional “Heal” for those two battery devices they at least showing to be working fine in HABmin, however the door/window is still not reporting any open/close state at all.

i tried again with the binding included in the snapshot release of OH2 and there everything is fine.

i re-included the node and this is what i can see if i open/close it"

2017-10-23 23:32:42.637 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 13 00 04 00 21 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 32 
2017-10-23 23:32:42.646 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-10-23 23:32:42.653 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=33, callback=0, payload=00 21 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 
2017-10-23 23:32:42.658 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=33, callback=0, payload=00 21 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 
2017-10-23 23:32:42.664 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=33, callback=0, payload=00 21 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 
2017-10-23 23:32:42.665 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2017-10-23 23:32:42.667 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 33: Application Command Request (ALIVE:DONE)
2017-10-23 23:32:42.672 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 33: resetResendCount initComplete=true isDead=false
2017-10-23 23:32:42.676 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 33: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2017-10-23 23:32:42.681 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 33: COMMAND_CLASS_MULTI_CHANNEL not found
2017-10-23 23:32:42.685 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2017-10-23 23:32:42.689 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
2017-10-23 23:32:42.694 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.698 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.702 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.707 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.711 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.715 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.717 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.719 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.721 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.724 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.729 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.730 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.732 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
2017-10-23 23:32:42.734 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing

chris · October 23, 2017, 8:23pm

This means that the controller thinks the device is no communicating. There was a long discussion on this earlier (somewhere!) in this thread. I don’t really know why the controller sets this state on devices that are working - according to the docs, it shouldn’t. This version of the binding uses the controller status to decide if the device is dead or not rather than doing something internally - this is why the older version works.

vossivossi · October 23, 2017, 9:11pm

Yes, there was a discussion here on this. But I remember that you planned to change this as the controller status seemed not to be reliable. Do you still plan to do this?
At the moment my “workaround” for main powered nodes (230V, no battery devices) that are marked as “dead” is to change an unimportant configuration parameter in Habmin. In this case the binding apparently seems to ignore the dead status, sends the parameter and gets a confirmation. Immediately the system starts the mesh update for the node and it works again. It is silly that these 2 clicks immediately “cure” each main powered node while the binding will show it for hours or days as “dead”.
However, for battery powered devices this does not work. I have a couple of sensative strips door/window sensors which are dead since more than several months (according to the binding and also according to the last time stamp of the xml-File in the Z-Wave folder). However, they report their status several times a day reliably to OH.
So I would like a solution that does not ignore these facts but states a “real” status of the devices (as in former times, eg. OH1, OH2 etc.)

chris · October 23, 2017, 9:12pm

Yes - clearly the current system doesn’t work well . I will try and look at this soon.

chris · October 23, 2017, 9:19pm

I’m not sure I understand this? What is the “Real” status? The theory is that the controller has the best information, and therefore it knows the “real” status better than anyone else. The binding can try to evaluate the status, but I’m not sure what you refer to as a “real” status? I guess you are asking to ignore the controller? Either way, we have to ignore some “facts”?

Can you explain what you mean? (sorry for my lack of understanding with this).

Matt77 · October 24, 2017, 4:12am

as per my previous post it seems that the controller is now not thinking any more the Node would be dead and as it looks like i receive messages from the node when the contact gets opened/closed.

2017-10-23 23:32:42.637 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 13 00 04 00 21 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 32 
2017-10-23 23:32:42.646 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-10-23 23:32:42.653 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=33, callback=0, payload=00 21 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 
2017-10-23 23:32:42.658 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=33, callback=0, payload=00 21 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 
2017-10-23 23:32:42.664 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=33, callback=0, payload=00 21 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 
2017-10-23 23:32:42.665 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2017-10-23 23:32:42.667 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 33: Application Command Request (ALIVE:DONE)
2017-10-23 23:32:42.672 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 33: resetResendCount initComplete=true isDead=false
2017-10-23 23:32:42.676 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 33: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2017-10-23 23:32:42.681 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 33: COMMAND_CLASS_MULTI_CHANNEL not found
2017-10-23 23:32:42.685 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2017-10-23 23:32:42.689 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
2017-10-23 23:32:42.694 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.698 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.702 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.707 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.711 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.715 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.717 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.719 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.721 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.724 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.729 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == false, frequentlyListening == false, awake == false
2017-10-23 23:32:42.730 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Node not awake!
2017-10-23 23:32:42.732 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
2017-10-23 23:32:42.734 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing

“binary sensor” and “battery level” are receiving status changes/values but not the important one “Door Sensor”

brononius · October 24, 2017, 7:53am

Hey,

Following another topic, I’ve installed the latest zwave binding. In short, after a while, my zwave setup stops working, all other things (knx, weather, pushover…) worked.
No idea why zwave goes dead. I’m running OH2 on Ubuntu17.10 as VM under proxmox. And I’m using 2(!) GEN5 USB sticks. This worked for about 1 year without problems. It’s possible that it’s a hardware/KV issue. But after 4 complete reinstalls (OS and OH), reset of 30 zwave nodes, I don’t have any clue more how to proceed.

I did following steps right now:

1. Remove zwave binding from paperUI
2. cd /etc/openhab2/addons/
3. wget http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.2.0-SNAPSHOT.jar
4. ssh openhab@localhost -p8101
    feature:install openhab-transport-serial
    bundle:start org.openhab.binding.zwave
    bundle:list
       215 | Installed |  80 | 2.2.0.201710172006     | ZWave Binding

A lot of logs passes by, but all my zwave nodes stay UNINITIALIZED.
I would guess that the outlet powered devices come online after 1 hour?

2017-10-24 09:40:19.620 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
2017-10-24 09:40:19.620 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Oct 24 09:40:21 CEST 2017 - 2000ms
2017-10-24 09:40:19.622 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2017-10-24 09:40:19.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
2017-10-24 09:40:19.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
2017-10-24 09:40:19.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
2017-10-24 09:40:19.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 1101: [WAIT_RESPONSE] requiresResponse=true callback: 0
2017-10-24 09:40:19.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2017-10-24 09:40:19.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2017-10-24 09:40:19.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start
2017-10-24 09:40:19.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction lastTransaction outstanding...
2017-10-24 09:40:19.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
2017-10-24 09:40:19.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Oct 24 09:40:21 CEST 2017 - 1998ms
2017-10-24 09:40:19.626 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 62 01 99 
2017-10-24 09:40:19.630 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-10-24 09:40:19.630 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=IsFailedNodeID[0x62], type=Response[0x01], dest=255, callback=0, payload=01 
2017-10-24 09:40:19.630 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=IsFailedNodeID[0x62], type=Response[0x01], dest=255, callback=0, payload=01 
2017-10-24 09:40:19.632 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=IsFailedNodeID[0x62], type=Response[0x01], dest=255, callback=0, payload=01 
2017-10-24 09:40:19.632 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 1101: [WAIT_RESPONSE] requiresResponse=true callback: 0
2017-10-24 09:40:19.632 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2017-10-24 09:40:19.632 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 1101: [WAIT_RESPONSE] requiresResponse=true callback: 0
2017-10-24 09:40:19.632 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=IsFailedNodeID[0x62], type=Response[0x01], dest=255, callback=0, payload=01 
2017-10-24 09:40:19.632 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 1101: Transaction COMPLETED
2017-10-24 09:40:19.632 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 1101: TransactionAdvance ST: DONE
2017-10-24 09:40:19.632 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 1101: TransactionAdvance WT: null {}
2017-10-24 09:40:19.632 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 1101: TransactionAdvance RX: Message: class=IsFailedNodeID[0x62], type=Response[0x01], dest=255, callback=0, payload=01 
2017-10-24 09:40:19.632 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 1101: TransactionAdvance TO: DONE
2017-10-24 09:40:19.632 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: Response processed after 12ms
2017-10-24 09:40:19.632 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: TID 1101: Transaction completed
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: notifyTransactionResponse TID:1101 DONE
2017-10-24 09:40:19.633 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 3: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 21: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 21: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 19: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 19: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 5: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 23: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 23: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 12: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 20: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: listening == false, frequentlyListening == false, awake == false
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 17: Node not awake!
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 1101: Transaction event listener: DONE: DONE -> 
2017-10-24 09:40:19.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: -- To notify -- COMPLETE
2017-10-24 09:40:19.634 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction Response Complete 1101 -- 
2017-10-24 09:40:19.637 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 7: Node Init response (0) COMPLETE
2017-10-24 09:40:19.637 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 7: Node Init transaction completed with response COMPLETE

5iver · October 24, 2017, 8:04am

You came over from the 2.1.0 binding, so you will need to delete your Things and then rediscover them.

chris · October 24, 2017, 8:25am

I can’t see this from the logs though - the last logs you posted say it’s failed.

What I see in the logs is that a command class isn’t found - this might be because the initialisation hasn’t completed due to the FAILED step timing out. Without a full log it’s hard to say why this class is not found.

You could try a complete init of this node to see if that fixes the issue. If not send me the full logs.

Again, without logs I’m just guessing, but possibly these commands are sent to the root node and the command classes get added even if the initialisation didn’t detect them. It doesn’t necessarily mean the initialisation completed.

vossivossi · October 24, 2017, 12:25pm

My impression is that the current status handling of dead nodes in the dev binding is not reliable while old versions (OH1 or OH2 non dev versions) appeared to be more reliable. I understood that you implemented your “own” status handling on the binding side in these old versions while you rely on the controller information in the dev binding.
So I would suggest to reimplement your “own status handling” if possible as from my experience it used to be superior to the current one.

chris · October 24, 2017, 12:40pm

That’s what I said I was going to do…

Matt77 · October 24, 2017, 6:09pm

@chris thanks for looking into this.
i attached the log from today. i tried several times to reinitialize the node (node 33) but the
COMMAND_CLASS_MULTI_CHANNEL is still showing as not found.

events.xml (486.8 KB)

chris · October 24, 2017, 6:20pm

The log doesn’t really have much in it. It’s just an event log rather than an actual log… What I’d like to see is the initialisation - delete the xml and restart, or perform an initialisation so we can see what’s happening.

Thanks.

Matt77 · October 24, 2017, 6:51pm

So here the log aver a full new initializing of Node 33.

openhab.xml (804.0 KB) (ZIP File)

chris · October 24, 2017, 7:05pm

Thanks…

Interesting stuff (unfortunately!). Give me a day or two to think about this one - it’s linked with the multi-instance-association configuration I think…

Matt77 · October 24, 2017, 7:16pm

thanks again. also i noticed, and i thing i have read a similar case somewhere, that after a restart the battery nodes are not getting fully initialized till the next wakeup. however they never get fully re-initialized automatically.

for example, after the restart my node 26 (fibaro motion sensor) is reporting all alarms without any issue but Battery state, temperature, … are not getting updated. even after the 7200 sec wakeup interval not. actually i have to manually wake it up, which is OK as long as i have only one. but should that not happened automatically? in the snapshot binding the same was working fine.

chris · October 24, 2017, 7:30pm

Battery state is polled, so if the device isn’t waking up, then it won’t get updated. However temperature should be sent unsolicited so shouldn’t be related to wakeup.

The wakeup shouldn’t be related to the binding - it’s a device function. Check the logs to see if it’s waking up - if it is, then let’s see what it’s doing.

vossivossi · October 24, 2017, 8:40pm

Great!