works well if you're living the iLife in Apple's walled garden. and here i am hoping for https://www.openhab.org/ to become bigger and better. i want automation without vendor lock-in (hardware or software), and without relying on closed-source and third-party services for the pleasure.
i was doing some research recently about having wifi-connected smoke alarm/CO listening device that can recognize [1] off-the-shelf alarm beeps (which are standardized) and send me an SMS & email. this turned out to be surprisingly difficult to achieve. ideally, i could hook up a microphone to a BeagleBoard of Raspberry Pi, run some daemon that monitors audio, does beep recognition and lets me hook into notifications.
instead, there are proprietary listening devices (ok, fine) that all work by sending notifications via third-party service (not fine) to some android or iphone app (not fine).
I was originally considering openhab, but then I discovered Home-Assistant (https://home-assistant.io/) and I've been hooked since. It ticks off a bunch of check-boxes that made it a great home OSS solution:
Pro's
- No internet required, can run entirely on a Rasberry Pi
Home-assistant also has a great homebridge plugin (https://github.com/home-assistant/homebridge-homeassistant) to easily bridge devices to HomeKit. I got home-assistant talking to zwave and zigbee with a Linear HUSBZB-1 stick (new version does both) and finally threw my wink hub in the garbage. Even through Home app -> homebridge -> home-assistant, everything is super fast and 100% local, unlike most of the commercial hubs.
I second the Home Assistant suggestion - I've also been running it for a while now, and it's pretty easy to get the hang of once you've been using it for a while.
Admittedly I'm definitely a tinkerer myself, but I honestly like the config just being a bunch of YAML files. It's really easy to back up that way.
Why not just monitor the actual beeper's voltage and alert when its going off? It seem's a lot more difficult to analyze audio and listen for specific sounds and patterns than it is to just trigger an interrupt when a beeper turns on. Program an ESP8266 to fire off a message whenever the interrupt pin is driven high [1]. You might even have enough room to fit the thing inside the alarm and power it using the onboard power supply. The alarm might even have a signal that is always active when the alarm is going off versus pulsing to active the beeper. It might be cheaper and more adaptable to have just one device listening for any beeps but it's going to be much more complex than just adding modems to all your devices that you care to listen to that fire off messages to a home server that would forward alerts if need be. You could even just make the modems use all the same code and refer to them by MAC address when they are sending out alarm messages to your server ("alarm a0:b1:c2 is activated").
The listening approach is, perhaps, more complex overall, but most of the complexity is in software. The hardware is simple commodity hardware.
The put an ESP8266 in each device approach puts the complexity in hardware, and in interfacing the hardware to the smoke detector. If you ever replace a smoke detector with one from a different manufacturer you may have to change the interface method.
In addition to that, the ESP8266 approach is harder to manage. Whenever you change your wifi network in a way that requires updating login parameters you have to update the firmware on all your smoke alarm monitors.
With the listening approach, you just have to change login parameters on the device that is doing the listening (if it is using wifi...I'd probably actually have it on ethernet)
Furthermore, the listening approach can be expanded to listen for other things besides smoke detectors just be changing software. You could add listening for your doorbell, or your telephone, or your dog barking, or glass breaking.
> Furthermore, the listening approach can be expanded to listen for other things besides smoke detectors just be changing software. You could add listening for your doorbell, or your telephone, or your dog barking, or glass breaking.
Or a whistling gas kettle, which is an actual use case for me.
Generally, I very like the approach of listening and trying to recognize sounds. It's much more flexible than trying to put a brain in every other thing you have at home.
Here in Ontario, it seems the government doesn't think too kindly of modifying smoke detectors[0], not sure about CO detectors. I suspect that wiring directly to the beeper is grey or black in many places. I guess you could do it if it's a redundant detector.
hmmm, i wonder if i can MITM a Roost Smart Battery, so i dont have to use their apps or servers. i guess IFTTT would be okay, and it does support this.
i was doing some research recently about having wifi-connected smoke alarm/CO listening device that can recognize [1] off-the-shelf alarm beeps (which are standardized) and send me an SMS & email. this turned out to be surprisingly difficult to achieve. ideally, i could hook up a microphone to a BeagleBoard of Raspberry Pi, run some daemon that monitors audio, does beep recognition and lets me hook into notifications.
instead, there are proprietary listening devices (ok, fine) that all work by sending notifications via third-party service (not fine) to some android or iphone app (not fine).
[1] https://github.com/benjaminchodroff/alarmBeepDetect