The reasoning was simple. If I were to enter a marathon, I would want to race it for a good time. The ultras, by contrast, were always about finishing. Two very different mindsets, and I had not been ready to commit to the first one. Until now.

Race Run Through

Pre-Race

My initial plan was to take the train through to the start. Last year there were reports of trains being full and runners missing the start of the race, so I thought I would just take an earlier train. Except this is Scotland on a Sunday, and the early trains don’t exist. My next idea was to drive to a park-and-ride, but that had the obvious problem of needing to drive home afterwards. Luckily my dad offered to give me a lift in, which took all the pressure off.

After being dropped off, I made my way to the start area, dropped my bag off and headed towards the start pens. On the way I bumped into some of the other RTC Warriors, so we had a quick chat and got a group photo.

I would be lying to say I had no nerves, but it certainly wasn’t as bad as some of the previous races.

The First Few Miles

Within the first two miles, a bead of sweat dripped down the inside of my glasses. That was the moment I realised the time I had been chasing was not going to happen. It was simply too hot.

I pushed on to see what I could achieve. By Portobello I had given up looking at my pace and was just focusing on running in a controlled manner. There was no point in burning myself out chasing a number that was no longer realistic.

Portobello and Beyond

The crowds were brilliant. The cheering and the placards genuinely lifted me, even when the support was clearly aimed at someone else. What I had not expected was the personal cheering - “Come on Alistair!”, “Well done Alistair!” - from complete strangers. The first few times I tried to work out if I should recognise them, before remembering that they print your name on the race number.

Somewhere along the coast I caught up with the tail runners from the half marathon. It was around this point that I started noticing ambulances and medics moving about the course. The course was very exposed and there were few opportunities to hide from the sun.

Survival Mode

At the far point of the course, I changed plan and shifted into survival mode. I had just passed someone collapsed at the side of the road receiving medical attention, and I made a firm decision that I was not going to let that happen to me.

From then on, at each water station, I ran into the station, took the water, then walked with it until the bottle was completely empty. No wasted water, no rushing through. I was going to give myself the best possible chance of getting to the finish in one piece.

The temptation to slow to a jog, or even just walk, was strong. But I gave myself a rule: if I had a water bottle with water still in it, I could walk. Otherwise, I had to run. That kept me honest between the stations.

The “Sprint” Finish

I still had a sprint finish in me. Unfortunately, I misjudged where the finish actually was. What I had intended as a 100m sprint turned into something closer to 500m.

Once I crossed the line, my blood pressure presumably crashed and I found it very difficult to balance. One of the first aiders pulled me aside, sat me down and made me drink some water. After a bit, I was keen to get out of the finish area and find my dad. I did my best to stagger in a straight line through the finish funnel, picking up my t-shirt and goody bag while trying not to look like I had had several drinks too many.

Strava Activity

Reflection

Reflection

I am not a fan of this distance.

I didn’t get the time I wanted, but I am not particularly keen to try again. The time commitment to train properly for a marathon is significant, and the race itself takes a lot out of the body. What I really enjoy about running is the training, and the feeling of being fit. Between the taper before the race and the recovery afterwards, these big events rob me of that feeling for several weeks at a time.

If I am being honest, I feel the same way about the ultras. I like the idea of them. I enjoy thinking back to them. But the actual doing of them is pretty miserable at the time, and the missed training weeks are just as frustrating. There is a pattern here that I should probably pay more attention to.

Hopefully I can recover quickly from this one and get back to running properly.

Arriving Home After Dark

When I arrive home after dark, the front door lights turn on at full brightness for ten minutes, then automatically switch off again.

Home Assistant does have its own presence detection, but I found it was too slow — often I would already be in the house by the time it registered that I had arrived. Using MacroDroid on the phone gives a much faster response, because it can combine two triggers: entering a GPS geofence around the house, or connecting to the home Wi-Fi network. Either one will fire the macro. The combination means it typically triggers before I have even reached the driveway.

Before doing anything, the macro checks two conditions. First, it must be after sunset — no point turning on lights in daylight. Second, a stopwatch that resets each time the macro fires must have been running for at least eight minutes. That second check prevents repeated triggering if the phone briefly drops off the Wi-Fi and reconnects, or drifts in and out of the geofence boundary.

If both conditions are satisfied, the macro makes an HTTP PUT request to a Home Assistant webhook. On the HA side, this triggers an automation that turns on the front door lights at full brightness and starts a ten-minute timer. When the timer finishes, a second automation turns the lights back off.

