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

security
zwave
Tags: #<Tag:0x00007fd313540298> #<Tag:0x00007fd313540158>

(Dan) #3268

sorry, not sure what you mean by attaching to the log ticket. The full zwave log is here - the troublesome node is node 29. It’s a wired FGS222 double relay, close to multiple nodes and so it really shouldn’t be offline… but it is!

Dan


(Chris Jackson) #3269

This comes from the controller - so it depends on the UID that you gave the controller. In this case, it seems you set it to 512?


(Chris Jackson) #3270

No - this should be fine so long as you transfer the network key correctly. Otherwise secure devices won’t work securely.


(Chris Jackson) #3271

What is node 23?


( -) #3272

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


(Dan) #3273

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


(Chris Jackson) #3274

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


(Dan) #3275

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


(Dan) #3276

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?


(Leo Siepel) #3277

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.


MySQL specific sensors don't persist their value's
(Scott Rushworth) #3278

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


(Chris Jackson) #3279

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.


(Leo Siepel) #3280

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?


( -) #3281

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?


(Chris Jackson) #3282

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.


(Chris Jackson) #3283

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.


( -) #3284

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!


(Chris Jackson) #3285

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…


(Dan) #3286

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


(Mark) #3287

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.