A Home Assistant Alternative That Keeps ESP32 on the LAN

People who type "Home Assistant alternative" are usually tired of one arrangement. The dashboard is local, the ESP32 in the hallway is not. It still publishes to a broker, still depends on an add-on to be real, and still has a cloud account waiting as the easy way to reach the house from the porch. A MATA Home Computer is the peer those boards can join instead. The chip stays in the room. The house holds the key.

The household product that names this mesh is dldeploy.com. The mesh itself is mata.network. The seam already written for local ESP32 devices is DLDeploy on MATA Home. This note is for the Home Assistant search: what moves, which crate the board runs, and where the Remade realtime core sits under it.

What a Home Assistant search is really asking

Home Assistant taught a generation of households that the hub can live on a machine they own. That lesson stands. The part that frays is the path from the sensor to the hub. A camera, a presence board, or a switch on ESP32 is often a client of MQTT, of a vendor firmware, or of a companion cloud that exists so the phone can see the house when the laptop lid is shut. The search for a Home Assistant alternative is a search for that path to end inside the walls.

The broker in the middle

A broker is a convenient meeting place, and it is also a second landlord. Topics, accounts, and retention belong to whoever runs it. When the broker is a container on the same shelf as Home Assistant, the household is the landlord, and the work of keeping it is theirs. When the broker is a vendor hostname, the hallway is rented. rusty_esp_iroh is the Remade answer to that rented path: a peer-to-peer node on the microcontroller, QUIC with pure-Rust TLS, a signed capability, media, adoption, and signed updates. The public field note for the same idea is the pure Rust alternative for cloud IoT brokers.

The MATA Home Computer already speaks the contract that node answers. A device shows up for the owner because the board advertised itself on the local network, not because a cloud account was created first. That is the difference a Home Assistant user can feel without throwing away the wish for a house-shaped screen. The screen can come later. The peer has to be true first.

The home computer is the peer

MATA Home Computer is the household computer on mata.network. It discovers a device, catalogs it honestly, adopts it under an identity the household holds, and can read what that device is willing to share. Wider Disco Party hosting is still a Preview. The boards do not wait on the Preview. They join the home computer on the LAN. The field note for the mesh is MATA.NETWORK in the wild. The product surface for the sensors is dldeploy in the wild.

Identity for the person who adopts the board is the same family as Sign in with MATA: a key you hold, checked locally. The device side of that idea is adoption on the chip, measured, not a login form on a vendor site.

The ESP32 that the home computer already lists

rusty_esp_iroh has two tracks. The peer runs on std and ESP-IDF, because it needs an async runtime and TLS. A bare-metal no_std chip does not pretend to be that node. It reaches the mesh through a bridge. That split matters to anyone moving an ESP32 off a Home Assistant MQTT topic: the board that the home computer lists is a real endpoint, with its own ticket, its own identity, and a service record on the LAN.

Discovery, adoption, and a camera that arrived

On ESP-IDF the node advertises _mata-oem-sidecar._tcp.local. so the home computer's pair client can list it. The sidecar contract is the JSON the home computer already speaks: ping, status, the device ticket, the manifest. Measured on a Seeed XIAO ESP32-S3 Sense, over a Wi-Fi network the board hosted itself: a service query answered, the node up 3.2 seconds after boot, ten connections of ten with a 520 millisecond median for a full fresh handshake, and a camera stream of 721 packets in 60 seconds with none lost and none reordered. The board's rate and the subscriber's rate differed by 0.14 percent. Adoption refused a stranger presenting the owner's record, and refused a superseded record. The owner then read private telemetry.

Two open defects are written down with the numbers, which is how a Home Assistant user should judge a new hub. After adoption the device can still advertise itself as free to claim, because the broadcast record is composed once at start and not revisited. A media subscription costs 19,088 bytes of internal memory, so a tight memory map fails the stream outright. Those are limits of the current firmware, not a brochure. The ledger is in the rusty_esp_iroh repository. Frames that stay on the LAN are the job of rusty_esp_video.

The realtime core under the board

Home Assistant users meet FreeRTOS only as the thing inside the ESP32 firmware they flash. The Remade realtime core is rusty_rtos_kernel, part of the Kairos family that remakes FreeRTOS in Rust and runs on Cortex-M, RISC-V, and the Janus ESP32 family. The kernel matched 9 of 9 scheduler scenarios against the C kernel, 8,408,764 trace lines identical at 100,000 ticks. The port has tickless idle on ESP32-S3. Heaps, MQTT, JSON, and SNTP in that family are the same idea: a name a FreeRTOS developer already knows, with the hot path in Rust. The companion search page is the pure Rust alternative for FreeRTOS-Kernel C.

The mesh node the MATA Home Computer lists today is still the ESP-IDF track of rusty_esp_iroh. A peer needs the async runtime and TLS that track provides. The RTOS work is the core under the next firmware a maker solders, so the scheduler itself is not a C kernel the household cannot read. Both belong in the same move. The board speaks to the home computer. The scheduler under the board is being remade so that speech does not depend on the old kernel.

How a household moves, one room at a time

A Home Assistant alternative that asks you to recreate every automation on a Sunday is a different product from the one that asks you to move one hallway. Start with the board that already bothers you: the camera that uploads, the switch that dies when the broker restarts, the presence sensor whose only API is a cloud topic.

A hallway, not a config import

Put the ESP32 on rusty_esp_iroh, on the ESP-IDF track, with a manifest the node loads as data. Let it advertise on the LAN. Let the MATA Home Computer list it, refuse the wrong adoption, and accept the household's. Read the camera on the mesh before you redraw a dashboard. The map of that Edge work is Vision, Edge. The reason the primitives are remade, rather than wrapped, is The Importance of Remade With Rust.

dldeploy.com is where that hallway is named as a product: cameras, microphones, and presence that stay home, Connect on the mesh, Own on a key you hold. Flashing from the site and ready boards are called out as coming next. The crates are what a builder can use now.

What a careful move looks like

Keep Home Assistant for the rooms you have not moved. Do not look for a converter that turns a YAML automation into a MATA Home Computer record. There is not one. The test is smaller. One ESP32, one service record, one adoption, one stream that never opened a vendor account. When that hallway is boring, move the next room. The home computer is mata.network. The board is rusty_esp_iroh. The scheduler is rusty_rtos_kernel.