Jekyll2023-03-21T16:43:56+00:00/feed.xmlProject logs and notes.Calle Laakkonen2022-05-09T19:20:00+00:002022-05-09T19:20:00+00:00/2022/05/09/aqara-srsc-m01Calle Laakkonen

Motorized blinds are possibly my favorite home automation products. The ones from IKEA are good but come only in a few sizes. For custom lengths, a tubular motor inserted into the roller shade is the solution. Aqara SRSC-M01 The Aqara roller shade controller is a Zigbee connected tubular motor. There is also the E1 model for automating existing shades with a beaded cord but for new installations the tubular motor should be quieter, stronger, and more discreet. It’s also mains powered, which may be a hurdle, but means no worrying about the battery. This is important for my use case, as the blinds are located in a hard to reach place. Included in the box is the motor itself, a controller, a clip and a couple of cotter pins for securing parts. Most importantly, the parts needed to fit the motor inside the tube are not included. Unfortunately for me, none of the curtain stores I visited carried compatible fittings, so it was time to improvise. The needed extra parts are: The runner: this is the part that attaches to the motor spindle and turns the tube The crown: this goes on the other end to support the motor and keep it centered in the tube. It goes over a freely spinning segment that rotates while the main motor body remains still Wall bracket The motor itself has a diameter of 35mm, so I’m not sure if it fits inside a common 38mm tube. To be safe, I went for the next bigger size: 51mm. I designed the runner and crown in OpenSCAD and printed them out of PLA plastic. PLA is not ideal for this use case but it’s what I had at the moment. I may need to reprint these in something like PETG in the future but time will tell. The square peg on the static end of the motor didn’t fit the round hole in the wall brackets I got, so I had a few options: modify the bracket, modify the motor (the peg is detachable and could be replaced with something else,) or print an adapter. I decided to go for the last option.   The part seems sturdy enough but I’m a bit concerned about its longetivity. I put a loop of wire through the hole where a retaining pin would normally go so the whole thing won’t come falling down in case the plastic fails. I’ll probably remake this part in the future. Setup and Home Assistant The pairing procedure is not described in the manual but is quite simple: Permit joining in Zigbee2mqtt dashboard Hold down the reset button on the bottom side of the controller until the blue light lights up Let go of the controller reset button. The light should start blinking to indicate the device is in pairing mode. You should soon see log messages on the dashboard to indicate the device has joined the network and it should appear in the list Another setup task that must be done before everything works properly is to set the up and down positions and possibly swap the directions. This is done with the buttons on the control box. The exact procedure is described in the manual. With the setup complete, the shades can be automated as usual in Home Assistant. I’ve listed some of the automations I use below. Automation: open when bedroom blinds are opened If my bedroom door is open, I don’t want to be woken up by the sun shining in prematurely, so the hallway blinds should follow the bedroom’s schedule, manual opening included. mode: single trigger: - platform: state entity_id: - cover.bedroom to: 'open' condition: [] action: - service: cover.open_cover data: {} target: entity_id: cover.hallway Automation: open only halfway when the sun is shining in and it’s hot inside (Under construction) Automation: close at sunset for privacy Very basic automation: close the curtains when the sun goes down or when I explicitly turn on night mode. mode: single trigger: - platform: sun event: sunset offset: 0 - platform: state entity_id: - input_boolean.night_mode to: 'on' condition: [] action: - service: cover.close_cover data: {} target: entity_id: cover.hallway

2021-07-16T13:30:00+00:002021-07-16T13:30:00+00:00/2021/07/16/shelly-rgbw2Calle Laakkonen

