This idea screams of race conditions. Remember, postUpdate isn’t processed in an instant. And it’s processed in the background. It’s very much possible that you could press the next button before the Item was cleared or when you check the state of the Item it will be different from what is expected.
So, given this is OH 3 it’s important to understand how rules are run. Unlike in OH 2 when a rule runs as soon as triggered, even if another copy of that rule is already running, in OH 3 only one copy of a given rule can run at a time. The remaining triggers will queue up and process in order. So why not rely on that and you can eliminate the need to clear the Item’s state in the first place.
First of all, don’t use the Item’s state in the rule. Even with a changed or received update trigger, the Item may not remain in the same state by the time the rule runs. Instead use
newState for changed or received update triggered rules to see the state that actually triggered the rule. By the time the rule runs, the Item might be in some different state. For received command triggered rules, use
Secondly, since you probably want to allow the same digit twice or more in a row, change the trigger to
received command. All interactions made from the UI come to the Item as a Command.
Finally, configure the Item with
autoupdate = false. That will prevent the Item from actually changing to the new digit that it received as a command, eliminating the need to clear the Item at all.
Therefore, because each of the commands are processed in order and you know for sure what the digit was that triggered the rule through
receivedCommand there should be no need to clear the Item at all. But if for some reason you do want the Item’s state cleared, turning off autoupdate will prevent the Item from change state in response to the commands so there is nothing to clear.
This is why on the other thread I said this smells of the XY Problem. You’ve already predetermined how you think you need to ultimately reach your goal. But there is a better way that completely side steps the symptoms caused by the predetermined solution.
So to summarize:
- turn off autoupdate on the Item
received command as the rule trigger
receivedCommand inside the rule instead of