hello everybody,
with the basic function blynk.edgent when I try to connect the Nodemcu device to a WIFI network with SSDI containing a non-ASCII character (the “à” in my case) it seems that the nodemcu cannot connect to the network because the character is not read correctly; In fact, in the log of nodmcu I see a “?” instead of the espcted “à”.
using other ssdi with other ASCII character, it works fine.
thanks for your help
pepson84
What version of the Blynk library are you using, and is the Edgent example sketch taken from the latest library version, or is it a file that was saved from an earlier version of the library?
What version of the ESP core do you have installed?
Pete.
hello Pete,
yes, i’m using this version of library: Blynk v1.1.0 and its Edgent example.
my device is:
Device: ESP8266 @ 80MHz
Flash: 4096K
ESP core: 3.0.2
ESP SDK: 2.2.2-dev(38a443e)
Boot Ver: 6
Boot Mode:1
FW info: 539824/3633152, MD5:8276cb1719cb4d05b9ae808ebe3c5108
Free mem: 23360
thanks a lot
the ASCII code for “à” is 224. So instead of entering “à” in your code, you would enter “\xE0”, which is the ASCII equivalent of “à”.
thanks, but i want to use the blink Edgent captive portal, not to embedde the SSDI name inside the code…
It might be worth updating to 1.2.0 and creating a new sketch from the Edgent example that comes with this library.
It’s also a good idea to update this to 3.1.1
How many characters are there in your SSID (how long is it)?
Pete.
ok i’ll try.
ok, i’ll try.
it is long 11 characters.
thanks
i did the upgrade you suggested Pete, it doesn’t work.
here the log that esp printout
blynk v1.2.0 on ESP8266
Platform: ESP8266 @ 80MHz
Boot ver: 6
SDK: 2.2.2-dev(38a443e)
ESP Core: 3.1.1
Flash: 4096K
Free mem: 30184
17:53:23.140 → ----------------------------------------------------
17:53:23.178 →
17:53:23.178 → >[422] INIT => WAIT_CONFIG
17:53:23.864 → [1136] AP URL: blynk.setup
17:53:55.723 → [33000] Applying configuration…
17:53:55.723 → [33000] WiFi SSID: ssdi⸮-Wi-fi Pass: *******
17:53:55.723 → [33000] Blynk cloud: ***************************** @ blynk.cloud:443
17:53:55.770 → [33004] WAIT_CONFIG => SWITCH_TO_STA
17:53:55.770 → [33006] Switching to STA…
17:53:57.044 → [34311] SWITCH_TO_STA => CONNECTING_NET
17:53:57.044 → [34311] Connecting to WiFi: ssdi⸮-Wi-fi
17:54:47.036 → [84320] Last error code: 701
17:54:47.036 → [84321] Configuration stored to flash
17:54:47.085 → [84321] CONNECTING_NET => ERROR
17:54:57.054 → [94327] Restarting after error.
thanks
What happens if you use a non-Edgent sketch and hard-code this SSID into your sketch. Does it work then?
Pete.
it works, i just tested it, but to be honest, i have other devices with hard-coded this SSID into the sketch and they works from long time.
Connecting to ****à-Wi-fi
.......
WiFi connected
IP address:
192.168.137.68
connecting to djxmmx.net:17
sending data to server
receiving from remote server
"Someone's not dead, until they're completely dead..."
- Munro Kelly (Congo)Okay, but your example doesn’t show you connecting to the Blynk server, it shows you connecting to something else, so presumably that WiFi connection was established using a WiFi.begin() command, not a Blynk.begin() command.
I’m trying to eliminate variables and track-down what is and isn’t working from a Blynk library point of view.
I suspect that the problem is connected with the way in which Blynk.Edgent stores the credentials in EEPROM and retrieves them again, and that extended ASCII characters (one with a code >127) are somehow being lost in this conversion process.
But, it’s impossible to know if that’s the case without knowing if a non-Edgent Blynk example with the hard-coded SSID works as expected.
Pete.
yes, you are right.
i done with the Blynk ESP8266standalone example, it works ( i use it also in the past 
)
Connecting to ****à-Wi-fi
[7901] Connected to WiFi
[7902] IP: 192.168.137.209
[7902]
___ __ __
/ _ )/ /_ _____ / /__
/ _ / / // / _ \/ '_/
/____/_/\_, /_//_/_/\_\
/___/ v1.2.0 on ESP8266
#StandWithUkraine https://bit.ly/swua
[8030] Connecting to blynk.cloud:80
[11326] Ready (ping: 204ms).
thanks again.
@vshymanskyy any ideas why these extended ASCII characters in the SSID name are producing problems in Edgent?
I suspect it’s an issue with the way that the SSID value is being manipulated before being stored in EEPROM and then extracted again to be used for the connection, but nothing leaps out at me as being the obvious cause.
Pete.
Need to check on ESP8266. It used to work on ESP32