As think I mentioned elsewhere, I think this is a problem with ESH - not the ZWave binding. There’s clearly a startup issue within the framework.
Yes, agreed. Sorry, I didn’t mean to suggest otherwise.
Again, I don’t believe this is a ZWave problem - I believe the problem is with the framework. You can see in your log that lots of bundles are shutting down, so it’s not just ZWave not starting.
I took a quick look at the logs, and this looks similar to what I’m seeing. The Things are created, the binding starts, and the ThingHandlers are created, but the ThingHandler’s initialize() method is never called.
I usually can get things to start normally by restarting openhab one or more times. Sometimes it takes 3 or 4 restarts. Given that it works sometimes and not other times suggests some sort of timing or synchronization issue. If this is a problem in the framework, I’m really not sure what to do next to get this resolved.
@Kai Should I open a Smarthome issue on Github?
I have installed a Qubino ZMNHBD Flush 2 relays with 2 lamps connected. When I press the physical switch connected to the relays, the channel switch_binary changes its state immediately, but it takes minutes until switch_binary1 (or switch_binary2) changes its state.
When I use OpenZWave, all channels react immediately.
Looking at the logs, I found out, that the device reports changes only on endpoint 0. After a while the openHAB starts to poll the device and the the channels switch_binary1 or switch_binary2 are correctly updated.
Some research on google indicates that this has to do with multi instance association (see here and here)
In the logs I also found that multi instance association is not supported in openHAB2:
2016-06-21 20:32:07.276 [WARN ] [tocol.commandclass.ZWaveCommandClass] - NODE 33: Unsupported command class MULTI_INSTANCE_ASSOCIATION
Any idea if the missing multi instance association is really the cause of the “wrong” end point reporting?
Are there any plans to implement multi instance association in openHAB2?
Logs:
After pressing the physical switch:
2016-07-01 22:34:14.180 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 33: Incoming command class SWITCH_BINARY 2016-07-01 22:34:14.183 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - Received Switch Binary Request for Node ID = 33 2016-07-01 22:34:14.185 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 33: Switch Binary report, value = 255 2016-07-01 22:34:14.187 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent 2016-07-01 22:34:14.188 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Got an event from Z-Wave network: ZWaveCommandClassValueEvent 2016-07-01 22:34:14.190 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 255 2016-07-01 22:34:14.191 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Updating channel state zwave:device:pailszwave:node33:switch_binary to ON [OnOffType] 2016-07-01 22:34:14.195 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 28: Transaction not completed: node address inconsistent. lastSent=28, incoming=255 2016-07-01 22:34:15.193 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 21 0A 32 02 21 34 00 00 02 0C 00 00 EB 2016-07-01 22:34:15.201 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
Polling:
2016-07-01 22:42:37.230 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Polling... 2016-07-01 22:42:37.236 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Polling zwave:device:pailszwave:node33:switch_binary
response of the polling request
2016-07-01 22:42:40.131 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@b9d60b already registered 2016-07-01 22:42:40.132 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 33: Incoming command class MULTI_INSTANCE 2016-07-01 22:42:40.132 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 33: Received Multi-instance/Multi-channel Request 2016-07-01 22:42:40.134 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 33: Requested Command Class = SWITCH_BINARY (0x25) 2016-07-01 22:42:40.135 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 33: Endpoint = 2, calling handleApplicationCommandRequest. 2016-07-01 22:42:40.135 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - Received Switch Binary Request for Node ID = 33 2016-07-01 22:42:40.136 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 33: Switch Binary report, value = 255 2016-07-01 22:42:40.137 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent 2016-07-01 22:42:40.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Got an event from Z-Wave network: ZWaveCommandClassValueEvent 2016-07-01 22:42:40.138 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Got a value event from Z-Wave network, endpoint = 2, command class = SWITCH_BINARY, value = 255 2016-07-01 22:42:40.140 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Updating channel state zwave:device:pailszwave:node33:switch_binary2 to ON [OnOffType]
I would need to look at this a bit more to better understand it (maybe tomorrow), but to answer this question at least -:
Yes - I’ve already coded this, but it’s not merged as it’s quite a large change since it also affects normal associations. It will be added soon(ish) though in OH2 only.
Hi Guys,
Since the circular reference problem is solved in the latest release, I tried again to get the Z-Wave Binding runnning for me.
But the behaviour is exactly the same as before (except no more Errors with “Circular reference”).
I can install the Binding correctly and add my Stick and the Wall outlet and both work fine. As soon as I restart OH2 both Things are stuck in “INITIALIZING”.
The only Error showing in log:tail is " Fatal Error: Markup im Dokument vor dem Root-Element muss ordnungsgemäß formatiert sein" (Don’t know why its in German).
If I stop OH2 the following error occurs in the log:
2016-07-10 10:43:14.786 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured during notification of thing 'zwave:device:364dd67a:node2' about bridge disposal at 'null': null
java.lang.NullPointerException
at org.eclipse.smarthome.core.thing.internal.ThingManager$11.run(ThingManager.java:835)[102:org.eclipse.smarthome.core.thing:0.9.0.201607061527]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)[:1.7.0_80]
at java.util.concurrent.FutureTask.run(Unknown Source)[:1.7.0_80]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)[:1.7.0_80]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)[:1.7.0_80]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)[:1.7.0_80]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)[:1.7.0_80]
at java.lang.Thread.run(Unknown Source)[:1.7.0_80]
The setup is running on a VM if that is relevant.
Please let me know how I can support to solve this problem or if I am doing something wrong here.
As you have found, even though the circular reference is fixed, things are not good still. I have errors in another binding, but zwave is working ok for me.
Currently, I still think this is an issue with the framework since this all started when the circular reference issue started, and maybe the new fix has got rid of the error, but has other issues. I’m happy to be convinced it’s only a ZWave issue though 
I have just downloaded what I think is the latest build (436) from the online repo and then installed the zwave binding. I auto discovered the two zwave nodes in my network (FGK101 Door Opening Sensor as Node 4 and WTRFID Mini Keypad RFID/Z-Wave as Node 6) but both showed as unknown devices node ‘n’ rather than resolving their types/names from the product database (both are in the product database). I have experienced this in the past (I think Chris said it was something to do with timing in ESH startup?). Did it ever get solved? Is it back?
Tim
It’s still open -:
This is listed on ESH as a critical bug, so I’m hopefull it will be resolved soon. If not, maybe I need to look at restructuring the binding to avoid storing properties in the thing/inbox, but that would be quite a bit of work.
Cheers Chris
is it ok if a device has two times the same command class in the db?
I would have removed Version 1 … but this is limited to superuser I guess
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/177
It won’t hurt in this case, but it’s not right. I’ll delete it… Do you know which version is correct (it should be in the XML).
is Version 1 or versionsupported 2 the correct one?
since this is the PAN11 which troubles me I would looks through all other classes in the xml aswell
Thanks - I’ve deleted one .
There might be an issue with the database which I’ll look at later, but hopefully I’ll publish the updates you’ve made tonight if I can get it fixed.
Cheers
Chris
I checked the other “Versions” of the command classes
There are 2 entrys (Version & versionSupported)
since you deleted the Version 2 from the class above I think “VERSION” is the relevant for the database.
Checking the XML also other classes say Version 2 in the DB but 1 in the XML:
ZWave Plus Info
Manufacurer Specific
Firmware Update MD
Assocication
if that is relevant
node4.xml (7.4 KB)
Mostly this isn’t used - the version information in the database is just for information. The binding will get the correct version and stores it in the XML file, and it will use this - not the value from the database…
That said, if the database is wrong, please feel free to update it as it’s always better if it’s correct
thanks 
just trying any and everthing to get the PAN11 working 
This was a long thread, but here I got a new PAN11 device, a Philio Tech Gen5 PAN11-1E to be specific, that has very similar capabilities compared to shorty707’s node4.xml file above. The only relevant differences are the following:
..........................................................
: Property : My Device : shorty707's :
:..............................:...........:.............:
: deviceId : 0x30 : 0x11 :
: VERSION:protocolVersion : 4.5 : 3.83 :
: VERSION:applicationVersion : 1.12 : 1.10 :
: SWITCH_BINARY:isGetSupported : true : false :
: ALARM:isGetSupported : true : false :
:..............................:...........:.............:
Because I’m a newly registered user I’m not allowed to attach my own node’s XML to this post.
@chris Thank you for all the amazing work you’ve done for openHAB, the Z-Wave binding and all. I’m impressed! If you want any help updating the Z-Wave database for this device, I’ll promise to do my best. I created an account today on your site with the username cjberg.