There is also a “leaving home” automation that turns off the lights when both adults have left the home zone, so there is no risk of them being left on all day.

The MacroDroid-to-HA webhook pattern is something I use in a few places. It lets me use the phone’s location and connectivity awareness — things MacroDroid handles very well — whilst leaving the actual smart home control to Home Assistant.

MacroDroid macro: The triggers are “Enter geofence: Home” and “Wi-Fi SSID in range: [your home SSIDs]”. The constraints are “After sunset” and “Stopwatch ‘Got home’ > 8 minutes”. The actions reset the stopwatch then make an HTTP PUT to the HA webhook URL.

Home Assistant automations:

# Turn on front door lights when arriving home after dark
- alias: Arrived Home After Dark
  triggers:
    - trigger: webhook
      webhook_id: "arrived-home-after-dark"
      allowed_methods: [PUT]
  actions:
    - action: light.turn_on
      target:
        area_id: front_door
      data:
        brightness_pct: 100
    - action: timer.start
      target:
        entity_id: timer.arrived_home
      data:
        duration: "00:10:00"

# Turn lights off when the timer finishes
- alias: Arrived Home Complete
  triggers:
    - trigger: event
      event_type: timer.finished
      event_data:
        entity_id: timer.arrived_home
  actions:
    - action: light.turn_off
      target:
        area_id: front_door

# Turn off front door lights when everyone has left the house
- alias: Leaving Home
  triggers:
    - trigger: zone
      entity_id: person.adult_1
      zone: zone.home
      event: leave
    - trigger: zone
      entity_id: person.adult_2
      zone: zone.home
      event: leave
  conditions:
    - condition: not
      conditions:
        - condition: zone
          entity_id: person.adult_1
          zone: zone.home
    - condition: not
      conditions:
        - condition: zone
          entity_id: person.adult_2
          zone: zone.home
  actions:
    - action: light.turn_off
      target:
        area_id: front_door

Children’s Bedroom Lights

Both children have loft beds with bright LED strips underneath. The LEDs are wired via smart switches that Home Assistant can control, but the only physical remote in each room is for the main ceiling light.

Rather than fitting extra remotes or switches, I set up automations that follow the main light’s brightness. When the main light is turned up above a high brightness threshold, the under-bed LEDs switch on. When the main light drops below a lower threshold — or is turned off entirely — they switch off. The gap between the two thresholds acts as a deadband, preventing the LEDs from flickering while someone is slowly adjusting the brightness.

The end result is that one remote effectively controls both the overhead light and the under-bed task lighting, without the children needing to think about it at all.

# Example for one child's room — repeat with different entities for the other
- alias: Set Child Bedroom Under-Bed Light
  triggers:
    - trigger: state
      entity_id: light.bedroom_main_light
      attribute: brightness
    - trigger: state
      entity_id: light.bedroom_main_light
  actions:
    - choose:
        - conditions:
            - condition: numeric_state
              entity_id: light.bedroom_main_light
              attribute: brightness
              above: 190
          sequence:
            - action: light.turn_on
              target:
                entity_id: light.bedroom_under_bed
        - conditions:
            - condition: or
              conditions:
                - condition: numeric_state
                  entity_id: light.bedroom_main_light
                  attribute: brightness
                  below: 100
                - condition: state
                  entity_id: light.bedroom_main_light
                  state:
                    - "off"
                    - unavailable
                    - unknown
          sequence:
            - action: light.turn_off
              target:
                entity_id: light.bedroom_under_bed

Note that HA represents brightness on a scale of 0–255, so above: 190 corresponds to roughly 75% brightness and below: 100 to roughly 40%.

The TV

Sharing Links from the Phone

One of my favourite automations is being able to share a link from my phone directly to the living room TV.

Home Assistant’s companion app registers itself as a share target on Android. When you share a URL to it, HA fires a mobile_app.share event containing the URL. An automation picks this up and checks whether the URL is a YouTube link using a regular expression. If it is, it extracts the video ID and launches the YouTube app on the TV at that specific video, rather than opening a browser. If the URL is not a YouTube link, it opens the TV’s built-in browser at that address instead.

The TV has a kids lock enabled, which requires a PIN before content will play. A parallel sequence handles this automatically: two seconds after launching the app (to give it time to open and show the PIN prompt), it sends the PIN digits as individual button presses to the TV, followed by Enter.

The whole thing means I can be reading something on my phone, tap Share, select Home Assistant, and it is playing on the TV within a few seconds.

