ESP8266 Mesh Experiment

MeshIn case anyone else (like me) has been sitting on the shelf over this one – and would like to have a go at an ESP8266 mesh… we’ve been having a play.

Regular readers may recall I wasted the better part of a year with those AWFUL NRG24L01 boards trying to make a mesh and ultimately getting no-where – indeed I think it is the mere existence of that board that drove me to the ESP8266.

Fast forward to December 2017 - take 3 ESP8266 modules, run the same code on each of the three, attach a LED+resistor to GPIO12… take ESP8266 modules for a walk. One is in the house, one in the office out of range, the other in the middle sitting on my car in the freezing cold.   When all 3 are talking to each other you’ll see 3 flashes in quick succession…

That’s it – no setup, no nothing.. You can watch the output of one of them on the serial port and see how many are talking (if your eyes are fast enough) on a LED.

So – here’s where we started….

That relies on 2 other libraries – install before compiling.

From this one you want the SimpleList library only

Once added to your Arduino Development environment (however you do that – I use Arduino 1.8.5 – and on other occasions Atmel Studio – on this occasion – the simple Arduino IDE on Windows 10 64 bit) – grab the example StartHere…. that’s it – you should be able to figure out once it is all working how to go from there.

To test this as suggested above, we left one unit in my office (shielded from the house by a small stone building) and put one unit in the house.  The one in the house saw nothing.  We added one on a battery in between, sitting on my car, in the frost -  so it could see both the house and the office by line of site.  Bingo, the house unit saw all three – they ALL saw each other.  That stayed up for a while then one of the units dropped out. A reboot fixed that but then It dropped out again – then reconnected.

At this point I was ready to throw in the towel – ANOTHER failed mesh. So to clarify – this is a mesh – it has NOTHING to do with your house/office WIFI and does not  need access to an access point or router. No setup is needed. Units can broadcast to everyone in the mesh or as you’ll see at some point when we’ve cracked it – can talk to individual devices which talk via their MAC numbers which means you don’t have to come up with names.

As you can see here “piggy in the middle” was talking to both of the others.


Well, that’s the idea but of course it didn’t work reliably.

After a while we became a little despondent that this was continually showing signs of being unreliable – I sent a message into the ISSUES section for the repository but noted that someone had beaten me to it 3 weeks ago and not heard anything back. Now remember this code had not been altered in a year.

As you do, I got side-tracked – and by sheer chance I came across this variation..

Same original codebase but modified only recently.  We hooked that up to all three boards and the only immediate difference was the LED being + based as against ground based.  With three units connected using this new code, the flashes were a tad too close together so I put my new OWON scope on slow scan to watch them. To date (hours later) with one unit in the house, one sitting freezing to death on my car and the third in my office here, we’ve not missed a beat.

Debugging on this one is WAY more sophisticated and shows memory use with garbage collection.


I’m keeping an eye on the RAM – which started at 32720 free and now hovers between 33904 and 31766… i.e. RAM usage seems just fine.

Lots of stuff in the image above but no actual errors that I can see. I do see three separate node numbers (automatic, from MAC address). In the code you can select how much if any debugging you see. This all looks a little more complex than the original code but most of it I suspect we can just assume works and not worry about it.

So here’s the plan

Once we’re happy that this is working – the plan would be to give each one a meaningful name… to then take ONE of these ESP8266s and have it talk to a normal ESP8266 via serial or similar along the lines of packages like  {topic:”who to”, payload:”the payload”}

i.e. An ESP8266 would use normal software to talk to MQTT and relay that message to this MESH. The unit doing the connection would then BROADCAST to all (easiest, I know you could do it another way) where the topic is the “name” of the unit. Each would compare, do what it is supposed to do with the payload and send a message back up – ie broadcast…. oh… {topic:”who from/reply”,payload:” reply payload”} which would be picked up by the unit connected to the external network – and sent back to go back to MQTT.

Ok this would be no good for super high speed connectivity but I’m guessing would be ok for turning things on and off.

This then gets around an issue where perhaps WIFI is not practical except for one unit allowed through a firewall or one unit in range – the rest of the MESH need be no-where near normal WIFI access.

Anyway, that’s where we are up to now, as I speak the scope is continually reporting, despite the poor piggy-in-the-middle unit+battery outside freezing to death at –6c, groups of 3 connections constantly – and RAM is just fine.

THIS is what makes things fun…. experimenting!


