Zwave network not updating

Once I added my eight or so node things stopped working for certain noes and all others added are not connected to node1 (controller) even though the controller added them. Is this a zwave network issue?

Don’t pay too much attention to the network configuration graphic in HABmin. It doesn’t work properly (atm).

At least do not conclude that your devices don’t work because the picture make you think so.

Yeah, I was just using it because it’s the only thing I have to go off. I’m assuming my network is not connected because devices are not working and in some cases I can’t add new ones which I’m assuming is because they are far away from the zstick.

Something is really up. I can turn lights on from the UI but when I manually turn them on the ui doesn’t update. I see logs. It’s like I can’t receive updates for some reason…

This could likely be the reason. There ist a “network wide inclusion mode” available, but it’s far more reliable to include devices near the controller(=zstick). Which zstick do you use? The Aeon G5 stick is battery operated, so you can include the device even if it’s already at it’s final position. Just take the stick near the device, include it and then put the stick back into your OH-hardware (raspberry, Laptop, whatever). That’s the easiest way.

That’s a little bit too imprecise. Which devices do not work? Are they mains powered or battery powered (battery powered devices are a little bit more “special”…)? What exactly means “do not work”? Inclusion didn’t work? Or are they properly included and operation do not work? Do you have logs (debug logs preferred…)?

Thanks, I realized I could include them by hand so I did that for the two that wouldn’t include and they worked first time but I’m assuming that won’t help when I move the stick back to it’s original location?

What I mean by doesn’t work is I can see it in OH but when I trigger it (switch) it doesn’t turn on, when I open a contact switch it doesn’t switch. Last night I was able to turn certain lights on through the interface but if I manually turned them on the interface didn’t update to indicate the change, now those same lights won’t turn on from the interface either. I have powered switches throughout the house and a bunch of battery devices (motion, contact, etc) but the switches are placed that they should all be within 15’ of each other to create a mesh. Also, these all worked under Smartthings so I’m guessing it’s something with either the software or network. I was hoping a heal last night would fix it but it’s not clear that even ran.

Here are some logs, here is me switching devices from the interface.


2017-02-23 07:18:28.928 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Command received zwave:device:8d5f3bba:node4:switch_binary --> OFF
2017-02-23 07:18:28.929 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 4: Creating new message for application command SWITCH_BINARY_SET
2017-02-23 07:18:28.929 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2017-02-23 07:18:28.929 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2017-02-23 07:18:28.930 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 04 03 25 01 00 25 5B BB
2017-02-23 07:18:28.930 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 4: Sending REQUEST Message = 01 0A 00 13 04 03 25 01 00 25 5B BB

2017-02-23 07:18:33.932 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 03 00 16 EA
2017-02-23 07:18:33.933 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 4: Sending ABORT Message = 01 03 00 16 EA
2017-02-23 07:18:33.933 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 03 00 16 EA
2017-02-23 07:18:33.933 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 03 00 16 EA
2017-02-23 07:18:33.936 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 4: Timeout while sending message. Requeueing - 2 attempts left!
2017-02-23 07:18:33.936 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 4: Node is DEAD. Dropping message.

Another light

