Device initialization on migrating zwave1 binding to refactored 2.1 version

I’m running 2.1 SNAPSHOT and I’m struggling to migrate my devices from the legacy zwave1 binding to the native OH2 zwave binding (the refactored one, to be precise - I’m running snapshot #970 as of 2017-06-25 which is equal to 2.1).

The problem is that the process to initialize and update all the things/devices does not come to an end.
I have ~80 zwave devices. After starting, a huge (500+) radio queue builds up and takes pretty long to get down to 0 (much longer than in v1).
If at some point in time it’s arriving there (and sometimes it even doesn’t seem to do that), habmin still shows many battery devices to have an unknown type (yes, I have clicked/woken them up already), but there’s also mains powered ones of known type but still shown as initializing (in different states or without state). I don’t think it’s related to these, it’s different old and new Fibaro and Qubino devices that all work fine in v1.
At some point, I don’t see any more progress, and I see a couple of mains nodes are being walked through over and over again and doubt this loop will ever finish.

Now as I was reusing the zwave directory from v1 binding with all the node xml files already there, I would have expected the zwave2 binding to load the data from there, but it seems to walk through all of them via radio.
@chris: Will the binding use stored data so we don’t need to get through this process on every OH/binding startup ? (I still have the need to switch forth and back between v1 and v2 binding so this is annoying and takes very long)
If so, where is it stored - node.xml or JSON DB or yet elsewhere ? is there any time-to-live or similar value how current the data needs to be?

And overall: is there any trick to make that process finish or at least speed it up ?
I have no idea where to start looking for.

It’s not my first attempt to migrate, and I’ve always been waiting for a couple of hours for the initialization process to complete, but there always came the point where there was no more progress and I had to switch back to v1 binding to keep my house working.

thanks in advance for any helpful input,

Yes - this is the same as all versions of the ZWave binding (OH1, 2, 3… :wink: ).

Again - the same as OH1 etc - in the XML file.

I’m not really sure what version you are using? Is it the master version, or the development version? You say it’s the “refactored” version - which I would think means the development version, but then you quote a snapshot - so I assume you are using the standard OH2 binding? This operates in a very similar way to OH1 so I wouldn’t really expect huge differences.

I’m running ‘Snapshot Release’ OH2 package from the jfrog repository, 2.1.0 #970 binding version
I believe that’s the development version, isn’t it? At least the output looks very much refactored :slight_smile:

Looking at the log, I found that the binding loads (“deserialises”) most node.xml files, BUT it shows errors on some of them. That seems to be the case for all those devices that ultimately don’t initialize.
There’s different reasons, below are the most common ones I found. Then again, whereever OH2 fails to deserialize a node.xml, it’s logging that it is doing this for that node: NODE 106: Starting initialisation from EMPTYNODE.

However, if the parser can’t parse the node.xml, it likely can’t parse the device’s output on initialisation either, can it ?

Here’'s some of those XML parsing errors:

2017-06-29 11:02:31.516 [ERROR] [ve.internal.protocol.ZWaveController] - NODE 87: Restore from config: Error deserialising XML file. com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter$UnknownFieldException: No such field org.openhab.binding.zwave.internal.protocol.ZWaveNode.healState
---- Debugging information ----
field               : healState
class               : org.openhab.binding.zwave.internal.protocol.ZWaveNode
required-type       : org.openhab.binding.zwave.internal.protocol.ZWaveNode
converter-type      : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
path                : /node/healState
line number         : 16
version             : 1.4.7
2017-06-29 11:02:31.646 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 1: Restore from config: Ok.
2017-06-29 11:02:31.690 [ERROR] [ve.internal.protocol.ZWaveController] - NODE 49: Restore from config: Error deserialising XML file. com.thoughtworks.xstream.converters.ConversionException: No enum constant org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass.Generic.GARAGE_DOOR : No enum constant org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass.Generic.GARAGE_DOOR
---- Debugging information ----
message             : No enum constant org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass.Generic.GARAGE_DOOR
cause-exception     : java.lang.IllegalArgumentException
cause-message       : No enum constant org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass.Generic.GARAGE_DOOR
class               : org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass$Generic
required-type       : org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass$Generic
converter-type      : com.thoughtworks.xstream.converters.enums.EnumConverter
path                : /node/deviceClass/genericDeviceClass
line number         : 4
class[1]            : org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass
converter-type[1]   : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
class[2]            : org.openhab.binding.zwave.internal.protocol.ZWaveNode
version             : 1.4.7
2017-06-29 11:02:38.718 [ERROR] [ve.internal.protocol.ZWaveController] - NODE 71: Restore from config: Error deserialising XML file. com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter$UnknownFieldException: No su
ch field org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAssociationCommandClass.configAssociations
---- Debugging information ----
field               : configAssociations
class               : org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAssociationCommandClass
required-type       : org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAssociationCommandClass
converter-type      : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
path                : /node/supportedCommandClasses/entry[3]/associationCommandClass/configAssociations
line number         : 44
class[1]            : java.util.HashMap
converter-type[1]   : com.thoughtworks.xstream.converters.collections.MapConverter
class[2]            : org.openhab.binding.zwave.internal.protocol.ZWaveNode
version             : 1.4.7

No - that’s the master version. There is the master version that is used in the snapshots and the releases, and there’s a refactored version that is the development branch.

Are these saved from OH1, or are they new for OH2? I would just delete them and they should be created properly next time.