Building a DIY Smart Doorbell | Hacker News Reader

Building a DIY Smart Doorbell

buzzert.net

157 pointsbuzzert71 comments

The best parts I found here :

> The Ring Doorbell, which is now owned by advertising megacorp Amazon, suffers from all of the same privacy problems described in my post about the Nest thermostat, but even worse. Like the Nest thermostat, the client software is a total “race to the bottom” one-size-fits-all garbage iOS app that not only looks bad, but is full of bugs. Also like the Nest, all of your data is hosted in “the cloud”, and a monthly ransom is required before you (“the customer”) are actually allowed to access it. Worse than the Nest, however, is the fact that the Ring doorbell actually has a camera and microphone built-in, so video and audio feeds are also held for ransom in “the cloud”, and are shared with any interested party, sometimes even without your permission.

> Just like many other Internet of Things products, the Ring has also been subject to multiple disastrous data breaches, meaning besides law enforcement agencies and advertising partners, many Ring customers’ private data is now also in the hands of malicious hackers, who may in the future offer ransoms that are much harder to refuse than the one offered by Amazon.

____ end quote.

Build all the small stuffs yourself, as much as you can. Another reason to learn DIY, even though off the shelf solutions exist.

You had me at "monthly ransom".

As someone on HN once quipped, Iinternet of Things is not going to happen until LAN of Things happens".

This has the problem of a common controller, though. The router could be it; most modern routers are quite beefy. For those running linux internally a standard to deploy apps, including the LAN smart home controller, should be reasonably easy to devise, unless it already exists.

> The router could be it

Already seeing various home hubs coming bundled, so this seems to be on the way. Whether you’ll have access to this or if it hosts a “partner” remains to be seen.

For now I think we’ll be seeing a profusion of Raspberri Pi based “LoT” devices just because they are so damn easy to work with and they come with a certain amount of sense and control stuff baked in.

I've got a lot of hope for Home Assistant here. Its just a little bit too involved for a typical end user at the moment but I really don't think its very far from being something that can be sold as an appliance to people who don't know what MQTT is.

I love Home Assistant, but it's definitely hobbyist software, not end-user software.

So you hire someone to put it in for you. A car analogy is not far behind 9)

Considering how unique each how is in details that matter to this type of thing I think smart houses will need to evolve to hiring someone to set it up. Sure your device can connect automatically - that is easy - then you need to tell it what room it is in, and what events to respond to. Only some of that can be automated.

If you hold your nose, you get OK Google and co to act as your intermediary.

Home Assistant has one paid for option: "Nabu casa" which includes an intermediated link to Google/Amazon etc. https://www.nabucasa.com/

I have run up several HAs and it keeps on getting better. Yes, each deployment is different but HA delivers because if you use "supervisored" or the hass.io distro you get all the addons out of the box and that includes Node Red with a shed load of batteries included. Adding more is simply a config entry.

I have one customer who needs a way to fire up and shutdown their office PCs when they work from home. These are Catia workstations with some serious grunt that a home machine generally lacks. I deployed HA and LAPS (MS way to deploy local admins on a Windows box.) HA is a VM so it is "free" apart from my time. I recently added an AD account unlock facility involving quite a lot of LDAP triggered by a button press, not to mention a few ACL changes on the AdminSDHolder container.

My home HA controls underfloor heating, makes my doorbell speak to us. It turns a water feature off and on depending on sunup and sundown and a few other things. I've recently added a power meter monitor.

My office one watches windows, doors and lights amongst other things. That was an easy win. When you lock up at the end of the day you check out the panel and it tells you which windows are still open etc and you sort that out. It will also send MQTT messages and SMS my phone if any smoke or water sensors go off on one. We have 40 windows and a quite a few doors in my office. Most doors are defined as fire doors (UK) so they must be shut. We have a NUC style PC with two LG commercial panels attached and a camera for constant video conferencing with a colleague in another country. A NodeRed routine wakes the lot up in the morning and shuts it down at night.

