Can't set Wifi SSID/password for Panlee project

[Rx7man]

Followed all the instructions in flashing the ESP32-S3 dev kit (Panlee is the only project available for it it seems) and I'm not able to set my wifi SSID/password, no dialog comes up, I've reset the device, reloaded the browser, etc (Chrome) and no dice

Here's the console output

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3808,len:0x44c
load:0x403c9700,len:0xbe4
load:0x403cc700,len:0x2a68
entry 0x403c98d4
E (268) esp_core_dump_flash: No core dump partition found!
E (268) esp_core_dump_flash: No core dump partition found!
Replacing Idle Tasks with TaskManager...
(I) (PrintOutputHeader)(C1) NightDriverStrip
(I) 
(I) (PrintOutputHeader)(C1) ------------------------------------------------------------------------------------------------------------
(I) (PrintOutputHeader)(C1) M5STICKC: 0, USE_M5DISPLAY: 0, USE_OLED: 0, USE_TFTSPI: 1, USE_LCD: 0, USE_AUDIO: 0, ENABLE_REMOTE: 0
(I) (PrintOutputHeader)(C1) ESP32 PSRAM Init: OK
(I) (PrintOutputHeader)(C1) Version 40: Wifi SSID: "" - ESP32 Free Memory: 287632, PSRAM:2095055, PSRAM Free: 2094659
(I) (PrintOutputHeader)(C1) ESP32 Clock Freq : 240 MHz
(I) (setup)(C1) Startup!
(I) (setup)(C1) Starting DebugLoopTaskEntry
>> Launching Debug Thread.  Mem: 287632, LargestBlk: 262132, PSRAM Free: 2094659/2095055, >> Launching JSON Writer Thread.  Mem: 279064, LargestBlk: 262132, PSRAM Free: 2094623/2095039, (W) (DeviceConfig)(C1) DeviceConfig could not be loaded from JSON, using defaults
(W) (NotifyJSONWriterThread)(C1) >> Notifying JSON Writer Thread
(W) (setup)(C1) Starting ImprovSerial
(W) (ReadWiFiConfig)(C1) Retrieved SSID and Password from NVS: , ********
(W) (setup)(C1) Creating TFT Screen
[  1057][E][esp32-hal-gpio.c:102] __pinMode(): Invalid pin selected
E (793) gpio: gpio_set_level(226): GPIO output gpio_num error
[  1068][E][esp32-hal-gpio.c:102] __pinMode(): Invalid pin selected
E (805) gpio: gpio_set_level(226): GPIO output gpio_num error
E (816) gpio: gpio_set_level(226): GPIO output gpio_num error
E (837) gpio: gpio_set_level(226): GPIO output gpio_num error
(W) (InitializeHardware)(C1) Allocating LEDStripGFX for channel 0
(I) (AddLEDsToFastLED)(C1) Adding LEDs to FastLED...
(I) (AddLEDsToFastLED)(C1) Adding 1152 LEDs to pin 5 from channel 0 on FastLED.
(W) (SetupBufferManagers)(C1) Reserving 312 LED buffers for a total of 1088256 bytes...
(W) (InitEffectsManager)(C1) InitEffectsManager...
(I) (InitEffectsManager)(C1) Creating EffectManager using default effects
>> Launching Drawing Thread.  Mem: 265900, LargestBlk: 249844, PSRAM Free: 986607/2084863, (W) (DrawLoopTaskEntry)(C1) >> DrawLoopTaskEntry
(W) 
(W) (DrawLoopTaskEntry)(C1) Entering main draw loop!
>> Launching Screen Thread.  Mem: 261428, LargestBlk: 245748, PSRAM Free: 986607/2084863, (I) (setup)(C1) Calling ConnectToWifi()
(I) 
(I) (ConnectToWiFi)(C1) Setting host name to NightDriverStrip...WL_NO_SHIELD
(W) (ConnectToWiFi)(C1) WiFi credentials not set, cannot connect.
(W) (ConnectToWiFi)(C1) Waiting for WiFi credentials to be set...
(W) (ConnectToWiFi)(C1) WiFi credentials not set, cannot connect.
(W) (ConnectToWiFi)(C1) Waiting for WiFi credentials to be set...
(W) (ConnectToWiFi)(C1) WiFi credentials not set, cannot connect.
(W) (ConnectToWiFi)(C1) Waiting for WiFi credentials to be set...
(W) (ConnectToWiFi)(C1) WiFi credentials not set, cannot connect.
(W) (ConnectToWiFi)(C1) Waiting for WiFi credentials to be set...

