Category: News

I have a soft spot for Shelly relays. They are the boring, reliable boxes behind my light switches, and they have mostly done what a relay should do, which is nothing noticeable. So when Shelly announced ThreadLink in early September, a free opt-in firmware that moves Gen4 devices from Wi-Fi to Thread, I read the announcement twice. Then I noticed the part that matters most: as of mid-October it still has not shipped.

That is the whole story of this post. There is a genuinely interesting idea here, and there is a long list of things nobody knows yet. I would rather write down both lists than pretend I have tested something I have not. My sources are Shelly’s own ThreadLink announcement and a careful third-party explainer, Local Smart Home Guide, which also checked where things stood on 16 October.

What ThreadLink actually is

Gen4 Shelly devices carry a multi-protocol chip with Wi-Fi, Bluetooth and an IEEE 802.15.4 radio. Today that last radio is used for Zigbee mode. ThreadLink would use it to join a Thread mesh instead, and here is the twist: it is not just “Matter over Thread”. Shelly says it runs a full IP stack on the Thread link (IPv6 with 6LoWPAN, UDP, and TCP), so one radio can carry three things at once: Matter for your ecosystem, Shelly’s own local RPC API for device-to-device scenes and interlocks, and the Shelly Cloud connection.

The cloud part works without Wi-Fi credentials stored on the device, via NAT64 translation at a Thread border router. I do not use the Shelly cloud, so that is not my headline feature, but the other two are. Local device-to-device logic that keeps running when the router is down is exactly what I want from a light switch.

Why a local-first person should care

My Wi-Fi network carries a lot of small, chatty clients, and every relay I add is one more. Moving them onto a low-power mesh would free those slots and, in theory, make the house less dependent on one access point. I wrote recently about why I want separate radios for Zigbee and Thread, and ThreadLink fits that way of thinking: the Shelly does its own radio work, and my coordinator stays a coordinator.

It also keeps the escape hatch open. It is per-device and opt-in, so a relay can stay on the standard Wi-Fi firmware if I decide the mesh is not worth it. Nothing forces a migration.

What is still unknown

This is where I slow down. The honest list, as of today:

No release date. Shelly said roughly three months after the announcement, which points toward early December, but no firm date has been given. No eligible-model list. The announcement says “eligible Gen4 devices” and names none. Gen3, Gen2 Plus, BLU and Wave are not mentioned at all. No measured numbers. The reliability and latency claims are Shelly’s own and I have not seen independent testing, which is understandable for software that has not shipped.

There is also an older wrinkle worth knowing about. Back in July, German outlet SmarthomeAssistent reported that Shelly would bring Matter over Thread to the Gen4 line, and noted that flash memory on these devices is tight, which is why a separate firmware was planned rather than one image doing everything. That reporting was thinner on sourcing than I like, but ThreadLink looks like the official form of that plan, and the flash constraint is a good reminder to check which features survive the switch, local scripting above all.

The Home Assistant side

Two paths, one real and one promised. The Matter path should work the way Matter devices already do in Home Assistant: you need a Thread border router and the Matter Server app. Matter is multi-fabric, so the same device could sit in Home Assistant and another ecosystem at the same time. The promised path is a dedicated Shelly module that exposes the full feature set beyond what the Matter data model covers. Shelly has said it is coming; nobody has said what it looks like. Home Assistant’s current Shelly integration supports all four Shelly generations over local push, and I would want that kind of depth before moving anything critical.

The border router requirement is the practical gate. Cloud access and app control need one on your network; device-to-device scenes run inside the mesh without it. Home Assistant can use any Thread border router but can only configure OpenThread ones. If you do not have one yet, Local Smart Home Guide notes that the older Yellow and Connect ZBT-1 are discontinued and recommends the ZBT-2 for new purchases. That matches what I concluded in my own coordinator shopping.

What I am doing about it

Nothing yet, deliberately. I am not buying hardware for a firmware that has no date. My Wi-Fi relays are reliable, and the bar for replacing something that works is high. The plan is simple: wait for the eligible-model list, wait for the firmware, then move one low-stakes relay, watch it for a few weeks, and write down what happens, including the ugly parts.

If you already own Gen4 devices and have a border router, you are in a good position to wait. If you do not, do not buy for ThreadLink. A radio profile is one at a time on these chips (Wi-Fi, Zigbee or Thread), so you will be choosing one, and I would rather choose with real-world reports in hand. I will update this when the firmware lands.

Sources: Shelly, ThreadLink announcement; Local Smart Home Guide, ThreadLink explained; SmarthomeAssistent, July report on Gen4 and Thread.

On October 13 the Home Assistant team announced that LEDVANCE, the company that inherited OSRAM’s general lighting business in 2016, is now a Works with Home Assistant partner. The headline number is 116 certified devices. My first reaction was a shrug, because lighting is the most crowded corner of the smart home. My second reaction, after reading the announcement twice, was more interesting: the certification terms are the actual story, not the bulbs.

What “certified” actually promises

According to the announcement, a Works with Home Assistant device has to do what you would expect inside Home Assistant, work locally with no cloud dependence, and keep doing so long term. The team says its in-house testers checked the LEDVANCE range for local control and privacy, using a standard Wi-Fi connection and the certified Matter integration.

That last detail matters. Every certified LEDVANCE device here uses Matter over Wi-Fi, so there is no hub, no bridge and no vendor app in the loop for control. The announcement does not mention Zigbee or Thread at all. If you, like me, have a Zigbee mesh doing the heavy lifting, these are not drop-in additions to it. They are Wi-Fi devices that happen to speak a local, open protocol.

