Contemplating opensource alarm system

[jpyeron]

Kinda frustrated with the insecure, featureless, overpriced choices in the industry.

Does anyone have useful thought to persuade me towards or away from this endeavor?

Goals:

1. Secure
2. Extensible with integration points
3. compliance / certifiable (e.g. UL - aware of $$$)

[pqass]

Wired?  Wireless?
Type of sensors?  eg. contacts, shock, PIR, smoke detector, ...
Type of output? eg. horn, strobe, internet connectivity, ...
Remote admin/monitoring?
Integration with existing commercial sensors/output devices?

It can be as simple as a current loop (zone) with end-of-line resistor, contacts, cat5 wire, bix block, Arduino, power transistor, horn, keyswitch, low-voltage PS.

[jpyeron]

Wired? 

Yes - primary use case.

Wireless?

Not one of my goals - but there is no reason to exclude it.

Type of sensors?  eg. contacts, shock, PIR, smoke detector, ...
Type of output? eg. horn, strobe, internet connectivity, ...

Existing (UL listed) sensors, this is more of the control panel, communications, keypads, etc.

Remote admin/monitoring?
Integration with existing commercial sensors/output devices?

remote admin - this is a big area for discussion. Most panels support remote programming, but some installation disable it.

remote monitoring is a must - by UL listed central stations (note: I work for a company that provides such services)

It can be as simple as a current loop (zone) with end-of-line resistor, contacts, cat5 wire, bix block, Arduino, power transistor, horn, keyswitch, low-voltage PS.

Any capabilities that are not (capable of being) supervised will be a non-starter. The questions then lead to how complex or simple should it be.

[pqass]

Given your need for all the peripherals (sensors and output) to be commercially available, it sounds like you're really only asking about the magic box (in the central panel) that ties everything together. That is, what are its i/o capabilities?

a. # of channels: current loop sensing (for contacts, keyswitch, etc.),
b. # of channels: relay dry contacts (for horn, strobe, etc.),
c. # of channels: TTL or RS232 UART or SPI for Bluetooth, or WiFi interfaces for local admin via phone, keypad, house WiFi to access Internet,
d. Ethernet interface to access Internet via house switch,
e. # of channels: independent power supplies to light up the current loops, power for output devices if needed, and for magic box itself,
f. battery and charger

Work things backwards. Identify all the commerical perpherals that you need or eventually want.  What interfaces do they require? Is my wiring topology compatible with those interfaces, The magic box should have all those interfaces.  Is there an existing platform that has some or all of those interfaces? Can I add shields to make up for the missing functionality.

[2N3055]

As someone who worked in industry for few years, my advice is not to got down that rabbit hole.

1. Connection to sensors is easy.
2. You cannot reuse any peripherals or modules (keyboards, readers or such) from current equipment. Protocols are proprietary. No standard there. No documentation. Reverse engineering them is no fun.
3. Central station communication... Good luck with that. Dozens of protocols on outdated POTS, and some TCP/IP. Some documented some not. Lots of proprietary stuff.. Ademco, Surgard, DSC, Bosch etc.....
4. Compliance? 150k - 250k USD per product... Not only all the UL and ISO EMC, low voltage, but also all security and/or fire standards and codes..

You can throw together something that can read standard sensors with relays, with tamper supervision, arduino, horn (use commercial one), some keyboard and alphanumeric LCD. Add in  Raspbery Pi and touch screen interface, and web display status. For your own fun and use ...
More than that, no way you keep your sanity with open source based full product.
You will get certifiable long before your alarm panel...

You're seriously underestimating time and effort needed.

[jpyeron]

There's nothing wrong with starting to develop this if it is of interest for you do to so.
But if your goal is to just make a small number of systems then build vs. buy is not likely to be cost effective.
If you just want to advance the state / capabilities of the systems out there by making one more flexible or modern or whatever then great even adding a little to the status quo is still progress.

Work things backwards. Identify all the commerical perpherals that you need or eventually want.  What interfaces do they require? Is my wiring topology compatible with those interfaces, The magic box should have all those interfaces.  Is there an existing platform that has some or all of those interfaces? Can I add shields to make up for the missing functionality.