On a side note, if you have the text size increased in your browser you can't see the whole page and there are no scroll bars.. I got that figured out pretty quick though

[dosipod]

Not sure why all the MCUs ( all normal esp32 ) i have do not work with https://plummerssoftwarellc.github.io/NightDriverStrip/ but works fine with web installer of Tasmota , wled ,openmqttgateway and ESPEasy . So this is general issue to web flashing . I was able to run the project on the same MCUs only by compiling and hard coding the SSID and pass .

And not sure of the change of the post subject as it seems the demo and ledstrip project also do not flash correctly from site

[robertlipe]

The default build for DEMO does not configure in networking. See https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/5a78b33ae34c59d36f085b71336acc77cc5e714a/include/globals.h#L255. I think it would not therefore prompt for WiFi credentials. (If it does, they won't be used...)

The default build for LEDSTRIP does. https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/5a78b33ae34c59d36f085b71336acc77cc5e714a/include/globals.h#L714

Panlee, the subject of this bugreport, is known to have issues with the online installer; that's what Rutger has spent weeks chasing and is in the late stages of submitting a fix for.

You've tossed a whole lot of broad variables into this mix, a thread that's already identified one issue and has a fix in progress. Because of that bug, I wouldn't expect PANLEE or LEDSTRIP to work when installed from binaries from the web; they'll just hang. I wouldn't expect DEMO to prompt for network credentials, but I DO expect it to work. If that's not the case, please open a new reports with particulars. If you're building locally and baking passwords into include/secrets, you should be immune from the titular bug. Of course, if you're building locally and want to turn on networking for DEMO, you can change the ENABLE_WIFI in the linked line and have network on DEMO.

If you haven't followed the bugreport here so far, we use https://www.improv-wifi.com/serial/ (I think ESPHOME does, too. I know WLED does not. You can chase the others down if you care.) but the problem being fixed isn't in the library, it's in the integration into this project. I would therefore not expect failure or success with other software packages to be an indication of the bug being chased here. Because this bug is in the handoff between the "download and configure" step that's unique to Improv + NDL, building locally with the passwords preconfigured will also bypass the improv serial code path, so that won't trigger it, either.

The title change just describes the trigger of the bug more precisely. The bug is unique to configurations that set WAIT_FOR_WIFI and WAIT_FOR_WIFI and PANLEE is the most common such configuration. It's common for refinements in a bug's description to change as our (developers) understanding of the triggers become more clear.

With this explanation, are you seeing something not work that we expect to work? If so, that's a new and different bug. If DEMO is actually failing in some way, please open a new report. Include output of the serial console if it's crashing/rebooting or hanging or otherwise being naughty. An unclear and custom configuration that wasn't adequately described was why several of us looked at this issue and couldn't reproduce it. Details matter.

Edit: this is actually twofold. There was a problem with the ESP32-S3, which Rutger already fixed. The remaining problem is in the WAIT_FOR_WIFI case. OP's original problem was because he was running a custom configuration that used the ESP32-S3 configuration. Once THAT was fixed, the PANLEE issue came into focus.

[rbergen]

@dosipod I think @robertlipe has done a great job explaining the reason for the title change with context, and as the guy making the change I can confirm that:

• The change reflects that the report concerns a specific issue (inability to configure WiFi credentials) on a specific project (Panlee), on a specific device (ESP32-S3). The latter part we get for free and don't have to mention because that's the device Panlee is configured for. The issue was confirmed locally by me, and then confirmed fixed by me as well after applying the fix that is the primary content of PR #469.
• Builds that do not have WiFi enabled will not offer the facility to configure WiFi credentials via the web UI; the Improv protocol loop is not executed on those builds (as per this section in the main program loop) because there is no point in doing so.
• If you or anyone else experience other issues than the one this one is now addressing, then a new bug report Issue is the way to let us know. And yes, details of exactly what does and does not happen, including captures of logging via serial if available will then be extremely helpful.

[dosipod]

