Hmmm - not sure what you mean. Items are items - you don’t need to map them to another item in an items file. Just use them in your sitemap.
I was looking to potentially add some groups or specify the callouts for HomeKit inclusion as well so I can use Siri to turn on/off. These were in the .items files previously, so just trying to understand where those changes could now be made. Will I need to modify the DB instead now?
If you are using the online runtime of OH2, then it’s simple to upgrade. All you need to do is to go to Extensions in HABmin or PaperUI, uninstall the current binding, then install it again. It will pick up the latest build from Cloudbees…
Perfect, I’ll get switched over to an online version as I believe the Pine64 versions shipped was offline since it has all the JAR files packaged.
Thanks for the help/direction. I’ll get updates and hopefully get around to testing the security binding this week/end.
I am testing the OH2 Online Distro with the Z-Wave Binding at the moment.
I have an Aeonlabs Zwave Stick Gen5 and an Aeonlabs Smart Switch 6 to test with.
If I start from scratch and install the Zwave Binding, I can add both things and they are working fine (online and working).
As soon as I stop and restart OH2 both Things are stuck in “INITIALIZING” .
Any Ideas on how to solve this?
Any additional information needed?
You can either put item definitions in item files like before, or, if you use the UI, they will be stored in a database. My confusion was you were talking about mapping items to other items - maybe we’re talking about different terminology…
@chris Yes I likely confused how I was talking about the items, things, and “legacy” item declaration methods. Still getting my bearings in OH2.
I’ll open a second threat for some of it, as I believe it falls into a failure to understand some of OH2 inner workings more so than this ZWave specific section. I’ll jump back into the thread when I’ve got my symbolic links and such squared away and have time to help test further.
I see something similar, about every other startup the Z-Wave binding simply hangs. bundle:list shows ‘Started’ but it doesn’t do anything, eventually after a couple restarts it works again. I’ve added debugging and tried to see what’s going on but haven’t seen anything at all in my logs other than the lack of messages.
This started for me in the 6/19 build, which happened to coincide with the introduction of the circular reference exception at startup. See here. I used the term “discovery process” in that thread, but I actually should’ve called it “initialization process”.
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.
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:
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.
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?
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.
