While it’s no longer necessary because Home Assistant 0.35 introduced native support for Flic buttons, I’m still using the controller I released just before Home Assistant updated. In part, this is because I haven’t taken the time to switch the integrations over to Home Assistant automations. Also, having spent some time on the controller, I am not ready to abandon it.
It’s been a while since I’ve posted anything new about my experiences with home automation, largely because I haven’t done anything new in a few months. I’ve been busy, and at the same time, things are working as expected, so I haven’t come up with new ideas to test or dreamt up something else to automate (much to my husband’s relief).
That said, I’ve been thinking about replacing our hacked Amazon Dash buttons with something purpose-built. While the hijacked buttons work well-enough, there’s a noticeable delay between button press and response, and their battery life is quite finite. Also, there’s only so much one can do with vinyl tape to make the Dash buttons less of an eyesore.
Enter Flic, one of the only “smart buttons” available right now, and the only one I’ve found that doesn’t require its own hub. Fortunately, they offer a Linux SDK, so I can associate the buttons with one of my Raspberry Pis, rather than a smartphone (alleviating a common complaint about the product). Since the SDK requires exclusive use of a device’s Bluetooth controller, I benefit from having two Pis, and this project is simplified because the Pi I intended to use with the Flic happens to be the one whose Bluetooth isn’t in use.
My first project is to configure the Flic button to toggle the lights on our Christmas Tree. The lights are connected to a SmartThings outlet, which turns up in our Home Assistant instance thanks to MQTT, but Home Assistant is only accessible to my husband and I, while any of our guests should be able to turn on the tree. 🎄
Being away from home makes me appreciate how accustom I’ve become to my home automations…
For quite some time, I avoided acquiring any Rasbperry Pis. I already have four VPS, and I genuinely wanted to avoid expanding the number of Linux instances I was responsible for. My hesitation was for good reason; less than a month after acquiring my first Pi 3, I found a reason to add a second to our home network.
To be clear, I’ve nothing against the Raspberry Pi; I simply knew that my addictive personality would compel me to find ever-more uses for the devices, compelling their multiplication.
In the month since I first posted about how I am using Home Assistant, I’ve made a number of improvements to my configuration. These changes were mostly focused around usability–removing clutter from the interface and simplifying the layout–without losing any functionality. Two changes in particular really simplified the default view, making our light groupings more manageable and less overwhelming.
I installed a GE switch that supports Zigbee, so the painful florescent light in our kitchen doesn’t glare at me any longer without recourse.
I’m absurdly happy about being able to control a built-in light from Home Assistant.
I’ve also learned that GE’s Zigbee line is far more reliable than Leviton’s Z-Wave products.
Last week, I provided an overview of how I’ve introduced automation and control to our apartment by combining various smart-home devices with a robust platform to manage those inputs. My earlier post described, in broad terms, the hardware and software I’ve leveraged, and some of the automations I’ve implemented. Today, in anticipation of releasing the software configurations that make this possible, I’ll inventory the devices used and explain their roles in the overall system.
Until recently, one of the few things I couldn’t control from Home Assistant was the “Smart Home Monitor” (SHM)–or alarm–feature of the Samsung SmartThings platform. With the exception of our locks, controlling this was the only other task that required the provider’s app.