- alias: Share to TV
  triggers:
    - trigger: event
      event_type: mobile_app.share
  actions:
    - if:
        - condition: template
          value_template: >
            {{ trigger.event.data.url | regex_match(
              '^(?:https?:\/\/)?(?:www\.|m\.)?(?:youtube\.com\/(?:watch\?v=|shorts\/)|youtu\.be\/)([0-9A-Za-z_-]{11}).*'
            ) }}
      then:
        - variables:
            vID: >
              {{ trigger.event.data.url | regex_replace(
                '^(?:https?:\/\/)?(?:www\.|m\.)?(?:youtube\.com\/(?:watch\?v=|shorts\/)|youtu\.be\/)([0-9A-Za-z_-]{11}).*$',
                'v=\1'
              ) }}
        - parallel:
            - action: webostv.command
              data:
                entity_id: media_player.living_room_tv
                command: system.launcher/launch
                payload:
                  id: youtube.leanback.v4
                  contentId: "{{ vID }}"
            - sequence:
                - delay: "00:00:02"
                - action: webostv.button
                  data:
                    entity_id: media_player.living_room_tv
                    button: "1"  # Replace these four digits with your PIN
                - action: webostv.button
                  data:
                    entity_id: media_player.living_room_tv
                    button: "2"
                - action: webostv.button
                  data:
                    entity_id: media_player.living_room_tv
                    button: "3"
                - action: webostv.button
                  data:
                    entity_id: media_player.living_room_tv
                    button: "4"
                - action: webostv.button
                  data:
                    entity_id: media_player.living_room_tv
                    button: ENTER
      else:
        - parallel:
            - action: webostv.command
              data:
                entity_id: media_player.living_room_tv
                command: system.launcher/open
                payload:
                  target: "{{ trigger.event.data.url }}"
            - sequence:
                - delay: "00:00:02"
                - action: webostv.button
                  data:
                    entity_id: media_player.living_room_tv
                    button: "1"
                - action: webostv.button
                  data:
                    entity_id: media_player.living_room_tv
                    button: "2"
                - action: webostv.button
                  data:
                    entity_id: media_player.living_room_tv
                    button: "3"
                - action: webostv.button
                  data:
                    entity_id: media_player.living_room_tv
                    button: "4"
                - action: webostv.button
                  data:
                    entity_id: media_player.living_room_tv
                    button: ENTER

Notification When the TV Is Turned On

This one started as a parenting tool. When the TV is turned on, Home Assistant sends a notification to any adult who is currently at home, telling them what time it came on and offering a “Turn Off” button. The check for whether each adult is home is there to avoid spamming someone who is out at work with notifications they cannot act on. Tapping the button fires a separate automation that turns the TV off via the media player integration.

The idea was to make it obvious to the children that we would always know if they had turned the TV on without permission. These days they are well aware the notification exists, which is arguably just as effective as it ever was.

- alias: TV Is On
  triggers:
    - trigger: device
      device_id: your_tv_device_id
      domain: media_player
      type: turned_on
  actions:
    - if:
        - condition: zone
          entity_id: person.adult_1
          zone: zone.home
      then:
        - action: notify.mobile_app_adult_1_phone
          data:
            title: TV is on
            message: "Someone turned on the TV at {{ now().strftime('%H:%M') }}"
            data:
              notification_icon: mdi:television
              actions:
                - action: TURN_OFF_TV
                  title: Turn Off
    - if:
        - condition: zone
          entity_id: person.adult_2
          zone: zone.home
      then:
        - action: notify.mobile_app_adult_2_phone
          data:
            title: TV is on
            message: "Someone turned on the TV at {{ now().strftime('%H:%M') }}"
            data:
              notification_icon: mdi:television
              actions:
                - action: TURN_OFF_TV
                  title: Turn Off

- alias: Turn Off TV via Notification
  triggers:
    - trigger: event
      event_type: mobile_app_notification_action
      event_data:
        action: TURN_OFF_TV
  actions:
    - action: media_player.turn_off
      target:
        entity_id: media_player.living_room_tv

Bluetooth Headphone Battery in Home Assistant

Home Assistant does a good job of tracking battery levels for devices — mobile phones, sensors, remote controls — but Bluetooth audio devices are a notable gap. There is no standard way for the Home Assistant mobile companion app to poll the battery level of a connected headset.

The solution uses MacroDroid on the phone. Android broadcasts a system intent (android.bluetooth.device.action.BATTERY_LEVEL_CHANGED) whenever a connected Bluetooth device reports a change in its battery level. MacroDroid can listen for system intents and extract values from the broadcast extras — in this case, the BATTERY_LEVEL extra is stored in a local variable.

