Until now in a rule I use triggeringItem.state insted of the item.state itself to detect the current state of the triggering item. I read somewhere here, that this is more relyable becasue the persitance lack is not there. But now I see, that it causes the same problem as using the item itself
rule "swTerrassenlichtStatus Änderung"
Item swTerrassenlichtStatus received command
logInfo("Logger","triggeringItem.state:" + triggeringItem.state.toString)
logInfo("Logger","receivedCommand: " + receivedCommand.toString)
If I use this without the sleep, receivedCommand is correct, but triggeringItem.state not. For me this means I must add sleep and then no need to use triggeringItem, because I need the same sleep here to let the persistance do his job and give me the right state of the item.
Am I doing something wrong?
No your are not.
The state of the item is updated after the item received a command. It can take a few millisecond by that time your rule is already running.
As your rule trigger is
received command you should use the implicit variable
receivedCommand in this case. The state of the item will be updated later as normal.
You can observe this behaviour in the log where an item receives a command and the states updates in the next line in the log.
Yes, you are right.
on trigger “changed” or “received update”
logInfo(“Logger”,“triggeringItem.state:” + triggeringItem.state.toString)
is working well
on “received command”
logInfo(“Logger”,"receivedCommand: " + receivedCommand.toString)
But in both cases I do not need sleep. Very good. Thanks.
Good. This an important distinction and you must be careful when choosing the trigger for your rules depending on what the rule does.
Please mark the thread as solved