I was tidying up my desk last week and pulled open the drawer where old tech goes to die. Tangled cables, a Pi Zero I bought for a project I never started, and a BlinkStick Square — a tiny USB board with eight RGB LEDs on it. I'd bought it years ago, played with it for an afternoon, and forgotten about it.

I plugged it into my Raspberry Pi 5 running Home Assistant, half expecting nothing to happen. The LEDs lit up white. Still alive.

Home Assistant used to have a BlinkStick integration, but it was removed a while back as part of a cleanup of unmaintained components. That meant no config flow, no UI, nothing. If I wanted this thing to do something useful, I'd have to write the integration myself.

Building the Integration

The BlinkStick hardware is straightforward. It's a USB HID device — no serial port, no special drivers. The Python blinkstick library handles the low-level communication: set a color, set brightness, run an effect. The challenge was wrapping that in a proper Home Assistant component with config flow, device discovery, and a clean light entity.

I set up the integration as a custom component with a few goals:

• Standard light entity — full RGB color picker, brightness slider, works with any automation
• Effects — Pulse, Morph, and Blink, selectable from the effects dropdown like any other HA light
• Config flow — add via UI, no YAML needed, with USB auto-discovery for plug-and-play setup
• Multiple devices — each BlinkStick is identified by serial number, so you can have several

The trickiest part was the effects. HA light entities expect turn_on to return quickly, but effects like Pulse run continuously. I ended up running effects in background threads with a threading event for clean cancellation — when you change the color or turn off the light, the running effect stops immediately without any awkward delay.

The Weather Idea

A working LED is nice, but a working LED that does nothing useful is just a night light. I wanted it to tell me something at a glance — something I check every morning anyway.

Weather.

The concept is simple: the LED color represents the current weather condition, and the brightness represents how the temperature compares to what's normal for this time of year. One look, two pieces of information.

Color Mapping

Each weather condition maps to a color:

• Green — sunny or clear. Good day ahead.
• Yellow — partly cloudy or overcast. Not bad, not great.
• Purple — fog. Wrap up, drive carefully.
• Blue — rain. Grab an umbrella.
• White — snow or sleet. Layer up.
• Red — lightning or thunderstorm. Maybe stay in.
• Orange — windy. Hold onto your hat.

After living with it for a few days, I found I stopped thinking about the colors consciously. Purple in the morning just meant "it's foggy" without reading anything or pulling out my phone.

Brightness as Temperature

Color alone doesn't tell you whether it's a mild 15 degrees or a bitter 2 degrees. That's where brightness comes in.

The automation compares the current temperature against UK monthly averages — 4 degrees in January, 20 in July, and so on. If the temperature is well above average, the LED is bright. Well below, it's dim. Around normal, it sits in the middle.

In practice: a bright green LED in March means an unusually warm sunny day. A dim blue means rain and cold — colder than you'd expect for the month. The brightness gives context that color alone can't.

The thresholds work out to roughly:

• Very bright — more than 5 degrees above the seasonal average
• Bright — 2 to 5 above
• Medium — within a couple of degrees either way
• Dim — 2 to 5 below
• Very dim — more than 5 below

The Dashboard

An LED on a desk is fine for me, but the rest of the household wanted to know what the colors meant without memorising a table. So I built a small dashboard setup in Home Assistant.

The main view has a compact markdown card that shows the current state in one line:

BlinkStick Purple -- Medium / 6.8 degrees vs 8 degrees seasonal avg

Below that sits a native weather card showing the full forecast, so you get both the at-a-glance LED summary and the detailed breakdown in the same view.

Tapping "legend" opens a subview with three panels: a color-to-condition table on the left, a brightness-to-temperature table on the right, and the monthly seasonal averages along the bottom. I used card-mod to strip the table borders and stretch everything to full width — it took a few rounds of fighting with shadow DOM styles, but the end result is clean and readable. The card YAML is included in the repo README if you want to replicate it.

Sharing It

The integration itself is a custom component installable via HACS: ha-blinkstick. It works with any BlinkStick model — Square, Strip, Pro — anything with the standard USB vendor and product ID.

The weather automation is packaged as a Home Assistant Blueprint, so you can import it with one click from the repository README. It takes three inputs: your weather entity, your BlinkStick light entity, and optionally your own monthly temperature averages if you're not in the UK.

Was It Worth It?

Honestly, yes. Not because the world needed another weather display, but because it turned a forgotten gadget into something I actually look at every day. It sits on my desk, quietly glowing, and I know what to expect outside before I open the curtains.

If you've got a BlinkStick in a drawer somewhere, dust it off. It takes about ten minutes from plugging it in to having a working weather display.

Last year my partner and I both picked up Samsung phones. Each came with a free Harman Kardon Citation One speaker as part of a promotion. We set them up, connected Google Assistant, and were genuinely impressed. The sound quality for a compact speaker is excellent — warm, balanced, and loud enough to fill a room.

Within a week I'd ordered three more. Kitchen, hallway, back bedroom, master bedroom, living room — music and voice control everywhere. For the price, it felt like a steal.

The Problem

The joy lasted about four days.

We started noticing that speakers would randomly stop responding to voice commands. You'd say "Hey Google, what's the weather?" and instead of a helpful answer, you'd get:

• "Something went wrong. Try again in a few seconds."
• "Sorry, try logging in via the Google Home app."
• "There was a glitch. Try again in a few seconds."