I needed (wanted) a floor lamp for my bedside that provides a bright indirect light for late night reading. There’s a rather nice looking one in the Philips Hue line but it’s rather expensive and (as of this writing) out of stock everywhere. So, I decided to make my own. Hardware The design is as simple as it gets: a heavy base with an aluminum LED profile sticking up. I made the base from a piece of ⌀90mm steel round stock I had lying around and screwed in a Paulmann Delta aluminum LED profile. The LED strips (2x 1.3 meter strips) are 24V 19 W/meter adjustable color temperature strips. To control it, I used a Shelly RGBW2 module. To make it look pretty, I 3D printed a case to hide the steel base and to hold the Shelly. I’m not sure if the metal part was completely necessary; I might have gotten away with just a 3D print but this at least feels a bit sturdier and less likely to tip over. I’m currently using a 36W power supply, which is not enough. The maximum consumption of the two strips is ~50W, but (theoretically) only half of the LEDs should be at full power at any given time, so a 36 Watt transformer should be enough. In practice, it’s not. When near the midway point between the two color temperature extremes, the strips consume just enough power to trip the overcurrent limit. Software Now, the interesting part. Shellies come with rather nice stock firmware with comprehensive support for local control using HTTP, COAP and MQTT. However, the RGBW2’s default firmware only supports two types of lights: an RGBW lamp or four individual lamps. Since I’m controlling this lamp with Home Assistant, I could have just exported the warm-white and cold-white channels as individual lights and wrapped them in a template light, but I thought it would be much neater if the device would export a single temperature adjustable light entity. Enter ESPHome. ESPHome is a framework for generating custom firmwares for ESP8266/ESP32 based devices, which includes most of the cheap Wifi operated smart lights and plugs on the market at the moment. So, let’s write down all the features we want: Wifi with captive portal for setup Over-the-air updates Adjustable color temperature LED strip control Button for toggling the light on/off (in the end, I didn’t bother adding this, since I always just use the HA app or Google Assistant.) An ESPHome configuration for the Shelly RGBW2 might look like this: esphome: name: my-rgbw2-lamp platform: ESP8266 board: esp01_1m # Enable logging logger: # Enable Home Assistant API api: password: "" ota: password: "" wifi: ssid: "MyWifi" password: "MyWifiPassword" # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Fallback Hotspot" password: "" captive_portal: status_led: pin: number: 2 inverted: true output: - platform: esp8266_pwm pin: 4 frequency: 1000 Hz id: pwm_w - platform: esp8266_pwm pin: 14 frequency: 1000 Hz id: pwm_b light: - platform: cwww name: "My RGBW2 Light" id: cwww_light cold_white: pwm_b warm_white: pwm_w cold_white_color_temperature: 6500 K warm_white_color_temperature: 2300 K constant_brightness: true # TODO this is the power meter. It reads the voltage difference from a shunt # resistor. Knowing the input voltage, we can calculate the power from this. sensor: - platform: adc id: voltage_analog_reading pin: A0 name: Voltage unit_of_measurement: V icon: mdi:flash-circle update_interval: 10s binary_sensor: # This is the external switch input - platform: gpio pin: 5 internal: true id: button filters: - delayed_on: 100ms on_press: - light.toggle: cwww_light # This is the built-in reset button. - platform: gpio pin: 13 internal: true id: resetbtn filters: - delayed_on: 100ms on_press: - light.turn_off: cwww_light Flashing the custom firmware Flashing the firmware can be done in two ways: by connecting to the exposed serial port header on the device itself or over the air. Since the header on the RGBW2 is not the usual 2.54mm pitch header and I don’t happen to have a suitable connector, I decided to try the OTA method first. This is done by first flashing Tasmota, using https://github.com/yaourdt/mgos-to-tasmota. Afterwards, Tasmota’s own OTA update method can be used to install the ESPHome firmware. Unfortunately, for whatever reason I was unable to get this method to work. The mgos-to-tasmota got onto the shelly, it even connected to the Wifi, but just appeared to sit there. In the end, I had to resort to using the serial port. The pin header is too small for regular dupont jumper wires to fit (some workaround ideas here), but I managed to get them in by filing the jumper pins down a bit. Then it was simply a matter of flashing Esphome in the usual manner. Afterwards, the firmware can be updated over-the-air. This can be done easily with the Esphome dashboard, which can be installed as a Home Assistant add-on. You can modify the firmware and observe logging output of your devices straight from HA!

2021-01-26T18:00:00+00:002021-01-26T18:00:00+00:00/2021/01/26/liberating-nedis-smartplugCalle Laakkonen

With the weather getting cold, I thought it would be nice to have a remote controlled outdoor plug so I could start my car heater from the comfort of the warm indoors. A Nedis SmartLife Wifi outdoor socket found at a local department store looked just right for the task. Like most Wifi smart plugs, it’s made by Tuya. Using the stock firmware with its cloud dependency was not acceptable to me, but luckily Tuya devices are easy to flash with open source firmware, like Tasmota or ESPHome… Or so it seemed. In any case, the device was cheap enough that I was willing to risk bricking it just for the experience. First, I tried Tuya-Convert, a program that emulates the manufacturer’s cloud and lets you slip in your own firmware as an OTA update. I installed the software on a Raspberry Pi 2 with a Wifi stick and followed the instructions. Pressing down the button on the plug for a few seconds until the LED starts blinking puts it into “quick setup” mode where it connects to the access point created by Tuya-Convert. So far so good, I could see a connection attempt in the smarthack-wifi.log file. However, the firmware update would not proceed. Looking at smarthack-psk.log file revealed a problem. The smart plug uses a new version of the firmware with better security so it can’t be intercepted by Tuya-convert (yet, anyway.) The Nedis plug is actually included in the list of devices known to have this problem, so I should have done better research before buying. Oh well. If OTA update was not an option, I could still do it the old fashioned way by opening the case and directly connecting a serial cable. Next problem: tri-wing screws. The manufacturer really doesn’t want users tampering with the device so instead of usual philips or torx screws, it has tri-wing. And not only that, they are pretty deep, so a regular hardware store security bit set won’t reach. Luckily, I found a set of extra-long tri-wing bits from Amazon that wasn’t too expensive. (The correct size appears to be tri-wing 1. Tri-wing 0 is often used in mobile phones and game consoles.) With the screws removed, the case could be twisted open with some force. Inside, the Wifi module is a TYWE3S. Luckily, the pins needed for flashing are not only already broken out, but labeled! I assume this is for ease of programming at the factory using a pogo pin jig. I could probably 3D print a jig, but since I only need to flash one device, simply soldering jumper wires onto the pads is easier. I used a common USB-serial adapter to connect to the board. GND to GND, 3.3V to 3.3V (had to be extra careful here, my adapter has both 3.3V and 5V power pins.), RX to TX and TX to RX. Note that the Wifi board in the plug receives all the power it needs from the USB adapter. It should not be plugged into the wall when doing this! IO0 should be connected to GND before the board is powered up to put the bootloader into flashing mode. (There is no need to solder a wire to IO0, pressing the onboard button does the same thing.) I downloaded Tasmotizer, plugged the USB adapter in and hit the flash button. And, surprise, it just worked! After restarting the device once, it appeared as a new Wifi access point. I connected my phone and visited the default IP (192.168.4.1) and filled in my home Wifi details. Unlike ESPHome, where you write a configuration file and generate a custom firmware, Tasmota is a “one size fits all” firmware that is configured at runtime by assigning components to the GPIO pins. Luckily, there is already a Tasmota template for this device, so configuring it was just a matter of copy&pasting the template in. For reference, the following components are connected to the Wifi board: GPIO0: Button GPIO04: HLW8012 CF GPIO05: HLW8012 CF1 GPIO12: HLW8012 select (inverted) GPIO13: Status LED (inverted) GPIO14: Relay The HLW8012 is a power meter chip. At least for me, it appears to work well enough without any calibration. (Tip: the command TelePeriod controls how often measurement data is pushed to MQTT. The default value is 300 seconds.) After setting the template, the plug appeared to be fully operational: clicking on the toggle button on the admin UI switched the relay on and off, as did pushing the physical button. Finally, I just needed to link it into Home Assistant. This turned out to be very easy: I just had to set my MQTT server’s address and password. Home Assistant automatically detected the new device and offered to activate the Tasmota integration. With the integration enabled, the plug appeared as a device with entities for power metering and the relay itself. Very nice. In summary, I did get the Nedis outdoor wifi plug reflashed with Tasmota, but it wasn’t as easy as I had hoped. Was it worth it? As an experience, sure. Soldering wires to reflash a device makes one feel like a real hacker. However, in the future I’ll stick with companies like Shelly that don’t try to lock you out of your own hardware.

2020-12-12T10:00:00+00:002020-12-12T10:00:00+00:00/2020/12/12/automation-3Calle Laakkonen

This is a continuation of my first post in which I wrote about using Home Assistant together with IKEA TRÅDFRI lights and zigbee2mqtt. The CC2531 based adapter I was using turned out to be too weak to reliably handle a network with about 30 devices on it (but it did work very well with smaller networks,) so I had to move all the lights back to the TRÅDFRI gateway. Some months ago I bought a zig-a-zig-ah!,a CC2652R based adapter, which can handle larger networks and I’ve transferred all the TRÅDFRI lights (and curtains) onto it. So far, it has been working well with no devices mysteriously dropping out like happened with the previous stick. Here are my revised notes on how to set up TRÅDFRI lights with their remote controls with zigbee2mqtt. Pairing lights and remotes to zigbee2mqtt Pair the lamp by first enabling pairing in zigbee2mqtt, then toggling the lamp on and off a few times quickly. The light will start pulsing to indicate it’s in pairing mode. (Check the supported devices page for device specific instructions.) Note: If there is more than one bulb in the fixture, unscrew the others and pair them one at a time. The process does not seem to work reliably if you try to pair more than one device at a time. You should see something like this in the MQTT topic zigbee2mqtt/bridge/log: { "type": "device_connected", "message": { "friendly_name": "0x14b457fffe9191cb" } } { "type": "pairing", "message": "interview_started", "meta": { "friendly_name": "0x14b457fffe9191cb" } } { "type": "device_announced", "message": "announce", "meta": { "friendly_name": "0x14b457fffe9191cb" } } { "type": "pairing", "message": "interview_successful", "meta": { "friendly_name": "0x14b457fffe9191cb", "model": "LED1732G11", "vendor": "IKEA", "description": "TRADFRI LED bulb E27 1000 lumen, dimmable, white spectrum, opal white", "supported": true } } That final interview_successful message indicates the pairing completed successfully. The default friendly name (the name used as the MQTT topic for the device) is the device’s MAC address. It’s a good idea to rename it to something descriptive: Topic: zigbee2mqtt/bridge/config/rename Payload: { "old": "0x14b457fffe9191cb", "new": "ceiling_light" } To use the light with a remote control, adding it to a group appears to be necessary. Edit: The firmware on newer remotes has changed. It seems that they no longer support groups, but can be bound to more than one individual device. Create a new group with: Topic: zigbee2mqtt/bridge/config/add_group Payload: { "friendly_name": "GROUP_FRIENDLY_NAME" } Then add the light(s) to the group Topic: zigbee2mqtt/bridge/group/GROUP_FRIENDLY_NAME/add Payload: LIGHT_FRIENDLY_NAME Pair a remote by opening the back cover and clicking the reset button quickly four times. You should see something like this in the log topic: { "type": "pairing", "message": "interview_successful", "meta": { "friendly_name": "0xccccccfffe6cddd7", "model": "E1524/E1810", "vendor": "IKEA", "description": "TRADFRI remote control", "supported": true } } For some reason, the remotes can be a bit tricky to pair, with the interview failing multiple times before it goes through, especially if low on battery. Rename remote the same was as the light above. I like to attach a little name sticker to the back cover to identify them. Edit: the following info may be obsolete. It appears that newer remotes (or ones upgraded to the latest firmware) must be bound to individual devices rather than groups. Next, the remote must be bound to the group. The IKEA remotes are bound to a random group by by default, so we need to unbind it first for everything to work right: Topic: zigbee2mqtt/bridge/unbind/REMOTE_FRIENDLY_NAME Payload: default_bind_group Note: Click remote button just before sending this message to ensure the remote wakes up to receive it. Now the remote can be bound the our own group: Topic: zigbee2mqtt/bridge/bind/REMOTE_FRIENDLY_NAME Payload: GROUP_FRIENDLY_NAME The remote should now be able to control the light(s), even without the coordinator! Pairing the FYRTUR curtains (and binding its remote) is done the same way as the lights. Light groups in Home Assistant Edit: As of Zigbee2mqtt version 1.20, this section is obsolete. Light groups now work without any manual configuration. A light group is a group of lights that act like a single device. Useful when you have a light fixture that holds multiple bulbs. First of all, add this line to your HA configuration.yaml file so you can configure the lights in a separate file. This will make the configuration file cleaner if you have lots. light: !include lights.yaml Light groups can be defined in two different ways. You can use the group platform to group together any light entities. This is (currently) the only way of creating light groups when using the TRÅDFRI gateway, since it only exposes individual lights: - platform: group name: Ceiling light fixture entities: - light.lamp1 - light.lamp2 However, zigbee2mqtt exposes topics for directly controlling a zigbee group. It does not publish an autodiscovery message for Home Assistant, so you will need to configure it manually (see also the official documentation) by putting something like this in your lights.yaml file: - platform: mqtt schema: json name: "HOME ASSISTANT NAME" command_topic: "zigbee2mqtt/GROUP_NAME/set" state_topic: "zigbee2mqtt/GROUP_NAME" availability_topic: "zigbee2mqtt/bridge/state" color_temp: true brightness: true The name: key will set the name with which this group will appear in Home Assistant. The group’s zigbee2mqtt friendly-name is used in the topics. Features supported by the bulbs must be specified: color_temp, rgb and brightness.

2020-06-13T08:11:00+00:002020-06-13T08:11:00+00:00/2020/06/13/automation-2Calle Laakkonen

Previously, I wrote about getting started with home automation using TRÅDFRI lights and Home Assistant. The cool thing about Home Assistant is that it lets you mix and match devices from different manufacturers, even things you build yourself. The easiest way (IMO) to integrate a custom device into Home Assistant is to use the MQTT protocol. MQTT is a simple and lightweight pub-sub protocol especially useful for IoT devices. Home Assistant has first class support for it and can run the Mosquitto MQTT broker as an add-on. The goal of this project is to retrofit an existing battery operated doorbell into a smart IoT doorbell that integrates with Home Assistant. This will make it possible to trigger automations when the doorbell is pressed, such as sending a message to my phone if I’m not home. Building the doorbell I decided to reuse my old doorbell, a simple battery powered chime. When the button is pressed, the battery is connected to the solenoid, causing the plunger to hit the chime and make the “ding-dong” noise. The physical button can be replaced with a transistor to connect power to the solenoid. The IoT part is handled by a NodeMCU, programmed using the Arduino IDE. The NodeMCU connects to my Wifi and the MQTT broker running on the Raspberry Pi. Presently, all settings are hardcoded into the firmware, which means I will need to reflash it when I change my Wifi password. This is something that could be improved later. An alternative would be to use ESPHome, which provides handy features out of the box, such as OTA updates and a web configuration interface. I might give this a try in the future. You can find the source code and a more detailed description of the hardware at my smart-doorbell repository. To better hold the extra components, I also 3D printed a new case for the doorbell. MQTT and Home Assistant The interesting part of the smart doorbell is how it uses the MQTT protocol to integrate with Home Assistant. A quick summary of salient MQTT features: MQTT clients connect to a broker Clients can publish messages which will be received by other connected clients. A message has a topic and a payload A message can be tagged as retained, in which case the broker will keep a copy and automatically send it to all clients who subscribe to its topic. (Only the latest retained message per topic is kept) Clients can subscribe to specific topics to receive messages they’re interested in A client can register a “last will and testament” message that the broker will publish on its behalf upon disconnection Basically, the smart doorbell needs to do just one thing: publish a message on some topic when the button is pressed (and also ring the bell.) Any topic can be used, but its a good idea to give it some structure, like: diy/frontdoor/button The diy part is what I’ll use as a namespace for all my home-made devices. The second part (frontdoor) identifies the device. On a mass produced product, this might be the MAC address or some other unique identifier. The final part (button) indicates which feature of the device the message is related to. The doorbell isn’t just a doorbell: it also has a reed switch for detecting if the door is open, so I need to distinguish between button and door messages. (In Home Assistant terms, the doorbell device has two entities: the button and the door sensor.) When the button is pressed, a message with the payload “press” is published on the above topic. Also, when the state of the door sensor changes,either “open” or “closed” is published at diy/frontdoor/door. Now, this is enough. It’s possible to create a device in Home Assistant’s configuration to get the status of the doorbell. The button press event can then be used in automations to do things like send a text notification. However, there’s a better way. A device can publish special messages for Home Assistant to automatically discover it. MQTT Discovery To enable automatic discovery of MQTT devices, we can publish messages that contain the same info that would be written in the configuration file. The MQTT Discovery page lists the types of entities supported by Home Assistant. My doorbell exposes two entities: the button and the door sensor. The button is exposed as a Device Trigger. This makes it show up in the Automations editor. Topic: homeassistant/device_automation/frontdoor/button_short_press/config Payload: { "device": { "identifiers": "frontdoor", "manufacturer": "DIY", "model": "Smart Doorbell", "name": "Doorbell" }, "availability_topic": "diy/doorbell/available", "topic": "diy/frontdoor/button", "automation_type": "trigger", "type": "button_short_press", "subtype": "button1", "payload": "press" } The device object makes the physical device show up in Home Assistant’s Devices list. The availability_topic is where the state (online or offline) of the device is published. More on that below. The topic is the MQTT topic where the button press will be announced. The payload field contains the value that identifies this device automation. Multiple types of device trigger could be published, like button_double_press or button_long_press. The door sensor is published using the Binary Sensor entity type: Topic: homeassistant/binary_sensor/frontdoor/door/config Payload: { "device": { "identifiers": "frontdoor", "manufacturer": "DIY", "model": "Smart Doorbell", "name": "Doorbell" }, "availability_topic": "diy/doorbell/available", "topic": "diy/frontdoor/door", "device_class": "door", "name": "Door", "unique_id": "frontdoor_door", "payload_on": "open", "payload_off": "closed" } The device_class tells Home Assistant what icon to use for this entity. A binary sensor has an on and off state, so we need to tell it which payload string means which. These configuration messages are published with the retained flag set, so Home Assistant will receive them even if it is (re)started after the device has connected to the broker. To let Home Assistant know the device is online, we’ll publish the retained message online at the availability_topic. We also register the last-will message offline to be published at the same topic. This way, when the doorbell goes offline for any reason, Home Assistant will know about it. Ringing the bell remotely As a final extra feature, I decided to make it possible to ring the bell via MQTT command. The doorbell listens on the topic diy/doorbell/bell. When it receives a message containing a number from 1-9, it will ring the bell the given number of times. There is no entity type for autodiscovering this feature, but we can still use it an automation by using the mqtt.publish service: service: mqtt.publish data: topic: diy/frontdoor/bell payload: "1" MQTT messages can also be published via Node-RED.

2020-06-07T15:58:47+00:002020-06-07T15:58:47+00:00/2020/06/07/home-automation-1Calle Laakkonen

A couple of months ago, I (re)discovered home automation, by way of IKEA automated blinds. With summer approaching and the sun rising earlier and earlier, the IKEA FYRTUR blackout blinds were just what I needed for my bedroom. Naturally, this quickly led me to the other IKEA smart home stuff: their Zigbee controlled smart lights. In short order, I replaced all the lamps in my home with IKEA smart lamps and now, two months and a few learning experiences later, I’m all the more excited about smart home technology. My experience with the IKEA system is mostly positive. The lamps are much cheaper than Philips Hue and the system has one very important feature (or from another perspective, lack of misfeature): No cloud dependency. The lights work completely locally. You don’t even need the hub for the remotes to work: clicking on a light switch sends the message directly to the bulb without looping it through a server in China (or Sweden.) Another important factor was that the TRÅDFRI hub is supported by Home Assistant, a Free/Libre home automation hub that can run on a Raspberry Pi. The IKEA smart home app is fairly barebones by itself, but with Home Assistant, you can do pretty much anything. An extra bonus I discovered while researching the TRÅDFRI ecosystem was that the devices are also supported by Zigbee2mqtt, which means the official gateway is not strictly needed even. The devices make use of Zigbee groups, which allows the remotes to send commands directly to the lamps and blinds without the need for a hub at all. This is awesome, since it means my remote light switches continue to function even if the gateway and Home Assistant are down. (For example, the remotes continued to work right after a brief power outage in the middle of the night rebooted everything in the house and turned all the lights on.)