How should UI implement `autoupdate="false"` for Switch?

1

What is autoupdate?

This is explained by many people on different places, here one more refresher.

In openHAB, when an item is linked via channel to a device, and the item sends a command to the device, different things can happen:

  • the device near instantly updates its state, so that it matches the received command, and announces its new state;
  • the device near instantly updates its state, so that it matches the received command, and does not announce the new state. Bindings behaving this way are improperly implemented;
  • the device can ignore the command - keep on purpose its old state and announce the old state, thus ItemStateUpdateTrigger does fire;
  • the device can ignore the command - keep on purpose its old state and do not announce the old state. In this case there is no event propagating the old state, ItemStateUpdateTrigger does not fire;
  • the device can act slow, e.g. because it is far away; signals are lost and need to be repeated; or for mechanical reasons changing the state can take a while, so the device updates its state after a while, and then announces its new state;
  • the device can be offline - openHAB sends a command, the command does not reach the device, the device does not update its state.

Items in openHAB have a property autoupdate, which has a default value for all items in openHAB, and can be overwritten per item. With autoupdate=true, when the value of the item is changed by openHAB, and the item is linked to a device, openHAB at the same time updates the state of the item within openHAB and sends the command to the device. When autoupdate=false, openHAB sends the command to the device, the device updates the state of the item, eventually notifying the UIs over the new state.

In particular, with autoupdate=false, when the device is offline, the state of the item is not changed; when the device acts slow, the state of the item is changed delayed. With autoupdate=true the state of the item is changed instantly, it is irrelevant if the device is slow or offline.

How should IU implement autoupdate=false for a switch?

There are different possiblities to implement autoupdate=false, when the user clicks in the UIs:

  1. The switch UI component intercepts the click/touch event, and from the intercepted event handler sends the command to the device. The intercepted event handler prevents the default action to happen (toggle the switch). After the device updates the state, there is an event in openHAB, and after that event is received by the UI, the item is updated in the UI.
  2. The switch UI component sends the command to the device, and at the same time changes the visual state of the toggle. So there is a difference between state of toggle and state of item and this difference creates an illusion. If after a while no event is received from openHAB, that the state of the item was changed, the switch UI component reverts to its old state, and state of UI-toggle and state of item coincide again.

An advantage of the second approach is that the user sees that the toggle command was accepted. A disadvantage is, that in case the device is slow, the toggle changes its state on the click event, reverts to its old state shortly afterwards, and when the device updates its state, the switch is toggled again. So there are in total three togglings, instead of one.

In the first approach there can also be implemented means, indicating that the toggle command was received by the UI, different from toggling the switch. Users might also not need feedback from the UI that the click command was accepted by the UI, users can get used to the fact that the UI updates its state for autoupdate=false items, only after and if the device has updated its state.

For items with autoupdate=true both approaches behave the same; users do not notice a difference, if the first or second approach is implemented.

This question is on purpose restrained to the simplest case - switch item, and avoids design discussions for slider or color light.

How do you think switch/toggle items should be implemented in the UIs of openHAB, when the items have autoupdate="false" metadata? Which of the mentioned approaches should be preferred? Should some completely diffent way be taken?

2

If I understand it correctly, (1) above doesn’t update the UI to indicate that it has been turned on until the device updates the state. That might cause confusion and make people keep clicking on it thinking something was wrong.

Your idea to show some feedback that the click has been received and processed (sent the command) but the status is not yet updated might be a good one.

Alternatively, option (2) above, but with a configurable default that’s slightly longer, say 2 seconds? If the time taken from command to state update is less than that, the user won’t see the switch goes off then back on. It just stays on all the time.

3

I’ll just say that I absolutely hate autoupdate. I think there should be a way to turn it off globally. It’s one of the things I find mist troubling with OH. It tried to address this as one of my first interactions on this forum, with the usual overwhelming pushback of course.

I’ve left it along ever since, because life is too short to fight when the other side isn’t even willing to listen. But, basically, autoupdate=true is the same as lie=true. I have to use other sensors like power consumption, as feedback for switch items to know if they are on or off. Not everything has this possibility, and it makes designing the UI awkward.

The core problem is that two functions are attempted forced into one control. For a switch, there are two states: 1) The commanded position (the state the user has requested that the switch should be in) and 2) The resulting state (whether the device/outlet/whatever is turned on or off). Both can’t be expressed using just one piece of information. Physical light switches where you can’t see the result immediately, has an indicator lamp that indicates if the load is on or off. Most light switches are placed in the immediate vicinity of the light itself, so the feedback is the light itself. That’s not a good feedback mechanism for a home automation system that can be operated from far away from the lamp.

