Wifi Mesh

[RubenKelevra]

I think it would be great if we could build Mesh Networks with our ESPHome devices, to not having to rely on your home wifi to reach all places in and around your home, where you may want to place ESPHome devices.

The idea is, to connect an ESP32 with ESPHome via Ethernet to your home network, and it will then communicate with all other ESPHome devices in your house on a dedicated Wifi channel.

This would

• free up your home router from maintaining and managing connections to all ESPHome devices
• free up your home's router bandwidth, since it doesn't have to communicate with far away ESPHome devices with low bandwidth connections
• allow us to reach places where your home wifi may be spotty or not reaching, as each ESPHome device would act as intelligent relay.
• avoid you from using Wifi Repeaters to reach the places where your regular wifi cannot reach, just to connect ESPHome devices.

While this was surely requested before in this project somewhere, I like to use this opportunity of these new discussions here to share the progress I've made:

I've started like 3 months ago to work on this, and I'm 80-90% complete with the implementation. It's using Espressif's ESP-MESH-LITE framework and integrates it neatly in ESPHome, with a lot of optimizations from my experience to run large scale mesh networks on top of that.

Feel free to ask any questions, or point out any things I should consider for the implementation. Thanks!

---

Previous Feature requests:

#1108
#2871

[msmarks]

Hi, thanks a lot for sharing your progress! I’m also working on a project based on ESP-MESH-LITE and considering how ESPHome might support mesh networking.

One challenge I’ve found is that, under ESP-MESH-LITE, each device has its own private address, and only the mesh root connects to the WiFi router and gets an IP address on the LAN. The other mesh nodes are “hidden” behind the root, so from the outside network, only the root is visible.

However, ESPHome typically expects each device to be reachable directly via hostname or IP address—for example, for OTA updates, API server, or web server access. With mesh, it seems difficult for ESPHome to support this, since devices randomly appear on the LAN and the rest are only accessible inside the mesh network.

I’m curious—how did you solve the problem of addressing and accessing ESPHome devices inside the mesh from the LAN? For example, how do you handle API/Web/OTA requests for devices that are not the root? Do you use some kind of proxy, forwarding, or service discovery mechanism? Would love to hear more about your approach!

Thanks!

[RubenKelevra]

One challenge I’ve found is that, under ESP-MESH-LITE, each device has its own private address, and only the mesh root connects to the WiFi router and gets an IP address on the LAN. The other mesh nodes are “hidden” behind the root, so from the outside network, only the root is visible.

However, ESPHome typically expects each device to be reachable directly via hostname or IP address—for example, for OTA updates, API server, or web server access. With mesh, it seems difficult for ESPHome to support this, since devices randomly appear on the LAN and the rest are only accessible inside the mesh network.

I’m curious—how did you solve the problem of addressing and accessing ESPHome devices inside the mesh from the LAN? For example, how do you handle API/Web/OTA requests for devices that are not the root? Do you use some kind of proxy, forwarding, or service discovery mechanism? Would love to hear more about your approach!

Well, this deserves a long answer.

While it's true that's the case for ESP-MESH (the old implementation), you can optional bridge traffic in ESP-MESH-LITE.

Let's establish some terminology:

• Private LAN is the home network
• Private Wifi is the regular home Wifi network which is bridged to the Private LAN
• Mesh LAN is the ESP-MESH-LITE network
• Root Node is the single note in the tree network, which ESP-MESH(-LITE) call "root"

In ESP-MESH-LITE you can install a bridge on the Root Node between the Private LAN and the Mesh LAN. By doing this the nodes in the Mesh-LAN can simply fetch IPs from the DHCP. It's just not done by default.

But doing this comes with downsides, too.

Bridging challenges

All broadcast/multicast traffic is copied to the mesh

The most obvious is that you also bridge all broadcast and multicast traffic you get from the Private LAN into the Mesh LAN.

That's why I implemented a package filter, which will only allow DHCP/ARP/mDNS (and NDP/DHCPv6 etc. if IPv6 support eventually becomes a thing, if IPv6 is enabled for the Mesh LAN).

This way you only forward the necessary packages to the Mesh LAN.

All ARP traffic is copied to the mesh

Now the issue becomes smaller, but you end up with all ARP traffic for any computer searching for a neighbor, regardless if it's in the Mesh LAN or not.

However, this can be also solved by another filter: The user specifies an IP range for the Mesh Nodes, like (start=10.10.5.2 end=10.10.5.200) which the Mesh nodes will be addressed with, and everything outside can safely be dropped (in the direction towards the Mesh LAN).

