Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: ESPEasy-now layer #3301

Open
wants to merge 703 commits into
base: mega
Choose a base branch
from

Conversation

TD-er
Copy link
Member

@TD-er TD-er commented Oct 9, 2020

A communication layer using ESP-now extended to be used in ESPEasy.
For example the ESP-now packets only can have a 255 byte payload, so sending more means those have to be split and merged while processing packets from several different nodes.

ESP-now is quite fast, with typical round trip times of less than 4 msec.
It also does not need to be connected to WiFi.
As it can use a very small bandwidth channel and low bitrate, its reach is significant more compared to normal WiFi.

This is nowhere near complete, but it takes a lot of time to keep in sync, so by merging it I may speed up development.
It is still highly experimental and lots of code may change regarding ESPEasy-now.

What's working now:

  • Can send MQTT packets over several hops to a connected node that publishes it. (tested upto 6 hops, each with 50m distance between them)
  • Node discovery via ESPEasy-now
  • NTP time sync with less than 2 msec jitter for the complete network.

Still in development:

  • ESPEasy p2p via this layer (share tasks, send commands/events etc.)
  • Encryption per set of nodes
  • Easy deployment
  • Sending logs to logserver just like MQTT messages (over hops until it reaches a network connected node)
  • Send via commands from rules using ESPEasy-now
  • Improvement of distance calculation and path find routine

Known issues:

  • CPU load of nodes not connected to WiFi is still rather high (no idea why)
  • ESP-now does seem to favor channel 1. Communication between ESP8266 and ESP32 is broken when using another channel
  • The option to add preferred MAC addresses for routing is mainly used for debugging and will be removed when path finding routine is fixed.

@tonhuisman
Copy link
Contributor

This PR fails the build because of this error:

Compiling .pio/build/custom_ESP32_4M316k/src/src/ESPEasyCore/ESPEasyWifi_ProcessEvent.cpp.o
src/src/ESPEasyCore/ESPEasyWifi_ProcessEvent.cpp:8:40: fatal error: ../ESPEasyCore/ESPEasyWiFi.h: No such file or directory compilation terminated.

Might need a fix?

@TD-er
Copy link
Member Author

TD-er commented Feb 10, 2021

Yep Case sensitive issue, which compiles well on Windows, but not on Linux.
And there are other issues as well, since it will crash if you load the AP candidate from RTC, so I'm working on it at the moment :)

@Misiu
Copy link

Misiu commented Mar 5, 2021

does this mean that we will be able to use one node (esp8266) as a sensor unit and another node as a display unit in places that don't have wifi?
that would be an awesome use case - be able to put one or more wireless sensors inside a building and have a single unit with a display that would show the values of all sensors.

@TD-er
Copy link
Member Author

TD-er commented Mar 5, 2021

Yep and even completely self-organising.
So the nodes will find a way for finding each other.

Currently the implementation tries to forward MQTT messages (of any size) to a node that's connected to a broker, but I am -as we speak- working on making it possible to send messages to any node in the mesh of nodes.
This could even be a node that just wakes up to send a measurement.

Both ESP8266 and ESP32 can be used together and also ESP32 + ethernet to act as a gateway (that's how it is being tested right now)

But there's still some stability issues in the self organizing routing which I'm working on.
That's why I added the traceroute feature yesterday, to see why it appeared a bit slow. (numbers are UnitNr)
image

I want to make it completely network-agnostic and thus very resilient to network outages.

Upto 6 hops of each 50m have been used in tests with 700+ bytes of payload (ESP-NOW packets can only hold 200 - 250 bytes of data), so the underlaying datastructure of splitting and merging packets does work well :)

@@ -221,6 +221,9 @@ void WebServerInit()
webserver_init = true;

// Prepare webserver pages

// FIXME TD-er: The added String() wrapper is needed for the latest ESP32 core lib.
// See: https://github.com/espressif/arduino-esp32/issues/4374
#ifdef WEBSERVER_ROOT
web_server.on("/", handle_root);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't that "/" also have the F() macro, like the other strings?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably, but I've had some issues not so long ago with the web_server.on calls with FlashStringHelper on ESP32.
So perhaps I missed this one?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps I missed this one?

That's the most likely cause 😉
Not a biggie, of course, just something I spotted.

@@ -293,12 +293,12 @@ void WebTemplateParser::getWebPageTemplateVar(const String& varName)
if ((i == MENU_INDEX_RULES) && !Settings.UseRules) { // hide rules menu item
continue;
}
#ifndef FEATURE_NOTIFIER
#if FEATURE_NOTIFIER==0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could have been:
#if !FEATURE_NOTIFIER
but the end-result is the same 😃

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And that piece of code looks like it might still be wrong in the mega branch (#ifndef instead of #if !...)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested that both ways and with and without Notifiers enabled, but it doesn't seem to make a difference, still works as intended (tab is shown or not, based on notifiers available or not), the code just looks a bit odd.
But you fixed it already so it will be corrected in due time 👍

TD-er added 30 commits April 25, 2024 12:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants