SSL Problem with App Fairy 3.0

[patmolloy]

When I select icon64, I see the following message

Loading app definitions for selected device type... Failure: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1123)

And the app drop-down is empty.

[marcelstoer]

I now got hold of a Windows machine to test: I can reproduce this bug. macOS is not affected.

[marcelstoer]

If you happen to have Python installed in your PC you can work around the issue with the self-contained binary by running the app through the Python interpreter.

• clone this repository (or download its sources)
• open the Windows "console" cmd.exe
• navigate to the app-fairy folder
• run pip install -r requirements.txt
• run python app-fairy.py

[patmolloy]

Thanks, I will try this!

[patmolloy]

Ok, this works. But unfortunately, the wordclock app does not .. The display shows

This builds from the right to left and seems to repeat every few minutes (goes blank and then re-builds). I've tried different WIFI SSID and TZ locations.

The Bluetooth speaker loads and works, but not ToothFairy. Any ideas?

This is the Console output

Loading app definitions for selected device type...ok
Loading properties for selected app...ok
Fetching app from https://thingpulse.com/apps/icon64/word-clock-1.1/app.bin...ok
Building app configuration file...ok

Installing application...
Command: esptool.py --port COM11 --baud 115200 write_flash --flash_size detect --flash_mode qio 0x00000 C:\Users\patmo\AppData\Local\Temp/word-clock-1.1.bin 0x210000 C:\Users\patmo\AppData\Local\Temp/thingpulse-app.spiffs

esptool.py v4.1
Serial port COM11
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.....
Detecting chip type... ESP32
Chip is ESP32-D0WD (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: c4:4f:33:53:bf:41
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash will be erased from 0x00000000 to 0x000d3fff...
Flash will be erased from 0x00210000 to 0x003fffff...
Compressed 866352 bytes to 483317...
Wrote 866352 bytes (483317 compressed) at 0x00000000 in 42.7 seconds (effective 162.3 kbit/s)...
Hash of data verified.
Compressed 2031616 bytes to 3929...
Wrote 2031616 bytes (3929 compressed) at 0x00210000 in 8.4 seconds (effective 1928.8 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Application successfully installed. Device will reset.

[patmolloy]

I don't think the device is joining the WiFi Network .. I don't see MAC: c4:4f:33:53:bf:41 being given a lease.

[marcelstoer]

I suggest you hook up the device to a serial monitor (e.g. from the Arduino IDE). Our apps write debug statements to serial, particularly verifying the config values entered in the App Fairy will be interesting: https://github.com/ThingPulse/esp32-icon64-toothfairy/blob/master/src/main.cpp#L135

[patmolloy]

As suspected, failing to join. I have tried multiple 2.4GHz SSIDs .. are there any limitations on acceptable SSID names? Most odd. The values entered in AppFairy are properly copied over.

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
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:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
▒▒▒U▒▒▒2-hal-cpu.c:189] setCpuFrequencyMhz(): PLL: 320 / 2 = 160 Mhz, APB: 80000000 Hz
[D][esp32-hal-psram.c:60] psramInit(): PSRAM enabled
▒Attempting to read application.properties file from SPIFFS.
File exists. Reading and assigning properties.
Using 'ssid' from SPIFFS
Using 'password' from SPIFFS
Using 'timezone' from SPIFFS
Using 'secondCounterEffect' from SPIFFS
[I][main.cpp:186] loadPropertiesFromSpiffs(): Using 'brightness' from SPIFFS
Effective properties now as follows:
        ssid: GL-E750-a7e
        password: *******
        imezone: UTC0
        second counter effect: false
        brightness: 100
 [D][WiFiGeneric.cpp:374] _eventCallback(): Event: 0 - WIFI_READY
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 2 - STA_START
...Connecting to WiFi
...Connecting to WiFi
...Connecting to WiFi
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:391] _eventCallback(): Reason: 201 - NO_AP_FOUND
...Connecting to WiFi
...Connecting to WiFi
...Connecting to WiFi
...Connecting to WiFi
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:391] _eventCallback(): Reason: 201 - NO_AP_FOUND
...Connecting to WiFi
...Connecting to WiFi
...Connecting to WiFi
...Connecting to WiFi

[patmolloy]

I have separately run a little wifi scan sketch on this device and it is correctly seeing all of the wifi networks around here - so that at least shows WiFi is working .. must be something to do with the wordclock app?

[marcelstoer]

Thanks for the console output.

must be something to do with the wordclock app?

