Z-wave things lose their Lifeline Association Group

Note that I’m currently doing a build which fixes the priority of the REMOVE command, and also ignores configuration that is unaltered which should reduce the network load. If you’ve not done the test yet, it might be nice to try with the latest version once it’s built - hopefully in about 30 minutes.

Let me know, I tried now, but there was no new snapshot available (after 1 hr).

The build finished successfully a while ago so it should now be available.

Three minutes ago:
openhab2 is already the newest version (2.4.0~M4-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.’’

When trying to upgrade to newest snapshot in openhabian-config.

Ah - you are using the M4 build. This will never change. At some point (in a week or two maybe) there will be an M5 build, but you don’t get the snapshots.

I see, the “Install or switch to the latest snapshot build” in openhab config is not really the newest snapshot?

It seems that way - the Mx builds are not snapshots - they are the so called Milestone builds that are done every few weeks…

PaperUI is showing the associations correctly, this is an exclusive problem within Habmin.
Just for example the associations of one of my Z-Wave thermostats with Habmin:
grafik

and the same device shown with PaperUI:

So PaperUI is showing things correctly.
This is really a pity that Habmin is not displaying this information reliably.

Maybe your are trapped to milestones because of this:

This is probably a bug in the binding unfortunately as it shouldn’t say this at all. I’ll have a look when I get a chance.

Gotcha.

Alright, I’ve done some debugging and deleting/discovering the nodes and finding them once again without lifeline. I have added the lifeline in paperUI and habmin until they show up both places (although as pending in habmin).

Then I pushed buttons on the dimmers and saw that they indeed did report to the controller. BUT! to the switch_dimmer1-channel and not the switch_dimmer-channel which I have used before.

The lifelines still are removed after awhile, but maybe everything will work as it should with new item channel bindings.

This is just down to the way the new binding works with the multi-channel associations.

I’m not sure what you mean? If the lifeline is removed, then there will be no updates to any channels.

In the log, the lifeline is not removed as far as I can see.

Alright. Does this mean that I can now pick up switch2-signals easier? I haven’t been able to do that before and have only used them for node-to-node communication before.

They are removed from UI (paper and habmin). Probably related to the bug you have written about before. It ssems like everything is working better now.

Probably, but without testing, I’m not sure. In general though, the new association system should properly encapsulate each switch in a separate endpoint.

Ok, yes, this sounds like it’s “just” a UI issue then - I know this is really not nice, but if it’s working, then I guess at least that’s positive.

Haha… Yea, I’ve probably spent 10 hours on trying to get this to work now, so that’s positive for sure…

I see now that several of my rules run multiple times. One is running seven or ten times now when reacting to a channel change. So there’s still stuff to figure out, but at least most things seem to be working.

Okay, so the lights started reporting when I switched. But my battery devices are behaving strange. Like this one (last part of the log) that is reporting its state multiple times and another which has its lifeline set, but is not reporting.

I am considering some night soon on starting anew:
New excluding all devices, hard resetting controller, booting with a blank openhabianpi image, upgrading to snapshot and then including devices.

I had an electrician here a few weeks ago and he took the power and all my half decent backups are from after this episode. So I am thinking that MAYBE this incident might be the source of the many and strange bugs.

Maybe I’ll wait for the new milestone build though.

This is normally caused by setting the controller into multiple association groups. You will normally only need to set the lifeline.

I’m not sure what to say here - if the lifeline is configured, then it should report and there’s not a lot the binding can do to change this.

I had a look at the log, but there’s a lot in there, and I’m not really sure what you want to look at. If by the “last part of the log” you mean this -:

I don’t know that this is really duplication - the two meter reports are received 5 seconds apart - if messages are duplicated, they tend to be received very close together. This might also be caused by the way you have configured the device.

This morning I was looking at motion sensors.

What I see in GUI for Lifeline (or device status for those with non zw+ firmware):
Controller set
node_1 set
no node set

Things with each of them may or may not be reporting. When both habmin and paperui show no node I get confused when the thing is reporting. And when both show Controller I get confused the node is not reporting. And looking at logs, excluding, reincluding et cetera will probably help. But every day there’s something new and I spent half of my spare time on trying to make what just worked a some 4-5 weeks back work again. So now I’m thinking it may be a randomly affecting sdcard issue.

As for the log I was thinking about what is going on with node38:

The only time I’ve seen this sort of multiple repetition is if the device has an issue and normally resetting it will fix it. That said, if you have multiple association groups set, this can also cause duplication (but here by duplication, I mean 2 messages - not ~10!). I suspect some of this will be related to the multiple associations as there are different messages being sent here as well and probably this would not happen if only the lifeline is used as it normally will not send the BASIC commands.

Alright. This node was working (sending one message) up until yesterday and has the “node_1” set on Device status. I will try changing to “Controller updates” instead of Device status and if that doesn’t work exclude, reset, reinclude. If that works I can start with the others.

I will start with his path until the new milestone build next week and if I haven’t been able to obtain a stable or semi-stable system by then I’ll start with a blank slate.