Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.913 won't connect to SSID with a space in name (also won't flash older fw) #39

Open
fat-tire opened this issue Aug 12, 2023 · 14 comments

Comments

@fat-tire
Copy link

Hey there!

Built from HEAD (v1.913) and manually updated to a bulb via the web interface...

It flashed fine, but did not connect back to the router (and hence) home assistant. I tried /reset and /clear ("file not found") and yet somehow everything got reset to defaults with "initial_ip" visible as the default SSID.

  • If I use my SSID from AP mode (which contains n a space- this cannot be changed) the space is replaced with a plus (+) in the wifisave command, but the bulb does not connect to the SSID.

  • If I set up a guest network with the initial_ip SSID & default pass of asdfasdfasdfasdf it WILL connect (at least, it did once) and work with home assistant (though strangely the web interface seems down making it hard to do any further fw updates or even to adjust any settings).

  • AP always comes back up as "kauf-bulb-MAC v1.913". I can connect to it and hit 192.168.4.1 to try to set stuff up, but can't seem to get it to see/connect back to the regular SSID.

  • I also tried substituting the + with %20 for the space in the SSID. This didn't seem to work.

  • I am unable to downgrade back to any other fw-- it just doesn't do anything, even when it says it will flash and reboot. It doesn't.

Any thoughts? Are there known problems like this with 1.913? It starts up red, and when I try wifisave it flashes to green and sometimes goes black. Don't know what any of it means though.

Thx in advance!

@DennisGarvey
Copy link

Having same issue

@bkaufx
Copy link

bkaufx commented Sep 30, 2023

Sorry guys I'll take a look. I can't really think of any reason this would be happening. If spaces aren't working in the SSID that sounds more like an ESPHome issue not anything we did.

When you say Built from HEAD (v1.913) and manually updated to a bulb via the web interface, what did you do exactly? Did you build the -update.yaml file to create a generic bin file that should keep your credentials you previously entered?

@DennisGarvey
Copy link

In my case, I tried updating the bulb through ESPHome Web UI, one bulb worked out, second one had this issue. SSID shows v1.914, won't connect to any wifi network with or without spaces. Wont flash new firmware file, wont reset.

@bkaufx
Copy link

bkaufx commented Sep 30, 2023

So in your case spaces made no difference? Have you tried setting up a network with credentials initial_ap / asdfasdfasdfasdf to recover the bulb? You should be able to flash a firmware that way.

@fat-tire
Copy link
Author

In my case, I built w the latest source a version 1.913 and when I start the bulb I see a kauf-bulb-abcdef v1.913 wifi AP, but when I connect to it with a laptop, 192.168.4.1 displays all the local wifi points but won't connect to any that are entered, spaces or not. It won't connect to the intial_ap w/asdfx4 I've set up either (though it shows in the list), and /reset just makes it drop out for a while, then come back with nothing changed.

Trying to update via kauf-builb-v1.87-update.bin.gz doesn't seem to take. It goes away, then comes back with the same v1.913 AP as before, and it hasn't updated the firmware at all. Doesn't seem like it's able to write anything. /clear and /events get a file not found. http://192.168.4.1/config.json works.. I tried building a new firmware.bin with latest source and that too is not taking 🤷 It just doesn't seem to know how to re-flash or attach to initial_ap for that matter (even if I make it the software defined SSID) instead, it always comes up with its own wifi and that's where everything gets stuck.

Trying to get it to restart via yellowx5 to red sorta works in that it eventually turns red. But it never really seems to take any settings anyway, so not sure if I'm resetting anything. It's like it's in read-only mode or something.

@DennisGarvey
Copy link

In my case, I built w the latest source a version 1.913 and when I start the bulb I see a kauf-bulb-abcdef v1.913 wifi AP, but when I connect to it with a laptop, 192.168.4.1 displays all the local wifi points but won't connect to any that are entered, spaces or not. It won't connect to the intial_ap w/asdfx4 I've set up either (though it shows in the list), and /reset just makes it drop out for a while, then come back with nothing changed.