We obviously can't rule out any bugs but it's unlikely. We never heard from anyone with this issue. I just verified both the Tooth Fairy and the Word Clock apps - they run flawlessly here. The WiFi AP-joining code we use in those two apps is almost embarrassingly simple, straight from the 101 tutorial.

  WiFi.mode(WIFI_STA);
  ...
  Serial.println("Connecting to WiFi");
  WiFi.begin(ssid.c_str(), password.c_str());
  // Try forever
  while (WiFi.status() != WL_CONNECTED) {
    Serial.print(".");
    delay(1000);
  }
  Serial.println("Connected");

Your console output is interesting, though. It appears the ESP32 WiFi stack makes multiple attempts at connecting to your AP (several event 5 messages) but fails because it finds no AP for the defined SSID. This message

Reason: 201 - NO_AP_FOUND

usually means there are typos or non-printable characters or trailing spaces or... in the SSID. You could try flashing a simple WiFi-connect sketch into which enter the SSID manually to see if/how that makes a difference. Example: https://techtutorialsx.com/2017/04/24/esp32-connecting-to-a-wifi-network/

[patmolloy]

Well, it just gets more mysterious. The script above works - but very hit and miss. Sometimes connects, sometimes does not. Tried different SSIDs on different APs. I also added a print statement right at the front of the script which should say "Starting ..." irrespective of WiFi goings-on. That output is also hit and miss. So maybe the script is just not starting reliably?? Who knows!!

So, maybe just hit and miss starting and/or connecting? Whatever the case - the wordclock script (using a known good SSID from above which has connected) NEVER connects...

Frankly, I am out of ideas!

Thanks so much for all the help, BTW. Much appreciated.

[marcelstoer]

So maybe the script is just not starting reliably??

Try adding a delay like this

void setup() {
  Serial.begin(115200);
  delay(4000); // maybe 2s would also suffice
  ...
}

Sometimes connects, sometimes does not. Tried different SSIDs on different APs.

That is really odd - particularly since the WiFi scanner you tested detects the networks around you.

If you happen to have a magnifying glass or a camera with a good zoom would you mind inspecting the ESP32 module on the Icon64 PCB? We recently had a case where the WROVER module had the wrong antenna resistor soldered - the one that should be used for use with an external antenna. This reduced the WiFi reach by some 90%. The regular WROVER module without external antenna should have R14 soldered rather than R15. See https://twitter.com/frightanic/status/1219874323361603586 for details.

[patmolloy]

Sorry for slow .. Covid again :-( A 4000 mS delay at the start guarantees a join. Will have a look at the PCB now ..

[patmolloy]

I don't see a resistor on either R14 or R15 and the little IPEX antenna connector is missing too.

.

[marcelstoer]

Thanks for the photos. They seem to confirm there's an SMD resistor on R15. It's tiny but it's there. The IPEX connector is supposed to be missing as this is the WROVER-B (rather than WROVER-IB).

[patmolloy]

You're right .. this photo from a more horizontal view is better ..

So we're no closer to figuring out why word clock fails to attach to the same SSID that works in the test script, unless it is related to the delay needed to make it work reliably in the test script? Can I influence that / change that in work clock?? Would that mean loading it all up in platformIO ?? Is that possible?

[marcelstoer]

I am still puzzled as I don't see a reason why the delay would be necessary in your environment or with your device but not for others. But yeah, one of the joys of open-source software is that you can grab the project from GitHub (Git clone or download) and load it into your PlatformIO.

• change upload/monitor port in platformio.ini lines 16/17 to COM11 (got that from your initial screen shot above)
• adjust user settings in src/main.cpp lines 41+
• adjust delay in src/main.cpp line 84

[patmolloy]

Ok, a lot of debugging later. It is something to do with the values coming out of PSRAM. If I hard card the SSID and Password, it joins instantly! Flummoxed. Bad PSRAM ??

[patmolloy]

This is also causing timezone not to work correctly for me. Despite setting String timezone = TZ_Europe_London; I am getting UTC0 (i.e. an hour behind)

[patmolloy]

I just commented it out and all is fine // loadPropertiesFromSpiffs();

[marcelstoer]

It's great to know it finally works but I am still puzzled as to what the root cause is. I went through the relevant App Fairy and firmware code sections but I don't see what could be wrong. It'll take a few days until I have access to a Windows machine again for further investigation.

I thought we had established through your comment https://github.com/ThingPulse/app-fairy/issues/2#issuecomment-1158661417 that the values read from the SPIFFS config file (created by App Fairy) were indeed correct. Your console output also says you had apparently entered 'UTC0' as timezone in the App Fairy.

The values in the SPIFFS config file overwrite anything you might have defined in the firmware source code. If you want to verify it before the App Fairy packs it into the firmware it'll upload you may check the temp dir C:\Users\patmo\AppData\Local\Temp for /thingpulse-spiffs/application.properties.