Home » Archived » Eclipse SmartHome » autoupdate(Moved from: https://github.com/eclipse/smarthome/issues/1194)
autoupdate [message #1726680] |
Tue, 15 March 2016 16:47 |
|
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 #1726773 is a reply to message #1726767] |
Wed, 16 March 2016 11:45 |
|
karel goderis wrote on Wed, 16 March 2016 10:50if 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 #1727086 is a reply to message #1727028] |
Fri, 18 March 2016 17:58 |
|
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 |
|
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 |
Karel Goderis 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 #1727874 is a reply to message #1727752] |
Mon, 28 March 2016 19:47 |
Kai Kreuzer Messages: 673 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
Just my two cents...
Kai
|
|
|
Re: autoupdate [message #1727890 is a reply to message #1727874] |
Tue, 29 March 2016 05:44 |
Karel Goderis 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 #1729102 is a reply to message #1727874] |
Mon, 11 April 2016 08:42 |
|
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:47I 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
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?
|
|
| | |
Goto Forum:
Current Time: Thu Apr 25 17:21:10 GMT 2024
Powered by FUDForum. Page generated in 0.04084 seconds
|