Z-Wave: Some questions/issues

Hi,

I’ve been checking with some different Z-Wave installations and I encountered different problems/questions but I keep them in the same post just in case they are related somehow.

Note: I’m using 2.5.7 version (no longer the latest one :stuck_out_tongue: ).

  1. I leaved the default 2AM healing configured in all installations and I observed that it triggers a healing process exactly at 2:44 AM. This leads to a lot of Z-Wave traffic and collisions (installations are next to each other). Is it any reason of the “delay” between 2AM setting and the real 2:44 AM execution?
  2. About the healing, I saw that there are other recent post saying that the healing is not recommended anymore? Should healing be disabled by default?
  3. Also regarding the healing, the installations are pretty static and without moving/adding any device. It is safe to disable it? Is there any way to trigger a weekly or monthly heal?
  4. Is there any problem if openhab performs a reset in the middle of a healing? I’ve configured a nightly reboot just to ensure everything is cleaned periodically but I’m concerned that if the heal process takes a lot of time, it might interfere.
  5. Once, one installation stopped responding, but all devices looked ONLINE. Checking the .xml files, all off them look with homeid as zeroes (network_00000000__node_1.xml). I restarted the embedded and they worked again.
  6. Checking the Zniffer for problems I’ve found some that node 1 is communicating no node 1. Is it normal?
  7. I had an issue with a Danalock v3 device where it stopped working. The reason seems that the “lock” command class is not found, but I’m not sure why it was lost (it were working properly):

2020-08-24 12:41:44.761 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 35: Command received zwave:device:3cdbad41:node35:lock_door → OFF [OnOffType]
2020-08-24 12:41:44.763 [WARN ] [ng.zwave.internal.converter.ZWaveDoorLockConverter] - NODE 35: Command class COMMAND_CLASS_DOOR_LOCK not found
2020-08-24 12:41:44.764 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 35: No messages returned from converter

  1. I got a final error when configuring the autolock parameter with danalock. I’ve restarted and it worked properly again, but I couln’t figure what is the problem and it might help you somehow:

2020-08-21 14:06:55.359 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - Value format error processing user code null
2020-08-21 14:06:55.363 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - Value format error processing user code null
2020-08-21 14:06:55.366 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - Value format error processing user code null
2020-08-21 14:06:55.371 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - Value format error processing user code null
2020-08-21 14:06:55.380 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - Value format error processing user code null
2020-08-21 14:06:55.388 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - Value format error processing user code null
2020-08-21 14:06:55.392 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - Value format error processing user code null
2020-08-21 14:06:55.396 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - Value format error processing user code null
2020-08-21 14:06:55.400 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - Value format error processing user code null

Thank you!

What do you mean with

?

No. Healing serves a purpose: if you change the location of things, e.g. including devices in proximity to your controller and then move them to their correct destination, the neighbors will change. Healing will discover that and amend the network information accordingly. IF you have a static network with no changes for some time so all the network information is correct/known to the controller, you may disable healing. But keep in mind, that it might need to be enabled again for a period of time if you change locations of things or add new things.

As far as I know you can only change the start time per day, nothing more. Everything beyond that needs manual intervention.

Good question. Honestly, I don’t know. Personally I would time it so the two processes do not interfere.

Node 1 is your controller. Normally the controller should have some neighbors to talk to. It should have at least ONE neighbor to talk to, otherwise your network would not work at all.

The other questions I cannot answer, others here will add to that, I’m sure.

1 Like

I mean that there are two houses next to each other so there are packets seen by the other devices

Yes, that’s for sure but it seems strange to me that node 1 sends information to itself. Why this can’t be done internally by the chip/binding? I’m just curious.

Thank you

This what inclusion and Home id are about.
zwave functions, not openHAB

You might view that as a broadcast, that every nearby node can hear, but recognizes that it is a special message and not addressed to any particular node. “Hey, anybody out there?”

1 Like

Yes! I know that with the HomeID, the installations should not be affect by the other. I just told this to make it clear that the healing at the same time of two nearby installation can create a huge amount of packets sent “at the same time”.

It is possible. Nevertheless, if no one in the zwave network would do anything with this packet, isn’t the controller spamming unnecessary messages out there? Isn’t it just wasting z-wave “bandwidth” without any reason?

Perhaps that is why the healing start time can be changed.

Yes! But if the default configuration is always set at 2AM, doesn’t it is a bit dangerous? Do I need to know if my neighbour is using Openhab? Also, if it doesn’t start until 2:44… is there any reason? Is Z-Wave binding doing something internally between 2:00 and 2:44? Is this delay caused from some bad configuration?

Some questions are just to know the real “issue” behind that and not just trying workarounds without knowing what am I doing. I think it’s better to ask so maybe Chris finds out some underlying issue or some improvement, rather that just “turning it off and on”.

This is a zwave protocol design question.
Nevertheless, what makes you think no one does anything with it? At the very least, the controller can hear its own “echo” and know the radio is working. Seems like a smart thing to do when beginning a heal. I expect the zwave rules call for an acknowledgement (to itself) as well, further validating radio function.
I don’t know and I’m not interested enough to find out - but you clearly are, have a search into silabs documentation perhaps.

For example, if you discover that the controllers support healing on demand or schedule other than daily, then you can ask more meaningful questions about how to do that in openHAB environment.

