This log is from the new binding, so he’s got the right one…
1 Like
I did a restart of OH - and then it came up. It was not nessesary with a delete of things, as I was already before on that version of the binding. Thanks anyway ! The motion sensor works fine now 
1 Like
Downgraded to old binding and now ZW095 works.
/mike
hi, im running the lates dev. binding and noticed some days back that some of my devices, all batt. driven, getting some issues with reporting there status.
one thing i noticed is that some of them have “ghost” neighbors. Meaning in HAMmin its showing notes as neighbors which doesn’t exist any more. those notes are not setup on the controller anymore, checked with zensys and also on openhab no things and xml files for those nodes.
so how are they still showing as neighbors for those nodes? i already ran acouple of manual heals during the last days, no change.
After couple of days of including and excluding my lock I was finally able to include my lock with security and it’s working flawlessly in OH2. Thanks Chris for all your work.
The neighbors listed in Habmin are informational only. They are requested from the controller, which manages them. If the neighbors are displaying improperly, then OH doesn’t have the most recent information from the controller. This is my understanding, but I’m sure someone will confirm or correct if this is not the case 
.
Have the devices completed a heal since the other devices were removed? This includes requesting the neighbor information from the controller and should sort them out. Do you have the daily heal disabled? If it’s been a few days, then you could watch the log filtered on one of them and kick off a heal for that device. Wake it up and see what the log shows during the heal. Specifically, if the neighbors are updated.
At times, I’ve seen devices not complete initialization after a restart, which prevents them from healing, but I haven’t seen this on the recent build. Waking the device up usually corrected this, but sometimes OH needed to be restarted. You can tell if they haven’t been initialized in Habmin, which will display the state (although, sometimes this doesn’t work quite right)…
or in the Tools (Advanced Settings) menu, which will not have the option to Reinitialize the device if it is not initialized…
or in the log when you try to heal the device…
2018-01-14 22:05:16.419 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 150: Starting heal on node!
2018-01-14 22:05:16.419 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 150: Can not start heal as initialisation is not complete (REQUEST_NIF).
I had time to look into my issue some more. I tried a re-initialized and it only reported the NOOP and BASIC command classes. The log showed that the REQUST_NIF timed out without responses. I then tried powering off and back on the thermostat (probably something I would have done sooner if it was a plug in device) and re-initialized again. Now everything is working again 
For my understanding; if the device supports MCA and this is reflected in the z-wave database, Habmin will have the option to select different endpoints from the same node at the group association dropdownlist? That is exactly what i was looking for.
According to the database the Fibaro Dimmer 2 does not have MCA. My search for documentation yielded zero results regarding this Fibaro dimmer2. I did find this page:
https://manuals.fibaro.com/knowledge-base-browse/associations/#bkb-h2 It notes a Fibaro Relay Switch 2 x 1,5 Kw as an example device that supports MCA. As fas as i can tell this is not reflected in the database either, but my knowledge about this database is limited, so maybe you can confirm this. This switch is just like the dimmer a 2nd generation Fibaro product, so the feauture set could be similair. (i just like to be optimistic)
With that said, how can i tell of my dimmer 2 supports MCA? Something i can test like a binding version with MCA enabled for this Fibaro dimmer 2?
Edit:
I also have this Fibaro Switch 2 (FGS213) that has MULTI_INSTANCE_ASSOCIATION class. Is that the same as MCA?
Ah - I forgot about that with the change of name. I’ll need to remember how to log on and change that
Should be done…
Hmmm, uninstalling and reinstalling still gives me the 20170102 20180102 version …
Don’t worry, I’ll do the update the old way with the addons folder …
On OH 2.3 snapshot 1188 and zwave 2.3.0.201801201437, I’m seeing lots of these…
Exception in thread "Thread-256" Exception in thread "Thread-257" java.lang.Error: Unresolved compilation problem:
Syntax error, type annotations are available only when source level is at least 1.8
at org.openhab.binding.zwave.internal.protocol.ZWaveController.sendTransaction(ZWaveController.java:525)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.processTransaction(ZWaveNodeInitStageAdvancer.java:251)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.processTransaction(ZWaveNodeInitStageAdvancer.java:224)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.doInitialStages(ZWaveNodeInitStageAdvancer.java:337)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.access$6(ZWaveNodeInitStageAdvancer.java:332)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer$1.run(ZWaveNodeInitStageAdvancer.java:182)
Exception in thread "Timer-8" java.lang.Error: Unresolved compilation problem:
Syntax error, type annotations are available only when source level is at least 1.8
at org.openhab.binding.zwave.internal.protocol.ZWaveNode.sendTransaction(ZWaveNode.java:1322)
at org.openhab.binding.zwave.internal.protocol.ZWaveNode$WakeupTimerTask.run(ZWaveNode.java:1438)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
… and some of these, but they seem to go away…
Several restarts of OH showed no improvement.
Try now - it should fix the first error. I’ve no idea what the issue is with HABmin - I’ll need to take a look over the source to see what makes the delete button show…
HABmin shows the delete button when it doesn’t get the thing type. I don’t think it’s changed for this device type, but I did make quite a few changes to the database to fix some xml format errors (the checker wanted things in a different order!) and I also removed a few duplicates - this device at least is still in the database though…
Actually - please check that it’s still in the database (or provide the type/id) - I don’t see a version with the 1LZ on the end of the name…