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

Cool - may the force be with me.:sweat_smile:

it’s an Aeon Labs ZW096 Smart Switch 6 - wired, of course. Seems to be behaving…

Is there an association configured between these devices? The binding is trying to set a route between them…

how weird - that’s the coffee grinder and the entryphone, so would make a pretty peculiar bit of automation.

I’ve used habmin to set the associations to the zwave controller only - I’ll see if that makes a difference

thanks,

Dan

doesn’t seem to help. here’s another log. This time I have offline nodes 17 and 39 (smart switches), 29 (double relay), 4, 30, 31 and 36 (heatit thermostats) and 55 (binary sensor).

I don’t suppose you could post a link to a version of the binding from before you changed the offline logic?

My log shows some warnings:

2018-07-14 21:33:08.622 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 4: Restore from config: Error. Data invalid, ignoring config.
2018-07-14 21:33:08.639 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 24: Restore from config: Error. Data invalid, ignoring config.
2018-07-14 21:33:08.642 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 35: Restore from config: Error. Data invalid, ignoring config.
2018-07-14 21:33:14.168 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Invalid item type defined (DecimalType). Assuming DecimalType
2018-07-14 21:33:14.368 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Invalid item type defined (DecimalType). Assuming DecimalType
2018-07-14 21:33:14.704 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 34: Invalid item type defined (DecimalType). Assuming DecimalType

For the first three messages it’s unclear for me what config the binding is talking about. Is it node.xml or something else? Maybe good point to add to the message what config it is related to.

About the last three warnings i suppose a DecimalType was expected and a DecimalType is supplied ? So this is wrong? I really don’t know how to read this.

node 33 and 34 are Coolcam PIR motion sensors (with lux sensor) and the channel is bound to a number item. The value does show up right on basicUI.

What you’re seeing looks to be related to this…

1 Like

It means that the initialisation is incomplete. I will remove this as it’s not something the user needs to worry about.

There will be an update tomorrow to fix this.

Cool, will update and provide feedback if needed.

About the initialisation. The nodes are battery devices and are connected for several days, shouldn’t the initialisation be done allready? Or is this done every time after a openhab restart?

Edit: Another question, if persistence is setup should the channel value be persisted after polling?

Would there be any benefit for me to also include a Vera Plus as a secondary controller now that I’m re-including my network - or would it only mess things up?

Normally, yes - so long as the wakeup interval is set. The binding should set this when the device is first initialised, and after this the device should wake at the wakeup interval you have set in the controller (I think it defaults to once per hour).

There is an “initialisation” every time the binding starts, but assuming the initialisation was previously completed, then it should be short. When the binding first initialises a device, it reads all the service information, and configures a load of stuff. After that, it stores it in the XML files, and reloads this on startup. Then it just reads data it considers is dynamic on startup (this is stuff like temperature, switch state etc) so that it can update the GUI.

Up to you really - I’m not sure there is a lot of benefit unless you are using your Vera for some reason still? It shouldn’t mess things up (too much!), but it is worth noting that some features in ZWave will only work with one controller, so the Vera may reconfigure some settings when may stop OH being able to make configuration changes.

Thanks,

I’ll skip extra controller
Use Z-Way (I’m running Z-Wave.me RaZberry board on rpi) to include all devices.
Copy the security key to OpenHAB.
and add all things, wait like 24h for initialisation and hope for a working system again!

Is there any way with OpenHAB Z-Wave Binding to do a network backup to avoid this happening again?

Thanks for all your support!

Not at the moment. It’s something I do plan to add, soonish, but there are a few other issues that are more important at the moment as I want to get the dev branch merged to master…

oh dear - tried restarting and I now have 14 nodes offline. Log here.

I fear this is something horribly wrong with my system, and not the binding - otherwise presumably everyone else would be seeing something similar…

may try backing up the zwave network and restoring onto a new zstick

I see lots of rejected by controller messages.

What version of the binding are you running? By any chance are you running OH on a fast computer?

Perhaps you could try using the version of the binding that introduces a delay when commands are rejected by the controller.

Edit: I’m running the version from post #3161. Before this version, I was seeing many nodes offline and tons of rejected by controller messages in my logs.

The latest version from the link at the top of this thread now includes this.

Ok, thanks. I wasn’t sure that made it in there yet.

But, he’s likely not running that version since there’s no delay between transmissions when he gets a rejected by controller response. WDYT?

It hadn’t - I only just added it :wink: .

Agreed - he’s not. This can be seen as there is no delay between retries. It would definitely help to update to the latest, and if there are still issues, provide another log.

:+1:

I’m on the version from post #3161. Is it worth me installing the version from post #1 (i.e. are there any other goodies in there?).