ZWave binding updates

Tags: #<Tag:0x00007f0148ad5160>

(Kris K) #422

Hi All

If I exclude a device from the network and reset it, then it should disappear completely never to return, right? I have an old node, 17 , which was factory reset a few times and also excluded successfully. For some reason it keeps coming up in my Inbox despite it being known as Node 22 and successfully working now?


(Chris Jackson) #423

Correct. But actually resetting it won’t really help - you need to exclude it, otherwise the controller will not know it has been removed. If you reset it without excluding it, then the controller will continue to think the device exists, and it will report this device to the binding during initialisation.

So probably it was not excluded before reset and the controller still knows about it. You need to remove it manually - there are options in the thing menu if you create a thing for this device.

(Kris K) #424

Thanks Chris, ive added them as things and removed them from the controller. I guess they can’t be good sitting there doing nothing. Am I right in saying that can slow the controller down?

(Andy) #425

@chris Is there anything else I need to do here (raise a ticket?), or is there anything you need from me? I can upgrade to 2.4 and get the logs for open/closed from there if you want? Thanks.

(Chris Jackson) #426

Yes, I think this is a fair assumption. I don’t know exactly what the controller does, but the binding will also try to communicate with them, so it’s definitely good to remove them.

(Kris K) #427

Thanks! Always good to learn something :slight_smile:

(Chris Jackson) #428

What is the issue? I thought from the last comment you made that the binding was correctly decoding the packets and updating the logs - but the UI wasn’t being updated somewhere? If that’s the case, then there’s not much more I can do. I can take a look at the log to see if your interpretation is correct, but otherwise it sounds like the issue is outside of the ZWave binding.

(Andy) #429

Hi @chris ,

Ah, sorry perhaps I’ve misunderstood, my knowledge of zwave and openhab is limited. In short, after upgrade to 2.4, the alarm_access channel is no longer updated when sensor_door is updated. In 2.3 alarm_access is set to ON whenever the door is opened/closed. I use this as a workaround for a (likely hardware) issue with the sensor_door channel. Instead, in 2.4, I see:

2018-12-31 16:08:53.243 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 29: Alarm converter NOTIFICATION event is 3, channel alarm_access is not implemented.

Whereas is 2.3 I see:

2019-01-02 13:56:46.091 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Updating channel state zwave:device:601e3458:node24:alarm_access to ON [OnOffType]

There is another channel, alarm_burglar that is updated when I remove the device from the alarm, this is the tamper alarm.

(Chris Jackson) #430

Ok, understood. Please provide a log showing what is received. Also, please confirm you are running the latest snapshot before we do anything (ie 2.5).

(Andy) #431


I’m still on 2.3 currently, is it possible to use version 2.5 of the zwave extension with this? Or, do I need to update all of openhab to 2.5 snapshot?

This is the log from 2.3 Door opened at 13:42:32 and closed at 13:42:42, Node 24.


(Romain) #432

Up :grinning:

(Kris K) #433

Hi @chris

Overnight these devices have popped back up after removing them from the controller using the thing.

How can I remove them? Node 17,21 are duplicates of the working node 22. There is also node 227, no idea where that came from! Node 7 was the one I excluded, its the same device also.

The nodes go offline after a while but as soon as I remove them from the controller they come back online.

Also, did you by any chance have any time to look at the Zwave Map we discussed when using two controllers and the lack of map when using two controllers?


(Chris Jackson) #434

In the thing configuration, there is a boolean option called “Remove device from controller”. You need to enable this and save the thing. This may or may not work (it is still up to the controller to decide!) - if it doesn’t you may need to use the Zensys tool.

(Kris K) #435

Hi chris yes i tried that. fails for these nodes. Whats odd is they are online but are old versions of the real thing. I looked into zensys but even it cant even see them.

The UI’s are showing Nodes that arent even on the Controller

Node 2, 7, 17, 21

(Kris K) #436

Even deleting the XML files makes no difference, they return back into the UI

(Chris Jackson) #437

Correct - it is not related to the binding. The problem is the devices need to be removed from the controller.

(Christoph Nagel) #438

Hi @chris,

my actual problem occurred after the recently applied z-wave binding upgrade. I followed your instructions step by step. Every single z-wave component of my little smarthome was re-recognized and I could use my existing sitemap, item definitions, and rules.

And, yes: I checked that the default region is set properly.

But now the thermostat setpoints for the Danfoss Living Connect thermostats which I change via sitemap are not transferred to the thermostats anymore unless I wake them up twice (!) manually.

In contrast: the Comet Z thermostat is working absolutely reliable, I have no problems at all changing the temperature setpoint.

I wanted to ask you to have a look at the log file. It starts at the point when I started debug mode today at around 5:35 p.m.

openhab.log (341.9 KB)

Node 27: Comet Z thermostat

Node 21: one of the Danfoss Living Connect thermostats

First you’ll see the successful change of the Comet Z thermostat setpoint (between 5:25 an 5:41 p.m.).

The next event was to try to change the setpoint for node 21 without waking up the thermostat manually (between 5:38 an 5:43 p.m.).

At last I changed the setpoint again via sitemap (iPhone App) but did a double manual wakeup (from 5:48 to 5:49 p.m.).

Thanks a lot in advance for your comment and recommendation on that phenomenon!

Many regards from Berlin


Danfoss Living Connect LC-13 thermostat and ZWave Binding Update 2018
(Kris K) #439

But the devices are not known to the controller because under NODES on Zensys they are not present. So how do you remove a node not on the controller? Am I right in saying that if I factory reset the controller it will wipe all inclusions and reset the node ID so I can start again? I think thats what I may need to do.

I will of course need to reinclude all my devices and revise my items files with the new IDs

(Chris Jackson) #440

If they are not on the controller, then they will not appear during startup in the inbox, so just remove the things.

(Kris K) #441

They aren’t on the controller - see the screenshots above. Yet they are in PaperUI.

It sounds so simple but it’s clearly not or I’m totally retarded.

Node 227, another one…Let me assure you, its appearing in the inbox :slight_smile: