I'm at odds with the logic here. This should be no different than the old PLC ladder logic I used to use. Here is how I understood that:
Equals: If x equals 1, then masterswitch turns on (for as long as x = 1, the masterswitch turns on, on every evaluation loop, if x =1 turn on masterswitch) I would expect a continuous loop here
Becomes: if x becomes 1, then masterswitch turns on (Here, the becomes option should only test true only the first time that the state changes to on as opposed to already being 1 according to the internal memory table that the engine maintains) This way when you manually change 1 to 1, or a polling event updates a variable to 1, etc, it will never fire again until it changes to something else first.
in ffneil's rule 112 that he said fires only once, logic wise I would agree and disagree. Yes, obviously the rule is firing when Dave says it shouldn't - i've witnessed that myself. It's all in the interpretation of your method "changes value" - is a changes value simply meant to be that it gets updated, regardless of value? Or is "changes value" defining a process where the stored value changes from what it is to something else? The better term may be when it "gets updated" since that implies nothing about the value itself. Then you can use "becomes" to show a transition of the value.
Sorry to pick on your rule engine Dave... I just don't think it's doing what we all think it's doing.
In ffneil's example; like my problem; we have an external device on a poll or unsolicited response updating values in the db which I still feel the engine is seeing as a change.