esp_mesh integration

[HollisTech]

Hi,

First - thank you so much for this great library. You saved me weeks of effort moving from hard-coded ssid/passwords to a more secure configuration. Well done!

I am working on small-ish collections of peer cooperating devices (using coap to communicate), and manually configuring each device via a web interface is ok for testing but not for a product. Ultimately I want to integrate esp_mesh as well, so that only one of the devices needs manual configuration and the rest just join into the soft-ap that (root) node creates.

Any thoughts on how to do this?

[Hieromon]

It has been integrated ESP-MESH into ESP-IDF for ESP32, but porting to Arduino-core does not seem to be done yet. The ESP-IDF document mentions the topology of ESP-MESH, but it is due to the ESP-MESH components included in ESP-IDF and not the Arduino-core implementation.

On the other hand, the ESP8266WiFiMesh::begin function of the WiFiMesh library contained in the Arduino-core of ESP8266 is an implementation that can itself be both a root node and a child node (in the case, limited to WIFI_STA as a station node). And it doesn't need WiFi.begin. (In fact, it has replaced by ESP8266WiFiMesh::begin accompany with SSID and password as a matter of course)

In light of the above, I wish to ask questions about your mention.

1. So, Are you looking for an ESP8266WiFiMesh::begin alternative that can behave like AutoConnect?

2. Need to configure with an SSID and password for all nodes, is it wrong?

   I took a look at the ESP8266WiFiMesh implementation a little, inspired by your post. According to its implementation, both a root node and child nodes need advance hardcoding of SSID and password to each other. Because the node as a root invokes SoftAP using WIFI_AP_STA with SSID and password, and if the same SSID is already in the broadcast, the node runs WiFi.begin using SSID and password. This means that all station (leaf) nodes in the mesh must know the SSID and password of the root node, which is in the WIFI_AP_STA state. And these SSIDs and passwords must be pre-embedded in all nodes by some mechanisms such as hardcoding or AutoConnect.
   But you mentioned.

   so that only one of the devices needs manual configuration and the rest just join into the soft-ap that (root) node creates.

   What is the intention?

[HollisTech]

What I want is a self-organizing collection of devices. Ideally there is no designated root node, so whichever node gets configured via the autoconnect web interface becomes the root node and the other nodes connect via the hard-coded mesh ap. It is possible that the mesh network is only used to propagate the root node's wifi configuration, it is also possible that the mesh network is used for inter-node communication and that the root node is just used as a management gateway. Once I integrate mesh I'll figure out how to use it :-)

[Hieromon]

It is possible that the mesh network is only used to propagate the root node's wifi configuration

Can I paraphrase it as the following steps?

1. Start phase
   All ESP modules as nodes start in AP_STA mode with a unique SSID and wait on the captive portal.
   At the same time, periodically monitor the SSID broadcast of the hardcoded mesh AP. (maybe by WiFi.scanNetworks)

2. Management gateway selection phase
   You open a captive portal by selecting only one of the SSIDs emitted by multiple node modules. That SSID is only used for WiFi configuration, not the SSID of the target WiFi router.

3. WiFi configuration phase
   Connect the module you selected as the management gateway to the target WiFi router using AutoConnect.
   At this time, you can select the SSID to broadcast from among the hard-coded mesh APs. That is, you can select particular ESP modules that can connect to the target WiFi router. Its selection function will be implemented by the AutoConnectAux pages.

4. Mesh AP broadcasting phase
   WiFi connected ESP module as a management node will start the mesh with the selected SSID.
   When the broadcast of the mesh SSID starts, other leaf node modules connect to the mesh. This behavior is already implemented in ESP8266WiFiMesh. At this time, the leaf node cancels the captive portal waiting by AutoConnect and shifts to WiFi-Mesh.

5. Leaf nodes connection phase
   The leaf node that started the mesh emits queries to the management node. The management node will respond with SSID, password and IP configuration data for connecting the target WiFi router.
   The leaf node closes the mesh and attempts to connect to the target WiFi router with the returned configuration data from the management node. It only calls a WiFi.begin, not action by AutoConnect.

It's an interesting operating model and is feasible, I think. In Japan, it is called the "IMOZURU-SHIKI" (like a chain-reaction)

[HollisTech]

yeah that is what I have in mind, or sort of in mind! Ha ha I googled IMOZURU-SHIKI and all I get is links to hentai manga porn!

[Hieromon]

Seriously?
Convey accurately, This is IMOZURU-SHIKI.

[Hieromon]

@HollisTech, Do you leave this topic open?
I cannot provide any more ideas to you on this topic at this time.

[HollisTech]

No you can close it. It wasn't really an issue it was a query. Mark Roddy

…

On Thu, Feb 27, 2020 at 7:49 AM Hieromon Ikasamo ***@***.***> wrote: @HollisTech <https://github.com/HollisTech>, Do you leave this topic open? I cannot provide any more ideas to you on this topic at this time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#182?email_source=notifications&email_token=ABJGMFZC2C44RACILMOGHL3RE6ZHDA5CNFSM4KXEZIPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENEH7TI#issuecomment-591953869>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJGMFZHGHHFXTUURUCHXQ3RE6ZHDANCNFSM4KXEZIPA> .

[Hieromon]

@HollisTech Hello, it's IMOZURU.
I will keep open this topic to research your idea.

I tried to implement the self-organized mesh using AutoConnet based on your idea. But, I have not succeeded in it yet.
Surprisingly, a LEAF node can establish the WiFi data link with the ROOT automatically.
However, it cannot connect to the WiFiServer on the ROOT for message exchange after the establishment WiFi data link. There seems to be a conflict between the ESP8266WebServer class used by AutoConnect and the WiFiServer class used internally by the ESP8266WiFiMesh library. (WiFiServer class is also the base class of ESP8266WebServer)
The cause is still unknown and not a port conflict because mesh communication uses port 4011. Maybe it is from the TCP stack.

I posted the trial code on the Gist named Hieromon/Mesh.ino. I hope it helps you.
If you have any good news, please post it here.
Thank you.

[phillezet]

Sounds very interesting, do you have any updates or news to this topic?

[HollisTech]

I've put it all on hold for a while. I was waiting for platform io to catch up to the latest esp releases. I might take another look. Mark Roddy

…

On Mon, Oct 5, 2020 at 2:41 PM pmartinz ***@***.***> wrote: Sounds very interesting, do you have any updates or news to this topic? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJGMF35J5OMWFDLZHODTFDSJIHO3ANCNFSM4KXEZIPA> .

[Hieromon]

@pmartinz I believe it a meaningful attempt and haven't abandoned it that tries to bring AutoConnect into the esp-mesh platform. I wish to resume after release work for AutoConnect v.120 is finished.

[phillezet]

@HollisTech, @Hieromon Thanks for the updates!

[ark02]

I too am interested in the ESP-mesh implementations and am willing to test things