No, as I have described this needs to be changed in the core first.
Only then can it be changed in the UI and only then an UI author has a reason to do so.
1 Like
I really donât see why.
The situation being complained about is that autoupdate issues a predict event and then follows up with an update event. Two different events.
The core proposal is to optionally remove the update, retaining the predict, I thought we agreed on that?
As I understand the current workings of UIs, all ignore predict events and use update events to drive display. Have I misunderstood?
So to properly handle the proposed autoupdate change, the UIs would need to listen for predict events and use them to drive display. (Might be in some fancy way).
The UIs would still need to listen for update events and use for display, just as before. In most real cases youâd still get predict-update sequence, except the update comes from the real device.
I canât see any reason why UIs can not be enhanced to act in that way today. It all has to work with the existing events sequence anyway. That way, if/when core autoupdate is changed, the UIs are already in place to deal with the events change.
If UIs are not changed, then the core change buggers the purpose of autoupdate. Were I in charge, I would veto such regression.
Simultaneous development and release of core and four/five different UIs just ainât going to happen. When you are tryin to sell an idea, it is a good plan to find the least disruptive way to implement it.
You need the UI changes up front.
Side issues -
On the practical side, there are likely to be some race/queuing issues to sort out with rapid predict-update events sequence. That applies with or without core change.
Whatever passes as âadminâ UI these days needs to choose to show or hide predictions. Maybe a user option. Admin interface may want to show true Item states.
Itâs not the update event that is wrong, itâs the actual state update. Iâll rephrase it:
The situation being complained about is that autoupdate issues a predict event and then follows up with an item state update.
The core proposal is to remove the state update for items that donât get an update from the channel, retaining the predict .
I canât answer this because I donât know all the UIs.
Maybe itwas a conscious decision to just display the actual values.
Maybe it wasnât.
And it actually doesnât matter because this is not a UI issue but a logical one.
A state should always be the reported state and not an assumption,
thatâs why the differentiation between commands and states exist in the first place.
I just added some Items in OH3 UI and noticed auto-update is off by default.
Yes. I think we say the same thing. You would like to remove autoupdate updating Item state.
Fine, but to do so ruins functionality that other people use.
I propose a way to retain that functionality by implementing UI that use predict events.
I donât know that UI all donât do that either, but thereâs no real point at the moment so I canât imagine anyone implemented it. The predict event is new circa OH2.4 I think.
Again I do think your real grizzle here is that few bindings apply a veto policy when appropriate. Again this is new.
1 Like
I think I can deduct why proposed way is currently hard to work. Given that events are asynchronous you can not and should not rely on event ordering.
It looks fine when you have everything in place, ie. UI fires command, then there is a predict-update cycle. But what if you get update right after UI fired command and before predict arrives? How do you know that it is an update for your command or update caused by some other end of installation? In order to make it work we would need to introduce correlation criteria for events so each command would have an random id and every update caused by this command should get back with same id.
With such mechanism in place we could simply check if update which arrived before predict is for our command or something else, change UI state accordingly and ignore late predict event.
Thatâs however an assumption cause most of devices does not correlate events and in quite many cases you canât really attach any metadata to payload which would allow such mechanism to be reliable. It means that all state would sit somewhere deep in bindings or framework trying to mimic correlation for all the devices which canât do it.
Yes. For an example, a polling binding will be fetching data at metronome intervals, one such update might arrive between command and autoupdate prediction.
âSo whatâ? i.e. if you donât like the effect of that, disable autoupdate.
But note that a similar situation arises even without autoupdate being involved; a possible sequence -
command
scheduled polled update (with pre-command state)
responsive update (or next scheduled, but after command actioned)
This is not an autoupdate problem, itâs the nature of asynchronous commands.
1 Like