Serious WiFi issue ESPURNA Version 1.13.4

[AlbertWeterings]

After updating my device to 1.13.4 I found multiple device not coming online anymore. Debug via serial is not giving me any information. Devices that come online after the update do not have their web interface reachable after some time, they keep responding to MQTT commands OTA from Arduino IDE is not possible anymore.

Devices that come back online after updating do not come back online after a power cycle.

On SonOff-basic after double pressing the button, serial debug says there will be a access point created but no access point comes online and if there comes one it drops out after a few seconds.

I flashed 1.13.3 in it and the device starts working again as it shout.
I flashed a later dev version and still WiFi is working correct.

I am using:
ESP8266 core 2.4.2 in all versions
Library JustWifi https://github.com/xoseperez/justwifi#2.0.2 in all versions

[mcspr]

Thanks!

Can reproduce with both pre-built and 2.4.2. AP mode behaves erratically.
@AlbertWeterings for now, you can revert 31195ba locally. Not really sure what's halting WiFi operation. And I think it also affects connection, as the Basic I have sometimes cannot connect at all.

[jnogues]

I have the same problem.
Sonoff Basic flashed with *.bin file in the repositiry. Test with differents ssid and never connects.

[AlbertWeterings]

If you go back to this state it is working all normal as @mcspr noted.
https://github.com/xoseperez/espurna/tree/31195ba3b62ff886313d0369baf4b6ab1a07187b

[biddster]

Confirming wifi issues with 1.13.4.

Sonoff RF updated via the web interface. Refused to connect to my home network and falling back to AP mode. If I connect to the AP, I'm unable to get to the web interface via either of the local addresses.

I long pressed the toggle button to reset and can see that the reset is successful. The AP is ESPURNA-xxxxxx. If I connect to that AP using the default creds, I'm still unable to get to the web interface via the local address.

I'll pop it out this evening and re-flash to see what happens.

[mcspr]

@AlbertWeterings what I meant is reverting to the state before that commit helped. i.e. 64b5155, where there is still delay(10) at the end of the loop() (which removal with the default builds seemingly broke things)

edit: formatting
Some observations using Core 2.4.2:

• WIFI_NONE_SLEEP etc. are enums and not preprocessor defines, and always equal 0 in preprocessor context.
• With default settings WIFI_SLEEP_MODE == WIFI_NONE_SLEEP, Basic connects / works as AP when CPU speed is set to 160MHz. platformio.ini env must have board_build.f_cpu = 160000000L, IDE has menu setting.
• Changing sleep mode to WIFI_MODEM_SLEEP does help too (note that delay() does not get included, because preprocessor statements are always false!) false alarm, cannot reproduce anymore.

So, what I think needs to happen is to replace preprocessor checks of sleep mode with runtime setting like wifiSleep to allow changing it at runtime, so loopDelay can always be changed.
And maybe it is worth setting sleep mode to MODEM again. I do not remember why exactly it was set to NONE.

[xoseperez]

I'm not noticing connectivity issues with my testing board and pre-built binaries, not with 2.4.2 binaries either. But I have seen the upgrade from web UI process fails most of the times... not sure yet if this could be related to the delay thing...

[mcspr]

I had similar results on testing boards. Basic is behaving differently for some reason. Bad power? Badly drawn antenna?

[xoseperez]

Basic has always had connectivity issues. I have even thought about stop supporting it (not really).

[mcspr]

Web OTA likely fails because of progress messages sent via websocket get pinged back every time (websock.send({})). Delay may help there, but they can be safely removed. Progress is already tracked client-side. Or replace generic debug function with DEBUG_PORT.printf_P(...)

edit: HTTP upgrade using curl works perfectly fine, so WebUI weblog pingback is the reason.