ESP8266 Mesh Experiment

In case anyone else (such as me) was sitting on the shelf within this particular one — and might like to have a go with an ESP8266 mesh… we’ve been having a play.

Regular readers may recall I wasted the better part of a year using those AWFUL NRG24L01 boards becoming no-where and finally hoping to generate a mesh — really I think it’s the mere presence.

Fast forward to December 2017 – take 3 ESP8266 modules, run the identical code on each of the three, attach a LED+resistor to GPIO12… choose ESP8266 modules for a walk. One is in the office out of scope, the other in the midst sitting in my car in the freezing cold.     After all 3 are speaking to each other you’ll notice 3 flashes in rapid succession…

That’s it no setup. . You can see the output of a few of these on the serial port and find out how many are speaking (if your eyes are quickly enough) to a LED.

So — here is where we began….

https://github.com/Coopdis/easyMesh

That relies on two libraries — before compiling install.

https://github.com/bblanchon/ArduinoJson

From this one you need the SimpleList library

https://github.com/blackhack/ArduLibraries

Once added to your Arduino Development surroundings (yet you do this — I use Arduino 1.8.5 — also on other events Atmel Studio — on this occasion — the easy Arduino IDE on Windows 10 64 piece) — grab the example StartHere…. That’s it you need to have the ability to figure out once it is working to go from that point.

To test this as suggested previously, we abandoned one unit at my workplace (protected from the home by a small stone construction) and place one unit at the home.   The one from the home saw nothing.   We included one to a battery between, sitting on my vehicle –  therefore it could visit the workplace and the home by line of site.    Bingo, the home unit saw all three .   That remained up for a while among the components dropped out. A reboot fixed that but It dropped out again — subsequently reconnected.

At this point I was prepared to throw in the towel ANOTHER failed mesh. So to explain it doesn’t have anything to do with your house/office WIFI and doesn’t  require access to an access point or router. No installation is required. Units can broadcast to everyone in the mesh when we’ve cracked it can talk to apparatus which talk or as you will see at some stage.

As you can see here “piggy in the middle” was speaking to the others.

Well, that is the idea but obviously it didn’t work reliably.

After some time we became a little despondent this was showing indications of becoming undependable — I sent a message to the ISSUES department for the repository but noticed that someone had beaten me to it 3 weeks ago and never heard anything back. Remember this code had not been modified in annually.

I obtained side-tracked because you do — and from chance I came across this particular variation. .

https://gitlab.com/BlackEdder/painlessMesh

Same codebase but altered recently.   We hooked that the sole immediate difference and up to all 3 planks was that the LED being predicated as against earth based.   With three components connected using this code that is new, the flashes were a tad too close together so I set my OWON scope on scan to see them. To date (hours later) with a single unit at the home, one sitting freezing to death in my vehicle and the next in my office, we’ve never missed a beat.

Debugging on this particular one is more complicated and shows memory usage.

I’m keeping a watch out for this RAM — which began in 32720 free and currently hovers between 33904 along with 31766… i.e. RAM usage looks just fine.

A great deal of things in the picture above but no real errors that I can see. I do see three different node numbers (automatic, from MAC address). From the code you can select how much should any debugging you see. This looks a little more complex than the code but the majority of it I guess not and we can assume works worry about it.

So here is the strategy

Once we are happy that this is functioning — the strategy is to give each and every meaningful name… to then take ONE of these ESP8266s and have it talk to a normal ESP8266 via sequential or similar across the lines of packages like  topic:”who to”, payload:”the payload”

i.e.. An ESP8266 would use software that is normal to talk to MQTT and relay that message. The unit doing the link would subsequently BROADCAST to all (simplest, I know you could do it another way) in which the issue is the “name” of this unit. Each would compare, do what it’s supposed to perform using the payload and send a message back up — ie broadcast…. Oh… subject:”who from/reply”,payload:” answer payload” which would be picked up from the unit connected to the external community — and shipped back to return to MQTT.

Okay this would be great for high speed connectivity however I’m guessing would be fine for turning things on and off.

This gets around a problem where WIFI isn’t functional except for a single unit permitted in scope through a single unit or a firewall — the remainder of the MESH want be no-where near WIFI access.

That’s where we are like I talk the scope is reporting, despite the poor piggy-in-the-middle unit+battery out freezing to death at –6c, groups of 3 relations constantly — and RAM is fine.

THIS is what makes things fun…. experimenting!

The article ESP8266 Mesh Experiment appeared first on Scargill’s Tech Blog.