BUG: LEDSTRIP project doesn't allow WiFi credentials to be set via Improv

[rbergen]

Bug report

Problem

The LEDSTRIP project demands WiFi to be connected (WAIT_FOR_WIFI is defined as 1), and bails out by rebooting if it isn't. This is handled by lines 629 to 637 in main.cpp.
If no WiFi credentials are available at boot, the code in lines 224 to 228 in network.cpp immediately gives up on WiFi connectivity, leading to the device rebooting very early in the boot process.

Although this makes sense if the project is flashed using a method that requires WiFi credentials to be set in secrets.h, it creates a problem if the project is flashed using the web installer, Part of that workflow is the setting of WiFi credentials using Improv. For the LEDSTRIP project that's impossible because the device is stuck in a boot loop by the time the user has a chance to enter their WiFi credentials.

Solution

If WAIT_FOR_WIFI is set to 1, the device should allow enough time for the user to enter WiFi credentials.

Note

This problem was first reported in issue #367. I'm opening this specific issue at @davepl's request.

[robertlipe]

I've admittedly not used this specific build (I'm heads-down on HUB75 right now) but why does this build uniquely _require_ WiFi at all? The rest of the projects would just boot and run their inbuilt effects. I just confirm that I can disable networking completely on my build and and they run. Is the question (or should it be) "why does this build uniquely _require_ networking" instead of "why does it do a silly thing if it cannot acquire a DHCP grant?" Consider someone developing/building a LED fixture in the lab where WiFi is plentiful and then taking it to someplace without WiFi or where security doesn't allow them on. Isn't it better to to just keep trucking with the programmed effects than to bomb out totally? Tangibly, what happens if you just delete the throw()? You might opt to disable networking completely or retry again every N minutes or something... Would it be better to emit some kind of telemetry on the LEDs (proposal: blinking red and off - commonly associated with an error and rather google-able) instead of just crashing over and over with no hint to the user _why_. P.S. The permalink is bad. There is no 629 on the currently checked in main.cpp. A permalink should include a git branch tag + a line number in order to be permanent, such as this one for loop() https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/86418d267e8142ed7cb1e90e4d3059d69dba946d/src/main.cpp#L527. I suspect you're speaking of the code at https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/86418d267e8142ed7cb1e90e4d3059d69dba946d/src/main.cpp#L502

…

On Sat, Jul 22, 2023 at 4:36 AM Rutger van Bergen ***@***.***> wrote: Bug report Problem The LEDSTRIP project demands WiFi to be connected (WAIT_FOR_WIFI is defined as 1), and bails out by rebooting if it isn't. This is handled by [lines 629 to 637 in main.cpp[( https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/main/src/main.cpp#L629-L637 ). If no WiFi credentials are available at boot, the code in lines 224 to 228 in network.cpp <https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/main/src/network.cpp#L224-L228> immediately gives up on WiFi connectivity, leading to the device to reboot very early in the boot process. Although this makes sense if the project is flashed using a method that requires WiFi credentials to be set in secrets.h, it creates a problem if the project is flashed using the web installer, Part of that workflow is the setting of WiFi credentials using Improv. For the LEDSTRIP project that's impossible because the device is stuck in a boot loop by the time the user has a chance to enter their WiFi credentials. Solution If WAIT_FOR_WIFI is set to 1, the device should allow enough time for the user to enter WiFi credentials. Note This problem was first reported in issue #367 <#367>. I'm opening this specific issue at @davepl <https://github.com/davepl>'s request. — Reply to this email directly, view it on GitHub <#371>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD36L2JH3BSQQ45UINP3XRONLFANCNFSM6AAAAAA2TXIKPU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[davepl]

In deployment, a chip that comes up and fails to get wifi is useless and has to be manually reset. That’s why in the code it tries some reasonable number of times, like 10, and then reboots. It’s done this way because the majority of times, failure to get wifi is transient and can be fixed with a reboot. But if you just kept trying, it’d never work. I don’t want to get on too many ladders, so OTA updates and automatic resets are a passionate topic for me :-). I’ve got a lot of the LEDSTRIP project scattered around here! - Dave

…

