Back in 2021, I wired up data from Buienalarm and Buienradar through Node-RED and a big pile of Jinja2 templates to get a rain forecast graph on my Apple Watch: eight Unicode block characters showing the next two hours in 15-minute chunks, glanceable without unlocking the phone. It worked, and I used it every day for years. While the Unicode graph as a concept never really took off in the Home Assistant community, I think a lot of Dutch people (spoiler: we are very obsessed with rain) enjoyed having this graph on their wrist.
But I’m not a developer, and this project had all the rough edges you’d expect from an amateur. It was built in bits and pieces, out of flows and templates, and very hard to maintain. Every tweak and bug-fix meant hand-editing Jinja and hoping I hadn’t broken whitespace somewhere. People reported issues I couldn’t reproduce, and every so often a Home Assistant template engine update would break everything all over again. It was basically held together with spit and duct-tape.
I’ve been experimenting with Claude Code and Home Assistant a lot this year, so this summer I finally did the thing I should have done originally: made this project work as a proper Home Assistant custom integration. I’m pleased to say that after some focused attention from Claude, Buienwatch is now on GitHub and installable through HACS.
What it is
The blog I wrote back in 2021 goes into all the details if you’re interested, but the TL;DR is: if you want to know whether it will rain on you in the next 2 hours, this integration creates a simple 8-character bar graph that you could display on your Apple Watch as a corner complication. The bar graph gets generated based on the data that Buienradar and Buienalarm, two rain forecast services in the Netherlands, would have for your current location. So instead of checking a weather app, a glance at your wrist tells you whether to grab an umbrella before you’re out the door. The “why” for building this in the first place hasn’t changed since 2021, only the “how.”
What changed
The core idea is still the same — follow a person or device_tracker around, ask Buienradar and Buienalarm what the weather will look like wherever that entity currently is, and turn the answer into a text-based graph a watch complication can display. But almost everything about how it does that is different:
- It’s simply a device. Each tracked person becomes their own Home Assistant device, with everything exposed as sensors, a config flow for setup, and a device-page dropdown for options. No templates, no Node-RED, not all these separate things you have to keep working.
- More than one visualization option. My original template only accounted for the Unicode bar graph. But what if you didn’t want a corner complication, but a circular gauge? Or a start/stop time? Buienwatch exposes sensors that can be used for other complication formats.
- Both sources, reconciled correctly. Buienradar and Buienalarm report on independent schedules with different formats. My original code didn’t even bother trying to match them up correctly. But Buienwatch snaps both onto a shared 5-minute grid and takes the worst-case value per slot where their times overlap. This is deliberate: I’d rather have the watch overstate a drizzle than tell me it will be dry and get caught unaware.
- Source switching for different scenarios. Buienradar-only, Buienalarm-only, Combined, or one of two primary-with-fallback modes that only bother the second source if the first one errors. Helpful if you prefer one source over another, but especially relevant when traveling outside of the Netherlands, where each source may or may not have data for your area.
- Actual failure handling. The original template was finicky and could easily result in an error message displayed on your watch. Now, a source timing out or returning garbage no longer means you see a broken template, it’s just logged and the integration carries on with whatever data it does have.
The bar graph, revisited
The complication itself is still eight characters wide, with increasingly higher Unicode blocks mapped to intensity buckets. What’s changed is where the bucket boundaries come from.
The original template used nice round numbers (0.1 / 0.5 / 1.0 / 1.5 / 2.0 / 3.5 / 5.0 / 10.0 mm/h) which were chosen arbitrarily but looked reasonable on paper. When you look at the real distribution, Buienradar’s conversion formula (10 ** ((code - 109) / 32)) turned out to only produce distinct mm/h values, not a continuum. For example, the 0.1 – 0.5 mm/h bucket happened to lump dominant Buienradar values together, so it contained roughly 60% of all rain commonly shown, while the buckets just above it were starved for data. The bar was technically accurate, but practically useless at distinguishing “barely” from “actually raining.”
The pragmatic fix was not so much “compute better statistics” but more “look at where the gaps in the data actually are”. We matched the bucket boundaries to the formulae’s geometric structure: split the 0.1 – 10.0 mm/h range into 7 buckets at a constant ratio, so every bucket represents roughly double the rain rate of the one before it. With some rounding that gives us the buckets of 0.1 / 0.2 / 0.37 / 0.72 / 1.4 / 2.7 / 5.2 / 10.0 mm/h instead. Not nearly as nice to look at in numbers, but much more useful to look at as a graph.
Where it does and doesn’t work
Buienradar has data for the Netherlands and Belgium only, so it returns a plain “not found” error for anywhere else, which the integration treats as a normal failed fetch rather than crashing. Buienalarm answers your requests everywhere on Earth, but a look at its response shows it’s backed by three different quality tiers of data: real radar data for NL/BE and just over the German border, a wider Western-Europe radar composite when you travel a few countries further away, and a coarse global satellite estimate for everywhere else. So Buienalarm would technically give you a rain forecast in Tokyo or New York, but I wouldn’t trust it the way I trust it fifty kilometers from home.
Installing it
- HACS: add
GuySie/buienwatchas a custom repository (category: Integration), install “Buienwatch,” restart. - Manual: drop
custom_components/buienwatchinto your config’scustom_components/folder, restart.
Then Settings > Devices & Services > Add Integration > Buienwatch, pick the person or device_tracker to follow, and repeat for anyone else you want tracked. Poll interval defaults to 5 minutes and is adjustable afterwards from the integration’s options.
The complication itself
Nothing changes here from the original post’s setup — point a Home Assistant Companion app Text Image complication at Buienwatch’s Forecast sensor state, and you’ve got the same rain bar on your wrist, just backed by something that no longer requires you to remember how templates work.
The usual disclaimer
This integration has been fully coded using Claude Code, and while I push Claude to follow all the current Home Assistant and coding best practices, there is no guarantee that I can personally give you about code quality whatsoever. It is released as-is under MIT license. If you are against the use of AI, you should not install any of my integrations. That said, if you trusted and installed the code I previously wrote manually, I’m pretty sure you were running much higher risks than you do running Claude’s new work. I’m still a marketer, not a developer, after all.