The underlying model of openHAB -
An Item is our model of some external device - let’s say, a roller blind.
You might send it a command from a rule or UI. Let’s say you command “UP”.
The command passes through bindings and communication methods to the device.
The device actions the command and passes it’s new status back through comms and binding etc.
Eventually that results in the Item state being updated, say to “80%”.
Maybe after a while longer it will send again, “90%”.
In order to work with real world devices, two key issues arise there -
We never expect an immediate response to a command.
Item state value has no direct connection to last command value.
The model also has to deal with devices that never send any status at all - so there is a mechanism to emulate the usual path, called “autoupdate” (it guesses a likely outcome).
Just like a real binding and device, it makes status updates in response to commands. So there’s still a turnaround delay.
That’s a useful feature for “dummy” Items that aren’t associated with any real device, but Items are Items and play by the same rules.
Looking at your rule, it’s a perfect example of why it works this way. You send a command to a rollershutter. Of course, at the moment you send it the roller is exactly where it was before you sent the command. It takes time to move to a new position.
You have choices to make about what you are interested in for your rules.
If you want to know the command, you can trigger rules from command and use the explicit variable in the rule to find out what the command was.
If you’re interested in the state after the command is actioned, you can trigger your rule from changed or updated to get the new state (and totally ignore commands if you like).