Exploring ESP32 Mesh technology

On last short holidays on Barcelona I went to visit my father and I brought with me a very small present:

Well actually the second one is for him, but the other that was made for my brother is still there, so we decided to run some tests. One of the cool things I find about ESP-IDF as a framework instead of Arduino framework for Espressif chips is that before compiling you can do a : make menuconfig

So basically you can set the configuration variables before compiling. Not only from main code but also for any component that is loaded using git submodules. This is how the Light example configuration looks like:

As you can see the RGB Gpios are fully configurable and also the color A to color B transition

So that’s the benefit of building your own light, you can just tweak it, to make a slow transition from Red to Green or add any submodule (Like this ESP32 Mesh Light Oled tweak I published in github)

So what my father did after I installed him the ESP-IDF / MDF stuff in his Ubuntu laptop is to debug the Lamp logs to see how they behave, to analyze the Root-> Nodes behaviour as described in the Mesh API Guide.

Actually only ONE Lamp acts as a root node. All other lamps are getting the instructions from this root node

If the root node lamp is disconnected, after no receiving beacon frames that is kind of a heartbeat to prove root node is alive, child Lamps organize a voting session to see who is going to become the next root node. We can see this clearly in this Log:

FIRST LAMP CONNECTS [0;32mI (695) phy: phy_version: 4008, c9ae59f, Jan 25 2019, 16:54:06, 1, 0 [0m 14:40:26.181 -> I (696) wifi: mode : sta (3c:71:bf:a9:45:14) 14:40:26.181 [0;32mI (745) [mwifi, 138]: esp-mdf version: 67a0a5b [0m 14:40:26.181 -> W (745) wifi:[beacon]new interval:100ms 14:40:26.181 -> I (747) wifi: mode : sta (3c:71:bf:a9:45:14) + softAP (3c:71:bf:a9:45:15) 14:40:26.185 -> I (751) wifi: Init max length of beacon: 752/752 MESH IS STARTED 14:40:27.204 -> I (1773) mesh: ;need_scan:0x1, need_scan_router:0x0, look_for_nwk_count:1 14:40:27.204 -> [0;32mI (1774) [mwifi, 98]: MESH is started [0m 14:40:27.204 -> [0;32mI (1778) [light, 655]: event_loop_cb, event: 0x0 [0m 14:40:27.204 -> [0;32mI (1783) [light, 660]: MESH is started [0m I (2075) mesh: find root:ESPM_D9C830, root_cap:2(max:256), new channel:1, old channel:0 14:40:27.510 -> I (2075) mesh: [S2]MiFibra-509A, 4c:1b:86:5a:50:9c, channel:1, rssi:-28 14:40:27.510 -> I (2078) mesh: find router:[ssid_len:12]MiFibra-509A, rssi:-28, 4c:1b:86:5a:50:9c(encrypted), new channel:1, old channel:0 SECOND LAMP IS CONNECTED 14:40:27.544 -> [0;32mI (2125) [light, 683]: the root connects to another router with the same SSID [0m I (2428) mesh: [SCAN][ch:1]AP:6, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:0,i:0][4c:1b:86:5a:50:9c]router found 14:40:27.850 -> I (2431) mesh: 6545[selection]try rssi_threshold:-78, backoff times:0, max:5 14:40:27.884 -> I (2438) mesh: [DONE]connect to parent:ESPM_D9C830 (This is the hidden SSID from ROOT Node Lamp), channel:1, rssi:-41, 30:ae:a4:d9:c8:31[layer:1, assoc:0], my_vote_num:0/voter_num:0, rc[00:00:00:00:00:00/-120/0] D (3513) [light, 168]: Erase restart count [0m I (3961) wifi: n:1 1, o:1 0, ap:1 1, sta:1 1, prof:1 14:40:29.375 -> I (3963) wifi: state: init -> auth (b0) I (3971) wifi: state: auth -> assoc (0) 14:40:29.409 -> I (3979) wifi: state: assoc -> run (10) 14:40:29.409 -> I (3980) wifi: connected with ESPM_D9C830, channel 1 NOTE: I guess restart count is a counter to reset the Lamp configuration, since turning it on/off for 3 times, resets the Lamp and blinks yellow waiting for configuration. SO NOW, WE DISCONNECT ROOT NODE (First Lamp) The node child has no parent, hence no connectivity at all and does not receive any commands, this is what happens [0;32mI (211787) [light, 140]: System information, channel: 1, layer: 2, self mac: 3c:71:bf:a9:45:14, parent bssid: 30:ae:a4:d9:c8:31, parent rssi: -34, node num: 2, free heap: 159120 [0m [0;32mI (221787) [light, 140]: System information, channel: 1, layer: 2, self mac: 3c:71:bf:a9:45:14, parent bssid: 30:ae:a4:d9:c8:31, parent rssi: -34, node num: 2, free heap: 159120 [0m [0;32mI (231787) [light, 140]: System information, channel: 1, layer: 2, self mac: 3c:71:bf:a9:45:14, parent bssid: 30:ae:a4:d9:c8:31, parent rssi: -34, node num: 2, free heap: 159120 [0m I (234633) wifi: bcn_timout,ap_probe_send_start I (237136) wifi: ap_probe_send over, resett wifi status to disassoc 14:44:22.553 -> I (237136) wifi: state: run -> init (c800) 14:44:22.587 -> I (237137) wifi: pm stop, total sleep time: 0 us / 233153623 us 14:44:22.587 14:44:22.587 -> I (237141) wifi: n:1 0, o:1 1, ap:1 1, sta:1 1, prof:1 14:44:22.587 -> [0;32mI (237148) [mwifi, 84]: Parent is disconnected, reason: 200 [0m 14:44:22.587 -> [0;32mI (237152) [light, 655]: event_loop_cb, event: 0x8 [0m 14:44:22.587 -> I (237153) mesh: [wifi]disconnected reason:200(beacon timeout), continuous:1/max:12, non-root, vote(,stopped) 14:44:22.587 -> [0;32mI (237158) [light, 669]: Parent is disconnected on station interface [0m 14:44:22.620 -> I (237168) mesh: [scan]new scanning time:600ms And after this starts the voting to see what Lamp is going to be the next Root lamp.

The interesting part of a Mesh network is that is like a self-healing network, where the hierarchy is redefined once you remove one of it’s pieces, and reconstructs automatically. Of course this takes time, and if you remove a Root node, all your system will be idle for some seconds (in our tests was up to 20/30 seconds) till the selection of a new Root node takes place. But the benefit, is that as every lamp can be connected to it’s parent and at the same time be an Access point where childs connect, you can extend your WiFi reach. Every lamp is like a small WiFi that broadcasts commands to it’s childs.