Espeasy only as AP

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
eddieth
New user
Posts: 4
Joined: 25 Oct 2020, 19:14

Espeasy only as AP

#1 Post by eddieth » 25 Oct 2020, 19:22

Hi.
I would like to use espeasy as a standalone device working in AP mode. Is it possible to deactivate the auto turn off timer for access point?
Thank you for your response.

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Espeasy only as AP

#2 Post by TD-er » 25 Oct 2020, 21:10

At the moment it can only be done via a trick.
As soon as the ESP found an access point to connect to, it starts a timer to turn off the AP.
When this timer expired, there is a last check to see if there's someone connected to the AP.
If the AP of the ESP is still actively used, it will not be turned off.

So there are 2 ways you can keep it running as an AP only:
- Do not enter WiFi credentials to connect to an AP.
- Keep at least one station connected to the ESP's AP.

I think not setting WiFi credentials is perhaps the simplest.

eddieth
New user
Posts: 4
Joined: 25 Oct 2020, 19:14

Re: Espeasy only as AP

#3 Post by eddieth » 25 Oct 2020, 21:21

Yes, I know all this. The problem is, this is supposed to be some kind of an extensive garage door controller and most of the time there will be no clients connected.
Is it possible to completely disable the AP mode time limits?

User avatar
budman1758
Normal user
Posts: 301
Joined: 15 Apr 2017, 05:13
Location: Riverside CA USA

Re: Espeasy only as AP

#4 Post by budman1758 » 25 Oct 2020, 21:40

Perhaps you could provide a bit more detail of your particular use case.
"The glass is twice as big as it needs to be".

eddieth
New user
Posts: 4
Joined: 25 Oct 2020, 19:14

Re: Espeasy only as AP

#5 Post by eddieth » 25 Oct 2020, 21:50

I want to build an esp8266 based driver for my garage. It will act as a temperature controller equipped with an oled display. In addition, I would like to be able to open the door using a smartphone. I did all this without a problem in ESPeasy, only the problem of disabling the AP remains. The garage is far out of range of my home wifi.

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Espeasy only as AP

#6 Post by TD-er » 25 Oct 2020, 22:30

How far is "far"?
At least In now understand your desire to keep the AP mode active.

User avatar
iron
Normal user
Posts: 221
Joined: 24 Sep 2016, 08:37
Location: Greece
Contact:

Re: Espeasy only as AP

#7 Post by iron » 26 Oct 2020, 08:30

TD-er wrote: 25 Oct 2020, 22:30 How far is "far"?
At least In now understand your desire to keep the AP mode active.
Many cases require a "stand alone" mode in locations where internet connectivity is not an option. ESP has enough gpios and ESPEasy has a great rules engine that makes it ideal for this.

I believe there should be some sort of an option/check-mark that will officially force the ESP to an AP only mode (requires a couple of additional AP criteria, such as AP ssid and channel) and the standard web interface instead of the config page that becomes default when not connected to an AP.

Controllers and notifications tabs will probably need to be "hidden" to avoid misunderstandings.

-D
-D

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Espeasy only as AP

#8 Post by TD-er » 26 Oct 2020, 09:58

As a matter of fact, I am -as we speak- looking into ways to implement this.
There have been some reports which make it clear the "wifi reconnect interval" should be more dynamic.
Reasons why this is needed:
- CPU load is too high when no AP can be found
- Connection Failure Threshold counter may increment too fast with the current (short) reconnect interval
- ESP may show "hopping" behavior between configured AP's if network is busy or reception quality changes
- To conserve power we also need a "WiFi off" mode
- Some ESP units have poorly designed voltage regulators so they may need some (extra) delay

Apart form that, we now also have ethernet support on ESP32 and soon ESPEasy-Now.

So I started thinking about the currently way too complex WiFi code (partly a left-over from all the WiFi issues we had in the past) and I am now trying to think of a more intuitive way to manage all of this.
It is still a work in progress, but I'm thinking of something like this:

