Problem with special character in wifi password

[amites]

Similar to tzapu/WiFiManager#804

It appears this has been fixed upstream from https://github.com/sidoh/WiFiManager

there's also a workaround suggested

don't know how far from upstream ya are but if it's just a matter of pulling in an update then issue should be resolved -- missing controlling my lights from my phone so happy to help once I know the context

[sidoh]

Not too far upstream. IIRC, the change was to add a callback hook when connection is successful. I believe an issue or PR was opened, but wasn't merged because there was an upcoming new version that would add the same functionality. Something like that.

Is the fix already merged upstream? Happy to pull it in and release a new dev version.

[amites]

haven't tested it but the comments suggest that this was fixed a while ago -- I noticed it's been 2 years since last commit to your copy of repo

[sidoh]

I point at a branch of my fork (lol):

https://github.com/sidoh/esp8266_milight_hub/blob/master/platformio.ini#L19
https://github.com/sidoh/WiFiManager/tree/cmidgley

[amites]

👍 good to know -- though still 6 months since last commit

[sidoh]

I just pulled from upstream, doesn't seem like much has changed:

sidoh/WiFiManager@a78c3b6

Am I missing something? Is there a branch other than master I should be pulling from?

[amites]

maybe not -- I was following comments which suggested the error was fixed

I'll run a build in next couple days to test

[sidoh]

There's a comment in the issue you linked which indicates the UTF-8 header might actually make a difference.

If that doesn't fix the issue, I'm happy to apply this patch:

tzapu/WiFiManager#804 (comment)

Sounds like that does fix the issue.

[amites]

Haven't used platform.io before -- anything special I need to do to build an img?

Most of my background in web programming so setting the header is trivial

[sidoh]

Nope, although I'd suggest building from the 1.9 branch. It should resolve the newest rev of my WiFiManager fork automatically.

With the ESP8266 connected to your machine, you should be able to build and upload a new image with:

pio run -e d1_mini --target upload

[amites]

that spit out a couple pages worth of warnings with a final error

Environment nodemcuv2	[SKIP]
Environment d1_mini  	[ERROR]
Environment esp12    	[SKIP]
Environment esp07    	[SKIP]
Environment huzzah   	[SKIP]

I'll look more into it later this week if I don't hear from ya

[sidoh]

haha. What's the error?

[amites]

Here's the full output

https://gist.github.com/amites/e5600728096efe2d0b3a75d90c843fde

[JMacIV]

@amites Try opening platformio.ini, then under common section, lib_deps_external, modify the ArduinoJson line to:
[email protected]

Not sure if that is the only error or not, but noticed the ArduinoJSON 5 mention in that log.

I could not get 1.9.0 to build myself the other day, but figured it was due to my never having used PlatformIO before. I ended up downloading and installing precompiled file instead.

After having messed a lot with PlatformIO over weekend (made a motion sensor + temp/hum sensor that communicates over MQTT using Homie convention), ran into that problem elsewhere. ArduinoJson 6.x is current, so if you are new to PIO, that is prob what is downloaded. However, 6.x had breaking changes over 5.x.

I just changed that line on mine and ended up being able to successfully build (plenty of other warnings, but that could also be because of newer versions of stuff.

@sidoh - What version of ArduinoJson are you using?

[sidoh]

Thanks @JMacIV, definitely looks like that's the issue.

Should definitely lock versions on dependencies. I'll take a look at doing that for everything for the 1.9 release.

[JMacIV]

@sidoh - Pretty proud of myself right now for figuring that out considering my first venture into PIO and even touching an esp8266/Arduino was middle of last week 😄

Ran into that ArduinoJson 6.x v 5.x issue when dealing with Homie 3.0 this weekend. Made me want to tear my hair out.

While I'm here, thanks for all of your hard work on this project! Using it to replace my iBox 2 and use Skinah's binding with openHAB.

[sidoh]

Nice, sounds like you should be. Good work!

I think platformio needs a better dependency locking solution -- something like ruby's Gemfile.lock. But at least there's a way to specify a particular version.

[sidoh]

Opened this issue to look into dep locking -- #414

[amites]

@JMacIV that got compiling to succeed thank you

@sidoh likewise thank you for all the effort you've put into this project

sadly it still seems to fail to connect to wifi -- had another project go sideways and don't have the capacity to tinker I was hoping for this week but happy to help keep testing until either it's solved or I have more time to dig in hopefully this coming weekend

[sidoh]

@amites, it's probably easier for you to dig into this since I don't have an easy way of reproducing the problem. I'd suggest the following next steps:

1. Fork sidoh/WiFiManager#cmidgely
2. Apply the patch described in this comment
3. Point your clone of espMH at your fork and build against it

If this works, I'd first try bumping the issue on the upstream project. Hopefully we can get that merged in. Also happy to apply the branch as well.

[amites]

quick update

tried a few different things related to modifying the form encoding -- nada

pulling the development branch in from upstream throws a compile error about setSetupLoopCallback no longer being defined -- will look into it later if I don't break down and just get an extra router just for the light controller

appreciate everyones help

[sidoh]

I pulled the development branch into a new branch in my fork. It's sidoh/WiFiManager#cmidgely_dev, in case that helps.

Hopefully the necessary feature will be pulled into the main branch soon. This is the issue:

tzapu/WiFiManager#858

After this is resolved, I can refactor to use non-blocking mode instead of the callback, and we can get rid of the fork.

[amites]

ran an install using your above branch -- thank you for pulling it in

seems like progress but still failing to connect
log output from boot after configuring Wifi

�EO,��4d�,H�p���*WM: [1] AutoConnect 

*WM: [2] Connecting as wifi client... 

*WM: [1] STA static IP:

*WM: [2] setSTAConfig static ip not set 

*WM: [3] WIFI station disconnect 

*WM: [1] Connecting to saved AP: **SSID**

*WM: [3] Using Password: **PASSWORD**

*WM: [3] WiFi station enable 

*WM: [3] enableSTA PERSISTENT ON 

*WM: [1] connectTimeout not set, ESP waitForConnectResult... 

hangs from there for several minutes and then reports

SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

may be a few days before I circle back to this but wanted to share findings -- again thank you

[sidoh]

Curious: is the password logged here correct?

*WM: [3] Using Password: **PASSWORD**

If so, I would imagine that WiFiManager is not the issue.

If you hard-code the password in the firmware, are you able to connect? Just put:

WiFi.begin("yourssid", "yourpsk");

somewhere before wifiManager.autoConnect. This will set the ssid/password that wifiManager will use.

If this doesn't work, the issue would probably be that your AP is somehow incompatible with the ESP8266.

[amites]

Yes the password is correct in the output, I hid it for publication

out of town for a couple days, gonna try hard coding the SSID/pass when I get back

the password is a longer phrase written as M1x3d C@$3 L33t$p3@k (mixed case leet speak) so full of "special" characters -- gonna be curious to see if hardcoding solves this or if there really is a limit to password support within the esp8266

thank you

[sidoh]

Hey @amites, did hardcoding the password end up working?

[amites]

nope, not sure if it's a limitation of the esp of the wifi config library

I ended up adding a 2nd router with limited access to network and a simpler password which is working

thank you

[sidoh]

Cool. I'll close the issue then. Feel free to re-open if you wanna discuss further :)