DEV Community: Michael Bernhart

Tapo H100: Cellar Humidity Monitoring in Home Assistant

Michael Bernhart — Fri, 07 Aug 2026 06:21:39 +0000

Cellars sweat. On a warm humid day the air you let in is warmer than the cold concrete, and the moment it touches a cold surface it gives up its water. That's condensation, and over enough summers it's how a basement grows mould in the corners you never look at. I wanted a number that warned me before that happened. The catch I already knew going in: a raw relative-humidity reading isn't that number.

This is Part 08 of the series. The hub was already in the house running other things, and the install was genuinely the easy 20 minutes. The part worth writing about is what came after the sensor showed up: turning its two raw readings into a dew-point spread, and deciding when that spread means "act" versus "ignore the spike."

Why the H100, and why 868 MHz is the whole point

The hub is a TP-Link Tapo H100, a little smart hub that acts as a radio bridge for TP-Link's battery sensors — the T100 motion, the T110 contact, and the one I care about here, the T310 temperature/humidity sensor. Here's the load-bearing detail, and the reason I reached for this hub instead of a WiFi sensor: the Tapo sensors don't talk WiFi. They talk to the H100 over 868 MHz sub-GHz radio.

That matters in a cellar more than anywhere else. Sub-GHz is long-range and punches through concrete and floors in a way 2.4 GHz WiFi simply doesn't. There's no WiFi worth having down in my cellar, and no interest in running a repeater into a damp room just to read a sensor. The T310 sits down there on a battery, the H100 upstairs where the network is, and the radio link between does the work. One H100 supports up to 64 sensors — for a house, more headroom than I'll ever use.

Getting the sensors into Home Assistant

The native TP-Link integration doesn't expose the H100's child sensors — it's built for the plugs and bulbs. The one that works is the community Tapo Controller integration (petretiandrea's TP-Link Tapo), installed through HACS, the same custom-integration store I've leaned on throughout this series. If you've followed along, you already have HACS; this is one more repository to add.

Setup is by the hub's local IP plus your Tapo cloud account email and password — the honest catch worth flagging, since it means the initial pairing needs internet rather than a local-only token. Once paired, every sensor on the hub is auto-discovered. Each T310 shows up as two entities — a sensor.tapo_temperature_* and a sensor.tapo_humidity_* — plus a battery sensor per device. I renamed the cellar one's children by location, so I'm working with sensor.tapo_humidity_keller rather than a random suffix. Do that early; it makes every template downstream readable.

Relative humidity is the wrong trigger — dew point is the right one

Here's the engineering beat. Alert on "humidity above 70%" and you get a sensor that screams every muggy afternoon and tells you nothing about whether the cellar is actually in danger. Relative humidity is relative to temperature; 75% RH in a cool cellar and 75% RH in a warm room are completely different amounts of water in the air. What actually predicts condensation is the dew point — and the spread between it and the coldest surface in the room. When that spread gets small, you're close to the wall going wet.

Home Assistant doesn't hand you a dew point. But it hands you temperature and humidity, and dew point is arithmetic on top of those — the Magnus formula. This is exactly the pattern I've used elsewhere in my config: I already keep a templates.yaml where raw sensors get turned into derived ones — scaling a raw boiler register, computing PV percentages like self-consumption and autarky. A cellar dew-point sensor is the same move, with a different equation, defined as a template sensor with its own unique_id, unit, and device_class. Here's the cellar one.

# Derived dew-point sensor for the cellar T310 (templates.yaml style)
template:
  - sensor:
      - name: "Taupunkt Keller"
        unique_id: taupunkt_keller
        unit_of_measurement: "°C"
        device_class: temperature
        state: >
          {% set t = states('sensor.tapo_temperature_keller') | float(0) %}
          {% set rh = states('sensor.tapo_humidity_keller') | float(0) %}
          {% set a = 17.27 %}{% set b = 237.7 %}
          {% set g = (a * t) / (b + t) + log(rh / 100) %}
          {{ ((b * g) / (a - g)) | round(1) }}

A word on the thresholds, to be honest about what's measured versus guidance. These are general building-science values, not something I calibrated against my own walls: relative humidity becoming a concern around 65–70% RH when sustained, mould risk climbing once surface RH sits above roughly 70–80%, and a dew-point spread under about 3 °C as the real "condensation imminent" line. Treat them as starting dials, not gospel. The point of computing dew point locally is that you can tune them — you own the formula and the trigger.

Making the alert fire on a real problem, not a spike

The other decision worth more than the formula: timing. Humidity is noisy — open a door, dry some laundry nearby, and the reading jumps for a few minutes then settles. If the automation fired on a single high sample I'd train myself to ignore it within a week. So the trigger only fires on a sustained breach — humidity above threshold held for a continuous 30 minutes. That debounce is the difference between an alert I trust and one I mute.

And then the part I genuinely like about this hub: the alert needs no extra hardware. The H100 isn't just a passive bridge — it exposes a switch for its built-in siren, a select for the alarm sound, a number for volume, and an RGB night-light ring. So a humidity warning can drive the hub's own light: flash it red when the cellar crosses the line. No buzzer to wire, no smart bulb to buy — the thing that bridges the sensor also announces the problem. That's three escalation paths I get for free: a Home Assistant push, the siren switch, and the RGB ring.

# Flash the H100's own light red when cellar humidity is too high
automation:
  - alias: "Keller: Feuchtigkeit Warnung"
    trigger:
      - platform: numeric_state
        entity_id: sensor.tapo_humidity_keller
        above: 70
        for: "00:30:00"
    action:
      - service: light.turn_on
        target:
          entity_id: light.tapo_h100_light
        data:
          rgb_color: [255, 0, 0]
          brightness: 128

That red is a deliberate [255, 0, 0] at brightness 128 — bright enough to catch your eye on the stairs, not a floodlight. For a slow-moving problem like cellar damp, a quiet push plus a red glow is plenty; the siren I keep for things that actually want to be loud.

When sensors don't show up

Three things account for almost every "my T310 isn't in Home Assistant" moment. Most often the sensor simply isn't paired to the H100 in the Tapo app yet — the integration only sees what the hub already knows, so pairing happens in the app first, discovery second. Next is a flat battery; these are coin-cell devices and a dead one just goes silent. And sometimes Home Assistant needs a restart to pick up a freshly paired device. When none of that explains it, I filter the log to tapo and read what the integration is actually complaining about — usually an auth hiccup against the cloud account or a hub it can't reach.

Worth being fair about the trade-offs. The cloud-account login is the annoying part of an otherwise local setup; the 64-sensor ceiling is a non-issue for a house. But the radio is the reason this works at all: a battery sensor on the wrong side of a concrete wall, reporting periodically rather than being polled, reaching a hub upstairs over 868 MHz — a problem WiFi sensors don't solve. The dew-point template and the 30-minute debounce were the new bits I built on top; the hub and its auto-discovered entities were already running. That's the honest shape of it: a small cheap sensor and a bit of arithmetic turned a reading I couldn't act on into a warning I can.

Shelly in Home Assistant: Local Switching & Energy Metering

Michael Bernhart — Tue, 04 Aug 2026 18:42:17 +0000

I didn't put Shelly Plus 1PM and 2PM behind my wall switches for the app or the cloud. I put them there because each one quietly does two jobs at once: it switches a circuit locally, and it measures exactly what that circuit draws. The moment I had them wired in, every light group and every roller shutter in the flat became both controllable AND measurable in Home Assistant — with no separate energy meter and, deliberately, no cloud in the loop.

This is the part most Shelly write-ups skip: the metering isn't a bonus, it's the reason to use them. This is how I set them up, kept them fully local, wired the physical switches so they still work like switches, and pulled per-channel energy into the HA Energy Dashboard.

Why the Plus series for in-wall use

The Plus 1PM and 2PM are Gen2 devices. That matters: they speak a local RPC API over HTTP and WebSocket, they're supported by the native Home Assistant Shelly integration out of the box, and nothing about them needs the internet once they're on your Wi-Fi. The 1PM is a single relay with power metering — I use it behind light circuits. The 2PM has two relays with metering and a dedicated cover/roller-shutter mode — that's what sits behind my shutters.

The catch you plan for up front: both need a neutral wire in the switch box. Older installations often don't have one at the switch, so check before you order. If the neutral is there, the rest is easy.

The first thing I change: kill the cloud, pin the IP

