Zipato Security System Improvements

Alberto Macias shared this idea 3 years ago
Under Consideration

Ok I will start with the fact that the zipato security

alarms are pretty neat. I think they would be awesome with a few improvements.

I got away with most of the following requests using the rules functionallity.

My Zipato alarm system is based on Zipabox, Fibaro Door/Window Sensors, Zipato

Quad Sensors, Fibaro Motion Sensors, Zipato Smoke detector, Zipato Indoor Siren

and Yale Door Locks.


1. Audible / Silent / Disabled Partition Configuration - I have found

that "audible" and "disabled configuration works as intended

but, the Silent Configuration still makes the siren sound. I had to set my

tamper alarm as "disabled" because silent" setting still trips

the siren.


2. Automatic Reports - Even though the automatic reports do

work, I think the fact that they report every single event is expensive if you

configure SMS and/or Voice, don't get me wrong, price for SMS and voice call

are fair but for example; if once sensor is being tampered with, it will send a

LOT of messages for the same sensor in a very short period of time. I think

there could be an improvement sending repetitive events for the same sensor in

a short period of time as a single report.


3. Entry/Exit Warning Sounds – Most security systems can be

configured to give you an audible warning (beeps) while the Entry/Exit time

period is passing by. I wanted my system to give me a warning (beeps) while the

entry time is passing by and then, if not disarmed, to sound the siren with the

emergency sound, this cannot be done using the alarm configuration. If you

configure the entry or exit delay, siren is silent (off), and there is no way

you can use a rule to trigger the “Beeps” in the siren since the alarm system

is still not tripped, until this time is expired. If you remove the entry/exit

delay, then the siren sounds the “last used sound” for the configured time

immediately.


It would be very nice if we could configure a sound for

entry/exit delays, such as beeps, to be sound while the entry/exit delay

configuration expires and also to configure and emergency sound if security

system is tripped, different sound for fire/smoke detection, etc… That way no

rule like the one attached is required, only configuration.


4. Notification in case the system was not successfully armed

(quick armed) or disarmed, very useful in case partition isn’t ready and

someone attempted to arm the system.


5. Ability to know if a system is armed home or away in

rules.


What do you think?

Comments (6)

photo
1

No more ideas or feedback?

photo
1

+1 for that

photo
1

Thanks for this summary.

About point 3: Workaround: A rule when door opens/motion sensor senses motion and when alarm is armed can be configured to take actions ahead of the tripped event. Less practical as this must be done for all sensors used as alarm zones. I think this is where grouping sensors could make things easier, but I have read this feature is not working well so I haven't yet tried. I use this to beep my zipato indoor siren to remind me that the alarm is armed when I open front door.

About point 4: any rules base on when alarm armed will not be triggered when arming fails: I have a rule that beep my zipato indoor siren when it is armed: no sound = arming failed. I know I have to wait a few seconds and retry.

photo
1

Olivier,


3&4. Yes, that was my workaround, I think this should be an integrated function though, see attached.

photo
1

I am curious about rule 1, how does the 'tripped' event work? is it only triggered once on the first sensor that detects something, or it is trigered again and again when each sensor detects/redetects something (it could get messy: here a join would not do the job because the rule will be interrupted and restarted, a variable set at the start of the rule to register that the rule is in action and reset at the end could be used to avoid concurrent runs of the rule). PS: I think the 'stop' are not needed :)

photo
2

Olivier,


The way it works is, my entry delays are set to 1 sec, so as soon as you breach any partition the security system will trip and start beeping for about 30 seconds and then sound the emergency (continuous) alarm. Since I'm not using a JOIN puzzle once the alarm system is tripped it will continue its execution. In theory yes, every "tripped" event will trigger the rule... I will test again and let you know.

photo
1

Thanks for explanation and looking forward the outcome of your tests.

photo
1

I would like in return share my set of rules that accomplish a similar purpose. Basically I start a beep/flash light countdown when I arm away the alarm until I close the door, and similarly I start a similar countdown when I open the door and the alarm is armed until disarmed.


I use two variables :

  • one 'AllumageAlarme' (I'm french, it means 'ArmingStatus') that is set to '1' when I start the arming procedure and reset to '0' when I want it to stop (on closing front door)
  • one 'Armvalue' that registers if I am arming away ('1') or arming home ('0'), so the procedure is different (usually kids are sleeping when I arm home)

photo
1

Thanks for sharing Olivier. I will post my final rules once I do all the testing. I have been very busy latelly.

photo
photo
1

Another addition should be the ability to send through a message which user Disarmed / Armed the system. The only attribute available for now in messaging is status.

photo
1

I use such a rule to manage this. Unfortunately this rule works 3% of the time.fae86d20d357e40dffe6da907cf70855

photo
1

I know my suggestion will be a pain but, try to split the IF's in several rules and see if it works. I had the same issue with my doorlock, I split the IF's into a few rules and it works 100%.

photo
photo
1

Could it be that at least Zipato considers the addition of the status "Armed Home", "Armed Away", "Entry Delay" and "Exit Delay"??


Anyone from Zipato??

photo
1

Alberto,


One thought crossed my mind; haven't had a chance to test it yet, but: If you create one virtual alarm per user, and each user arm/disarm his own virtual alarm only, you can have those virtual alarms control the "master alarm"?

photo
1

I get your point. Seems much trouble just to know who disarmed the system though, shouldn't be to hard for zipato to implement this feature, the info is on the log already.

photo
2

Some news about that?

Could it be that at least Zipato considers the addition of the status "Armed Home", "Armed Away", "Entry Delay" and "Exit Delay"??


Anyone from Zipato??

photo
3

Yes, we are working on it. Entry and Exit events are already in API and we will integrate them in rule creator soon....

photo
3

Awesome!! I have spent plenty hours creating different workarounds for this. Please make it so we can configure a "warning squawk" in the virtual alarm, it would be VERY useful!

photo