Wifi breaks when using some combination of components.

[harmptor]

Operating environment/Installation (Hass.io/Docker/pip/etc.):

pip on debian 10

ESP (ESP32/ESP8266, Board/Sonoff):

Sonoff Basic

ESPHome version (latest production, beta, dev branch)

1.18.0

Affected component:

I can't say exactly because it differs. In my testing OTA, Restart switch and GPIO Binary Sensor

Description of problem: The error logs show when combining some of the components of my yaml together. All further log messages say 'Probe Request Unsuccessful'. Individually these components work fine in my testing. I cannot figure out which combination is the magic one, all I know is it breaks when using OTA, Switch and Binary sensor all together, but works when disabling one of them (which one didnt matter). The comment # are just from my testing, I actually intend to use all components.

Problem-relevant YAML-configuration entries:

substitutions:
  l_name: heinz
  u_name: Heinz

esphome:
  name: $l_name
  platform: ESP8266
  board: esp01_1m

wifi: 
  networks:
  - ssid: !secret myrouter_ssid
    password: !secret myrouter_pass
  - ssid: !secret defaultrouter_ssid
    password: !secret defaultrouter_pass

# Enable logging
logger:

# Enable Home Assistant API
api:
  services:
    - service: flash
      then:
        - output.turn_on: output1
        - delay: 150ms
        - output.turn_off: output1
        - delay: 150ms
        - output.turn_on: output1
        - delay: 150ms
        - output.turn_off: output1
        - delay: 150ms
        - output.turn_on: output1
        - delay: 150ms
        - output.turn_off: output1
        - delay: 150ms
        - if:
            condition:
              light.is_on: light1
            then:
              - output.turn_on: output1
    - service: restart
      then:
        - switch.toggle: restart_my_esp

ota:

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO0
      mode: INPUT_PULLUP
      inverted: True
    name: "$u_name button"
    on_press:
      - light.toggle: light1

light:
  - platform: binary
    name: "$u_name"
    id: light1
    output: output1

output:
  - platform: gpio
    pin: GPIO12
    id: output1

status_led:
  pin:
    number: GPIO13
    inverted: yes

sensor:
  - platform: wifi_signal
    name: "$u_name WiFi signal"
    update_interval: 60s

  - platform: uptime
    name: "$u_name uptime"

switch:
  - platform: restart
    id: restart_my_esp

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "$u_name IP"

Logs (if applicable):

[20:25:11][I][logger:170]: Log initialized
[20:25:11][C][ota:366]: There have been 0 suspected unsuccessful boot attempts.
[20:25:11][I][app:029]: Running through setup()...
[20:25:11][D][binary_sensor:034]: 'Heinz button': Sending initial state OFF
[20:25:11][C][light:097]: Setting up light 'Heinz'...
[20:25:11][D][light:265]: 'Heinz' Setting:
[20:25:11][C][wifi:033]: Setting up WiFi...
[20:25:11][D][wifi:324]: Starting scan...
[20:25:17][D][wifi:339]: Found networks:
[20:25:17][I][wifi:385]: - 'MY SSID' (MY BSSID) ▂▄▆█
[20:25:17][D][wifi:386]:     Channel: 1
[20:25:17][D][wifi:387]:     RSSI: -60 dB

--24 more networks--

[20:25:17][I][wifi:194]: WiFi Connecting to 'MY SSID'...
[20:25:20][W][wifi_esp8266:444]: Event: Disconnected ssid='MY SSID' bssid=MY BSSID reason='Association Expired'
[20:25:20][W][wifi:485]: Error while connecting to network.
[20:25:20][W][wifi:522]: Restarting WiFi adapter...
[20:25:20][I][wifi:194]: WiFi Connecting to 'MY SSID'...
[20:25:26][W][wifi_esp8266:441]: Event: Disconnected ssid='MY SSID' reason='Probe Request Unsuccessful'
[20:25:26][W][wifi:485]: Error while connecting to network.
[20:25:26][W][wifi:522]: Restarting WiFi adapter...
[20:25:11][D][wifi:324]: Starting scan...
[20:25:17][D][wifi:339]: Found networks:
[20:25:17][I][wifi:385]: - 'MY SSID' (MY BSSID) ▂▄▆█
[20:25:17][D][wifi:386]:     Channel: 1
[20:25:17][D][wifi:387]:     RSSI: -60 dB

