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.
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.
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?
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ā¦
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.
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.
thanks - Iāve just updated to the new version. It is indeed a fairly fast computer - an i5 4200. To date the speed has been a big advantage over the raspberry pi I started out with. Funny if it thatās the source of the problemā¦
@mhilbush was it you I was discussing an issue relating to initialisation where a command class was marked as a control class? I canāt find the reference, but I thought it was related to minimote initialisation, but I canāt find it here or on the other thread.
Iāve just updated the link to now not initialise classes that are marked as control classes - this should fix that issue but it would be good to check.
Yes, I think we had that discussion in an email, IIRC. And, yes, it was related to the Minimote.
Iāll check out the new version.
I also was wondering about how you handle the ADD_NODE_STATUS_ADDING_CONTROLLER response when including a controller. It didnāt look like you were processing (i.e. adding as supported) the command classes that are reported in that message (similar to the NIF). That was a couple weeks back, so Iām not sure if that has changed in the binding.
Edit: This seemed to manifest in the device being initialized with no supported command classes, hence it shows up as an unknown device (because MANUFACTURER_SPECIFIC is not added as a supported command class).
.