I've barely scratched the surface of what HA and co can do. The real point is that all this stuff is free or nearly free and is documented and there are forums for support.

In HA (finally) Zwave, Zigbee and all the rest are finally all useful and very well supported. You still need to take some care but there are very few sharp edges left. Nowadays all I see is a relentless progress, functionality just keeps on appearing. It's quite something to watch.

It has come a really long way, to be fair. My configuration.yaml no longer has any integration configs, it wasn't that long ago that a ton of basic integrations required YAML, and the restart cycle that entails.

Right now the only thing of note in mine is a template cover, I have a relay controlling my garage door opener and a tilt sensor checking the door, so I need to tie those together into a cover entity via a template.

I do a fresh install of HA every so often to see where it's at. It has a steep learning curve and it's a mostly unpleasant experience to setup.

Webthings (formerly Mozilla) is a much more consumer friendly interface and a breeze to setup by comparison, it's a shame it's languishing with little interest in the project.

HA has improved quite a lot over the last say 18 months. Please consider giving it another go.

Make sure you are using either hass.io or supervised. The dockerised approaches are far superior to say the venv jobbie. I'm a dyed in the wool old school sysadmin and it took a while for me to get it. Get the nginx proxy addon with Lets Encrypt working and you are all good for kick off.

As always, ensure stuff you don't trust is on its own network/VLAN or use host based firewalls to take up the slack. HA will use HIBP to check your passwords in your addons which was controversial but I think rather good.

HA is in the hands of people who seem quite driven, which is nice.

Specialized IoT controllers are massively oversold. Most people don't need one, including hobbyists and HN commentors. I've developed this opinion after several years of work in IoT.

At the link layer, just use WiFi. If power is an issue, there's 802.15.4 and 6LoWPAN (bridged to WiFi). At the network layer, it's a regular LAN. Lastly, at the application layer, most devices stand on their own. 90% of the value in a smart doorbell is derived from its connection to your smartphone, not whether it can talk to your thermostat or smoke detector.

To evaluate the truth of this statement, walk down Home Depot's "Smart Home" aisle and count products which support complex multi-device interactions, or advertise these interactions as core features.

You forgot to mention the most important thing. If it is important then it should work despite the internet and ideally, despite the LAN/WLAN.

My home doorbell triggers a battery backed chime as well as all the other funky stuff. The chime is always first before our phones and the Sonos thingies go berserk. I monitor the battery on the chime too because the Home Assistant tells me to on a schedule. I use my multimeter.

If I am down the garden, I can't hear the chime but I have a phone on me normally and the lights on the summer house blinking in morse is a give away if the mower is drowning out the phone.

Tools for the job. ... Yes I do have quite a lot of time on my hands ...

Home assistant said this better than you from the start: https://www.home-assistant.io/blog/2016/01/19/perfect-home-a...

Once you realize where you are right and where you are wrong you can start asking if and how automation might help you personally.

So what would you recommend as a wifi item? A lot of them seem to be crap, and don't you get issues with having +30 low frequency, low bandwidth wifi items added to your home network, along with the 30 other ones at your home already? How about remote exploits of those devices?

The fact that wifi 'can't handle a 100 small devices well' was sold to me as a reason to go z-wave 5 years ago.

I hope Thread[0] and Metter[1] will solve that problem

[0]: https://www.threadgroup.org/

[1]: https://buildwithmatter.com/

The "long range doorbell that doesn't do evil things" seems like a product space that is a bit of a vacuum.

We've recently had an office built at the end of our garden. Finding a doorbell that will work from the front of our house has been a futile mission so far. I have little interest in a camera, I certainly have no need to connect anything to my (lack of) smart home. I just want a thing that rings in my shed when someone pushes the house bell.

"Long range" wireless bells just don't seem to cut it. Everything else is massively over engineered. It's a strange thing that maybe my best solution seems to be running a very long wire down the garden...!

How about a baby phone near your door bell and one in your office?

Something like this?

https://m.banggood.com/DIGOO-DG-DB1-433MHz-Wireless-Doorbell...

I think that's similar to the one they are referring to; does it have the range to pass through a house into the back yard?

This seems like a good use case for LoRa wireless modules, I haven't used them personally, but they claim a range of 10 miles without obstacles. Try searching for "LoRaWAN Door Bell" if you want off-the-shelf products, or otherwise for "Arduino + LoRa" if you want to DIY :-)

I can recommend moteino - Arduino with a Lora transceiver piggy backed on it.

There's the August doorbell.

Save yourself from all the disillusionments in the future and run that wire.

Indeed, and if it stops working, debugging the wire will be much easier than reverse-engineering an obsolete mobile application.

If you need wireless and are not adverse to some tinkering, a pair of Arduinos, a button, a buzzer and a pair of RF 433MHz transceivers [1] may do the trick!

[1] https://randomnerdtutorials.com/rf-433mhz-transmitter-receiv...

Rather than trying to add a button at the front door, tap into your existing buzzer (or listen to it, maybe with an accelerometer on the Arduino)

I use the live feed from the Reaper drone overhead.

I embarked on a fun lockdown project retrofitting our traditional doorbell (which runs off a 12V AC transformer in the basement) to generate MQTT messages for logging and to trigger notifications (phone, pop-ups on my workstation, sonos noises, hue lighting flashes etc). I have the same problem of not hearing the front door from my office in the loft.

I ended up with an ESP-32 module connected to the house wifi, and an opto-isolated circuit to trigger it from the doorbell wiring. It sits in the basement where it's easy to give it power from a USB power adaptor.

Of course, the irony was that it was only after I'd lost a few days going down this particular rabbit hole that I discovered that almost every visitor (and especially delivery drivers) uses our door _knocker_, rather than the doorbell since it's much more obvious! The next project may be to electrify that, or mount a vibration sensor on the door!

Or just remove the door knocker :)

Not if it looks great!

I just bought a house and discovered that it has a working long-tube door chime system! It’s got 3 brass tubes, each over a meter long, perfectly tuned and plays a short musical number when someone presses the button. You can sure hear it anywhere in the house, but I really like this MQTT idea!

what about hearing what's going on at the front door? a small pipe from door to office that transmits sounds (door bell or whatever is happening at front door)

My solution was to attach a little board from https://www.particle.io/ to a doorbell ringer to detect when the doorbell rings, which pokes a port on a PC in my office that is always on anyway. The PC uses ffmpeg to play a sound.

Do you have wifi in the office?

The killer bit here was that the author already had a PoE run available: That's the killer for nearly all good IoT projects. PoE is king, and unless you're building new, you probably don't have it.

PoE is desirable for sure, but you could always just power it with a battery.

RPI Zero with a camera is more power intensive than just a little microcontroller. You would need to either recharge / swap batteries now and then or charge from solar. Then you still need network and the WiFi signal might be weak where your doorbell is.

My old doorbell has a wire, I'm sure it's just a low power switching wire but that should be good enough for the 5 volts needed.

Doorbells typically use 12-16VAC provided by a small transformer near your circuit breaker panel. It's plenty of power to run whatever you need.

Sure, but then you have no data line, and using Wi-Fi for security is a really bad idea.

Low power design is pretty hard (for me at least) if you need to send radio stuff

Try something like this if you just need one-way radio just need to intermittently send a few bytes [1]. On the receive side there are similar modules [2], but if you've got an RPi on the receive side or a desktop computer then there is another way to receive which I'll describe below.

