This is a confusing choice. Can a sensor be tripped if it isn’t armed?
Secondly, what is the reason for the choice “Tripped?” in the event dialogue under the sensor choices?
Thank you
From a sensor perspective there is no such thing as “armed”. It’s just a convenience factor provided by Vera and nothing more than a flag. Thus from a Vera perspective you can “arm” a sensor so it only reports tripped notification when armed. Again - down to the hardware, a sensor always report when it’s tripped, Vera just filters this.
Thus, you can choose to report sensor being tripped only when it’s armed, or always. Hence, “armed sensor is tripped” vs. “a sensor is tripped”
As of “Tripped?” Yes/No question - sensor sends 2 messages: when it detects motion (tripped=yes) and when there was no motion for some idle time (“untripped”, or tripped=no)
I’m having a hard time wrapping my head around this. Can you expand a little on this?
This comes up frequently. We seriously need to come up with better terminology for these concepts. denix, you seem to understand it well – can you suggest some words we could use to name these? Or is there a better user interface or graphical layout that would make it more intuitive for users? It’s clear that much, if not all, of Vera’s UI was designed by programmers. It might be okay for now, but it sure won’t succeed with average consumers.
Many of you in this forum have IT backgrounds – any suggestions?
I’ll take a stab at this, although I’m no IT pro, or anything like that.
When a sensor beam is interrupted, from a sensor, it’s ‘tripped’. The little red light comes on, indicating movement.
However, Vera won’t do anything, or recognize it to activate anything else, unless you ‘arm’ it, through Vera. So, if you want something to happen based on that sensor picking up movement, you would need to ‘arm’ (tell vera to watch it).
Trip = what the sensor does, no matter ‘armed’ or not.
Arm=tell Vera to watch it, and do something…
Unarmed = Vera doesn’t do anything based on the sensor detecting movement.
The word ‘tripped’ comes mainly from old military technology, where they used very thin wires for landmines, (also called tripmines) and other things that were used as alarms. When someone stepped on/kicked/disturbed that wire, it made something act on that. These wires were stretched out barely above the ground, a few inches, and each end hoooked to something. So, if they were like steel cable, and didn’t move, you would actually trip on them. 
Hope this helps, in layman terms
One more stab at it. The motion sensor sends a signal when it first detects motion. That’s signal number one. You then spend a few minutes doing something in range of the sensor but the sensor doesn’t send anymore signals just yet. When you leave the area, it will watch for LACK of movement for some time period, usually about 2 minutes, and THEN it will send another signal.
The first signal is “Tripped = 1” the second is “Tripped = 0”. You can do something to respond to either or both signals. These signals get sent regardless of whether the sensor is armed or not.
As denix mentioned above, the ARMED or unARMED modes are purely a convenience. Think of it as allowing the sensor to be dual purposed. You can turn on a light if a sensor is tripped but send an alert if the sensor is ARMED and tripped.
If your in “At Home” mode, you walk into the den and on comes the light. In “Away” mode, motion in the den turns on the light and sends an alert to your phone.
Hope this helps, it IS rather confusing at first.
Thanks everyone for your help.
It’s a lot clearer.
I would like to ask whether a battery powered sensor that only wakes say every four hours can be fine tuned to be armed or bypassed at very specific times.
That is, if I ask that it be bypassed right at sunrise, but it may not be awake for three more hours to report to vera, whether it actually changes its behavior at sunrise, or only when it’s awake and talking to vera again.
Thanks!
[quote=“CMRancho, post:4, topic:165025”]This comes up frequently. We seriously need to come up with better terminology for these concepts. denix, you seem to understand it well – can you suggest some words we could use to name these? Or is there a better user interface or graphical layout that would make it more intuitive for users? It’s clear that much, if not all, of Vera’s UI was designed by programmers. It might be okay for now, but it sure won’t succeed with average consumers.
Many of you in this forum have IT backgrounds – any suggestions?[/quote]
What about “Instruct Vera to act?”
Only vera knows whether a sensor is armed or bypassed, thats why the sensor can be changed at any time… the sensor doesnt know any different and always reports its status, but vera changes her reaction based on whether you tell her the sensor should be armed or bypassed at any specific time.
In short, Arm and Bypass are simply flags in vera that result in different actions for a sensor. For example… You are home, vera “bypasses” the sensor, motion sensor detects motion and vera does nothing. You are not home, vera “arms” the sensor, motion sensor detects motion, vera sends you a notification.
The confusion is that in the Z-Wave world, there’s no concept of arming/disarming sensors. If you associate a sensor to a light, then every time the sensor trips, the light goes on. But we figured there were times when you would want a sensor to be ignored. For example, if it’s for a light, maybe you only want it to turn the light on at night, not during the day. And if it’s for security, you only want it to send you an SMS text when you’re away from home, not every time you walk past it while at home.
So if you create an event with ‘sensor is tripped’, it’s traditional Z-Wave, and will always fire when the sensor is tripped.
You can also send the command ‘arm/bypass’ to set Vera’s internal flag, and then use the event ‘armed sensor is tripped’, and the sensor will only fire the event when it’s armed. So you can arm a sensor that turns on a light with a sunset timer and bypass it in the morning, or create a ‘leave home’ scene which arms sensors used for security.