What is in the range

Per the announcement, the lineup covers filament-style bulbs, spotlights, recessed and track downlights, ceiling and wall lights, floor lamps and flexible LED strips, most of them tunable white or full color. There are IP-rated options for bathrooms and outdoors, a SMART+ Plug, and smart wall switches that control a ceiling light while keeping your existing bulbs. The range sits under the OSRAM SMART+ name, since LEDVANCE still sells OSRAM-branded products under a licensing agreement.

The post does not list model numbers, prices or firmware requirements, and sends you to the certified device list instead. So I cannot tell you which bulb to buy, and I will not pretend to. I have not tested any of these myself.

Why a lighting brand certifying matters more than the bulbs

Smart lighting has a long history of the following pattern: cheap hardware, a pleasant app, a cloud account, and a quiet end-of-life notice a few years later. A certification that explicitly demands local operation and long-term behavior is a direct answer to that pattern. It gives a buyer something to check before purchase, rather than something to discover after the vendor pivots.

It also fits the local-first rule I run my house by: if a device stops working when my internet does, it does not belong on a light switch. Matter over Wi-Fi is not my favorite transport, since a crowded 2.4 GHz network is a real cost when you add dozens of bulbs, but it is local, and local beats clever.

The caveats I would keep in mind

First, the announcement is written by Home Assistant itself and ends with a pitch for its Link subscription plan, so read it as a partnership post, not an independent review. Second, the long-term support is a commitment attributed to LEDVANCE, and the post does not spell out the terms. A promise is only as good as the firmware updates that follow it. Third, the team notes that a device missing from the list is not necessarily unsupported; it may just be untested or use a different connection type.

The company’s own quote is easy to agree with: product manager Pulkit Dhanuka says openness and interoperability are essential for the future of smart homes. I will believe it when the first firmware update arrives without asking for an account.

What I will do with this

Nothing yet. My Zigbee bulbs work, my mesh is stable, and I do not replace working hardware to follow a trend. But if I were building a new room from scratch today, especially one far from a Zigbee router, a certified Matter-over-Wi-Fi light is now a defensible option rather than a gamble. When I pick one up, I will write down how it behaves after a router reboot and after a month on the network, because that is where lighting claims tend to get honest.

If you are already running any of these, tell me in the comments how the pairing went and whether anything phoned home. I would rather publish your real-world notes than my guesses.

A few days ago I wrote that I was not updating to Home Assistant 2026.10 on release day, and listed what I would check first. Since then, other people have done the uncomfortable part for me. In the German-language simon42 community forum, a thread opened on 7 October collects what broke after the update. I read it end to end, and I think it is more useful than any changelog, so here is what I took from it.

A caveat first: this is a forum thread, not a bug tracker. Reports are anecdotal, mostly about 2026.10.0, and the thread title already points at 2026.10.1, which the official changelog lists as released on 10 October. Some of what follows may already be fixed. I am reading it as a map of where to look, not as a verdict on the release.

The pattern: custom integrations break first

The loudest reports are not about Home Assistant itself. One user reported that the EcoFlow Cloud custom integration (version 1.7.1) would not start and rolled back to the previous version; another was already running the EcoFlow IoT integration in parallel, where things kept working, and planned to switch. A third reported that a custom Ecovacs integration refused to load because it could not find cryptography==48.0.1, even after installing the package by hand. That user went back to 2026.9, and the thread links a core issue for it. The workaround that reportedly worked for someone else was to remove the integration, delete its folder under custom_integrations, restart and set it up again.

None of this is surprising, and none of it is Home Assistant’s fault in a simple sense. Custom integrations pin dependencies, core bumps dependencies, and the two collide on update day. But it is a good reminder of what the real risk is on my own box: not core, but the handful of things I installed from outside it. Every custom component is a small bet that its maintainer ships a fix within days of a release.

The one that hits automations: input_select conditions

The report I would take most seriously is an automation error: “Cannot use ‘for’ with a list of states”. One user hit it with a state condition on an input_select helper and made it go away by swapping the condition for the dedicated “dropdown option selected” condition instead. I cannot reproduce that, so I will not claim to know the exact trigger. But the lesson is cheap to act on: before an update, search your automations for state conditions that compare helpers against lists, and know where they are.

The editor change people are grumbling about

The other cluster of complaints is about the new automatic trigger IDs. Several users said custom, human-readable trigger IDs can no longer be set in the visual editor and now require YAML, and a frontend issue was opened on 8 October saying custom IDs are not displayed in the new trigger picker. One user fixed a display glitch simply by clearing the browser cache, which is the most boring and most common fix in this hobby, and worth trying before you file anything.

I understand the design instinct: automatic IDs save typing for people who never name theirs. But I name mine, because “trigger 3” in a trace tells me nothing at 2 a.m. If your automations lean on named IDs in choose blocks, this is a place to look closely rather than assume.

Not everything is a regression

To keep this fair: the thread also has good news. One user ran the repairs dialog and fixed 23 entities whose area did not match their device. Another said KNX runs normally on 2026.10.0, while a different user reported KNX trouble, so the same integration produced both a success story and a complaint, which usually points at setup differences rather than a clean bug. And one reported Proxmox install that hung at “Still waiting for Home Assistant Core to start” had no resolution in the thread, with the poster suspecting their reverse proxy. A hanging system is the scary kind of report, but one unresolved case is a data point, not a trend.

