SSIDs with Chinese characters fail

[lvturner]

Got everything up and running with the demo, then entered an SSID with Simplified Chinese Characters in it (喝一点儿茶)

Got the following from the serial monitor

configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:952
load:0x40078000,len:6084
load:0x40080000,len:7944
entry 0x40080310

Reading saved configuration
[E][WiFiSTA.cpp:124] begin(): SSID too long or missing!
Waiting for WiFi to connect....................
Connection timed out
Starting Access Point
ets Jun  8 2016 00:22:57```

[nrwiersma]

Hi,

Sorry for the delay getting back to you.

The SSID is saved as a char[32] but to be honest, I have no idea how Simplified Chinese will interact with a char. Can you perhaps inform me?

Thanks,
Nick

[lvturner]

Hey Nick,

No worries man, if I expected an instant response - I'd expect to be paying a support contract too :D

It's been a while since I've done any of this, I'll see if I can figure something out/read up on it and get back to you. I suspect the Chinese characters in UTF8 just aren't being coerced neatly to a char.

Best

Lee

[nrwiersma]

My guess would have been that Simplified Chinese is Unicode, and i have not idea how that would look in UTF8. The ESP8266/32 only supports connecting Wifi with a char*, so there must be some conversion there that makes this possible.

The AP POST converts the SSID from json string to char* using ssid.c_str(). This may be the source of the issue. See L118 of ConfigManager.cpp.

That is at least a place to start looking.

[nrwiersma]

After reading very quickly on the subject, it seems 1 Simplified Chinese character gets encoded as 9 char characters, making your test 45 characters, outstripping the arbitrary 32 char limit I put on it (I was obviously not thinking about this use case when I set the limit). As a first test could you remove the last 2 characters, which should then work, if I am anywhere near right.

If this is the case, I have an idea that might solve this issue. A friend of mine pointed out that EEPROM is not necessarily the only place to put this, we also have the SPIFFS that we can store info in, perhaps in json. There would be a slight performance hit here (json conversion) but it would probably not be that bad. It would be possible to make an interface for this storage allowing us to swap the implementation out, and have the current EEPROM version, and the SPIFFS version which would be more flexible for this kind of use case.

[lvturner]

Seemed a bit better this time...

entry 0x40080310

Reading saved configuration
Waiting for WiFi to connect....................
Connection timed out
Starting Access Point

Note that for this test I actually set up my phone as a pair AP (as renaming my home wifi is quite disruptive so keen to avoid), so I'm not that surprised that the connection timed out.

Hope this helps!

[nrwiersma]

Yes, that confirms my suspicion that it is a space problem. The best plan is to abstract the storage of WiFi and config, allowing us to store them on the SPIFFS. I will try to start getting this going this week.

Sorry, this is not a use case I even considered when writing the library. Hope to have a fix for you soonish.