The transmit module uses a few mA when transmitting. I don't know what it uses when just sitting idle--probably very low but if not just don't give it power except when transmitting. Its maximum current draw is below is below what a GPIO pin can supply on an Arduino, RPi, and microcontrollers such as the ATtiny, so you could probably just hook its Vcc pin directly to a GPIO, hook its DATA IN to another GPIO, hook up ground and (optionally) add an antenna, and you are all set.

Lets say you can send at a rate of 2400 bits/second, and you need to send 400 bits every minute. That's 10 seconds of transmit time per hour. If it draws 10 mA while transmitting, that's 0.028 mAh or 0.14 mWh if you are using a 5 V system. A rechargable NiMH battery has about 2000 mWh capacity, which should power the transmitter for around 600 days.

For receiving you could use the corresponding module, but that is a bit of a pain. The way the transmit side works is that it has an oscillator running at 433.92ish MHz, and a transistor controlling whether or not the output of that oscillator is fed to the antenna. The DATA IN data controls that transistor.

If DATA IN is 1, the module transmits. If DATA IN is 0, the module does not transmit. The typical way this is used is to use this to send a series of pulses. You might encode a 1 message bit as pulse of T usec followed by no transmission for T usec, and a 0 message bit as a T usec pulse followed by 2T usec of silence. Or you might do a 1 as a pulse of 2T followed by silence of T, and a 0 as a pulse of T followed by 2T of silence. There are other ways, but those two are pretty common. (And you might use longer pulses to mark starts of messages or ends of messages).

The receiver module just monitors 433ish MHz and outputs a 1 on its DATA OUT when it thinks someone is transmitting and a 0 when it thinks no one is transmitting. The thing is it automatically adjusts the gain to where it almost always sees something even though it is usually noise. So what you see from the receiver's DATA OUT is an almost constant stream of 1 and 0. You need to look at that, and try to find in that sections that match what your transmitter sends.

If where you want to actually deal with the received data is an RPi or a desktop computer or similar, a simpler approach is to get an RTL-SDR dongle and the program rtl_433 [5]. From the description:

> rtl_433 (despite the name) is a generic data receiver, mainly for the 433.92 MHz, 868 MHz (SRD), 315 MHz, 345 MHz, and 915 MHz ISM bands.

...

> It works with RTL-SDR and/or SoapySDR. Actively tested and supported are Realtek RTL2832 based DVB dongles (using RTL-SDR) and LimeSDR (LimeSDR USB and LimeSDR mini engineering samples kindly provided by MyriadRf), PlutoSDR, HackRF One (using SoapySDR drivers), as well as SoapyRemote

It already knows about nearly 200 sensors and devices. Find a device it already supports that is similar to what you are doing, and use that as a model to add a decoder for your device.

[1] https://www.sparkfun.com/products/10534

[2] https://www.sparkfun.com/products/10532

[3] It is a very popular band for a ton of consumer devices. In my fairly low density neighborhood, I can pick up at least 5 temperature or temperature/humidity sensors from various home weather stations, the sensors from someone's AcuRite 5-in-1 weather station [4], the tire pressure sensors from several cars, someone's power use monitor, a soil moisture sensor, and some sort of remote button or keypad.

[4] https://www.weathershack.com/product/acurite-06004m.html

[5] https://github.com/merbanan/rtl_433

…or if you want to re-use your existing intercom and hook it up to MQTT, see https://michael.stapelberg.ch/posts/2021-03-13-smart-interco... for how I did that :)

This looks amazing - well done! I’ve started dabbling in hardware about a year ago. Starting with the Arduino starter kit. But somehow my brain doesn’t seem wired for it. It feels like all the pieces are there in my head but I’m unable to draw the connections.

I built a self igniting torpedo heater for a powder coat oven but even though it worked, I still feel like I stumbled through every step instead of understanding any of it. Like building a piece of software using SO snippets and just trial and erroring it until it works ;-)

Do you have any tutorial (series) recommendations for semi beginners on stuff like this? Maybe some “hardware explained for a software developer”? :D