The historygraph looking “broken” to one user turned out, per another poster, to be the new frontend layout rather than a bug. I mention it because the 2026.10 release rebuilt the map card and touched card layouts, and some of the “my dashboard is wrong” energy is really “my dashboard is different”.

What I am changing in my routine

Reading the thread, three habits earn their keep. First, I take a backup and copy it off the machine before any minor update, not just before the scary ones. Second, I write down which custom integrations I run and check each one’s issue tracker on release day, because that is where the thread says the pain concentrates. Third, I wait for the first patch release. Most of the reports I read were against .0, and a few days of other people’s bug reports is a cheaper test environment than my own living room lights.

The thread’s authors suggest the same basics: read the backward-incompatible changes and keep an external backup. It is dull advice, and it is the advice that works. Thanks to everyone in that thread for documenting their breakage so publicly; this is the part of the open-source smart-home world I would not trade for any cloud dashboard.

Home Assistant 2026.10 lands today, and I will say up front: I have not installed it. My update routine since the 2026.9 patch notes is to read first, wait for the first point release, and only then touch the production box. So this is a read-through of the release notes and beta coverage, not a field report. Field notes will follow once I have actually lived with it.

Still, a few things in this release say something about where Home Assistant is heading, and two of them touch the local-first philosophy this blog is built on.

The map stops phoning a third party

The headline feature is a redesigned Map dashboard. According to the beta write-up at Smart Home Assistant, it moves from third-party tile providers to OpenStreetMap vector tiles, so streets and labels stay sharp at any zoom level. There is a new overview tab showing people, devices and zones with activity history, and markers now use profile pictures for people and icons for zones. On mobile, details move into a pull-up sheet.

I have ignored the map for years, mostly because it was a grey rectangle with a dot on it. Whether the new one earns a place on my dashboard depends on something I can only judge after using it: how much of this is rendered locally, and what still gets fetched from outside when I open it. Vector tiles are a good sign for sharpness, but tiles still have to come from somewhere. I will check the network traffic when I update, and report back.

“Triggered by” is the quiet winner

If you have ever written an automation with several triggers and then a choose block that branches on trigger IDs, you know the chore: invent an ID, type it in the trigger, type it again in the condition, and hope the two spellings still match three months later. The new “Triggered by” condition lets you pick the trigger directly, without managing IDs by hand. Per Smart Home Centre’s summary, existing YAML keeps working, so nothing forces a rewrite.

It is not glamorous, but it removes a classic source of silent breakage, and I expect it to shorten a few of my longer automations. Dashboard cards also gain broader visibility conditions (template, sun, zone and device on top of screen and user), which should help with the kind of “only show this when it matters” dashboard I wrote about after 2026.9.

An MCP server, one click away

There is now a dedicated AI settings page that exposes a Model Context Protocol server with a shareable URL, so tools like Claude or ChatGPT can talk to your Home Assistant. It is optional, and I understand why people want it. But my honest take is simple: a URL that lets an external assistant read and control my house is exactly the kind of thing I want to think about before enabling, not after. If you do turn it on, look carefully at which entities are exposed and who can reach that URL. I will not be enabling it on the production instance until I have read the access model properly.

Small things worth knowing

Matter leak sensors get separate switches for audible and visual alarms, which is a thoughtful detail: loud next to the washing machine, notification-only under the bedroom-adjacent sink. Smart plugs and energy monitors can report mains frequency and power factor. Household members can edit their own profile picture and name without an admin. Active alerts show on the Home dashboard, and there are separate energy readings for home battery discharge. Fifteen new integrations arrive and eight are removed because their services were discontinued.

Read the breaking changes before you click update

This is the part that matters most for an update day. The beta coverage lists legacy authentication being removed, with usernames normalized to lowercase without spaces. If you have an old account with a capital letter or a space in the name, check that before you update, not after you are locked out. Telegram bot users need to allowlist download directories, Sofar inverters without energy meters lose six energy sensors, and UniFi Network cannot be reconfigured by re-adding it. The official release notes carry the authoritative table; treat the list above as a pointer, not a substitute.

What I will do

Take a full backup, read the breaking-changes table against my actual integrations, wait for 2026.10.1, and then update. After that I will test the map with the network tab open and decide whether it earns a spot. If the traffic looks clean, expect a follow-up with screenshots. If not, expect that too.

Sources: details above come from the beta coverage linked inline; I have not yet verified them against the final release post.

Last Friday Nabu Casa announced that Home Assistant Cloud is being renamed Home Assistant Link. My first reaction was an eye-roll: a rebrand, how exciting. My second reaction, after reading the announcement post, was more interesting. The rename is really an argument about words, and I think it is a fair one.

Why the name never fit

According to the post, the old name caused real confusion. Some people assumed “Home Assistant Cloud” meant Home Assistant running in somebody else’s data center, when it has always been software that runs in your own house. Nabu Casa also admits the label sat awkwardly next to the project’s own advice to avoid cloud-dependent devices. I have felt that tension myself. I run Home Assistant OS bare-metal on a used HP EliteDesk, I tell people to keep things local, and the project’s own optional subscription carried the word I try to avoid.

I have explained the difference to friends more than once. “No, it is not in the cloud, it is just a tunnel and some extras.” A name that needs a footnote is a bad name. Link says what the thing does: it links a local installation to a handful of online features.

What Link actually is