Now you end up with just the ARPs for the IP range you nodes actually might have.

Further optimizations

mDNS/ARP-Caching

Based on the fact that we know, that we run ESPHome, we can now predict some limitations, which allows us to make even more optimizations:

• The mDNS name won't change without a reboot of the node
• The IPv4 won't change without a reboot of the node (if it's static)

So we snoop if a node appears or disappears from ESP-MESH-LITE and analyze mDNS and ARP returns from the Mesh LAN.

By doing this a node has to answer the ARP/mDNS query once, and all further queries can be answered from a cache, which will be invalidated by the node leaving the mesh aka the node is rebooting. I've also added a failsafe on reboot, so all ESPHome nodes will send an unsolicited ARP with new data on their reboot. So if the regular cache invalidation fails, this will update the data nevertheless, if it's changed.

This allows us to massively reduce the broadcast inside the mesh network, as we only need to broadcast 2 packages per boot cycle per node.

Broadcast/Multicast to Unicast

Another very interesting optimizations, which is implemented in the Linux kernel, is, that you can send Broad and Multicasts on Wi-Fi level as Unicast.

So instead of addressing a Multicast/Broadcast MAC address, you copy the package and send it once out per Unicast neighbor.

The benefit here might not be obvious on first glance, so a short explanation, why this is basicly always beneficial:

On Wifi devices try to not listen all the time for saving energy, especially not for broadcast data. That's why there's a notification in the beacon (every couple of beacons) if there's broadcast/multicast data for a wifi node to receive.

So a single broadcast is not a single broadcast. Instead, it's actually send multiple times to multiple nodes, after they requested the data still in the queue on the Wifi hotspot, after they read the DTIM (=Delivery Traffic Indication Message).

I'm not sure how Espressif implemented this, as the Wifi driver (and ESP-MESH-LITE for that matter) is closed source. But since that's pretty much how Wifi in general works, it's extremely likely that it applies to the Mesh as well (will do some sniffing to verify here).

So the idea is to grab the list of neighbors if there's a broadcast frame and then address each neighbor via it's Wi-Fi MAC address with a copy of the frame.

That's a bit of effort, but the benefit is, that we might send data with up to 72 MBit/s instead of just 1 MBit/s which what all Broadcast/Multicast is use. And we can make use of 802.11n's frame aggregation (A‑MSDU / A‑MPDU) this way, as all data of an aggregated frame needs to be send at the same data rate.

Summary

With this optimizations it should be possible to use bridging without (much) downsides on the performance end of the mesh.

Hope this helps clear things up!

[msmarks]

Wow, you did a lot of low-level work and it looks very technical. I'm impressed. Thank you so much for your detailed explanation and insights! I’ve learned a lot from your posts.

[RubenKelevra]

Hey @msmarks thanks!

I did actually go a bit further still, but I'm not sure if that's possible to be shipped, due to memory concerns.

I thought you may enjoy this as well. The main issue in a mesh is, that:

Say you want to send data from A to D and you got a chain like A -> B -> C -> D.

The worst thing you can now do is send all data you got as fast as possible from A to B. Because this will pile up on B, while B cannot forward them to C, because you send more data on A.

This is especially true of you think of bursty data transmissions or data transmissions which are timed, say if the root node gets data from the LAN for multiple peers at exactly the same time.

So this behavior should be avoided, as it leads to either conflicts in the air, by collisions, drops in the queue, as one nodes gets more data than it can forward in the same timeframe, or jitter, because some data is stored very long before it can be forwarded to the next node.

So the solution here is to introduce pacing.

sch_cake, from the Linux kernel, does something like this already, so I've basically adapted a very lightweight version of sch_cake for the mesh.

To understand how much data we can send, we look at the wifi statistics: ESP-IDF allows us to read global TX statistics, which gives us collisions, resends, timeouts etc. but also global package count.

This let us estimate how "full" the channel currently is. So I weight the different metrics to come up with a percentage value, how much we think is still "free", say usage 30% and 70% is free would be a common value in noisy environments.

So what do we now want to do with that info?

Well, we allow on each Mesh Node only a certain amount of airtime to be used. To do this we not only need to know how much of the air is free, but also need to know how fast a certain package will be likely be transmitted to the next mesh node.

Here we run into a limitation of the ESP-MESH-LITE framework, and since it's closed source I've created a feature request. But I'm not even sure I was correctly understood...