2017-02-23 07:19:41.150 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 03 00 16 EA
2017-02-23 07:19:41.151 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 17: Sending ABORT Message = 01 03 00 16 EA
2017-02-23 07:19:41.151 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 03 00 16 EA
2017-02-23 07:19:41.151 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 03 00 16 EA
2017-02-23 07:19:41.153 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 17: Timeout while sending message. Requeueing - 2 attempts left!
2017-02-23 07:19:41.153 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 17: Node is DEAD. Dropping message.
2017-02-23 07:20:14.653 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Polling...
2017-02-23 07:20:14.653 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Polling deferred until initialisation complete
2017-02-23 07:20:24.381 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Stage PING. Initialisation retry timer triggered. Increased to 1800000
2017-02-23 07:20:24.381 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Node advancer - PING: queue length(0), free to send(false)
2017-02-23 07:20:24.382 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Initialisation retry timer started 1800000
2017-02-23 07:20:24.382 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Node advancer: loop - PING try 2: stageAdvanced(false)
2017-02-23 07:20:24.382 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Node advancer: PING - send NoOperation
2017-02-23 07:20:24.382 [DEBUG] [ndclass.ZWaveNoOperationCommandClass] - NODE 8: Creating new message for command No Operation
2017-02-23 07:20:24.382 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Node advancer - queued packet. Queue length is 1
2017-02-23 07:20:24.382 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2017-02-23 07:20:24.383 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2017-02-23 07:20:24.383 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 08 00 13 08 01 00 25 B4 7C
2017-02-23 07:20:24.383 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 8: Sending REQUEST Message = 01 08 00 13 08 01 00 25 B4 7C
2017-02-23 07:20:24.442 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 7: Stage PING. Initialisation retry timer triggered. Increased to 1800000
2017-02-23 07:20:24.442 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 7: Node advancer - PING: queue length(0), free to send(false)
2017-02-23 07:20:24.442 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 7: Initialisation retry timer started 1800000
2017-02-23 07:20:24.442 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 7: Node advancer: loop - PING try 2: stageAdvanced(false)
2017-02-23 07:20:24.442 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 7: Node advancer: PING - send NoOperation
2017-02-23 07:20:24.442 [DEBUG] [ndclass.ZWaveNoOperationCommandClass] - NODE 7: Creating new message for command No Operation
2017-02-23 07:20:24.443 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 7: Node advancer - queued packet. Queue length is 1
2017-02-23 07:20:24.443 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2017-02-23 07:20:29.386 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 03 00 16 EA
2017-02-23 07:20:29.387 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 8: Sending ABORT Message = 01 03 00 16 EA
2017-02-23 07:20:29.387 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 03 00 16 EA
2017-02-23 07:20:29.387 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 03 00 16 EA
2017-02-23 07:20:29.390 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 8: Timeout while sending message. Requeueing - 0 attempts left!
2017-02-23 07:20:29.390 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 8: Node is DEAD. Dropping message.
2017-02-23 07:20:29.390 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2017-02-23 07:20:29.390 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 08 00 13 07 01 00 25 B5 72
2017-02-23 07:20:29.390 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 7: Sending REQUEST Message = 01 08 00 13 07 01 00 25 B5 72

None of the devices are marked as Dead in HABmin or the paper interface.

From my point of view it looks like commands are getting lost, or stuck on some device that isn’t connected to the controller. Maybe it thinks it’s connected to it so it sends it but it’s not within range so it gets lost and stuck? Not sure how to resolve that though, there doesn’t seem to be any way to manually heal the network.

So I booted up the demo of homeseer because they have good zwave tools and looked at the nodes, a lot didn’t have neighbors so I “fixed the network” and it added a whole bunch of the always on ones. That seemed to help a little ( I can now control most things from the interface) but the interface still does not update (devices are not sending commands) so it helped but not a fix. This makes me think it’s really a network issue, when I turn a switch on the message is never actually getting to the zwave controller thus the software. Is there anything else that could cause this?

I did some searching and other people have had similar issues and they suggested starting over. I probably went about it the wrong way so maybe I’ll clear the network and add all of my hardwired devices first to make sure there is a network present before adding the battery ones. The question I still have is if I add them by walking around with the controller will they be able to reach the controller once I plug it back into the computer? If not, what happens?

Is openHAB in the “lifeline” or “controller” group?

Others, including me, are having the same problem:

I reported it in this thread - you can find some more info there:

I don’t think it’s in any groups, I didn’t add anything.

Sorry to say that but guess what: The heal doesn’t work at the moment. :frowning: It has worked before, but is deactivated in the current binding. Only the development branch of the binding has this feature included. It will come back to the stable version as soon as the development version is tested.

Other than that, the logs don’t look good. You should ping Chris (the developer of the binding) and ask for support.

I think I’m going to hard reset and start over now that I understand how the network works better. Two of my main powered switches are reporting

 1239 2017-02-23 09:05:00.362 [DEBUG] [almessage.GetRoutingInfoMessageClass] - NODE 9: No neighbors reported
 1268 2017-02-23 09:05:00.372 [DEBUG] [almessage.GetRoutingInfoMessageClass] - NODE 13: No neighbors reported

So that’s probably the reason nothing works. I’m going to try and add all my powered nodes one by one starting with the closest to where the computer is and test as I go. If everything works after that I’ll add the battery powered devices after.

Assuming I get this up and running I might have to start contributing. The developers have done some amazing stuff but it’s obvious they are limited on resources and I would love to see better zwave tooling in OH. Currently I’m using HomeSeer to diagnose zwave issues which has pretty good tools, replicating some of this over to OH would be extremely valuable.

