[Solved] App Issues on Android Xiaomi miA3: Selecting WiFi network not possible

[fasani]

Hello RainMaker team,

I must report that also with Android I'm having problems with some devices.
Clients report to me that they can scan successfully the QR but when they try to send the WiFi credentials they get stuck in this screen

Select Network: (No possibility to choose any WiFi)

Expected behavior: Show default WiFi where the master device is connected and let user choose another SSID .

Note that only some Android models seem affected as other people could configure them with this ecosystem without any problem (I also did it and worked on mine)

Also as a technical question I would like to know:
Is this WiFi list coming from the App itself, or it's being sent by the ESP32?
Thanks for looking in to it and give me a prompt response

[ESP_Piyush]

Hello,

Since you have mentioned ESP32, I am assuming that you are using BLE provisioning (the default for ESP32). Is that right?

When the users come to this screen or tap on the "Select Network", do they get any error toast message? Do those phone models always face this issue, or is it intermittent?

Our Android Engineers will check what the issue could be.

Meanwhile, the Wi-Fi list is fetched from the ESP32 and the default network in the dropdown is supposed to be the same network to which the phone is connected (given that it supports 2.4GHz).

Regards,
Piyush

[fasani]

Thanks Piyush,

I think we know what's going on after looking at the serial:

Code: Select all

CalEPD component version 1.0.6
Wave5i7Color() constructor injects IO and extends Adafruit_GFX(600,448)
[0;32mI (935) cpu_start: Starting scheduler on PRO CPU. [0m
[0;32mI (0) cpu_start: Starting scheduler on APP CPU. [0m
[0;32mI (944) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations [0m

12:37:59.425 [RX] - NVS Read OK. Minutes till next refresh: 27

[0;32mI (1024) system_api: Base MAC address is not set [0m
[0;32mI (1024) system_api: read default base MAC address from EFUSE [0m
[0;32mI (1044) wifi_init: rx ba win: 6 [0m
[0;32mI (1054) wifi_init: tcpip mbox: 32 [0m
[0;32mI (1054) wifi_init: udp mbox: 6 [0m
[0;32mI (1054) wifi_init: tcp mbox: 6 [0m
[0;32mI (1054) wifi_init: tcp tx win: 5744 [0m
[0;32mI (1054) wifi_init: tcp rx win: 5744 [0m
[0;32mI (1064) wifi_init: tcp mss: 1440 [0m
[0;32mI (1084) esp_rmaker_work_queue: Work Queue created. [0m
[0;32mI (1104) esp_mqtt_glue: I
12:37:59.525 [RX] - nitialising MQTT [0m
[0;32mI (1104) esp_rmaker_node: Node ID ----- UuLQj6edhdaRVczNsbMdt8 [0m
[0;32mI (1114) esp_rmaker_ota: OTA state = 2 [0m
[0;32mI (1124) esp_rmaker_ota_using_params: OTA enabled with Params [0m
[0;32mI (1124) esp_rmaker_time_service: Time service enabled [0m
[0;32mI (1124) esp_rmaker_time: Initializing SNTP. Using the SNTP server: pool.ntp.org [0m
[0;32mI (1134) esp_rmaker_core: Starting RainMaker Work Queue task [0m
[0;32mI (1144) esp_rmaker_work_queue: RainMaker Work Queue task started. [0m
[0;32mI (1144) wifi_prov_scheme_ble: BT memory released [0m
[0;32mI (1154) app_wifi: Already provisioned, starting Wi-Fi STA [0m
[0;32mI (1154) wifi_prov_scheme_ble: BTDM memory released [0m
[0;32mI (1164) phy_init: phy_version 4670,719f9f6,Feb 18 2021,17:07:07 [0m

12:38:01.743 [RX] - [0;32mI (3324) app_wifi: Disconnected. Connecting to the AP again... 

The ESP32 is stuck trying to connect to an old WiFi, and does not open the QR code and BLE to get provisioned again.
But the App in this case should report something otherwise the user is stuck in this Select network without any network to choose from.

From my side what I need to do is to also inform the user showing a text message and finding a way to render the QR in the display, and also informing that it's trying to connect to WiFi. Also maybe it's a good idea to store in the NVS the amount of WiFi retries, and go to sleep 10 minutes or so before trying again, and in case it does not connect for long time then call the wifi_reset so it will start on provisioning mode again.

This is only an issue if the user decides to switch off the Router, something that is quite normal if people go in holidays or decide to that for any reason.

[ESP_Piyush]

From your log, it seems that provisioning wasn't even started since the device already had Wi-Fi credentials and so, was trying to connect to it. In such a scenario, we do not even start the bluetooth which will allow the app to connect to the device. Have you made any changes in the firmware due to which the bluetooth could start even if provisioning isn't started?

With regards to the other suggestions, since a lot of users may have different opinions on what should happen when Wi-Fi network isn't available, we can't generalise any specific behaviour. It would boil down to having many config options for different behaviours. An option is to copy esp-rainmaker/examples/common/app_wifi into a components/ folder under your project's top level folder and then modify it the way you want. Components under the project's folder are chosen over the common ones.

[fasani]

I understand but then if there was no Bluetooth then the App should never arrive to the point of asking for the WiFi credentials, to just show an empty select network. It should simply stop with error I can find device or similar.

[ESP_Piyush]

Hello,

You mentioned that you yourself haven't seen the issue and it was reported by some client. Is that still valid or have you also seen the issue yourself now? If you yourself see the issue, can you double check if the logs are indeed taken during this specific provisioning attempt where the issue is seen? If Bluetooth itself is off (as we can see in the console logs), there is no way the phone app can connect and reach the Wi-Fi scan list page, because before going to that page, there is quite some 2 way communication involved which is not possible without device being in provisioning mode.

Would it be possible to share the entire provisioning workflow and complete logs while the device was indeed in provisioning mode?

[John__]

Martin,

I have a Poco X3 pro running MIUI 12 now but used to have a Galaxy S9+. When I switched over, I didn't see any particular problems however, I do remember seeing symproms similar to what you describe when the app was updated back in June or July (with the new, pretty UI). I seem to remember removing and reinstalling the app solced the problem but have to admit I wasn't very scientific about the process.

[fasani]

Hello ESP Piyush,
Marked the issue as solved since it was mostly my fault.
As you mention there was no Bluetooth but still my client managed to get to this screen in the App. How I don’t know, but as you can see I‘m not the only one that experienced this.
So I’m sure there is a small bug somewhere.

Other than that I’m struggling a bit with Rainmaker limitations to make a smooth flow for the end user, specially giving more events, to enable firmware with displays to have a smoother onboarding process. It already helps a lot and I will continue using it but there is a lot of improvements to be made.
For example, providing other events like BtProvisioningStart, generateQR (and pass the String to be generated), with only this two we could already make a much better integration. Please check this related QR improvement if you find some time:
https://www.esp32.com/viewtopic.php?f=41&t=22879

Many thanks for your continued support!