Smarthome: triggeringItem state not update before rule is triggered.

[Josar]

As discussed here https://community.openhab.org/t/group-rules-trigger/38512

When items are grouped and then the group switch is pressed this triggers the members.
But reading out the state results in wrong values, sometimes.

Hardware RPI3
setup and log can be found in the thread.

[Josar]

This is faulty by design. Using received command triggers before the state is updated.
to get the actual command use implicit variable receivedCommand instead of triggeringItem.state solves this problem.

But the design is somehow not as i would expect it. On Trigger RECEIVED COMMAND i expect to be able to read out the command which triggered the change. This is solved by the implicite variable, but somehow not intuitiv, IMHO.

[maggu2810]

@Josar Why do you think that the state of an item needs to be changed after an received command at all?

• an item receives a command
• channels could be linked to the items
• every channel is part of a thing
• a thing is handled by a handler (if available)
• the handler implements a handleCommand method
• the handler could do "whatever he wants" in the method

a handler could then do whatever he wants e.g.

• post an state update derived from the command
• send something to a physical device, wait for a response, update the state
• send something to a physical device without updating the state
• do nothing at all

There is also an auto update "feature" that tries to be clever and updates the state async if the command could be converted to one without any handler involved, ...

If you would handle an update of a state in your rules, you should change the trigger of your rule.
If you want to act on the received command -- perhaps because you want to post an item state update, you can do it, too.

[Josar]

So let me reformulate my statement, IMHO, if there is an state change this schould be handled before the rule is called. So when the rule is called the changed state can be used. But this is solved by the receivedCommand which is more overhead to grasp.

So basically there should be a sort sequence in which handler are worked off, or a significants flag number to sort them.

And so the updateState handler could be invoked before the call the rule handler.

[sjsf]

[rkoshak]

I know this is closed and probably will not be addressed, but I agree with Josar.

For the average user who is not fully versed in the underlying architecture on how a command is processed, the natural assumption is when the Rule triggers on an Item MyItem received command or Item MyItem received update, if I call MyItem.state in the Rule I will get the state that caused the Rule to trigger. Furthermore, I would expect MyItem.state == receivedCommand to always return true (if that is the only trigger for the Rule.

I've not encountered anything in the docs or my helping people on the openHAB forums to make me think it would be otherwise. The natural assumption is that all my Items will reflect their commanded states when the Rule is triggered.

[kaikreuzer]

@rkoshak This is a pretty nasty misconception of the fundamental principles then that should indeed be better addressed in the documentation.

I actually documented it in 2010 for openHAB1 and also always mentioned the concepts of command vs. state events right in the beginning of any presentation/tutorial/etc. that I did.

[rkoshak]

Well, the English presentation requires creating an account with Element 14 to access. Something that not everyone will have (I used to but it is not letting me get into my account) so I can't comment on the presentation. I remember watching it a long long time ago but I don't remember getting this information from it. I'm not saying it isn't there, just that I don't remember or failed to recognize the importance of it at the time.

I just spent a good deal of time reviewing the wiki and as written I just don't see how someone who isn't a developer on OH 1 would necessarily conclude that they can't rely on the Item Registry being updated yet when a received command Rule is triggered.

When I move on to the OH 2 docs I find nothing at all that states or implies that if I use a received command trigger we cannot guarantee that MyItem.state == receivedCommand.

So I clearly agree this needs to be addressed in the docs.

So a really big question becomes, where should this be addressed in the docs? Should be documented in the ESH docs here I'm not sure where it belongs, perhaps in a new Event Bus page under Concepts, or should it be documented as part of the Rules page over at openhab2-docs? Or despite DRY should it be in both places?

Personally, if I were to look for something like this in the docs I would look in the Rules. Plus, based on the questions on the OH forum I wonder how many people ever look at the Concepts pages. :-(