Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse SmartHome » autoupdate(Moved from: https://github.com/eclipse/smarthome/issues/1194)
autoupdate [message #1726680] Tue, 15 March 2016 16:47 Go to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 100
Registered: August 2014
Senior Member

This continues: https://github.com/eclipse/smarthome/issues/1194
As @kaikreuzer stated in the topic and I agree the forum should be used for such discussions.

---

I would assume that the autoupdate does not make sense for items that are linked to a channel.
Also for "uni-directional bindings" (I assume you mean bindings that handle uni-directional thing communication) I would assume that a binding updates the channel state if a command is received.
If binding_a receive the command ON for a unidirectional actor (so the binding does not know if the actor has been switched on really), I would still prefer if the binding_a updates the state of the channel to ON.
The binding_a is the only one who knows that it will never receive a response from this device.
Re: autoupdate [message #1726767 is a reply to message #1726680] Wed, 16 March 2016 10:50 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
To add to the discussion: quid the desired behaviour if you have more than one channel linked to the item? imo, updating the state should be delegated to the handler
To add to the discussion 2: what about the "bridging" of state updates between multiple channels linked to a single Item? if binding_a updates the channel, the item gets updated, and the the other channel of binding_b is updated as well?
Re: autoupdate [message #1726773 is a reply to message #1726767] Wed, 16 March 2016 11:45 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 100
Registered: August 2014
Senior Member

karel goderis wrote on Wed, 16 March 2016 10:50
if binding_a updates the channel, the item gets updated, and the the other channel of binding_b is updated as well?


What do you mean with "the other channel of binding_b is updated"?
Items have a state, a channel does not really exist, there is just an UID. Or I am missing something?
Re: autoupdate [message #1727028 is a reply to message #1726773] Fri, 18 March 2016 10:53 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
Switch someSwitch { channel="thing_a:....:channel_a", channel="thing_b:....:channel_b"

The state of channel_a gets updated by the handler of thing_a, then someSwitch changes state, and consequently, the state of channel_b gets updated with thing_b calling handleUpdate(). someSwitch effectively acts as a bridge between thing_a and thing_b
Re: autoupdate [message #1727086 is a reply to message #1727028] Fri, 18 March 2016 17:58 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 100
Registered: August 2014
Senior Member

I know that people assign multiple stuff to one item to implement a "connection".

But I don't think this is the correct use of state vs. command.

I would prefer Kai could give some details.

My assumption is that most bindings implements a view of the outside world. So we transfer states from the real device to channels and delegate it to items.
A item is currently used to transmit commands to channels and to the outside world (I think we could drop the discussion about use channels directly here, there is a separate issue).

It is also valid for bindings to act on state changes, e.g. let's assume the system itself simulate a sensor. We would send "to the outside world" changes states (e.g. a new temperature value).

If you handle the state update of an update similar to a command for a command, then I assume the split between a state (this is the current state) and a command (I would like to trigger something) is obsolete.

IMHO we need a simple mechanism to link channels together (common example a rocker and a light actor). But mixing state and commands seems to be the wrong approach (for me).
Re: autoupdate [message #1727135 is a reply to message #1727086] Sat, 19 March 2016 22:24 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 100
Registered: August 2014
Senior Member

The bundle "org.eclipse.smarthome.model.item" contains an Import-Package of "org.eclipse.smarthome.core.autoupdate".
With this import I cannot deinstall the autoupdate bundle.

So, do I need to implement an AutoUpdateGenericBindingConfigProvider that returns false on every "autoUpdate(String itemName)" call, to disable the auto update?

I also don't think this "By default the State is getting updated automatically which is desired behavior in most of the cases." is correct.
The desired behaviour is that a binding handles the command and set the state.
The autoupdate is IMHO only useful (see above) for items that are not handled by an update / rule / something similar.
Re: autoupdate [message #1727747 is a reply to message #1727135] Sat, 26 March 2016 16:43 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
To follow-up on the difference between updates and commands: if you have an Item that is "interconnecting" two channels, each from a different binding.

1. you send a Command to the Item
2. binding_a relays the command to the hardware device, binding_b does something similar
3. the hardware device responds with a status update, as a confirmation that the command was executed well
4. binding_a updates the state of the channel to reflect this
5. the Item gets updated
6. binding_b is triggered with an handle_update() (it already received a command before)

So, binding_b has no way to distinguish between an update and a command on a given channel, so, it needs to implement both handleUpdate and handleCommand in a similar fashion?

It is rather unclear when handleUpdate and handleCommand should be used, and what they each should provide/implement. Since an Item is not directly connected to a binding anymore, but things are funnelled through Channels, how can the binding know that is was a Command that was send to an Item, or an Update that was issued, on that same channel?

To me there is no difference anymore between Updates and Commands, but rather on the type of Channel it was done, the binding has to make the distinction, no? And, how to solve the problem of receiving the same change of the Item twice, once as a command, once as an update? is it up to the core to track this and make sure that the binding receives it only once?

This is quite confusing.
Re: autoupdate [message #1727752 is a reply to message #1727747] Sat, 26 March 2016 21:16 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 100
Registered: August 2014
Senior Member

I posted my point of view above (https://www.eclipse.org/forums/index.php?t=msg&th=1075677&goto=1727086&#msg_1727086).
I don't think that such a link (one item, multiple channels) should be used to link e.g. a state update reported by thing_a and handle that as a command for thing_b (for boths to be more correct "channel_... of thing_...).

@kaikreuzer, could you add your point of view?
Re: autoupdate [message #1727874 is a reply to message #1727752] Mon, 28 March 2016 19:47 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 648
Registered: December 2011
Senior Member
Sorry to join in so late, this thread slipped my attention...

I do not have much to add to what Markus said about commands vs. state updates already.
As stated in https://github.com/openhab/openhab/wiki#the-event-bus:
Quote:
There are mainly two types of events:
Commands which trigger an action or a state change of some item/device.
Status updates which inform about a status change of some item/device (often as a response to a command)

So indeed, bindings should hardly ever implement handleUpdate(), because they themselves know the state of "their" device best and can ignore if anybody else claims to know it better.

> Since an Item is not directly connected to a binding anymore, but things are funnelled through Channels

It still is - the channel is just a formalized way to provide a binding configuration that was before different for every binding. Nothing really changed here from openHAB 1.

Regarding KNX: Karel, you are right that in theory every telegram on the KNX bus is the same, but in practice, you clearly have GAs that are used for triggering actions and others that are used to report status changes.
Take e.g. a wall button with a status LED: Pressing the button sends ON on 0/1/1 and the actuator responds with a 1/1/1 to say that its new state is ON. The 1/1/1 is configured in the button to control the LED. The important aspect here is that the LED simply reflects the status of a different device (the actuator) and is NOT modelled as a device itself - neither in KNX nor in openHAB. So a valid scenario where you might WANT to react on handleUpdate() is the situation that this button LED is showing the state of some device that is controlled by openHAB and not KNX. But in the majority of cases, you simply would not want to care about state updates from the openHAB side.

> I would assume that the autoupdate does not make sense for items that are linked to a channel.

You should note that the auto-update functionality is there since 6 years now and has always been active by default. From the 120+ bindings, only a very low fraction uses the possibility to turn it off. So I think the reality shows that there isn't anything wrong with it.
I would claim that it is important also for items that have a channel linked. Take e.g. the hue binding: You send commands immediately (and they are immediately received by the device), but the state updates happen only every 10 seconds through polling - and in most other cases it also happens asynchronously or at least delayed, since you need a physical roundtrip to the device.
If the user now switches a toggle in the UI, he wants it to IMMEDIATELY stay at the new state and only if something might have gone wrong, it is ok to move back again later on. The auto-update provides this immediate change, which I call the "optimistically anticipated state". You could now argue that you are not that optimistic and thus it is not right to anticipate this state before you have a definitive answer from the device itself. But this would mean in consequence that we would have to introduce something like a "transition period", where a UI should show the state as "pending" and we would have to find good ways to do render this, deal with timeouts, etc. - all pretty complex stuff, just because not being optimistic Wink

Just my two cents...
Kai
Re: autoupdate [message #1727890 is a reply to message #1727874] Tue, 29 March 2016 05:44 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
Kai, I do agree with what you say, but the practical consequences are not clear.

How can a binding make the distinction between what is to be considered a "regular" handleUpdate() call, received through some OH/ESH mechanism (script rule, UI,...), and a handleUpdate() that is the consequence of an Item being updated after a handleCommand()?

I guess for bindings like KNX it will boil down to not implementing the handleUpdate(), but specifically foresee status GA's in the Thing definition (as it is proposed today in the PR), and deal with those separately (Although, for KNX, as you pointed out, they are strictly speaking the same)
Re: autoupdate [message #1727960 is a reply to message #1727890] Tue, 29 March 2016 20:53 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 648
Registered: December 2011
Senior Member
> I guess for bindings like KNX it will boil down to not implementing the handleUpdate(), but specifically foresee status GA's in the Thing definition

I just checked, how the OH1 binding handles it. The issue is the same there - and the solution there is this method, which means that state updates are generally sent to the GA, but it is tracked which ones resulted from a command from the binding itself and these are suppressed.

I agree that this isn't particularly nice and maybe even risky (because potentially state updates can suddenly trigger an action on KNX although they are not supposed to).
So having some specific flag on a channel to allow state updates to be processed might be a good idea.
Re: autoupdate [message #1729102 is a reply to message #1727874] Mon, 11 April 2016 08:42 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 100
Registered: August 2014
Senior Member

Kai Kreuzer wrote on Mon, 28 March 2016 19:47
> I would assume that the autoupdate does not make sense for items that are linked to a channel.

You should note that the auto-update functionality is there since 6 years now and has always been active by default. From the 120+ bindings, only a very low fraction uses the possibility to turn it off. So I think the reality shows that there isn't anything wrong with it.


I would like to concentrate (ATM) on Eclipse SmartHome only.
Is it a must that ESH is compatible to the openHAB 1 bindings?


Kai Kreuzer wrote on Mon, 28 March 2016 19:47
I would claim that it is important also for items that have a channel linked. Take e.g. the hue binding: You send commands immediately (and they are immediately received by the device), but the state updates happen only every 10 seconds through polling - and in most other cases it also happens asynchronously or at least delayed, since you need a physical roundtrip to the device.
If the user now switches a toggle in the UI, he wants it to IMMEDIATELY stay at the new state and only if something might have gone wrong, it is ok to move back again later on. The auto-update provides this immediate change, which I call the "optimistically anticipated state". You could now argue that you are not that optimistic and thus it is not right to anticipate this state before you have a definitive answer from the device itself. But this would mean in consequence that we would have to introduce something like a "transition period", where a UI should show the state as "pending" and we would have to find good ways to do render this, deal with timeouts, etc. - all pretty complex stuff, just because not being optimistic Wink


I agree that the UI have to handle / gives a feedback to the user, that the command has been received.

But IMHO the current approach is not correct.

I will try to explain it with an example (the example should demonstrate a scenario and perhaps make no sense in its simplification standalone):
=== Example 1 ===
Let's assume my thing has at least two channels. One channel (A) is used for a "control locked" function and the other channel (B) is one that controls something.
If a command is received for the channel B the binding needs to check the state of channel A.
If A is ON the command should be dropped and not executed.
If A is OFF the command should be handled and a state change will follow.

With autoupdate = true, the UI shows a state change for the item linked to channel A regardless of the state of channel B and the item does not show the correct state (the binding does not send a state update of B at all).

=== Example 2 ===
The binding receives a command for a channel and set the state immediately.
The channel is a switch and should be used as trigger only (similar to a button instead of a switch - in german "schalter vs. taster").
If an OFF is received, do nothing (perhaps send state update OFF).
If an ON is received, handle something (perhaps send the state update OFF).
I would expect that if I use a UI to set ON, the state is updated to OFF again (if the binding sends state update OFF always).
If my observation has been correct, the events are handled asynchron and sometimes the autoupdate is executed after the binding sets the state back.


@kaikreuzer: WDYT are the examples completely wrong? Or do I miss something? Sure, the bindings could prevent the autoupdate for all items linked to such channels but should a binding rely on the fact that another bundle could implement such an autoupdate function and add code to prevent other code?
Re: autoupdate [message #1729683 is a reply to message #1729102] Mon, 18 April 2016 06:39 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 100
Registered: August 2014
Senior Member

ping @kaikreuzer
Re: autoupdate [message #1729703 is a reply to message #1729683] Mon, 18 April 2016 08:49 Go to previous message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 648
Registered: December 2011
Senior Member
Hm, there is an easy answer from my POV:

Example 1 is the natural exception for which we would need https://github.com/eclipse/smarthome/issues/595, so that your binding can declare that channel B does not necessarily follow the logic that the state changes according to the received command.

Example 2 is the reason why we urgently need https://github.com/eclipse/smarthome/issues/1043 - triggers should simply not have any state.
Previous Topic:The starting of ESH
Next Topic:Understand Philips Hue Binding
Goto Forum:
  


Current Time: Mon Jun 25 08:35:37 GMT 2018

Powered by FUDForum. Page generated in 0.02879 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top