text: Alarm tripped by no motion
  Zipato help center
  Zipato help centerTopicThanksGeneral
  Virtual alarm part 1 and part 2
  Alarm was disarmed but still tampered when
  Alarm send message about tripped
  Blinking with all lights when alarm is tripped
  Rules when the alarm is tripped and should take pictures
  Claus shared this thanks 9 months ago
  When I arm my alarm I get the message below. Makes me wonder if I have misconfigured something?
  TripType: INTERIOR
  Zone: OpholdsStue
  Zone UUID: a4ed2f02-9053-436b-a0bd-2733c5a575ff
  Endpoint: Bevægelse Opholdsstue
  Yea, I just started to experience the same problem. For a long time I was using for each zone setting ARM STATE the correct setting I would expect (like NO MOTION for a motion sensor). Since recently this started to become a problem as when leaving house most of my sensors (battery operated) are in the blind time (MOTION state for 3 minutes) and I was unable to arm the alarm (not on the zipatile, nor on the android app, not the keyring) as some sensors were in wrong state...Manually bypass each sensor is not a solution especially that i have set up BYPASS ALLOWED.
  So I changed the ARM STATE to ANY (which i guess you have a s well) and now - when you leave the house and arm the alarm, you have some of your sensors still in MOTION state after the exit delay finishes. Then when the sensor changes state (from MOTION to NO MOTION), it triggers the alarm.
  So currently Im unable to find the right setting as I would expect that because i have allowed BYPASS ALLOWED. I would expect this setting would tell the controller that even if my motion sensor is not in the right state, I would be able to alarm the arm as the 1st state change back to the desired setting (from MOTION to NO MOTION) the alarm will not trip.
  Currently the only workaround I can think of is to set the exit delay for a longer time than the Blind time of the sensors but this is what I will need to test today as Im facing this problem as we speak.
  Im unsure if the exit delay extension will help as some zones are follower zones (some are not even follower zones) and I need to test what will happen when a motion sensor changes state back to NO MOTION after exit delay ended.
  Unfortunately even if this will solve the main problem, it still can leave a room for one more error. If a battery operated sensor (for example door sensor) is somehow stuck in state OPEN when you close the door (this can easily happen to anyone) and still reports door open, you arm the alarm, exit delay pass. Then lets say in 1 hour the sensor wakes up and sends signal CLOSED. This will be evaluated as state change and trigger the alarm...
  I would recommend to Zipato to change the setting BYPASS ALLOWED so this option will tell the controller that the 1st state back to the desired state based on the ARM STATE will not trigger the alarm.
  let me know if the above makes sense and/or you have a different recommendation/experience.
  I noticed this problem since the beginning to me this is a "design error" on the virtual alarm from Zipato. I actually got in touch with development team and submitted a few requests to make virtual alarm an awesome device. One of the most important problems is this one.
  The way I see it, the proper solution is to add another configuration per Zone. Exising config "ARM STATE" remains, but then creating "TRIGGER STATE". This will allow us to say in case of motion sensors ARM STATE = ANY and TRIGGER STATE = MOTION. I guess if we all request it they might put more attention to it.
  https://community.zipato.com/topic/new-configuration-for-zones-configured-to-arm-state-any
  The way I have it working right now is ARM STATE = MOTION, Bypass Allowed and Remove Bypass checked. Then after you sync these changes you have to bypass all motion sensors for the first time, and then when you ARM your system bypass is removed and motion sensors active and also no further problems not being able to ARM the system (most of the times) from time to time you have to bypass the sensor again.
  Files: 2017_06_19-0017...
  Another of my topics in regards of Security System Improvements;
  https://community.zipato.com/topic/zipato-security-system-improvements
  Setting Arm state to "ANY" is generally a bad idea.
  You should set the Arm state to the one which you would like to have while arming the system. This will allow you to use option Remove bypass properly. For example, in case of Motion sensor (Arm state = NO MOTION, Bypass allowed = TRUE, Remove bypass = TRUE), if you bypass it while arming the system, system will remove this bypass once when the sensor goes to the Arm state. In case it goes back to some other state, this will trigger the alarm.
  All Follower zones are working in the same way. So to avoid Bypassing some zone too often, you can just set it as the "Follower Zone". it will be active only after it gets back to it's Arm state, and it will trigger the alarm if it changes the state afterwards.
  Thanks for the explanation, just to make sure I understood correctly, configuring a zone as "follower zone" is equivalent of having "Remove bypass = TRUE"?
  Also, what do you think about my proposal on TRIGGER STATE, it would make the system more "straight forward" in my opinion I honestly didn't understand why "remove bypass" would be an option, in my "automation integrator brain" having "Bypass Allowed" and "Remove Bypass" = TRUE is non-sense, I understand now their purpose but I think most people is wondering why they should be used together. To me, bypass option should be only used in case battery is dead or the sensor is defective.
  Yes, the Follower Zone will act like it has Remove bypass option = TRUE. This means, it will not trigger the alarm during the Exit period, and after the Exit period, it will not trigger the alarm when it goes back to Arm state. But it will trigger the alarm if it changes the state afterwards.
  The way how we did it is common with professional alarm systems. There are many "corner cases" already, and adding an additional option would complicate things even further.
  In general, setting up Zipato alarm is not very difficult, but it requires some testings and adjustments while it doesn't become tailored made for user's particular needs.
  Understood thanks. I agree, you cannot customize it to every user, however this scenario will happen to any user which uses "Interior Zones" in my opinion, basically any motion sensor and for example, your main entrance door sensor.
  Another standard function in most alarm systems is the "warning" or "beeping" tone when the system is on entry o exit delay and not tripped yet. This is not posible currently on virtual alarm and is not easy to achieve using rules.
  This "beeping" option will be soon available on Zipatile.
  Thank you, would be nice to be able to use it also on Zipabox through external siren.
  Sebastian. For 2 years I was using the alarm, where I have battery sensors. For all sensors I was using arm state (NO MOTION) and was using BYPASS ALLOWED and REMOVE BYPASS as the way I understood is that if I enable BYPASS ALLOWED and REMOVE BYPASS the system will allow me to arm the alarm WITHOUT THE NEED to manually bypass zones in wrong state. If I understood you correctly, this is the same thing you described. I dont think I need to use FOLLOWER ZONE for sensors that are not in a way to or from the Zipatile (or a keypad) and the entrance (and/or exit).
  2 weeks ago I have set up an complete system for an installer. After a couple of issues (I did not know until I raised a ticket, that if a new motion sensor does not have any history after including, it will force the alarm to not allow to be ready, until at least once the sensor reports state) i got the alarm ready and tested so it was ready for the installer to go to customer and install.
  Then the issue stated and I was going crazy (together with the installer) spending a couple of hours over the phone trying different things because of a bug 3-4 sensors was in the alarm as not ready making it unable to be armed. I thought I dont believe it and only after changing all 20 sensors ARM STATE to ANY I was finally able to arm the system.
  The same issue appeared with my alarm a couple of days later as well. I have zones which are entry/exit zones, I have 2-3 sensors which are follower zones and I also have 3-4 sensors which are not entry/exit and not follower zones. Again I was forced to change the arm state to ANY as otherwise I always had a zone not ready.
  Now what? I dont want to use ARM STATE as ANY, but Im forced to do as otherwise I might have this issue.
  Sebastian, can you tell me how am I supposed to set up my alarm? A sensor should be ARM STATE no motion, but then perhaps if the bug does not let me arm alarm (despite Bypass on and remove bypass also).
  See attached printscreen. The zone currently has arm state ANY, allow bypass and remove bypass on. This zone is not a follower zone because it is a remote room that is not in the way between entrance and exit, but as you can see it can happen that zone was in motion a couple of minutes before arming and 1 minute after arming done, it changed to no motion that triggered the alarm. I don't want make all my sensors as follower zones, that would not make sense, because intruder can come in via front door and system will let intruder to go to any room without immediate trigger.
  As i say, for customer currently all zones are arm state any as after testing at installation system somehow stopped allowing to arm alarm in any zone was in wrong state despite bypass allowed and remove bypass on.
  Files: alarm how to se...
  Just changed ARM STATE no motion for all my sensors that are not in follower zone, entry or exit zone. Sync and refresh. On the alarm everything seems to be OK, however system does not let me alarm. Why?
  Files: failed to arm a...
  Now I have changed all zones which are technically not follower zones to follower zones with ARM STATE ANY (then synch) and as you would expect I was able to arm the alarm.
  But for me this is technically not right. Now intruder if enters via the correct entry, can go anywhere in house and the entry delay will count.