Retry WIFI connect while in AP mode?

ESPHome
1

Folks,

I had a (self induced) power outage in my wifi router yesterday, and subsequently all my ESPHOMEs apparently did not reconnect. I pushed the reset button on all, and we were back in business.

I presume they went into AP mode. As I have set

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome-Web-xxx"
    password: "xxx"

captive_portal:

Will ESPHOME try to wifi connect, even when in AP mode?

Says:

ap_timeout (Optional, Time): The time after which to enable the configured fallback hotspot. Can be disabled by setting this to 0s, which requires manually starting the AP by other means (eg: from a button press). Defaults to 1min.

and:

reboot_timeout (Optional, Time): The amount of time to wait before rebooting when no WiFi connection exists. Can be disabled by setting this to 0s, but note that the low level IP stack currently seems to have issues with WiFi where a full reboot is required to get the interface back working. Defaults to 15min. Does not apply when in access point mode.

Is there any way to teach the ESP to do the best of the two worlds: Open an AP for emergency or PW change - but reconnect once the wifi is back?

Thx alot!

1 Like
2

Just curious: do you need AP? I don’t… i don’t have AP set up in any of my devices. I use fixed IP, fixed SSID and password (wrote down in yaml itself), so i see no need for AP. I also don’t have “captive_portal’” in any of my devices. If you remove AP then module will restart after “restart_timeout”:

  • when there”s no wifi connection,
  • when there’s no connection to HA via API (if you use api, not mqtt).
3

Thx Pavel,

disabling the AP fall-back would require me to physically remove all ESPs and serial-flash those if at any point I need to reconfigure my wifi. E.g. I recently had to change the wifi password, that would lead to quite some some effort.
(If it is planned one could OTA all with new credentials, while the old config is still live, knowing they would not be connecting, as the new config is not yet active)

I was hoping to get free lunch with AP and retry at the same time.

Cheers

Henrik

4

I see you… although it’s questionable which is faster:

  • do OTA of all devices before changing password or
  • connect to each one of them and change password of each manually…

since it’s possible to have wifi credentials in one file only for all esphome devices (with include…file in yaml) i dare to say that first option is way faster, since you just change password in that file and click “update all” in esphome web interface…

I have wifi credentials and sensors, which are in all devices stored in that file (like wifi signal strength, uptime, connection led…)

5

Hi there,

So is the answer to this question “no”?

Thanks,
Tom

6

Pavel,

I agree if you plan for it, you can update all ESPs with new WIFI data.
Accept that they are offline until all are done and the new WIFI is up.

If everything works you are good to go.
If not… serial flash…

7

Another case where this is extremely painful is when using bssids instead of ssids.

Cases when we need a wifi credentials change:

  1. Change existing wifi credentials.
  2. Changing to new equipment, when existing equipment is at hand.
  3. Existing equipment goes bad and need to replace it with new equipment.

Case 1 and 2 is fairly simple (although we do have to wait for the new equipment to arrive in case 2). Case 3 is quite painful, if we don’t have AP mode backup.

Two possible solutions I’m exploring currently:

  1. Setting up a hardcoded backup network to connect to (like a mobile hotspot). If this works properly, then AP may be disabled safely.
  2. Setting ap_timeout to a large value and setting up physical actions on the device (like button presses) to change it to a low value, and once connected to wifi changing it back to a high value (possible?)

Will keep you posted on the above.

8

Solution 1 works. Solution 2 doesn’t, if AP is enabled setting “reboot_timeout” in wifi has no effect. But “reboot_timeout” in API should work, but I can’t figure out why it doesn’t for me.

9

So, should this be possible with a bit of yaml?

E.g., can we start a timer once AP is enabled, and once it times out, reboot the device? Anyone ever did that?

1 Like