What I need is a way to ask ESP-MESH-LITE where a certain MAC will be routed to. So Ethernet destination MAC in and I get the next hop's MAC out.

The reason we need this is, that we can use Per-Package Metrics for RX called wifi_pkt_rx_ctrl_t to grab the speed to a neighbor (granted that's RX, but there's no way to get the TX speed). I've asked for a simpler method to simply ask the Wifi driver for the TX-speed as well, but got no response yet.

Anyway, so we currently just use the average RX of all neighbors, except if it's routed towards outside the mesh, in this case we can assume that it's going towards the parent node (towards the root node).

My sch_cake adaption will keep track of the communications happening in both directions, in time, not amount of data. So we can measure how much airtime each source-destination-mac communication pair is using.

By this communication pairs with low amount of airtime, will be prioritized and communication pairs which do use up much of the airtime, will be throttled.

Benefits of this approach is head-drop of each individual queue, so the package which would be send next, will be dropped, allowing TCP to recognize drop faster, and keeping a somewhat strict latency target, so we don't go up to seconds of delay, if there's a high amount of traffic in the mesh network.

The frames are then send out with pacing, meaning by knowing the (rough) transmissions speeds, we estimate for each package how much airtime it will use, and then pause a given amount of time after that, before sending the next frame from the queue.

This allows us to keep the airtime usage per node in total under the configured limit, which is the fraction of the "free airtime" we guesstimate, as explained, from time to time.

And with the sch_cake adaption we keep latency low, as we buffer only as much as we can possibly send out within the latency target, while also prioritizing communication pairs which do not use up much airtime. Meaning pressing a switch will be prioritized vs a camera feed, a voice communication or a firmware update.

---

That's what I'm currently be working on: To fit everything as tightly into the memory as possible. Currently working on the ARP/NDP/mDNS caching to reduce it's memory footprint. And next is the sch_cake implementation, to see if I can save some memory there as well.

I'm also reworking parts of the code to avoiding locks as much as possible, and using atomic state machines to reduce the CPU load for concurrent access on things like the cache, and the queue.

[msmarks]

I started with a technical curiosity about how ESPHome could access mesh nodes behind the root, but your answers went far beyond that. Your work demonstrates a deep understanding of both network theory and practical engineering, with thoughtful optimizations for performance and resource management. It’s truly inspiring to see such professional and open sharing—thank you for all the insights and ideas!

I’m currently working on a small mesh network myself. Back then, I worked around the problem by using an 6.96 USD MT7628N module running OpenWRT with an MQTT server as the gateway. This way, I avoided the need for external devices to actively access the mesh nodes behind the gateway— all data operations are handled through the MQTT server on the gateway. It’s not as technically sophisticated as your approach, but it solved my problem effectively.

[RubenKelevra]

Thanks, just trying to make this work as good as possible, even in large deployments.

You're only using one root node, right?

Because my approach would throw away the default assumption that you connect to an "uplink" via Wifi. Because it makes no sense in an ESPHome deployment. You want your mesh away from your home network, not forced to be on the same channel.

So instead in my component it's required that a root node got an Ethernet cable. The default check is, to see if the Ethernet cable is up.

If the user supplied an IP for Home Assistant, this IP will be pinged to check connectivity as well.

So if these checks are working, I switch the node to be root.

But this also means, you can deploy more than one root node.

ESP-MESH-LITE documentation is a bit hazy on that, but it sounds like this should work fine, and each mesh node will just kinda randomly connect to establish the best connection it can find.

So this should provide failover, and allow also to connect different nodes in different buildings to Ethernet, while using the same mesh config on all of them, so you get roaming inside the mesh to the semi-best-path to the next Ethernet connection.

If you got any more details how ESP-MESH-LITE will behave with more than one root node, please do share. I'm curious.

---

Ah and I forgot, there's an Wifi backup.

So you would configure a mesh: and a wifi:. On startup the node tries to find a mesh, and connect to it. If this fails it will fallback to wifi and connect to your home wifi.

So if the root in the mesh is lost, we just switch to Wifi and it will from time to time search for the mesh.

And since all members will do this, the mesh would be gone, until the root node gets it's connection back, and starts up it's mesh network based on that.

Since the assumption is, that both are on the same L2 network, we just oneshot the DHCP client and grab the IP and lease time off of it. If the lease runs out, we just oneshot the DHCP client again.