Here is an example of how a switch with feedback could be implemented:

image
image800×599 38.1 KB

image
image480×640 29.1 KB

Something akin to that would have to exist for all channels where feedback (a resulting state) is possible. The “write only” channels are the only ones that should use the current switch control, there is no feedback, so all you know is the commanded position.

4

Some technologies do not send back any state information. For example, if you use the IRTrans binding to change the channel on your non-smart TV, how does this binding know that the TV changed the channel? RFXCOM similarly has no ack nor status update messages comming back to OH to confirm the change.

If the binding can receive a state after sending the command and it doesn’t update the Item, it’s improperly implemented. But just because a binding doesn’t does not necessarily mean it’s wrong. The technology may not support it.

The current behavior has been around since OH 1.x as has autoupdate. And autoupdate is true by default. That doesn’t mean it cannot be changed, just that extreme care needs to be taken if the behavior is to be changed.

This will impact BasicUI, both phone apps, and MainUI at a minimum.

5

I opened the discussion here, as there are different opinions on how to implement autoupdate=false for sitemaps under openHAB-Android.

The way to change the default autoupdate for all items to false, is by modifying the file /var/lib/openhab/config/org/openhab/autoupdate.config:

:org.apache.felix.configadmin.revision:=L"1"
sendOptimisticUpdates="true"
service.pid="org.openhab.autoupdate"
6

I’d add, in the case of OH Zwave, a device response to a Set command is forbidden by the Zwave specifications. What the binding contains is a command poll (a Get state) after the command is sent. The default is a 1.5 second delay. It’s been a while, but without autoupdate IIRC, the item will quickly turn off (after being turned on) for 1.5 seconds until the poll is received. It was distracting to users. Not all devices are compliant, so some devices report without the poll and the binding handles that fine.

I’m not sure about Zigbee, but it is/was also a Silabs creation, so could be the same. However, specification compliance with Zigbee is a little more iffy.

7

I think autoupdate is very troubling with my Z-Wave devices, perhaps especially them, because you “never know” if they’ll comply/if the packet gets lost on the way. I very much prefer no autoupdate, because otherwise, I have no idea what the device actually has done. 1.5 seconds is a very long time to wait to do the poll, why was that chosen? If you say it’s by default, does that mean that I can change it? 100 ms sounds plenty to me, because even if it takes the packet longer to reach the device, chances are that the same is true for the “poll” packet.

I think it’s much less “disturbing” that the switch doesn’t change until the state change is confirmed, however long that takes. Shorter is better of course, but it’s essential to know what the command got through.

We control e.g. the electric fence for the horses with Z-Wave, and defrosting of the water pipes in the stable. You’d like to “know” that what you have commanded is actually followed through. That’s why we need to use switches in combination with the power sensor from the same devices to determine if the command actually worked, and it’s not rare at all that it doesn’t. Even that would be better without autoupdate, because then you could send another ON command when it didn’t work. Instead, now, you’ll first have to send an OFF command, wait so that it has hopefully propagated through the network, and then turn it ON again - because otherwise, you risk that OFF arrives after ON…

8

You do have strong feelings about a lot of things. :wink:

Yes it is configurable. Based on your comments (about dropped commands), I’d be cautious about reducing too much. The ZW frames travel at 9.6Kb, 40Kb and 100Kb (not wifi speeds) and can have multiple hops. The default was set by the developer.

poll2026-07-21 200203
poll2026-07-21 200203584×256 8.16 KB

I did a recent scan captured on my zniffer. The device is maybe 20 ft from the controller, so is fast (100Kb) but a bunch of hops. Since you have experienced drops it is hard to say without zniffer data.

Zen73 response 2026-07-21 170118
Zen73 response 2026-07-21 1701181382×167 33.8 KB

Note on this thread topic; This device is not compliant since it responded to a Set with a Report (no poll). (I created this to copy the device manufacturer in a DM).

Good luck

9

Seems like if one is to turn off Autoupdate and still have the system make sense, the switch needs a third or a fourth state, those being either: “change requested” or the combination “off requested” and “on requested” shown till the device reports it’s current state.