--more networks again--

[20:25:20][I][wifi:194]: WiFi Connecting to 'MY SSID'...
[20:25:26][W][wifi_esp8266:441]: Event: Disconnected ssid='MY SSID' reason='Probe Request Unsuccessful'
[20:25:26][W][wifi:485]: Error while connecting to network.
[20:25:20][W][wifi:522]: Restarting WiFi adapter...
[20:25:20][I][wifi:194]: WiFi Connecting to 'MY SSID'...
[20:25:26][W][wifi_esp8266:441]: Event: Disconnected ssid='MY SSID' reason='Probe Request Unsuccessful'
[20:25:26][W][wifi:485]: Error while connecting to network.
[20:25:26][W][wifi:522]: Restarting WiFi adapter...
[20:25:11][D][wifi:324]: Starting scan...
[20:25:17][D][wifi:339]: Found networks:

--rinse and repeat--

Additional information and things you've tried:

[harmptor]

Nope, it even breaks without the restart switch. I'm clueless. All I know is that the entire YAML should work but doesnt.

[gb53smith]

You may not have enough eeprom memory on your ESP8266 module. I notice you are using esp01_1m. Does that mean 1 MB eeprom? OTA has a large memory cost. Can you try a 4MB module like a NodeMCU?

[harmptor]

I'm using a Sonoff Basic so yeah, might be 1MB only. It did work fine before tho with OTA. That was on 1.17 or older tho. Also, the problem also happens when flashing over serial instead of OTA, if that makes a difference.

[gb53smith]

OTA uses more memory on the module than upload over USB so that explains your issue.

[harmptor]

No, please reread.

[gb53smith]

When you compile how many bytes do you get?

[harmptor]

Flash: [==== ] 38.5% (used 394484 bytes from 1023984 bytes)

[gb53smith]

Your esphome: section looks different than this documentation: https://esphome.io/devices/sonoff_basic.html

[Fusseldieb]

The Sonoff Basic doesn't use an ESP8266, but an ESP8285!

Like @gb53smith mentioned, change your esphome section to the code below and it'll probably work.

esphome:
  name: <NAME_OF_NODE>
  platform: ESP8266
  board: esp8285

Let us know so we can close this issue :)

[harmptor]

The docs say

The Sonoff Basic is based on the ESP8266 platform and is a subtype of the esp01_1m board.

so I assumed this

  name: $l_name
  platform: ESP8266
  board: esp01_1m

should work, since that's also what the wizard put there when I selected generic sonoff. Anyway, I'm going to try esp8285 and report back.

[Fusseldieb]

According to https://docs.platformio.org/en/latest/boards/espressif8266/esp01_1m.html the esp01_1m is meant for an ESP8266 device. Sonoff Basic's are ESP8285 devices.

[harmptor]

https://esphome.io/devices/sonoff_basic.html reads

The Sonoff Basic is based on the ESP8266 platform and is a subtype of the esp01_1m board.

[Fusseldieb]

https://esphome.io/devices/sonoff_basic.html reads

The Sonoff Basic is based on the ESP8266 platform and is a subtype of the esp01_1m board.

Reads platform, not board. But yea, it's confusing. Also, depending on the version of the Sonoff Basic there are even more chip types. But I think with the esp8285 you might have luck.

Try it and report back!

[harmptor]

I reflashed and the only thing I changed was esphome: to conform with https://esphome.io/devices/sonoff_basic.html. That seems to have made it worse, it won't connect to wifi anymore. I have to screw open the sonoff once again to check logs and reflash over serial. Will report back, but its safe to say that the issue isn't caused by esphome:.

Edit: removing arduino_version: 2.4.2 makes it connect to wifi again. To test whether that fixed the initial issue, I enabled more components (ip address sensor, wifi signal sensor, uptime sensor) which made the node not find any wifi networks at all. I tested both OTA and serial flashes, no difference.

[gb53smith]

