frog32

Fixing a bricked Mi Flora sensor

2022-02-03T22:00:00+01:00

I am using MiFlora sensors from Xiaomi to monitor some of the plants in our apartment. Around 2 years ago one of the sensors got bricked and started to advertise itself as "Dial Test" while turning its LED on permanently. This caused the battery to drain very rapidly making the sensor no longer viable. Some quick research showed that Chris Scheffler was encountering a very similar behavior after he wrote data using the wrong byte order to the device.

Since I did not want to spend a lot of time investigating and tinkering with the sensor I just ordered a new one as they were only around 10$ including shipping back then. This week I had another sensor showing the exact same behavior after the battery died. I spent a bit of time on it and realized that the simplest way to set up an environment to run code to fix this was to log into the container running Home Assistant since it already had all the libraries installed. Turned out it was fairly simple to fix the sensor after all.

To create an interactive python shell using the Home Assistant container on my Home Assistant Blue I am using the following command.

docker exec -it container python3

And this is the code snippet I have used to connect to my sensor and write the magic bytes to reset it which turns the LED off again. Just replace the mac address with your mac address and give it a try.

import btlewrap
from btlewrap.base import BluetoothBackendException, BluetoothInterface

_bt_interface = BluetoothInterface(backend, adapter="hci0")
_HANDLE_WRITE_MODE_CHANGE = 0x33
_RESET_DEVICE = bytes([0xD0, 0xAA])
mac = "C4:7C:8D:00:00:00"

backend = btlewrap.BluepyBackend
with _bt_interface.connect(mac) as connection:
    connection.write_handle(
        _HANDLE_WRITE_MODE_CHANGE, _RESET_DEVICE
    )

Which Laptop is connected to my screen?

2021-01-12T21:32:00+01:00

I've installed an LED strip behind my monitor in my home office to reduce the contrast between the wall and the screen. A timer to turn it on and off does not work well since I am frequently using the same monitor with my private Macbook in the evening so I needed to be able to figure out if a running laptop is connected to my USB-C monitor.

At first I planned to use a ping sensor, however my work laptop is a Chromebook and does not respond to pings so I needed to have a better option. I thought that it would be nice to detect which laptop is connected and change the background color based on that.

My work laptop has a single port exposed so I could use nmap to detect whether or not my work laptop is connected. On my private Macbook I am running sshd which is also detectable using a port scan. Here is the sensor that I cam up with and returns either "Chromebook", "Macbook" or "None" depending on what signature it detects on the IP address of my monitor.

sensor:
  - platform: command_line
    name: Docking Station
    command: nmap -p22,5555 192.168.1.123 | grep -e tcp -e down
    scan_interval: 10
    value_template: >-
      {% if value|regex_search("open +freeciv") %}Chromebook{% elif value|regex_search("open +ssh") %}Macbook{% else %}None{% endif %}

I am using grep to limit the output of nmap to keep it below 255 characters which is a requirement that the command_line sensor has. I have added 'down' as well since grep returns an error if it does not find anything which command_line sensors do not like.

The following automation sets the light to different colors depending on whether I am working or my private laptop is connected.

automations:
  - id: '1610140797120'
    alias: Control Office Screen Light
    description: ''
    trigger:
    - platform: state
        entity_id: sensor.docking_station
    - platform: homeassistant
        event: start
    - platform: state
        entity_id: binary_sensor.screen_light_status
        from: 'unavailable'
    condition: []
    action:
    - choose:
        - conditions:
        - condition: state
            entity_id: sensor.docking_station
            state: Chromebook
        sequence:
        - service: light.turn_on
            data:
            rgb_color:
            - 108
            - 255
            - 108
            entity_id: light.screen_light
        - conditions:
        - condition: state
            entity_id: sensor.docking_station
            state: Macbook
        sequence:
        - service: light.turn_on
            data:
            rgb_color:
            - 255
            - 145
            - 200
            entity_id: light.screen_light
        default:
        - service: light.turn_off
        data: {}
        entity_id: light.screen_light
    mode: single

As light I am using the PCB that I created a long time ago to drive an WS2811 strip as seen in this video. It is powered through the monitors USB port and running ESPHOME.

Blackbox probing Home Assistant

2020-02-02T14:09:00+01:00

Having an developer/ops/support background I am interested in good monitoring to be able to investigate after unexpected things happen. Especially my Z-Wave and Zigbee network is where I am not so sure about the observed latency and whether or not it is doing what it should 24/7. I started writing an AppDaemon app to set a switch to on and then observe a binary_sensor until it is also switching to on, since they are electrically connected I can measure round trip latency. To achieve that I used ESPhome with a minimal config and the switch and binary_sensor are a pin each with a jumper wire connecting them.

# ESPhome configuration
switch:
  - platform: template
    name: "ping"
    lambda: 'return false;'
    turn_on_action:
      - output.turn_on: out_pin
      - delay: 1000ms
      - output.turn_off: out_pin
binary_sensor:
  - platform: gpio
    pin: D6
    name: "pong"
output:
  - platform: gpio
    pin: D5
    id: out_pin

Since the goal is to measure the latency of my Zigbee and Z-Wave networks and not just the latency introduced by ESPhome to toggle a pin I added a ZHA door sensor to trigger an update that exercises the Zigbee network. To keep the circuits isolated I used a PC817 optocoupler and at a later stage I will replace the battery of the door sensor to either run on 3.3V or introduce an other low drop voltage regulator to not have to constantly replace batteries as this "door" is opening and closing every minute.

The AppDaemon part is relatively straight forward and consists of two applications. The first one provides a way to add a point to a Google Cloud Monitoring metric. Replacing that with a different monitoring platform should be relatively simple. The second application handles a single prober and defines a ping and a pong entity. Every minute it changes the ping entity to on and waits until the pong entity is reporting an on state as well. The time in between those two events is the round trip latency and then reported to monitoring.

# app.yaml used in AppDaemon
monitoring:
  module: prober
  class: StackdriverMonitoring
  project: myproject-name
  credentials_json: "/config/gcp_serviceaccount.json"

prober1:
  module: prober
  class: Prober
  ping: switch.ping
  pong: binary_sensor.pong
  metric_name: prober_latency

prober2:
  module: prober
  class: Prober
  ping: switch.ping_zha
  pong: binary_sensor.pong_zha
  metric_name: zha_latency

Resources

Smart Intercom

2019-11-24T22:52:00+01:00

More than a year ago I was looking for a solution to integrate our intercom with Home Assistant. Back then nello seemed to be the only option that works with the most popular intercom in Switzerland the Koch AG TC Bus system.

Together with mensi I started do some research. Since there is not a lot of information available we quickly hooked up an oscilloscope to the intercom. The following shows a which is the signal line measured against b which is ground. The measured signal shows the open the outside door command.

While we were curious how the protocol works I did not want to decode the full protocol since I just needed to understand it enough to detect the signal sent when someone rings my apartment and be able to dispatch the 'open the door' command. To get started with recording the signal I designed a circuit that level-converted this the 9-24V to 0-3.3V and also allows to pull down the bus to 9V for active signaling. The schematic used is available through easyeda but the PCB is outdated and I needed to be creative with fixing my already ordered PCBs.

To integrate this with Home Assistant I used ESPHome and specifically the remote receiver and transmitter components. Using dump: raw I dumped all the signals and identified which ones I need. Then using the receiver and transmitter with the previously gathered raw signal I was able to successfully open the door and detect when ever the door bell signal was sent.

remote_receiver:
  pin:
    number: GPIO5
    inverted: true
    mode: INPUT
  dump:
    - raw
  idle: 7ms

remote_transmitter:
  pin: GPIO4
  carrier_duty_percent: 100%

switch:
  - platform: template
    name: Open Door
    turn_on_action:
      remote_transmitter.transmit_raw:
        code: [6463, -4387, 2142, -2208, 2142, -4387, 2142, -2207, 2142, -2213,
               4318, -2207, 2142, -4388, 2142, -4382, 2142, -2208, 2142, -2207,
               2142, -2212, 4318, -4382, 2142, -4392, 4319, -2207, 2142, -2207,
               2142, -2207, 2142, -2199, 4330]
binary_sensor:
  - platform: remote_receiver
    name: "Klingel"
    raw:
      code: [6000, -4000, 2000, -2000, 2000, -2000, 2000, -2000, 2000, -2000,
             4000, -2000, 2000, -4000, 2000, -4000, 2000, -2000, 2000, -2000,
             2000, -2000, 4000, -4000, 2000, -4000, 4000, -2000, 2000, -2000,
             2000, -2000, 2000, -2000, 2000]

Having this integrated with Home Assistant gives me some interresting options. To start with when we expect visitors we enable an automation that will automatically let people in once they ring the doorbell. We do not yet have a good solution on how to open the door from outside without opening Home Assistant but I have several ideas on how to achieve that.