Z-Wave battery devices issues in general

vespaman · April 23, 2016, 8:23am

I am having so much trouble with battery devices, that I am wondering if I’m missing something?

I used to have a Vera until I decided to try out oh2+zwave binding some months ago. And while most things are so much better, battery devices are not. I don’t know if I am missing anything but in essence, all battery devices struggle unless I’m very close to the controller.

I did have set-up issues also with the Vera for battery devices, but not this much, so I figure I’m doing something wrong.
I have about 10 battery devices, and I think maybe one or two is working as they should. The network has about 60 nodes, so mesh is good.

I am now trying to get a wall controller to work. And as long as I’m about 3 meters away from the gen5 stick, all is good. But if I try on a different floor, nothing.
I’m sending NIF and regular key press, nothing finds its way into the zwave (debug-) log.

So I figure that if I move a working device out of the direct path of the gen5 stick, some network update needs to happen before the signal finds its way back to the stick. But what? How can I trigger this?

chris · April 23, 2016, 8:31am

A NIF is not routed, so will only work if it’s close to the controller.

It sounds like the wakeup is not set on your devices. You must initialise the device with it close to the controller. OpenHAB should initialise the wakeup when it first initialised the device, but it’s always possible (I guess!) that this isn’t happening - although it would be very strange if its not working on a number of devices.

So, the question is - did you iniitalise the devices close to the controller, or did you take the stick out of the controller to the device, include the device, and then take the stick back to the computer and plug it in and run openHAB. If so, this won’t work - the device must be configured before it’s moved to the final position.

You can check the wakeup configuration in HABmin - make sure the target node is set to the controller address.

vespaman · April 23, 2016, 8:55am

I have tried sending NIF close to the computer where the stick is, and it seams to work. If I leave the device close to the computer/stick it works. With wake ups as well.
But once I take it away, I cannot get it to work. No sign of it in the logs.

I am currently testing with one node, a wall controller, where battery is updating, and scene is updating. So I’m thinking it is set-up correctly. But once moved away, nothing. The node is associated with the controller on key press. [quote=“chris, post:2, topic:10022”]
You can check the wakeup configuration in HABmin - make sure the target node is set to the controller address.
[/quote]
In habmin it only says wakeup period, no target. Maybe I missed it when doing the device updates in database?

chris · April 23, 2016, 9:02am

Which version are you using?

The target actually gets set at the same time as the period, but I’m pretty sure that in OH1 it’s shown in HABmin (but it’s been a while since I’ve used OH1). In OH2, only the period is displayed I think…

Is the device completing initialisation? What is in the XML file? What is in the log?

Again, a NIF will not be routed - never. So, if all your device is sending is a NIF, then it won’t work when you move it away. I don’t know the device, but maybe it does wakeup differently than NIF (ie uses a different button sequence). I’m just guessing of course as I don’t know your system.

Maybe you should set the wakeup to a low number and then see if it works. This will ensure the device sends a wakeup periodically and you won’t have to rely on the NIF.

vespaman · April 23, 2016, 9:19am

I’m on OH2, habmin 1.4. Never tried old OH, coming straight from Vera.

Here’s what I do:
I’m sending NIF close to the computer/stick. A couple of them, with 10 seconds apart.
Node is reporting battery on wakeup when close to the computer/stick.
Node is sending scene number on single/double click when close to the computer/stick.
I leave it for some time, see that it updates on wakeups.

Then I move the wall controller to my office, since I’d like to create some rules for the scenes. But here I get Nothing in logs. I leave it over night hoping some routes needs updating etc.
But still, it will not work.

I bring it back to the “server room” (it is really more like a closet!) where the computer/stick is, and it works again.

I have now set 10 minutes on most of my battery nodes, and they are all with the computer/stick. I’ll see if any of them survives a move away.

vespaman · April 23, 2016, 12:25pm

OK, so during the day, I have done further tests.

So far, the following devices behaves the same:
ZME_06443 Single Paddle Wall Controller
Everspring HSM02
Aeon DSB05 4 in One MultiSensor

I.e. they work just fine close to the stick/computer - they accepted 10 minute wake up, and are waking as they should. Also reporting works as intened.
If I move them away, to my office they disappears from the network - nothing in the logs, until I bring them close again.

There’s one battery device, Everspring ST814 that works, even in my office, and then there’s one EZMotion that I am currently testing, so it might/might not work.
I’m thinking that the ST814 has direct contact with the stick, maybe has a better radio/antenna than the other nodes.

@chris do you have any suggestion what to look for, or do next?

xsnrg · April 23, 2016, 1:07pm

How far is far away? both from the stick and any mains devices.

vespaman · April 23, 2016, 1:12pm