The list is short and unchanged: remote access without port forwarding or VPN setup, the Alexa and Google Home integrations, online speech-to-text, private backup storage, human support, and a new account management interface with a setup wizard. The announcement is explicit that your home keeps working locally without it, that you can cancel at any time and keep everything, and that the service funds a nonprofit rather than shareholders. The post sets this out in a comparison table against Big Tech clouds: optional versus required, no lock-in versus walled garden. It is marketing, yes, but every row is checkable. You can unplug Link tomorrow and nothing in your house stops.

The official switch is planned for the 2026.12 release in December, and the team says it wants community feedback before making it final. No new pricing was mentioned in the post, so I will not guess at any.

Where I land, as someone who does not subscribe

I should be upfront: I do not use the subscription. My remote access is my own setup, and my backups go to storage I control. That is a choice I made because I enjoy owning the plumbing, not a claim that everyone should. For a lot of households, paying a small amount for remote access that just works, with money going back into the project, is a good deal. Most of the people I would like to see running Home Assistant do not want to maintain a reverse proxy. If Link is how they stay local-first for everything else, that is a win for the philosophy, not a compromise of it.

What I care about is the test the post itself implies: does the thing degrade gracefully? When Link is off, the lights, the automations, the Zigbee network and the dashboards should not notice. That was true of Cloud, and I expect it to be true of Link. Until the pricing and the transition details are published, the rename tells me nothing new about that. It only tells me how the team wants to be understood.

What I will watch before December

Three things. First, whether the new account management and setup wizard make it easier to see exactly what Link is doing for you and to turn individual pieces off. Second, whether existing subscribers get a clear explanation of what changes, because the announcement does not cover transition specifics. Third, whether the word “optional” keeps showing up in the documentation as loudly as it does in the announcement. Naming is the cheap part of trust. The expensive part is the boring promise that your house keeps working when the subscription ends.

If you do use Cloud today, I would read the original post and leave feedback while it is still being asked for. If you do not, this is a good moment to look at which parts of your remote access you would be happy to hand over, and which you would rather keep on your own hardware. I will keep my own tunnel for now, but I no longer roll my eyes when someone tells me they have Link.

Patch releases are the part of Home Assistant I used to skim. The headline features go into the monthly release, the .1, .2 and .3 follow, and I would click Update whenever the badge appeared. This month I stopped and read the release notes for 2026.9.2 and 2026.9.3 line by line instead. It took ten minutes, and it changed how I think about what a “boring” update actually contains.

Here is what I found, what applies to my bare-metal install, and the small routine I now follow before pressing the button.

What is actually in 2026.9.3

The 2026.9.3 release landed on 18 September and lists 23 changes. Almost all of them are integration-level bug fixes and dependency bumps. A few are worth a closer look because they are not cosmetic.

The Backup fix now encrypts and decrypts supervisor.tar correctly when a backup is rewritten. If you keep encrypted backups, which you should, that is exactly the type of bug you only discover on the day you need a restore. The Private BLE Device flow now requires the IRK, the identity resolving key, so you cannot end up with a half-configured tracker. Onboarding now validates the username before creating the user, and AirVisual no longer writes its API key into debug logs.

The rest is the long tail of a big ecosystem: a Matter cover that was not created when the tilt attribute was null, an Alexa doorbell that raised an error in state reports, a Nest thermostat turn_on that is now idempotent, an EnergyZero price regression, and Reolink, Lutron and Waterfurnace library bumps. None of those touch me directly, and that is precisely the point: a patch release is a bundle of other people’s fixes, and the chance that one of them is yours is higher than it feels.

And 2026.9.2, a week earlier

2026.9.2 (11 September) had the same shape: Hive login normalisation, a Vizio soundbar authentication fix, a ZHA library bump to 2.2.2, a frontend update, and credential redaction in go2rtc logging, which is the second “stop leaking secrets into logs” fix in two weeks. Two consecutive patch releases quietly closing log-leak paths is a nice reminder that the debug log is a place where secrets end up, so I never paste one into a forum thread unread.

The one thing that did draw complaints was not a bug at all. A community thread about the History page notes that the new layout reserves a panel for entity tags and leaves “barely half a screen” for the graph. Another user pointed out that the panel collapses via the Sources button at the top left. I would call that a discoverability problem rather than a defect, but it is a fair example of how even a patch release can change your daily workflow.

The routine I now use

Running Home Assistant OS on a used HP EliteDesk means I am the only person responsible for it. There is no vendor sitting between me and a bad update, so I keep the process short and dull.

First, I read the release notes for every patch, not only the monthly one. I am not looking for my integrations by name so much as for the words backup, auth, security, redact and migration. Those are the lines that change what I should do next. Second, I take a fresh full backup before updating, and I check that it is encrypted and that I can see it in the list. Third, I update on a quiet evening rather than in the morning while the household is trying to switch on lights. Finally, I glance at the log for new warnings for a day, and only then do I stop thinking about it.

None of this is heroic. It is the smart-home equivalent of looking both ways before crossing a quiet street. But local-first cuts both ways: no cloud means no one else can break my house, and also no one else will roll it back for me.

Should you update straight away?

My honest answer is yes for patch releases, with a backup, and I am more relaxed about it than I am about the .0 release. By the third patch a monthly release has usually been through a few thousand real installations, and the fixes are aimed at exactly the papercuts they found. If you use one of the integrations in the list above, the case gets stronger. If you keep encrypted backups, it gets much stronger.

