In OH 3 there are several ways you could deal with this, including disabling the rule. In 2.5.9, far fewer options are available.
Since the rule is triggered by a change, I don’t think that’s a problem here. I’m also not certain that newState existed back in 2.5.9. That’s a nearly two year old release.
I’m pretty sure the follow profile at that time had a pretty nasty bug but the big problem with follow is it’s one way. It will command one Channel with changes to the other, but not go the other way.
@Memes11, assuming upgrading to a more recent version isn’t an option (you should at least move to OH 2.5.12 since everything before that point is basically gone when bintray shut down), you will have to make this a lot more complicated.
Presumably you’ve set up Switch1_power1 and Switch2_power1 are configured to subscribe to some MQTT topic (the same topic?) to get its state.
Why don’t you configure the Item to publish as well as subscribe? Then you can just command the Item and do away with the scripts.
If the same topic is subscribed and you publish to to control this Item, you are out of luck. You pretty much can’t get there from here except by doing some brittle timing based tricks like @Matze0211 suggests. The problem is you can never distinguish between a state change caused by openHAB or caused by some other cause.
The usual way to solve problems like these (and there are dozens of threads on this forum that discuss it) ultimately revolve around putting a break on the looping. If the device is already in the state desired, do not command it again. See the following for an example