Zwave errors in getting / setting dimmer states to on/off

@Chris As per my earlier email in the dimmer thread that he marked solved, here is the error log that shows the errors I’ve been seeing lately - Error

In addition I just ran a startup under debug logging at that file is here- Debug

In general, I’m unable to create rules that either capture the on/off state of dimmers and/or has issues actually setting dimmers to on/off state. I used to be able to do that back in May / early June (I had an error upgrading and it wiped my system and of course I didn’t have a backup then so had to recreate the rules).

Please let me know any thoughts or additional information I can provide. Thanks for the help.

The error looks like its associated with security classes. In the controller settings you should set the security to disabled.

That would make sense. I was starting to get ready to migrates die locks so I bet I turned it on when I rebuilt my system. Do I need to exclude and rediscover all my nodes since they were added with security on? Thanks

So even after removing the security class, restarting OH2 and excluding/including a test node (Node 49) I’m still seeing a lot of errors including with the controller?

2016-07-20 07:19:03.099 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Timeout while sending message. Requeueing - 2 attempts left!
2016-07-20 07:19:08.101 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Timeout while sending message. Requeueing - 1 attempts left!
2016-07-20 07:19:13.104 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Timeout while sending message. Requeueing - 0 attempts left!
2016-07-20 07:19:18.108 [WARN ] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Too many retries. Discarding message: Message: class=RemoveNodeFromNetwork[0x4B], type=Request[0x00], priority=High, dest=255, callback=0, payload=05 FE
2016-07-20 07:19:20.565 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘zwave:device:155eff456fc:node49’ to inbox.
2016-07-20 07:19:20.575 [ERROR] [WaveSerialHandler$ZWaveReceiveThread] - Protocol error (CAN), resending
2016-07-20 07:19:20.576 [WARN ] [rialmessage.IdentifyNodeMessageClass] - Got IdentifyNodeMessage without request, ignoring. Last message was SendData.
2016-07-20 07:19:25.575 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 49: Timeout while sending message. Requeueing - 2 attempts left!
2016-07-20 07:19:25.582 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 49: Got an error while sending data. Resending message.
2016-07-20 07:19:30.587 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 49: Timeout while sending message. Requeueing - 1 attempts left!
2016-07-20 07:19:30.591 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 49: Got an error while sending data. Resending message.
2016-07-20 07:19:32.712 [ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 49: Node advancer: Retries exceeded at DYNAMIC_VALUES
2016-07-20 07:19:32.732 [ERROR] [WaveSerialHandler$ZWaveReceiveThread] - Protocol error (CAN), resending
2016-07-20 07:19:32.733 [WARN ] [l.serialmessage.SendDataMessageClass] - Node 255 not found!
2016-07-20 07:19:37.730 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Timeout while sending message. Requeueing - 2 attempts left!

And this test rule is still not generating any entries in the log file:

rule "Light Test"
when
Item Light_GF_Dining_Main changed
then
logInfo(“Dining Room”, "Light = ",Light_GF_Dining_Main.state)
if(Light_GF_Dining_Main.state==ON) {
logInfo(“Dining Room”,“Light On”)
} else {
logInfo(“Dining Room”,“Light Off”)
}
end

It’s impossible really to tell what is causing this. Id need to see a longer debug log…

Thanks Chris, I’ll generate a full debug log tonight and send it over.

Feel free to email it if you like - it’s probably better than trying to put it on the forum with the restrictions here…

@chris That’s what Google Drive is for :slight_smile: Thanks. - Startup Debug

Sorry for the delay…

I had a look through the log, and there’s nothing obviously wrong that I can see. There are a few errors - just one timeout though and nothing systematic. Node 49 completes initialisation ok…

All in all I don’t really see any real issues in this log at least…

Chris

No worries, and thanks. Heading out of town for a bit so will have to do some specific use case debugging when I get back.