Yeah, a Blink chime is definitely a solution. But after feeling like I got a great deal on a cheap doorbell, I didn't want to buy yet another thing from them. I also thought it would have been easy to play audio on the Google home and so I started tinkering and then got carried away.
MQTT was an option, but it actually felt like overkill to add an MQTT server on my VPS than just a tiny Express server. (But who am I to talk about overkill here.)
I thought it was finally time to write up the story of my absurd home doorbell implementation, especially because the upcoming Samsung SmartThings API pricing means things will have to change soon.
We have a Ring doorbell that hooks into the actual chime that the old doorbell used, so it still preserves the old doorbell's functionality[1]. I can understand not wanting to buy into the Ring ecosystem (we started using them before they were bought by Amazon), but maybe there are cheaper doorbells that also do that? All we had to do to make the old chime work with the Ring doorbell was install an extra widget that came with the Ring doorbell inside the chime; the Ring doorbell's instructions explained how to do it. It just needed a screwdriver and a few minutes' work.
[1] More precisely, we did until we moved to a manufactured home that did not even have a doorbell installed, after which I had to do some jiggering (now we have a Ring chime that the doorbell can talk to over the house's LAN). But the setup I describe above worked fine for a number of years in the house we were in before.
I have a similar problem, except I needed to ring the actual doorbell. Currently I'm using a HomeKit-compatible video doorbell that communicates over proprietary radio to its wifi gateway that triggers a HomeKit automation (which presumably runs on my Apple TV as the hub) to turn a Shelly relay on for one second to do the same thing as pressing the doorbell button. I think this all ends up just using my internal network, but who knows. Thank goodness the Shelly relay can get a wifi signal while stuffed into that electrical box in the basement ceiling.
(The actual doorbell button is still there too, so it's a crapshoot which one somebody decides to use in the first place. And yes, many video doorbells have a "chime adapter" to take care of this, but our house's doorbell wiring made them run in fear.)
I'll have to check the latency of my 'smart' doorbell now. I have occasionally heard the doorbell, taken the obligatory time to find the key to unlock the door to find that it was just a package delivery, but enough time had passed that the courier was nowhere to be seen.
(Yours wasn't a latency issue though, what kind of latency do you get with your 5-cloud services chain?)
Also, interesting about the SmartThings API access moving to a subscription model: https://hackaday.com/2026/07/28/samsungs-smartthings-api-ter... (this link is in the article - the cost is only for third party usage, not if you're directly using the SmartThings app).
I thought it was finally time to write up the story of my absurd home doorbell implementation, especially because the upcoming Samsung SmartThings API pricing means things will have to change soon.
I too have a IOT doorbell! It's using Zigbee, just like the actual speaker ("bell") that also serves as our home security audible alarm, and other things. It's basically "Button on the outside of house > Home Assistant > Speaker", and works 100% offline, and is backed by a UPS :)
If you get rid of HTTP and 3rd party services, all this stuff gets really simple, durable and easy to maintain. Haven't touched the setup in years, except to change the battery once in the bell as it's 100% remote, haven't had a single issue since we set it up.
Yeah, a local solution is probably the way to go. This was at the beginning of my home automation journey so I didn't have Home Assistant and Zigbee set up yet.
But even if I replace the actual doorbell with a zigbee button, I still need a solution for the camera portion too.
> But even if I replace the actual doorbell with a zigbee button, I still need a solution for the camera portion too.
True. My cameras (none outdoors though) are WiFi connected, and run tiny little individual UPSes too, saves recording locally to SD card and to a NAS, which also mean you need UPS for your WiFi network+NAS if you go this way. I'm running it with Frigate, and communicate over MQTT to Home Assistant, so cameras can be viewed in HA and react to events and so on.
This setup hasn't been problem free though, not sure if it's the cameras that overheat or something, but I need to reboot them every 48h or so, or they lock up, but at least Frigate been working out well for me.
> After a few days of digging around for answers (I even asked gpt-4o, but no luck),
I'm surprised GPT didn't suggest a local HA setup, when I went looking some years ago when I first got started with HA, Zigbee and everything 100% local seemed like the obvious solution based on what I found around in the HA communities.
