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

Add-ons Bindings
,
2993

I would probably say it doesn’t point at anything if you did no investigation :wink:

All I can say is it’s up to the framework to notify the binding when a channel is linked. When this happens, it will log the entry above, and if this is not seen in the log, then we can be pretty sure there’s a framework issue. After that, there can always be binding problems, but if the framework doesn’t notify the binding of the linked channels, then it won’t poll.

To be clear, the reason behind this is to reduce network traffic. Many devices have a LOT of channels - often some are repeated through different endpoints or command classes, and many are simply unused. To reduce noise on the network, especially during startup when everything gets polled, I only poll channels that are actually in use.

2994

I’m (finally) getting ready to take the plunge to convert my 70 node network to the dev version of the binding (I’m currently running on master version 2.4.0.201806152142). Also, I’ve been running the dev version on a couple smaller networks for quite a while without issues.

Before I jump in, I wanted to get clarification on a few things:

  • Does the version linked to in post #1 include the reworked code for handling dead nodes?

  • Does the dev version support the new UOM type for Temperature channels? I recall reading that it does, but I wanted to confirm.

  • I have a couple nodes that the controller thinks are there, but really are not there. In the past I have had little luck removing them from the controller using HABmin, so I was going to remove them using the zensys tool. Does anyone have a better suggestion?

  • And finally, I wanted to confirm the procedure

    • make a backup
    • delete all zwave things except for the controller
    • remove the zwave binding from conf/services/addons.cfg
    • shutdown OH
    • remove all node.xml files (if not removed as part of deleting the things)
    • place the dev zwave binding into the addons directory
    • start OH
    • start zwave discovery
    • add all things from the inbox

Please tell me this will go ok. :wink:

2995

TMK, no. You can find it in post #2952. I have 120 nodes and I currently have 9 that are marked dead (smarthome:things list |grep zwave| grep OFFLINE| wc -l). They appear to still be sending events, and then come back to life. Much like 1.x behaviour.

Yes.

This is probably your best bet, but you could try Tools> Advanced Settings> Remove device from controller.

This looks spot on to me. Make sure to right down your controller config, esp. security key if using any secure devices. And you didn’t say it, but I’m sure you meant it, but after adding the controller, you will need to configure it before discovery. TMK, discovery does not start after adding the controller and will need to be manually initiated.

1 Like
2996

I haven’t had much luck with this in the master version. Maybe it’ll be better with the dev version. Of course, it might be an issue with my stick (Aeon Gen 5).

Previously when I’ve done this with the Zensys tool, before I can “remove failed device”, I first need to “replace failed device”, then cancel the operation before including a new device. After that “remove failed device” works ok. Very odd.

Good point. Thanks.

Yes. Good catch.

2997

I get this too. And sometimes need to shut Zensys Tools down, unplug/replug the controller, to get it all to work. Definitely a buggy app. The newer version included with the Aeon firmwares may be improved (haven’t needed to do this in a long while). IsFailed (until successful), then Remove Failed. The IsFailed uses the text box, and IIRC you need to have the device selected for Remove Failed.

2998

Ah, so that’s the magic that makes it work. I’ll try that next time.

2999

I thought of one more thing that may be helpful… when manually adding bindings, things get messy if the name of the jar changes. Currently, the dead node builds are 2.3 with a date in the name, so I rename the file to org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar. As long as the name of the jar is the same, OH doesn’t cache the old one and leave you with two versions of the binding running after an update. As far as I know, the name of the jar can be anything you’d like.

1 Like
3000

If I remember correctly (?!?) the replace failed device is what is called when you do a “Move device to failed list” in HABmin. The controller will not remove devices that it thinks are alive.

3001

I’m pretty sure I tried that – Set Device as Failed followed by Remove Device from Controller. I’ll try again and post a log. Note the log will be from the master version (assuming this hasn’t changed in the dev version?).

3002

Here’s the log file (reminder that this is from master version, not dev)
https://drive.google.com/open?id=1p31MNpx8AmuiPK31EfJm2Bk44P5TJgqU

And here’s what I did.

  • Add Node 30 from Inbox
  • In HABmin do Set Device as Failed on node 30
  • In HABmin do Remove Device From Controller on node 30
  • Run discovery, which detects node 30
3003

as a result of https://community.openhab.org/t/cant-get-the-zwave-binding-to-update-the-s2-switch-from-a-fibaro-fgd-212

