ESPHome on William Floyd (low-quality images)

Smart Yogurt Maker Part 2

William Floyd — Wed, 16 Mar 2022 00:00:00 +0000

Last time we met, I got my rice cooker reporting temperature and roughly maintaining a set-point, producing my first batch of yogurt. Now follows a tale of Accidents, Averages, and Algorithms (sorta).

An accident has occurred

How prophetic… My last post said so truly that I needed to “ensure the outlet will turn off if the ESP8266 loses connection”. Of course, I couldn’t help myself and tried making a new batch before fixing this. So it came to be that 6 hours into a batch of yogurt, it was unceremoniously boiled for a full hour.

At first, all hope was lost - the mess of solidified dairy mocked me from the teflon lining of my dear rice cooker. As I forlornly drained the whey, I figured I’d give it a taste… After all, it had been boiled to death, it couldn’t possibly hurt me?

Rice Maker $\to$ Yogurt Maker $\to$ Cheese Maker?

I had in fact made cheese. Not at all intentionally, and not very well (it was still somewhat yogurt-sour), but it was undeniably cheese. A rough straining through a cheese cloth yielded something more passable as cheese, if only barely. My girlfriend confirmed it seems to be very similar to Paneer, though she declined to taste it. I ate only a small portion before deciding it wasn’t worth the effort…

Simmer down now!

Clearly, it was time to get my automation in order. It didn’t take much to ensure the automation would turn the heat off in case of connection loss, but the regular spikes in temperature were yet to be sorted.

Fortune Telling

The primary issue in using PID for this system is thermal lag. While my temperature sensor is accurate for its location, it cannot account for the temperature gradient in the contents itself. It would require a complete model of the system, including factors such as convection rate from the rice cooker housing, specific heat capacity, power draw, ambient temperature, volume of contents, initial temperature of contents, etc. All things considered, this is well outside of the scope of this project - this is meant to make yogurt, and I can do with much less.

Dirty Shortcut

What I have settled on is a simple hybrid between simple and PID-informed bang–bang control. My automation simply turns the heater on if the PID value (ranging between 0 and 1) is above 0.95. This is the case on startup, for example. If the value is between 0.6 and 0.95, it will turn it on, wait 750 milliseconds, turn back off, then delay any further action for the next 15 seconds. This ensures when attempting to hold a setpoint that the thermal lag in the system will catch up. These values are found purely by experimentation, but yield sub $1^{\circ} F$ variation easily.

PID Settings

Given some changes to the PID integration I am using, as well as further testing, these are now my PID settings:

\begin{array}{c} P & = 175 \\ I & = 0 \\ D & = 0 \end{array}

So really, it’s just the “P” in “PID” - I don’t mind if it works.

“Next time, on Rice Cooker Adventures”

Completed since last time:

ensure the outlet will turn off if the ESP8266 loses connection
PID tune the setup for the most common scenario (steady $107^{\circ} F$ with the lid shut)

Left to do now:

solder a perfboard version of the circuit
add a relay to control the cooker directly

Smart Yogurt Maker Part 1

William Floyd — Tue, 25 Jan 2022 00:00:00 +0000

A certain Rice Cooker has been languishing in a box for the last several years - now it is time to revisit it. It is a tale of Solder, Software, and Streptococcus thermophilus.

“Last time, on Rice Cooker Adventures”

This story picks up where I left off 3 years ago - the rice cooker has thermistors taped to the bottom of the pot with high temperature fiberglass tape. Specifically, I have 4 of the same thermistor in 2 parallel lines of 2 series resistors, like so.

This serves to roughly average the resistances, to account for possible hotspots on the pot, while only taking a single ADC pin.

However, time has not been kind to my memory, and the specific parameters of these thermistors are unknown, so first, it’s time to do some testing.

Side Quest: Thermistor Calibration

I have a thermocouple that I can use to verify the temperature of the pot with, so here is the setup: log the resistance through the thermistor bank at close to room temperature, rolling boil, and a middle temperature (during cooldown). These three sample points may then be used to find the parameters of the thermistor exactly.