Forget the fact that we can install on the same MCUs from other sites . I can also open a new issue as the aim is to help improve things and not just point out the site is not working ( which is unfortunately the case ) . The important thing is if you do not see issues in flashing via site then that is more then enough for me . I do also have s3 but only one and not sure it would be best to report an issue if I can not replicate on multiple MCUs . If there is anything you would need from normal esp32 flashing logs then that i could do

[robertlipe]

On Thu, Oct 26, 2023 at 2:00 AM AlDIY @.***> wrote:

Forget the fact that we can install on the same MCUs from other sites .

Right. That's awesome that you're able to confirm the board isn't flatly broken. There are times when comparing against other, similar projects is helpful. The bugs addressed in this thread are for these extremely specific configurations.

I can also open a new issue as the aim is to help improve things and not

just point out the site is not working ( which is unfortunately the case ) .

We know that some very specific things don't work right now. I've tried to set your expectations for what will and won't work. If we need to roll up our sleeves, we'll need a lot more than "not working".

I've lost track of what board you have. If your LEDs on pin5 are blinking with WLED and it's a plain ole ESP32 (maybe an S), I'd expect them to blink when flashed with our DEMO configuration.

If you want DEMO + Networking, I've shown you how to turn that on and you can build and flash right from Platformio as described in our landing doc.

The important thing is if you do not see issues in flashing via site then that is more then enough for me .

We know of issues with one very specific case. Panlee or anything else using the LEDSTRIP configuration or otherwise setting USE_WIFI and WAIT_FOR_WIFI (the spellings may be off - I typed them before) are probably on the edge of delivering a fix.

I do also have s3 but only one and not sure it would be best to report an issue if I can not replicate on multiple MCUs . If there is anything you would need from normal esp32 flashing logs then that i could do

For us to help, we still need way more details. Let's focus.

https://plummerssoftwarellc.github.io/NightDriverStrip/ You have a plain ESP32, so let's go with that one. DEMO should blink lights. It will NOT prompt you for network, so if that's your definition of 'broken', that's working as intended. LEDSTRIP will run into the same problem we're discussing as PANLEE.

IF you have a combination that's expected to work from that flowchart, please open a new bug. Include enough detail that one of us can reproduce it. Exact board type, whether you build the code yourself or are using downloads, arguments passed or any modifications made, etc. If you're building from source, include the git hash of the fork you're building from.

On the web download, there's an option for a serial console. If there's anything interesting (we don't need to see every line of a downloading: 1% 2% 3% ...progression) please post that into the bugreport.

Explain what "not working" means. No lights at all? You've confirmed that the LED_PIN0 definition in globals.h under whatever build configuration (PANLEE, LEDSTRIP, DEMO, etc.) matches where your LEDs are. The TTGO configuration, for example, uses different pins as the boards are routed differently.

If you get an announcement every 15 seconds (?) saying that it's outputting some number of FPS to some specific serial port, that tells you it actuallly IS writing LED data; it just may not be writing it where you want. Scroll upward and look for a line that looks like it came from debugI("Adding %zu LEDs to pin %d from channel %d on FastLED.", devices[channel]->GetLEDCount(), LED_PIN ## channel, channel); \

That'll tell you what GPIO pin it's writing to.

Obviously, if it's crashing or rebooting or drawing a pattern you don't like or something, we have a completely different problem and need a completely different approach. But we need more than "doesn't work" to go from there.

Help us to help you.

Message ID: <PlummersSoftwareLLC/NightDriverStrip/issues/425/1780526089@ github.com>

[rbergen]

@dosipod At the moment I would actually wait a little while until #469 is merged - at which time this issue will be closed. The fix in that PR should address the WiFi configuration issue on all builds that are based on the Ledstrip configuration - including Panlee on the S3, and Ledstrip on a variety of other devices.
As mentioned, the Demo project won't allow WiFi configuration on the ESP32, the M5StickC or the M5StickC Plus, in any case. On the other devices with a Demo project WiFi does seem to be enabled for it, so credential configuration should work.

[dosipod]

@rbergen Thank you yes it is clear now about the demo project , i could wait no issue as i am really just exploring leds projects and will only try Ledstrip after the merge . I do have a lot of fixtures and MCUs which I hope i could demo for this project as i did with other projects . Appreciate the quick response