On Jul 22, 2023, at 3:33 PM, Robert Lipe ***@***.***> wrote: I've admittedly not used this specific build (I'm heads-down on HUB75 right now) but why does this build uniquely _require_ WiFi at all? The rest of the projects would just boot and run their inbuilt effects. I just confirm that I can disable networking completely on my build and and they run. Is the question (or should it be) "why does this build uniquely _require_ networking" instead of "why does it do a silly thing if it cannot acquire a DHCP grant?" Consider someone developing/building a LED fixture in the lab where WiFi is plentiful and then taking it to someplace without WiFi or where security doesn't allow them on. Isn't it better to to just keep trucking with the programmed effects than to bomb out totally? Tangibly, what happens if you just delete the throw()? You might opt to disable networking completely or retry again every N minutes or something... Would it be better to emit some kind of telemetry on the LEDs (proposal: blinking red and off - commonly associated with an error and rather google-able) instead of just crashing over and over with no hint to the user _why_. P.S. The permalink is bad. There is no 629 on the currently checked in main.cpp. A permalink should include a git branch tag + a line number in order to be permanent, such as this one for loop() https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/86418d267e8142ed7cb1e90e4d3059d69dba946d/src/main.cpp#L527. I suspect you're speaking of the code at https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/86418d267e8142ed7cb1e90e4d3059d69dba946d/src/main.cpp#L502 On Sat, Jul 22, 2023 at 4:36 AM Rutger van Bergen ***@***.***> wrote: > Bug report Problem > > The LEDSTRIP project demands WiFi to be connected (WAIT_FOR_WIFI is > defined as 1), and bails out by rebooting if it isn't. This is handled by > [lines 629 to 637 in main.cpp[( > https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/main/src/main.cpp#L629-L637 > ). > If no WiFi credentials are available at boot, the code in lines 224 to > 228 in network.cpp > <https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/main/src/network.cpp#L224-L228> > immediately gives up on WiFi connectivity, leading to the device to reboot > very early in the boot process. > > Although this makes sense if the project is flashed using a method that > requires WiFi credentials to be set in secrets.h, it creates a problem if > the project is flashed using the web installer, Part of that workflow is > the setting of WiFi credentials using Improv. For the LEDSTRIP project > that's impossible because the device is stuck in a boot loop by the time > the user has a chance to enter their WiFi credentials. > Solution > > If WAIT_FOR_WIFI is set to 1, the device should allow enough time for the > user to enter WiFi credentials. > Note > > This problem was first reported in issue #367 > <#367>. I'm > opening this specific issue at @davepl <https://github.com/davepl>'s > request. > > — > Reply to this email directly, view it on GitHub > <#371>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCSD36L2JH3BSQQ45UINP3XRONLFANCNFSM6AAAAAA2TXIKPU> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > — Reply to this email directly, view it on GitHub <#371 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF3G7G5Y4VMZE5OT6DDXRRIM7ANCNFSM6AAAAAA2TXIKPU>. You are receiving this because you were mentioned.

[robertlipe]

OK, there's a bug that nobody wants to tackle. That seems the real bug, but I get those can be hard.

Why not let it blink out an error message OR just run the provided effects until it reboots? Then at least people will have a clue what's wrong and/or the benefit of it If that timeout is a minute, it would then at least work 55 seconds (mine takes ~5 seconds to boot) out of the first minute.

From a user perspective, working partially or working mostly seems preferable to being just dead. Imagine building a Halloween costume that works great in your home, but only silently boot loops when you're out of WiFi range. Maybe you build A Thing and now it silently fails when you get to Maker Faire. I DO hear your point about the ladder, but it seems better to work at least somewhat when you can.

If I need to put code where my mouth is, I'll try to implement a "works with no wifi" mode, including a decaying backoff timer on retries up to some max if that helps it run longer for that case. Little Josh may appreciate it.

FTR, I agree that a self-reboot on heap corruption or depletion IS right right action to take. I'm not against reboots in all cases.

[davepl]

But a blinking pattern would tell me: “Dave, this module won’t connect to WiFi this power cycle. Please climb a ladder to reset the chip.” That’s fine on the bench but not in production. If you can get a WiFi module into this state and then get it OUT without a reboot through successful backoff, that would be a better solution, and I encourage you to implement it. For now, my suspicion is that only a reboot will correct it. I don’t know enough about the internal wifi espressif code to know why, though! -Dave

…

On Jul 22, 2023, at 7:50 PM, Robert Lipe ***@***.***> wrote: OK, there's a bug that nobody wants to tackle. That seems the real bug, but I get those can be hard. Why not let it blink out an error message OR just run the provided effects until it reboots? Then at least people will have a clue what's wrong and/or the benefit of it If that timeout is a minute, it would then at least work 55 seconds (mine takes ~5 seconds to boot) out of the first minute. From a user perspective, working partially or working mostly seems preferable to being just dead. Imagine building a Halloween costume that works great in your home, but only silently boot loops when you're out of WiFi range. Maybe you build A Thing and now it silently fails when you get to Maker Faire. I DO hear your point about the ladder, but it seems better to work at least somewhat when you can. If I need to put code where my mouth is, I'll try to implement a "works with no wifi" mode, including a decaying backoff timer on retries up to some max if that helps it run longer for that case. Little Josh may appreciate it. FTR, I agree that a self-reboot on heap corruption or depletion IS right right action to take. I'm not against reboots in all cases. — Reply to this email directly, view it on GitHub <#371 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCFZOISV45QI7MV7RPXTXRSGRHANCNFSM6AAAAAA2TXIKPU>. You are receiving this because you were mentioned.

[robertlipe]

Apparently there was a bug in the IDF (That's the ESP32 platform SDK) part of the Arduino stuff that could result in parts not always getting a DHCP lease.

espressif/arduino-esp32#7068 (comment)

People have confirmed that updating IDF helped. I don't know what IDF this project is using or when the stuck DHCP's were observed, but it's possible that the fundamental problem might be behind us.

I get that's not totally the point of this report, but it may be worth investigating if intermittent DHCP jamups are actually being observed in the field.

[sdmtr]

The core problem as described in the bug report is that a reboot definitively cannot correct a situation in which wifi credentials haven't been supplied, which will always be the case when flashing LEDSTRIP from the web installer. There isn't enough time between the board booting and rebooting for the web installer to ask the user to supply credentials and then send them through to the board, so no matter what, anyone who tries to install LEDSTRIP from the web installer will never, ever be able to use their board, and they'll have no idea why unless they inspect the console output and put two and two together.

[rbergen]

I've opened #395 to fix this.