STOPping execution of a REPEAT block

Thank you very much Alberto, that resolved the issue!

I know this isn't an elegant solution, but it's all I've come up with so far.

Well there is no elegant way of doing this with the actual capabilities of the virtual alarms in zipato systems. Check the following topic with a discussion I started in order to try to gather a "wishlist" for zipato to work on.

https://community.zipato.com/topic/zipato-security-system-improvements

My workaround is to use two alarms instead of one, with the same sensors. First is always armed with no entry or exit delay and it is a silent alarm. Second is the main alarm which can be armed/disarmed and it's tied to my siren. What I do is, when the first one is tripped but the second one is armed (not tripped) I make my siren beep (during day) or my LED strips to glow red (night) in order to advice the user that the security has been breached and needs to disarm the system or the siren will sound. I can post pictures of my rules if you want, let me know.

Hi Alberto,

Please see my rule. it seems to work fine but do you also recomment uding a join statement?

Attila,

In your case the execution of the rule seems much faster, two beeps to arm, one beep to disarm. I think its almost imposible that the alarm changes status before either event finishes so I think in this case it doesnt really matter. You could still add the JOIN but I think the result would be the same. I started playing with this because I wanted my siren to beep for a minute if the system is breached but not tripped (during the entry delay time) and started having issues like Tim, after a lot of testing I think I got it.

Alberto,

Yes, I would like to see your rules that do this.

Thanks!

Tim,

No problem, but first I have to explain to you my setup. I have created two virtual alarms with the same zones (Sensors), the first called "Security Alarm" which is my real alarm system, it is tied to my siren and it has configured entry and exit delays. Second virtual alarm called "Security Warning" and it is a silent alarm with no entry or exit delay. The way it works is;

1. I have created rules that "mimic" SECURITY ALARM to SECURITY WARNING (Disarm, Arm Home/Away). Http puzzle I use it to change a value on a virtual meter that I use in Zipatile to also mimic this status (since no cluster stil).

2. I use rules to make siren beep if SECURITY WARNING is breached but SECURITY ALARM is ARMED (Not tripped), I had to implement a rule such as yours in order to stop the beeping if the ALARM is disarmed let's say at second 30. Security Alarm Silent is a virtual switch that I trigger ON/OFF in another rule using SCHEDULERS so if it is late the beeping is replaced by glowing my LED strips green for disarmed and red for armed.

3. I used rules to make siren sound emergency sound if SECURITY ALARM is tripped. See attached and let me know any question or comment.

That is odd. Did you put the JOIN between the WHEN and the first IF?

In theory the REFRESH ALL puzzle is not required, yes that block will make your controller to solicit status to your devices, doing it very often may decrease battery life on your devices on the long run. With the JOIN statement the condition within the first IF would stop executing if the test condition/variable changes, therefore stoping the beeping or whatever is inside the REPEAT block, although I have noticed for some devices REFRESH ALL does improve the status update (not doing it within a repeat).

I agree JOIN is a fully working solution. Yet I want to precise what I understand from using RefreshAll: to me it does not make the controler solicit the status to devices (why should it do it since when a devices changes state this event is automatically sent to the controler) but it does make the rule reload the state of the devices as if the rule is using the state of all devices as they where when the rule was triggered. This post is an example of what I understand: https://community.zipato.com/topic/when-do-we-need-to-use-the-resfresh-all-#comment-14016. According to this theory a repeat block with en embedded if will never see any change of device status if not using REFRESHALL.

Attila, I mean what I said a few post above: You need to use Refresh All if you want to detect a change of state of a device during the execution of a rule. When a rule is triggered, it is running on a copy of all devices status. Hence RefreshAll to curcumvent this.

I have created a very goog example for this:

This rule doesn't work: I don't get the message though the status of the switch has been changed by the rule itself.

This rule works: I get the message because of RefreshAll after the status is chnaged and before the status is checked.