Check what is there before designing
The request was mine: when the washer or dryer finishes, tell us on the television, since that is where we usually are. The first plan was to do it inside the appliance maker's own app, on the assumption that everything in the house was the same brand.
It was not. The app can only put messages on televisions of its own brand, and neither of the two screens I cared about qualified. One look at the inventory of what the house actually contained changed the approach from "configure an app" to "route it through our own automation system". It took two minutes and saved an afternoon of configuring the wrong thing.
The working version I threw away
The first build spoke the announcement through the television, and it worked. I heard it. Then I asked for the thing I had wanted all along without saying so: the message should go away after thirty seconds and leave the video alone.
A spoken message sent to that television stops the video, and the video does not come back. So the working version was the wrong version. We switched to a banner that appears over whatever is playing and times out by itself, and the spoken automation was disabled on the spot so that it could not fire in the meantime.
The first version that works is not the requirement. The requirement turns up when someone uses it.
Nothing was listening
The banner needs a small helper app on the television. The first attempts to reach it failed with a connection error. There were many things that could have been adjusted at that point. Instead we asked one narrow question: is anything listening at that address? Nothing was. Then a wider one: is anything listening for this, anywhere on the home network? Nothing was.
The helper app had never been installed on that television. The download I remembered had gone to a different device. Once it was installed and opened, the connection worked the first time. A test banner appeared over a playing video; I asked for it to move from the bottom corner to the top, and we tested it again there. Only then was the real automation switched on, explicitly, because reloading the settings does not undo an earlier "off".
Voice came back, in the right room
A few days later the spoken announcement returned, this time on the voice assistant in a room that has its own speaker and no video to interrupt. That one stayed.
We also tried the obvious next step: starting the machines by voice. It was built, and the first test failed. The machines only accept a remote start if someone has armed it at the machine, for that load, with the door shut. If I have to be standing at the dryer to allow a voice command, the dial is already under my hand. The feature saved nothing, so it was removed cleanly the same day.
The doorbell that could listen but not talk
The doorbell had a "Listen" button on our dashboard that was supposed to give two-way audio. It never really had. The camera itself was capable of it. The button opened a page that only worked inside the house and that a phone would not trust with its microphone.
Before adding anything new, we checked what was already installed. The camera view we were already using has a talk button built in; it had simply never been connected. Push-to-talk went out to both our phones, an iPhone and an Android, at home or away, with nothing new installed and nothing restarted.
What I took from it
- Verify what is actually installed before designing around it.
- Ask the narrowest question that can fail. "Is anything listening?" beats an hour of adjusting settings.
- A feature that saves nobody anything should be removed, even after it has been built.
- Look at what you already have before installing something new.
"The house shelters daydreaming, the house protects the dreamer, the house allows one to dream in peace."
Previous: Twenty times fasterNext: The quietly rotting index