Shouldn’t be any need for binding to keep any state here.
Either - got a valid update, postUpdate via channel.
Or - got an error.
If option “keep last”, DO NOTHING. Should not post faked updates.
If not option “keep last”, postUpdate UNDEF
Hi @hmerk I am not sure that I understand your point. Why would I want to retrieve a last known state at start up? Can you please explain?
Your code snippet lead me to a wrong thinking. You have added the keepLastOnlineState to a channel, not to the thing itself. Channel or Item state can be persisted.
Nevertheless, Thing or Channel, a binding should not store such Information, it should be stateless.
@hmerk you have still misunderstood. I am not trying to persist anything. The issue is when a device is lost from the RF mesh network, and the hub continues to report the last known state value to the binding, plus an offline flag. My discussion here with @rossko57 is whether the binding should a) show this last known state value to the user, or b) show UNDEF. There are two opinions, and we concluded that the choice a) or b) is determined by a Configuration Parameter on the Channel.
I’d slightly rephrase. If the binding has nothing to say about the state, because of say a device/comms problem, then it can … say nothing.
Inaction is permitted, and any linked Item remains unaffected. Binding is stateless, does not need to “remember”.
In practice, that would mean last good state preserved, but in the Item.
But does not trigger false update events, nor stop user doing their own monitoring with expire binding, or setting a failsafe value, blah.
We’re not really talking state from the bindings viewpoint. A normal message comes in, ends up being a state update event. A bad message comes along, we can choose to ignore (no update) or report (UNDEF update).
The last known state is preserved in the hub. And if the Config Param is set, in the Channel/Item as well. But the state in the hub is not actively pushed to the Channel/Item (even though their values are in fact the same).
No, it should not. If the connection is lost, the binding should set the Thing to OFFLINE, you could also add further status information, like e.g. communication error or something else.
But it should not be set as a property.
You seem to be determined to misunderstand me. Your post has nothing to do with my discussion. Sorry.