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.

[aerlon]

June is here, so I think it is time for an update. Current status:

ESP-NOW backend: Now working and feature complete. (Turned out that adding easy to use ESP-NOW encryption was a bit of an undertaking, in the "suddenly your code base size doubles" kind of way.) Polishing and documenting still required.
New mesh network example: Needs to be adapted to ESP-NOW backend and completed.

Since release 2.6.0 is due this month (although seemingly delayed?), my current focus is to get the ESP-NOW backend to a release-worthy state as soon as possible. Then a separate pull request with only the backend is possible, should that be desired.

[devyte]

@aerlon 2.6.0 will be pushed back, there is a bit of time yet.
Have you tested with 2.5.2 or latest git?

[aerlon]

@devyte
OK.

Yes, the ESP-NOW part works well on the latest Git, but PR #6026 by @d-a-v introduced a possible bug that makes the TCP/IP code misbehave. I've opened issue #6191 regarding this.

[rorosaurus]

Hi @aerlon! Sorry, I'm just now getting back to this. I actually broke all my hardware (snapped USB traces) and I'm looking to fix/replace it soon.
It looks like #6191 is fixed! So this means the mesh library is working (maybe missing some polish), and is missing updated example code? So I could dive in if I'm willing to work backwards to figure out the usage?

[aerlon]

Hi @rorosaurus!

#6191 is indeed fixed. However the part that I was discussing above which is working well is actually the new ESP-NOW backend. It will allow you to send small payloads (1~700 bytes) up to 100 times faster than with the TCP/IP backend. The backend itself is still not a complete mesh network, although it has been designed to allow for easy mesh network creation. For the complete mesh network experience you will need my updated example, which still needs to be done after the ESP-NOW backend is complete (but should require substantially less time to finish).

Actually the ESP-NOW backend is getting very close to a release-worthy state, so I should be able to create a PR with it by the end of this week, with an updated example to follow soon thereafter. That way you will be able to judge yourself if the library fits your needs yet.

[aerlon]

A few more problems than expected popped up during final testing, but now a work in progress PR can be found here: #6280.

[devyte]

@aerlon given the previous comment, and my review, I'm pushing this back. We'll merge as soon as it's done.

[aerlon]

@devyte Sounds reasonable.

[devyte]

The new mesh PR isn't quite done, and we're past due on 2.7.0. Pushing this back to 2.7.1 for now.

[aerlon]

Sure. My schedule has been pretty swamped the last few months due to the pandemic, but I should be able to finish this up soon, I hope.

[devyte]

Pushing back to 3.

[d-a-v]

Does merged #6280 address this issue ?

[devyte]

@aerlon is therr anything pending? Can this be closed?

[aerlon]

Mesh version 2.2 should address everything mentioned here. The issue can be closed.

[d-a-v]

Thanks !