Straight out of the box I do two things in the Shelly web UI (just browse to the device's IP). First, I disable Bluetooth and Cloud under Settings — I don't want the device reaching out to anything, and Home Assistant talks to it directly on the LAN. Second, I give it a fixed address via a DHCP reservation on my router, so the native integration never loses it after a reboot.

That's the whole hardening story. No firmware flashing, no third-party firmware — stock Shelly firmware with the cloud switched off is already a fully local device. It keeps working if my internet drops, which for anything wired into a wall is exactly what I want.

Adding them to Home Assistant (no MQTT required)

The native Shelly integration finds Gen2 devices over mDNS. In Home Assistant I go to Settings, Devices & Services, and the Plus 1PM/2PM usually show up under discovered — one click to add. If they don't auto-discover, adding by IP works just as well. Each device brings in a switch entity per channel plus sensors for power and cumulative energy.

You can run them over MQTT instead, and I do that for a couple where I want the reporting cadence fully under my control. But for most people the native integration is the right answer: it's local push, it's zero-config, and it exposes the energy sensors HA's dashboard needs. MQTT is the escape hatch, not the default.

The switch input mode that makes or breaks it

Here's the setting that decides whether this feels great or fights you: the input mode. By default the physical switch directly toggles the relay ("follow"). That's fine for a dumb light. But behind a switch I want to automate, I set the input to detached — now the wall switch no longer hard-wires the relay; it just sends a button event to Home Assistant, and HA decides what happens. The relay still switches on command, so nothing is "lost" — the physical switch becomes an input, not a hard override.

For a 2PM in cover mode you leave the inputs mapped to up/down, but for the 1PM behind a lamp, detached plus a Home Assistant automation is what lets one switch do more than one thing (single press = this light, double press = the whole room).

# One wall button, two actions — Shelly Plus 1PM input detached
alias: Hallway switch
triggers:
  - trigger: state
    entity_id: event.hallway_shelly_input_0
    attribute: event_type
    to: single_push
    id: single
  - trigger: state
    entity_id: event.hallway_shelly_input_0
    attribute: event_type
    to: double_push
    id: double
actions:
  - choose:
      - conditions: "{{ trigger.id == 'single' }}"
        sequence:
          - action: light.toggle
            target: { entity_id: light.hallway }
      - conditions: "{{ trigger.id == 'double' }}"
        sequence:
          - action: light.turn_off
            target: { entity_id: all }

Per-channel energy in the Energy Dashboard

This is the payoff. Every Plus device reports active power in watts and a cumulative energy total per channel. In Home Assistant that total energy sensor is exactly what the Energy Dashboard wants: Settings, Dashboards, Energy, then add each Shelly channel under "Individual devices". Suddenly the hallway lights, the office circuit and the bathroom shutter each show up as their own slice of the day's consumption.

What surprised me: it wasn't the lights that mattered, it was the standing draw. A 2PM behind a shutter that hadn't moved in three days was still showing a small constant wattage — the little things you only find once you can actually see per-circuit numbers instead of one house total. That per-room visibility is the whole reason I'd tell anyone to spend the extra few euros on the PM variant over a plain relay.

Roller shutters on the 2PM

For shutters, the 2PM's cover mode turns the two relays into up/down with a calibration run so Home Assistant gets real position control — a cover entity with a 0-to-100 percent slider, not just up/stop/down. Run the calibration once from the Shelly UI (it times the full travel), and after that HA can send "close to 40 percent" and mean it. I drive mine from sun elevation and an indoor temperature sensor so the south side closes before the afternoon heat rather than after.

Gotchas I hit

Two things cost me time. First, power readings: the Plus PM devices report real active power, but if you're comparing against an old cloud screenshot or a non-PM Shelly, don't expect the numbers to line up — apparent versus active power is a real difference on inductive loads. Second, keep firmware current but read the changelog before a mass update; a Gen2 firmware bump once changed an entity's unique_id behaviour and I'd rather stagger updates than have HA re-discover a dozen devices at once.

And the obvious one worth repeating: a neutral wire is non-negotiable for these. If your switch box doesn't have one, that's a wiring job before it's a Home Assistant job.

FAQ

Do I need a Shelly account or the cloud?

No. With the native Home Assistant integration everything runs on your LAN. I disable Cloud on every device — Home Assistant discovers and controls them locally, and they keep working with the internet unplugged.

Native Shelly integration or MQTT — which should I use?

Start with the native integration: it auto-discovers Gen2 devices, it's local push, and it exposes the energy sensors the dashboard needs. Reach for MQTT only if you want full control over the reporting cadence or you're consolidating everything onto one broker.

Can I still use the physical wall switch?

Yes — that's the point of detached input mode. The switch keeps working, but instead of hard-wiring the relay it sends a button event to Home Assistant, so one switch can trigger automations while the relay stays independently controllable.

Where this fits

Shelly Plus 1PM/2PM turned every circuit in the flat into something I can both control and measure, locally, without adding a single cloud dependency. The metering side is what makes them an energy story, not just a switching one: they feed the same Energy Dashboard I use for solar and the inverter. If you're building that dashboard out, my writeups on pulling PV self-consumption and autarky into HA and steering solar surplus into hot water pair naturally with per-room Shelly metering. And when you're hunting for the dashboard cards to visualise all of it, the HACS directory is where I go looking.

I Built an Awesome List for Open-Source GEO Tools. The Licence Check Cut the Popular Ones.

Michael Bernhart — Thu, 30 Jul 2026 11:23:47 +0000

Generative Engine Optimization is the unglamorous name for a real problem: your content now has to be findable, parsable and citable by systems that answer instead of link. ChatGPT, Perplexity, Claude, Google AI Overviews. The original GEO paper from KDD 2024 showed the levers differ from classic SEO — citations, statistics and quotable structure move the needle where keyword density does essentially nothing.

The tooling around it is almost entirely paid SaaS. There are two existing awesome-lists for GEO and both are good, but their tools sections read like a funding announcement: Profound, Otterly, Goodie, Semrush. Useful if you have a budget. Useless if you want to read the source and run it yourself.

So I built the other half: Awesome Open GEO — 62 entries, one criterion, awesome-lint clean.

The criterion

Every entry has to be free to run and published under an OSI-approved licence.

That sounds like a formality. It is the entire list.

What it cut

Two of the most-linked tools in this space didn't make it, and explaining why is more useful than the list itself.

firecrawl/llmstxt-generator — 534 stars, genuinely handy, generates llms.txt and llms-full.txt for any site. It has no LICENSE file. Not a restrictive one. None. Under default copyright law that means all rights reserved: you have no granted right to use, modify or redistribute it, however public the repo is and however obviously the authors intended you to.

Canonry — 99 stars, an AEO monitoring platform, source fully readable. Licensed FSL-1.1-ALv2, the Functional Source License. Source-available, converts to Apache-2.0 after two years, and a perfectly reasonable commercial choice. It is not open source today, and the OSI has been clear about that class of licence.

Neither of those is a criticism of the projects. A missing licence file is usually an oversight, and FSL is a deliberate, defensible business decision. But a list that calls itself open-source has to actually check, or the label means nothing.

I found the same pattern repeatedly: repos described as "open source" in their own README with no licence in the tree, and "open" platforms whose licence quietly excludes competing use. If you're picking a tool to build on, that distinction is the difference between a dependency and a liability.

How the list was actually vetted

I did not want to hand-pick from memory, so:

A GitHub API sweep — about 15 topic and keyword queries (topic:generative-engine-optimization, topic:llms-txt, topic:answer-engine-optimization, topic:ai-visibility, plus keyword searches), producing 603 unique repositories.
Filtered on stars, licence SPDX id, last push, and archived status. Most of the 603 were false positives — user-agent parsers, Telegram bots, a C# cheat sheet that happened to mention llms.txt.
Read the README of everything I planned to feature, because a repo description is marketing and a third-party blog summary is worse. That's how I learned OneGlanse drives the real chat UIs in a browser rather than calling model APIs — which turns out to be its whole point, and isn't in its description.
Sanity-checked the outliers. A brand-new "SEO skill" repo with 12,000 stars deserves a look at its star-to-fork ratio and creation date before you vouch for it.
curl'd every link for a 200 before publishing. All 64.

What's in it

Ten sections, ordered so a newcomer can start at the top:

Standards & Specifications — llms.txt, Schema.org, ai.robots.txt, and Joost de Valk's Website Specification
Audit & Linting — CLIs you run against your own site
Visibility & Citation Monitoring — the widest paid-SaaS gap, and where self-hosting matters most since you pay the inference either way
llms.txt Tooling — generators and validators
Framework & CMS Integrations — Nuxt, Astro, VitePress, MkDocs, Sphinx, Laravel, WordPress
Crawler Access & Log Analysis — including Anubis, listed on purpose: you cannot be cited by a crawler you blocked, so access control is a GEO decision in both directions
Agent Skills & MCP Servers — with the honest caveat that none of their scoring is calibrated against a benchmark
Research & Papers — the KDD 2024 original, the 2026 survey covering 45 studies, AutoGEO, and a governance paper that argues against the whole enterprise
Directories & Datasets
Related Lists — including the two broader GEO lists, because they complement this rather than compete with it

Contributing

Self-submissions are welcome and don't need an apology — just disclose it in the PR. My own audit tool is in there exactly once, under the same rules, with no special placement.

The bar is in contributing.md. Removals count as contributions too: if something on the list is abandoned, relicensed away from open source, or simply worse than it looked, open an issue and I'll cut it.

Repo: github.com/cloudapp-dev/awesome-open-geo

The niche is young enough that a lot of good work isn't on the list yet. If you maintain something that clears the bar, I'd rather hear it from you than find it in six months.

KNX Motion-Sensor Automations in Home Assistant

Michael Bernhart — Wed, 29 Jul 2026 12:46:30 +0000

A note before the post: the mistake in the first section is genuinely mine. It cost me an evening of forking conditions in Home Assistant before I accepted the fix didn't belong in Home Assistant at all. I've left it in rather than writing around it, because it's the part I'd have wanted to read first.

The first time motion-controlled lighting actually worked in my place, it didn't feel clever. It felt obvious — I walked into a dark hallway and the light was already on by the time I'd registered it was dark. That's the bar. Not smart, just attentive. Getting there with seven KNX motion sensors took me less code than I expected and one insight I wish I'd had on day one.

This is Part 05 of the series. The earlier parts cover the boring-but-load-bearing groundwork: running Home Assistant in Docker and wiring up HACS. Here I'm assuming HA is up, talking KNX, and you just want the lights to behave.

One sensor, two jobs, two addresses

Here's the mistake I made, and it's the whole reason this post exists. KNX exposes each motion sensor to Home Assistant as a binary_sensor with device_class: motion, fed by a KNX group-address state object you configure in knx.yaml with a state_address per sensor. Simple enough. So I wired all seven sensors with one group address each and pointed both the lighting automation and the presence logic at the same signal.

That works right up until you want the two to behave differently. A light should react to the smallest twitch, instantly, generously. Presence and security want the opposite: a debounce, a grace window, some scepticism before they commit. When both ride the same group address, every change you make to one quietly deforms the other. I spent an evening forking conditions in Home Assistant trying to make one signal mean two things.

The fix isn't in Home Assistant at all. It's in ETS: give each physical PIR a second group address. One drives comfort lighting, the other feeds presence and the alarm path. I use a flat convention — 5/4/x for lighting, 5/5/x for the security path, 5/6/x reserved for generic presence. Now "the light reacts" and "security reacts" are genuinely separate events. The lighting automations below never touch the alarm side, which is exactly how I want it — this post is strictly about lights and presence, and the alarm internals stay out of it on purpose.

The dumb version first

Start with the on/off automation that everyone writes. Motion goes from off to on, turn the light on. Motion goes off, turn the light off. Two automations, a sensor and a light:

# Motion ON -> light on; motion OFF for 5 min -> light off
- alias: "Hallway light on motion"
  triggers:
    - trigger: state
      entity_id: binary_sensor.flur_motion
      from: "off"
      to: "on"
  actions:
    - action: light.turn_on
      target: { entity_id: light.flur }
      data: { brightness_pct: 100 }
  mode: single

- alias: "Hallway light off after 5 min"
  triggers:
    - trigger: state
      entity_id: binary_sensor.flur_motion
      from: "on"
      to: "off"
      for: { minutes: 5 }
  actions:
    - action: light.turn_off
      target: { entity_id: light.flur }
  mode: single

Two things are doing quiet work here. mode: single keeps the automation from re-triggering itself into a storm when a sensor chatters — pair it with max_exceeded: silent so the overlap is swallowed without filling your log. And the off side triggers on the sensor going to off with a for: of five minutes, not immediately. That for: is the single most important number in the whole setup.

The honest failure: lights dropping while you're still there

Every motion-lighting setup fails the same way the first week: you're standing perfectly still reading something, the sensor stops seeing you, and the room goes dark. It's the classic failure and it's infuriating because it makes the house feel like it's sulking at you.

The instinct is to fight the sensor — chase faster polling, a more sensitive PIR, fancier presence detection. Don't. The fix is almost always to lengthen the off-delay. I settled on a small taxonomy that maps to how long people actually linger in a space: short hold of about 30 seconds to a minute for small rooms you pass through, medium of 3 to 5 minutes for halls and stairs, and long of 10 to 15 minutes for living rooms and offices where you sit still. A hallway gets five minutes. A reading chair does not get thirty seconds.

I also give the trigger a 2 to 5 second grace window before acting, so a single flicker on the wire doesn't strobe the room. Cheap insurance.

The touches that make it feel intentional

Once the lights stop misbehaving, you can add the bits that make it feel like the house was designed rather than scripted. None of these are hard; they're just thoughtful.

Night-only stairs. The stairwell and hallway lights only auto-fire in the dark. A condition: sun with after sunset / before sunrise gates them, so they don't pointlessly switch on at noon when there's plenty of daylight.

Time-of-day brightness. A fixed brightness is a tell that a machine wrote your house. Full blast at 3am is hostile. I drive brightness with a choose: block keyed on time windows — roughly 30% late at night (22:00 to 06:00), 70% in the early morning (06:00 to 08:00), and 100% during the day:

# Time-of-day brightness with choose:
actions:
  - choose:
      - conditions:
          - condition: time
            after: "22:00:00"
            before: "06:00:00"
        sequence:
          - action: light.turn_on
            target: { entity_id: light.stairs }
            data: { brightness_pct: 30 }
    default:
      - action: light.turn_on
        target: { entity_id: light.stairs }
        data: { brightness_pct: 100 }

Pathway lighting up the stairs. My favourite trick. The stair automation chains two lights with a delay: of about three seconds between them — the lower light first, then the floor above a beat later — so the light walks up the stairs ahead of you instead of flooding the whole shaft at once. It's a tiny thing that gets noticed every single time.

A whole-zone energy cutoff. The thing I'm proudest of, because it's where the naive version quietly wastes power. Instead of each light timing out alone, an energy-saving automation triggers on a list of motion sensors all going to off for a hold time — I use ten minutes across the group — and then re-asserts in its conditions that every single sensor in the zone is still off before it drops anything. That AND-of-all guard matters: one sensor flapping back to on shouldn't keep a whole floor lit, and one sensor going quiet shouldn't plunge an occupied zone into darkness. Lights only drop when the zone is genuinely empty. Driving it by area_id rather than enumerating every fixture means one automation can switch off a whole zone at once.

A cheap presence value, almost for free

Here's a small one I keep reaching for. You don't always need a real presence-detection platform to answer "was anyone in the kitchen recently?". Give each area an input_datetime helper, and add a one-line automation per motion sensor that, on going to on, stamps the current time into it. Now you have a per-area "last motion seen" value you can read anywhere — in conditions, on a dashboard, in a notification — without installing anything.

It's not occupancy in the rigorous sense; it's a timestamp. But "last seen two minutes ago" answers nine out of ten of the questions I actually ask my house, and it costs one helper and one tiny automation per room.

To tune any of this, put the sensors on a Lovelace type: entities card so you can watch live motion state per area while you fiddle with the off-delays. Seeing a sensor sit on off a full second before you expected it to is how you learn which room needs a longer for:.

What I'd tell past me

Two things. First: split the signal at the bus, not in YAML. A second group address per sensor is five minutes in ETS and it saves you from building a tower of conditions that tries to make one event mean two contradictory things. Second: the entire quality of motion lighting lives in the off-delay, not the on-trigger. Turning a light on is trivial; turning it off at the right moment, after the right hold, only when the room is really empty, is the whole craft.

Throughout this I've kept entity names generic on purpose — flur, stairs, hallway — and the group-address scheme abstract. The real reason a lighting signal and a security signal get separate addresses is the alarm path that lives on the other one, and that's a story for a part of this series that very deliberately leaves out the internals. For lights, the recipe above is the whole thing. Next part picks up where the second group address leads.

Updating Home Assistant in Docker Safely: My Workflow With Backup, Test and Rollback

Michael Bernhart — Tue, 28 Jul 2026 08:34:57 +0000

My Home Assistant has run for years as a bare Docker container — no Supervisor, no HAOS, just the official image and a mount onto my config directory. It's lean and controllable, but it comes at a price: there is no "update" button in the UI and no automatic snapshot. A major update can break my KNX heating, the PV sensors and half a dozen HACS integrations all at once, and if I'm unlucky I only find out when the bathroom stays cold that evening.

After a few painful updates I settled on a fixed procedure that I run through stubbornly every single time. The core of it: order is everything, the container gets recreated instead of overwritten in place, and I note down the exact way back before I touch anything. Here is the complete flow.

Why the order trips almost everyone up

The most common mistake is to pull the Home Assistant core first and then wonder why HACS integrations are broken. It is actually safer the other way around: update the custom components and HACS first and test them against the still-running OLD core version, then raise the core. That cleanly separates the two sources of failure. If something breaks after the HACS update, you know it's the integration — not a core break you rolled in at the same time.

Concretely: I open HACS, update the pending custom components one by one (for me usually things like the Shelly or Huawei Solar integration), restart Home Assistant once — still on the old core — and check that everything works. Only when that intermediate state is clean do I go for the image.

Step 1 — full backup before touching anything

Before every update I back up the entire config directory. On a Docker install that's simply the folder you mount into the container — it holds configuration.yaml, the database, the .storage registries and all your YAML packages. If that folder is backed up, your entire state is backed up. Put the copy outside the container mount (a different directory or another host), not next to it.

Important: stop the container before the backup, or at least accept the live SQLite database. For a major update with a database migration, a clean snapshot of the old state is the only thing the migration won't carry along anyway.

Step 2 — note the old image ID (your real rollback)

This is the step almost every guide leaves out, and it's the most important one. "Rollback" in Docker does not mean "pull stable again" — that just fetches the new version. A real way back only works via the exact image ID your container ran on before the update. You record it before pulling anything:

sudo docker inspect homeassistant --format '{{.Image}}'
# Rollback: docker run ... <OLD_IMAGE_ID>

Save that ID somewhere (text file, note, whatever). As long as the old image hasn't been pruned locally, you can start a new container with instead of the stable tag at any time and be back on the old state within seconds — together with your (backed-up) old config folder.

Step 3 — recreate the container instead of in-place

Now the actual core update. I never update in place; I stop the container, pull the new image and recreate the container from scratch — with exactly the same mount and the same flags as before. That keeps the container state predictable and stops any old runtime configuration from dragging along:

sudo docker stop homeassistant
sudo docker pull ghcr.io/home-assistant/home-assistant:stable
sudo docker rm homeassistant && sudo docker run -d \
  --name homeassistant --restart unless-stopped --network host \
  -v /home/USER/homeassistant:/config \
  ghcr.io/home-assistant/home-assistant:stable

Replace /home/USER/homeassistant with your actual config path. The --network host mode is practically mandatory for many local integrations (discovery, Modbus, KNX); keep exactly the flags your old container had — a forgotten flag is its own class of "X stopped working after the update" bugs.

Step 4 — wait for the database migration

On a major update, Home Assistant migrates its database schema on first start. Depending on database size that can take several minutes, and during that time the API won't answer yet. Don't get impatient and restart the container — that aborts the migration mid-flight. Instead I watch for when the API comes back:

watch -n 5 'curl -s -m 3 http://HA_HOST:8123/api/ 2>/dev/null'

Replace HA_HOST with your instance's address. As soon as the command returns a JSON response instead of an empty line, the core is up and the migration is done. In parallel it's worth tailing the container log (docker logs -f homeassistant), which logs the migration as it runs.

Step 5 — the post-update checklist

A green API endpoint doesn't yet mean the smart home works. I keep a short checklist of the things that, in my experience, act up first after updates — especially anything that goes over local bus systems. I actively walk through it after every update:

- [ ] KNX thermostats respond (switch preset mode)
- [ ] Window sensors correct (all off after startup)
- [ ] Solar/PV data coming in
- [ ] HACS works
- [ ] Automations active (blind schedule, heating day/night)

I check the PV and Modbus sensors especially closely, because they're prone to being mapped differently after a core jump — how I wire them up in the first place is in the Modbus basics post. If something's off, I fall back to the rollback from step 2 instead of poking around in a live system.

When the update goes wrong: the rollback in practice

The way back is exactly the reverse of step 3, just with the old image ID. Stop and remove the container, restore the old config folder from the backup (important if the migration already touched the schema — a migrated database won't run reliably on the old core), and start a new container with . That's precisely why the backup and the noted image ID aren't an optional extra but the two things that separate a bad update evening from a completely wrecked weekend.

My self-sufficient energy setup, for example, hangs off a chain of Modbus sensors and template calculations — if the self-consumption ratio suddenly reads unavailable after the update, I know a data source has dropped out, and I decide from the checklist whether to fix forward or roll back. How those derived metrics are built is described in the autarky sensors post.

Frequently asked questions

Why not just use Watchtower for automatic updates?

Watchtower silently pulls the newest image and recreates the container — which is exactly the scenario I want to avoid. A major update with a database migration and potentially breaking HACS integrations is something I want to run in a controlled way, with a backup and a noted rollback ID, not automatically at three in the morning. For pure minor/patch releases Watchtower is tempting, but Home Assistant's stable tag doesn't distinguish patch from major — so I deliberately do it by hand.

Isn't the Home Assistant backup enough instead of a folder backup?

The built-in backup doesn't exist as a button in the pure Docker variant (without Supervisor) — it's a Supervisor feature. In a bare container, your config mount is the backup. That's exactly what makes it so simple: copying one directory secures your complete state including the database and .storage registries.

How long do I keep the old image?

Until the new update has proven itself over several days of normal operation. Only then do I clean up with docker image prune. Before that, the old image is your only seconds-long rollback — a few hundred megabytes of disk are well worth it. I note the image ID and date so I know which image belongs to which working config.

What if the API doesn't come up at all after the update?

Then look at the container log first (docker logs homeassistant). The most common causes after a major jump are a removed/renamed YAML option or a HACS integration that's incompatible with the new core. If the log shows a concrete error you can fix it surgically; if it's opaque or the downtime drags on, the clean move is the rollback from step 2 rather than minutes of guessing on a live system.

Originally published on cloudapp.dev, where I write about Home Assistant, self-hosting and data infrastructure.

A "Last Motion" Sensor in Home Assistant: Per-Room Timestamps with input_datetime

Michael Bernhart — Mon, 27 Jul 2026 15:12:22 +0000

A classic motion sensor only knows two things: motion right now, or none right now. What it doesn't answer out of the box is the far more useful question — when was someone last in this room? That single piece of information is the foundation for any presence heuristic: "house empty for two hours", "nobody in the hallway since breakfast", "has anyone even been in the garage today".

My first instinct was to buy expensive mmWave presence sensors for this. But the plain PIR detectors already on the wall are enough — you just have to store their last on-moment somewhere. In Home Assistant that's an input_datetime helper per room plus a trivial automation. This isn't a light-switching tutorial; it's a pure data pattern that I've since rolled out across the whole house.

Why input_datetime instead of last_changed?

Fair objection: every sensor already has a last_changed attribute. The problem is that last_changed flips on every state change — including the switch from on back to off. So you get the time of the last change, not the last motion. And it doesn't survive a Home Assistant restart cleanly: after a reboot the sensor sits freshly at off, last_changed is the boot time, and your history is gone.

An input_datetime helper fixes both. We write the timestamp only on the transition to on, the value is persistent (it survives restarts), and it's a real, queryable entity you can use in templates, conditions and on the dashboard just like any other sensor.

Step 1 — create one helper per room

Under Settings → Devices & Services → Helpers, create an input_datetime for each room with both date and time enabled. I keep the naming strictly consistent — letzte_bewegung_ (last_motion_) — because that makes later scaling trivial: new entity, same schema. If you prefer YAML, the same thing goes into configuration.yaml.

input_datetime:
  letzte_bewegung_gang:
    name: Letzte Bewegung Gang
    has_date: true
    has_time: true
  letzte_bewegung_garage:
    name: Letzte Bewegung Garage
    has_date: true
    has_time: true

The only thing that matters is that both flags are set — without has_time you lose the time of day and the whole pattern goes blunt.

Step 2 — write the timestamp on every motion

Now the actual logic, and it's pleasantly short: an automation that, on the motion sensor's transition to on, writes the current time into the matching helper via input_datetime.set_datetime. I deliberately trigger only on to: 'on' — the off event doesn't interest us, we want to capture the start of the last motion.

- id: '1711200000001'
  alias: Letzte Bewegung Gang
  triggers:
  - trigger: state
    entity_id: binary_sensor.bewegungsmelder_gang
    to: 'on'
  actions:
  - action: input_datetime.set_datetime
    target:
      entity_id: input_datetime.letzte_bewegung_gang
    data:
      datetime: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
  mode: single

The now().strftime(...) formats the local time into exactly the format set_datetime expects. mode: single is plenty: the action takes milliseconds, parallel runs are irrelevant.

Step 3 — the same pattern across rooms

The real charm is repeatability. For every additional room you copy the automation and swap only two things: the entity_id of the motion sensor and the entity_id of the helper. Same shape, different room.

- id: '1711200000007'
  alias: Letzte Bewegung Garage
  triggers:
  - trigger: state
    entity_id: binary_sensor.bewegungsmelder_garage
    to: 'on'
  actions:
  - action: input_datetime.set_datetime
    target:
      entity_id: input_datetime.letzte_bewegung_garage
    data:
      datetime: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
  mode: single

I run about a dozen of these automations in parallel — one per PIR. If you prefer something more compact you can build a single automation with multiple triggers and a template over trigger.to_state; I prefer the one-per-room variant because it stays instantly readable in the UI and lets you disable individual rooms on purpose.

Step 4 — relative time on the dashboard

The raw timestamp "2026-07-17 14:32:10" is awkward on a dashboard — what's interesting is "12 minutes ago". For that Home Assistant has the template function relative_time(), which turns a datetime into a human-readable span. In a Markdown card it looks like this:

type: markdown
content: >
  ## Last motion

  - **Hallway:** {{ relative_time(states('input_datetime.letzte_bewegung_gang') | as_datetime) }} ago

  - **Garage:** {{ relative_time(states('input_datetime.letzte_bewegung_garage') | as_datetime) }} ago

  - **Living room:** {{ relative_time(states('input_datetime.letzte_bewegung_wohnzimmer') | as_datetime) }} ago

The as_datetime converts the string state into a real datetime object that relative_time can process. The result is a compact overview — "Hallway: 3 minutes ago, Garage: 6 hours ago" — that tells you at a glance where there was life most recently.

What the data is good for

Once the timestamps exist, the interesting automations open up. A "house empty" heuristic: if the most recent of all letzte_bewegung_* times is older than, say, 30 minutes, the house counts as unoccupied — cheap presence detection without an mmWave sensor. Or room-scoped triggers: only ramp up the heating in a room if there's been motion there in the last hour. If you like the Modbus/sensor-data way of thinking, you'll find the same "data first, logic second" stance in my post on PV string fault detection.

Frequently asked questions

Why not just use the sensor's last_changed attribute?

Because last_changed flips on every state change — including the switch from on to off — and doesn't survive a restart: after a reboot the sensor sits freshly at off and last_changed is the boot time. The input_datetime helper, by contrast, stores only the last on-moment, is persistent, and survives restarts.

Does the value survive a Home Assistant restart?

Yes. input_datetime helpers are persistent — their last set value is stored and restored after a reboot. That's one of the main advantages over raw sensor attributes, which start from scratch after a restart.

Do I need a separate automation per room?

No, but it's the most readable option. You can also build a single automation with multiple triggers and pick the matching helper from a mapping via trigger.to_state. I deliberately use one automation per room because it stays instantly understandable in the UI and can be disabled individually.

Does this work with any motion sensor?

With any that shows up in Home Assistant as a binary_sensor with on/off states — Zigbee PIR, KNX presence detector or Wi-Fi sensor alike. The pattern doesn't know the hardware, it only reacts to the on transition. On KNX detectors that I also use for light switching, the same timestamp automation runs alongside without issue.

Originally published on cloudapp.dev, where I write about Home Assistant, self-hosting and data infrastructure.

Motion Light With Time-of-Day Brightness in Home Assistant: the choose Pattern (30% Night, 70% Morning, 100% Day)

Michael Bernhart — Fri, 24 Jul 2026 10:02:07 +0000

A simple motion light in the stairwell is quick to build: motion detected, light on, off again after a few minutes. You only notice the problem at night. In my own stairwell, the sudden 100 % light at three in the morning blinded me so badly that I was wide awake afterwards. During the day, on the other hand, dimmed light is too weak to see the steps safely.

The fix isn't a second setup or an expensive adaptive-lighting layer — it's a single choose: block in the motion automation that grades brightness by time of day: 30 % at night, 70 % in the early morning, full 100 % otherwise. Plus the one real-world lesson that cost me two evenings of debugging — against flicker, a longer delay helps, not a shorter one.

Why on/off alone isn't enough

A fixed brightness level is always set for the wrong time of day. Set it to full and it blinds you at night. Set it dimmed and it's too dark during the day. That's exactly where the pattern comes in: motion stays the trigger, but how bright the light comes on is decided by a short time branch inside the actions. No second sensor, no second automation — just one choose block.

Step 1 — the choose block for time-of-day brightness

The core is the choose: block in the actions. It checks conditions top to bottom and takes the first branch that matches; if none does, the default runs. I use three tiers: 22:00–06:00 dimmed to 30 %, 06:00–08:00 medium at 70 %, and the rest of the day at full 100 %.

actions:
  - choose:
      # Spaete Nacht (22:00-06:00): gedimmt, blendet nicht
      - conditions:
          - condition: time
            after: "22:00:00"
            before: "06:00:00"
        sequence:
          - action: light.turn_on
            target: { entity_id: light.stiegenhaus_eg }
            data: { brightness_pct: 30 }
      # Frueher Morgen (06:00-08:00): mittlere Helligkeit
      - conditions:
          - condition: time
            after: "06:00:00"
            before: "08:00:00"
        sequence:
          - action: light.turn_on
            target: { entity_id: light.stiegenhaus_eg }
            data: { brightness_pct: 70 }
    # Default: volle Helligkeit
    default:
      - action: light.turn_on
        target: { entity_id: light.stiegenhaus_eg }
        data: { brightness_pct: 100 }

Two things matter. First, order is decisive: the night branch comes first because its window doesn't overlap the morning branch — with overlapping windows the first match wins. Second, the time condition is correct across midnight: after "22:00:00" / before "06:00:00" covers the night properly, because Home Assistant treats that as one continuous window spanning the day boundary. Replace light.stiegenhaus_eg with your own light entity.

Step 2 — turning it back off cleanly

The second part is switching off. Most motion sensors report "no more motion" fairly quickly once you stand still. If you turn off directly on that, the light keeps flicking on and off whenever someone pauses on the stairs or stands in the hall on a call. The for: filter on the off trigger waits until the sensor has seen nothing for a continuous stretch of time.

triggers:
  - trigger: state
    entity_id: binary_sensor.bewegungsmelder_stiegenhaus_eg
    from: "on"
    to: "off"
    # Flacker-Fix: lieber 5 Min als 1 Min - kurze Delays lassen das Licht
    # bei stillem Sitzen an/aus springen
    for:
      minutes: 5
actions:
  - action: light.turn_off
    target: { entity_id: light.stiegenhaus_eg }

This block is the separate off automation (or the off trigger of the same automation). The trigger only fires when the sensor has stayed "off" for 5 uninterrupted minutes — if someone moves again in that window the timer resets and the light stays on.

The flicker fix: raise the delay, don't lower it

This is the lesson that feels counter-intuitive. When the light flickers — rhythmically on and off while someone sits still or walks the stairs slowly — the first instinct is to shorten the off delay so it reacts faster. That makes it worse. PIR motion sensors detect heat movement; sit still and the sensor drops to "off", you breathe or reach for a glass and it goes "on" again. A short delay lets the light chase that jitter.

The solution is a longer for: delay. At 5 minutes the timer bridges the dead phases where the PIR sees no motion even though someone is still there. Better the light stays on a few minutes too long than a blinking stairwell.

Sensible delays per room type

The right for: duration depends on how long you typically stay in a room with little movement. In a stairwell or pass-through hall, 2–3 minutes is enough, because you rarely stand still long. In a room where you sit — a study, a reading chair — go higher, to 8–10 minutes, or the light cuts out during focused work. My stairwell runs on 5 minutes as a good middle ground: generous enough against flicker, short enough that no light burns for hours in an empty stairwell.

Extending: only after dark, or with more tiers

If you don't want the light to come on at all in bright daylight, add a sun condition (sun.sun = below_horizon) or an illuminance sensor as an extra condition on the on trigger. The choose pattern itself scales freely: add more time windows (say a midday tier) or run different brightnesses per weekday. If you're curious how the same motion sensors feed presence heuristics, see the "last motion" sensor — it builds on the same triggers.

Frequently asked questions

Why a choose block instead of several automations?

You could build a separate automation per time of day with its own time condition, but that scatters the logic across three places and makes changes error-prone. The choose block keeps the whole time-of-day branch in one automation — one glance, one place to tune. That's exactly what choose: is for: several mutually exclusive branches under one trigger.

My light still flickers — what now?

First raise the for: delay further (say to 8–10 minutes) and see if it disappears — usually it does. If it persists, it's often the sensor hardware: some PIR units have their own cool-down/blocking time set too short, or the detection field is so narrow that a small turn drops you out of it. Then it comes down to sensor placement, or an mmWave presence sensor that also detects still occupancy.

Can I leave it fully off at night instead of 30 %?

Yes — just replace the light.turn_on in the night branch with no action, or drop the branch entirely (the default won't take over since the trigger still fires). Cleaner is to keep the night branch and dim very low there (say 5–10 %): enough to see the steps without waking up. Going fully dark on a staircase at night is a safety risk.

Does this work with any light or only dimmable ones?

brightness_pct assumes the light entity supports dimming. With a plain on/off switch, Home Assistant ignores the brightness value and just turns it on. Then the time-of-day grading does little — in that case a dimmable bulb or a dimming actuator is worth it, especially in the stairwell where the night-time glare is the actual problem.

How do I track when a room was last occupied, not just current motion?

That's a separate pattern — an input_datetime updated on last motion — I use it alongside this brightness automation to answer “how long has this room been empty”, not just “is it occupied right now”.

Originally published on cloudapp.dev, where I write about Home Assistant, self-hosting and data infrastructure.

A Self-Hosted Modern Data Stack Under €200/Month

Michael Bernhart — Thu, 23 Jul 2026 07:41:43 +0000

Every managed data platform quote I got landed in the same place: over a thousand euros a month before a single dashboard existed, on US-owned infrastructure, with my data living somewhere I didn't control. I needed an analytics platform — ingest a handful of sources, model them, put numbers in front of non-technical people — and the modern data stack has perfectly good open-source answers for every layer of that. So I self-hosted the whole thing on Hetzner. It runs for under €200 a month. Here's the stack, the real trade-offs, and the two decisions I got wrong first.

What "managed" actually costs

The pitch for managed platforms is that they save you operational work, and they do. What the pitch skips is the shape of the bill. Microsoft Fabric quoted over €1,000/month for my workload. Snowflake and Databricks are usage-priced, which sounds cheaper until a backfill or a careless dashboard scans more than you budgeted for — the number is unpredictable by design. And all three put my data on infrastructure I don't own, under a jurisdiction I'd have to explain to a data protection officer.

None of that is a dealbreaker for everyone. If you have no ops capacity and a generous budget, managed is the right answer. But I had the opposite: a tight budget, a hard requirement for EU data sovereignty, and enough Kubernetes and SQL to run infrastructure myself. That combination points straight at self-hosting.

The stack, layer by layer

The "modern data stack" is really just a set of roles — storage, ingestion, a query engine, transformation, orchestration, and a BI layer — each of which now has a solid open-source option. Here's what I picked and, more usefully, why.

Storage: object storage + Apache Iceberg

The lake sits in Hetzner Object Storage (S3-compatible) as Apache Iceberg tables. Iceberg gives you table semantics — schema evolution, time travel, atomic writes — on top of plain Parquet files you fully own. The format is open, so nothing about this layer locks me to a vendor or even to the query engine. That single choice is what makes the rest of the stack swappable.

Query engine: ClickHouse on dedicated hardware

ClickHouse is the core, and it runs on a dedicated Hetzner box rather than inside my Kubernetes cluster. That was deliberate: an analytics column store wants direct access to fast local NVMe and predictable memory, and putting it in K8s next to noisy neighbours buys you nothing but scheduling headaches. A dedicated machine with a lot of RAM and mirrored NVMe costs a fraction of a managed warehouse and outruns it on the queries I actually run.

Transformation: dbt

Transformation is dbt with the ClickHouse adapter. dbt is the one layer where I'd have made the same choice managed or not — it's become the default for turning raw tables into modelled ones, and the dbt-clickhouse adapter is mature enough for real work. Models are version-controlled SQL, tested in CI, and materialised straight into ClickHouse. It's niche enough that you'll occasionally hit an adapter edge the Postgres or Snowflake worlds never see, but for standard modelling it simply works.

Orchestration: Dagster

Everything is stitched together by Dagster, running as open-source in Kubernetes. I went with Dagster over Airflow because it models the pipeline as assets — "this table exists and depends on that source" — rather than as a bag of tasks. When the question is "is this dashboard's data fresh and where did it come from", an asset graph answers it directly. The whole ingest → dbt → BI chain is one lineage graph I can look at.

BI: a self-hosted dashboard layer

For the last mile — numbers in front of people who will never write SQL — I use a self-hosted BI tool backed by its own Postgres. It reads straight from ClickHouse, so dashboards are fast, and because it's self-hosted the data never leaves the platform to be rendered. This is the layer that justifies the whole thing to everyone who isn't an engineer.

Ingestion: the part I got wrong first

My original design pulled changes out of the source databases with Debezium, the standard change-data-capture route. On paper it's the right answer: near-real-time, battle-tested, exactly what CDC is for. In practice it was too much moving machinery for what I actually needed. Debezium wants a Kafka-shaped world around it, and my sources didn't change fast enough to justify that weight.

So I reversed it. The batch sync now runs on dlt — a small Python library that reads a source and lands it in the lake on a schedule — with Dagster triggering it. It's less impressive on a diagram and far less to operate, and for data that's fresh enough at hourly or daily granularity it's simply the correct trade. The lesson I keep relearning: pick the ingestion cadence your data actually has, not the fastest one available.

What it costs — money and otherwise

The infrastructure bill is under €200/month: the dedicated ClickHouse machine, the object storage, and a small Kubernetes cluster carrying the orchestration and BI pods. That's a fraction of the managed quote, on hardware in an EU data centre, with my data in open formats I could move anywhere tomorrow.

The honest cost is on the other side of the ledger. Self-hosting means you own the pager. A managed warehouse that falls over is someone else's 3 a.m.; mine is mine. Until I add a second node the query engine is a single point of failure, and every component is one more thing to patch, back up and understand. If you can't comfortably operate Kubernetes and a database, that operational load will eat any money you saved. That number is real, but it isn't free — it's a trade of cash for control and competence.

Would I do it again?

For this situation, without hesitation. The combination that made it right — a real budget ceiling, a hard EU-sovereignty requirement, and the in-house ability to run it — is common enough that a lot of teams are quietly in the same position and defaulting to managed anyway. If that's you, the modern data stack self-hosts cleanly, and the pieces are all open source and genuinely good now in a way they weren't a few years ago.

Frequently asked questions

Is a self-hosted data stack really cheaper than Snowflake or Fabric?

On raw infrastructure, dramatically — under €200/month here versus €1,000+ quoted. But that number ignores your own time. If you have to hire or divert an engineer to run it, the managed premium can be the cheaper option. It's cheaper in money, not necessarily in total cost.

Why ClickHouse instead of just Postgres?

Postgres is a row store; analytics queries scan columns across millions of rows, which is exactly what a column store like ClickHouse is built for. For transactional workloads Postgres wins; for aggregations over large tables ClickHouse is often orders of magnitude faster.

Do I need Kubernetes for this?

No. I use it because I already ran a cluster and it makes the orchestration and BI pods easy to manage, but you can run the same stack with Docker Compose on a couple of machines. The query engine deliberately sits on dedicated hardware either way.

Why Dagster over Airflow?

Airflow models tasks; Dagster models data assets and their lineage. For an analytics pipeline where the real question is "is this table fresh and where did it come from", the asset model answers it natively. Airflow is the safer choice if your team already knows it well.

Originally published on cloudapp.dev, where I write about self-hosting, Home Assistant and data infrastructure.

Decoupling a KNX Alarm from the JUNG Panel in Home Assistant

Michael Bernhart — Tue, 21 Jul 2026 08:38:33 +0000

The house came with a JUNG EAM4000 KNX alarm panel, and for years it owned the entire security story. It gated the motion detectors, it decided whether the place was armed, and it drove the sirens. When I started pulling the house into Home Assistant, the obvious move was to read the alarm out of that panel and call it done. I didn't do that, and this post is about why.

The naive way couples you to the panel

The tempting approach is to tap the panel's own outputs: wire its zone and sabotage objects into HA and read them as sensors. It works on day one. But then HA only ever knows what the panel decides to tell it. When the panel is disarmed, those zone outputs go quiet, so HA sees nothing either. Your automation logic now lives downstream of someone else's arming logic, and you've inherited a dependency you can't easily reason about or change.

I didn't want Home Assistant to be a slave to the JUNG panel. I wanted HA to be the thing that decides, and the panel to become, at most, a peer on the bus. So I inverted who owns the truth.

HA owns the state and exposes it back onto the bus

The core trick is almost embarrassingly simple once you see it. Instead of reading the alarm's status out of the panel, I made Home Assistant the owner of the alarm state and exposed it back onto the KNX bus. Two HA input_booleans — an 'armed/active' object and a 'ready to arm' object — get published to KNX group addresses as type binary via an expose: block in knx.yaml. The bus now reflects HA's truth, not the panel's.

# knx.yaml — HA OWNS the alarm state and pushes it back onto the bus
# (status + 'ready' are HA input_booleans exposed to KNX, not read from the panel)
expose:
  - type: "binary"
    entity_id: "input_boolean.knx_ha_alarm_status"
    address: "x/1/10"   # HA-owned 'armed' object on the bus (real GA masked)
  - type: "binary"
    entity_id: "input_boolean.knx_ha_alarm_bereit"
    address: "x/1/11"   # HA-computed 'ready to arm'

Note these exposed objects deliberately omit sync_state — HA is the writer here, it's allowed to push. The addresses use the normal 3-level KNX form; I've masked the leading group because this is a security topic and the real map stays private.

Read presence off the light address, not the alarm zone

Here's the detail I'm genuinely happy about. The motion detectors already fire a light telegram to switch corridor and stair lighting, and they send it regardless of whether the alarm is armed. So I read each detector into HA through its light group address, not through the panel's alarm zone — a plain binary_sensor with device_class: motion pointed at the light status object. The payoff: HA sees presence even when the alarm is fully disarmed — exactly the information the panel would have hidden from me. There are seven JUNG 3361-1 detectors across the property, and I split them into a five-detector cellar set for a 'night' mode and the full seven-detector set for 'away'.

Every one of those read-only sensors sets sync_state: false — window contacts, motion detectors, tamper. That stops HA from issuing GroupValueRead requests or writing back, so on those objects HA is a passive listener and can't disturb the alarm's own bus traffic. The exposed alarm objects above deliberately omit it, because there HA is the writer.

'Ready to arm' is computed in HA, and arming is gated on HA's flag

The readiness lamp ('Bereit') isn't the panel's calculation anymore — it's mine. Window and opening contacts are modelled as binary_sensor with device_class: window straight off their KNX status objects, and the garage gets its own device_class: garage_door sensor. Two automations watch floor-level window groups for the ground and upper floors, and only when every window on both floors reports closed do they flip the exposed 'ready' boolean on. That computed readiness is then pushed back to KNX so the lamp on the bus shows HA's answer.

Arming converges on one source of truth. Two 'sync' automations keep a physical KNX wall switch and input_boolean.knx_ha_alarm_status in lock-step in both directions, so arming from the wall and arming from the app land on the same flag. And every escalation is gated on that flag: a window or door open triggers the automation, but nothing escalates unless HA's own armed flag is set. The JUNG panel is no longer in that decision.

# Every escalation is gated on HA's own armed flag, not the JUNG panel:
conditions:
  - condition: state
    entity_id: input_boolean.knx_ha_alarm_status
    state: 'on'
triggers:
  - trigger: state
    from: 'off'
    to: 'on'
    for:
      seconds: 5   # debounce a bouncing reed contact

That for: seconds: 5 is intentional anti-bounce — a flickering reed contact has to hold open for five seconds before it counts. On a real trigger HA writes the offending opening plus a timestamp into an input_text helper, logs it to the logbook, raises a persistent notification, sends a critical-priority push to the household phones (sound critical, volume 1.0, so it punches through iOS focus mode), and turns on a local buzzer plus lighting in a set of areas. The buzzer auto-deactivates five seconds after the armed boolean goes off again. All of it is orchestrated in HA, independent of the panel.

The safety net, and the honest trade-off

Before any of the HA work, I did one thing in ETS: I stripped the siren, flash and transmission group addresses out of the JUNG central unit. The point was that even if the panel mis-fired during the rewire, nothing would physically sound. HA becomes the only thing that can raise an alarm. (Editing the central unit needs JUNG's vendor ETS plug-in on Windows with a KNX/IP gateway — you can't reconfigure it from generic ETS.)

One real gotcha along the way: some detectors were still brightness-gated in ETS ('helligkeitsabhängig'), so they only sent their movement telegram in the dark. Reading presence off the light address means you have to reprogram those to send brightness-independently, or they show up dead in HA. A few of mine did exactly that until I caught it.

The honest trade-off: I gave up the panel's certified, tamper-monitored signal path for flexibility. The tamper contacts still exist — they're mapped as device_class: tamper sensors — but I'm no longer routing security through the panel's coupling. If you need a monitored, insurance-grade alarm path, that certified panel still has a real job. For a house where I want HA to actually own the logic, inverting ownership and listening passively on the bus was the cleaner build. If you're following the series, this leans on the same KNX foundation as the earlier HACS and Docker posts.

KNX Thermostats Drop to 'Standby' After Every Home Assistant Restart - A Startup Automation Fix

Michael Bernhart — Wed, 15 Jul 2026 10:19:28 +0000

It's a quiet bug that only bites you when the flat is cold in the morning: after every Home Assistant restart ‚Äî an update, an add-on install, a container restart, a power cut ‚Äî all of my KNX thermostats sat on 'standby'. No heating, no error, the mode simply gone. By the time I noticed it was usually hours too late and the radiators stone cold.

The cause is both harmless and infuriating: on restart the KNX integration briefly loses its connection to the bus, and many KNX climate actuators fall back to a safe default state ‚Äî namely 'standby'. Home Assistant no longer knows the previous mode after the reboot and doesn't restore it on its own. The fix is a small but precisely timed startup automation. It cost me about 30 minutes ‚Äî and the waking-up-cold problem has been gone ever since.

The symptom: 'standby' instead of 'heat'

Concretely: before the restart a thermostat is on hvac_mode: heat with preset comfort. After the restart the same climate entity shows standby (or 'off' on some actuators). The setpoint drops out of the control loop and the radiator stays cold. In the history graph you see the kink exactly at the restart moment. Important to understand: this is not a fault in your automations ‚Äî it's an initialisation gap right after boot.

Why a simple 'set mode' call isn't enough

The obvious reflex ‚Äî just fire climate.set_hvac_mode at startup ‚Äî fails, because in the first seconds after boot the climate entities are often still unavailable. The KNX bus has to connect first, the actuators have to report their state. Send the command too early and it goes nowhere, leaving the thermostat on standby. That's exactly why the automation needs two ingredients: a trigger on HA start and a short wait until the bus is back.

The fix: a timed startup automation

The automation below triggers on the homeassistant start event, waits 30 seconds for the KNX bus to connect and all climate entities to become available, and then sets the right state depending on night mode: if night mode is on, every thermostat goes to preset economy; otherwise to heat plus preset comfort. A simple input_boolean helper ‚Äî which I share with the master heating switch ‚Äî drives the day/night branch.

- id: heating_startup_initialize
  alias: 'Heizung: Modus beim Start initialisieren'
  description: >-
    Setzt alle Thermostate beim HA-Start auf den korrekten Modus,
    basierend auf dem Nachtmodus-Status
  triggers:
  - trigger: homeassistant
    event: start
  conditions: []
  actions:
  # the KNX bus needs a few seconds after the restart until all
  # climate entities are connected/available again
  - delay:
      seconds: 30
  - choose:
    # night mode active -> economy
    - conditions:
      - condition: state
        entity_id: input_boolean.heizung_nachtmodus
        state: 'on'
      sequence:
      - action: climate.set_preset_mode
        data:
          preset_mode: economy
        target:
          entity_id:
          - climate.thermostat_wohnzimmer
          - climate.thermostat_buro
          - climate.thermostat_kuche
          - climate.thermostat_schlafzimmer
          - climate.thermostat_kinderzimmer_1
          - climate.thermostat_kinderzimmer_2
    # otherwise day mode -> heat + comfort
    default:
    - action: climate.set_hvac_mode
      data:
        hvac_mode: heat
      target:
        entity_id:
        - climate.thermostat_wohnzimmer
        - climate.thermostat_buro
        - climate.thermostat_kuche
        - climate.thermostat_schlafzimmer
        - climate.thermostat_kinderzimmer_1
        - climate.thermostat_kinderzimmer_2
    - action: climate.set_preset_mode
      data:
        preset_mode: comfort
      target:
        entity_id:
        - climate.thermostat_wohnzimmer
        - climate.thermostat_buro
        - climate.thermostat_kuche
        - climate.thermostat_schlafzimmer
        - climate.thermostat_kinderzimmer_1
        - climate.thermostat_kinderzimmer_2
  mode: single

The entity list here targets my six rooms ‚Äî replace it with your own climate. entities. The room names are generic placeholders; fill in office, living room, kitchen and so on exactly as they're named in your setup.

Why exactly 30 seconds of delay

The 30 seconds aren't arbitrary. On my system the KNX integration reproducibly took about 10 to 20 seconds after boot before all climate entities flipped from 'unavailable' to a real state. 30 seconds gives a safe buffer without noticeably delaying when the flat warms up. On slower hardware (a Raspberry Pi, lots of integrations) it can make sense to go to 45 or 60 seconds. Rule of thumb: better to wait a little too long than to send the command into the void.

If you want it more robust, you can replace the fixed delay with a wait_template that waits until a representative climate entity is no longer 'unavailable' ‚Äî but for a home setup the plain 30-second delay is proven and entirely sufficient.

The day/night branch via choose

The choose block makes sure that a restart at three in the morning doesn't ramp everything up to full comfort temperature. If input_boolean.heizung_nachtmodus is 'on', all thermostats get the economy preset (set back); in the default branch ‚Äî i.e. during the day ‚Äî heat is set as the HVAC mode first, then comfort as the preset. I share this night-mode helper with the central heating switch, so startup and manual control use the same source of truth.

I use the same building-protection/preset logic in my window-contact-triggered frost-protection automation too ‚Äî both act on the same thermostat pool, just on different occasions.

Testing without restarting Home Assistant

You don't have to fully reboot every time to check the automation. In Developer Tools you can trigger the automation manually via 'Run' ‚Äî the homeassistant-start trigger is skipped, but the actions (delay + choose) run exactly as they would. First set a thermostat to 'standby' as a test and watch in the more-info dialog how it snaps back to 'comfort'/heat after a good 30 seconds. For the real test, do a deliberate restart and check the last-changed timestamps of the climate entities.

Frequently asked questions

Why do the KNX thermostats drop to standby on restart at all?

On restart the KNX integration briefly loses the bus connection. Many KNX climate actuators fall into a safe default on connection loss ‚Äî often 'standby' or 'off'. Home Assistant does not reconstruct the previous mode after boot automatically, so the actuator stays in the default until something actively resets it. That's precisely the gap the startup automation fills.

Isn't a shorter delay than 30 seconds enough?

Possibly, but it's risky. If you send the command before the climate entities are available, it goes nowhere and the thermostat stays on standby ‚Äî the bug is back. 30 seconds is a conservative, proven value. On fast hardware you can go down to 15 seconds, but then verify across several restarts that it reliably takes effect.

What if I don't have a night-mode helper at all?

Then you don't need the choose block. Keep just the default branch: 30 seconds delay, then climate.set_hvac_mode heat and climate.set_preset_mode comfort for all thermostats. You only create input_boolean.heizung_nachtmodus if you actually want a nightly set-back.

Does this work for other climate integrations, not just KNX?

Yes. The pattern ‚Äî trigger on homeassistant start, wait briefly for the entities to become available, then force the desired mode ‚Äî is generic. Any climate integration that falls into an unwanted default after a restart can be initialised this way. You only adjust the entity IDs and, if needed, the delay duration.

Window Open, Heating Off: Auto-Switch Each KNX Thermostat to Frost Protection in Home Assistant

Michael Bernhart — Sat, 11 Jul 2026 19:12:46 +0000

In winter I heat against the open window. Every time I tilt a window for a quick airing, the KNX thermostat below dutifully ramps up and blasts heating energy straight outside ‚Äî for minutes, until someone notices the room going cold and closes it again. Across a heating season that adds up to real money going out the window, literally.

The fix is a simple, per-room duplicable automation: window contact opens ‚Üí that room's thermostat goes to frost protection; window closes ‚Üí back to comfort. The one trick almost every tutorial leaves out is a 5-second debounce against false triggers. Here's my setup, step by step.

Why building_protection and not just "off"

The obvious reflex is to switch the thermostat fully off while the window is open (hvac_mode off or preset standby). That's dangerous: with a thermostat you forget or a window contact that gets stuck, the room can then cool down indefinitely ‚Äî in the worst case below freezing on an exterior wall. So I switch to the building_protection preset (frost guard, typically ~7 ¬∞C). The radiator stays supervised and kicks in if it genuinely gets cold, but it never heats the open window. That's the whole difference between "saving energy" and "a burst pipe in January".

Step 1 ‚Äî the window contact as a KNX binary_sensor

Every window I want to watch gets a binary_sensor with device_class window. That matters because Home Assistant derives the correct "open/closed" state and the right icons from it. The state address is the KNX group address your window contact reports on ‚Äî shown here as X/X/X placeholders; fill in your own. sync_state: false avoids needless polling of the bus, since the contact sends its state on its own.

binary_sensor:
  - name: "Fenster Buero Status Sensor"
    state_address: "X/X/X"
    sync_state: false
    device_class: window

  - name: "Fenster Wohnzimmer Status Sensor"
    state_address: "X/X/X"
    sync_state: false
    device_class: window

  - name: "Fenster Kinderzimmer 1 Status Sensor"
    state_address: "X/X/X"
    sync_state: false
    device_class: window

  - name: "Fenster Kueche Status Sensor"
    state_address: "X/X/X"
    sync_state: false
    device_class: window

  - name: "Fenster Kinderzimmer 2 Status Sensor"
    state_address: "X/X/X"
    sync_state: false
    device_class: window

One entry per window. The names are just examples ‚Äî generic room names like "Buero" (office) or "Wohnzimmer" (living room) keep the automations readable later on.

Step 2 ‚Äî the per-room automation pair

For each room I need two automations: one disables the heating on open, one re-enables it on close. Both hang off the same window contact and control the same thermostat. Here's the pair for the office:

- alias: Heizung Buero Deaktivieren
  triggers:
  - trigger: state
    entity_id: [binary_sensor.fenster_buro_status_sensor]
    from: 'off'
    to: 'on'
    for: {seconds: 5}
  actions:
  - action: climate.set_preset_mode
    data: {preset_mode: building_protection}
    target: {entity_id: climate.thermostat_buro}
  mode: single

- alias: Heizung Buero Aktivieren
  triggers:
  - trigger: state
    entity_id: [binary_sensor.fenster_buro_status_sensor]
    from: 'on'
    to: 'off'
    for: {seconds: 5}
  actions:
  - action: climate.set_preset_mode
    data: {preset_mode: comfort}
    target: {entity_id: climate.thermostat_buro}
  mode: single

On open it sets building_protection; on close, back to comfort. Which preset modes your KNX thermostat actually supports, and how they map onto the bus, is covered in detail in my post on KNX thermostat preset modes.

Step 3 ‚Äî understanding the 5-second debounce

The for: {seconds: 5} is the real trick and the reason this automation doesn't drive you mad in daily use. Without it, every micro-movement of the contact fires immediately: a reed contact sometimes bounces on closing, the window rattles in its frame during airing, and the KNX bus occasionally delivers brief flutter telegrams. Each of those glitches would otherwise trigger a pointless mode switch.

With the 5-second filter, the automation only fires once the window has actually been open (or closed) for five seconds. Short rattling is ignored, real airing is detected. Five seconds is short enough that no noticeable heating energy is lost, and long enough to mask all the flutter junk.

The mapping scales per room

The nice thing about the pattern: it's bluntly duplicable. One window-contact binary_sensor plus one climate thermostat per room, and the automation pair gets copied once with its two entity_ids swapped out. Here's my mapping table:

# Raum            Fensterkontakt                              Thermostat
# Buero           binary_sensor.fenster_buro_status_sensor    climate.thermostat_buro
# Wohnzimmer      binary_sensor.fenster_wohnzimmer_...        climate.thermostat_wohnzimmer
# Kueche          binary_sensor.fenster_kueche_...            climate.thermostat_kueche
# Kinderzimmer 1  binary_sensor.fenster_kinderzimmer_1_...    climate.thermostat_kinderzimmer_1
# Kinderzimmer 2  binary_sensor.fenster_kinderzimmer_2_...    climate.thermostat_kinderzimmer_2

If you have several windows per room, you can list them all in the trigger's entity_id and express "at least one window open" via a group or a template condition ‚Äî the logic stays the same.

Verifying it works

After reloading I test each room once by hand: open the window, wait a moment, then check in the thermostat overview that the preset jumped to building_protection (the list with secondary_info "last-changed" shows the timestamp). Close the window, wait five seconds, back to comfort. If the switch happens but too early or too late, the for duration is almost always the knob to turn.

Frequently asked questions

Why not hvac_mode off instead of building_protection?

Because off disables all frost protection. If a window is accidentally left open overnight or the contact gets stuck, the room cools down without limit ‚Äî on an exterior wall a burst pipe is the worst-case outcome. building_protection holds a safety minimum (~7 ¬∞C) but doesn't heat against the open window. That's the entire point of the exercise.

What if my thermostat doesn't have a building_protection preset?

Then check the climate entity's more-info dialog for which preset_modes it reports. On some KNX actuators the frost guard is called "frost", or it's done via a low target temperature with climate.set_temperature instead of a preset. The trigger logic stays identical ‚Äî you only swap the action in the disable block.

Do I really need two automations per room?

Not strictly ‚Äî you can also solve it in a single automation with two triggers and a choose block. I deliberately use two separate ones because they're instantly readable in the automation UI ("Heizung Buero Deaktivieren/Aktivieren") and can each be disabled individually when I'm testing something in one room. For a maintainable setup the small redundancy is worth it.

Do I lose heating energy during airing because of the 5-second delay?

Practically none. In five seconds a radiator gives off barely measurable heat, and the inertia of a water-based system is far larger anyway. Those five seconds buy you the reliability that not every rattle and bus glitch triggers a mode switch ‚Äî an excellent trade.

A Robust Modbus Proxy: Reconnect, Stale-Cache Detection and Timeouts Done Right

Michael Bernhart — Fri, 10 Jul 2026 13:26:12 +0000

A self-built Modbus cache proxy runs for weeks without complaint in summer — until the first night the inverter shuts down, or the first firmware reboot of the SDongle. That's exactly when you find out whether you built a proxy or a time bomb. My first attempt was naive: poll, cache, serve. It worked perfectly during the day. At night, when the SUN2000 went to sleep, the poll loop hung in a read that never returned — and for hours the proxy silently served the last daytime values as if nothing was wrong.

That's the dangerous failure: not the crash (you notice that), but the proxy that keeps running and serves stale data while nobody is the wiser. This post is the reliability playbook that turned my proxy into something I trust. I build the proxy itself in the Modbus caching basics post — here it's purely about the robustness underneath.

The failure mode no beginner guide covers

Tutorials show the happy path: connect to the SDongle, read registers, done. What they leave out: the SDongle is slow, opinionated hardware. It drops the connection at night, it needs a minute after a firmware reboot before it answers again, and it can't handle reads fired back-to-back. A naive asyncio read without a timeout then blocks forever, and your cache freezes on its last value. HA dutifully keeps showing numbers — they're just no longer true.

The fix has three pillars. First, every single read gets a hard timeout and the spacing the SDongle needs. Second, the poll loop retries fast and then backs off, instead of hanging. Third — and this is the part almost nobody builds — the proxy makes its own staleness visible, so Home Assistant can alert on it.

Step 1 — per-batch timeout and the 50 ms spacing

The inverter is polled in register batches. Each batch gets its own timeout (in the read_batch helper, as an asyncio.wait_for), and there's a 50-millisecond pause between two reads — the SDongle is too slow to answer reads in quick succession and punishes haste with timeouts. The crucial bit is distinguishing the two exceptions: a single TimeoutError is survivable (one batch is missing this round), but any other exception means the connection is probably dead — then we leave the loop immediately via break instead of hammering a dead socket.

for start, count in REGISTER_BATCHES:
    try:
        values = await read_batch(reader, writer, start, count)
        if values:
            async with cache_lock:
                for i, val in enumerate(values):
                    register_cache[start + i] = val
        await asyncio.sleep(0.05)  # 50ms between reads — the SDongle is slow
    except asyncio.TimeoutError:
        fail_count += 1
    except Exception:
        fail_count += 1
        break  # connection probably dead, leave the loop

The break is the heart of it: a single timeout must not abort the batch pass — otherwise every passing glitch loses you half the register set. But a real ConnectionError or a torn-down stream has to end the pass, so the outer loop can build a fresh reconnect instead of reading blindly into the void.

Step 2 — fast-retry-then-backoff and the stale-cache warning

The outer reader loop decides how often to reconnect. The logic is deliberately asymmetric: after a successful poll we wait the normal POLL_INTERVAL (10 s). When a poll fails, we retry fast — capped at 10 s, so a brief hiccup is bridged in seconds without flooding the SDongle with reconnect attempts. And then the most important part: when the cache is older than 120 seconds, we write an explicit Cache stale warning to the log.

retry_delay = 5
while True:
    success = await read_sdongle()
    if success:
        last_update = time.time()
        retry_delay = POLL_INTERVAL
    else:
        retry_delay = min(retry_delay, 10)
        age = time.time() - last_update if last_update > 0 else -1
        if age > 120:
            logger.warning(f"Cache stale for {age:.0f}s")
    await asyncio.sleep(retry_delay)

That one log line is the difference between a proxy that lies and one that's honest. It makes staleness observable. In Home Assistant you can catch it on the consumer side: a sensor that hasn't updated for minutes flips to unavailable — and you can hang a push notification off that, just like any other anomaly (see the pattern in the PV string anomaly post).

Step 3 — client idle timeout against dead connections

The other side of the proxy is the clients (HA, evcc, a second dashboard). Without an idle timeout, dead client connections pile up — an HA restart, a crashed container, and the old socket sits open forever. Every Modbus request starts with a 7-byte MBAP header; we read it with a 60-second timeout. If nothing arrives, or fewer than 7 bytes, the client is gone and we close the connection cleanly.

header = await asyncio.wait_for(client_reader.read(7), timeout=60)
if len(header) < 7:
    break  # Client disconnected

60 seconds is generous — HA typically polls every 30–60 s, so a healthy connection easily outlives the timeout. A dead connection, on the other hand, never sends another header and gets reaped within a minute at most, instead of holding a slot and memory hostage.

Configuration — never real LAN IPs

All the values that change live at the top in a config block. Put in your own SDongle address — a DHCP-reserved LAN address is ideal so it doesn't drift. The port is 502 or 6607 depending on firmware. Never publish your real LAN IP in a gist or forum post; use placeholders, like here.

# Configuration (mit eigenen Werten ersetzen)
SDONGLE_HOST = "YOUR_SDONGLE_IP"   # z.B. eine DHCP-reservierte Adresse im LAN
SDONGLE_PORT = 502                 # oder 6607, je nach Firmware
DEVICE_ID = 1

SERVER_HOST = "0.0.0.0"
SERVER_PORT = 5502
POLL_INTERVAL = 10  # seconds

Numbers from long-term operation

These values were tuned over months of real operation with a Huawei SUN2000 SDongle. 50 ms spacing: below it timeouts piled up, above it the poll got sluggish. 10 s poll interval: fine enough for PV data and gentle on the SDongle. 120 s stale threshold: two missed polls plus headroom. 60 s client idle: covers any sane HA scan interval. Tune them to your hardware, but start here.

Frequently asked questions

Why not just use the ready-made ha-modbusproxy add-on?

You can — the add-on is good and takes the work off your hands. This post is for those who built their own proxy (or want to understand what happens underneath) and need to control the reliability layer themselves. The failure modes and thresholds here apply conceptually to any caching proxy, self-built or add-on alike.

My cache still freezes sometimes — why?

Almost always the missing break in the batch loop: if the connection dies but a read throws only a TimeoutError instead of a ConnectionError, the loop keeps running against the dead socket and the outer loop never rebuilds. Make sure a real connection failure leaves the batch pass. Second suspect: a read with no asyncio.wait_for at all — a single read without a timeout is enough to block the whole loop forever.

How do I alert on a stale cache in Home Assistant?

Easiest is via the sensor staleness itself: a Modbus sensor that stops getting fresh values goes unavailable after a few missed scans. Hang an automation off that with a state trigger to unavailable and a for duration of a few minutes to ride out brief dropouts. If you want it more explicit, build a template binary sensor that checks the age of the last update against a threshold.

Which SDongle port is correct — 502 or 6607?

Depends on the SDongle firmware. Older firmware often speaks the standard Modbus port 502; newer ones moved Modbus TCP to 6607 in places, or require you to enable it in the FusionSolar app first. Try 502 first; if the connect is refused outright, use 6607. If nothing happens at all, Modbus TCP on the dongle is probably still disabled.