The strange part: Bluetooth streaming still worked fine. Spotify Connect still worked. The speaker wasn't crashed — Google Assistant was just... frozen. The only fix was to physically unplug the speaker, wait a few seconds, and plug it back in.

With five speakers, this became a daily chore. Someone would walk into the kitchen, try to ask for a timer, get the frozen response, sigh, and pull the plug. Not exactly the smart home dream.

Digging Deeper

I run Home Assistant on my home network, so I had a decent starting point for investigation. The Citation One speakers run a variant of Google's Cast platform, which exposes a local HTTP API on port 8008 and an HTTPS service on port 8443.

I started poking at both ports on a known-frozen speaker versus a healthy one. The difference was immediate and consistent.

Healthy speaker (Master bedroom):

POST /setup/get_app_device_id  →  77ms
POST /setup/reboot             →  31ms
GET  https://:8443/eureka_info →  45ms

Frozen speakers:

Kitchen:      get_app_device_id=5000ms (timeout!)  reboot=42ms
Back bedroom: get_app_device_id=2544ms             reboot=53ms
Hallway:      get_app_device_id=38ms               reboot=3106ms

Three symptoms, and here's the interesting bit — different speakers exhibited different ones. The Kitchen speaker was slow on get_app_device_id but fast on reboot. The Hallway speaker was the opposite. A single-endpoint check would have missed half of them.

I also discovered a third indicator: port 8443, the HTTPS service that powers Google Assistant's cloud communication. On a frozen speaker, it hangs completely — the connection times out after a few seconds. On a healthy speaker, it responds instantly. This turned out to be the most reliable signal of all, because some frozen speakers still responded normally on port 8008.

Building the Detection

Armed with three reliable symptoms, I built a Home Assistant custom integration: ha-hk-citation.

It does three things every five minutes:

1. Discovers speakers via mDNS — scans for _googlecast._tcp.local. services and filters to HK Citation models
2. Probes each speaker with three checks — two POST requests on port 8008 (measuring response time) and one HTTPS request on port 8443 (checking for timeout)
3. Exposes a binary sensor per speaker — Connected means healthy, Disconnected means frozen

No configuration needed beyond clicking "Add Integration". Speakers appear automatically as they're discovered on the network. If a speaker gets a new IP address from DHCP, the integration handles it transparently — your automations don't break.

The Automation

Detection is only half the solution. The other half is doing something about it.

I ordered five Sonoff MINIR4M smart switches — one for each speaker's mains plug. They're tiny enough to fit behind the wall socket, run on Wi-Fi, and integrate natively with Home Assistant.

Now the clever part. You don't want to reboot a speaker the instant it freezes. These speakers play a boot chime when they restart, and if someone's asleep or in a meeting, that's not ideal. So the automation looks like this:

• Trigger: binary_sensor.kitchen_speaker_health turns to Disconnected
• Conditions: It's daytime (8am–10pm) AND nobody is home (presence detection via phone GPS)
• Action: Turn off the smart plug, wait 10 seconds, turn it back on

If the speaker freezes at night, it waits until morning. If someone's home, it waits until they leave. The speaker reboots at a convenient time, and by the time anyone tries to talk to it, it's already back and responsive.

The Result

After running this setup for a couple of weeks, the experience is night and day. Every speaker responds when spoken to. The freezes still happen — that's a firmware issue I can't fix — but the recovery is automatic and invisible.

The integration is open source and installable via HACS: github.com/azgooon/ha-hk-citation. If you have Citation speakers and a Home Assistant instance, give it a try. The speakers deserve it — they really do sound great when they're actually working.

Docker gets all the hype, but LXC containers are an underrated option for hosting small sites. They're lighter than VMs, give you a full Linux userspace, and on Proxmox they're dead simple to manage.

For a flat-file CMS like Statamic, an LXC container is perfect: you get full filesystem access, easy snapshots for backups, and none of the Docker networking complexity.

The Setup

Here's the high-level architecture:

1. Proxmox host runs on a dedicated machine
2. LXC container (Debian) hosts PHP, Nginx, and the Statamic app
3. Cloudflare Tunnel handles HTTPS and DNS
4. Git deploy pushes content and code changes

Container Configuration

I'm using a minimal Debian LXC with:

• PHP 8.2 with common extensions (mbstring, xml, curl, zip)
• Nginx as the web server
• Composer for PHP dependency management
• Node.js for building frontend assets

The container uses about 256MB of RAM at idle — much lighter than a Docker setup with separate containers for each service.

Deployment Flow

The deployment is simple:

# SSH into Proxmox, then into the container
ssh root@proxmox "pct exec 103 -- bash -c '
    cd /var/www/sobesto-blog
    && git pull
    && composer install --no-dev
    && npm run build
    && php artisan cache:clear
    && php please stache:clear
'"

Since Statamic is flat-file, there are no database migrations to worry about. Pull the code, build assets, clear cache — done.

Backups

Proxmox makes backups trivial. I snapshot the entire container weekly, and since all content is in git, I have a second layer of backup automatically.

Trade-offs

The main downside vs. a managed platform is that you're responsible for security updates and server maintenance. But for a personal blog, the control and simplicity are worth it.

LXC containers are one of those tools that, once you use them, you wonder why you ever reached for anything heavier.