Smart Devices Aren't (or why connected devices suck)
- Comments:
- here.
I love tinkering with gadgets. I’ve put a bunch of sensors around my house, so I can see the temperature in various places, and have a couple of smart light and power devices too. At the moment, they are limited to my laundry (where the hard-wired switch is in the wrong place, due to the moving of a door), my workbench (because the overhead lights there run from a power point, so it was trivial to put in a smart switch), and the lounge room (where I had room in the light fitting to put a Sonoff Mini).
In all of these cases, with the exception of the Laundry, since the switch is not really accessible, I have taken great care to ensure that the physical switches still toggle the light. In that case I have an Ikea bulb connected to an Ikea dimmer.
In my study, I have a desk lamp that has a smart (dimmable) bulb in it, and it irks me no end that I have to use a smart device or computer to turn it on or off. I will be getting some more of the Ikea dimmers to alleviate this, but in the mean time, it’s a pain to turn on or off.
Having said that, I love the option of being able to automate power and lighting, or turn things off from a distance. I just don’t like that being the only way.
I installed Home Assistant on the weekend. But, in order to fit that onto my Raspberry Pi, I needed to use a bigger Micro SD card.
Which meant I needed to clone the old one.
Which took several hours.
I’d already installed Home Assistant before running out of space, and had converted a couple of my esphome devices to use the API instead of just MQTT for connection, including the lounge room light.
Now, it turns out, by default there is an “auto reboot if API not found in 15 minutes” setting, which meant that during the four or five hours it took to create an image of the Micro SD, verify this, copy to a new SD card, and then verify that, my lights (and a powerboard in my office) would flick off every 15 minutes. Likewise, if they cannot connect to a WiFi access point they will power cycle. I believe this second one can be resolved using a Captive AP setting that will mean if they can’t connect to a network, they will create their own.
Which really got me thinking. Smart devices should continue to work in every way possible when they don’t have access to the local network, or the internet. In my case, my smart devices do not have access to the internet anyway, because they don’t need to. However, the point is the same.
In situations where a network connection, or even worse, a working connection to a server that you don’t control, is no longer available, you dont’ want your lights or god forbid, your coffee machine to not be able to perform their simple task.
This worries me somewhat about the current trends in smart homes. At some point, companies will stop supporting their devices (this has already happened), and they will become less useful than their dumb counterparts. And add further to our global waste problems.
But having a significant system outage (even an intentional one, like in my case), made me think about other aspects of my home automation as well.
I’ve been using NodeRED for a couple of automation tasks. One of them was to have different grind lengths for my coffee grinder, and making this available to Siri.
However, with the device running NodeRED not operating, I was no longer able to rely on this.
I was heading this way philosophically before, but (OMG NO COFFEE) this just cemented something else in my mind. Automations, where they don’t rely on interaction between multiple devices, should live on the local device where possible. Further to this, where the interaction between devices is required for the automation (like the PIR sensor in the laundry I have that turns on the Ikea lightbulb), the devices should connect directly to one another, without requiring some other mechanism to trigger the automation.
In my case, I have a physical button that I press to trigger a long grind. But, the grind only stops if the NodeRED server tells it to. And, I had no way to (when NodeRED was not running), trigger a short grind.
I was able to fix this: I now have a short press triggering a long grind, and a long press triggering a short grind. That seems backwards, but since I mostly do a long grind in the morning before I’ve had time to properly wake up, I want that the easiest one to trigger…
Having to program this in my esphome firmware instead of NodeRED made for an interesting exercise. Because we need to turn off the device after a period of time, but need to be aware of other events that have happened in the meantime, we need to use scripts.
script:
- id: short_grind
then:
- switch.turn_on: relay
- delay: 13s
- switch.turn_off: relay
- id: long_grind
then:
- switch.turn_on: relay
- delay: 17s
- switch.turn_off: relay
Whenever our relay turns on, we want to start our long grind script, so that even if the relay was triggered some other way than through the script, it will turn off after 17s if not before. Whenever it turns off, we want to stop any instances of our scripts running. We can also use Template Switches to have logical devices we can use to trigger the different scripts, either from Home Assistant, or from button presses:
switch:
- platform: gpio
id: relay
pin: GPIO2
restore_mode: ALWAYS_OFF
on_turn_on:
- script.execute: long_grind
on_turn_off:
- script.stop: short_grind
- script.stop: long_grind
- platform: template
name: "Grind a Single"
optimistic: true
id: grind_a_single
icon: mdi:coffee-outline
turn_on_action:
- script.execute: short_grind
- script.wait: short_grind
- switch.template.publish:
id: grind_a_single
state: OFF
turn_off_action:
- switch.turn_off: relay
- platform: template
name: "Grind a Double"
optimistic: true
id: grind_a_double
icon: mdi:coffee
turn_on_action:
- script.execute: long_grind
- script.wait: long_grind
- switch.template.publish:
id: grind_a_double
state: OFF
turn_off_action:
- switch.turn_off: relay
Both of these template switches will also turn off the grinder when toggled off if they are currently on.
There’s only one more bit of logic that’s required, and that’s the handling of the physical button. I wanted this to trigger either length based on the amount of time that the button is held down for, but I also want a UX affordance of knowing when you have held it down long enough to trigger the alternate action. Finally, if it’s on, any type of press should turn it off, and not trigger a new grind.
binary_sensor:
- platform: gpio
pin:
number: GPIO14
inverted: true
mode: INPUT_PULLUP
on_press:
- light.turn_on:
id: led
transition_length: 0s
- delay: 500ms
- light.turn_off:
id: led
transition_length: 0s
on_click:
- max_length: 350ms
then:
- if:
condition:
- switch.is_on: relay
then:
- switch.is_off: relay
else:
- script.execute: long_grind
- min_length: 500ms
max_length: 2s
then:
- if:
condition:
- switch.is_on: relay
then:
- switch.is_off: relay
else:
- script.execute: short_grind
Remember that the turning off of the relay will stop any running scripts.
So, now, when you hold down the button, when the light turns off, you can release it and it will trigger a short grind. If you just tap the switch and release it immediately, it will trigger a long grind. Any button press when the grinder is already running will turn it off.
