Has anyone run into this problem? During the onboarding process, when my Samsung S10 goes to switch WiFi to connect to the ESP8266, my phone gives the notification: “Security policy prevents use of unsecure Wi-Fi networks.”
After I select the device to add, but before I click start, I can see the ESP wifi network appear, but I don’t know the password. Is there a way to hard code the wifi password, or make it print in the serial monitor?
From what I can see, you’re using WSL on your Legion notebook, but which distro?
Try this: Navigate to Settings → Biometrics and Security → Secure Wi-Fi → 3-Dot More Options Icon (Upper Right) → Settings → Allow Access to Data Usage → Uncheck Secure Wi-Fi
If that doesn’t work, look for an app that might be preventing access to unsecure Wi-Fi networks: Navigate to Settings → Biometrics and Security → Other security settings → Device admin apps
I believe the default password for the ESP8266 Access Point is thereisnospoon.
After establishing a connection with the Access point, you can go to the default IP address 192.168. 4.2 to open a web page that allows the user to configure your SSID and password. Once a new SSID and password are set, the ESP restarts and tries to connect with the new SSID and password.
It’s my understanding that MSYS2 isn’t the same as WSL, that it’s more limited, but better for ESP8266 development. I’m not entirely sure what a distro is, are Ubuntu and Debian examples of distros? If so, I don’t think MSYS2 uses a standard distro, but I read that it’s based on Cygwin (is that a distro?).
I tried unchecking Secure Wi-Fi, but the problem persists. I also checked for admin apps, and none were active. I uninstalled Outlook all the same, but no luck. The only other app on the list is Find My Device, which cannot be uninstalled, and it’s not active anyway.
Thanks for the tip on the default access point password, love the Matrix reference, haha! I read that connecting to the network manually help the phone trust the network in the future. Unfortunately, it looks like the Smart Things SDK probably changes this, maybe generates it at random. The Wi-Fi name is Smart Things _[letters and numbers], so it’s likely the password is reset too for security. I’ll keep looking for it in the source code, but there’s a lot of files to sift through, haha!
As I was poking around, I found this description of the status: and stat: values.
/**
* @brief Contains a enumeration values for types of iot_status.
*/
typedef enum iot_status {
IOT_STATUS_IDLE = (1 << 0), /**< @brief For idle status, not connected. supports IOT_STAT_LV_STAY */
IOT_STATUS_PROVISIONING = (1 << 1), /**< @brief For provisioning status. do onboarding process. supports IOT_STAT_LV_START/CONN/DONE/FAIL */
IOT_STATUS_NEED_INTERACT = (1 << 2), /**< @brief For user interation status. need to interact with user. only supports IOT_STAT_LV_STAY/FAIL */
IOT_STATUS_CONNECTING = (1 << 3), /**< @brief For server connecting status. do connecting server. supports IOT_STAT_LV_START/DONE/FAIL */
IOT_STATUS_ALL = (IOT_STATUS_IDLE | IOT_STATUS_PROVISIONING
| IOT_STATUS_NEED_INTERACT | IOT_STATUS_CONNECTING),
} iot_status_t;
/**
* @brief Contains a enumeration values for types of iot_status level.
*/
typedef enum iot_stat_lv {
IOT_STAT_LV_STAY = 0, /**< @brief meanings for staying level with each status */
IOT_STAT_LV_START = 1, /**< @brief meanings for start level with each status */
IOT_STAT_LV_DONE = 2, /**< @brief meanings for done level with each status */
IOT_STAT_LV_FAIL = 3, /**< @brief meanings for fail level with each status */
IOT_STAT_LV_CONN = 4, /**< @brief meanings for connection with mobile */
IOT_STAT_LV_SIGN_UP = IOT_STAT_LV_START, /**< @brief meanings for trying to sign-up process */
IOT_STAT_LV_SIGN_IN = 6, /**< @brief meanings for trying to sign-in process */
} iot_stat_lv_t;
This is from iot-core/src/include/st_dev.h. Not super useful to me right now, but it might help someone else in the future. The rest of the file has some great descriptions of other variables.
Oh, OK. I became so fixated on the terminal window that I completely overlooked the “msys2, 32bit” part of your explanation. Yes, Ubuntu and Debian are examples of Linux distributions (aka distros), while Cygwin is a runtime environment.
Any message which mentions “security policy” usually means that there’s an app or service with admin permissions running. Microsoft Outlook is one app that is known to interfere with unsecure connections, as are anti-malware/anti-virus, and VPN apps. I’d reboot the phone and try again - if you haven’t already.
Additionally, the dev recommends that you disable the phone’s ‘Adaptive Wi-Fi’ option.
Concerning the default password, if you haven’t yet found it in the documentation, your best bet is to open an issue on the GitHub repo. In fact, you may want to ask for help in as many places as possible; there’s also the ESP8266 community sub-forum for IoT problems.
Finally, that was a good discovery - those iot status values will be useful, as should the help menu.
I managed to find where the password was stored and added a line that prints the SSID and the password. It seems to default to 1111122222. I was able to connect to and remember the network, but it didn’t seem to help. I also noticed that the SSID had spaces in it, and that first error mbedtls_base64_decode = -0x002c has something to do with invalid characters (mbed TLS v2.2.0: base64.h File Reference), so I tried removing the spaces from the device name on the SmartThings developer workspace. This didn’t seem to help either. I was looking at the GitHub issues (good recommendation!) and found someone solved a connection issue by simply deleting the build folder and rebuilding. That worked! The example is working now!
I went back and added the spaces into the device name again just to see if that broke it, and this time, the SSID was generated with underscores for spaces. Somehow that didn’t happen the first time around and I think that’s what was causing all the problems. Lesson learned, rebuild from scratch whenever errors persist!
The original build was erroneously compiled? But the second build works, following the identical compile procedure as the first? Mysterious. Deleting and recompiling doesn’t identify the problem but at least it’s working now, so that’s good news. If I were you, I would submit a new issue at the repo, maybe the dev can pinpoint the SSID anomaly and explain the cause of it. Nonetheless, well done with the working example.
Yeah, I guess that is weird… I wonder if it saved something in that build folder that never got overwritten? And that still doesn’t explain why the SSID was generated with spaces the first time and with underscores later. Good idea, I’ve submitted an issue on the repo. For posterity (and anyone who’s just curious), that can be found here: ESP8266 switch_example SSID error · Issue #126 · SmartThingsCommunity/st-device-sdk-c-ref · GitHub
