Rule processing?

[WayneW]

I just wrote a pair of rules that seem to be interfering with each other:

Whenever zoneX becomes not secure
and OutY is on
then turn OutY off

Whenever zoneX becomes not secure
and OutY is off
then turn OutY on for 15 minutes

In testing, I can turn OutY on, but not off. I believe that the second rule is firing when I don't really intend it too and is therefore turning OutY right back on after I turn it off.

What is the cleanest way to debounce this and/or prevent both rules from firing in the same pass?

 

[Guy Lavoie]

If the "and OutY is on/off" statements are testing the hypothetical status of the output (which it what it seems to be doing) then you have a classic case of a self triggering toggle which you cannot logically avoid. In the Ocelot, a "Skip to" statement would be used to skip the second rule if the first one fired. I know that Spanky mentioned that he would like to add a similar type of statement to end processing for a particular event. Until then, you would need to use a flag to have it skip thge second rule, and then a statement to reset the flag. Something like this (pseudo code):

Whenever zoneX becomes not secure
and OutY is on
then turn OutY off
then set counter 1 to 1

Whenever zoneX becomes not secure
and OutY is off
and counter 1 is = 0
then turn OutY on for 15 minutes

Whenever zoneX becomes not secure
then counter 1 is = 0

 

[upstatemike]

In Stargate logic it would be something like:

If
zoneX becomes not secure
Then
......If
......OutY is on
......Then
......turn OutY off
......Else
......turn OutY on
......Set a timer for 15 minutes
......End If
End If

If
The timer expires
Then
turn OutY off
End If

 

[Sandpiper]

I believe it may work as desired if you simply swap the processing order.

 

[WayneW]

I believe it may work as desired if you simply swap the processing order.

If I swap the order, then I can turn it off, but not on. Until Elk changes something in their language or rules processing, the only way to make this work are to debounce it using a counter (like Guy showed) or a timer. I think I will use the timer method since it lets me use 1 output to debounce a number of zones.

Whenever zoneX becomes not secure
and OutY is on
and OutZ is off
then turn OutY off
then turn OutZ on for 2 seconds

Whenever zoneX becomes not secure
and OutY is off
and OutZ is off
then turn OutY on for 15 minutes
then turn OutZ on for 2 seconds

OutZ is a virtual output just used as a testing flag. OutY is real.

 

[Spanky]

Whenever zoneX becomes not secure
and OutY is on
then turn OutY off

Whenever zoneX becomes not secure
and OutY is off
then turn OutY on for 15 minutes

The Rules are processed from Rule 1 upwards to the end of Rules. In the case above when zoneX becomes not secure, all Whenever statements that use ZoneX becoming not secure is evaluated. The first Rule turns OFF OutY. When the second Rule is evaluated OutY is now off and the THEN statement also fires.

I am considering adding an EXIT processing statement to jump out of the Rule processing for an event if you do not want to evaluate any further Rules.

 

[electron]

That would be great!

 

[WayneW]

here we go squeeking again....

 

[Guy Lavoie]

Yes, we discussed that possibility a few weeks ago and you had mentioned the possibility of adding that. I'd call it something like ENDEVENT or EXITEVENT for clarity (because its not the end of that written rule that we are indicating, but the end of processing this event).

Add my squeak...