How to prevent script to trigger rules?

Setup, Configuration and Use Scripts & Rules
1

Hi,

Using Openhab 2.5.9 for a while now, I am stuck with one problem.

I have a setup with 2 switches on MQTT for the same light.

a set of rules such as :

rule Light_by_Switch1
	when
		Item Switch1_power1 changed 
	then
		if(Switch1_power1.state==ON) {
                callScript("switch_on_light")				
        } else {
		        callScript("switch_off_light")
		}		
end

rule Light_by_Switch2
	when
		Item Switch2_power1 changed 
	then
		if(Switch2_power1.state==ON) {
                callScript("switch_on_light")				
        } else {
		        callScript("switch_off_light")
		}		
end

and 2 scripts
switch_on_light

publish("broker", "cmnd/switch1/power1", "ON")
publish("broker", "cmnd/switch2/power1", "ON")

switch_off_light

publish("broker", "cmnd/switch1/power1", "OFF")
publish("broker", "cmnd/switch2/power1", "OFF")

My problem : sometimes, there is a timing issue (at least, I guess it is a timing issue), I switch on Switch1, then, it keeps on toggling On and Off at fast speed for couple of seconds.

Is there a way, in my script, to start with something like “Rules active= false” and close the script with a “Rules active=true”. or did I miss something in my rules/scripts?

Thanks

1 Like
2

As item state change is happening asynchronous to rules, I would avoid using item.state within the if condition, but would use the newState implicit variable as a quick fix.

In addition you could introduce another switch item that is on while any of your rule is running to prevent multiple executions of the same rule.

However I would more question why you need to have 2 switch items for the same light?

Shouldn’t you have 1 switch item for the light itself and 2 switch items for 2 physical switches?
Maybe use a follow profile to keep both switch items in sync

3

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