hello! i used custom build using the controller espeasy-now (c019) and dht12.
esp1 connected to screen showing temperature received from esp2
esp2 is connected to dht12
esp1 controllers: 1- mqtt, 2- espeasy p2p, 3-espeasy-now
both esp have espeasy-now enabled from advanced tab. espeasy-now peer mac addresses are added in config tab. on main tab i can see nodes are discovered showing "peer info" "ESPEASY-NOW with node mac address and channel"
i am receiving the sensor output on esp1 screen when both are connected to wifi, but when i disconnect esp2 from wifi to communicate via espeasy-now controller, i no longer receive updates of the sensor, eventhough i can see nodes are still on both main tab of both esp. and on esp1, log is showing that it is receiving data from esp2 "2005572: ESPEasy-NOW: received BE:DD:C2:16:1C:CD payload: 51 type: p2p (1/1) 2005572: ESPEasy-NOW: received BE:DD:C2:16:1C:CD payload: 51 type: p2p (1/1)"
Have I missed something?
p2p and espeasy-now
Moderators: grovkillen, Stuntteam, TD-er
Re: p2p and espeasy-now
Nope, you haven't missed anything.
There is a reason why it is still a work-in-progress.
Right now the ESPEasy-NOW feature only acts as a mesh to forward MQTT messages to any node in the mesh that has a connection to the broker.
As of now, it simply doesn't yet work without an extra network connection on at least one node in the mesh.
The reason why it takes so long is because its interoperability between ESP8266 and ESP32 is unpredictable at best.
Also there have been a lot(!!) (and still are a few) issues regarding WiFi code on the ESP nodes.
There is a reason why it is still a work-in-progress.
Right now the ESPEasy-NOW feature only acts as a mesh to forward MQTT messages to any node in the mesh that has a connection to the broker.
As of now, it simply doesn't yet work without an extra network connection on at least one node in the mesh.
The reason why it takes so long is because its interoperability between ESP8266 and ESP32 is unpredictable at best.
Also there have been a lot(!!) (and still are a few) issues regarding WiFi code on the ESP nodes.
Re: p2p and espeasy-now
in my setup, both esp are esp8266. esp1(node1) is connected to wifi and to mqtt broker, esp2(node2) connected to dht12. even though node 1 is connected to mqtt broker via wifi, i'm still not able to receive from node via espeasy-now controller, while i can see in log of node 1 that i'm receiving data from node2. i will try to figure out how to make it work while 1 node connected to the broker, if you can lead me to any sensitive configuration it would be awesome. i need to forward the temperature from node 2 via espeasy-now to node1 which can reach the wifi and is connected to mqtt broker.
Re: p2p and espeasy-now
In the controller you also need to enable the MQTT fallback, to indicate the ESPEasy-now mesh layer that your node may be an elligible 'gateway'.
The reported "distance" is related to the nr of hops needed to reach such a gateway.
So in short:
- Set in the MQTT controller it is allowed to forward MQTT messages (either within the mesh, or to the broker)
- Enable the mesh in the tools->advanced page
The "force mesh channel" (tools->advanced page) is mainly needed when you have an ethernet gateway node instead of wifi gateway.
Problem with "ethernet" nodes is that there may not even be an access point, so there is not really a defined channel to use.
By setting this forced mesh channel (preferably to 1 as that will be tried first, thus speeding up mesh detection), you make the mesh network a lot more stable.
If a mesh node has WiFi credentials, it will periodically stop "meshing" to see if it can reach an AP.
This is done roughly every 10 minutes.
So if you know "mesh nodes" will never reliably connect to an AP, you better not set any WiFi credentials on those.
Right now, it only forwards MQTT messages to a gateway node.
The gateway node(s) will every 30 seconds send out a packet to all nodes to help all nodes determine what other nodes are visible.
This will then help them find the best route to a gateway node.
You can also publish a message from any node to a MQTT topic ending with "traceroute".
This will then have the node nr of each node on its route appended to the message. Great for debugging.
This also means each node needs to have an unique node nr, not being 0 nor 255.
Right now, there are only announcement messages (and NTP time sync) via the mesh.
Currently you can't send commands via this layer to other nodes as this needs path traversel in the other direction which isn't working yet.
I have been testing this upto 6 hops, but it should really have not a limit. However it is more likely the message will enter a loop somewhere along the route if it is used in a mesh with lots of nodes where there are lots of possible routes.
If the nodes are all in a straight line, then it will probably work just fine over many hops.
The distance between nodes can be quite a bit longer compared to normal WiFi as it is automatically switching to a lower bandwidth when an ESP-NOW packet isn't acknowledged.
The reported "distance" is related to the nr of hops needed to reach such a gateway.
So in short:
- Set in the MQTT controller it is allowed to forward MQTT messages (either within the mesh, or to the broker)
- Enable the mesh in the tools->advanced page
The "force mesh channel" (tools->advanced page) is mainly needed when you have an ethernet gateway node instead of wifi gateway.
Problem with "ethernet" nodes is that there may not even be an access point, so there is not really a defined channel to use.
By setting this forced mesh channel (preferably to 1 as that will be tried first, thus speeding up mesh detection), you make the mesh network a lot more stable.
If a mesh node has WiFi credentials, it will periodically stop "meshing" to see if it can reach an AP.
This is done roughly every 10 minutes.
So if you know "mesh nodes" will never reliably connect to an AP, you better not set any WiFi credentials on those.
Right now, it only forwards MQTT messages to a gateway node.
The gateway node(s) will every 30 seconds send out a packet to all nodes to help all nodes determine what other nodes are visible.
This will then help them find the best route to a gateway node.
You can also publish a message from any node to a MQTT topic ending with "traceroute".
This will then have the node nr of each node on its route appended to the message. Great for debugging.
This also means each node needs to have an unique node nr, not being 0 nor 255.
Right now, there are only announcement messages (and NTP time sync) via the mesh.
Currently you can't send commands via this layer to other nodes as this needs path traversel in the other direction which isn't working yet.
I have been testing this upto 6 hops, but it should really have not a limit. However it is more likely the message will enter a loop somewhere along the route if it is used in a mesh with lots of nodes where there are lots of possible routes.
If the nodes are all in a straight line, then it will probably work just fine over many hops.
The distance between nodes can be quite a bit longer compared to normal WiFi as it is automatically switching to a lower bandwidth when an ESP-NOW packet isn't acknowledged.
Re: p2p and espeasy-now
Understood, switching to a lower bandwidth when an ESP-NOW packet isn't acknowledged is a great way to improve the signal range.
unfortunately we can't send commands to nodes via espeasy-now mesh. hope to have this feature ready soon
Thanks TD-er
unfortunately we can't send commands to nodes via espeasy-now mesh. hope to have this feature ready soon
Thanks TD-er
Who is online
Users browsing this forum: Google [Bot] and 47 guests