It will work. It is only inclusion that has to be within direct range of the controller. If you have one or more mains powered zwave devices between it and the controller the mesh networking will relay the messages. I think four hops is the limit.

Not all zwave devices report state changes back to the controller automatically. In particular the GE switches are known not to report state. I have a switch from Linear that also does not report. There is a polling period I think where the binding will poll periodically for the current state (its a slow poll on the order of a minute so as not to overwhelm the network) but that is of limited use. What devices are you working with?

Indeed, particular when you realize that the bulk of the binding was developed through reverse engineering the zwave protocol. It has only been openly published for a few months at this point.

One of my switches doesn’t report anything but the others do (Cooper and Homeseer). Here is an example homseer message that was received when I turned the light on.

2017-02-23 19:13:50.017 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 19 00 49 84 05 13 04 10 01 5E 86 72 5A 85 59 73 25 27 70 2C 2B 5B 7A EF 5B 97
2017-02-23 19:13:50.019 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-02-23 19:13:50.020 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 19 00 49 84 05 13 04 10 01 5E 86 72 5A 85 59 73 25 27 70 2C 2B 5B 7A EF 5B 97
2017-02-23 19:13:50.020 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 19 00 49 84 05 13 04 10 01 5E 86 72 5A 85 59 73 25 27 70 2C 2B 5B 7A EF 5B 97
2017-02-23 19:13:50.021 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 05 13 04 10 01 5E 86 72 5A 85 59 73 25 27 70 2C 2B 5B 7A EF 5B
2017-02-23 19:13:50.021 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 5: Application update request. Node information received.
2017-02-23 19:13:50.021 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 5: Starting initialisation from DONE
2017-02-23 19:13:50.021 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@6c3b5f0c already registered
2017-02-23 19:13:50.021 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=6, callback=90, payload=06 03 26 01 FF
2017-02-23 19:13:50.022 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 05 13 04 10 01 5E 86 72 5A 85 59 73 25 27 70 2C 2B 5B 7A EF 5B
2017-02-23 19:13:50.022 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationUpdate, callback id=90, expected=SendData, cancelled=false      MISMATCH
2017-02-23 19:13:50.024 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0B 00 04 00 05 05 5B 03 B4 00 02 1E
2017-02-23 19:13:50.027 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-02-23 19:13:50.027 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0B 00 04 00 05 05 5B 03 B4 00 02 1E
2017-02-23 19:13:50.027 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0B 00 04 00 05 05 5B 03 B4 00 02 1E
2017-02-23 19:13:50.028 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 05 05 5B 03 B4 00 02
2017-02-23 19:13:50.028 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 5: Application Command Request (ALIVE:DONE)
2017-02-23 19:13:50.028 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 5: Starting initialisation from DONE
2017-02-23 19:13:50.028 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@6c3b5f0c already registered
2017-02-23 19:13:50.028 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 5: Incoming command class CENTRAL_SCENE
2017-02-23 19:13:50.028 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 5: Received CENTRAL_SCENE command V2
2017-02-23 19:13:50.028 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 5: Received scene 2 at key 0 [Single Press]
2017-02-23 19:13:50.028 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2017-02-23 19:13:50.029 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-02-23 19:13:50.029 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint = 0, command class = CENTRAL_SCENE, value = 2.0
2017-02-23 19:13:50.029 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Updating channel state zwave:device:8d5f3bba:node5:scene_number to 2.0 [DecimalType]
2017-02-23 19:13:50.029 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 6: Transaction not completed: node address inconsistent.  lastSent=6, incoming=255

It looks like it got the signal correctly but the interfaces don’t update.

The next step is to trace the event through the system.

Do you see anything in events.log indicating that the Item linked to the Thing for this node is being updated?

What is your sitemap definition for this Item and how are you accessing it?

Okay, figured it out. Basically my battery powered devices didn’t have neighbors thus why they didn’t send events. I tried everything in OH and nothing was working so I downloaded the HomeSeer demo and optimized each node after waking it up. After that I ran an entire network optimization and 40 minutes later all nodes react instantly and my network is much more filled out now.

As great as OH is some products just do certain things better, if HS wasn’t so expensive I’d buy it just for their zwave tooling.

Sounds great!
Can you explain and share the steps to do this?
Thanks in advance