I also find the fact that autoupdate leaves the UI showing the incorrect state quite annoying. Maybe my all Zwave site is more susceptible to that.

I’m sure there are many who would find that even more annoying, but it at least in theory ever show the wrong state, just occasionally an unknown state.

10

I must admit that I do, but this one is special. autoupdate is one of the very first things I tried to raise on this forum, years ago, and I’ve always disliked it strongly. It’s just that since most seem to be fine with it, and changing it would require changes in many places, I’ve never had “the energy” to try to do something about it. It’s always in the back of my mind though, it’s my one biggest “problems” with OH.

I know that I can turn it off, but the UI controls aren’t made to handle it, so it’s not really a satisfactory solution. To me, most of the controls should be “dual”, where you set/command it one place, and then see the result next to it/independently. It could be solved for knobs, sliders etc. by having some kind of “colored fill” or similar that displayed the state. If the control setting and the state mismatched, you knew that something didn’t play ball. You could verify (with a delay) that what you commanded happened, when things worked as they should.

I feel that the controls would have to support this before it would work “properly” without autoupdate.

11

I would like to see the UI have a “pending” or expected value indicator when autoupdate=false and timeout not reached.

Maybe the visible “indicator” should be the value expected to come back (from device) for the Item.

I always found the UI confusing for this too so I have been grepping/tailing logs to see what really is going on.

(In my case this was very apparent with zwave devices covering several buildings, but i see the same with zigbee too. Ie. it is always devices with poor connectivity in the mesh)

12

It would take extra Items and a little work but this can be achieved in OH at least with MainUI. I’m not as certain with Sitemap UIs how to do that easily but it could be achieved.

The general high level approach:

  1. create an Item to receive commands from OH. You can create a rule to forward the commands or link the Item to the Channel and set up a script Thing to Item transformation that drops the updates. This Item never represents the state of the device, only what you’ve asked the device to do. Configure autoupdate=true on this Item.

  2. create an Item to receive updates from the binding. You can simply just be careful to never send commands to this Item, or configure the Item to Thing script transformation to drop the commands if you want to make sure. This Item always repersents the actual state of the Item, or at least the state of the Item as reported by the binding. Set this Item to autoupdate=false, though since it never receives commands that’s just a precaution.

  3. In MainUI you can create a custom widget that uses both Items that allow you to command the Item created in 1 and show the status from Item 2.

NOTE: This is neither an indorsement for nor an argument against autoupdate as a concept nor proposed changes to it. It is a concrete example of what can be achieved right now. Nothing more.

Ultimately there are two problems here.

  1. Did the command even get sent? This is the default assumption for most of the users of your home automation who are not you. They toggle the switch. Nothing changes on the UI. Maybe I clicked in the wrong place. Still didn’t change, click click click click click. 2 seconds later (or what ever) you are now having epelitic seizures as the light strobes as it responds to each and every one of those clicks.
  2. Did the device respond to the command? This one is a little more subtle from the end user’s perspective. The UI shows the light is ON but can see the light is off.

For the majority of users, 1 is a bigger problem than 2. So unless and until something that solves both problems is proposed and implemented, autoupdate remains defaulted to true.

But you can default it to false everywhere (see above) and you can configure it on an Item by Item basis. And for those rare Items where 2 is the bigger problem, for now you have a way to achieve what you need.

I will also note, that if you are seeing these sorts of delays for most technologies, it usually means something is wrong.

13

Is it? I thought autoupdate was “system wide”, so that it would also reflect the “guessed state”?

What I suggest would solve both. The controls would have to show the commanded state and the actual state independently. I think that’s the only way to make this “truly satisfactory”. But, implementing this across controls in all their UIs and variations would be a sizable task.

For Z-Wave, this has been a problem as long as I’ve used it. The whole “mesh network” thing of nodes relaying packets isn’t particularly reliable, and while those that connect directly to the controller are usually relatively obedient, that’s not the case for those that have to jump through some other devices, like the devices we have in the stable.

But, I have other situations as well - like my Onkyo that sometimes just refuses to accept commands. It can be both because it has some internal rule that only “one connection” can make changes, so if it sometimes feels like another device/computer “is in control”, it will reject what OH sends. The other alternative is that the network card in the Onkyo sometimes just hang, and it must be restarted to start listening. So, I can’t just assume that the command I sent was received.

14

Autoupdate has always been setable at the individual Item level.

