General discussion about AutoUpdate of Items

Add-ons Bindings
,
1

Hello User, Developers, Maintainers,

I would like to start a general discussion on the topic “Auto Update” of items.

In openhab items are automatically updated by commands. This is currently not the task of the bindings. But when a binding is unable to execute the command the item is set anyway and displays an incorrect status.

Only by adding autoupdate="false" to the item configuration this behavior can be disabled per item. In this case you have to update the item manually by rule because the bindings do not do this.

Of course it would be left to the simplest of this the binding. But there are a few things to consider.

  • There are multiple bindings per item allowed. Which binding here is right in case of item update?
  • All current bindings are not able to update the item states.
  • Is a per binding change possible and also a good idea? Why not?
  • How many users affected by this issue/´feature?
  • Everything must remain compatible

Well, this is a design decision that might no longer be optimal today. But that is the standard, and we should here find a user-friendly solution.

I start this discussion, because I wanted to change the behavior of the “Homematic” binding. To this end, there is the PR https://github.com/openhab/openhab/pull/3463 in openhab repository. I would also like to include this in my eBUS Binding.

I would like to discuss this behavior with other binding developers and users.

Maybe I’m completely wrong with my problem and no one else sees a problem.

1 Like
2

Sending a command to an item by default changes its state to match the command, unless you add autoupdate="false" to the binding section of the item, in which case this is suppressed. I always assumed that this default behavior exists so that the user interface would immediately feed back to the user that they just toggled a switch, changed a setpoint, etc.

In cases where the true state of the item cannot be fed back to openHAB immediately but the command was in fact passed to the binding, this default auto-update behavior makes sense. However, the UI is, in a way at that moment, “lying” about the state of the item when the item is bound to one or more underlying systems that may not have yet, or may never, process the command so that the desired command is reflected faithfully in the bound system(s).

The bindings I’m familiar with do in fact update the state of the item at some point after the command is sent (if they can), but the binding update is usually not noticed because the auto-update logic described above already changed the state when the user requested it. The problem, however, is that some bindings take a long time to get around to updating the state, so the auto-update logic fills in the user-experienced time gap between user action and the binding updating the item, in order to give the appearance of an instantaneous change. The is a sound user-interface practice, in my opinion.

The way I view bindings is that they are simply trying to update the states of items as best they can over time to match the systems they are integrating to, but the binding in no way “owns” control over the items it is bound to. So when a user or rule sends a command to an item, and openHAB propagates that command to your binding, your binding will try to execute that command as best it can, but is not in a position to update the item’s state if it doesn’t actually know the state. So if your binding is in a disconnected state, at that moment you simply don’t know what state the item should have, and so you simply shouldn’t be setting the state when you don’t know it.

I think the big issue here has more to do with giving better feedback to users about whether your binding is working when it needs to be working. The next generation of openHAB has an improved concept of “bridge thing” that tries to represent the state of the path from openHAB to a device, and more sophisticated semantics exist when the path to the thing is not possible because of the state of the bridge. At the end of the day, I think these are more user-interface issues, and trying to compensate for it by changing per-binding semantics would be a step in the wrong direction. Also, the idea that one binding would have very different semantics about how it processes updates and commands from other bindings gives me chills, as this would add yet a new level of complexity to an already very complex system.

Perhaps the Homematic binding could instead support item bindings that report the last time you communicated with the underlying equipment, or have a simple status message update a String item, so the user has better feedback that what they are trying to do won’t, or didn’t, work?

3

Hello watou,

thank you for your detailed answer. I’m still thinking about your answer, but I would answer to your last paragraph immediately.

The “Homematic” binding provides options to configurate items for sensor “Configuration pending”, “Unreachable”, “RSSI” etc.

1 Like
4

Some details about the auto update behavior…

There is an AutoUpdateGenericBindingProvider (binding name: autoupdate) that is responsible for optionally doing the post-command update of an item. In the typical case, bindings have no direct interaction with the autoupdate behavior although a binding may update the item state itself independent of any autoupdate configurations.