The macro then POSTs that value as JSON to a Home Assistant webhook, but only when the value is not -1. Android uses -1 to indicate that the battery level is unknown or unavailable, so that constraint prevents spurious updates reaching HA.

On the Home Assistant side, the webhook automation reads the battery_level field from the JSON payload and writes it into an input_number helper. From there it appears on the dashboard alongside every other battery sensor.

MacroDroid macro: Trigger is “Intent received: android.bluetooth.device.action.BATTERY_LEVEL_CHANGED”, with the android.bluetooth.device.extra.BATTERY_LEVEL extra mapped to a local variable (e.g. bt_batt). The single action is an HTTP POST to the HA webhook with body {"battery_level": {lv=bt_batt}}, with a constraint that bt_batt != -1.

Home Assistant — helper and automation:

First, create an input_number helper for the battery level (this can also be done via the UI under Settings → Helpers):

input_number:
  headphone_battery:
    name: Headphone Battery
    min: 0
    max: 100
    step: 1
    unit_of_measurement: "%"
    icon: mdi:headphones

Then the automation to receive updates from the webhook:

- alias: Update Headphone Battery
  triggers:
    - trigger: webhook
      webhook_id: "headphone-battery-update"
      allowed_methods: [POST]
  actions:
    - action: input_number.set_value
      target:
        entity_id: input_number.headphone_battery
      data:
        value: "{{ trigger.json.battery_level }}"

I have many other simple automations for example turning lights on and off at set times, but the ones listed here are the more interesting ones I thought it would be worth sharing. I hope this can be of help or inspiration to someone else.

I’ve been fire spinning for just under a year. After my first time spinning with fire, I immediately bought a set of basic fire poi for under £20. These were nice enough as a starter set, allowing me to spin at occasions other than the fire clubs of nearby cities. But as my skills developed, their limitations became apparent.

The problems with my starter set

My first issue was that the heads were small and, when combined with the chains, meant that not much weight was at the end. This made spinning feel different from my homemade practice poi, adding an extra hazard to be aware of.

I also found that as my skills improved and I was able to perform a wider variety of tricks, the burn time became annoyingly short. I’d run out of fuel before I’d run out of performance.

Enter the TechPro Cathedral

The Firetoys TechPro Cathedral Fire Poi are a significant improvement. At around £70 they’re a considerably higher investment than my starter set—probably too much if you’re not sure fire spinning is for you—but I’m delighted I made the upgrade.

The technora cords are lovely and, combined with the heavier heads, mean they behave much more like my practice poi. I’ve found performing tricks much smoother and easier than before. There’s a small section of chain between the head and the technora rope, which is great at letting the heads get dipped into the fuel whilst keeping the fuel off the rope. The chain is long enough to maintain this separation, but short enough not to interfere with the weight distribution or feel of the poi.

The heavier heads don’t feel burdensome—the lack of chains elsewhere actually helps—and I really like the extra weight at the business end.

It’s disappointing how few fire poi are sold with technora from UK suppliers. Even Firetoys seem to sell many more sets with chains rather than rope. I think rope should be the default, possibly with some “budget friendly” chain options for those who want them.

Cathedral flames

The wicks are much larger as well. I’m enjoying the bigger flames and louder roars, though I suspect these would have been quite intimidating for my first few spins. My wife commented on how much brighter the flames were and that they lit up my face better.

I didn’t test the maximum burn time because I ended the burn early using a fire blanket, but it was long enough for me to go through all the tricks I’m currently confident to perform—a marked improvement over my previous set.

Nice touches

The glow-in-the-dark handles are also a nice addition. I prefer holding them over the finger loops and, while I’m not yet ready to start tossing the poi, it’s nice to know that the equipment I have is capable when I am.

One minor inconvenience

My main issue with the new poi isn’t a fault of the poi themselves, but of my setup. I had a small paint tin and fuel container that worked nicely for the old small-headed poi, but the cathedral heads are much larger and don’t fit my existing setup. I need to source larger dipping and fuel storage containers.

Verdict

These are an excellent upgrade. The technora cords, heavier heads, and larger wicks have made spinning more enjoyable and my performances more confident. If you’re past the beginner stage and ready to invest in better equipment, I’d thoroughly recommend them.

Lots of people have asked how I feel, and to be honest, there wasn’t much I was feeling at first.

There were occasions when it started to feel real. Emptying out the lockers and drawers. Bringing my books and course notes home. Saying goodbye to the various shifts, each time knowing it was the last time I would see them.

