Hacker News Reader

Comment by leeoniya | Hacker News Reader

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).

[1] https://github.com/benjaminchodroff/alarmBeepDetect

View on HN

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

- Integrates with most everything thanks to the huge component library (https://home-assistant.io/components/)

- Easy to write your own Python component to integrate with new stuff

- Can use existing SmartThings/etc hubs or Z-wave usb stick to talk to most anything

- Fairly easy to write automations

- Well written Python 3 code-base that's fairly easy to read and see what's going on yourself

Con's

- Definitely more for the DIY tinkerer

- Need to write YAML for the automations, though a new GUI makes this easier for many cases

Setting up an SMS to me when a motion sensor tripped was pretty easy, my automation was:

    - alias: Alerting on bedroom motion
           initial_state: False
           trigger:
             platform: numeric_state
             entity_id: sensor.bedroom_burglar
             above: 0
           action:
             - service: notify.aws_sns
               data: 
                 message: "Bedroom alarm sensor has been tripped!"
                 target: HassAlert

I've had it running for over a year now, and it's been quite nice.

sounds pretty nice. thanks, i'll check it out.

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.

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.

What would be the steps you'd take when you receive the SMS "Bedroom alarm sensor has been tripped!"?

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").

[1]: https://techtutorialsx.com/2016/12/11/esp8266-external-inter...

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.

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.

[0]: http://www.mcscs.jus.gov.on.ca/english/FireMarshal/MakeitSto...

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.

Reply on news.ycombinator.com