Our house has roller shutters on all windows and most of them have an electric motor to open and close them. The motors are Schellenberg shaft motors (not sure this is the right English term), that you can configure end positions for and then by applying current to the right pair of pins they move the shutters up and down until the current is removed or one of the endstops is reached. As the motors were installed over a long period of time, the attached control units varied in functionality: different ways to program open/close times, with and without battery for the clock/settings etc, but they all had something in common: no central management and pretty ugly. We decided to replace those control units with regular 2 gang light switches that match the other switches in the house. And as we didn't want to lose the automatic open/close timer, we had to add some smarts to it.
Shelly 2.5 and ESPHome
Say hello to
Shelly 2.5! The Shelly 2.5 is an ESP8266 with two relays attached to it in a super tiny package you can hide in the wall behind a regular switch. Pretty nifty. It originally comes with a
Mongoose OS based firmware and an own app, but ain't nobody needs that, especially nobody who wants to implement some crude logic. That said, the original firmware isn't bad. It has a no-cloud mode, a REST API and does support MQTT for integration into Home Assistant and others.
My ESP firmware of choice is
ESPHome, which you can flash easily onto a Shelly (no matter 1, 2 or 2.5) using a USB TTL adapter that provides 3.3V. Home Assistant has native ESPHome support with auto-discovery, which is much nicer than manually attaching things to MQTT topics.
To get ESPHome compiled for the Shelly 2.5, we'll need a basic configuration like this:
esphome:
name: shelly25
platform: ESP8266
board: modwifi
arduino_version: 2.4.2
We're using
board: modwifi as the Shelly 2.5 (and all other Shellys) has 2MB flash and the usually recommended
esp01_1m would only use 1MB of that - otherwise the configurations are identical (see the PlatformIO entries for
modwifi and
esp01_1m). And
arduino_version: 2.4.2 is what the Internet suggests is the most stable SDK version, and who will argue with the Internet?!
Now an ESP8266 without network connection is boring, so we add a WiFi configuration:
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
power_save_mode: none
The
!secret commands load the named variables from
secrets.yaml. While testing, I found the network connection of the Shelly very unreliable, especially when placed inside the wall and thus having rather bad bad reception (-75dBm according to ESPHome). However, setting
power_save_mode: none explicitly seems to have fixed this, even if
NONE is supposed to be the default on ESP8266.
At this point the Shelly has a working firmware and WiFi, but does not expose any of its features: no switches, no relays, no power meters.
To fix that we first need to find out the GPIO pins all these are connected to. Thankfully we can basically copy paste the definition from the
Tasmota (another open-source firmware for ESPs)
template:
pin_led1: GPIO0
pin_button1: GPIO2
pin_relay1: GPIO4
pin_switch2n: GPIO5
pin_sda: GPIO12
pin_switch1n: GPIO13
pin_scl: GPIO14
pin_relay2: GPIO15
pin_ade7953: GPIO16
pin_temp: A0
If we place that into the
substitutions section of the ESPHome config, we can use the names everywhere and don't have to remember the pin numbers.
The configuration for the
ADE7953 power sensor and the
NTC temperature sensor are taken verbatim from the ESPHome documentation, so there is no need to repeat them here.
The configuration for the switches and relays are also rather straight forward:
binary_sensor:
- platform: gpio
pin: $ pin_switch1n
name: "Switch #1"
internal: true
id: switch1
- platform: gpio
pin: $ pin_switch2n
name: "Switch #2"
internal: true
id: switch2
switch:
- platform: gpio
pin: $ pin_relay1
name: "Relay #1"
internal: true
id: relay1
interlock: &interlock_group [relay1, relay2]
- platform: gpio
pin: $ pin_relay2
name: "Relay #2"
internal: true
id: relay2
interlock: *interlock_group
All marked as
internal: true, as we don't need them visible in Home Assistant.
ESPHome and Schellenberg roller shutters
Now that we have a working Shelly 2.5 with ESPHome, how do we control Schellenberg (and other) roller shutters with it?
Well, first of all we need to connect the Up and Down wires of the shutter motor to the two relays of the Shelly. And if they would not be marked as
internal: true, they would show up in Home Assistant and we would be able to flip them on and off, moving the shutters. But this would also mean that we need to flip them off each time after use, as while the motor knows when to stop and will do so, applying current to both wires at the same time produces rather
interesting results. So instead of fiddling around with the relays directly, we define a
time-based cover in our configuration:
cover:
- platform: time_based
name: "$ location Rolladen"
id: rolladen
open_action:
- switch.turn_on: relay2
open_duration: $ open_duration
close_action:
- switch.turn_on: relay1
close_duration: $ close_duration
stop_action:
- switch.turn_off: relay1
- switch.turn_off: relay2
We use a time-based cover because that's the easiest thing that will also turn the relays off for us after the shutters have been opened/closed, as the motor does not "report" any state back. We
could use the integrated power meter of the Shelly to turn off when the load falls under a threshold, but I was too lazy and this works just fine as it is.
Next, let's add the physical switches to it. We could just add
on_press automations to the binary GPIO sensors we configured for the two switch inputs the Shelly has. But if you have kids at home, you'll know that they like to press ALL THE THINGS and what could be better than a small kill-switch against small fingers?
switch:
[ previous definitions go here ]
- platform: template
id: block_control
name: "$ location Block Control"
optimistic: true
- platform: template
name: "Move UP"
internal: true
lambda: -
if (id(switch1).state && !id(block_control).state)
return true;
else
return false;
on_turn_on:
then:
cover.open: rolladen
on_turn_off:
then:
cover.stop: rolladen
- platform: template
name: "Move DOWN"
internal: true
lambda: -
if (id(switch2).state && !id(block_control).state)
return true;
else
return false;
on_turn_on:
then:
cover.close: rolladen
on_turn_off:
then:
cover.stop: rolladen
This adds three more
template switches.
The first one, "Block Control", is exposed to Home Assistant, has no
lambda definition and is set to
optimistic: true, which makes is basically a dumb switch that can be flipped at will and the only thing it does is storing the binary on/off state.
The two others are almost identical. The name differs, obviously, and so does the
on_turn_on automation (one triggers the cover to open, the other to close). And the really interesting part is the
lambda that monitors one of the physical switches and if that is turned on,
plus "Block Control" is off, reports the switch as turned on, thus triggering the automation.
With this we can now block the physical switches via Home Assistant, while still being able to control the shutters via the same.
All this (and a bit more) can be found in my
esphome-configs repository on GitHub, enjoy!
A SYNCNI article passed by on my Twitter feed this morning, talking about balancing work life balance while working from home in these times of COVID-19 inspired lock down. The associated Twitter thread expressed an interest in some words of advice from men to other men (because of course the original article has the woman having to do all the balancing).
This post does not contain the words of advice searched for, but it hopefully at least offers some reassurance that if you re finding all of this difficult you re not alone. From talking to others I don t think there s anything particularly special we re doing in this house; a colleague is taking roughly the same approach, and some of the other folk I ve spoken to in the local tech scene seem to be doing likewise.
First, the situation. Like many households both my wife and I work full time. We have a small child (not even a year and a half old yet). I work for a software startup, my wife is an HR business partner for a large multinational, dealing with employees all over the UK and Ireland. We re both luckily able to work from home easily - our day to day work machines are laptops, our employers were already setup with the appropriate VPN / video conferencing etc facilities. Neither of us has seen any decrease in workload since lock down; there are always more features and/or bugs to work on when it comes to a software product, and, as I m sure you can imagine, there has been a lot more activity in the HR sphere over the past 6 weeks as companies try to work out what to do.
On top of this our childcare arrangements, like everyone else s, are completely gone. Nursery understandably shut down around the same time as the schools (slightly later, but not by much) and contact with grandparents is obviously out (which they re finding hard). So we re left with trying to fit 2 full time jobs in with full time childcare, of a child who up until recently tried to go down stairs by continuing to crawl forward.
Make no mistake, this is hard. I know we are exceptionally lucky in our situation, but that doesn t mean we re finding it easy. We ve adopted an approach of splitting the day up. I take the morning slot (previously I would have got up with our son anyway), getting him up and fed while my wife showers. She takes over for a bit while I shower and dress, then I take over again in time for her to take her daily 8am conference call.
My morning is mostly taken up with childcare until nap time; I try to check in first thing to make sure there s nothing urgent, and get a handle on what I might have to work on later in the day. My local team mates know they re more likely to get me late morning and it s better to arrange meetings in the afternoon. Equally I work with a lot of folk on the US West coast, so shifting my hours to be a bit later is not a problem there.
After nap time (which, if we re lucky, takes us to lunch) my wife takes over. As she deals with UK/Ireland folk she often ends up having to take calls even while looking after our son; generally important meetings can be moved to the morning and meetings with folk who understand there might be a lot of pot banging going on in the background can happen in the afternoon.
Having started late I generally work late - past the point where I d normally get home; if I m lucky I pop my head in for bath time, but sometimes it s only for a couple of minutes. We alternate cooking; usually based on work load + meetings. For example tonight I m cooking while my wife catches up on some work after having put our son to bed. Last night I had a few meetings so my wife cooked.
So what s worked for us? Splitting the day means we can plan with our co-workers. We always make sure we eat together in the evening, and that generally is the cut-off point for either of us doing any work. I m less likely to be online in the evening because my study has become the place I work. That means I m not really doing any of my personal projects - this definitely isn t a case of being at home during lock down and having lots of time to achieve new things. It s much more of case of trying to find a sustainable way to get through the current situation, however long it might last.
Due to sickness I was not able to complete my 8 hours of work on Debian LTS as planned. I only worked 1.5 hours this month, moving the remaining 6.5 hours over to May.
LTS
For the foreseeable future I'm working for myself, as a contractor, here in sunny Helsinki, Finland.
My existing contract only requires me to work 1.5-2.0 days a week, meaning my week looks something like this:
The new FAI version 5.9.4 adds support for the new Ubuntu LTS version 20.04 (focal).
New FAI installation images (including a Ubuntu only ISO) are available from
...even the SD cards were wet!
The last photo my camera took before it died
Tada! Turns out you can dehydrate hardware too!
A few days ago KDE Apps 20.04 were released, and I am happy that thanks to the 
The previous location (debian-plasma at OBS) should be replaced by the following entries in 
Troubleshooting mdns issuses. I've noticed that mdns wasn't working on crostini.
It seems like avahi-browse -a returns empty results.
Chrome browser also doesn't seem to resolve .local host names, so that might be related.
My solution up to now was to keep a Unison binary from Buster on my Sid system, and used that binary when syncing to Buster server, but the normal Unison binary when syncing between two sid computers. This created lots of pain, because, when using a incompatible Unison binary, already a simple connect without a sync trial messed up the state files and required a complete resync. And so it happened often that I used the wrong binary, and had to resync a few gigabyte, what a pain.
The Debian maintainer is 