Is it possible to use Autoupdate without it short-circuiting?

Tags: #<Tag:0x00007efec17f0ff0>

Is it possible to use Autoupdate without it short-circuiting? That means, without it echoing the status update back to itself locally.

I set autoupdate to VETO on all the channels because the framework was reflecting it’s own Commands back to itself as a status, which is a HUGE NO-NO! But, I do need to insure that Commands force a “REFRESH” Command so the Status reflects the actual device status. It’s easy enough to code it, but it seems like autoupdate ought to be able to do more than generate fake status updates.

Autoupdate operates on Items. Channels may make (fairly insistent) recommendations to autoupdate, such as veto. Autoupdate listens for commands. It’s not really clear what your complaint is.

Are you perhaps sending commands through your channels to the Item? That’s not usual for bindings, but certainly permissable for various reasons.

My complaint is the short-circuit. Autoupdate commands seem to go directly to Status. It should never, ever do open loop status when there is a choice. Commands should go to the device. The status of the device should go back to the Status.

My complaint is I once went on a business trip for 14-days, and came home to find an additional 336 hours on the lamp of a $13,000 projector… because the Status was off, but the projector wasn’t. At around $0.50 per hour that burned $168 before you count the electricity. Automation must always use closed loop feedback! The object of the Status is not confirm that I pushed a button. It’s confirmation that pushing the button actually did what it was supposed to do.

I was hoping that Autoupdate could actually send the RefreshType.REFRESH command to the device to Autoupdate the status after the Command gets sent. If there’s a way to do that it will save me wring a bunch of code.

1 Like

I checked the code; It can’t. The name is deceptive. What it actually does is create a pseudo-status. It feeds a derived status back to the Item, mostly for when the Channel isn’t status-capable, so you have to fake it.

I’ll have to trigger the status refresh in the binding.

Yes. You seem to have misunderstood autoupdate. “auto” = automated “update” = self-evident, but like most OH actions it is a response to a command. It’s actions are under the control of the user. Some detail here -

(edit - fixed wrong link)

Unless you can’t like a ir code to a tv to toggle it on and off.

This is a limitation of some devices people want to integrate into the system. It is also a limitation on peoples grasp of how to use English.

As I understand it the Autoupdate tries to limit the Two General Problem

As this is different for many of the closed systems with there own limitations it is hard to have a one solution fits all.

MQTT uses command topic and state topic to have 2 way communication to openHAB. Other Bindings request a state after a set time.

You can always close the loop, whether you should is another matter, as that would mean additional sensors. Current and light sensors can be used to provide feedback for devices which draw current and/or produce light, for example.

Of course, also on my list is:

  • You should never try to control something that toggles (state machine sync issues)
  • You should never try to control something with an IR light path (reliability issues)

Add those two and you have an unreliable command channel, which can, and probably will, lose sync between the internal and external state machines sooner or later, with no way to reset to a known state, or feedback to know when you’ve gone out of sync or to facilitate re-synchronizing.

But this derives from one of two philosophies. I started doing automation back in the 1970’s. So, automation came first, and any device I’ve acquire since has been specifically selected for the ability to be integrated. I just don’t buy things that can’t be controlled.

Of course, the other philosophy is simply opportunistically integrating whatever people already own, no matter how unsuited it may be, and they’re more accepting of the “best effort” reliability. People form those two worlds will never agree with each other, their “needs” are in a different places.

Yes, that is one of the things it can do. But the name is a very poor generalization. “Auto” and “Update” are pretty specific, yet completely fail to convey the key differentiators. Bindings also automatically update status, yet the two are completely different. Autoupdate actually does optimistic state prediction, and pseudo-state dissemination. Bindings, on the other hand, automatically update things based on actual device status. One is just an algorithm, the other provides an actual device state updates.

It’s ironic; Autoupdate is designed to hide the inequality and unreliability of real state updates, while it’s name hides it’s true function at the same time.

Are we happy now that autoupdate is doing what it is intended to do? And that binding authors may influence that, but ultimate control lies with the system owner?

2 Likes

I’ve had my fair share of problems with autoupdate and set it to “false” for all items that are linked to a channel. Since then my experience has vastly improved.

The issue is that it tries to solve an UI problem (show that a command has been sent) but does this on a logical/item level.

This is one of those things I really wished would have been tackled and cleaned up with OH3 and the never ending posts about it really speaks for itself.

3 Likes

Just so. It has to do it there, at the Item, because that is the UI facing part. Don’t forget multiple UIs may listen to the same Items.

The default decision was made back in OH1 days - I think the benefit of functional unlinked Items was seen to outweigh edge/failure cases. Can’t please everybody.
It is not yet unpossible to improve though :wink:

autoupdate left to default on a linked Item generally makes prediction events. No-one yet exploits those as far as I know.
But if user-facing UIs listened for prediction events, autoupdate going on to actually update the Item becomes less necessary for the snappy response.
You need UI authors buy in here.

If the UIs were all refactored for that, it would be possible to review autoupdate default action and have it only issue predictions in some circumstances, without following through with a real state update.

“some circumstances” - take note of channel autoupdate policy settings = ‘influencers’. Hardly any bindings make use of these.
A subtle change here where “recommended” gets the follow through update, but “default” policy does not update, that would work.
Absence of any channel policy can become “recommend”, saving unlinked Item normal functionality.
channel policy “veto” remains as is.
You need binding authors buy in here.

1 Like

