So I switched to a new router. Kept the same SSID, password, encryption, etc. I have 5 devices running wled on an esp8266. One will not connect to the new wifi. Tried to tell it to connect again, re entered the password. It just keeps creating its own access point. According to the router, it doesn’t seem to connect. I would assume WLED keeps logs/shows error messages… But I can’t find where.
Can someone help?
Make sure your new router doesn’t have e.g. 2.4GHz or WPA2 disabled by default…
Does WLED see your network when you scan after connecting to the AP?
You won’t find “saved” log data on an ESP32 running WLED, there’s no spare storage.
ESP8266’s are getting close(r) to not having enough space for the code that exists.
The closest you’ll get are some diagnostics messages if you hook your device up to a serial port that you watch during power up. Anything more requires diagnostic messages enabled in your own compiled version of WLED.
Watch out for your router running out of IP addresses due to too many devices connecting or “pre-reserving” IP addresses (iPhones and the like are famous for this). Try shutting down all the other ESP’s, reboot the router and try the “bad” ESP. If you can get the ESP’s MAC address, try and set a static address for that device.
Check or uncheck “disable WiFi sleep mode” in WLED config.
It already has a reservation set, and me network is set up with a 255.255.128.0 subnet. I have lots of IPs…
Either way it just seemed to start working for some reason… So its all good…
Serial output logs would be fine… But needing to compile specific code to get them seems a bit concerning. Not to go off on a tangent, and I am not by any means a programmer, but isn’t not keeping our at least outputting logs somewhere considered “improper” programming practice?
Yes, it sees the network. The 2.4 GHZ has a different name than my 5 GHZ network. I select the 2.4 GHZ network, re-enter the password, click connect. And told to connect to the new Ip address if it has changed, and then 4.3.2.1 pops up again.
Glad you’re up and running.
As for programming practice…
The WLED project is an excellent example of open-source at it’s best (IMHO).
The developers have started with a nice implementation of a WiFi controllable LED driver and proceeded to enhance and add features beyond expectations.
And with all such excellent projects there’s a limit to what you can do, especially when you’re constrained by the hardware in a SOC device like the ESP’s
Remeber there’s no reasonable way to add RAM to those devices, you get what they’ve built into the chip and that’s it. That has a huge impact on how “best practices” the code can become.
I’m not complaining in anyway about the structure or robustness of the current code - my hat is off to what has been done and what is on the drawing board now. Truly excellent work in my mind.
But in the end, something’s gotta give, and things like nice redundant log files of internal activity are prime candidates when you just don’t have the resources to maintain them.
Keep having fun 
Oh, I agree. Its great software. Everyone involved gets my thanks beyond any doubt for creating the software. The community is amazingly helpful. But just like every bit of hardware, software, machinery or device. Its awesome… until it doesn’t work. lol. Not that I am saying wled isn’t awesome when my device wouldn’t work. Its awesome period. Its just when something doesn’t work, should be not be able to see why?
Now, I know there are constraints on what can be installed into the device. It has limited RAM and storage, that your right, can’t be upgraded. But you did say yourself, logging can be enabled in the console by just “enabling it” in a custom compiled version puts those logs out of reach of people like me… Who have no idea what we are doing in the ways of compiling… I use WLED by going to the install website, plugging in my controller, and hitting install…
So, I guess this is kind of of turning into a suggestion. If it can be enabled in a custom compiled version, would it be possible to have a flag that can be set, either in the console (Since one would have to get there anyway) or in the web interface? That way people like myself could troubleshoot any issues we do have if we were so inclined? Again, I am no where close to a programmer, so that request may not be possible. But I thought I would throw it out there.
What you suggest, might be possible.
The alternative is what we’ve done here - post your issues and the combined knowledge of the community will point you in the right direction (we hope).
The “compiled only” features will likely cause a non-programmer more headache than help as it will give you insights into what’s going on, but they’ll be insights for someone familiar with the code structure of WLED. That said, there are various repositories out there with beta/debug features for download. In your case they probably would help less than just plodding through the usual checklist of items that have already been suggested.
I appreciate where you’re coming from - I do a fair bit of work in Linux environments and I can’t survive without the ability to see what’s happening under the hood. Unfortunately WLED is verrrrry far from an environment that can support those kinds of features easily.
Thought that may be the case; that is would just be too hard to implement.
As far as console output causing non-programmers headaches, I find that is the case with 25% of the logs I work with… Maybe 50? More often than not I think its just a thing for me to cut and paste into a forum and say “It won’t work, this is what the log says” lol.
Heres hoping everything just keep working. I have a bunch more esp32’s coming in to add more lighting…
That leads me to another question… But I will post it as another topic.
1 Like
to confirm your ssid’s and frequencies / troubleshoot interference, try running homedale from laptop to ensure everything is broadcasting properly.
Google it - it’s a free wifi tool