OH2 Z-Wave refactoring and testing... and SECURITY

[5iver (Scott Rushworth)]

@DanielMalmgren

Nope, never seen anything from this binding in the inbox that shouldn’t be there

It doesn’t mean you don’t have ghosts. If your node numbers are not sequential, or the gaps aren’t explained by excluded nodes, it’s another sign that they are lurking.

@DanielMalmgren

it’s just the first days after a binding restart I’m experiencing problems

How many nodes? I’m at 110 nodes and it used to take me a full day for things to get back to normal after a restart. After cleaning up some ghosts, it’s now about 5-6 hours. I just remembered another thing… shutdown OH or the binding and unplug the stick. I find an occasional power cycle helps the controller. Restarting the PC may not cycle the USB ports.

[DanielMalmgren]

No, no gaps either

My network is only 15 nodes. I might try unplugging the stick, haven’t done that in quite a while. The server was last restarted some time last year if I’m not misremembering

[chris (Chris Jackson)]

@DanielMalmgren

My experience is that every time I restart either the binding or openhab (something I’ve done way too often last couple of days) a couple of nodes (the ones that don’t have direct contact with the controller) are OFFLINE

It’s unlikely that heal will make any different unless you are changing the topology of the network?

The heal mainly configures the routes between routing nodes - if you haven’t changed the topology, then this shouldn’t need to update. Additionally, it probably only helps return routes where associations are in use - routing from the controller should in most cases not be impacted by the heal if all you’ve done is restart the binding.

[chris (Chris Jackson)]

@5iver

It doesn’t mean you don’t have ghosts.

I think it does doesn’t it? If there are ghost nodes (which I assume you mean nodes that the controller says are there, but aren’t really?) then the binding will definately add them to the inbox.

[mhilbush (Mark)]

@chris

I’m curious about a behavior difference I see in the dev versus master.

After a fresh start of the binding, my Aeon Minimote (DSA03202) shows Offline. The specific message shown is Status: OFFLINE Node not found in Z-Wave network. There is a node.xml file for the device, therefore, it previously was initialized. Since this device never wakes up on it’s own (I believe there are other devices that have this behavior, such as Fibaro button), it will never initialize unless action is taken to manually wake it up.

In the snapshot version of the binding, the device was functional after a restart.

If a button is pressed, the binding logs this.

2017-12-08 09:56:14.271 [DEBUG] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0A 00 04 00 03 04 2B 01 01 00 DD
2017-12-08 09:56:14.272 [DEBUG] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-12-08 09:56:14.273 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=3, callback=0, payload=00 03 04 2B 01 01 00
2017-12-08 09:56:14.274 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=3, callback=0, payload=00 03 04 2B 01 01 00
2017-12-08 09:56:14.274 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=3, callback=0, payload=00 03 04 2B 01 01 00
2017-12-08 09:56:14.274 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - lastTransaction null
2017-12-08 09:56:14.275 [WARN ] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 3: Not initialized (ie node unknown), ignoring message.
2017-12-08 09:56:14.275 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2017-12-08 09:56:14.275 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
2017-12-08 09:56:14.275 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: listening == false, frequentlyListening == false, awake == false
2017-12-08 09:56:14.275 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 7: Node not awake!
2017-12-08 09:56:14.276 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
2017-12-08 09:56:14.276 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing

[chris (Chris Jackson)]

@mhilbush

The specific message shown is Status: OFFLINE Node not found in Z-Wave network.

Without checking the code, I’m pretty sure this means that the node is not found in the list of nodes the device reports on startup. This should be the same in both the dev and master versions.

To check, look at the startup and look for the list of nodes that are discovered…

[mhilbush (Mark)]

@chris

To check, look at the startup and look for the list of nodes that are discovered…

Yes, you’re right.

2017-12-08 10:17:14.564 [INFO ] [col.serialmessage.SerialApiGetInitDataMessageClass] - NODE 1: Node found
2017-12-08 10:17:14.569 [INFO ] [col.serialmessage.SerialApiGetInitDataMessageClass] - NODE 6: Node found
2017-12-08 10:17:14.570 [INFO ] [col.serialmessage.SerialApiGetInitDataMessageClass] - NODE 7: Node found
2017-12-08 10:17:14.571 [INFO ] [col.serialmessage.SerialApiGetInitDataMessageClass] - NODE 8: Node found
2017-12-08 10:17:14.572 [INFO ] [col.serialmessage.SerialApiGetInitDataMessageClass] - NODE 9: Node found

That’s really odd. When I run the Zensys tool, it also doesn’t show up. But, if I press buttons, the Zensys tool reports the presses. I’ve never seen that before.

[chris (Chris Jackson)]

@mhilbush

When I run the Zensys tool, it also doesn’t show up. But, if I press buttons, the Zensys tool reports the presses. I’ve never seen that before.

This is the same as the binding is doing (except it’s reporting an error). It’s kind of strange to me actually - IMHO if the controller doesn’t recognise a device, it probably shouldn’t pass data for it through the serial API, but it does (I’ve seen this myself - I have devices in my test network that I haven’t excluded since I reset the stick, and I’m still getting data from them every few seconds).

[mhilbush (Mark)]

@chris

This is the same as the binding is doing (except it’s reporting an error). It’s kind of strange to me actually

No kidding! It was driving me nuts why it would work after I woke it up. I might never have figured out what was going on. Thanks!

So, the solution was simple. Factory reset the device and re-include it into the network.