I think the sheer amount of work I was attempting to get done in the last few weeks kept me from truly thinking about it. Even within the last hour before leaving, I was still updating documentation and trying to complete one last job to make life easier for those staying behind a bit longer.

But that changed once I got home.

While I am sad, my overwhelming emotion is one of gratitude. I have been very lucky these last 14 years. Lucky that I have somewhere to go to immediately. I’ve definitely matured during my time at Grangemouth and learnt a lot along the way. Thanks to everyone who has helped me along the way.

The problem is that strong winds we experiance have a tendency to blow out the gas flame. Not only can this be dangerous, but it’s also incredibly frustrating to discover that the stone has gone completely cold by the time I’ve noticed. This has been bothering me for quite some time, but I have finally got around to doing something about it.

The Problem

I wanted a reliable flame detection method to warn me before everything cooled down.

I have now wired up a thermocouple and connected this to my home-assistant to create an automated monitoring system.

The Hardware

I had an unused M5Stack Atom Echo lying about, which I hoped would be suitable for the job. I paired it with a K-type thermocouple from Amazon - a temperature probe that can handle the high temperatures inside a pizza oven.

The wiring was mostly straightforward, though the Grove connector only has 4 pins and the MAX6675 requires 5. This meant I had to run an extra wire directly into the back of the Echo, which is a bit of a pain as it comes out at an odd angle compared to all the other wires. I connected the thermocouple to the MAX6675 amplifier board that came with the thermocouple I bought, then wired that to the Atom Echo.

I tucked the thermocouple probe into the back of the oven where it wouldn’t get in the way, and left the electronics safely outside. I am not measuring the stone temperature, or any other particular temperature, but close enough to the flame that I should see any changes quickly should the flame go out.

Here is the yaml configuration I added to the atom echo in the ESPHome Device Builder:

# SPI configuration for MAX6675 temperature sensor
spi:
  clk_pin: GPIO32  # Grove SCL pin
  miso_pin: GPIO26 # Grove SDA pin

# Temperature sensor
sensor:
  - platform: max6675
    name: "Pizza Oven Temperature"
    cs_pin: GPIO25   # Spare pin - needs wire access
    update_interval: 5s
    unit_of_measurement: "°C"
    accuracy_decimals: 1
    filters:
      - median:
          window_size: 5
          send_every: 5

The Data

Here’s what an evening of pizza-making looks like in numbers:

The graph shows the temperature throughout the evening. You can see the initial heating phase as the gas flame gets the oven up to temperature, reaching about 350°C. I suspect the brief gap in data when the oven was up to temperature was caused by my USB power bank going to sleep. There is some variation in temperature for most of the cooking period. Then there’s the dramatic drop when we finished cooking and turned the gas off.

With this data, I think I would struggle to work out where to place an ‘alarm’ for detecting that the fire has gone out. During the heating, it spent all of the time above 300°C, but there was one point when the temperature dropped close to that temperature (when the oven door was open and there was a short sudden downpour of rain). I suspect if I set my alarm at 300°C, It would be susceptible to spurious alarms, as well as taking some time before triggering during a genuine flame out.

Luckily home assistant makes it easy to track a derivative value, in this case rate of change of temperature:

In this case you can see four distinct dips where the door was opened to put pizzas in and take them out. The last dip is much more dramatic the final dip, much larger is the flame out. In this case, the drop is almost instant. If I set the alarm at -0.4°C/s, it should generate an alarm within a minute of the flame out, but hopefully not get triggered by normal fluctuations.

The Fun Bit

Once I had the temperature monitoring working, I couldn’t resist adding fun with the automation.

Now when I light the gas, my Home Assistant voice in the kitchen plays “The Heat Is On” by Glenn Frey from the Beverly Hills Cop soundtrack.

More importantly, when a flame-out occurs, it plays “Fire’s Gone Out” by Chris Duarte Group, in this case queued up to the words “I think this fire’s gone out” which seems perfect for the situation.

Next Steps

Now that I’ve got the basic monitoring working, there are a few practical improvements I need to make. I’ll need to monitor it a few more times and perhaps tweak the alarm limits or timing to avoid spurious alerts whilst also not missing any genuine flame-outs.

I also need to create a proper enclosure for the electronics to protect them from rain, ideally finding a way to mount it permanently - but it needs to be heat resistant since the oven surface gets really hot.

I may also need to find a better portable power supply or find a way to stop the USB power bank from going to sleep.

But for now, I’m quite pleased with my musical pizza oven alarm. It’s solved the original problem of not knowing when the gas had gone out, and it’s added a bit of theatre to our weekly pizza evenings.