ZWave device association/physical switches not registering

@chris I wonder if you could point me in the right direction on a problem that I’ve been banging my head against for a few weeks.

My zwave setup had been working very well up until recently, when a number of devices have stopped reporting changes in the physical switch states back to openHAB, including Qubino 2 relay (firmware 1.1), Fibaro FGD212 dimmer etc. I no longer see anythig in the debug logs when the physical switches are pressed for these few devices, but do show fully for other devices that are reporting correctly. In the attached logs (zwave.pdf - it is a zip file), there should have been entries for node 15 OFF, followed about 10 seconds later with node 17 OFF and then ON. In the past, both these devices were reporting correctly and various rules that I had based on the status were working normally.

I know there was some discussion on Qubino relay reporting issues, and specifically firmware 1.1 related. However, mine had been working well, and reporting physcial switch changes back to openHAB immediately. Similarly, the Fibaro dimmers always reported back in the past. Moreover, I have other Fibaro FGD212s that are continuing to report back fine. I don’t think it is thus a device specific issue.

I’ve tried factory resetting the Qubino, and re-including it back into the controller (via replace failed device), deleting the xml files, deleting from openHAB and re-adding etc, but none of this has worked.

I’ve also tried both the development binding and the snapshot binding - that hasn’t help either, so I don’t think its a binding issue.

I have checked the associations on these devices and all are showing blank on Habmin. I’ve manually set each of the association groups (including lifeline) to ‘openHAB Controller’ but they revert back to blank whenever I go back to the device in Habmin.

Other than moving to the development binding a few weeks back (and of course using newer builds of OH), the only other thing I recall doing was changing my Zwave.me USB controller for an Aeotec z-stick (so that I can use the backup functionality). I have used the controller shift methods discussed elsewhere in the forum for making the Aeotec primary and changing its node number to 1, in case the controller node number was causing an issue. This also did not solve the problem. Finally I have also tried going back to the old controller, but still nothing showing up in the logs for these devices when the physical switches are pressed.

I have attached the XML file for Nodes 15 (Qubnio relay) and 17 (Fibaro dimmer), both of which are currently not reporting back.

Is there anything else I can try?

zwave.pdf (5.9 KB)
network_ede3f11f__node_15.xml (27.2 KB)
network_ede3f11f__node_17.xml (42.2 KB)

@chris An update on this - I’ve finally managed to get the devices to respond.

It seems as if when I changed the controllers, the Lifeline assocation group had also changed. However, trying to revert this to the correct Node 1 (openHAB Controller) via Habmin kept failing - the lifeline dropdown in Habmin kept showing an unselected state. In the end, I used another HA tool, and changed the lifeline association back to the correct node 1. All seems to be working again!

@smar I seem to be experiencing this issue as well with several of my modules (different brands, including Fibaro and Aeotec)

What tool did you use to restore the lifeline association? I’m hoping this will help me too, I was just about to reset my entire Z-wave network and start the inclusion process for all my devices. But I was hoping to avoid this as it take quite a lot of time and patience :wink:

For future reference (and other users coming to this thread with similar issues). I compiled and installed open-zwave-controlpanel https://github.com/OpenZWave/open-zwave-control-panel. I will be trying to fix the problem by explicitly setting the association group 1 to the zwave controller - will report back if this worked for me.

Sorry for the late reply, but as you figured, it was OpenZWave Control Panel.

Thank you for your input! It seems.to.have solved my issues as well, although I accidentally did a RESET instead of a SOFT RESET during the process so I now have to start including all my devices from scratch :slight_smile:

:slight_smile: At least you got it working

Another thing to try is to delete the Thing in OH and rediscover. This is different than excluding/re-including. I typically need to do this after every binding update to get my switches to report manual toggles. I put this together to make it easier…

Also, there is a bug in Habmin where the associations do not display properly…

I would like to add to this thread for future reference (both for myself and others).

Before when this happened to me I used the OZWCP tool (as mentioned in the other thread) to re-set/force the lifeline group back to the controller node (in my case node 1).

I had to upgrade my OpenHAB system to 2.4.0M6 yesterday and I had issues with several (but not all) Fibaro 212 dimmers (the new ones). Some of them were not reporting their state back to the controller when manually switched. I tried to reconfigure the nodes using OZWCP as I have done previously but now this didn’t work either…

What did work for me, however… I went into PaperUI to the Thing of the Fibaro dimmer, pressed the ‘edit/configure’ button and once again set the ‘Lifeline’ association group to ‘Controller’, but in addition I also toggled the ‘re-initialize device’ toggle switch under ‘Show more’… And now all of a sudden my device is once again correctly reporting it’s state when triggered manually…

1 Like

I would like to add the following here for future reference:

Today I updated from 2.3 to 2.4 per APT repository. I readded the things as recommended in the release notes, but I had a similiar problem as discussed here:
The state of the switch of my “FGS213 Single Switch 2” was not updated . Based on the last post I changed in the configuration parameters - Association Groups - 2: Switch 1 to controller and now it is working as expected.
Honestly, I have no clue, what this configuration parameter exactly is about, but it’s working.