Home Assistant just gave AI a KNX toolbox. Here is who should get the keys.

Home Assistant 2026.10 landed on 7 October, and buried in the release notes is a section called "KNX AI tools". Most of the coverage this week is about the map redesign and the one-click MCP server. The KNX part is the bit that matters to anyone who has a KNX bus in the wall.

In short: the KNX integration now ships a set of tools that an AI agent can use. They can read your ETS project, look through your bus history, decode values, and (this is the part to slow down on) write to group addresses.

What is actually in the box

The KNX integration docs describe a new LLM API called KNX, with 21 tools in four groups.

The first group is telegram history. It can query recorded telegrams, pull the last values, and count what has been going across the bus. It needs telegram history switched on, with a retention period you set.

The second group reads your ETS project. List group addresses, describe one, list devices, list communication objects, list functions, get the topology. You upload the project file in the KNX panel for these to work.

The third group is data point types. Encode a value, decode a payload, describe a DPT. No project and no bus connection needed. If you have ever stared at a raw hex payload from a telegram and tried to work out whether it was a 1-byte scaling or a 2-byte float, you will see why this one is handy.

The fourth group is live bus access. Check the connection, read a group value, send a read request, and send a write. The docs describe the write tool as sending a telegram to your installation, the same as the group monitor does.

I have not found anything in the docs that labels the other live tools as strictly read-only, so I would not assume it.

The good part

I want to be fair here, because this is useful.

Diagnosing a KNX installation is mostly detective work. Someone says "the lights in the passage came on at 3am". You open the group monitor, scroll, squint, and try to match a group address to a room from a naming convention someone invented in 2019. An agent that can read the ETS project, find the telegram history for that address, and tell you which device sent it is a real time saver. That is the kind of job I would happily hand to an intern.

Decoding values is the same story. Nobody enjoys it, and a tool that does it correctly is better than me doing it at the end of a long day.

The part that needs a decision

Here is what the docs say about access, and it is worth reading twice.

The KNX API is off by default. You enable it by adding KNX to the "Control Home Assistant" setting on a conversation agent, and only administrators can do that. The docs warn that you should only enable it on agents you are willing to give write access to your installation.

Then the line that caught my attention: once KNX is selected on an agent, everyone who can talk to that agent can use every KNX tool, write tools included. That includes voice satellites, where the request is not tied to a particular user.

Read that as a site owner. If the KNX API sits on the same agent that answers the kitchen speaker, then anyone who can speak near the kitchen speaker is, in principle, one well-phrased sentence away from a group write. Guests, kids, a cleaner, a podcast playing too loud.

For MCP clients like Claude Desktop or Cursor, there is a dedicated KNX endpoint, and the docs say it needs an administrator token. The base MCP endpoint serves whichever API you selected and is available to non-administrators. So where you point your client matters.

One more thing I could not confirm from the docs I read: whether the usual Home Assistant "exposed entities" list limits these tools. These tools work on group addresses, not on entities, so I would not assume the entity exposure settings act as a safety net. If you need a firm answer for a specific installation, check the KNX integration docs and test it on a non-production setup first.

How I would set it up

This is my opinion, not a rule from the docs.

Keep a separate agent for KNX tools. Not the one on your voice satellites. Not the one the family chats to.

Start with the diagnostic side. Upload the ETS project, turn on telegram history, and use the tools to answer questions about the bus. That alone earns its keep.

Treat the write tool like a master key. A group write can switch a light, but it can also move a blind, change a setpoint or drop a lock output, depending on how the project is built. Anything on the safety side of the installation (heating cut-outs, wind and rain protection for blinds, access) should not be reachable by an agent that you have not tested properly.

And think about the project file itself. Uploading your ETS project to Home Assistant means the full map of the building's group addresses sits in that system. That is a normal thing to do for the integration, but it is one more reason to keep admin access tight and remote access sensible.

Where this leaves a KNX owner

KNX has always been a deliberately boring, deterministic bus. A telegram goes out, an actuator acts, and everyone can read the project to see why. Adding an AI layer on top does not change that bus, but it does change who and what can speak on it.

That is not a reason to avoid the new tools. It is a reason to decide the limits before switching them on, not after.

If you have a KNX installation and want to talk through how to plug Home Assistant in safely, or whether you should at all, that is a conversation I am happy to have. Just a conversation about what the project needs: wayne@knxlogic.co.za, 082 564 3982, or www.knxlogic.co.za.

Sources: Home Assistant 2026.10 release notes (7 October 2026); Home Assistant KNX integration documentation, KNX LLM API section; Home Assistant MCP Server integration documentation (home-assistant.io).