Mains devices are very close wherever I am in my house, so I’d say never further away from those than about 2 meter.
From the stick, I think maybe 5 meter or so. The stick is in the basement, with concrete between the floors, but it (the stick) is in a place just under the wooden stairs to the upper floor, and if I put the device on the top stair “level” (missing the English word, sorry) just above the stick it seams to work.

vespaman · April 23, 2016, 3:48pm

So, now I can also add EZMotion Express Wireless 3-in-1 Sensor to the (non-working) list.

All these devices worked in Vera set-up, so something is wrong here.

How is the network routes updated on a battery device? Will it find its own routes, and is that what is failing here? Could it be that I need to allow the neighbors to report the (“new”) battery nodes back back to the controller, which in terms decides which will be the proxy for the battery node?
I don’t know enough how the routing tables work in zwave…

chris · April 23, 2016, 4:02pm

All routing is handled by the controller - there’s little information made available at application level, and no way to set routes. The controller should automatically sort this out - it may take time, but it is meant to be able to handle dynamic nodes moving around such as remote controls.

The neighbour list may also take some time to update. Currently I don’t force any update, but from what I see here, the controller automatically updates periodically (no idea how fast).

What does this statement mean? Does that mean that it works if you press the on/off button?

I don’t think you answered this? Can you provide the XML file and the log?

vespaman · April 23, 2016, 4:40pm

OK, I stopped OH, and unplugged the stick, since I think it sometimes help, and got this on the EZMotion (node 53);

17:51:07.433 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 20 01 80 ED C5 7B FD EC E5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F9 
17:51:07.435 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
17:51:07.435 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 20 01 80 ED C5 7B FD EC E5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F9 
17:51:07.435 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 20 01 80 ED C5 7B FD EC E5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F9 
17:51:07.436 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=GetRoutingInfo[0x80], type=Response[0x01], priority=High, dest=255, callback=0, payload=ED C5 7B FD EC E5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
17:51:07.436 [DEBUG] [almessage.GetRoutingInfoMessageClass] - NODE 53: Got NodeRoutingInfo request.
17:51:07.436 [DEBUG] [almessage.GetRoutingInfoMessageClass] - NODE 53: Neighbor nodes: 1 3 4 6 7 8 9 11 15 16 17 18 20 21 22 23 25 27 28 29 30 31 32 35 36 38 39 40 41 43 46 47 48
17:51:07.436 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveNetworkEvent
17:51:07.436 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 53: Got an event from Z-Wave network: ZWaveNetworkEvent
17:51:07.436 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=GetRoutingInfo[0x80], type=Request[0x00], priority=High, dest=255, callback=0, payload=35 00 00 03 
17:51:07.436 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=GetRoutingInfo[0x80], type=Response[0x01], priority=High, dest=255, callback=0, payload=ED C5 7B FD EC E5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
17:51:07.436 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=GetRoutingInfo, callback id=0, expected=GetRoutingInfo, cancelled=false        transaction complete!
17:51:07.436 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
17:51:07.437 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 53: Node advancer - NEIGHBORS: Transaction complete (GetRoutingInfo:Request) success(true)
17:51:07.437 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 53: Node advancer - checking initialisation queue. Queue size 1.
17:51:07.437 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 53: Node advancer - message removed from queue. Queue size 0.
17:51:07.437 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 53: Node advancer - NEIGHBORS: queue length(0), free to send(true)
17:51:07.437 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 53: Node advancer: loop - NEIGHBORS try 1: stageAdvanced(false)
17:51:07.437 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 53: Node advancer - advancing to FAILED_CHECK
17:51:07.437 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveInitializationStateEvent
17:51:07.437 [DEBUG] [g.zwave.internal.ZWaveNetworkMonitor] - NODE 53: Network initialised - starting network monitor.
17:51:07.437 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 53: Got an event from Z-Wave network: ZWaveInitializationStateEvent
17:51:07.437 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 53: Node advancer: loop - FAILED_CHECK try 0: stageAdvanced(true)
17:51:07.438 [DEBUG] [rialmessage.IsFailedNodeMessageClass] - NODE 53: Requesting IsFailedNode status from controller.
17:51:07.438 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 53: Node advancer - queued packet. Queue length is 1
17:51:07.438 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 142. Queue={}
17:51:07.438 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Response processed after 9ms/332ms.
17:51:07.438 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:controller:node53' changed from ONLINE: NEIGHBORS to ONLINE: FAILED_CHECK
17:51:07.438 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 141

But the node is still not visible until I bring it to the stick/computer.
I guess, I might not have waited long enough, only a few days. But then again, on Vera it would work, most of the time, after a few hours.

The device that I started with, is a wall controller, and on that, I can associate the buttons with a particular device. I have set the controller as receiver. The button I press, is one of the paddle buttons. And as I have written many times, it only works if I am very close to the stick/computer.

Sure. I mailed the complete log since last startup. Sorry for it being so big…