Changing the board type would require you to serial flash again since the flash memory partitioning has to change. I don`t think removing the arduino_version: is a good idea. How about removing the ota: and use serial flash? That will give you twice the flash memory for the sketch. Also, while you have the Sonoff case open, see if you can read ESP8285 on the ESP chip.

[harmptor]

Okay, the first update I sent was over OTA, my bad. Thank you, I didn't know. After that I had to reflash multiple times, most of them where over serial and I never changed anything besides arduino_version, so I should be good on that. Removing arduino_version (which renders it to the default recommended value fyi) did help the issue though. I tested it back and forth twice to be sure. It just wouldn't work on 2.4.2. I didn't see it logging ESP8285, but I spotted ESP8266EX somewhere. Yes, removing OTA (or any other component) works around the issue, as stated previously and in the initial issue description. The size of the binary also doesn't exceed the limit at all, if I read the numbers correctly. I also said that already.

@gb53smith I appreciate you trying to help, but please read carefully. I know times can be tough and busy, but poking around in the dark instead of reading what's already there is unnecessary.

[gb53smith]

I tried your yaml code example (with all features) using a Wemos D1 Mini board that I got today. It is a ESP8266 with 4MB of flash. It works well, even with OTA uploads. Here is proof: (I connected a switch to GPIO0 and found that flashing over USB did not work if GPIO0 was at GND.) If you can get all your features working without using OTA, you should be happy. It is not an issue with the Esphome code but rather a problem with your board`s flash memory size or the compiler settings.
Your issue is not due to a combination of components but only the OTA feature. As you know, OTA approximately halves the maximum size of the sketch code. The complier does not measure the available flash size so it is incorrect when OTA is used.

[gb53smith]

I have created a "Real Flash Size" Sensor using a custom component. It reads from the board and is not a compiler assumption. I got 4,194,304 bytes. I also discovered that GPIO0 is a poor pin for a generic switch input. The board won't connect to WiFi if the switch connects GPIO0 to GND on power up.
Here is my code. Hopefully, that will help close this issue.

esphome:
  name: sonoffbasic
  platform: ESP8266
  #board: esp8285
  #arduino_version: 2.4.2
  board: d1_mini
  includes:
    - flashsize.h

wifi:
  ssid: "GreenMountain"
  password: !secret wifi_password

# Enable logging
logger:
  level: DEBUG
  esp8266_store_log_strings_in_flash: False

ota:
  password: !secret ota_password

substitutions:
  l_name: heinz
  u_name: Heinz

# Enable Home Assistant API
api:
  password: !secret ota_password
  services:
    - service: flash
      then:
        - output.turn_on: output1
        - delay: 150ms
        - output.turn_off: output1
        - delay: 150ms
        - output.turn_on: output1
        - delay: 150ms
        - output.turn_off: output1
        - delay: 150ms
        - output.turn_on: output1
        - delay: 150ms
        - output.turn_off: output1
        - delay: 150ms
        - if:
            condition:
              light.is_on: light1
            then:
              - output.turn_on: output1
    - service: restart
      then:
        - switch.toggle: restart_my_esp

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO0
      mode: INPUT_PULLUP
      inverted: True
    name: "Heinz button"
    on_press:
      - light.toggle: light1

light:
  - platform: binary
    name: "$u_name"
    id: light1
    output: output1

output:
  - platform: gpio
    pin: D6
    inverted: True
    id: output1

status_led:
  pin:
    number: GPIO2
    inverted: yes

sensor:
  - platform: wifi_signal
    name: "$u_name WiFi signal"
    update_interval: 60s

  - platform: uptime
    name: "$u_name uptime"

  - platform: custom
    lambda: |-
      auto flash = new MyFlash();
      App.register_component(flash);
      return {flash->flash_sensor};
    sensors:
    - name: "Real Flash Size"
      unit_of_measurement: bytes
      accuracy_decimals: 0

switch:
  - platform: restart
    id: restart_my_esp

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "$u_name IP"

The included flashsize.h

#include "esphome.h"

class MyFlash : public PollingComponent, public Sensor {
 public:
  Sensor *flash_sensor = new Sensor();

  // constructor.  Update interval set here to 60s
  MyFlash() : PollingComponent(60000) {}
  EspClass ESP;

  float get_setup_priority() const override { return esphome::setup_priority::DATA; }

  void setup() override {
    // This will be called by App.setup()  
  }
  void update() override {
    // This will be called every "update_interval" milliseconds.
    float flashsize = float(ESP.getFlashChipRealSize());
    flash_sensor->publish_state(flashsize);
    ESP_LOGD("custom", "The flash size is: %f", flashsize);
  }
};