The exception is the moment you rely on something fragile, like a custom integration that has not caught up with a core change. In that case read the notes twice, check the integration’s issue tracker and wait a week. Nobody ever lost a house to being seven days behind on a patch.

Next month I will be back with whatever the 2026.10 beta brings. Until then, go and read your release notes. They are shorter than you think, and this month they were more interesting than I expected.

Eight days ago a deadline started existing that did not exist before. Since 11 September 2026, any manufacturer placing a connected product on the EU market has 24 hours to tell a national CSIRT when one of its vulnerabilities is being actively exploited. That includes the smart plugs in my hallway, the Zigbee sensors on my window frames, and the mini PC my whole house runs on.

I did not notice. Nothing in my Home Assistant dashboard changed. No vendor emailed me. The change happened entirely on the legal side of the smart home, which is exactly the part I normally ignore, so I spent an evening reading the actual text instead of the headlines. Some of it is better than I expected. One part of it is weaker than the headlines suggest, and it happens to be the part that concerns me as the person living in the house.

What actually switched on this month

The law is the Cyber Resilience Act, Regulation (EU) 2024/2847. It entered into force in December 2024, and most of it does not apply until 11 December 2027. Article 14 is the exception: it applies from 11 September 2026, and Article 14 is the reporting article.

Two things have to be reported. An actively exploited vulnerability, meaning there is reliable evidence somebody is already using it against systems without permission. And a severe incident affecting the security of the product. The timeline is an early warning within 24 hours of the manufacturer becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a fix or mitigation being available. For a severe incident the final report is due within a month.

Reports go through one portal, the Single Reporting Platform, which ENISA switched on the same day the obligation started. A vendor files once, the receiving CSIRT distributes to the other member states where the product is sold. I like this part. Coordinated disclosure in the smart home has historically meant a researcher tweeting at a vendor and hoping.

Two details I had to read twice. First, “aware” is not the moment a bug report lands in an inbox: Commission guidance from July puts it at the point where an initial assessment gives a reasonable degree of certainty. Second, the clock does not pause for weekends or public holidays, so a Friday evening disclosure is somebody’s Saturday. And one more that matters in a flat full of older kit: the obligation covers products already placed on the EU market before the regulation fully applies in December 2027. My four-year-old sensors are not grandfathered out.

The 24 hours are not for me

This is the bit worth being precise about, because the coverage I read collapsed it. The 24-hour deadline is the manufacturer’s obligation toward CSIRTs and ENISA. The obligation toward me exists too, but it is written differently: manufacturers have to inform impacted users, and where appropriate all users, about the vulnerability or incident and any mitigating measures they can take. Without undue delay. No hour count attached.

I do not think that is scandalous. There are good reasons not to force a public announcement 24 hours into an active exploitation, before a fix exists, and the authorities being told first is the point of the design. But it does mean the mental model of “the EU now guarantees I hear about it within a day” is wrong, and I would rather run my house on the accurate version. I still find out the way I have always found out: release notes, GitHub, the vendor’s changelog, and whatever shows up on the Home Assistant community forum before either.

There is also a gap I cannot fully resolve as a non-lawyer. The reporting duty applies now, but the penalty and market surveillance machinery in the rest of the regulation does not arrive until December 2027. So for the next fifteen months the obligation is real and the consequences of ignoring it are thinner than they will be. Treat that as my reading of the application dates, not legal advice.

Home Assistant is not on this clock yet

The CRA invented a category for projects like the one running my house: the open-source software steward. A steward is not a manufacturer. No CE marking, no Declaration of Conformity, no administrative fines. It carries a lighter set of duties: a cybersecurity policy, cooperation with authorities, and reporting. And genuinely free and open-source software supplied outside a commercial activity sits outside the scope entirely.

ENISA’s launch note is explicit about the timing: the steward reporting duty sits in Article 24(3), and that article applies from 11 December 2027. So Home Assistant Core, ESPHome and Zigbee2MQTT are not filing with a CSIRT this month. Home Assistant Green, the Home Assistant Connect ZBT dongles and Home Assistant Cloud are a different story, because those are sold products with a company behind them.

Which is why the most convincing evidence that this regulation has teeth is not a press release. Nabu Casa currently has a Product Security & Compliance Engineer opening, and the description reads like a CRA to-do list: vulnerability handling, security updates, SBOMs, defined support periods, incident reporting, plus EN 18031 and the Radio Equipment Directive. Shelly Group has posted a comparable role. Two smart home vendors I actually buy from are hiring people whose job is to know when the 24-hour clock started. That is a more honest signal than any compliance badge on a box.

My house is in Switzerland, which has none of this

Here is the slightly uncomfortable part of writing this from Switzerland. Switzerland is not in the EU, and there is no Swiss equivalent of the CRA. The Federal Council acknowledged that in August 2025 and told the federal cyber security office, together with OFCOM and SECO, to draft a bill for consultation by autumn 2026, explicitly aligned with the CRA. Autumn 2026 is now. A consultation draft is still several years away from being a law I benefit from.

Meanwhile every Zigbee sensor and smart plug I own was designed for the EU market and sold to me through a Swiss retailer out of essentially the same stock. I get the security work for free, as a side effect of my hardware needing to be sellable in Germany. It works, and I am not going to pretend otherwise. But it is spillover, not protection. If a vendor decided the Swiss channel was not worth the same support period, nothing local stops them today.

What I am actually doing about it

Nothing dramatic, because the CRA does not make any device in my flat better this month. What it changes is the cost of silence for the companies I buy from, and that shows up in purchasing decisions rather than in my configuration files.

Three things I now check before buying, which I did not check this carefully a year ago. Whether the vendor publishes a security contact and an advisory feed at all, because a company that has to report within 24 hours in 2027 probably starts building that habit in 2026. Whether firmware updates can be applied locally, without the vendor’s cloud, since an advisory I cannot act on is trivia. And whether the product page states a support period, because the CRA is going to force that number into the open and I would rather buy from whoever says it voluntarily first.

The rest of my defence is unchanged and unglamorous: almost nothing in this flat can reach the internet, the Zigbee network has no cloud dependency, and my hub is a used office PC whose firmware I patch myself. Local-first was never primarily a regulatory argument. It just happens to be the setup where a vulnerability disclosure I hear about three weeks late is still a manageable problem.

Ask me again in December 2027, when the rest of this regulation arrives and the support-period numbers have to be printed somewhere I can read them. That is the date I have actually put in my calendar.

There is a specific kind of dread that comes with re-pairing a Zigbee device. Not the pairing itself — that part usually works. The dread is about everything around it: the friendly name you picked two years ago and that eleven automations now depend on, the debounce you tuned, the temperature offset you worked out by holding a reference thermometer against the wall for ten minutes, the retain flag, the group membership. Remove the device, and Zigbee2MQTT throws all of it away. Pair it again and you get a fresh 0x00158d0004a1b2c3 with default everything, plus a quiet trail of broken automations you will discover over the following week.

That has been the deal for as long as I have run Zigbee2MQTT. It is the reason I have left a dying wall switch in place for months rather than touch it. Zigbee2MQTT 2.13.0 and 2.14.0 quietly changed the deal, and almost nobody noticed, because both changes landed as one-line entries in release notes dominated by device converters.

What actually changed

Zigbee2MQTT 2.14.0, released on 1 September 2026, added a keep_config flag to the device remove request. The pull request describes it plainly: previously, device removal always deleted the stored device configuration; now the remove request can explicitly keep that configuration intact. The device leaves the network. Its settings stay in your database, waiting.

In practice that is a single extra key in the MQTT payload you send to zigbee2mqtt/bridge/request/device/remove:

{"id": "kitchen/ceiling_switch", "keep_config": true}

Pair the same physical device again, and it comes back as itself: same friendly name, same options, same offsets. No renaming, no re-tuning, no automation archaeology.

A month earlier, 2.13.0 had added the mirror-image option: clear_cache. That one throws more away, deliberately. It wipes the cached interview data so the next join starts from a clean slate with a full interview from scratch. The PR is explicit about why this matters — it removes the need to restart in what the project used to call the “remove/restart/re-pair” dance. If you have ever been told on a forum to restart Zigbee2MQTT before re-pairing a device that refuses to interview properly, that restart was working around exactly this cache.

So the remove request now has four modifiers, and they are not interchangeable:

• keep_config — device leaves the network, its saved configuration survives. Use when you know you will re-pair it.
• clear_cache — forget the device completely, including cached interview data. Use when a device is behaving strangely or when you are developing firmware for one.
• force — remove from the database only. The device still holds the network key until it is factory reset, and can still talk on your network.
• block — ask the device to leave again immediately if it ever tries to rejoin.

The documentation covers all four, and the bridge response now echoes every flag back, so you can confirm what actually happened rather than guessing.

The catch, and it is a real one

At the time 2.14.0 shipped, keep_config is an MQTT-level flag. The pull request closes with “Next steps: Update frontend with a toggle to activate this.” If you do all your device management through the Zigbee2MQTT web UI — which is most people, reasonably — the remove button still behaves the old way. The feature exists, but you have to reach past the interface to use it.

That means one mosquitto_pub command, or a two-line script action in Home Assistant that publishes to the bridge topic. It is not hard. It is just not discoverable, which is why a genuinely useful change is sitting unnoticed in a changelog full of Tuya converters. I would rather write this post than let it stay there.

Two other things in this release cycle worth knowing

Covers went upside down, briefly. Two days after 2.14.0, 2.14.1 shipped as a hotfix for several issues where cover states were inverted. Open read as closed, buttons did the opposite of what they said. If you run blinds or shutters over Zigbee and you updated on release day, that was not your wiring. Go to 2.14.1. I mention it because this is the honest shape of running a fast-moving open-source stack: a release every month, an occasional two-day correction, and a maintainer who ships the fix rather than pretending it did not happen. I will take that trade over a vendor cloud that silently changes behaviour and tells me nothing.

Node.js 20 is gone. 2.13.0 dropped support for Node.js 20 because it reached end of life. If you run Zigbee2MQTT bare metal, you need Node.js 24 or 26. If you run it as a Home Assistant add-on or in the official Docker image — as I do on the EliteDesk — this is handled for you and you will never notice. Bare-metal installs are the ones that will fail to start with an unhelpful error if you skip this.

While we are on the subject of things that changed under bare-metal installs: since 2.11.0 in June, external extensions and external converters are disabled by default for new installations. Existing setups keep working. New ones need enable_external_js set in the advanced section of the configuration. This is the right default — an external converter is arbitrary JavaScript executing inside the process that holds your Zigbee network key — but it does mean a fresh install will silently ignore a converter you copied over from an old one.

Why this is the kind of change I care about

Nothing here is exciting. There is no new protocol, no new device class, no announcement video. keep_config is a boolean in a JSON payload.

