I’ve had a suspicion that something was going on in ESH that made devices behave oddly after a binding update. Maybe more often than that. Deleting my Things would fix it. For me, it was related to scene_number. Resolving @sipvoip’s issue reinforces this for me a bit, but I really don’t have anything solid to open a bug with. Looking forward to when the Thing definitions refresh themselves!
I’ve actually had the same exact symptoms as @sipvoip regarding polling. I would have posted something earlier, but I just haven’t had the time to debug so I just reverted to a previous snapshot of my system. I now have 2.3.0.201804022210 of the binding installed. When I tried the updated binding, I did see the polling started log entry. The one difference from Nathan on my system is that my things are not manually defined.
Just one more thing to add…I also recently tried updating to the latest daily build of openhab while keeping the same old 2.3.0.201804022210 version of the z-wave binding. I had polling issues with this setup as well, but I did even less investigating this time and did not look at the log at all. Sorry for the lack of information, but this at least further points to a framework issue instead of binding issue. My wife has gotten accustomed to using Openhab (especially with google home support) so I can’t leave my setup broken for too long.
I would probably say it doesn’t point at anything if you did no investigation
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.
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
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.
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.
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.
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.
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.
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?).
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:
Under group associations the lifeline is empty, while it does report and work as expected.(display error?)
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?)
When an Association is removed by habmin, an NPE is shown
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?
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 .
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?
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…
.
.