Trying to update via kauf-builb-v1.87-update.bin.gz doesn't seem to take. It goes away, then comes back with the same v1.913 AP as before, and it hasn't updated the firmware at all. Doesn't seem like it's able to write anything. /clear and /events get a file not found. http://192.168.4.1/config.json works.. I tried building a new firmware.bin with latest source and that too is not taking 🤷 It just doesn't seem to know how to re-flash or attach to initial_ap for that matter (even if I make it the software defined SSID) instead, it always comes up with its own wifi and that's where everything gets stuck.

Trying to get it to restart via yellowx5 to red sorta works in that it eventually turns red. But it never really seems to take any settings anyway, so not sure if I'm resetting anything. It's like it's in read-only mode or something.

This is the behavior of one of my bulbs. Weird how I updated two bulbs and only one resulted in this behavior.

@DennisGarvey
Copy link

It now randomly decided to connect and work normally, weird.

@DennisGarvey
Copy link

Nevermind, updating the bulb from ESPHome web dashboard made it unresponsive again.

@fat-tire
Copy link
Author

fat-tire commented Oct 1, 2023

Oh I forgot to answer this:

When you say Built from HEAD (v1.913) and manually updated to a bulb via the web interface, what did you do exactly? Did you build the -update.yaml file to create a generic bin file that should keep your credentials you previously entered?

Yup. I've tried:

esphome compile kauf-bulb-update.yaml

and

esphome compile kauf-bulb.yaml

The firmware.bin that results doesn't take (except the first time, getting me into this situation).

Also tried gzipping to kauf-firmware.gz but although I got this:

"Firmware file uploaded successfully. The device will now process the firmware file and reboot itself. You can try to connect to the device over Wi-Fi immediately, but don't power cycle for at least five minutes if the device is not reachable."

After 5 minutes of the bulb staying yellow... I manually reset. It still reports as

Project Version | 1.913(u)
ESPHome Version | 2023.7.1

It knows the requested AP in the infobox.... but doesn't connect to it. Still comes up with its own AP. But it looks like making it a .gz at least made it try to flash, though the 1.87 was in .gz too and it didn't take- so I dunno what's going on. Sometimes it comes up red, sometimes it turns yellow. Sometimes the light goes off....

Weird.

@bkaufx
Copy link

bkaufx commented Oct 2, 2023

I've been unable to see any weird wifi issues on my end, including moving a few bulbs over to an ssid with a space in it. Can you guys maybe try flashing the exact same bin file on a d1 mini and see if you get the same result? That way we could see some logs via USB.

I'd also probably try doing the -lite.yaml package to see if any of the custom stuff I programmed is causing an issue. Just change kauf-bulb.yaml to kauf-bulb-lite.yaml. You can also try kauf-bulb-minimal.yaml.

@fat-tire
Copy link
Author

fat-tire commented Oct 2, 2023

I think I actually tried those builds too-- at this point I think the bulb is unable to write anything as I've tried a rebuild of 1.913, rebuild of the latest (I think there was one new commit since I first opened this PR?), plus going back to 1.87. maybe it worked the one time I got the "firmware file uploaded successfully" but I'm not sure.

I don't think I have the original build that started the problem any more, but I can maybe try flashing the latest build onto a 8266 d1 if I still have one laying around.. if needed, I can sacrifice the bulb and try to get a log, though I'm guessing there's no convenient microusb port in there to use... is there a best practice for disassembly/separating the base from the plastic "bulb" housing without trashing everything inside?

@DennisGarvey
Copy link

I ended up exchanging the bulb for a new one as I was within my return period with amazon.

@bkaufx
Copy link

bkaufx commented Oct 9, 2023

Returning via Amazon is probably the best thing to do here. The bulbs should get back to me eventually and I can check them out. If you can put a note in the box about the problem that would be helpful too. I don't know why this is happening and can't recreate the problem.

@fat-tire
Copy link
Author

fat-tire commented Oct 9, 2023

Way past the return period for amazon, but maybe I'll take it apart and try to reflash manually or something... there's no disassembly guide anywhere?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants