WifiMesh library has no way for "master" node to initiate transmission

[rorosaurus]

Basic Infos

• [X ] This issue complies with the issue POLICY doc.
• [ X] I have read the documentation at readthedocs and the issue is not addressed there.
• [ X] I have tested that the issue is present in current master branch (aka latest git).
• [X ] I have searched the issue tracker for a similar issue.
• [X ] If there is a stack dump, I have decoded it.
• [ X] I have filled out all fields below.

Platform

• Hardware: ESP-8266EX
• Module: Wemos D1 mini r2

Problem Description

This is a issue/question related to the new changes to WifiMesh.
https://github.com/esp8266/Arduino/tree/master/libraries/ESP8266WiFiMesh

Is it intended that the node currently functioning as the AP is unable to initiate transmissions? I have put the example code on two devices, and found that the 2nd device connects to the first and sends messages (and receives confirmations), but the 1st device is only ever able to reply - never able to initiate a transmission of its own.

It seems to be this might be intended, based on the comparison of nodeIDs in the networkFilter in HelloMesh. I guess this is how you handle prioritizing which AP to connect to?

It would be nice to be able to send some information to all the nodes in the mesh network, without requiring each child node to "ping" the master to enable a response. Am I missing something? :)

Example code: https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFiMesh/examples/HelloMesh/HelloMesh.ino

[rorosaurus]

@devyte @aerlon, in case you're willing to help me see what I'm missing :)

[aerlon]

Your observation is correct. In the current example that is the intended behaviour. To quote my own PR:

Next I’ve been planning on providing a better reference mesh implementation than in the current example. At the moment the library is more a framework to build your own mesh network, rather than a working mesh network.

So think of the current mesh library as the basic building blocks you need to build your own mesh network with ESP8266. If you have patience you can of course also wait for my new example. It will allow all nodes to send messages to the entire network, but it will be a few weeks till I can complete it.

I've tried to make the base library quite flexible, so perhaps there will one day be many different mesh algorithm choices as examples, so the user can choose whichever is optimal for the task at hand.

[devyte]

@aerlon should I leave this open pending your better reference example? Just to track, no hurry.

[rorosaurus]

Thanks for the information! I'll cobble together something with the current library to meet my deadline, and circle back in a few weeks to update with your new example 😃! Thanks!

[aerlon]

@devyte Sure, you can leave this open to track the example.

@rorosaurus No problem! I'm currently working on an intermediate update which will add some features, fix the issues remaining in my last PR and fix some new things I've discovered since. In particular you should know that WiFi.disconnect(); should be added to the mesh example code after delay(50);, otherwise a dedicated mesh AP will suffer from poor WiFi performance.

[rorosaurus]

You could also just pass in false to attemptTrasmission to disconnect after the transmission, right?

While on the topic, in this example, a mesh of > 6 nodes with all nodes within range of each other would result in at least one node who isn't able to connect to the AP? By this, I mean each node has no way of knowing a priori whether a connection attempt will fail (due to too many connections, if nodes don't disconnect after transmission), right?

[aerlon]

Ah, almost real time communication.

Not sure how to interpret your sentence. meshNode.attemptTransmission(request, false); will not disconnect. meshNode.attemptTransmission(request, true); or meshNode.attemptTransmission(request); will disconnect after transmission.

Yes, though I've since discovered the default max number is actually 4, not 5. The intermediate update I mentioned above may allow you to adjust this, but it is a topic I need to research a bit more first. Nodes that cannot connect will time out.

[Elijahg]

Thanks for the many library fixes @aerlon, your work is much appreciated!

I've got the same issue as rorosaurus, it currently means one node has to always be assigned as a "root" and is effectively useless to send messages. I've also not found a way of forcing a particular node to be "root", thus a random one is assigned when the mesh is powered up - which isn't great for my use in a smart-home environment since if the wrong device becomes root, it can't communicate and that device is effectively useless! Is there a way to force a particular node to be root? Also, have you pushed the new example anywhere to try out? Thanks!

[aerlon]

@Elijahg Glad to hear it is useful!

For forcing a node to be root, line 90 in the example is useful to look at. Here we decide which nodes will connect/receive connections. As you can see, the node with the lowest NodeID will only receive connections. So the easiest solution to your problem would be to give the desired root the lowest NodeID by using the following code in setup() after meshNode.begin(): meshNode.setNodeID("0"); (this of course assumes that you have no node with NodeID "0", but if you do you can always change that id to something else in the same way).

Work is underway on a new library update, but feature creep has ensured it will arrive later than planned. I've been experimenting with ESP_NOW as a way to speed up the network. Currently it seems as though this may cut transfer speeds in larger networks by 98-99 % for small payloads (around 200-600 bytes). This was so interesting that I decided to write a new (optional) ESP_NOW backend for the library.

My intention was to have it done by release 2.5.0 (which is scheduled for today), but it is a bit more effort than I first expected and my schedule has not allowed me to allocate more time to compensate. The ESP_NOW backend and a new example to go with it will be finished, but I do not have enough information yet to give a set time (current guesstimate is around Christmas).

[devyte]

@aerlon do you have an update for this?

[aerlon]

Current status:

ESP-NOW backend: Working and almost complete (14 ms to transmit up to 234 bytes at the moment, 40 ms for 702 bytes). Only feature remaining to implement is encrypted transmissions.
New mesh network example: Needs to be adapted to ESP-NOW backend and completed.

Progress is good at the moment, but I'll refrain from giving a set time for completion since it seems to be hard to estimate. The update should be ready in time for the 2.6.0 June milestone at least.