The user must be able to set a defined preference for a medium.
For example (just a random suggestion):
- Ethernet
- WiFi STA
- ESPEasy-Now
- WiFi STA+AP
- WiFi AP

But also there must be an option to set a minimal delay before (re)attempt to connect.
For example for battery powered units that could decide to turn the unit off when battery voltage is too low, or ones with weak voltage regulators.

Right now, we just have a logic similar to "we have WiFi credentials and no connection so retry to connect", which is a bit too simple.
This logic also uses very basic "time since last attempt", while it would make more sense to schedule a new attempt and cancel that attempt if no longer needed.
By scheduling the next attempt (for whatever medium), it becomes all much more simple and clean.

"WiFi off" or "WiFi AP only" state simply becomes "cancel scheduled action to reconnect".
Delayed WiFi connect at start is simply a matter of adding some user defined time to the schedule moment. (-1 for not starting at boot)
Preferred order of attempts may be as simple as schedule the next medium when the previous one failed to connect (or even schedule the next when attempting to connect the preferred medium)
Another way could be to have "Ethernet" and "WiFi STA" at the same preferred level, so start connect both at the same time and use the one finishing first.

So that's what I'm thinking of right now.
It may become quite a big change, so I will probably do it in steps.

eddieth
New user
Posts: 4
Joined: 25 Oct 2020, 19:14

Re: Espeasy only as AP

#9 Post by eddieth » 26 Oct 2020, 10:10

For starters, maybe the option to reset the AP shutdown timer is enough? Maybe introducing some system variable that can be modified with rules?

BTW "far" is ~1,5km ;(

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Espeasy only as AP

#10 Post by TD-er » 26 Oct 2020, 10:24

eddieth wrote: 26 Oct 2020, 10:10 For starters, maybe the option to reset the AP shutdown timer is enough? Maybe introducing some system variable that can be modified with rules?

BTW "far" is ~1,5km ;(
The disadvantage of a "temporary" solution is their incredible long life span.
So I will keep it in mind and if a command like that does fit my future ideas I will add it as a "temporary" fix and later re-use the same command to implement the intended behavior.

And 1.5 km is a good use case for LoRa :)
Roughly a week ago, that was used during the Delsbo Electric event in Sweden to cover a 3.3 km track for the World Record attempt.
So they were in the "studio" switching to me for live updates from the Netherlands on how the power consumption was on some track in the middle of Sweden :)

martinus
Normal user
Posts: 129
Joined: 15 Feb 2020, 16:57

Re: Espeasy only as AP

#11 Post by martinus » 26 Oct 2020, 13:00

As i needed a persistent AP for my ESPNOW stack running on the AP interface i just did this slash-hammer approach:

Code: Select all

void setWifiMode(WiFiMode_t wifimode) {
  if(c_persistentAP)
    return;
c_persistentAP is a global, set by the ESPNOW plugin when active in a task. The ESPNOW plugin configures the Wifi connection and does not want the ESPEasy framework to interfere when active.

But having a setting like "Persistent AP mode" would be nice to have OOTB...

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Espeasy only as AP

#12 Post by TD-er » 26 Oct 2020, 13:15

Yep, the ESP-now layer is quite picky on the WiFi state.
It does work if you are connected to another AP, but you really need to know the conditions or else it will be unreliable.

In STA mode, you simply cannot set the channel as it is determined by the AP you're connecting to.
In AP mode you can set the channel.
In STA+AP, it is best to not try to set the AP channel or else you will be missing lots of packets.

In STA mode, the ESP may enter some kind of "eco mode" (lack of a better word) where it increases the DTIM interval and thus lowers power consumption.
However this does mean the WiFi radio is not always on and thus you will miss ESP-now packets (or the sender must retry it for several 100's of msec)
In AP mode (and STA+AP) the WiFi radio is always listening.

Another thing to keep in mind is the inter-operability between ESP32 and ESP82xx regarding ESP-now.
In my tests it only worked reliable when set to channel 1.

So that's why I consider the (future) ESPEasy-now medium a separate medium as it depends on very specific settings of the WiFi radio.
Maybe something similar is applicable for Bluetooth on the ESP32?

martinus
Normal user
Posts: 129
Joined: 15 Feb 2020, 16:57

Re: Espeasy only as AP

#13 Post by martinus » 04 Dec 2021, 10:45

Hello Gijs,

Any new development on ESPNOW or on 'persistent AP mode?
I've just finished to 'patch' latest release 20211105 to my custom needs and needed to 'hack' even more stuff to avoid OOTB functions from interfering with my own plugin.

I did found some new AP advanced settings, but it looks like they do not solve my issues. This is my plugin hack on System Wake event:

Code: Select all

  WiFi.mode(WIFI_AP_STA);
  const char *ssid       = SecuritySettings.WifiSSID; // getLastWiFiSettingsSSID();
  const char *passphrase = SecuritySettings.WifiKey; // getLastWiFiSettingsPassphrase();
  WiFi.begin(ssid,passphrase);
  if (Settings.IP[0] != 0 && Settings.IP[0] != 255)
  {
    IPAddress ip = Settings.IP;
    IPAddress gw = Settings.Gateway;
    IPAddress subnet = Settings.Subnet;
    IPAddress dns = Settings.DNS;
    WiFi.config(ip, gw, subnet, dns);
  }

  String softAPSSID = NetworkCreateRFCCompliantHostname();
  String pwd        = SecuritySettings.WifiAPKey;
  WiFi.softAP(softAPSSID.c_str(), pwd.c_str(),P212_Channel,1);
  c_persistentAP = true;
  if (esp_now_init()==0) {
    byte state = esp_now_init();
    esp_now_set_pmk((uint8_t*)kok);
    esp_now_register_recv_cb(P212_OnDataRecv);
  }
And then i hack some more in the core routines to stop interference from OOTB code:

if(!c_persistentAP)
NetworkConnectRelaxed();

if(!c_persistentAP)
handle_unprocessedNetworkEvents();

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Espeasy only as AP

#14 Post by TD-er » 04 Dec 2021, 21:38

Not entirely sure what the problem is you encounter.

About the progress on ESP-now layer.
I have spent a lot of time on investigating very strange issues regarding WiFi radio becoming a bit "deaf" after some time.
This also happened on the ESP-now layer and on normal WiFi STA mode.

Right now, what I think is happening is that the actual active WiFi channel may not always be what you'd expect.
This becomes more of an issue on ESP-now as a registered peer is internally (thus in the ESP-now code from Espressif) registered not only by its MAC, but also by its channel where it was last seen.
But also when performing a WiFi scan.
On ESP8266 it is not that much of an issue as it is on ESP32, but now that I've been looking into it, it may explain a lot of issues.

This also plays a role in running an access point and connecting in STA mode.
In STA mode, you cannot set a channel (obviously), but in AP mode, you can.
This means that if you try to run your code, you MUST set the channel of your new AP mode the same as the channel of the AP you're connecting to in STA mode.
STA+AP mode is therefore a bit complicated as you need to keep track of the channel of your STA mode. However you cannot just query the active channel as that returns the.... you never would have guessed it... active channel, but that can be either the AP or the STA mode.

For ESP-now this also plays a rather big role, as you have to decide yourself whether you send via the AP or the STA interface and thus the associated MAC address for your node.

So what can change the active channel:
- perform a WiFi scan
- (Re)connect to an AP in STA mode
- Have an old peer associated in your ESP-now peers list which may not be on the same channel as you are.
- Send broadcast ESP-now messages with a peer on a different channel (N.B. broadcast messages are only sent to all known peers)

This all means you really need to process network events or else it may get unnoticed when things may have changed and thus you may hop between channels without you knowing and this may hurt performance and stability big time.

So knowing all this, please tell me what you try to do which needs to not handle unprocessed network events?

martinus
Normal user
Posts: 129
Joined: 15 Feb 2020, 16:57

Re: Espeasy only as AP

#15 Post by martinus » 05 Dec 2021, 09:13

I've tried to trace back how i even got to the current ESPNOW code that i'm using atm but it looks like results from earlier experiments have been lost.
Somehow i must have concluded that i needed to run ESPNOW on the AP interface to be able to let an ESP32 relay incoming ESPNOW packets to an MQTT broker and be connected to normal Wifi at the same time.

So my 'central' unit also acts like an ESPNOW to MQTT gateway.

After upgrade from ESP Easy 2021014 to 20211105 release, i've noticed that ESPNOW messages were no longer received on my central unit.
I suspected that Wifi handling of ESP Easy core routines interfered somehow and decided to disable those when my ESPNOW plugin is activated. Then ESPNOW worked again.
Still need to figure out why this happens... Maybe the recent wifi handling code does some sort of reset that wipes out my actions that are done at System#Wake event.

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Espeasy only as AP

#16 Post by TD-er » 05 Dec 2021, 19:11

For your use case to act as a gateway, then using the AP interface for ESP-now is the best choice as that one doesn't allow the WiFi radio to go into light sleep, which may happen when using the STA interface.

martinus
Normal user
Posts: 129
Joined: 15 Feb 2020, 16:57

Re: Espeasy only as AP

#17 Post by martinus » 06 Dec 2021, 10:37

I rediscovered some instructions that made me believe that AP_STA mode is required to have both normal Wifi and ESPNOW:
https://randomnerdtutorials.com/esp32-e ... eb-server/

After running some more tests with 20211105 i noticed that i only needed to disabled the calls to setWifiMode() to prevent core features from disabling the AP mode.
This happens after 5 minutes.

Is it possible to keep a persistent AP+STA mode with stock firmware somehow or do i still need to 'hack it'?

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Espeasy only as AP

#18 Post by TD-er » 06 Dec 2021, 10:45

Not yet, but I do plan on adding some user preferred mode for WiFi as it is also very useful to allow the WiFi to not turn on at all for a while.

A quick hack for you may be to hack the code where it checks to see if the AP is actively used.
If it is considered to be actively used, then the AP will not be disabled.
So just add a global variable which you can set to keep the AP "up"

martinus
Normal user
Posts: 129
Joined: 15 Feb 2020, 16:57

Re: Espeasy only as AP

#19 Post by martinus » 07 Dec 2021, 12:42

TD-er wrote: 06 Dec 2021, 10:45 Not yet, but I do plan on adding some user preferred mode for WiFi as it is also very useful to allow the WiFi to not turn on at all for a while.

A quick hack for you may be to hack the code where it checks to see if the AP is actively used.
If it is considered to be actively used, then the AP will not be disabled.
So just add a global variable which you can set to keep the AP "up"
I think the least invasive patch is to run this every minute from my ESPNOW plugin:

Code: Select all

WiFiEventData.timerAPoff.setMillisFromNow(WIFI_AP_OFF_TIMER_DURATION);
Seems to do the job! AP no longer stops after 5 minutes and no ESPEasy core code hacking required...

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Espeasy only as AP

#20 Post by TD-er » 07 Dec 2021, 15:16

Yep, that's one way to do it ;)

JohnW
Normal user
Posts: 10
Joined: 19 Oct 2019, 20:27

Re: Espeasy only as AP

#21 Post by JohnW » 11 Jan 2023, 13:51

TD-er wrote: 07 Dec 2021, 15:16 Yep, that's one way to do it ;)
Can we use ESPEasy also as ESP-Now gateway? Or it’s still in development?

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Espeasy only as AP

#22 Post by TD-er » 11 Jan 2023, 15:23

It is still in development and the code so far is only using ESP-NOW as a local mesh to forward MQTT messages from within the mesh to a "gateway node" (= ESPEasy node connected to network and a MQTT broker)

Post Reply

Who is online

Users browsing this forum: Google [Bot], Jieffe and 31 guests