But the friction in a self-hosted smart home is almost never the big architectural stuff. It is the accumulated cost of small irreversible operations — the ones where a routine maintenance task quietly destroys configuration you spent real time producing, and you only find out three automations later. That cost is what makes people stop maintaining their setup. It is what makes a dying switch stay on the wall for six months.

A flag that lets me swap a failing device without losing its identity is worth more to me than another dashboard card. It makes the system feel less like a house of cards and more like something I am allowed to work on. That is the whole point of running this locally.

The switch comes off the wall this weekend.

There is a folder on my phone full of blurry photos, and every single one is the back of a smart home device. The QR code, the setup code printed underneath, sometimes the serial number if I was being thorough. I take them before I install anything, because I learned the hard way that the sticker you need is always on the surface that ends up facing a wall.

Matter 1.6 is quietly trying to make that folder obsolete. And this week in Berlin, the first piece of hardware that actually does it turned up on a show floor.

What Matter 1.6 actually changed

The Connectivity Standards Alliance published Matter 1.6 back in June. Joint Fabric got most of the headlines, but the change I keep thinking about is the boring-sounding one: NFC as a commissioning transport.

This is not the same as what came before. Matter 1.4.1 already let you put the commissioning payload — the thing normally encoded in that QR code — onto an NFC tag. But Bluetooth LE still had to carry the actual handshake. The tag was a convenience; BLE was the pipe. In 1.6, NFC itself is the pipe. The whole exchange runs bidirectionally over the 13.56 MHz coupling that every modern phone already has.

That has a side effect that sounds like a typo the first time you read it: the device does not have to be powered on. The commissioning data sits on the NFC chip and waits. You can pair a bulb before you screw it into the fixture. You can set up an in-wall switch before the mains is live. For anyone provisioning fifty devices in a building, you can do the whole batch on a table and then go install them.

The first hardware showed up at IFA

At IFA Berlin this week, Heiman showed an HS2HT outdoor temperature and humidity sensor sitting next to a sign reading “Matter 1.6 NFC Pairing Function” — as far as Matter Alpha reports, the first demonstrated hardware using the feature. It is an IP65 sensor, which is a nice bit of symmetry: the outdoor device is exactly the one you least want to be crouching under with a phone torch.

Heiman brought other things too. A WS6GW bridge that pulls Zigbee and Sub-GHz devices into Matter, SC3 smoke and CO alarms offered in separate Matter, Zigbee, Wi-Fi and Sub-GHz variants rather than one device with every radio crammed in, a four-in-one door and window sensor, and an HS1ZT dongle that can run as a Zigbee coordinator, a Zigbee router, or a Thread RCP. No pricing, no availability dates. So this is a “the spec is real” story, not a “go buy this” story.

Worth noting alongside it: the Open Home Foundation had its own booth at IFA for the first time, Hall 1.2, stand 1.2-153, running 4 to 8 September. An open, locally controlled smart home standing on the same floor as the ecosystems it is trying to route around is its own kind of milestone.

My mini PC cannot tap anything

Here is where the enthusiasm meets my basement. Home Assistant spent most of this year rebuilding its Matter stack on matter.js — the old python-matter-server ended at 8.1.2 and is no longer updated. That migration slowed Matter adoption for a while, and then unblocked it: Matter 1.6 support landed in the 1.2.x Matter Server beta along with ICD battery-saving controls, wider Thread diagnostics, and multiple stored Wi-Fi and Thread credentials.

The backend supports 1.6. NFC commissioning still does not work, and the reason is physical. My Home Assistant runs bare metal on a used HP EliteDesk 800 G4 in a cupboard. It has plenty of USB ports and no NFC radio. Even if I bolted one on, the mini PC is not where the sensor is — it is two floors below, behind a door. Per the same reporting, the implementation is still an open discussion: a USB reader, or some proxy device that hands the onboarding payload to Home Assistant.

The obvious answer is the phone. The companion app already scans QR codes; it is already the thing I hold against devices. Turning it into an NFC commissioner is the natural path, but it is real work in the app and in core, and it has not happened yet. So the spec is done, one sensor exists, and the controller I actually run has no way to use it.

What it would honestly buy me

I should be careful not to oversell this to myself. I commission a new device maybe once a month. Scanning a QR code on my kitchen table, with the device in my hand and good light, is completely fine. Tap-to-pair would save me four seconds.

The cases I actually remember being annoyed by are all the same case: the device was already mounted. The sensor on the outside wall. The bulb in the stairwell fixture. The switch I installed before I understood that I would want to re-pair it two years later. For those, commissioning something that is not yet powered and not yet on the wall is a genuinely better order of operations. In January, in Switzerland, on a ladder, with cold hands, “pair it at the table first” is worth more than four seconds.

Batch pre-provisioning, the feature everyone leads with, is an installer feature. In a normal house it is close to irrelevant. I would rather say that plainly than pretend my seven-room flat is a commissioning bottleneck.

The question I want answered before I get excited

The Matter setup passcode has always been physically printed on the device, so NFC does not obviously change the threat model — you need to be standing next to the thing either way. But a printed sticker can be covered with tape, photographed once, and forgotten. A chip keeps answering for as long as it is in the device. I would like to understand how the window behaves after a device is already commissioned, and I have not had a demo unit in my hands, so I am not going to pretend I have tested it.

What I do like: none of this involves a cloud. Commissioning is a conversation between my phone, the device, and my controller, and that is the whole reason I care about Matter at all rather than another vendor app.

What I am doing about it: nothing, yet