However, if any binding provider implements the AutoUpdateBindingProvider interface, then it provides an autoUpdate(itemName) method that returns a Boolean value indicating if a specific item should be autoupdated or not. The following binding providers implement the interface and provide varying implementations for the autoUpdate function.

  • AlarmDecoderGenericBindingProvider (always returns true)
  • AutoUpdateGenericBindingProvider (parses {autoupdate=“”} binding configs, default is true)
  • HDanywhereGenericBindingProvider (always returns false)
  • IhcGenericBindingProvider (always returns null)
  • InsteonPLMGenericBindingProvider (always returns true)
  • KNXGenericBindingProvider (derived from datapoint configuration)
  • PlugwiseGenericBindingProvider (always returns false)
  • RFXComGenericBindingProvider (always returns null)
  • ZWaveGenericBindingProvider (always returns false)

If a binding returns null, it appears to me this is a no-op and has no effect on the autoupdate behavior. If the binding returns false, then this means the binding is requesting that autoupdate be disabled (but the request may be overridden by other binding providers). If the binding returns true, this will enable autoupdate for all items.

When multiple AutoUpdateBindingProvider binding providers exist, the behavior is interesting and potentially surprising. According to the Javadocs, the AutoUpdateBinding…

"Iterates through all registered AutoUpdateBindingProviders and
checks whether an autoupdate configuration is available for itemName.

If there are more then one AutoUpdateBindingProviders providing
a configuration the results are combined by a logical OR. If no
configuration is provided at all the autoupdate defaults to true
and an update is posted for the corresponding State."

As stated earlier, a null value is ignored (represents neither true nor false).

(Warning: I haven’t done runtime testing of the following information yet, so there may be inaccuracies!)

It appears to me that if one of the binding providers that returns true for all items is present (Insteon and AlarmDecoder), then autoupdate will be enabled for all items regardless of any {autoupdate=“false”} binding config on an item. This is globally true even for items completely unrelated to those binding providers.

For binding providers that always return false, that behavior can be overridden by an item autoupdate binding config. However, it seems that this also globally changes the default autoupdate binding behavior to be disabled rather than enabled. For example, if a item has no autoupdate binding config and the ZWave addon is present, then the item (which may be completely unrelated to ZWave) will have it autoupdate behavior disabled. Without the ZWave component it would be enabled by default.

If my analysis is correct, then I’d recommend that any binding provider implementing ‘AutoUpdateBindingProvider’ should check if the item being queried in the autoUpdate function is an item associated with their binding and return null for any that are not. However, if a item command is processed by multiple bindings, there still may be surprising interactions.

1 Like
5

I came across the problem while developing the Homematic binding and implemented the reloading of all datapoints if there is a communication error (see exception handling in the HomematicCommunicator). So the item state should be wrong for a short time and then goes back to the real value from the gateway.

I think this should be handled by the framework itself to have a consistent behaviour of all bindings.
So what is the best solution, i think we need a confirmation from the binding:

  1. Only update the state if the binding confirms the change. But the eventbus never knows the command in case of an error, is this good? Also, if the binding needs a while to know if the change can be done, the event is blocked.

  2. Update the state, if the binding does not confirm the change, switch the state back to the previous value. So we have two events for one command in case of an error. If there is a rule, we don’t know in the rule if the command was successful or not.

  3. Add a flag to the State and/or Command class where the binding must confirm that the change has been done. The state is on the eventbus, but unconfirmed until the binding confirms it. In a rule, the user can configure the trigger if the confirmation must be set or not.

Nr. 3 is my favorite…

6

:+1:

7

I total agree with you all that the framework should handle this instead of the bindings. As far as I know the openHAB2 framework handles this differently?! But I’m right that than the compatibility layer causes the same behaviour than in openHAB 1?

In that case we should think about a solution for the compatibility layer to address this issue.

8

If this is really their implementation, this is DEFINITELY a bug in those bindings! A binding should clearly ONLY return a value other than null on items that itself is bound to. That’s what the auto-update feature is all about: To give bindings a chance to overrule the auto-update (which happens in the default case, especially, if no binding is bound to an item).