Bottom Line: I updated a Python script called Fauxmo that lets you control your Raspberry Pi with an Amazon Echo (and now supports HomeAssistant).
I was looking for a way to control my home automation devices with my new Amazon Echo, and I came across Fauxmo. I liked how it was local and didn’t require port forwarding or lambda functions like using an Alexa Skill would. Additionally, I didn’t like the required verbiage for running actions as a skill, e.g. “Alexa, tell the house to turn on the kitchen light” — I want to just say “Alexa, turn on the kitchen light,” which is supported by Fauxmo. I especially liked the fact that Fauxmo was written in Python, but I prefer Python3, so I decided to update it.
Fauxmo works by pretending to be a WeMo device, which the Echo supports natively. I don’t know much about websockets or upnp, so it was definitely a learning process, but I eventually got something that works. You can find my updated version at: https://github.com/n8henrie/fauxmo, or you should also be able to install through PyPI:
pip3 install fauxmo. One minor change (that made a big difference for me) was implementing a new handler for Home Assistant services.
After months of trying to decide on a central system to run my home automation, I’ve finally settled on Home Assistant — for a lot of reasons. It’s Python3, so I can tool around on it and hopefully even make a few contributions, but more importantly I can understand how it’s working. The interface is beautiful, development and the community are active, and the documentation is pretty good. Having a web-based interface means I can use any mobile or desktop interface I want, and once I have it set up with SSL, I’ll be able to access everything remotely as well.
Once I decided that Home Assistant (running on my Raspberry Pi 2) would be the core of my Home Automation system, I wanted to make sure that all my other systems worked through Home Assistant if possible. Luckily, in addition to its REST API, it has an awesome Python API. Because I have Home Assistant running on the same device that runs Fauxmo, I was able to implement a new type of handler that simplifies things a bit by using the Python API.
The reason I’ve done it this way is that Home Assistant now keeps track of the state of the devices for me. For example, I can turn on my kitchen light through Alexa: “Alexa, turn on the kitchen light”. Alexa then uses the Home Assistant API to turn on the light, so the next time I open Home Assistant, I’ll see the kitchen light button indicating the light is on.
Continuing this example of running everything through Home Assistant, you may have seen my recent post on home automation with Siri / HomeKit, which uses a Raspberry Pi running HomeBridge.
Well, it ended up being pretty simple to use the legacy HomeAssistant plugin to expose my Home Assistant services to homebridge — there is now even a mention of this method on the official Home Assistant blog. Update 20160310: as per discussion in this thread, GitHub user Maddox has moved the homebridge-homeassistant plugin out of legacy and into its own repo now moved into its own repo in the home-assistant organization.</p>
This way, I can open up Home Assistant and turn on my kitchen light — which will obviously have Home Assistant indicate that the light is on. I could then turn it off with Siri: "Hey Siri, turn off the kitchen light," and Home Assistant will update to show that the light is off. I can then turn it on again with Alexa: "Alexa, turn on the kitchen light." Home Assistant will then correctly show that the light is on again, and will show in its history that the light was turned on, off, then on again.
Schematically, it's something like this:
Having this kind of central system will be critical for more advanced automation schemes in the future, because they will depend on the accuracy of the reported states of devices. You can't exactly have a system "turn off the nightlight when the overhead light is turned on" unless it knows when the overhead light is on. This way, I can still use the dumb but super cheap RF switches I like for a lot of simple tasks and still keep pretty good track of their states, even though they don't support reporting their state to controllers, and at the same time I avoid locking myself into a single system for interacting with them.