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?
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)
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…
If you look in the comments, I took off the -1LZ. So these would need to find a new Thing Type. Should all things be deleted and rediscovered, or were you able to find a way for the Thing Types to be updated automatically? There were some other zwave Things I needed to do this to in order to get manualy switch updates to start working again, but was saving to test if you managed to get it automagic’d it.
I’m no longer seeing the NPEs in 2.3.0.201801201844.
I think this would be an important feature to add so that users of the zwave binding don’t need to periodically delete and rediscover their Things to get the latest device updates, which they may not know even exist. Not to mention the time it would save for people with a lot of devices!
Or will the zwave binding be redone in the future to be more like the way the zigbee binding identifies the devices?
.
).