Home Assistant 2026.10 and your Vome home

Home Assistant's own AI server is now one click, and it hands our tools to your AI apps. ESPHome devices can call Home Assistant instead of waiting to be called. Two breaking changes switch automations off quietly. What we changed the day after release, and what to check before you upgrade.

Posted 22 October 2026 home-assistantreleasesaiesphome

Home Assistant 2026.10 came out on 7 October. It is mostly a map and automation-editor release, and both are good. We read it for the parts that touch homes we run, before any of them upgrade. Three matter.

Your AI apps now see Vome's tools, and the tools now describe themselves

The Model Context Protocol server, the part of Home Assistant that lets an AI app on your laptop talk to your home, now turns on from a card on the AI settings page. New setups offer every AI toolset Home Assistant knows about, to administrator accounts only.

One of those toolsets is ours. The Vome integration registers it so that Assist, the phone app and voice can use the same tools as our in-home chat. On 2026.10, any AI app you connect to Home Assistant gets them too, without any setup.

That is where we found something wrong in our own code. In this release a tool can declare how it behaves: whether it only reads, whether it can destroy something, and whether it reaches outside the house. A tool that says nothing is assumed to do all three, which is the right default, and ours said nothing. So looking up which lights are on reached your AI app labelled as dangerous, and a careful app would stop and ask before every lookup.

Vome 0.3.65 fixes it. Looking is marked as read-only and staying in the house. Changing automations stays in the house but can replace what you made, and is marked as such. Controlling devices keeps the most cautious label, because a device action can reach a cloud and cannot always be undone. The tools also stop writing a deprecation warning to your log on 2026.10.

One thing does not work yet on a home we host. An AI app that signs in with a long-lived access token can reach Home Assistant's MCP server through your Vome address; we tried it. An app that signs in through Home Assistant's own login page cannot, because behind our proxy Home Assistant tells the app to sign in at the machine's internal address, which the app cannot reach. Fixing that means changing how our proxy and every hosted Home Assistant agree on the public address, so it is a planned change rather than a quick one. Until then, use a token, or Vome's own MCP connection, which reaches your home through us rather than through that login page.

ESPHome devices can place the call themselves

Until now Home Assistant dialled each ESPHome device, so it had to be able to reach it. For a home we host, that means a box in the house or a tunnel into it. With the new outgoing_connection option, the device dials Home Assistant instead. It needs ESPHome 2026.10, which was released on 21 October (see ESPHome 2026.10 and your Vome home):

api:
  encryption:
    key: !secret api_encryption_key
  outgoing_connection:
    host: 203.0.113.7   # an IP address; a hostname is refused
    port: 6054

For a hosted home this is the most interesting line in the release, and three details decide how far it goes:

• Home Assistant takes these calls on TCP port 6054, not on the web address you open in a browser, so something has to deliver each call to the right home. And the device is given an IP address, not a name, so whatever address it dials is fixed in its firmware.
• It only accepts devices it already knows. A device has to be added once while Home Assistant can reach it.
• Encryption is required. The device's key is the only proof of who is on either end. The device opens with a short hello naming itself, so that Home Assistant can pick the right key, and everything after that is encrypted.

That hello is the part we like. A router in the middle can see which device is calling and nothing it says after.

We are working on that router now. It is not a promise yet, and adding a device the first time, when Home Assistant cannot yet reach it, is still an open question. We will write it up when it works, or when it doesn't.

Before you upgrade: two changes that switch things off quietly

Both are reasonable, and both are easy to miss.

• A state condition that combines for: with an attribute:, a list of states, or a state taken from another entity now fails validation. Those combinations never honoured the duration; now they say so. An automation that fails validation does not load, so after the upgrade it is missing rather than wrong.
• mqtt.publish and mqtt.dump now need an administrator when a person starts them: a dashboard button, a script run by hand, a manual trigger. The same automation running on its own trigger is unaffected, but a family member's "open the garage" button that publishes to MQTT will now answer Unauthorized.

To check yourself, search your automations for for: inside a state condition that also has attribute: or more than one state, and look at any dashboard button a non-administrator uses that ends in an MQTT publish. The health check now looks for both, so a linked home is told before it upgrades.

Smaller things

• Usernames are lower case now, everywhere. A new login with a capital letter is refused; existing ones still work. Every login we create was already lower case, apart from one tool in our AI tooling that gives a user a password. It now lower-cases the name first, and says so.