31 thoughts on “ESP8266 Mesh Experiment

  1. We attempted a similar scenario several months back, where we wanted to trial electronic colour ticketing for a deli. We didnt use the same library as used here, one of my developers used the afore mentioned easy mesh, and tweaked it.

    The results at first looked promising, but as we added more devices, it all just melted down. So in an attempt to rectify, the code was changed, and each device was reflashed. (we no longer had OTA). Then the reaslisation kicked in. Each device only could cope with 4 concurrent connections, after which meltdown.
    So using the esp as a relay worked fine, but as a participant in a mesh, well we failed dismally. So I pulled out an old Cisco 1242 AP, which allows up to 128 connections, and went back to plan A. And now we have OTA back.
    I hope you have more luck with your setup, but the loss of OTA, with lots of devices, made the whole idea unusable for me.

    1. Indeed there is a limitation of the number of concurrent connection in the ESP library. Now you can not do more than 5 connection. But using the FreeRTOS and a modified lwIP library the number of concurrent connection can be increase up to 20 ( a pretty safe value). I did that for my MQTT broker that is running on ESP8266. I assume that with a some effort a new mesh library can be written to accommodate more node. In this way a full mesh of 20 nodes can be achieved.

      The actual implementation is more like a star topology to me and not a full mesh.

      This limited functionality is ok if you intend to use the mesh in a big open space to control the lights. I've seen it in the EspressIf office and it worked fine to change the color of some lights, to turn them on and off all together.

      1. I totally agree that there are options to increase the number of nodes, using ESP-Now or some other libraries. but a mesh may/will associate with heaps of other nodes, unless you have the space to seperate them, which then implies that your talking about hundreds of metres seperation in the open air. And there may well be use cases for such topologies, but think about this. If you create an isolated mesh with 10's or hundreds of nodes, how do you upgrade the firmware, and more importantly they still use WIFI, so the congestion will render other wifi devices useless, or at least create other as yet unkown issues. This all looks good on paper, but in the real worl and at scale, it's just an academic excersise.

    2. You could have used Web-server based approach, where each esp broadcast its own ID (MAC id can also be Tried if need) and relevant data. All other node listens to it and if respective data is detected then the particular node will respond based on NEED. 🙂

  2. I love the idea of mesh networks but to get round the issue of range I found it easier and more flexible to use a pair of LORA enabled ESP32 modules,searchweb201602_1_10152_5130011_10065_10151_10344_10068_10130_10345_10324_10342_10547_10325_10343_51102_10340_10341_10548_10609_5000011_10192_10541_10190_10084_10083_10307_10301_10303_5080011_10539_10312_10059_10313_10314_10184_10534_100031_10604_10603_10103_10605_10594_10596_5060011_10142_10107,searchweb201603_25,ppcSwitch_5&algo_expid=1e3d62a4-cf6b-4c50-bfd0-63284753a01d-1&algo_pvid=1e3d62a4-cf6b-4c50-bfd0-63284753a01d&rmStoreLevelAB=0 (868mhz also available) which including display, purpose built case and 1000mah battery I picked up for approx £25 for a pair. I use one at the end of the garden to interrogate the local miflora plant sensors using the inbuilt BLE and then squirt the results back every 30 minutes before going to sleep after confirming data is received intact. The inhouse ESP32 then dumps results onto MQTT using wi-fi. When testing using the supplied cheap whip aerials (one on my desk the other on the passenger seat of the car) I was getting reliable transmission at well over 500m with dozens of brick buildings between. I reckon with a decent aerial in a good location and possibly using a wider spreading factor I could easily get 1-2km - although god knows why I might want to. The data rate is not up to heavy traffic but at SF7 I am getting a reliable baud rate of 5.5K which allows me to send all the sensor data from 5 miflora units within a second, so when using the ESP32 deep sleep for approx 30 minutes - the battery life looks like it will be several months at least.

  3. Well, I have to say I did find it a lot of fun researching this and setting it up only to find it on the one hand reliable but on the other hand - this low limit is annoying - and more's the point, if you had 10 units more or less within range of each other, would it stick with 5 or eventually talk to the others... in other words if one unit sent a message to another, is it guaranteed to get through eventually - because if not, with all due respect to the designer of the mesh, it is useless. I wonder if anyone knows the answer to that?

  4. Here's another thought while we're on.... if, as in the case that started all of this, WIFI is not available - possibly corporate restriction or for one reason you just don't have WIFI, would something like this reasonably priced unit not do the job?

    Does anyone have experience of this unit - can it create a network of it's own with DHCP without being attached to anything? If so a bunch of ESPs could be on it, possibly with an ESP8266 running MQTT - or probably more practically a PI Zero or little Nano running the MQTT broker??

    Experience of this, anyone?

    1. If you have a PI already connected by a network cable, use that as the access point.
      Obviously if you had to buy one, the device you linked above would be cheaper, but a PI, running the script, is capable of also running as an access point with the option of easily allowing (or denying) the ESPs access to the network.

      1. Assuming you DON'T have any network at all, can a Pi3 be both a client to the network - and a wireless router for the ESPs (but it would have to be an add-on that didn't mean a different operating system just to be a router)

        1. a wifi adapter can work in a single mode, so station or ap, not both... you can of course add an other wifi dongle... it's easy to setup, i used this this summer so the esp i was testing could reach node-red on my pi without an access point (the 3G AP as a limit of 5 devices, too low...):

          i think there's an ad hoc setup in the DietPi software selection, too:

          1. Hi Dr Fragle and Mr Shark. I hope you dont mind me asking this, but my 6 y/o grandson who is a budding electronics maker / geek is terrified by your avatar to the point that he has been worried if "that nasty man might be on the internet this time" . We always get on and look at projects etc when he visits. Any chance you could tone it down a bit? I'd hate something like this to put him off.

    2. From what I can deduce from the description and the information on the page, the unit is simply a WiFi Router, or AP, or Client depending on the switch position. As a Router or AP, you still need to have it hard wired (via the RJ45 port). And as a client, you would connect it to your PC via the same RJ45 port. In essence it is a nice versatile unit for travelers as stated in the description.

    3. I think that an old router would do a good job it would not need Wlan use the router for your system and connect the router to your main internet router for any external communication, so if internet was not available your system would be safe with its own sub network.

  5. I spent a lot of time working (testing) with Coopdis but found that it was too unstable. I spent a little time looking at Painless-mesh. It was more reliable than easyMesh but it didn't suit my needs. There have been some improvements since then but I have not had time to look at it again.

    What I would like to evaluate (when I have time) is this. It is a very interesting project.

      1. There are two limitations in the ESP8266 SDK:

        - the max. number of STAs connected to an ESP8266 SoftAP. It is 5 by default, but can be increased to 8 by calling "wifi_softap_get_config()" with apConfig.max_connection = 8 (more doesn't work). This is a limit imposed by the WiFi driver, where the code is not avaliable. I.e. up to now a hard limit.

        - the max . number of concurrent TCP connections (default 5). Can be increased by calling "espconn_tcp_set_max_con(n)" with n, the max. number of concurrent TCP connections, less or equal to 15. This is a limit in the default lwIP implementation, but it can be increased even further by recompiling lwIP. However, as TCP connections are somewhat memory consuming the absolute limit is not too much higer.

        Now it is the question, which mechanisms are used to implement a mesh:

        - PainlessMesh is implemented above OSI level 4 and uses both: AP-STA connections and TCP links. Thus, I expect that the max. degree of this topologie can be increased to 8 using the above mentioned API calls.

        - ESPNow from Espressif uses none of these and is implemented on OSI level 2, i.e. it sends plain MAC frames and receives anything, no AP-STA connections, probably it has its own internal routing. No IP connectivity here, just plain datagrams. But: there is no explicit limitation on the number of connections between nodes.

        - My "AutoMesh" ( ) uses a different approach: it is implemented above layer 3, the network layer, i.e. it uses IP routing. As in Painless Mesh there are AP-STA connections between neighbours (i.e. a limit on the degree of 8) and it builds up a routing tree. It then forwards IP packets using standard routing and NAT. I.e. it supports TCP and e.g. MQTT conections over several hops. As it uses NAT, connections always have to be set up towards the root, communication between arbitraty nodes is not supported.

        In general mesh networks are a topic of research: there is the IEEE802.11m standard for WiFi meshes: none of the discussed protocols has anything to do with that standard and the ESPs aren't capable of handling it.

        Other IoT wireless networks like IEEE802.15.4 (and ZigBee on top of it) have their onw mesh implementation using AODV and RPL protocols for dynamic layer 2 routing. Mesh networking, especially when there are mobile nodes and unstable links, is still quite difficult and reliability is still low.

        1. Wow thanks for that in depth feedback - great, helps us all understand the limitations...

          Shame that isn't spelled out in the repository, might have saved a little wasted experimenting... still - at least now we know.

      2. PainlessMesh max number of nodes is limited by esp8266 RAM. All nodes store all other addresses and network topology. Any node can be STA and AP. One AP may have up to 4 subnodes, having a tree like topology.
        Have a look to wiki section on gitlab repository for further info.


              1. Hi.. I have played with easy then onto painless mesh getting a special effects lighting system going, using high density ws strings.
                A five node system has been running outdoors now for around three months, in all sorts of conditions and it is holding up very well.
                Using 8266's I found that using dedicated 82's for the mesh and serial data out to secondary devices was the best way of ensuring a reliable setup.

                Each of them is server enabled so I can use an app to send
                10 or so parameters, store and change channel ssid passwords etc. ( Simple app with sliders, buttons using gets).

                I tested 14 devices in quite close proximity and had a few issues with continual reconnects, disconnects etc. By reducing the rf outputs such that there was less confusion as to which nodes had better connectivity, all became far more stable.

                Moving on to 32's .... faster and just feels even more robust .. I still have multiple node testing to do .. but what I do like is that I can use FastLed in rmt drive mode along with the Pmesh and no apparent conflicts have shown up.

                Sure, for some, OTA may well scupper the concept, whereas for others, like me, the independent communication network fits very nicely in this particular project.

  6. Thanks for the research. Just to mention that a RPi WiFi can be configured as Ap & St at the same time. I have it working flawlessly.
    Will experiment ESPNow

  7. I have created a mesh network using esp8266 with 3 clients and 1 server. It is working fine and we are getting the temperature and humidity values from clients to our server. The clients are deployed on ESP01 and server is deployed on nodemcu. then from the same server we are posting these values to cloud using mqtt broker in Nodemcu. you can have look here there are three repo on my github page for client 1, client2 and server

Leave a Reply

Your e-mail address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.