Rules fires before item actually is updated using sendcommand()

Setup, Configuration and Use Scripts & Rules
1

Dear all,

I need some advice on the following:
I have an items called “abcdef”
If I send e.g.

abcdef.sendCommand(1)

and have a rule

rule "xyz" when
	Item abcdef received command then
....

then this rule actually has a chance to fire before the state of the item (i.e. abcdef.state) is updated. How do I make sure the rule starts after the actual item was updated?

I was thinking of using “changed” instead of “received command” but then the rule doesnt fire if the state didnt actually change. I was the rule to fire even if the state gets updated with the same value, e.g. if i do sendcommand(1) while it was already 1.

Thank you,

Ramon

2

There is no way to ensure this. Why do you need it?

3

Yes, exactly as designed.
Command → instruction, “do something”
state → condition, “its like this”.

Real device example for rollerblind
Command → “up”
state → “exactly where it was a millisecond ago”
then → “now at 50%”
then → “now at 40%” etc…
State is not directly related to command, commands may or may not produce a state change.

Maybe you are interested in state update? (which includes update-to-same-value)

1 Like
4

Use a received update or changed trigger instead.

Then received update is the trigger you want.

A command does not imply a state change. One can issue a command to a device that’s offline.

If not configured with autoupdate, the Item will never change state. Some Items can receive commands that have nothing to do with its state. For example, INCREASE to a Dimmer Item.

So if you care about the state of the Item you have to use a trigger that happens on the state change.

5

thx all for your replies. I understand a bit better what the thinking behind it is.

But let me explain my setup a bit more, I actaully use the item to track the state of multiple others (sort of like a scene), in my case some rollerblinds, i.e. at sundown i have a rule to move then all down to specific locations, at sun rise another one to move them to other locations, and a state for completely up or down. Then have a rule on that item to move them to the actual location. In that way it will also update when somebody manually changes the item via a button on the UI.

But anyway the update on the item itself should be more or less instant as it is just a sort of dummy, but I guess not instant enough i.e. the rule fires just before the update.

But I think “received update” is indeed the right way to go.

Maybe one last question is there a way to query what command was send?

Thanks,

Ramon

6

Only if you trigger from a command event

receibedCommand

1 Like
7

Thx!

8

Thank you very much! That’s one reason for a rule of mine that got unreliable after update from 2.5 to 3.1

9

Update from my side.
Even with received update the rule fire sometimes before the state was updated. Not sure why But I reverted back to received command and now use the local variable receivedCommand to check what was actually send and switch on that instead of xyz.state.
This seems to work

1 Like
10

Sorry for the late reply, I only saw this today: You know that received update and received command are different semantically? See Actions | openHAB for explanation.

If a received update rule fires before state was updated, then it would be a bug and needs a bug report, as it isn’t mentioned in documentation that this can happen (and there doesn’t seem to be a receivedUpdate item)