It’s completely predictable that this will fail, crops up regularly. Item states may or may not respond in some way to Item commands eventually, but
any response is totally asynchronous. This is a fundamental openHAB design feature, not a flaw.
Usually requires a bit of thinking about how to deal; if a rule is reliant on Item state, maybe trigger on state not command.
The most important cycle in openHAB -
a) Item gets command (from rule or UI)
b) Item passes command to binding
c) binding passes to device
Note that Item state is not affected so far
d) binding receives status from device
e) binding/channel updates Item state
It sounds like your original rule was operating at the (b) point in the cycle, where reading the Item’s state is likely to get you the “old” state before the command takes effect.
It’s just luck though, all the timing of rule execution is running in parallel.
There is also openHAB’s autoupdate feature in the mix here. If your Item is linked to a real device, autoupdate will be having a speed-up effect. If your Item is freestanding, you may be reliant on autoupdate for any state change at all.
This is probably important in your rule design.