[probot-esphome[bot]]

wifi source wifi issues wifi recent changes _{^{(message by IssueLinks)}}

[harmptor]

Thanks for the code, @gb53smith. I set up the custom sensor and got 1,048,576 bytes, as you predicted. Now, I'm by far no expert as you can tell, but in my head and with my math, that chip should be able to fit the binary of 394,484 bytes more than twice, with overhead. Again, I could be missing something here.  

Regarding this:

Your issue is not due to a combination of components but only the OTA feature.

I don't see how this could be true, as I'm currently using the stripped down binary with OTA, without any issues. The issue arises when I add only two components. For example, adding these two will cause the issue.

sensor:
  - platform: wifi_signal
    name: "$u_name WiFi signal"
    update_interval: 60s

  - platform: uptime
    name: "$u_name uptime"

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "$u_name IP"

The difference in size between these two binaries is a whopping 9948 bytes. (385,844 vs 395,792) 385,844 byte binary works. 395,792 byte binary doesn't work. The total available flash size is 1,048,576 bytes. Half of that is 524,288. 524,288 > 395,792. There's more than a kilobyte of headroom. For both binaries. I do not think the size is the breaking factor.     Eventually, of course one could say "if you're having an issue with component xyz, just don't use it". This is what I am doing right now. I currently don't use these three sensors, because I prefer being able to flash new firmware without uninstalling the Sonoff from its location, screwing it open and redo the mains wiring with the flimsy terminals. However, I don't think that's the proper way to handle an issue.

[harmptor]

Also, I just flashed another Sonoff Basic with a binary of 434,324 bytes. Works fine. YAML https://pastebin.com/r4kXZRT9

[gb53smith]

If another Sonoff Basic board works with 434,324 bytes you will finally have to agree that this issue was not an Esphome software bug. I once worked in the Flash Product Group at Intel so I learned a little about flash memories. Flash chips have extra blocks of memory arrays that can be swapped using non-volatile switches to bypass a bad block. It is possible that Sonoff is using factory seconds flash chips with only enough memory left for their application. Sonoff is not obliged to provide the full 1Mb for other applications.

The "fun" thing about the IOT hobby is that an issue may be caused by a software bug, hardware defect or combination. In this case the hardware was defective, not suited for purpose.

[gb53smith]

The difference in size between these two binaries is a whopping 9948 bytes. (385,844 vs 395,792) 385,844 byte binary works 395,792 byte binary doesn't work. Here is some interesting binary math: The 4 MSB of 385,844 bytes is '1011' (a18,a17,a16,a15 address bits) The 4 MSB of 395,792 bytes is '1100' If the address bit, a17, in the flash chip was stuck at 0 your available sketch size would be reduced to 393,215. It is a 1Mb memory so a19 would be used by OTA to switch between the current program and the new OTA downloaded program.

[harmptor]

What makes you always so sure you have the exact cause identified, pinned down and solved? I'd appreciate it if you changed your demeanor. I'm not arguing with you about who's right, and there's no shame in not having the final answer yet.

If what you're saying is true, then the Heinz code (395,792 bytes) should work on the Gustav node, which managed the 434,324 bytes, ye? It doesn't.

[gb53smith]

For a greater understanding of boards and flash memory partitions here are the details for PlatformIO and Arduino: Board Manifests Flash Memory partitionshttps://github.com/esp8266/Arduino/tree/master/tools/sdk/ld For example the sonoff_basic.json and esp01_1m.json refers to a eagle.flash.1m256.ld flash partition which would give a sketch size of 761840 bytes. I tried a similar sketch on my Platform IDE with a esp01_1m board and it reported a maximum size of 761840 bytes. So there may be a complier setup issue. On the other hand, you are not using the Esphome recommended board. If their recommendation does not work submit another issue about the Sonoff basic board support.

I went back to beginning and tested the Heinz code here. I even used the esp01_1m board and it still worked. Make your changes on the lines marked #GBS and try again.

I did get this error on the first USB download but it went away on the second USB download.