From hazy memory (and counting parts in inventory), my suspicion was that I had used a $100 k Ω$ thermistor. Brand is unknown, but representative datasheets online cite a $β$ value of 3950 - let’s see how we compare.

Wait, what does $β$ mean?

For a more in depth read, look here, but in summary early studies proposed that for NTC thermistors, the temperature $T$ could be determined given a measured resistance $R$ , coefficient $β$ and reference resistance $R_{0}$ and temperature $T_{0}$ , like so:

\frac{1}{T} = \frac{1}{T_{0}} + \frac{1}{β} \ln \frac{R}{R_{0}}

While this may work for small temperature ranges (approximately $20^{\circ} C$ or so), we require a larger range, and so we are instead going to look at the…

Steinhart-Hart Equation

Briefly summarizing Wikipedia, the equation states:

\frac{1}{T} = A + B \cdot \ln {(R)} + C (\ln (R))^{3}

Which, when using 3 sample points, results in:

[\begin{array}{c} 1 & \ln R_{1} & \ln^{3} R_{1} \\ 1 & \ln R_{2} & \ln^{3} R_{2} \\ 1 & \ln R_{3} & \ln^{3} R_{3} \end{array}] [\begin{array}{c} A \\ B \\ C \end{array}] = [\begin{array}{c} \frac{1}{T_{1}} \\ \frac{1}{T_{2}} \\ \frac{1}{T_{3}} \end{array}]

In my case, I found the points of reference using a setup like so:

Do note that in order to reach a full boil (and $100^{\circ} C$ on the thermocouple), the lid of the rice cooker was attached.

While I could show the calculations, and they wouldn’t be difficult, I’ll be honest: I used an online calculator.

Using the measurements:

\begin{array}{c} R (Ω) & T (^{\circ} C) \\ 81 k & 33 \\ 21.3 k & 66 \\ 6.4 k & 100 \end{array}

Yielded

\begin{array}{c} A & = 1.032978070 \cdot 10^{- 3} \\ B & = 1.733021623 \cdot 10^{- 4} \\ C & = 1.902682261 \cdot 10^{- 7} \\ R_{(25^{\circ} C)} & = 117072.68 Ω \\ β_{calculated} & = 4202.76 K \end{array}

As we can see then, the actual $β$ value is larger than predicted ( $3950 K$ predicted vs. $4203 K$ actual), as is the reference resistance ( $100 k Ω$ predicted vs. $117 k Ω$ actual). In fact, neither of these are even in the commonly stated “ $\pm 1 %$ ” range. Good thing we’re calibrating, hey?

“Back to our regularly scheduled programming”

How to use this data then? Being short on time, I opted to take the easy way out, and use the wonderful ESPHome, as I already use Home Assistant. As it turns out, they already have us covered, with a NTC Sensor component already built in. This, coupled with a resistance and ADC sensor allow using a voltage divider to measure the resistance of the thermistor.

You know those calculations and equations we did above? Unnecessary, all of it. ESPHome supports doing Steinhart-Hart calculations itself, and only needs the three sample points.

In the meantime, a Wemos D1 Mini on a breadboard is ready to go (they’re cheap and cheerful). I wire it up with a $6.8 k Ω$ resistor (what I had handy), and away I went. The circuit looks something like this, where the two trailing wires connect to the thermistor bank:

To prevent confusion, here is my final working config, then I’ll explain.

sensor:
  - platform: ntc
    sensor: resistance_sensor
    calibration:
      - 81.0kOhm -> 33°C
      - 21.3kOhm -> 66°C
      - 6.4kOhm -> 100°C
    name: Rice Cooker Temperature
    unit_of_measurement: °C

  - platform: resistance
    id: resistance_sensor
    sensor: source_sensor
    configuration: DOWNSTREAM
    resistor: 6.96kOhm
    reference_voltage: 3.306V
    name: Resistance Sensor

  - platform: adc
    id: source_sensor
    pin: A0
    name: Voltage Sensor
    filters:
      - multiply: 3.2
    update_interval: 1s

Calibrate all the things

Series Resistor

Easy, measuring mine I found it to be $6.96 k Ω$ , certainly different from the $6.8 k Ω$ it’s meant to be. Throw that in the config.

Reference Voltage