This allows us to configure the IP static instead of dynamic on the interface, and use the same IP on the Mesh and in Wifi backup mode. This way the switch is more seamless and in theory even connections should start to be rerouted as soon as connectivity is established back.

[persuader72]

Hi maybe someone may be interested, but I'm working too to an esphome mesh network implementation, maybe is not mature as esp-mesh-lite but is opensource. You can find this at Firmware, HUB. Or this for the full esphome project.

As now The project is usable but require some export user because is quite young, I'm working with some other devs on discords to make it able to integrate in esphome in the future.

Let me knew if you have some questions i will glad to answer it

[persuader72]

Hi about the requirements:

First of all: Sorry but the network highly centralized. I designed it to be controlled from the CPU attached to the border node (coordinator) this CPU maintain the connection graph of all network.

As for robustness you have to consider it an alpha quality software, it's possible to use it (I'm using at my home from some time now) but there a lot of thing that can change and bugs that can be found.

About overhead: is very low in size and number packets that are transmitted. There are no beacons. I'm quite paranoid about EM pollution.

The node address are 3 bytes long

There are five protocol supported:
broadcast (to all neighbors)
unicast (to a single neighbors with no hops)
multipath (to a single neighbors with hops)
politeBroadcast (to all network)
connectedPath: is used from HA to connect to the API server in esphome and is quite similar to a tcp socket (the hops are declared in the handshake phase)
discovery: each node can discover their neighbors but as said only the coordinator can handle the network graph.

The whole system is controlled by an HUB software that run on the CPU connected to the border node (coordinator). It do the automatic discvery and traslate the data exchange between HA and the single node.

Last but not least is opensource so maybe can evolve in something more complex in the future.

[RubenKelevra]

Hey Stefano,

thanks for the overview. The centralized architecture doesn't align really with my goals, so sadly that's not compatible here.

My goal is, that you can connect multiple nodes via ethernet to the home network, as many people might have an ethernet network at home already. And each ethernet connected node "offers" to be a gateway to the mesh nodes. The mesh nodes then select one of these.

I'm pretty much finished with my protocol draft now for my implementation. Sadly some of my goals are not possible due to ESP-IDF limitations, like MTU 1500 limit on wifi, while the standard allows more and no 4 way addresses.

But in my design there are no packages exchanged at all, instead everything is detected passively by observing the traffic flow through the network itself, including alternative routes.

I think I got a single dedicated package which is just used in the rare case that a node switches the gateway. :)

I think I might be able to squeeze in some time next week to start implementing that.

Do you do L2 or L3 routing in your mesh implementation?

[persuader72]

Understood... I'm interested about your solution let me know when you will publish something to test.

Anyway I'm using the L2 layer. I'm using only frames of type DATA a this level. Above this there is another layer that implement the routing protocol. There is not a single routing protocol but you can select on different routing protocol for now I'have implemented the ones I listed before. They are all centralized protocols maybe in the future I can add some auto forming routing protocol.

[RubenKelevra]

Understood... I'm interested about your solution let me know when you will publish something to test.

Yeah, it might take a month or two, until I got something to test, but testing it will be highly appreciated, before the PR to merge it gets out of the "draft" state then!

Anyway I'm using the L2 layer. I'm using only frames of type DATA a this level. Above this there is another layer that implement the routing protocol. There is not a single routing protocol but you can select on different routing protocol for now I'have implemented the ones I listed before. They are all centralized protocols maybe in the future I can add some auto forming routing protocol.

Interesting! How did you address the overhead per package? Meaning the reduced MTU per package for the encapsulated packages you're forwarding?

I'm currently have a solution for that, but I'm not sure if all IP stacks support that.

[nschimme]

Something to consider is portability to different architectures. It would be very useful if all strategies (i.e. centralized, de-centralized, various protocols, etc) work across all the supported ESPHome architectures. This might not be possible given we've already seen some ESP-IDF limitations, but ideally the mesh can adapt and accept many nodes. Such a solution would give us the best chance of becoming a new standard and getting widespread adoption with the smart home community.

[rosbeef]

Hey! i like both of your work,

The idea of @RubenKelevra to connect an Ethernet cable to select the border node or let it self working if no border found is soo good.
I search this for "decades" ( and i'm not so good to develop that).

And i like the @persuader72 paranoia about EM ( EM is powerloss not so brain eraser for me, but! ) and Opensource.
👀 looking for future improvement ant esphome integration.

[persuader72]

Thanks for the support, As now the network can be tested using this external_component repository. I'm trying to write some documentation to make less hard the bootstrap of the network.