Building /data/heinz/.pioenvs/heinz/firmware.bin
RAM:   [====      ]  43.9% (used 35944 bytes from 81920 bytes)
Flash: [====      ]  37.9% (used 395732 bytes from 1044464 bytes)
Creating BIN file "/data/heinz/.pioenvs/heinz/firmware.bin" using "/root/.platformio/packages/framework-arduinoespressif8266/bootloaders/eboot/eboot.elf" and "/data/heinz/.pioenvs/heinz/firmware.elf"
======================== [SUCCESS] Took 146.62 seconds ========================
INFO Successfully compiled program.
INFO Resolving IP address of heinz.local
ERROR Error resolving IP address of heinz.local. Is it connected to WiFi?
ERROR (If this error persists, please set a static IP address: https://esphome.io/components/wifi.html#manual-ips)
ERROR Error resolving IP address: Error resolving address with mDNS: Did not respond. Maybe the device is offline., [Errno -5] No address associated with hostname

Also, try cycling the power between downloads. OTA downloads worked too.

I have also included the source code created by the ESPhome tool here in tar format. If there is any difference in tool setup it will show up it in the source code. From there is is up to the PlatformIO compiler. This test was done using ESPhome 1.19.1 but Heinz code also worked in 1.18 This comparison should exhaust the possibility of a ESPhome software bug.

[harmptor]

You know I'm not an expert, so what I understood from that comment was this:

I'm not using the recommended board.

Yes, that may be correct.

You tested the Heinz code and it worked on a esp01_1m board, so I should just try again.

I did, and the issue persisted. Yes, even through multiple power cycles.

You published your source code, so I'm assuming I should somehow compare your source code to mine.

I wouldn't know what differences should be looking for, but I'm happy to provide the source code to you if you want to compare them.

[gb53smith]

Please check the Heinz Source code on my github link above. It should be identical to yours except for the WiFi credentials and the the GPIO number used for the push button. This is the assumed test case that I have tested twice and found working on a WEMOS D1 mini board. This is my main evidence that this issue is board and not code dependent.

Use this command to tar the source files:

tar cvf heinz.tar heinz

and post a link to it. I will use:

diff -qrN dir1/ dir2

to compare the Esphome source code trees. Or you could use:

tar xvf heinz.tar

to create my source code tree at your end for you to compare. (use a temporary directory)

Other thoughts

1. Did you see a ESP8285 label on the ESP chip when you opened up the Sonoff Basic enclosure?
2. I find it strange that the larger Gustav code should work over OTA. To prove the OTA worked you need to make small change you can recognize. For the Heinz code I changed a delay in the flash service to 1500 ms so that the LED would blink differently.
3. I found two issues with the ESPHome suggested board settings. First the compiler complains that the version of the platform dependences (toolkit) are not specified. This happens only on the first compile. Second as discussed above the memory partition specified in sonoff_basic.json is not used. If it was used you would see a maximum sketch size of 761840 bytes

[harmptor]

It works over OTA! I've used OTA updates all the time to upload new firmware with different settings many, many times. It does work. I also double checked just now. You might just have to believe me, thats it.

I find it strange that the larger Gustav code should work over OTA.

You might find it strange, but it is proof that 420+kb cannot be the sole issue.

[gb53smith]

So how did you distinguish between the two OTA installs. I saw nothing in the Gustav code that you could use. Try adding a LED flash service. You could be still using the last USB install.

[harmptor]

Please. Read.

[...] new firmware with different settings [...]

Since I got the Gustav Sonoff four years ago, I opened it up once to install tasmota and never opened it up again to this day and installed (as I said already) many many different configurations over the years. Just like one hour ago. If you require to know exactly what I changed to make sure I'm not lying to you: I changed line 73 to expose the LED to HA.

Can we PLEASE move on from this now? People told me I should create an issue on here, so I did. If I knew it would go like this...

[harmptor]

Thanks for your instructions on the extraction part. I had a quick look and it looks like my main.cpp is a little cooked. You can have a look at it yourself here. I checked a few other files but they seem to be common resources since their content look pretty generic.

Edit: nevermind, its just a few commented lines that seem off.

[gb53smith]

The only difference is that you can see my WiFi password. From here the files sent to the platformIO compiler using platformio.ini to setup the compiler. So if one board works and another doesn't it is an error in platformio.ini. The right compiler options are supposed to take care of board differences. I look forward to a new issue submission regarding ESP8285 board support. I see that there a several issues related to esp01_1m boards. Good Luck with your new issue.

[harmptor]

Maybe there is something wrong with my compiler. Couldn't you compile Heinz.yaml and send me the binary? Seeing if that makes a difference would reveal a lot I think.

[gb53smith]

Here is heinz.bin You will have to change the Wifi credentials, see in my main.cpp. I changed the binary_sensor to use GPIO0 like your original Heinz code. Seems that my WEMOS D1 Mini board is compatible with the esp01_1m board. There is no guarantee that the ESP8285 in the Sonoff Basic is compatible with the esp01_1m board. Why would ESPHome recommend/specify other compiler options, like an older version of platformio/espressif8266 ?

[harmptor]

So I just found something really interesting: When I have

wifi: 
  networks:
  - ssid: Mary Poppins
    password: supercalifragilisticexpialidocious

everything is cool. When I add a second network

wifi: 
  networks:
  - ssid: Mary Poppins
    password: supercalifragilisticexpialidocious
  - ssid: !secret defaultrouter_ssid
    password: !secret defaultrouter_pass

the issue pops back up. To be precise, it goes

[23:51:58][C][wifi:037]: Setting up WiFi...
[23:51:58][D][wifi:365]: Starting scan...
[23:52:04][D][wifi:380]: Found networks:
[23:52:04][D][wifi:382]:   No network found!
[23:52:09][D][wifi:365]: Starting scan...
[23:52:15][D][wifi:380]: Found networks:
[23:52:15][D][wifi:382]:   No network found!
[23:52:20][D][wifi:365]: Starting scan...
[23:52:26][D][wifi:380]: Found networks:
[23:52:26][D][wifi:382]:   No network found!
...

This is of course using the yaml with the two text sensors etc. I will investigate further lol

[harmptor]

Thanks for the binary. Wdym change wifi? I can't edit a binary file lol. Did you change it from mary poppins? I just set up that wifi for testing.

I just realized, you probably didn't use the yaml I linked. Use that and it'll be alright. Ah, I see, I could set up your Wifi network.

Or even better, could you compile Gustav.yaml instead? Sorry for the confusion I caused.

[gb53smith]

OK send me your Wifi credientials and I can recompile for you. Otherwise change your router settings for the test.

Just an aside. I don't why you have this in your gustav.yaml code:

  ap:
    ssid: "${u_name} Fallback"
    password: "password"

captive_portal:

It is a overhead for a feature that you probably won't use. It creates an access point so you could connect directly from an App on your smartphone and not go through Home Assistant. In my opinion EspHome should not include this in the default template.

[harmptor]

Yes, this Gustav.yaml would be perfect.

As for the fallback hotspot, I had this on the original gustav yaml because the sonoff is on an extension cord and I wanted to use it outside where there's no wifi and I still wanted to control it via the webserver:. I also don't think this is in the default template if I'm not mistaken.

[gb53smith]

Here is gustav.bin Good Luck. When I generated the gustav node, ap: was there in the template.

[harmptor]

Thanks for the binary. I tried it and it gives

[23:52:04][D][wifi:380]: Found networks:
[23:52:04][D][wifi:382]:   No network found!
[23:52:09][D][wifi:365]: Starting scan...
[23:52:15][D][wifi:380]: Found networks:
[23:52:15][D][wifi:382]:   No network found!
[23:52:20][D][wifi:365]: Starting scan...
[23:52:26][D][wifi:380]: Found networks:
[23:52:26][D][wifi:382]:   No network found!
...

Is that exactly Gustav.yaml or some other gustav yaml I sent the other day?

Oh okay, well I don't know either. I guess it's there by default in case the user messes up the wifi credentials so he has an easy way back? I don't know.

[gb53smith]

gustav.yaml was copied from from your github link provided in the "Yes, this Gustav.yaml would be perfect." section. Here are the compiler logs if that helps:

Processing gustav (board: esp01_1m; framework: arduino; platform: platformio/espressif8266@2.6.2)
--------------------------------------------------------------------------------
HARDWARE: ESP8266 80MHz, 80KB RAM, 1MB Flash
PACKAGES: 
 - framework-arduinoespressif8266 3.20704.0 (2.7.4) 
 - tool-esptool 1.413.0 (4.13) 
 - tool-esptoolpy 1.20800.0 (2.8.0) 
 - toolchain-xtensa 2.40802.200502 (4.8.2)
Library Manager: Installing Update
Library Manager: Already installed, built-in library
Dependency Graph
|-- <ESPAsyncTCP-esphome> 1.2.3
|   |-- <ESP8266WiFi> 1.0
|-- <ESP8266WiFi> 1.0
|-- <ESP8266mDNS> 1.2
|   |-- <ESP8266WiFi> 1.0
Retrieving maximum program size /data/gustav/.pioenvs/gustav/firmware.elf
Checking size /data/gustav/.pioenvs/gustav/firmware.elf
RAM:   [====      ]  43.9% (used 35964 bytes from 81920 bytes)
Flash: [====      ]  38.6% (used 395616 bytes from 1023984 bytes)
========================= [SUCCESS] Took 12.00 seconds =========================

All the version numbers should match since they are or should be specified in the platformio.ini file which matches. That is one thing I like about Platformio is that you can pin down the versions of all the project dependencies.

[harmptor]

Yes that's perfect, thank you. So it seems like my esphome installation isn't causing the issue. I'll try some things with this approach. Yes, all the versions match mine. The only difference is that I get a warning Warning! Could not find the package with 'Update' requirements for your system 'linux_x86_64' but that doesn't make a difference apparently.

[harmptor]

Alright, I think I hit a spot. Idk how to proceed from here on though.

This yaml works:

wifi: 
  networks:
  - ssid: Mary Poppins
    password: supercalifragilisticexpialidocious
  - ssid: Mary Poppins
    password: supercalifragilisticexpialidocious

However, slightly modifying one SSID like this messes everything up:

wifi: 
  networks:
  - ssid: Mary Poppins
    password: supercalifragilisticexpialidocious
  - ssid: Mary
    password: supercalifragilisticexpialidocious

Full yaml: pastebin     I suspected that if a network is an exact duplicate, it's merged into just one network inside main.cpp, so I checked... Turns out it isn't. There are two identical networks defined: main.cpp:

  wifi_wificomponent = new wifi::WiFiComponent();
  wifi_wificomponent->set_use_address("gustav.local");
  wifi::WiFiAP wifi_wifiap = wifi::WiFiAP();
  wifi_wifiap.set_ssid("Mary Poppins");
  wifi_wifiap.set_password("supercalifragilisticexpialidocious");
  wifi_wifiap.set_priority(0.0f);
  wifi_wificomponent->add_sta(wifi_wifiap);
  wifi::WiFiAP wifi_wifiap_2 = wifi::WiFiAP();
  wifi_wifiap_2.set_ssid("Mary Poppins");
  wifi_wifiap_2.set_password("supercalifragilisticexpialidocious");
  wifi_wifiap_2.set_priority(0.0f);
  wifi_wificomponent->add_sta(wifi_wifiap_2);
  wifi_wificomponent->set_reboot_timeout(900000);
  wifi_wificomponent->set_power_save_mode(wifi::WIFI_POWER_SAVE_NONE);
  wifi_wificomponent->set_fast_connect(false);
  wifi_wificomponent->set_output_power(20.0f);
  App.register_component(wifi_wificomponent);

I don't understand what's wrong with having two different networks (+ having certain components), while two identical networks is fine. Remember, two different networks work just fine if I don't add these additional text sensors. Maybe the priorities are conflicting? I'm gonna try, but I think it's up to the people smarter than me to solve this.

[3ative]

This was not a problem in previous versions of ESPHome. In my OLED Thermostat project (D1 Mini) I started with powering both a DALLAS sensor and the OLED display and it was working fine until ESPHome got an update - around v1.18.xx. 😢 As a work-around I delayed the powering of the DALLAS sensor on boot for about 20secs by using a GPIO pin allowing the Wi-Fi component to 'do its thing'. See here for how I did it: https://youtu.be/RorDXsYIrnQ

[andriej]

Encountered this on one of my sonoffs. It was "down" since half of year (1.15), I've reflashed it and put newest 1.19.4 on - still "Probe request" and was not able to login to WiFi. I've found one of issues regarding removing "captive portal" - did that, removed one line, reflashed and it works like a charm.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[itanczos]

Unfortunately, this problem still exists! Moreover, even more since version 2021.10.x!

[arko36]

take a look at https://github.com/esphome/issues/issues/2912