I’m not aware of any tutorials unfortunately, but I would recommend connecting with your local Makerspace or Hackerspace. They can often be a great resource to find other people interested in electronics :)

> Starting with the Arduino starter kit. But somehow my brain doesn’t seem wired for it.

Have you looked into Raspberry Pi. I use these for even very simple things, just because it’s so easy to get up and running. Way over spec’d of course but if you jus want to “get something done” they can’t be beat.

With all these smart devices, what is so smart about them? Does the doorbell know to ignore certain people? Most of the smartness in this doorbell is simply having the notification go to a different place.

My smart TV still doesn't know what I want to watch, that is should pause stuff when I stand up during the middle of a move but should keep playing the commercials when I stand up so I can ignore them. Smart means: internet-connected or has a (touch)screen in case of a smartphone. /rant.

Nice build though, I'll replicate this some time.

Unfortunately a smart TV would be more likely to pause the commercials when it detects you are not looking at the TV

Reminds me of the infamous "Say McDonald's to end commercial" patent from Sony. You will engage with the advertisement, or content will be withheld.

That is what smart is: having technology that works when and how you need it to. Some people would put a sign on the door: "don't knock, just come in", and be comfortable with strangers doing that (the door exists for HVAC reasons) at any time of the day/night. Other people would prefer their doorbell be a few km away from their house and set it only ring during visiting hours. Most people are somewhere between those two extremes. Their doorbell needs to serve how they live their life.

While using an RPi is fun to get into and set up yourself, there's starting to be cheaper and better hardware featured controllers for doorbell projects like these, such as the TTGO, an ESP32-based board with camera, display, wireless, and button for anywhere from U$15-25.

https://github.com/petrepa/ESPHome-VideoDoorbell

Neat. Even w/o PoE already wired up, I guess a Pi Zero can be powered with a regular 12V line that every doorbell uses. Otherwise, getting this to run off batteries with a Pi (and WiFi) would be an exercise in futility - am currently building something with some Zeros, and even at an optimistic 150mA, that'll eat through 3000mA lithium batteries in no time.

I do wonder how the longevity of the case is, though - the case isn't weather-proof (also, its ABS, so I'd argue you can print it on an Ender 3).

I always find that to be one of the most challenging problems for outdoor-projects. If you ever too take a part e.g. a Blink XT (equally spyware, but I gave up at that point), you'd notice some pretty tight tolerances and seals, so that the cameras survive the outdoors. That doesn't seem easily replicated with a $9 box.

