Monuments to failure – part 3 – home automation

Howdy all, in this column I begin an {n} part series exploring ideas and code of mine that for one reason or another did not pan out. It’s important to note that none of these ideas were directly tied to my research and funding, though any could have found their way in pending better results. These posts will broadly represent blind explorations of tools and concepts outside of my discipline in an attempt to broaden my repertoire. In each entry I will explore the basic idea, why I tried it, what design considerations I made, and why I considered it a failure. I will also link or will embed the source code for others to experiment upon with attribution under the GNU general public license.



This Christmas I received a rather unexpected gift – an LED lightbulb with a built in bluetooth speaker. Up until this point I had been extremely skeptical of bluetooth technology. I’d dabbled with bluetooth headsets back when I was working a *people-job in Hoboken, New Jersey. I liked the idea of being able to make calls and handle business on the road without immediately handing $100 to the nearest state trooper, but south of the Mason Dixon this was hardly a concern. Further, the audio was sub-par on every headset I’d ever tried. Likewise, keeping track of a $50, acorn sized gadget and its respective charger is a talent that I will never have. But, here I was with this speaker.

Lightbulb speakers have some pretty obvious advantages, namely singing in the shower sans electrocution and keeping unobtrusive tunes in far flung places. There was something interesting about this unit though, some potential that eluded easy recognition. One trend I’ve observed in recent years is the ways in which robust technologies have distinguished themselves by their constraints. Every laptop I ever bought was the result of a careful tug of war between price and power. Yet when I picked up my first Chromebook a flaw in this logic asserted itself – the lack of extraneous features is an extremely desirable feature in its own right. Rather than lugging a heavy dinosaur and awaiting its inevitable heat death, this tiny, passively-cooled laptop with the heart of a cellphone proved infinitely more practical. Sporting a streamlined operating system that does far less, it proved vastly more proficient at the few tasks it was designed for. I had the same observation with my Chromecast whence compared to a virus laden Rockchip 3188 Android HDMI stick purchased around the same window. Reductionist design is something Google does quite well.


Points of interest

Assessing the light-bulb, its primary task is obvious, relaying content audibly. With the rise of Alexa and various home use surveillance AIs, it has become clear that something useful is occurring in this space. The technologies of speech recognition and speech generation have finally hit suitable levels of utility. Further, as we all carry candy crushing/ infinite knowledge machines in our pockets, there is little utility in wasting amps and volts on further visual renditions of data in our homes. Surveying the various home automation projects on Hackaday and Instructables, it became clear there was a journey-more-important-than-destination thing going on here.

So, what else does a bluetooth light bulb tell you? It tells you and you alone, for the most part, that the light has been turned on. This is advantageous for those unwilling to participate in the latest bot net. By scanning for bluetooth mac addresses, one may quickly surmise the power states of various gadgets and the occupancy of various rooms throughout the house. Living in a modest apartment, this information is available with a quick glance. However, having this information accessible via python is a different beast altogether.


A light bulb goes off

One piece of information that I desire frequently yet digest slowly is the weather. Mountain weather is often unpredictable with brisk nighttime lows in the cooler months and a lingering threat of sudden, violent storms any summer afternoon. So, what if I could have a script that would detect the weather and create a detail dense, plain english summary of the present conditions, the conditions three hours from now, and the manner in which they differ. As my luxurious apartment lacks the customary, noisy-by-design bathroom fan, what if the same script could fade in music? This would save the occasional guest running the sink and would make mother nature cry a little less. By crafting a framework for detecting stimuli and responding to events I could start a whole host of applications for further development. The mind races…


A calm before the storm

The first task was getting the speech generation script going. Forecasts were pulled from a Dark Sky python api and converted to MP3 via the Google text to speech api. This was easy and ran almost immediately on my chromebook. Second was setting up the automation. I created what I called senses, memories, and actions. Senses were a dictionary of lambda functions which return an integer value. Memories were a dictionary of slow scrolling, fixed length vectors of previous measurements from the senses. Finally, actions were a dictionary of paired tests and responses. If a given test applied to the memories from senses returned true, its corresponding action would be performed. All was well so far.

The next step was connecting to bluetooth. This could easily be done via the OS but raised immediate issues per design intent. Bluetooth is generally intended for stable pairings and most phone and PC connection managers reflect this. Once paired with a reciever, both ChromeOS and Raspbian were reluctant to let go of the little lightbulb that could. Tests under this setup worked perfectly, the device could detect when the lightbulb was turned on, give the weather, play its music, and terminate when no longer needed. Unfortunately, the Raspberry Pi appointed to this task connected to the speaker faster than any user could. This would be the end of all shower music, and this simply could not be.


The fail

This was when things fell apart. Kludged iterations of stack overflow solutions were fruitlessly rendered, a thousand monkeys banged out nonsense on a thousand typewriters, and the bluetooth could not hear the bluetoother. The media centre could not hold.

In order to preserve the ability to connect other devices to the speaker I would need to program in a delay in establishing connections. To do this I would have to use python to fully override and duplicate the normal function of the bluetooth audio connection process with slightly different behaviors. Raspberry Pi software is a hack held together by a vast network of hacks on hacker-friendly hardware. When it works it’s beautiful, but a hobbyist such as myself may only build but so much on uneven ground before it collapses. A solution was crafted which scanned every 30 seconds for devices using bjarkan, paired and connected with the speaker when detected, connected VLC pulse audio playback to a bluetooth sink, played the requisite sounds, and terminated, returning everything to its prior state once the lights were off. It worked, briefly, but an attempt to fix a periodic instability led to an ill-advised sudo apt update; sudo apt upgrade. With this the jenga tower collapsed alongside my will to finish the project.


The lesson

It’s hard to know when one is astride a sinking ship. Given the hours upon hours spent debugging this script, perhaps a single hour more could have redeemed the effort? I came at it another time or two with a fresh mind, hoping to glean some new insight but to no avail. The problem was not so much the code. It did function exactly as intended a few times and responded correctly to all intended cases during testing. The problem was my understanding and configuration of the underlying dependencies. Perhaps I could have succeeded in one goal outside of my experience or comfort zone, but several interrelating goals was a different matter altogether. Further, most of the tutorials found had little relevance to my specific hardware configuration. Raspberry pis are common and affordable and Raspbian remains the go-to operating system for them. However, I cannot imagine Raspbian has reached anywhere near the install base of Ubuntu on x86 processors. There’s something to be said for community support.

Every time a fellow hobby/ science geek tells me about the exciting new hardware + niche OS combo they’re fiddling with, I sit back and pour myself a nice tall glass of schadenfreude, because there’s only but so many ways their story will end. As for this story? Well, maybe one day it’ll move to the top of the procrastination pile? Maybe I’ll even post it to stack overflow or hackaday for more qualified assistance. Until then, feel free to gaze upon this monument to failure.

Source jupyter notebook:


*with a people salary