There is no product to buy and no setting to enable. What actually changed this week is smaller and more useful than a tap demo: Home Assistant is back on a fast Matter cycle. The 1.6 spec shipped in June and support was in a server beta by July, in the same release window as ICD controls, Thread diagnostics and the groundwork for Matter cameras. Before the matter.js rewrite, that gap was measured in a lot longer than a month.

So I will keep watching the Matter Server changelog, and I will keep taking blurry photos of stickers. But it is a good sign when the most interesting thing at a consumer electronics show is a temperature sensor that you pair by touching it.

I do not own a single Modbus device. No solar inverter, no energy meter, no heat pump with an RS-485 port hiding behind a plastic flap. So the Modbus section of the Home Assistant 2026.9 release notes, published on 2 September, should have been the part I skimmed.

I read it three times instead. Not because of what it does for inverter owners this month — that list is short and I will get to it — but because of the shape of the problem it solves. This is plumbing work, and plumbing work either quietly fixes a decade of pain or quietly goes nowhere. You can usually guess which by looking at where the authors put the code.

The last YAML holdout

Modbus has been supported in Home Assistant for years through the modbus integration, where you hand-write a register map in your configuration. Register 40072 is grid power, scale it by 0.1, it is a signed 16-bit, next. It works. Plenty of people run it. It is also the last significant corner of Home Assistant where understanding a device’s wire protocol is the user’s job.

Everything else has moved the other way. You add Shelly, you type an IP, you get entities. With Modbus you add the device, then you find a PDF from the manufacturer, then you translate that PDF into YAML, then you debug your own translation. That gap has been widening for years, and 2026.9 does not close it. It builds the thing that makes closing it possible.

Why sharing a wire is the hard part

Here is the constraint that explains the entire design, and it is worth stating plainly. A Modbus connection is exclusive: one party talks at a time. But an RS-485 bus, or a TCP-to-serial gateway sitting in front of one, can carry several devices at once, sometimes from different manufacturers. If two integrations each open their own connection to that bus, they do not take turns politely. They contend.

Historically Home Assistant did not support sharing a bus between integrations at all. That is a large part of why Modbus stayed one YAML monolith: one integration, one connection, one owner.

The new approach inverts it. The modbus integration becomes a broker. It hands out units over connections it owns, and a device integration — your inverter, your ventilation unit — collects its own connection details in its own config flow like any normal integration, then asks modbus for a unit on them. Two integrations that ask with identical details get units on one connection, and their requests serialise behind it instead of colliding.

The detail I keep coming back to is that the shared connection is never configured or persisted as something you can see. It exists only while an integration holds a unit on it, and it closes when the last consumer’s config entry unloads. Paulus Schoutsen’s developer post from July puts it better than I can: you set up your heat pump, not a bus. The bus gets a single owner without the user ever learning that a bus exists.

What actually shipped

Three integrations use the new mechanism so far, and it is only fair to say that is a small first crop.

Fronius gained optional Modbus TCP support over SunSpec, alongside its existing local HTTP API. The payoff is per-string data — current, voltage, power and lifetime energy for each MPP tracker — which the HTTP API does not expose. It shares its connection with anything else talking to the same inverter, and that is not academic: some Fronius models accept only a handful of simultaneous Modbus sessions, so people have had to choose between Home Assistant and whatever else they wanted pointed at the inverter.

Sofar Inverter Modbus is brand new: Modbus TCP directly or through a bridge, automatic model detection, and support for both PV-only and hybrid inverters with battery storage. Flexit, for the ventilation units, is built the same way.

That is the whole list. If you run a Huawei, a SolarEdge, a Victron or a Stiebel Eltron, nothing changed for you this month. Your YAML still works, and the release notes are explicit that the old integration is not going anywhere.

The bit that decides whether this matters

The connection layer did not stay inside Home Assistant. It was published as modbus-connection, a standalone PyPI package with no Home Assistant dependency, sitting on top of tmodbus, a modern fully-typed Modbus library.

That is the part I would bet on. A device library becomes an ordinary Python package that knows how to talk to one specific device and mentions Home Assistant nowhere. An integration wires that library to a shared connection and exposes entities. The two can be written and tested independently, by different people, and the library is useful to somebody building a Grafana exporter who has never run Home Assistant in their life. modbus-connection also ships a device-modelling framework and a pytest plugin, which tells you the intent is for other people to write these — not for the core team to write forty of them.

The developer post goes further and includes a ready-made prompt for handing your existing Modbus YAML to an AI agent, complete with a reference implementation to copy. Make of that what you will. As a way of saying “we would like a hundred of these and we are not precious about how you get there”, it is unambiguous.

What I would actually do about it

Nothing, if you have working YAML. There is no migration, no deprecation notice, no reason to touch a running setup. For almost everyone reading this, that is the correct answer.

Two exceptions. If you have a Fronius and have ever been annoyed that your per-string numbers were invisible, the Modbus option is there now and worth enabling. And if you have ever hit the “something else is already talking to my inverter” wall, this is the release that turns that from a fact of life into a solvable problem.

The thing to watch over the next few releases is simple enough to check: does the list of device integrations grow past three? If it does, hand-written register maps become the fallback for obscure hardware rather than the default experience for anyone with a solar array, and that is a genuinely large quality-of-life change for a corner of the smart home that has been stuck for a very long time. If it does not, this stays a well-built piece of infrastructure with almost nothing standing on it.

I will check back at 2026.12. That feels like enough time to tell which one it is.