Most doorbells in the US are 16volt AC, (from memory so I'm probably off by a bit). While you can power a pi from that, the power supply will be tricky.

Yes, though for many doorbells when you push the button the power goes away.

Nice. Next step would be a microphone and speaker. You are effectively building an outdoor SIP videophone.

I like the idea, nice implementation, but I was hoping to be able to answer the door remotely.

One alternative I've been looking at is the ubiquiti doorbell, it allows answering the door with 1 way video and 2 way audio, without involving any cloud services.

Given there's an electronic lock on the other side with a keypad, it makes me think that thing has its own actuator and didn't want to mess with it. Otherwise it would just be a matter of adding an "Electric strike?" (https://www.tesa.es/en/site/tesa/products/electromechanical-...), feed it 12/24v through a relay connected to the pi zero, and add another api endpoint

I'd hold off buying anything Ubiquiti in the near term and wait for them to decide if they totally turn hostile their consumers (well, prosumers in that case) or not.

Just search the recent (3 to 6 months ago) news for them...

I think that's already been decided.

If you're not into walled gardens, don't bother waiting. You'll likely be unhappy with the outcome.

I'm in a situation where there was no wire at my front door so I'm limited in the type of doorbell cam. The one I settled on is Eufy who at least stores the information locally on the home base and doesn't charge for access. That said, I don't really know what's happening with my data, but from what I understand, it's not going to at third party (at least for the doorbell). This seemed like my best option.

I have the Unifi Doorbell, and I like it a lot. My use case is mainly for 24/7 recording and less so for interactive communication with people at the door, so take my preference with a grain of salt. Heck, I have never even used the two-way communication function since buying the doorbell earlier this year.

While I generally like the Unifi Protect walled garden (because of usability compared to other non-cloud options), it's not all sunshine and rainbows either.

If your doorbell rings and you launch the app, you're going to be waiting several seconds for the app to reinitialize, etc. By the time you answer, a significant amount of time will have passed. There's also latency between the two-way comms.

In my particular case, the tradeoffs of going with the Protect walled garden were worth it. The cameras are decent (yes, you can get cheaper and better), it is super easy to set up, and I didn't need to train my wife on how to use the mobile app at all.

If you're not into walled gardens, however, the Unifi Protect ecosystem probably isn't for you. As most surveillance cam peeps online will tell you, you can do a lot better for less money.

The project box aesthetic works really well for this. Did you waterproof the mounting holes and seam where the box fits together? Some silicone sealant will help keep out the moisture and keep out the wasps (ask me how I know lol)

My ideal DIY doorbell would be like a progressive-enhancement to the oldschool physical bell chime, just with the addition of a camera, maybe using something like this: https://www.2nusa.com/en_US/products/intercoms/2n-2wire

I used a little bit of hot glue to seal the screw holes I drilled into the back, and rubber washers for both the camera and the button in the front. Haven't had too many rainy days yet, but it seems to be holding up in the fog at least!

thanks for the link to 2N - depending on costs it may save me a time implementing rs-485.

The casing is huge, may be ok for a drivway system - in front of a gate, but I would want the casing to be much more lower profile

I have been playing with a crazy idea of getting some sort of realisic dog effect when the door bell is pressed, by using a linear solinoid and syncing the solinoid hitting the door frame (without daminging it) once or twice with a sound of a dog - playing on a few speakers - not all at once, some close and some further away to the door so it sounds like the dog is coming to the door then running off

If you like this sort of thing, Crowdsupply [1] and Tindie [2] are great places to browse once in a while.

And when you’re done with them, there’s always [3]!

1. https://www.crowdsupply.com/ 2. https://www.tindie.com/ 3. https://twitter.com/internetofshit?s=21

I'm not sure if this is the case, but doesn't this create the option for somebody to remove the casing and directly connect to your network?

I just assumed that he Pi lives in a separate box on the other side of the fence with just the GPIO pins exposed through a small hole.

What a cool project! If only I actually needed a doorbell... ;)

I would however LOVE to have a blueprint for a DIY "smart" door lock (like https://nuki.io/, but with FOSS firm- and software) available, yet a recent web search for such a thing did not yield results. If I did overlook something, please let me know!

Nice project & looks great!

All these DYI LoT projects assume one of two things:

  *  you are connected to your home Wifi

  *  you are routing all your mobile traffic to an always-on home VPN

This is where they fail for me and Rings, Nests, etc win:

  * I do NOT want to route ALL my mobile data traffic through at-home VPN while im out and about.

  * I have an iPhone which does not allow app-specific VPN configuration

  * I want to be able to get instant real-time video feeds in case of a doorbell events.

I have multiple internet-of-things hardware and software including

  * Ring

  * Wyze
 
  * Abode

  * Home Assistant

  * Blue Iris

And one thing is common: cloud-based services(Ring, Wyze, Abode) are faster and easier to use remotely then local-only Lan-of-Things products such as Home Assistant and Blue Iris which require one of two assumptions I listed above.

In other words, in order to connect to my local-only LoT products, i have to turn on my VPN and then open up the app and then to remember to turn it off when Im done. This is too slow and takes too much efforts and thus turns me back to cloud-based services.

Im not even talking about training the software to ignore things like wind moving leaves and tree branches and to only pay attention to what can be identified as humans

Reply on news.ycombinator.com