version: 1
items:
  JennPresence:
    type: Switch
    label: Jenn's Presence
    icon: f7:person_circle
    autoupdate: true
    groups:
      - Presence

In the UI you’ll find it under “Add Metadata”. The default is true but you can set it to false on those Items where you don’t want that behavior.

Or you can set it to default to false and then enable it on individual items as needed.

It’s never been an all or nothing setting.

15

I know that, that’s not what I meant. But, it turns out that what I meant was probably wrong, I somehow thought of the autoupdate as a “channel level event” that would be broadcast to all Items bound to that channel, but that’s not correct. So, what you said is probably right.

16

You defintely can have two Items linked to the same Channel, one with autoupdate enabled and one with it disabled. The setting lives at the Item, not the Link nor the Channel.

From an operational perspective, it is a separate “service” (don’t really know where or how it’s implemented in code) that works off the event bus. The command is put on the bus and autoupdate gets kicked off (along with what ever is subscribed to the bus for commands for to that Item like the Link, rules, and persistence), predicts the new state, and issues an update back to the bus.

17

oh, clever! why didnt I think of that, I have to investigate :slight_smile:

Just to clarify:

I write all my new rules in HABapp, and the UI is very little used. Items are defined in conf-files, some with autoupdate=false. Missed commands to a device that control a 5KW heater can be expensive, so until now I have sent a refresh every few minutes. However, that is not good enough if a device like that goes bad.

Like @Nadahar I use Zigbee/ZWave to prevent frozen water (and for diesel-engine heaters).

18

Even if you couldn’t link the same Channel to two different Items, you could still make one Item not linked to any Channel which you send the commands to and the state Item is linked to the Channel. But in that case you need a rule to forward the command to the state Item and the State Item would need autoupdate set to false.

19

On a related note, I added a PR to the Zwave repo Add Supervision CC handling for binary switch commands by apella12 · Pull Request #2032 · openhab/org.openhab.binding.zwave. What this does is use a class that allows the device to respond to switch commands with its new state. No waiting for a command poll. On devices with good communication this will be at the msec level, so will be smoother for those with autoupdate=“false”. One caveat is that only newer devices support Supervision. This is also used today in zwave-js.

Separately on the comments about dropped Zwave commands for remote switches. As background, the binding only sends one command to a specific node at one time. If the command is not acknowledged by the device the controller will try different routes and different speeds for five seconds. After 5 seconds the command is cancelled but requeued. After three tries and 15 seconds the node should get marked as Dead. The command poll is queued at the interval on the UI but won’t be sent until after the three switch tries are over (at least theoretically). There is the one command rule, and the poll is also a lower priority when messages are pulled from the queue. If a node is Dead no new commands will be sent, however, I have seen that commands in the queue still get sent to a Dead node. I could imagine a scenario where the command fails, the device is marked Dead, but the queued poll is still sent and is acknowledged, so the device is marked alive. Anyway, for those with the issue, the flow I described is revealed at the debug level but should also appear in the event log (if the node changes state, even temporarily).

Besides posting an issue on the forum with the logs to find any insight, my other suggestion is to look at a new 800 series switch. The OH ZW binding does not have the LR inclusion option (and LR is limited to North America anyway), but the radios of the new switches are advertised as better range, even with classic inclusion (nodes up to 232). They also will likely have the Supervision CC (if that gets added).

20

This differs quite a lot from my practical experience, so I’m wondering is there might be some “holes” in the logic in the binding or something like that. It’s not that uncommon that commands don’t get through, and that doesn’t mean that the node is considered “dead” (unless that isn’t visible from OH), the Thing stays online and everything is “peachy” except that the command is never carried out. In my experience, if nothing has happened within 3-4 seconds, it won’t happen. You must simply do it again. That shouldn’t be possible with the scenario you describe.

I actually have much less of these problems than I used to after I put my ZWave controller on a USB extension so the controller itself is far away from the RPi, higher up on a wall. But, regardless of how frequent the problems are, I just know that I can’t trust what I see in the UI. I’ve seen it disagree for hours if there’s an issue and a command never gets through, but I forgot about it. Hours later, that might be the situation. Don’t ask me how that’s possible, you’d think that several polls/reports would have taken place in the meanwhile.

From what I’ve read, there have been numerous issues with the 700 and 800s? I typically wait until everything has been straightened out and stabilized before I’m willing to upgrade, and I’d rather not do it at all. “You know what you have, but not what you get”.