If end design does not result in a hardware design that "could be UL listed" then it is a non-starter. Just because it does not get certificated/listed (due to funding), I think it could be a benefit to the industry / state of the art.

As someone who worked in industry for few years, my advice is not to got down that rabbit hole.

1. Connection to sensors is easy.
2. You cannot reuse any peripherals or modules (keyboards, readers or such) from current equipment. Protocols are proprietary. No standard there. No documentation. Reverse engineering them is no fun.

Given your need for all the peripherals (sensors and output) to be commercially available, it sounds like you're really only asking about the magic box (in the central panel) that ties everything together. That is, what are its i/o capabilities?

Correct, not looking to re-use "magic boxes".

3. Central station communication... Good luck with that. Dozens of protocols on outdated POTS, and some TCP/IP. Some documented some not. Lots of proprietary stuff.. Ademco, Surgard, DSC, Bosch etc.....

Ademco Contact ID and several others, especially the IP based are very well documented. Albeit many aspects are covered by NDAs.

a. # of channels: current loop sensing (for contacts, keyswitch, etc.),
b. # of channels: relay dry contacts (for horn, strobe, etc.),
c. # of channels: TTL or RS232 UART or SPI for Bluetooth, or WiFi interfaces for local admin via phone, keypad, house WiFi to access Internet,
d. Ethernet interface to access Internet via house switch,
e. # of channels: independent power supplies to light up the current loops, power for output devices if needed, and for magic box itself,
f. battery and charger

The design intent would to allow scalability. Add "modules" as needed. You see this in some panels / keypads where additional zones are added on to a supervised bus.

4. Compliance? 150k - 250k USD per product... Not only all the UL and ISO EMC, low voltage, but also all security and/or fire standards and codes..

Hopes (pipe dream?) would be to demonstrate product design vaibility and partner with an existing OEM.

More than that, no way you keep your sanity with open source based full product.
You will get certifiable long before your alarm panel...

You're seriously underestimating time and effort needed.

Meh, it could be fun.

[pqass]

By "magic box" I mean that thing you're getting UL listed to glue all the commercial bits together.  The more commercial components you can buy, the less of that "magic box" you'll need to design/build, the easier/faster it will get done.

Is it a PCB sitting in a metal box in a home basement or in the wiring closet(s) of a 10 story building?
Scale matters to the design and you haven't quantified that.  It could be multiple custom controllers scattered over multiple floors with local area communcations to a central controller or a Beaglebone with protocol converts (current loop to SPI) and relay banks on a DIN rail.

[Bassman59]

Kinda frustrated with the insecure, featureless, overpriced choices in the industry.

The home-security-alarm industry sells a service. Often the hardware is given to the customer in exchange for signing a contract of some non-trivial term.

The money's in the monitoring service.

[Leiothrix]

Insecure?  Featureless?

Alarm panels are made to attempt to be everything to everyone, you just need to program them properly to do what you want.

Overpriced perhaps, but that's individual.

By what metric are you using to judge the first two?  How will your version be better?  And how will your version be cheaper, especially with the time invested?

[jpyeron]

By what metric are you using to judge the first two?  How will your version be better?  And how will your version be cheaper, especially with the time invested?

Need to reflect on that.

[50ShadesOfDirt]

Are you after a system that you can assemble yourself, lego-like? No black box for a "controller", no proprietary pieces, standard kinds of wiring, etc? Standards (of some kind) throughout?

Sounds like: ONVIF (for cams, other sensors), ethernet wiring & ip-based (for any sensor), software (on any hardware platform) that controls everything. Solutions for relays & other specialty requirements, such that you assemble & wire your own "devices" to do something, and tie it back into security system.

I looked at this a few years ago, and at that time, it was possible to assemble an entirely open-source security system, bypassing the usual proprietary commercial vendor/suspects who only wanted to sell a black box system managed by their installers (like the home market suspects). Install your own cams from any vendor, your own door locks & access software, wire everything with ethernet cabling.

The controller software was sold by many vendors, with the usual "free piece" (controls X number of devices), then "paid piece" (controls unlimited, etc). Ran on any platform (windows, linux, etc). A few entirely open-source controller software packages (should be more these days, given Github & such).

Is this the goal? And for home use only, or commercial?