Yesterday i changed from the snapshot build 1302 to this dev binding (19 june). I followd the first posts and got the network up and running in no time. I discovered something strange in habmin:

  1. Under group associations the lifeline is empty, while it does report and work as expected.(display error?)
  2. Associations group 4 contains two empty Associations. These associations are with full operational nodes, still work and where setup with the snapshot version. (display error?)
  3. When an Association is removed by habmin, an NPE is shown

assocation_groups
assocation_groups.png1280×1400 77.4 KB

NullPointerException.css (8.1 KB) (css due to the forum not accepting .txt or .log ?! )

3004

Yes - this is a known problem with the widget that HABmin uses so I can’t easily fix this :frowning: .

The exception is thrown in ESH and not in the binding so I’m not really sure what this is without knowing what is sent over the REST interface.

3005

Well the NPE is possibly a result of the habmin widget problem, is point 2 also related to this ?
The REST request payload, kind of confirms this:
{group_4: [null]}
group_4
:
[null]
0
:
null

Didn’t get this problem with the snapshot version.
Maybe offtopic, but shouldn’t the REST api be protected to this kind of NPE?

3006

Ok, but it’s different code right? So it can be different… I’m not really sure why the widget isn’t working, but as it doesn’t seem to be in development any more, it’s not easy to resolve.

Yes, it would be nice if it provided a nice error :slight_smile: .

3007

I’ve run into my first issue with the conversion from master to dev.

My Minimotes, Wallmotes, and Fibaro Buttons won’t discover.

For example, my Wallmote thing (node 72) shows as Unknown Device in HABmin.

Normally, I would wake it up to trigger the rest of the discovery process. But, when I wake it up, I get this in the log. If a wakeup won’t trigger it to complete discovery, how can it be fully discovered?

2018-06-24 08:22:17.926 [DEBUG] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 08 00 04 00 48 02 84 07 3A 
2018-06-24 08:22:17.927 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=72, callback=0, payload=00 48 02 84 07 
2018-06-24 08:22:17.927 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[4], type=Request[0], dest=72, callback=0, payload=00 48 02 84 07 
2018-06-24 08:22:17.927 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=72, callback=0, payload=00 48 02 84 07 
2018-06-24 08:22:17.927 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-06-24 08:22:17.927 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 72: Application Command Request (ALIVE:PING)
2018-06-24 08:22:17.927 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 72: Incoming command class COMMAND_CLASS_WAKE_UP, endpoint 0
2018-06-24 08:22:17.928 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 72: Command class COMMAND_CLASS_WAKE_UP not found.
2018-06-24 08:22:17.928 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 72: Commands processed 1.
2018-06-24 08:22:17.928 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 72: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@2b538d1b.
2018-06-24 08:22:17.928 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-06-24 08:22:17.928 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-06-24 08:22:17.928 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

The Minimotes and Buttons exhibit the same behavior w.r.t. the WAKE_UP command class not found.

Edit: I’m also seeing this issue with my Ecolink TILTZWAVE2 garage door sensor.

3008

I’ll take a look tonight…

The first part of the initialisation is to read the classes - we’ve not got that far so this is not a problem - until the device is initialised the class won’t be found…

3009

Thanks.

I’m using the version that is linked to in post #2952

180 │ Active   │  80 │ 2.3.0.201806161405     │ org.openhab.binding.zwave

I’m also having a problem completing discovery of my Fibaro FGK-101 Door/Window Sensor. This looks like a simple DB update, which I just made to device #847.

3010

#381 #847:grinning:

1 Like
3011

Yes, thanks for the correction!

3012

So, to summarize, all my mains and battery-powered devices appear to have migrated successfully, except for the following devices:

Aeon DSA03202 Minimote
Aeon ZW130 Wallmote
Fibaro FGPB-101 Button
Ecolink TILTZWAVE2 Garage Door Sensor
Fibaro FGK-101 Door/Window Sensor

The FGK-101 is just a database issue, which I’ve already fixed.

The remaining 4 devices appear to have the same characteristic that they all have a wakeup interval of 0 by default. Not sure if this is relevant. I vaguely recall a change a while back to specifically account for these types of devices during initialization. Again, not sure if this is relevant.

As an aside, I’d like to see these log messages moved to TRACE level. With a big network, it generates a lot of noise in the logs… :wink:

2018-06-24 11:19:32.863 [DEBUG] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE XX: Checking zwave:xxxxxxxxxxxxx
...