I was asked to describe the stuff I use for my not-so-smart home and how it fits together. This was originally an email, but I figure other people might find it interesting
This is as complete as I can think!
The goal, where possible, is to have everything under local control and not dependent on the cloud. Setup may require cloud…
Lights
Philips hue bulbs where possible (including the mirror light)
- Hue hub has a local API
- Mostly Hue White bulbs (LWB014), a couple of Hue White Ambience (LTA003) and a mirror light (LWT018)
- Hue dimmer switches (RWL020) for normal “light switch” type control.
- Hue Motion Sensors (SML001) downstairs bathroom, laundry, attic
Lutron Caseta switches elsewhere (eg for outside garden lights, fluorescent bulbs)
- Really a cloudy service, but people have reverse engineered the protocol to allow for local communications, at least for monitoring and control. Requires cloud to add new switches
Smart switches (https://www.amazon.com/gp/product/B079FDTG7T/)
- flashed with Tasmota firmware for local control
- The original firmware is chinese cloudy but Tasmota firmware replaces this and provides local control via API or MQTT
- NOTE: Tasmota is not a supported firmware and newer revisions of the switch may not be flashable! Do research.
Ikea TRADFRI bulb 950lm
- This is a Zigbee bulb and can be added to the Hue Bridge. It’s a lot cheaper than Hue bulbs, but can’t be upgraded from the Hue Bridge.
- Pairing isn’t always easy (it took me many attempts) and it sometimes falls off the bridge and needs a power cycle.
- Doesn’t support the “on power failure/restore return the previous state” function of Hue Bulbs.
- I wouldn’t consider these for bedrooms because of that.
Plugs:
TP-Link HS105
- Really cloudy (Kasa) but people have reverse engineered the protocol for local control
Generic (https://www.amazon.com/gp/product/B07N1JPPXK/)
- Flashed with Tasmota. See previous warning!
Power sensing (https://www.amazon.com/gp/product/B07LGSBFNJ/)
- Flashed with Tasmota. See previous warning!
- I’m not sure these are accurate in what they report, but they’re good enough to let me know when the washing machine or drier has finished
Thermostat
- Radio Thermostat CT50 with Wireless module
- I got this ‘cos it has full local control API… but it’s not very good; it seems like it only has a single-threaded CPU/OS so when it’s busy doing one thing then it can’t handle another, so API calls frequently get dropped. It works, but I don’t recommend it.
Garage Door
- Shelly-1 with magnetic reed switch.
Other
Frigidaire Air Conditioner FGRC0644U1
- This isn’t a bad aircon, but the mobile app isn’t the best. It’s totally cloudy with no local API.
- Has Alexa integration
Toshiba Microwave ML-EM34P
- As a microwave it’s OK. As a smart microwave it’s pretty bad.
- Totally cloudy
- Alexa integration frequently breaks (so much so, I stopped using it)
- The MSSmartLife app on mobile device isn’t even working properly!
Home Grown Stuff
Lots of things based around ESP8266/ESP32 with sketches I’ve written, to
either report information or try to turn dumb devices semi-smart
eg
- https://github.com/sweharris/esp32-doorbell
- https://github.com/sweharris/esp8266-temperature
- https://github.com/sweharris/esp8266-indicator
- https://github.com/sweharris/esp8266-bme280
- https://github.com/sweharris/esp8266-aircon
More complicated stuff:
https://github.com/sweharris/huebridge-shell
- It presents a “fake Hue Bridge” which is good enough for Alexa to discover. The lights it presents are handled by scripts. So if I say “Alexa turn bluray on” then it will turn on the fake light called “bluray” and my script will turn on the TV, turn on the BluRay player, turn on the Denon receiver and switch it to BluRay input. This is also how I can control the Tasmota switches by voice.
- I run 3 copies of this! One on my Mac for media player stuff, since it also can control itunes; one on the Home Automation (HA) VM for thermostat, aircon, tasmota devices, Garage Door; one on my desktop Linux machine so I can turn the screen off.
https://github.com/sweharris/Alexa-Smart-Home-VirtualButtons
- Using Lambda functions to present fake “door sensors” to Alexa which can be triggered via HTTP calls. When these sensors trip an Alexa routine can be triggered (eg say “Garage door is open”).
(unplublished) Media-API Alexa Skill
- “Alexa tell the robot …”
- This is written in GoLang and runs on my Mac Mini media player and is mostly for media control (“tell the robot to pause”). It’ll work out the current device (eg BluRay, or iTunes, or DVD Player App, etc) and send the appropriate commands. Also can be used for reporting (“ask the robot what for temperature”) where it will query MQTT for current values. This is kinda parallel to all the home automation stuff.
Putting it all together
A lot of this stuff communicates via MQTT, so I run Mosquitto MQTT server (https://mosquitto.org/) on the HA VM. Since I use CentOS 7 for the VM, I just use the version in EPEL
And then I run Home Assistant (https://www.home-assistant.io/) in a Docker container on the HA VM. This is what handles the coordination and triggers, as well as providing a dashboard. It also provides a mobile app so I can control things from out of home, as well as receive notifications (eg my phone plays a noise when the garage door opens). Talks to Hue, Caseta, TP-Link, MQTT directly without cloud requirements. Can talk to the Frigidaire cloud via a third party integration.
The Alexa Skill requires access from the internet so a firewall hole needs to be opened (in my case I had a webserver exposed, so I made it also act as a reverse proxy to send the request from external to internal).
Home Assistant requires access from the internet if you want to use it out of home, so needs a firewall hole as well. OR you can sign up for a cloud account and have them proxy the data. I didn’t want cloud dependency.
Examples:
“Alexa open the garage doors”
- Alexa -> HueBridge-Shell -> Shelly 1
Alexa announcing “Garage Door is open”
- Shelly 1 (reed switch) -> MQTT -> HA Automation -> VirtualButton -> Alexa Routine
Walk into downstairs bathroom, light turns on
- Motion Sensor -> Philips Hue Bridge -> Light
Turn on basement main light, second light over computers turn on
- Caseta -> HA Automation -> Caseta
- (this is how two unrelated switches can be put together to act as if they are one)
Walk into laundry, Hue Bulbs turn on, fluorescent bulbs turn on
- Motion Sensor -> Philips Hue Bridge -> Light -> HA Automation -> Lutron Caseta
- (an example how two different ecosystems can be put together)
Turn off Laundry lights with switch, Hue bulbs turn off
- Caseta -> HA Automation -> Philips Hue Bridge
- (another example of two different ecosystems)
“Alexa what’s the temperature”
- Alexa routine -> “ask the robot for temperature” -> Media-API
- (an example of how Alexa routines can now call skills)
“Alexa bedtime”
- Turns off the media center, nearly all the lights, my Linux machine monitor, the ground floor air-con; turns on the bedroom lights, starts the bedroom Echo playing music
- Alexa routine -> Philips Hue Brige + Caseta + HueBridge Shell (all 3 copies) + …
- (basically uses a lot of the stuff, all together in one routine!)
Conclusion
The current state of home automation involves a lot of patchwork and kludges. At least if you’re doing it on a budget!
I’ve got it working, and it’s pretty reliable. But it’s not totally hands free (I’d estimate maybe once a month I have to poke at HA; less so once I got rid of the Alexa integration and wrote my own VirtualButton skill).
What I’ve done works for me. And somehow the HA VM has gone from being a test (“how does this work”) to part of my daily home experience. It does stuff in the background that I only realise if it breaks!