1 Like

Only if your devices are right next to each other. I have issues just reaching devices in my front yard with a repeater on the front porch. This network is intentionally designed to be low power ti avoid such issues.

I want to add a new case.

  1. DanalockV3 (node 18) “suddenly” stops working until openhab process is restarted (systemctl restart openhab2).
    1. 2020-08-31 18:59:53.774 sending command to Danalock, but it doesn’t appear to be really sent into the Zniffer logs.
    2. 2020-08-31 19:02:35.734 after some trying, I’ve set the “Heal device”. Zniffers shows “Cmd Set Nwi Mode” only.
    3. 2020-08-31 19:03:22.671 execute “Heal device” again. “Cmd Set Nwi Mode” packet again.
    4. 2020-08-31 19:04:20.189 Tried communicating with another device but still nothing shown in Zniffer.
    5. 19:06:13.031 Another device sends a packet to the controller. The controller responds with ACK
    6. 19:06:36.662 Manually force a “Node Info” from Danalock.
    7. 2020-08-31 19:08:13.982 Restart of OpenHAB service.
    8. 2020-08-31 19:09:22.516 Starting of Z-Wave binding log.
    9. 19:10:04.592 Communication successfully from the controller to Danalock.

This shows that the reason for the Danalock not unlocking was the “internal state” of the binding, that prevented from sending any real command to the device.

All related files of the event:

@chris lately I’m testing several cases and trying to keep the traces of everything. If do you think there’s anything extra I can add to make it easier, just tell me.

I add an extra question:

  1. Once all devices finish the healing, there’s a last process where Node 1 tries to communicate with itself (or something similar). Once the attached log is finished, I keep seeing in the Zniffer messages of node 1 asking to itself for a long period of time. Is this a wanted behaviour? I’m not sure if this really improves the network.
2020-09-09 16:51:49.243 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 9: Node advancer - advancing to DONE
2020-09-09 16:51:51.052 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 12: Node advancer - advancing to DONE
2020-09-09 16:53:14.990 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 13: Node advancer - advancing to DONE
2020-09-09 16:53:17.983 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 14: Node advancer - advancing to DONE
2020-09-09 16:53:18.512 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 15: Node advancer - advancing to DONE
2020-09-09 16:53:19.310 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 16: Node advancer - advancing to DONE
2020-09-09 16:53:21.250 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 17: Node advancer - advancing to DONE
2020-09-09 16:54:44.151 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 18: Node advancer - advancing to DONE
2020-09-09 16:54:46.362 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 19: Node advancer - advancing to DONE
2020-09-09 16:54:47.459 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 20: Node advancer - advancing to DONE
2020-09-09 16:54:49.725 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 21: Node advancer - advancing to DONE
2020-09-09 16:54:50.892 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 23: Node advancer - advancing to DONE
2020-09-09 16:54:51.752 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 24: Node advancer - advancing to DONE
2020-09-09 16:54:54.655 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 22: Node advancer - advancing to DONE
2020-09-09 16:54:57.589 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 25: Node advancer - advancing to DONE
2020-09-09 16:56:20.769 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 26: Node advancer - advancing to DONE
2020-09-09 16:56:23.187 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 27: Node advancer - advancing to DONE
2020-09-09 16:56:24.737 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 29: Node advancer - advancing to DONE
2020-09-09 16:56:29.293 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 30: Node advancer - advancing to DONE
2020-09-09 16:56:30.308 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 31: Node advancer - advancing to DONE
2020-09-09 16:56:36.261 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 32: Node advancer - advancing to DONE
2020-09-09 16:56:36.837 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 33: Node advancer - advancing to DONE
2020-09-09 16:56:37.888 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 34: Node advancer - advancing to DONE
2020-09-09 16:56:39.551 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 35: Node advancer - advancing to DONE
2020-09-09 16:56:42.052 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 28: Node advancer - advancing to DONE

I do not have the time to look at it right now, but perhaps the Z-Wave log viewer can provide some hints.

Can you please provide the sniffer log - or at least describe what you mean by this as I don’t know what “asking to itself” means?

I’m also a bit confused about what this log is provided for? What are you trying to show here?

After 16:56:42.052 (last DONE) I’m receiving a lot of “Find Nodes In Range” blocks like those in the line 12561 of the zniffer log. This messages are send from node 1 to node 1, so it looked strange.

Zniffer log

Binding log

Like the previous questions, I’ve been playing with zwave devices and found some strange things to me. Some of them break Z-Wave net and devices stop responding, and some are just questions. I wanted to point them out here so I can get an extra knowledge of how it works and maybe help finding some bugs.

I will take a look at teh log, but this doesn’t sound like something that the binding is doing - this is probably just the controller.

Ok, that’s fine, but I don’t understand what you’re asking? What was the point about posting this log?

Did you have a question about it? I’m not sure if there’s something you wanted to know, or if it is just posted for some other reason? It just seems a very strange this to post so I’m a little confused, that’s all.

This was just to “show” that after all Things in the installation report DONE as the stage of the healing process, there’s still a lot of transactions in the controller.

This seems strange to me, but if it’s done internally by the controller I suppose that’s fine. There’s a fuzzy line between the actions done by the binding and the ones done by the controller itself.