This is also easy enough, measure the $3.3 V$ pin off the D1 mini. Mine came out to be $3.306 V$ , respectably close to rated! That goes in the config too.

Multiply Filter

As it turns out, the D1 mini has an internal voltage divider to convert the $3.3 V$ of the input voltage down to the $1 V$ the ADC is rated for. This is nice, as it protects the ADC, but it must be accounted for. But there’s a catch - on my board this wasn’t quite right - the voltage read was still slightly wrong. I could try manually tuning this, but there is an easier way. Instead, I measured the actual voltage ( $3.306 V$ ), and compared it to the voltage being read.

Say there was no error, then we would say $V_{actual} = V_{measured}$ , and if there is an error of a multiple difference between the two, we can say $V_{actual} = m \cdot V_{measured}$ . Thus, to find this multiplier, we say:

m = \frac{V_{actual}}{V_{measured}}

Using this method, I find my multiplier to be $3.2$ , not $3.3$ .

With that, the board is finally reading the correct voltage, the correct resistance, and the correct temperature.

“You’re so controlling!”

Given that I have Home Assistant, automating it becomes easy.

I’m currently using a Tasmota flashed smart outlet to control the power to the heating element of the rice cooker (for reference, it pulls up to $400 W$ at full load). In future, I would like to condense all functionality into a relay controlled directly by the ESP8266, to allow greater safety in case of network issues or even local PID tuning.

I am also using a PID controller for Home Assistant. It seems to work fine, I am just bad at PID tuning, so results may vary depending on hardware, amount of mass in the cooker, ambient temperatures, etc. That being said, a simple automation to turn the heater on when the PID response goes high and turn off when not high yields acceptable results.

From fiddling with the settings, I currently am using the following parameters:

\begin{array}{c} P & = 60 \\ I & = 5.6 \\ D & = 6.7 \end{array}

Further tuning is required, but this held well overnight - mostly…

I did change the set point from $105^{\circ} F$ to $107^{\circ} F$ halfway through, as well as tweaked some of the PID tuning. The concerning spike at 9:00 is marked by a momentary loss of connection with the ESP board - my automation failed to account for a loss of connection and so allowed the heat to continue rising. Thankfully, this was a short-lived event, but it is concerning nonetheless, and will require testing of my automation to prove that power loss tends towards a “safer” outcome. Do note that “safer” means no dead yogurt culture - the safety features of the rice cooker remain unchanged and functional.

The proof is in the… yogurt?

So how did it do? I am notoriously not picky when it comes to food, but I think it turned out great! Filling the rice cooker about halfway with whole milk, I heated it to $180^{\circ} F$ for a few minutes (I read I ought to go for longer…), cooled to about $110^{\circ} F$ , then added a liberal few spoonfuls (think 1/5 volume of milk) of plain Dannon yogurt. I let it proof in the rice cooker for 7.5 hours, with the lid sealed.

I put the whole rice cooker in the fridge to cool, with the lid sealed. Trying it later that same evening, I quite enjoyed it. I’ll start my next batch from this one, and hopefully it’ll be even better.

“Next time, on Rice Cooker Adventures”

Now that I have a temperature controllable rice-cooker, and the ability to remotely start, stop, and modify set points, I may try other foods. For now, I need to:

solder a perfboard version of the circuit
add a relay to control the cooker directly
ensure the outlet will turn off if the ESP8266 loses connection
PID tune the setup for the most common scenario (steady $107^{\circ} F$ with the lid shut)

First though, I’m gonna go eat some fresh yogurt…

Home Automation at School

William Floyd — Wed, 21 Apr 2021 00:00:00 +0000

I love home automation - I’ve spent far longer writing automation routines and hacking together my own devices and programs than I have ever saved by doing so, and that’s perfectly fine. One unique aspect of my setup, however, is that I cannot control the network I must use - in my Uni dorm, I am not allowed to run my own router, and so all IoT devices must connect to the school wireless network. There abound dozens of Google Home devices, Chromecasts, and so on, all accessible on the same network - but not from the wired connection that my server/desktop uses.

Here then is my solution: MQTT everything I can. From my lights, to light sensor, to coffee maker to desktop software, I bounce it through a MQTT server hosted on a VPS. I use Home Assistant, so automatic discovery is easy on most things, especially ESPHome. In fact, I disabled direct Home Assistant connectivity entirely on these devices, which works well enough for me to live with.

But how to flash?

Given that my Home Assistant instance isn’t even on the same network as the IoT devices, how do I update the firmware? Using my laptop, I can connect to the wireless network that they reside on, and using IP address sensors reported by these devices, flash them directly without needing local discovery. In fact, I can easily automate this for myself using a couple scripts and a minimal number of hard-coded values:

hassio.sh

#!/bin/bash

export HASS_SERVER=https://<server_url>:443
export HASS_TOKEN='<HA_Token>'

hass-cli ${@}

exit

lamps.sh

#!/bin/bash

declare -A aa

aa["gosund_lb1_1.yaml"]="sensor.desk_lamp_ip_address"
aa["gosund_lb1_2.yaml"]="sensor.bed_lamp_ip_address"
aa["gosund_lb1_3.yaml"]="sensor.floor_lamp_girlfriend_ip_address"
aa["gosund_lb1_4.yaml"]="sensor.desk_lamp_girlfriend_ip_address"
aa["gosund_lb1_5.yaml"]="sensor.floor_lamp_ip_address"

__flash() {

    __config="${1}"
    __entity_name="${aa[${__config}]}"
    echo "Getting ${__config} IP..."

    __ip="$(
        ./hassio.sh -o yaml state get \
            "${__entity_name}" |
            grep -E '^ *state' | sed -e 's/.* //'
    )"

    echo "IP: ${__ip}"

    if [ "${__ip}" == 'unavailable' ]; then
        echo 'Ignoring...'
    else
        echo "Flashing..."
        ./esphome.sh "${__config}" run --upload-port="${__ip}"
    fi
    
    echo

}

if [ "${#}" -gt 0 ]; then
    until [ "${#}" == 0 ]; do
        __flash "${1}"
        shift
    done
else
    for __config in ${!aa[@]}; do
        __flash "${__config}"
    done
fi

exit

this allows me to mostly painlessly flash my devices, though truth be told there is little need.

Custom software

I developed for myself a tool in Golang to help tie more of my devices together. It is rather uncreatively/cryptically named ha-mqtt-iot - that is, “Home Assistant MQTT Internet of Things”. I may rename this some day, but why bother. It is similar to IOTLink (which is Windows only), and HASS Workstation Service - they are great projects, but this one is mine, even if it is poorly written.

The gist of the software is that most (all?) device types supported by Home Assistant may be implemented using a selection of user defined commands. The most prominent example in my case is to enable/disable dark mode on my desktop. I automate this according to ambient light in my room, to better match the aesthetic I want. Additionally, I can use it to turn my desktop monitor off, without resorting to using a relay outlet, and even change the color temperature of my system. The script I use for this looks like the following:

#!/bin/bash

__monitor_i2c='dev:/dev/i2c-3'
__monitor_dpms='0xd6'
__monitor_brightness='0x10'
__monitor_standby='4'
__monitor_off='5'
__monitor_on='1'

__unknown() {
    echo "Unknown ${1}"
}

f2i() {
    awk 'BEGIN{for (i=1; i<ARGC;i++)
   printf "%.0f\n", ARGV[i]}' "$@"
}

com="${1}"
arg="${2}"

case "${com}" in
"command")
    case "${arg}" in
    "ON")
        xset dpms force on
        ;;
    "OFF")
        (
            #xset dpms force off
            #sleep 0.5s
            #ddccontrol -r "${__monitor_dpms}" -w "${__monitor_standby}" "${__monitor_i2c}" -f
            #sleep 2s
            ddccontrol -r "${__monitor_dpms}" -w "${__monitor_off}" "${__monitor_i2c}" -f
        ) &
        ;;
    *)
        __unknown "${arg}"
        ;;
    esac
    ;;
"command-state")
    echo -n "$(xset q | grep 'Monitor is' | sed -e 's/.* //' | tr '[:lower:]' '[:upper:]')"
    ;;
"color-temp")
    v="$(f2i "$(bc -l <<<"1000000/${arg}")")"
    ./scripts/run-in-user-session.sh gsettings set org.gnome.settings-daemon.plugins.color night-light-temperature "${v}"
    ;;
"color-temp-state")
    v="$(./scripts/run-in-user-session.sh gsettings get org.gnome.settings-daemon.plugins.color night-light-temperature)"
    echo -n "$(f2i "$(bc -l <<<"1000000/${v/* /}")")"
    ;;
"brightness")
    ddccontrol -r "${__monitor_brightness}" "${__monitor_i2c}" -w "${arg}"
    ;;
"brightness-state")
    echo -n "$(ddccontrol 2>/dev/null -r "${__monitor_brightness}" "${__monitor_i2c}" | tail -n 1 | grep -o '/[0-9]*/100' | sed -e 's|^/||' -e 's|/.*||')"
    ;;

*)
    __unknown "root command ${com}"
    ;;
esac

exit

Note that the display doesn’t respond to being turned back on, so this is somewhat incomplete, but it’s good enough for my needs. The corresponding portion of the config for ha-mqtt-iot looks like the following:

"lights": [
    {
        "info": {
            "name": "Desktop Monitor",
            "id": "monitor"
        },
        "command": [
            "./scripts/monitor.sh",
            "command"
        ],
        "command_state": [
            "./scripts/monitor.sh",
            "command-state"
        ],
        "command_color_temp": [
            "./scripts/monitor.sh",
            "color-temp"
        ],
        "command_color_temp_state": [
            "./scripts/monitor.sh",
            "color-temp-state"
        ],
        "command_brightness": [
            "./scripts/monitor.sh",
            "brightness"
        ],
        "command_brightness_state": [
            "./scripts/monitor.sh",
            "brightness-state"
        ],
        "brightness_scale": 100,
        "update_interval": 5
    }
]

Pretty simple. This makes custom system sensors trivial. For example, to show my system IP, I use the following:

"sensors": [
    {
        "info": {
            "name": "IP Address Desktop Solus",
            "id": "ip-address-desktop-solus",
            "icon": "mdi:ip-network"
        },
        "command_state": [
            "/bin/bash",
            "-c",
            "ip -j address show eno1 | jq -r '.[0].addr_info[0].local'"
        ],
        "update_interval": 10
    }
]

Some common use cases are built in as well. Currently, this includes laptop displays (as lights) and batteries (as sensors), as well as Crypto prices (through the CoinGecko Golang library). These are really easy to call. An exhaustive example is quite short:

"builtin": {
    "prefix": "Name Prefix ",
    "backlight": {
        "enable": true,
        "temperature": false,
        "range": {
            "minimum": 0.025,
            "maximum": 0.95
        }
    },
    "battery": {
        "enable": true
    },
    "crypto": [
        {
            "coin_name": "dogecoin",
            "currency_name": "usd",
            "update_interval": 1,
            "icon": "mdi:currency-usd"
        }
    ]
}

This lets me tailor my setup to each machine I’m using, while still enjoying the benefits of Home Assistant MQTT Discovery. The primary limitation at present is the inability to signal to ha-mqtt-iot from another process - it can only poll for changes. This will be addressed one day, when it is important for my own needs.

How to host?

But the question is now, how do I access my HomeAssistant instance if it’s also hosted at school? I most certainly don’t have a public IP, so in comes AutoSSH. I’m not sure which is the best one at this stage, but refer to this repo and check the various forks of the parent project.

I have configured on my VPS a docker image that accepts reverse SSH tunnelling, authorized only to the key of the HA addon. From my docker-compose.yml:

homeassistant:
    image: "docker.io/panubo/sshd"
    container_name: homeassistant
    environment:
        - TCP_FORWARDING=true
        - GATEWAY_PORTS=true
        - SSH_ENABLE_ROOT=true
        - DISABLE_SFTP=true
    volumes:
        - "./hassio/authorized_keys:/root/.ssh/authorized_keys:ro"
        - ./docker-config/hassio/data/:/data
        - ./docker-config/hassio/keys/:/etc/ssh/keys
    ports:
        - "<MY_PORT>:22"
    restart: unless-stopped
    hostname: "homeassistant"

This is then reverse proxied to using Caddy, to expose the website on a subdomain of a website. From my Caddyfile:

<MY_SUBDOMAIN>.{$MY_DOMAIN} {
    reverse_proxy homeassistant:8123
    encode gzip
}

Pretty simple, but not without some hiccups now and again - I occasionally have to restart the sshd docker on my VPS if something goes wrong with HomeAssistant.

Bonus: Android tie in

I use Sleep As Android to track my sleeping patterns, and as my alarm clock. Using Tasker, I can run an action when I begin sleep tracking, which (using a HomeAssistant plugin for Tasker) can call a script on my HomeAssistant instance to turn off my lights (only if I’m home, of course). Similarly, it turns on my bedhead light when my alarm goes off in the morning, and could optionally make me coffee…

DIY 'Smart' Coffee Maker

William Floyd — Sun, 05 Jul 2020 00:00:00 +0000

I have recently (last couple months) been getting into home automation, specifically using Home Assistant. I also wanted to get a coffee maker that used K-Cups. Thus the goal was born - to get a coffee maker working with Home Assistant, such that I could automate it to fit my morning routine.

I first searched for new coffee makers, looking to see what the easiest ones would be to hack into and automate. I got so far as adding a sleek new brand name model to my Amazon cart, but thankfully reason and frugality prevailed! Instead, I opted to swing by the local Goodwill the next day, to see what secondhand options might be available. As luck would have it, I found a no-frills, single button coffee maker for the princely sum of $4, and I was on my merry way.

Later that evening, opening the black box up (thankfully I had the correct triangular screwdriver head), I found very easily hackable innards.

The control board (front, back) is very simple - two buttons in parallel, an LED, and a couple resistors. I’m not quite sure what the logic is upstream (it un/latches on each press), but the buttons short to ground, and this is something I can work with. The control board has wires for ground, signal, and 5V, in that order.

The ordeal of hacking into the thing, and my missteps trying to do so, is rather boring really, but it produced this:

The brains I added was a Wemos D1 Mini (thanks, Aliexpress!), with a 3.3V<->5V converter between to sense when the coffee maker is on, and also turn on a mosfet to short the button to ground. I initially had issues with the coffee maker turning on whenever I plugged the D1 Mini in, but a pulldown resistor solved this.

I also opted for an external USB plug - this allows me to possibly reflash this without opening the enclosure, and also meant I did not need to splice into the mains line inside, which I was reluctant to do.

I initially flashed and programmed the coffee maker with Tasmota, but almost immediately opted to use ESPHome instead. I like Tasmota and ESPHome, I was just able to get more fine control of the setup using ESPHome in this instance, especially concerning the button logic.

The (important) code is as follows:

binary_sensor:
  - platform: gpio
    device_class: power
    internal: true
    id: power_on
    pin: D2
    
switch:
  - platform: gpio
    pin: D1
    id: relay
    restore_mode: ALWAYS_OFF
  - platform: template
    name: "Coffee Maker"
    icon: "mdi:coffee-maker"
    lambda: |-
      if (id(power_on).state) {
        return true;
      } else {
        return false;
      }
    turn_on_action:
    - switch.turn_on: relay
    - delay: 50ms
    - switch.turn_off: relay
    turn_off_action:
    - switch.turn_on: relay
    - delay: 50ms
    - switch.turn_off: relay

The beauty of the way in which I can detect signals and simulate a button press is that ESPHome senses when I use the physical button, and updates accordingly. I can use the coffee maker absolutely as normal, the ‘Smart’ part of it is optional.

The rest of my setup using this coffee maker is somewhat outside the scope of this post, but it includes using Tasker on my phone to run a ‘Wakeup’ automation on Home Assistant, which will - along with turning on my bed-head lamp, and switching my monitor on before putting it to sleep - check if I turned on a ‘Morning Coffee’ user input. If I remembered to prep my coffee the night before, and turned on the switch, I will wake up to a hot cup of coffee (or, the sound of a coffee-in-progress). I can also command Alexa and Google Assistant to do my bidding and make me a coffee. At least someone does what I want…

Truly, we are living in the future.