Creating a new Z-wave network

Are others of you having any luck creating/adding devices to OH2.2 with either the SNAPSHOT builds pre-2.2 or the released 2.2 binding? (As opposed to people who had an existing network before that)…

I literally can’t get anything to work. The one and only device I’ve managed to get working 100% is a basic plug-in power module. Other devices never add fully, or seem to add fully and only partially work or don’t work at all. I’ve been unable to get a single secure device to add.

It seems unrelated to the Z-wave adapter. I have a Razberry and a Homeseer USB dongle running on my Homeseer system. If I shut down homeseer and move the stick to OH, all of my existing non-secure devices seem to work fine (at least within the bounds of what I tested at the time). I can’t replicate the encryption key from Homeseer, so I have to remove/re-add secure devices. Those never fully joined. OH would “see” them, but they wouldn’t initialize fully and wouldn’t respond to any messages, with security-related errors.

Switching to the Razberry, I can get some devices (non-secure) to add (although it often takes a half dozen exclusions/inclusions to work), but not a single one except that GE ZW4201 will generate events. Statuses never update, even from hardwired devices. (Across other plug-in dimmer and appliance modules, and GE, Cooper and Linear switches) Sensors add correctly, but the created items never get updates. I can see logging when adding/removing devices, but nothing at all gets logged with the zwave binding in DEBUG (into events.log or the OH logs) for status changes. Same with turning on or off the GE module – I get a dozen or so log lines every time, nothing else (even if they look added) generates anything.

WIth Z-Way instead of the OH binding, everything “works”. Secure devices add, devices report statuses to Z-Way, so its not the physical environment or the Razberry. I can even interact with them in OH using the Z-Way plugin, although it seems to have a very limited sense of what channels ought to exist for a given devices, so I can’t really use it for “production” (like battery levels aren’t reported for anything).

For a slew of reasons I’m trying to get off Homeseer, and the Z-wave devices are the only thing I can’t get working even remotely. I’m wondering if others have had recent success or if anyone has seen these sort of pervasive problems and have had an “ah ha, the docs don’t say it but you need to _____” sort of moment with it.

Worst case, I’ll just eventually write a Homeseer binding and keep everything on there, but I’ve got a couple other ones I want to write as a higher priority, so I’d really like to figure out why this isn’t working. Or even ideas for troubleshooting.

Are you running with Chris’s development branch of the zwave binding? The mainline version of the binding does not support secure devices. See OH2 Z-Wave refactoring and testing... and SECURITY

Describe your start to finish process you are following. It should be something like:

  • Install the Zwave binding
  • Create a Serail Thing to connect to the controller
  • Go to the Inbox and kick off a scan for new Zwave devices
  • Select a Thing from the Inbox and accept it
  • Create an Item
  • Link the Item to a Channel on the Thing
  • If the Thing in the Inbox shows up as Unkown and it is a battery powered device, wake up the device multiple times until the binding can detect what it is. If it isn’t a battery powered device, it might not be in the zwave database yet and it needs to be added.

I can go even a step before that. In an attempt to get it working, I usually start from a truly-clean slate, including in the Z-wave controller.

  • Use Homeseer to do a forced exclusion on the devices in question (since OH is usually in a weird state)
  • Hard reset the controller via OH, or via the physical button on the Razberry
  • Reflash SD card with Openhabian
  • Wait a looooong time
  • Use the openhabian-config tool to set up the serial/bluetooth module configuration settings on the Pi so that the serial port for the Razberry (or the HS dongle) correctly initializes and sticks to /dev/ttyAMA0
  • Configure OH to do the easy-linking, so I don’t have to manually link everything.
  • At this point if I install Z-Way, I have no issues. I can continue with the Z-Way binding and things work, I just get incomplete sets of channels for most of the devices (no battery statuses, I can’t get the last notification value for my locks, etc)
  • Using Z-wave, install HABMIN (I find it easier than PaperUI for doing exclusions)
  • Install the Z-Wave binding from Paper UI
  • Create the Z-wave controller thing, point it at /dev/ttyAMA0
  • At this point if I didn’t do the hard reset, if I do a discovery on the Zwave binding, the old devices show up. They end up generally just as non-working as they previously were, which is why I took to doing a hard reset. Of note, if I previously added them to the controller with Z-way or Homeseer in the case of the USB dongle, they work “better”, although I can’t say they all worked because I have a ton of devices on my Homeseer and I didn’t go through them all. Secure ones obviously don’t. I also tested the opposite – insecure devices added in OH work fine in Z-Way, so I think inclusion is “working” relative to the controller itself. Another note – network-wide never works with OH. I have to bring the device in here. With Z-Way or Homeseer, I can add devices anywhere – even sure ones – without issue. I think the core issue there is timing related. HS and Z-Way add devices almost instantly – the back-and-forth requests to get the device info and status fly by in a blur, and OH takes 15-30 seconds each. That means most battery devices just never add correctly. If I keep waking them up, OH seems to start the polling over, it finds dupe channels, seems to remove them and start the whole process over again, so it never gets any farther.
  • Do a “true” discovery. I can see on the LED that the Razberry goes into inclusion mode. Nothing in the logs.
  • Do an inclusion on the device. Once in a blue moon the device just show up identified properly. Most of the time it says its unidentified, and if I do a delete and add again, when it pulls from the controller the second time, it sets up correctly. Sometimes I have do do the delete/add multiple times to get it to work, and some devices I just have to exclude and re-add to get them to work. They get a new node id at that point, and it seems to get beyond whatever got stuck. (Of note here, even with battery devices, the full negotiation is always finished in that first inclusion with the other systems.)
  • The GE power module works for me at that point, generally. I usually have to add it a couple times to get it to come up right, but when I do, it’ll both control and update status as a result of local control
  • No other devices work. My hardwired switches add, but are unresponsive and no events get generated.
  • My door locks (Kwikset) will generally show up, but won’t work. Having done it a bunch of times, I think that may be similar to the other battery devices, only made worse because of the security handshaking. It seems to sit and struggle trying to get all the info it needs, times out, the inclusion mode times out and it gets wedged in a broken state. Until today, I was running the dev branch, now I’m running the 2.2 release one. I haven’t tried the secure inclusion today because I have to remove the unit from a door and bring it in here. That’s more of a weekend test. The installed version today does have configuration settings for security. Are those there and not hooked up in the mainline?
  • Some devices (like my Aeotec minimotes) show up, seem to have added correctly, but never log any events. I can’t tell from the logs if the binding gets the event and isn’t passing it to OH, or its not getting it at all. The logging for the events for the GE module seem to come from OH, so I’m assuming it goes controller->binding->channel->item, and only the last step is doing any logging. (The log package for them is always under org.openhome.event, not org.openhome.binding.zwave)

