Set autoupdate="false" as default

Is there any option to set autoupdate="false" as a default for item configuration?
All my devices report the state after a command and for proxy items I properly use postUpdate.
I just don’t want to attach it to every item I have defined.

Logically configuration should actually be the other way around (autoupdate="true") if the user wants to implicitly derive the state from the commands.
This would make way more sense and clear up the problems new users have with postUpdate and sendCommand.

command
Command the device through the defined binding. If the device has no back-channel the value can be implicitly set with autoupdate="true"

update
update the value on the openhab side

I think the short answers are:

  • No, there is no way to change the default to false instead of true

  • The best I can offer is to file an issue on openhab-core.

I’d consider it a breaking change so getting a change like this in before OH 3 is released would be the fastest way to get it done, assuming the maintainers agree with the change.

There is enabled property in AutoUpdateManager

So I guess, that

org.eclipse.smarthome.autoupdate:enabled=false

in runtime.cfg should do the trick.

2 Likes

Way ahead of you, and @rossko57 explained the feature and the mechanics very nicely.

@pauli_anttila:
Thank you very much. But if I disable autoupdate completely I’ll have to create rules for all proxy items I show in the sitemaps. I’m not sure if that’s what I desire, I think I’ll have to try it out to get a feel how it handles.

I still expect openhab to not automatically make assumptions for devices that provide a back channel because it creates confusing behavior.
This would not even a breaking change, it’s just a change in timely behavior.
However I am unclear how to achieve a change like that.

That’s a very good find. Can you tell if that disables autoupdate altogether, or if it only changes the per-Item default autoupdate behaviour?

As I said in github, I think you would need to persuade each binding maintainer about use of per-channel “veto”, as the best place to make that decision.

The only place I am currently sure that gets used is Zigbee binding, and has of itself led to surprises. Long tale about that -


The binding can work in command-response mode (hurrah! let’s veto autoupdate)
or can work in command-silence-eventual poll mode (oh - now I want autoupdate!!)
and this presents a conundrum.