(burglar) Alarm systems

The only thing that's essential is arm/disarm. That's all my first design had.

NT

The user interface of a key operated switch is hard to beat and understood instantly. Insert key, turn to ARM, withdraw key. etc. One LED annunicator per function is also easier on users than terse messages shoe-horned into a small display. Menu navigation is also hard to get right.

Some codes require that it should not be possible for someone outside the protected area to determine whether the alarm is set ot not.

piglet

Color touch-LCD and camera to take picture of the person in front of it? That allows user interface customization as the need arises, and arm/disarm potentially without having to enter codes.

red light on = door open green light on = alarm disarmed all lights off = alarm armed green light flash = alarm on exit delay

a button: press to set, press to reset a beeper to sound for 30 seconds upon entry during entry delay before the real horn goes off

the controller is in a hidden location

m

When I installed alarms 40 years ago, the typical user interface was a key switch (the round type used in soda machines) with three positions and a small number of LEDs (I can't remember if it was two LEDs or 1 with two colors, this *was* 40 years ago and I don't recall if they had two color LEDs). The switch was OFF, TEST and ARM. The test position was needed to see if the alarm could be set or if any of the sensors were presently tripped. This could be simpler with today's systems containing an MCU by just having OFF and ARM. The ARM position would do a test and if anything was open would not ARM, rather indicate a problem with an LED and annunciator. If everything was ok, a timer would allow you to leave the building before arming the system.

--

Rick C

Biometric interfaces aren't particularly reliable. E.g., while you can recognize faces, you typically also have to recognize that the "face" you are seeing is actually a living organism (and not a photo). This can be done by noting animation in the face (blinks, twitches around the mouth, etc.).

More typically, it is done by augmenting one biometric with another (and/or other authentication channel, entirely).

E.g., I engage the "visitor" in a conversation and characterize the voice sample to use as a second biometric channel. The identified face must agree with identified voice.

Then, I examine the "expected replies" to the queries that are issued. They're designed to not be easily predicted to confound real-time spoofing. (You would have to design an electronic agent that could figure out what the person you're impersonating is being asked and automatically play back the appropriate response -- assuming you'd managed to capture the entire set of potential responses that might be required; trying to manually playback individual RECORDED voice samples would be noticeably too slow!).

[For the *normal* "authorized users", the process is more reliable and less imposing]

But, my goal, here, is to know what sort of user interface would be *minimally* sufficient to interact with the user -- as a BACKUP to the more elaborate interfaces (that rely on far more kit being operational).

[E.g., I could implement a WiFi interface and require the user to use a WiFi-enabled phone to talk to the system. Or, place a phone call to it and interact with the voice menus. Etc. But, those add other complexities and risks to the design. You might not know, /a priori/ that the alarm system has degraded to fall-back mode until you open the door -- thereby starting the alarm process!]

As I stated in my OP, I think a "user" needs to be able to issue two commands/events: ARM and DISARM. Additionally, the system must be able to convey its "general state" back to the user: IDLE, ARMING, ARMED, TRIPPING, TRIPPED (in logical progression).

I can't see a need for additional "command events" -- nor the need for additional "status displays" (given that this is just a fall-back interface... not intended to be relied upon for regular use).

Likewise, I can't see how to handle LESS than this and still be able to address an unconstrained set of deployment scenarios.

E.g., growing up, we had an electrician friend wire up a crude alarm that was little more than a switch embedded in the door jamb that pulled in the coil of a relay. One set of contacts on the relay held the relay latched while the other set powered a

110VAC klaxon (rescued from a local firehouse) located in the attic gable end vent. The "user interface" consisted of a toggle switch mounted in the garage: when UP, the transformer feeding the relay coil current was powered; when DOWN, the transformer was off. So, ARM/DISARM was a STATE, not a set of events. And, the system's state was determined by examining the position of the toggle switch (IDLE vs. ARMED/TRIPPED) and listening to hear if the klaxon was sounding (which differentiated "ARMED" from "TRIPPED").

The ARMING and TRIPPING transient states were not present. If the door was open (i.e., if the house was "insecure") when you armed the alarm, it *immediately* advanced to the TRIPPED state: "Hmmm... door must not be closed properly. Try again..."

If the *garage* door was closed when you came home (e.g., from school), an ARMED condition left you with no choice but to TRIP the alarm (by entering the house), opening the garage door (with the opener's remote) and then running inside to silence the TRIPPED alarm (as the relay was latching, closing the door to the house wouldn't "reset" the alarm)

As stated elsewhere, I've already got the other aspects of the "alarm system" handled. What I need is to figure out how "trivial" I can make the "fall back" interface so I can make it as unobtrusive and robust as possible.

Arm/disarm:

Fingerprint scanner Iris scanner Facial recognition

Programming done by smartphone

Cheers

Klaus

All too complicated for a fall-back interface.

And, more tedious than necessary for a "rich" interface.

E.g., when either myself or my SWMBO enter the house currently, the alarm disarms itself AND the door unlocks itself, automatically; our stride isn't broken along the way!

I'll leave you to sort out how to do it (there are several different ways with different costs/complexities) :>

I think you may have it backwards. You want the normal method to be as simple as possible, and the rarely used backup procedure (also known as back door) to be as complexicated as possible.

Minimally simple would be a bank vault style time lock. That means no user interaction. At 7:30AM, the alarm would automagically disable itself for the duration of the work day, and re-enable at 5:30PM. Program the normal schedule into the alarm system with a computer, smartphone, etc. Exceptions, such as overtime and working on weekends can be handled by whatever complicated procedure is deemed useful, because it's not used very often.

For home use, some kind keyless entry similar to automobiles. A wireless device with a simple time based rolling code would be adequate. If the home owner has the device in their possession, the alarm is disabled when they approach the house, and enabled a few minutes after they leave. If they forget or lose the card, the backup procedure can be as complicated as you might want, because presumably, it's not used very often.

Thank you for disclosing your goal. However, I'm curious. What problem with the existing burglar alarm technology are you trying to solve? Is the existing system too expensive, error prone, user hostile, complicate, inadequate, or does not offer patent protection? The keypad style of entry control has had about 50 years of experience in order to shake out the bugs. If you invent a new entry paradigm, you get to climb the learning curve again.

--
Jeff Liebermann     jeffl@cruzio.com 
150 Felker St #D    http://www.LearnByDestroying.com 
Santa Cruz CA 95060 http://802.11junk.com 
Skype: JeffLiebermann     AE6KS    831-336-2558

And thus not easily remembered because of missing refresh of the dynamic memory in the meatware.

--
Reinhardt