[SOLVED] Z-Wave parameter mismatch between REST API and Thing parameters

I don’t know if it’s a problem related to Z-Wave binding, PaperUI or REST API, but I found an inconsistency in the configuration parameters of a Thing:

  • In PaperUI, the Lifeline association of a thing appeared empty
  • If asking through REST API the configuration of that thing, the Lifeline was linked to controller

I think somebody is lying, but don’t know why. I put the Lifeline again through PaperUI and now is shown correctly as linked with the controller.

There is a known bug in PaperUI when displaying multi select lists.

I don’t know who is responsible, but I might help to track down this issue (I don’t know if it will happen again). Any clue to I should address?

I don’t think it can or will be fixed in any current version of PaperUI. The author of PaperUI stated a while ago that it was a “hand crafted” widget, and he is no longer supporting this after the ESH de-merger.

Maybe in future UIs it will be resolved.

If you are using the latest ZWave binding, then the binding should prevent removal of required associations at least.

Ok then!

I’m using the latest binding, but I don’t know about this feature. Is Lifeline connected in any case with the gateway?

Yes, it is. It is linked during initialisation - that has been the case for a long time. In the later versions, it is now not possible to remove the lifeline which avoids errors in the UI propagating to the device by sending incorrect commands.

1 Like

Thank you for your explanation, I didn’t know that.

That explains why sometimes I receive information from battery sensors even if the Lifeline is not set, but there are other cases where this might not happen:

  • I stop receiving data from a device (battery) until I reconfigure Lifeline through PaperUI (and forcing an awake of the device).
  • A device doesn’t send any data until Lifeline is configured.

So… Is there a way to verify that the Lifeline is linked? This might solve some of the cases.

It should always be linked. It should be configured during initialisation, and it should not be possible to remove it. You could reinitialise the device and check the debug logs if you want to confirm this.

I’m also assuming that you are using a recent build - if not, please upgrade to a recent snapshot.

Perfect!

In fact some of the cases were performed using 2.4.0 stable version.

Just to check: this Lifeline feature was added in this commit? Or is in an even newer version?

There are different features added at different times.

The binding has always set the lifeline during initialisation - ever since 1.3 it has been doing this. At that stage it relied on the database, but in more recent times (probably in 2.4) I added specific checks to detect and set the ZWave Plus lifeline.

In more recent times we identified bugs in ESH/UIs that sent incorrect commands to the binding that caused lifelines and other necessary associations to be removed - this is the PR that you refer to.

1 Like