How long are you waiting for devices to be identified by the binding before trying stuff, especially with battery powered devices? Are you waking battery devices up multiple times when they show up in the Inbox as Unknown?

That’s my understanding. You still have to use the dev branch for security.

Use http://docs.openhab.org/administration/logging.html#logging-into-separate-file to configure the zwave binding to log at a debug level and log to a separate file. You can then load the file into the zwave log viewer in Habmin I think which can help make it easier to read.

Look for errors, anything having to do with a node you are working with.

You will need these logs anyway for @chris to help with once he gets back from holiday.

It is hard to tell how much time you are giving when you try things or what state things end up in but it does look like there is a lot of thrashing around.

I haven’t done it with the 2.2 release yet, but I run in Docker and pretty much every time I upgrade I’m starting over from scratch with Zwave because all my Things get wiped out (I’m too lazy to do a proper upgrade right now). And it has not been that long ago that last upgraded.

The way I understand it, at least with the USB controllers, inclusion is completely separate from the binding. In fact, when I pair a device with my controller I actually remove the dongle from my machine, take it to the device, press the button on the controller, press the button on the device and watch for the flashing lights. When I come back to OH, the device shows up in the Inbox as a new node. If it is a battery powered device, I then have to wake up the device a number of times (sometimes 6-10 times) but eventually it shows up with the correct information. At this point it always works without problem for me, so I don’t think I’ll be much help.

Yeah even waiting overnight they don’t start working. Battery devices or hard-wired, it doesn’t really matter. Repeatedly waking up will eventually turn a battery device from “unknown” to its “known” state, but they still end up only partially functional, or non-functional. Its bizarre. I’ve got a handful of devices I added yesterday when I was testing it on this network, and this morning the GE module is still the only one completely working. Although even that seems like it may just be the events working. The status says its not doing routing, but I can see in Homeseer that the other one of these I have does support routing. So I’m not really sure that one initialized properly either.

The waiting thing doesn’t make sense, other than a band-aid for an issue with the binding, because none of the other Z-wave stacks require it. As I mentioned, even a battery powered secure device at a remote spot on the network adds immediately with the others, as long as there’s routing nodes that can reach it. No needing to wake things up repeatedly, or need to wait, etc. Even my locks (which appear to the the chattiest Z-wave devices I’ve got) only take a few seconds to be fully associated.

This snippet from the logs just a bit ago is also interesting:

2017-12-20 07:07:06.192 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Stage PING. Initialisation retry timer triggered. Increased to 1800000
2017-12-20 07:07:06.195 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Node advancer - PING: queue length(0), free to send(false)
2017-12-20 07:07:06.199 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Initialisation retry timer started 1800000
2017-12-20 07:07:06.202 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Node advancer: Retries exceeded at PING
2017-12-20 07:07:06.206 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Retry timout: Can't advance
2017-12-20 07:08:22.304 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling...
2017-12-20 07:08:22.307 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling zwave:device:e100d5c1:node2:scene_number
2017-12-20 07:14:01.175 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Polling...
2017-12-20 07:14:01.178 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Polling deferred until initialisation complete

Its interesting because there is no node 22 or 23. I flipped the connection over to Z-way and it doesn’t show them, so they aren’t coming from the controller. Also weird.

All I can say that the way the zwave binding was written, which was through reverse engineering the Zwave protocol before Sigma opened it up, it makes a difference.

I’m no Zwave expert so I can not provide any further assistance except to suggest capturing logs and ping chris after the holidays.