Esphome access

[bogdanr]

It would be nice if it had access to the esphome binary somehow so it can try to compile the configs, flash devices and read the logs.

[ESJavadex]

Hi @bogdanr, thanks for the feature request!

This is an interesting idea. There are a couple of approaches we could take:

1. Volume mapping — Add /addon_configs to the add-on's volume mounts so Claude can read/write ESPHome YAML configs directly
2. ESPHome binary access — This is trickier since ESPHome runs in its own container. We'd need to either install the ESPHome CLI inside Claude Terminal (heavy dependency) or communicate with the ESPHome add-on via its API

For now, approach (1) is the most practical — it would let Claude read and edit your ESPHome YAML configurations. Compiling and flashing would still need to happen through the ESPHome dashboard, but Claude could help write and debug configs.

We're adding addon_configs:rw mapping in an upcoming release which should cover the config editing use case. Would that be a good start for your workflow?

[bogdanr]

In my case, volume mapping is not necessary. Claude Code already has access to all the esphome file. The only thing needed for a better experience would be to allow it to build the files and read the logs from the devices after they boot.

And also, it keeps disconnecting and that is a pain when doing more complex things.

[ESJavadex]

@bogdanr yesterday I launched a new release, can you update the plugin to see if it is better now?

About the ESP Home thing, I will work on that because would be useful for more people I guess!

[bogdanr]

I did see the update and did it this morning. It still disconnects. My workflow is: a new browser only runs this, so the tab doesn't go to sleep. But after some inactivity, it still disconnects when I am in a different browser.

Thank you for the esphome thing.

[ESJavadex]

Hey @bogdanr, update on both topics:

Disconnections

We're actively looking into this. There's a discussion in #12 about integrating tmux for session persistence — the idea is that even if the browser disconnects, your Claude session keeps running in the background and you just reattach when you come back. We're evaluating the best approach to integrate it.

ESPHome access

Good news — we've done some research and it turns out the ESPHome add-on exposes a dashboard API that supports compiling, validating, reading logs, and even OTA flashing. So instead of installing the full ESPHome CLI (which would massively bloat the container), we can talk directly to your existing ESPHome add-on via its API.

The main operations (compile, validate, logs) use WebSocket, so it needs a bit of work to wrap it nicely, but it's definitely feasible. The plan would be to provide a helper script or command that Claude Code can use from the terminal to interact with ESPHome — something like triggering a compile, streaming device logs, or validating a config, all without leaving the Claude terminal.

There's also an authentication piece to figure out for the cross-addon communication, but nothing blocking.

This will take a bit more work to get right, so it's on the roadmap for a future release. We'll keep this issue open to track progress.

Thanks for your patience, and thanks for pushing for this — it's going to be a great addition!

[ESJavadex]

Estado (triaje, jul 2026)

Desglosando las tres partes de este hilo:

1. Edición de configs ESPHome — ✅ ya funciona. Como confirmaste ("Claude Code already has access to all the esphome files"), los YAML de ESPHome viven en /config/esphome/ y el add-on ya los ve vía el mapping existente config:rw. No hace falta mapping adicional para leer/editar/debuggear configs.
2. Desconexiones — ✅ abordado. Desde 2.0.13 el add-on levanta una sesión tmux persistente y ttyd reengancha cada pestaña (con --ping-interval 30 y reconnect=5), así que la sesión de Claude sobrevive a que el navegador/pestaña se duerma o a un reinicio de Core. Si sigues viendo cortes tras actualizar, cuéntame y lo miramos aparte.
3. Compilar/validar + logs de dispositivos — ⏳ pendiente. Esto es lo único que queda de verdad y requiere hablar con la API del dashboard de ESPHome (compile/validate/logs van por WebSocket), no con la CLI (metería una dependencia enorme en el contenedor). Es trabajo de diseño no trivial (auth cross-addon + wrapper de WebSocket), así que se queda en el roadmap.

Dejo el issue abierto acotado al punto 3. Gracias @bogdanr por la paciencia.