Standalone Alarm System with physical keypad

While I love my Home Assistant server, I much prefer to set up any hardware/physical smart home as self-contained, with the server being bonus features. I want my smart thermostat + boiler receiver to be directly paired and the same for my light switches + lights.

For my alarm panel that means I want my alarm to work without any other computer, and I want fallback physical keypad to arm/disarm. If I’m on holiday and my network is down, and my server has crashed, I want my alarm to still work, but more importantly I want to be able to give my neighbours or my mother a way to disarm it!

I’ve achieved this using the standard “alarm-panel-pro-esp32-local-alarm.yaml” config on the github konnected-io/konnected-esphome repo, combined with the Wiegand and Key Collector ESPHome component.

My core concern, and the biggest risk I found was finding a keypad which would actually work. I found that this model worked Amazon.co.uk. The only downside is that it’s a bit noisy!

I wired up 12V+ and GND, and then connected D0/D1 to zone 1 and zone 2, and that simply works! I even managed to reuse the wiring for my old alarm system’s keypad, as it was a simple 6 core cable. It also came with RFID tags, which can be used as well: an RFID tag just sends a unique number per tag. Not very useful, but easy to do!

My current config can be found here.

My next steps are to set up the smart side of my intergrations, so that I never actually have to use the keypad myself :slight_smile:

1 Like

Very useful and a great result, and has made concerns I had about the interface board moot. I’d much prefer a simpler all in one solution like yours! Some questions:

  1. In your testing/use, are there any limitations during offline use (vs a traditional alarm)?
  2. Did you use a pro for this? Would it work on a standard?

Re 1:
I’m still working on it, so still testing at the moment, but from my limited understanding of traditional alarms (e.g. reading the manual of the 20 year old honeywell alarm I had before): there really isn’t that much functionality in a traditional alarm.

As far as I can tell all they do is:

  1. Keypad to arm/disarm with one or two codes
  2. Two or Three sets of zones for “night” vs “away”, armed with different codes
  3. Delay before arm
  4. If motion, delay before trigger
  5. Once triggered, set off sirens and strobe
  6. Backup battery, to keep running if powercut
  7. Siren battery, to set off siren if panel disconnected

If one is comfortable with amending custom firmware to set up modes and zones and experimenting with the state machine, I can’t see any limitations with offline usage compared to an old traditional alarm.

However, I’m not using this offline, and my understanding is that modern normal alarms aren’t offline either. The rest of the value I’m getting from this is from local and online usage.

It’s a lot more work to build a reliable replacement for the notification and any remote control features that alarms may have these days. You need a bunch of other services.

I’m using the mqtt component to expose the state of the alarm to other services I run. Notably, I have a nodered instance which will send me notifications using ntfy for alarms. I also use the zone sensors to trigger lights in the kitchen.

Re 2:
I’m using a Pro, yes.

I don’t really know the practical differences between Standard and Pro. The standard has an ESP8266 instead of ESP32, which is more limited in some ways, but I don’t see why that would matter for this. It’s also only got 6 zones, and you lose 2 to the keypad, so that’s only 4 zones. There are addon boards, which I haven’t looked into, but they have separate chips so that might need more complicated inter-board comms.

You might need @nate to advise on standard vs pro.

That’s really helpful! For reference by “traditional” I did mean “offline” as my mental model uses my existing 20 year old dumb alarm as the base case, so notifications and API access is all out of scope for the minimum requirements here (which is a fancy way to phrase “existing users”).

Your list is pretty bang on, perhaps with the omission of

  1. A key or remote switch. I dont use this feature myself (but expect to as a result of making it smart), but I’d imagine being able to use Bluetooth for that locally if really required.
  2. A panic feature which I think is just another zone.

I also have some questions about anti tamper, but suspect that’s also Just Another Zone.

In that sense your post is very reassuring so thanks!

Re pro, I believe these features do not work on extended setups, but even if you only need 4 zones it’s probably worth going pro to save some pain.

Anti-tamper is an interesting one, but yes, I think it’s just another zone, although I suspect it’ll have different pin configuration.

I decided, together with the engineer who did the wiring, not to bother with the existing tamper wiring (the strobe, siren, old keypad, sensors, internal siren, and box all had tamper circuits!). Partly to reduce complexity, but also just to save having to work out whatever odd wiring they used.

My plan is just to ensure that any motion when the alarm is armed sends an immediate notification to my phone. So how do they avoid that?

It all gets a bit excessive when modelled:

  1. They disable a sensor → by drilling through walls?
  2. They get to the alarm panel to disable it → past the sensors?
  3. They cut the power → Battery backup
  4. They cut the power and the backup battery-> Siren backup battery
  5. They cut my internet so I don’t get notified, and prevent triggering → OK, this could work. So I’ll just set up a cloud-based dead man’s switch where I’m notified if my home internet is out and my alarm was armed.

It feels like the tamper circuit can only be useful to avoid people taking advantage of the delay before an alarm goes off. But immediately notification of that to me seems to handle the same issue.

Yes, in a smart context tamper probably matters less, and my working assumption is that the smart-failure state (eg Home Assistant or the internet goes down) is transient and monitored separately anyway.

So I guess a conclusion is that core features can be split into mission and non-mission critical features, the former of which is covered by your list. And it seems that Konnected should be able to do that much.

If the alarm is triggered while disconnected, how can you see what zone triggered it (or even its current state)? We traditionally have LEDs - is there a local log of sorts?

There’s a continuous log which is sent to listeners when connected (in my case, MQTT or the web dashboard), but I think ESPHome’s log component doesn’t have any local storage by default. The default konnected firmware makes use of a web portal which just shows you all the state of the alarm + logs, which you can use to see what’s happening live.

This is getting into even more custom firmware logic, but if I were to implement this I think there are two parts:

  1. Keeping a list of triggered zones: This is probably quite easy, just build a list and reset it on disarm. I don’t know how you distinguish between the original trigger and the user triggering on their way to the keypad/panel.
  2. Showing that information to users

For 2, I guess it depends how sophisticated you want to be:
a. Use the buzzer: Every 10 seconds or so, just beep the right number of times for the zone id?
b. A single LED: If you sacrifice a zone, you could just drive a single LED, again using flashing for the number?
c. Individually addressable LEDs
d. Dot matrix display
e. Any other directly wired external device which you can display on
f. A locally networked device which runs a web server and does the display

For c, d, e, that’s going beyond my electronics experience: ESP Home has components for all sorts of things (Display Component — ESPHome), but I don’t know whether there are limitations due to the way Konnected have mounted the chip. I wouldn’t know what would have risk of damaging things :slight_smile:

A neopixel LED strip or matrix is pretty simple re hardware though.

Well given the transience of the situation we’re talking about (an alarm event during an unexpected infrastructure failure state), retrieving a log with a WiFi device connecting directly to the Konnected device should suffice!