[jpyeron]

Are you after a system that you can assemble yourself, lego-like? No black box for a "controller", no proprietary pieces, standard kinds of wiring, etc? Standards (of some kind) throughout?

Standards and avoidance of proprietary pieces are a strong motivator. "Yourself" may have too much of a connotation.

Is this the goal? And for home use only, or commercial?

Seems a close summary. Both home and commercial.

Opensource hardware. Open firmware - but assuming certified (e.g. UL) firmware would possibly be closed source...

[johnboxall]

Does anyone have useful thought to persuade me towards or away from this endeavor?

Why would anyone buy an alarm system whose design and firmware is made public? The smart crooks would be all over it.

[bitwelder]

In modern security one motto is: "don't roll your own cryptography"
(because it's easy to miss the weaknesses of a newly-invented algorithm when it doesn't have a chance to be analyzed and 'peer-reviewed' in the open by others)
So, at least in terms of security, I think that making an alarm system into an open-sourced design, using proofed logical blocks, has the chance to offer a better value over propriatery 'black boxes'.

[jpyeron]

Does anyone have useful thought to persuade me towards or away from this endeavor?

Why would anyone buy an alarm system whose design and firmware is made public? The smart crooks would be all over it.

I think that is backwards. The smart crooks "hack" the non-public and keep their hacks as secrets to themselves. The smart non-crooks are blissfully unaware of the vulnerabilities.

In modern security one motto is: "don't roll your own cryptography"
(because it's easy to miss the weaknesses of a newly-invented algorithm when it doesn't have a chance to be analyzed and 'peer-reviewed' in the open by others)
So, at least in terms of security, I think that making an alarm system into an open-sourced design, using proofed logical blocks, has the chance to offer a better value over propriatery 'black boxes'.

Agreed.

[libralect]

This is my tripwire method!!! It's the cheapest, most robust motion based alarm, which uses no energy until triggered!!! it's 20 grams in total if you wanna loud invisible micro-alarm on a bike. It can be sized up to a 500dB train-horn.

The tripwire works by jamming the switch of a very loud piezo/horn using a plastic card like a plexus, and using nylon fishing line to snag the card to something you don't want displaced (a bike), or to make a tripwire in your house.

1/ Put a very loud piezo or a horn on a battery / DC circuit.
2/ make an interruptor switch with spring metal which can be jammed with a plastic card
3/ measure a length of Nylon that you can attach to a bike wheel or in a tripwire and snag the plastic card

It's that easy! when someone walks in your perimiter zone, the invisible nylon will pull the plastic card in the interruptor and the piezo/horn will sound at 100-500dB whatever you wish is.

You can even put it in the saddle of your bike, so that it beeps at 120dB if taken.

[Nominal Animal]

It can be sized up to a 500dB train-horn.

500dB? It's an exponential scale.  A shockwave peaks at 191dB in standard atmospheric pressure, where the low-pressure regions become a vacuum.  500dB involves 2¹⁰⁰ ≃ 10³⁰ times that much energy; with high-pressure peaks of 10¹⁵ atmospheres, or around 40 million times the pressure at the center of Jupiter.

A train horn actually producing 500dB would need to be powered by antimatter, and you need a Kardashev type II civilization to be able to build one.

[jpyeron]

It can be sized up to a 500dB train-horn.

...
A train horn actually producing 500dB would need to be powered by antimatter, and you need a Kardashev type II civilization to be able to build one.

, but it would also need to be UL listed.

[Nominal Animal]

I don't think UL has standards for planetary obliteration weaponry.
(The "500dB" train-horns you see on eBay and such is just a ploy to attract gullible buyers.  They can be anything from 40dB (toy) to 110dB (real).)

If I were to build an open-source alarm system, I'd make it into multiple independent circuits which monitor each other, all messages encrypted, and disarm messages additionally using salted hashes of the passkey (derived from the user "password").  This way, each monitoring circuit knows only one or more salted hashes of the disarm message key, not the key itself.  I'd also add purely passive monitoring circuits, recording (write-only) all trips, disarm attempts, and successful disarms.  Simply put, a distributed interconnected system favouring one-way monitoring connections.

The main thing, for me, would be to avoid single point failure scenarios.