chris · April 23, 2016, 4:42pm

Ok - we’d generally been talking about the NIF in the past, and I just wanted to be sure that it wasn’t only the NIF that wasn’t working but also the other buttons on the device…

Got it - thanks. No problem about the size . I’ll take a look shortly…

chris · April 23, 2016, 5:03pm

I can’t see anything (much) wrong, although 2 of the 3 devices you sent me the XML files for apparently have 0 neighbours (node 5 and 33).

The log doesn’t show all the initialisation which would have been interesting as I could have checked the config. If you wanted to delete the XML for one of these nodes and restart, it might be interesting to see the log - I suspect based on what I see that it will show everything being set ok, but I’m happy to check if you wanted to create the log…

The only other thing I can think of is to put the heal code back in. It hasn’t been added to the OH2 codebase yet as I was in two minds whether it did more harm than good, but I can add it and we can see. It does set some routing information, and forces a neighbour update, so it might help. The reason I took it out is often these calls fail, and that causes other issues, and from what I read, the controller should automatically be setting routes…

vespaman · April 23, 2016, 5:06pm

OK, I’ll do that - stop OH, remove the xml, restart, and try to get the full log!

Give me a minute!

vespaman · April 23, 2016, 5:37pm

OK that was one long minute…

I stopped, removed stick and restarted. I removed both 5.xml and 33, but 5 has not been generated.
33 is fresh though!
(in the mail)

vespaman · April 30, 2016, 6:25am

@chris did you have any time to look into the newer logs, or think about a solution? Maybe it is worth a shot to re-add the heal code, just to test? I’d be very happy to test, OH life is rather limited without battery devices…
Nothing has happened during the week with regards to the network, I updated to latest binding yesterday. The two nodes are still without neighbours and the others still does not work correctly.

In Vera, it was possible to read out from each node, both the node list but also the ‘current path’ (or rather, the next hop). I think this would be very useful in the network tool view, but maybe that is not available for the binding?
Also, in the network view, would it be possible to move nodes into more lines (y)? As it is now, all devices that has 1 in the neighbour list is on the same level, even if they are not in contact with 1. It is then impossible to see which other path’s the node has since they are all on a single line.
Mabye a textual representation if nothing else would be enough?

I actually think I might be seeing multiple problems in my set-up regarding battery devices, but the “next hop” problem is very distinct and easy to test (and of course a total show stopper).

chris · April 30, 2016, 8:25am

Sorry - I had a very busy week of travelling (especially thanks to French air traffic controller strikes ).

I did add the heal code back in last week but I’m not sure it’s running properly yet and I’ve not had a chance to test. In any case, I have doubts it will help, but let’s see.

As far as the publicly available information goes, there is no way to do this in the ZWave serial API. I know that Vera had custom firmware since they also had an option to use “Vera routing”. So, as I’ve said many times, there is no way for us to influence the routing - this is all done by the software in the stick.

While I agree that the current drawing isn’t perfect, what would you suggest? Currently the node is on the level related to the number of hops it is from the controller - I could arbitrarily add more levels, but what would that mean? Also, in a large network it would still be difficult to see. I’m open to concrete suggestions.

What I can do is to add the list of neighbours to the mouseover text - at least this would be clear.

Sorry - I don’t think there’s much I can do to help. It’s really strange that battery devices aren’t routing, but this is in the domain of the controller.

One other thought - have all your devices been completely reset since leaving the Vera network?

vespaman · April 30, 2016, 9:38am

No worries! I fully understand that there’s a life outside the z-wave binding!

I can try more with the heal, if it might be working - I set it up at night, but that did not change anything this morning. But I did not have the logs properly set up, so I’m not sure if anything happened.

OK, I figured this might be the case.

How about a circle, with zstick in the middle? A mouse over list would be sufficient though.

If it is all down to the controller, then I guess it must be a bug with the aeon gen5 stick. But I don’t think I’m alone using this one. If heal does not help (I need to verify it is working) I guess I will have to ask Aeotec for advice.

I don’t think I have reset every node before moving to OH, but on the other hand, node 5 was never used prior to OH2, and it is one of the “empty nodes”.

I will try to take another wall controller (same as node 5), and reset it before inclusion, to see if it makes any difference at all (but I am almost certain it will act exactly like the rest of the pack).

I have tried to move node 14 and 12 and 13 away from the controller, since they, according to the network diagram has other routes, but they instantly fail when I move them.

Here’s the current view;

chris · April 30, 2016, 9:45am

Very interesting idea - but not one the current library I use can do (I think). I’ll take a look at this to check though.

You didn’t answer if you completely reset the devices after removing them from your Vera network? Maybe the Vera routing has done something to override the controller routing (this is of course a complete guess).

vespaman · April 30, 2016, 10:45am

I did answer!