You can put constraints on your item changed trigger (see the event triggers section of the rules doc). So the simplest solution, depending on whether or not the item ever goes to any other intermediate states, might be:
Item TestItem changed from ""
Then the rule won’t run if the item goes from pin to “” but will run with it goes from “” to pin code.
Not with that rule, it didn’t.
Because it triggers on change, you will get a double trigger. Once when it changes to XX, and again when it changes to empty “”. But only twice,it’s harmless.
Sometimes people use update and changed triggers interchangeably, but they are most definitely not the same.
But yes,changed from “” is an excellent trigger choice. Just remember to be sure the Item is set to “” at system startup.
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 receivedCommand.
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
use received command as the rule trigger
use receivedCommand inside the rule instead of TestItem.state
Thanks Justin. I think this will be what I need… Will test asap. Different view always helps.
This was about a year ago when I was just starting with OH2.5. My trigger might have been different, but the way I used it then definitely caused a loop. Had to stop OH to recover. That was why I eventually implemented a switch to trigger the rule.
Thanks Rich. Appreciate the detailed response.
I am going to try out Justin’s suggestion above in the hope that this will help.
The Keypad widget handles all of the input handling, so only sends the completed PIN to the Item - which simplifies things a bit I think?
My rule doesn’t do much with the actual PIN other than run the ACTION.
I will have to familiarize myself more with the complexities you mention though.