I had another weird situation. There was a battery device node that the stick thought existed but didn’t. I tried multiple times without success to do a “Remove failed node” in the Zensys tool.

So, then I used the Zensys tool to do a “Replace failed node” with an unused battery device, then excluded that node from the network. That seemed to work.

[Patrick_Beauchamp]

Hello,

I have a hard time including my kwikset 910 in the network. I have openhabian built with Z-stick5. I’ve read a lot on this forum but i can’t get it work. I have 3 dimmer and 1 power plug working flawlessly!

I installed this addon: org.openhab.binding.zwave-2.2.0-SNAPSHOT. I added the security key to the z-stick.

Last thing i done is removing the thing (kwikset) from habmin, then deleting .xml file. I removed the lock from the network with the z-stick. Reboot openhabian. I added the lock back with the z-stcik, put it back in the pi. (The zwaveLog.pdf start here) Then i added the thing in habmin, node 11. I saw that it didn’t use security so i rebooted openhabian again with no change.

This image is what i got now.

Do i need to edit the .xml file with the security key or something?

I would love that to work so i could be free of my Vera3!

zwaveLog.pdf (97.6 KB)

[mhilbush (Mark)]

@Patrick_Beauchamp

I have a hard time including my kwikset 910 in the network.

FWIW, I’m having exactly the same problem right now.

@Patrick_Beauchamp

I added the lock back with the z-stcik, put it back in the pi.

You can’t do this. The stick needs to be plugged into the computer to do secure inclusion.

[mhilbush (Mark)]

@nolan_garrett

I have figured out a work around for this, at least when using the Aeon Z-Stick Gen5 (white). Maybe it does or does not give a clue to the root cause of the problem. Workaround for secure inclusion failing when a certain threshold of nodes exists in the network:

Thank you for this!!!

I’ve been messing around all afternoon trying to securely include my Kwikset 910 lock with no success. My network has only 5 nodes, but I was unable to securely include my lock in OH. I did a factory reset on the device - no luck. I removed the lock from the door in order to get it close to the controller – no luck. I tried all settings for inclusion mode – Network Wide, High Power, and Low Power - no luck.

Then I decided to try your method. I followed your steps and it worked flawlessly on the first try!

[mhilbush (Mark)]

Try this. It worked for me on the first try.

OH2 Z-Wave refactoring and testing... and SECURITY

I have figured out a work around for this, at least when using the Aeon Z-Stick Gen5 (white). Maybe it does or does not give a clue to the root cause of the problem. Workaround for secure inclusion failing when a certain threshold of nodes exists in the network: Download Zensys Tools (link) Download Aeon Backup tool (link) Copy your network security key from Habmin Shut down OH2 and remove the Z-Stick Place the Z-Stick in a Windows PC Perform a backup of your Z-Stick following the directions i…

[shadowmite (Matthew Fogle)]

Hey Chris, any idea what would cause these errors when trying to set a color item on a RGB bulb?

2017-12-08 17:41:40.820 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Command received zwave:device:c0ffedad:node29:color_color --> 219,68,0
2017-12-08 17:41:40.821 [DEBUG] [ternal.converter.ZWaveColorConverter] - NODE 29: Unknown color mode null.
2017-12-08 17:41:40.821 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: No messages returned from converter

[Patrick_Beauchamp]

@mhilbush

You can’t do this. The stick needs to be plugged into the computer to do secure inclusion.

You are officially my hero! I wasn’t aware of that.

So for people in my situation : I deleted the thing, delete node11.xml, restart openhab and remove doorLock from zwave network with z-stick in hand. Then i plugged back the z-stick to the Pi and played with the daugther till bedtime (45ish minutes). Then i did an inclusion with habmin and voilà! The doorlock appeared and was using security.

Thank you so much and thanks Chris for you time with this addon!

[chris (Chris Jackson)]

It means that there is no “colorMode” defined for the channel. This should (if I remember correctly) be defined in the database - what device is this for?

[DanielMalmgren]

@chris

It’s unlikely that heal will make any different unless you are changing the topology of the network?

Nope. I guess the nodes simply need heck load of time communicating before they work then…

But if you say that a heal is a good thing to do when the topology has been changed, wouldn’t it be a good idea to have a manual heal option anyway? That users could activate when stuff has been moved around in the house…

[chris (Chris Jackson)]

@DanielMalmgren

But if you say that a heal is a good thing to do when the topology has been changed, wouldn’t it be a good idea to have a manual heal option anyway?

Yes, this probably is a good idea. Currently you can do it manually per device, and it is done on startup, but I can add a button to do it at other times. Note that it can cause problems on the network for a while though as it generates a lot of activity…

[5iver (Scott Rushworth)]

@chris

I think it does doesn’t it? If there are ghost nodes (which I assume you mean nodes that the controller says are there, but aren’t really?) then the binding will definately add them to the inbox.

You would think so, but on at least one occasion I definitely saw a node in Zensys Tools that was not being discovered in OH… it was node 59. I have no idea where it came from or how long it had been there. No xml, nothing in the log, but there it was in Zensys. Ghost nodes usually only show up after an inclusion failure, but sometimes after an exclusion. I’ve also seen nodes in Zensys that would consistently fail removal, but be gone in a few days after trying… and OH zwave logs from nodes that never existed! It’s been really rare, but enough to make me a believer!

[shadowmite (Matthew Fogle)]

@chris

The device is:
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/598

Which may or may not be a new version. Mine seems to support secure inclusion unilke the one in your database.
network_ffbd8746__node_29.xml (10.7 KB)