Updating channels when a thing goes offline

When a thing goes offline (e.g. a communication failure), it’s easy enough to call updateStatus(ThingStatus.OFFLINE). This marks the thing as offline, and if it’s a bridge, then all of the things connected via this bridge are marked offline as well.

However, all of the channels retain their value, which is a little odd. If you’re looking in the UI or querying an item from a rule, there’s no indication that the thing is offline and the channel state is probably stale.

Is there a convention for what a binding should do in this case, to clear out all of the active channels? Maybe set them all to UnDefType? Is there an easy one-shot way to do this to all channels for a bridge, and all of its things and their channels?

The standard approach is when a thing goes OFFLINE it sets all the Items linked to the Channels to UNDEF. That’s what MQTT does and I believe Zwave/Zigbee too if you want to find some examples. Beyond that I can’t help but I’m sure a developer can.

It is recommended to set to undef. But I don’t think it very strict enforced to implement, so the behavior differs from binding to binding. If you want to set all channels to undef you can do it with this one-liner:

getThing().getChannels().forEach(c -> updateState(c.getUID(), UnDefType.UNDEF));
1 Like

It’s rather dependent on the technology involved.
We previously found with a binding (Modbus v1) polling at sub-second intervals that repeated UNDEF updates were sometimes a pain, and made the behaviour user selectable. That was about read errors though.
In the v2 version, abandoned the idea altogether - if wanted, expire or Thing status rules could do the job when required.

You don’t have to do everything you think might be useful in a binding -users might want something different. Might be happy to stick with the old value until something valid comes along. In this case, it might depend on if the user can easily find out the same thing e.g.missing periodic updates.

Bear in mind channels are stateless, this really a “set UNDEF” event upon some change.

Thanks @rossko57, I agree it’s a judgement call. If you’re polling and you miss a message or two, you might assume it’s a transient failure and that the last-known state is still valid. I was thinking more about the case where you know you’ve lost your connection to the thing and it’s unrecoverable (e.g. an I/O error on a serial connection that fails to reconnect). In that case you probably want to make it clear that you just don’t know the thing states anymore. Newly-created things are set to UnDefType.NULL so that seems like the right choice.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.