As you say yourself it does generate prediction events, why in addition to that change the item.
All UIs receive the PredictionEvent, so there is no need to make an item change except for unlinked items where it makes sense.

But why should I - as a UI author - make any changes?
The users are not confused with my UI, they’re confused with the item logic.
Also there is no differentiatiation between state changes through autoupdate and “real” state changes.
As long as the state changes from autoupdate are coming it’s even impossible for me to develop a proper “command has been send but no update received yet”-feature because I don’t know which is which.

This is exactly why the change has to happen in the core, first.

What do they do with it?

Because you want something different to happen, duh.

You can argue that you wish openHAB core to change because you do not wish to change your UI. Fire away, it is not me that you need to convince.
I am happy to bounce ideas around and perhaps help to work up a coherent suggestion for a path forward to improvement. I do not regard “turn it all off” as an improvement, but again that is a personal opinion.

That’s right. A state change or update is a state change or update regardless of whether it was caused by rule, UI, binding, or magic.

I have an idea - if you listened for prediction events (which are a different event to update, and a different event to change) you might be able to do something with those.

Nothing, because they can’t do anything with them.
That’s what I was explaining in my post above.

I was just playing devils advocate and explaining that even if I would be an eager programmer it’s impossible for me to develop a feature because I don’t know which event is from auto_update and which is from the device.
Even if I catch the Prediction event, which value does disable the prediction because it’s the correct one from the device?

We’ve had some constructive discussions in the past, I really valued those and really wish we could get back to that level and not just talk back with snappy remarks.

1 Like

Prediction events do update status. It is not implemented at the UI, Event Bus listeners pick them up and use them to update the Status. If that wasn’t the case we would not be having this conversation since that was the reason I asked this question in the first place.

I’m happy with my understanding of what it dosen’t do and that i know how to disable it.

Is that true? If a Binding VETO’s for a channel, does some other setting have precedence?

Surely the UI could be altered to do something?

The event boils down to “Item X predicted to take state 99”.
The UI can just display 99. Hurrah, we have achieved the original aim of rapid response for the user.
(I don’t know how complicated that gets where quantities and transforms are involved, but all that stuff already happens for normal state display)

If you think that is cheating, display it in flashing red, or substitute a whirly wheel graphic or suchlike, to show that something is happening and it is interim. Still satisfies snappy UI response.
Let’s call it an interim display, exact style is UI designers choice.

When a real event comes along, “Item X has taken state 98”, the UI changes display to that in the ordinary way.

Well, that’s the thing. This whole discussion is predicated on there being some real response from the target device. That’s the binding’s job, it makes an ordinary update to the Item.
We’d expect the UI to follow this and make an ordinary display update. Clearly that replaces any interim display.

At this point, the UI doesn’t care if the device is stuck in its old state, or if the binding declares a disaster and sets it to UNDEF, its all just UI business as usual.

If there is no response - this is where the proposed ‘interim’ style display of a prediction would get useful - it shows something amiss.
I don’t see why that should not persist until a real update comes along.

My overall suggestion here is that if we get UIs acting on prediction then we can usefully stop autoupdate making the real updates follow-on in many cases - while still satisfying responsive UI, without messing up virtual Items, etc etc.

Yes, that is where we’ve moved to … can we alter the scheme so as to break that link? I think so but it requires several related changes.

Yes - see my primer, Item autoupdate set true acts as a “force” and overrides any binding channel veto policy. Just as it should be, bearing in mind an Item may be linked to many channels.

Example -
channel A, a write only switch. Sensible channel policy VETO, you’ll never get a response here.
channel B, a current sensor. Sensible channel policy VETO, we can’t command a sensor.
User links Item to both channels, gets crap command response because current sensor is slow to update.
User can choose to override veto by his Item configuration, and get fast response, accepting it is a temporary guess at state.

I confess I have no idea who wins in the case of conflicting channel policies, but it would almost certainly be ‘wrong’ for any given user, and the overrides prove useful.

The bit to grasp here is that Item autoupdate setting is not binary true/false, the third default neither-true-nor-false results in different behaviour (essentially its the only state that observes channel policies)

Actually, user may not “choose” anything, because they simply live with the default, never knowing there was a choice to be made, and not realize they’re getting a fast, fake, response until the day that something goes wrong and the real action never happens. Fake responses should not be the default. That is something that people should have to knowingly opt-in to with eyes wide open. I only noticed it because I’m writing a binding and the state kept changing even though I hadn’t written that code yet.

If I were going to implement that I’d put a timeout on it so that it reverts to previous state if the response doesn’t show up.

Also, I’m a binding author, so I have the ability to handle things correctly in the first place. Things like Autoupdate are just hacks to get around low-level shortcomings. While I realize those exist in some cases, it’s only relevant here if I screw up.

The documentation is editable.

If you re-read my veto example, note that by default a binding channel veto succeeds. I guess the place you want to highlight this is the binding authors guide, if such exists.

I have described multiple time that this is how it should be implemented.
The prediction should only change the UI (or whatever), but never the actual item state.
Because it is just that - a prediction and it not the actual state of the item.

If there will never be a response from the device the binding can leverage autoupdate to set the correct state. In this case it is desired that the item state changes with the prediction.
But the binding should explicitly enable autoupdate because it knows, that there is no back channel.

Exactly, this is a huge pitfall that can easily avoided by using a sensible default.

Then you need the buy-in of UI authors.

The channel policies set by the binding are designed for exactly this purpose. Few binding authors use them. (To be fair, a relatively recent introduction)