Skip to main content

Frequently Asked Questions

Where is the ESP RainMaker Cloud infrastructure hosted?​

We use Amazon Web Services (AWS) Servers located in the US region.

Can I use ESP RainMaker on ESP32?​

Yes, ofcourse. With Assisted Claiming or Host driven claiming, you can use ESP RainMaker on ESP32.

It is possible that you may see compilation errors like below:

error: 'ESP_EFUSE_OPTIONAL_UNIQUE_ID' undeclared OR error: 'ESP_EFUSE_SYS_DATA_PART1' undeclared

This error may occur because in the esp-idf, ESP_EFUSE_SYS_DATA_PART1 was renamed to ESP_EFUSE_OPTIONAL_UNIQUE_ID. Just pull the latest master branches of esp-idf and esp-rainmaker to resolve this issue.

How do I fix the "Claim Verify Failed" error on ESP32-S2?​

Self-claiming uses the secret key programmed on the ESP32-S2 chips. If your chip is from the very earlier lots (samples), it may not have the secret programmed and so, you may get this error in self claiming:

I (103182) esp_claim: Starting the Self Claim Process. This may take time.
E (110122) esp_claim: Invalid response for https://esp-claiming.rainmaker.espressif.com/claim/verify
E (110122) esp_claim: Status = 400, Data = {"status":"failure","description":"Invalid challenge response"}
E (110132) esp_claim: Claim Verify Failed.

As a solution, claim your board using the CLI

  • Set-up the ESP RainMaker CLI by following the instructions here.

  • Go to esp-rainmaker/cli from the terminal.

  • Login using esp-rainmaker-cli login

  • Connect your ESP32-S2 board and claim it using:

    esp-rainmaker-cli claim $ESPPORT

  • Please ensure that you have set appropriate value of $ESPPORT which is the serial port on which your board is connected.

  • Flash any RainMaker example and you are good to go.

Please note that if you erase the flash, you will have to repeat the claiming process.

Why is the RGB LED on my ESP32-S2-Saola-1 not working?​

The ESP32-S2-Saola-1 board has the RGB LED connected to GPIO 18. However, a few earlier boards may have it on GPIO 17. Please use CONFIG_APP_LED_GPIO to set the appropriate GPIO.

$ idf.py menuconfig
    Example Configuration -> RGB LED GPIO -> 17

Why does the "Confirming Wi-Fi connection" on the Phone app show a warning type sign?​

ESP RainMaker uses SoftAP based provisioning. Since the ESP chips have a single radio, the station and SoftAP need to be on the same Wi-Fi channel. During provisioning, if the target Wi-Fi network is on a different channel, the Soft AP too switches to that channel. There are chances that the Phone gets disconnected from the SoftAP interface during this transition and so, cannot confirm the status of Wi-Fi provisioning. However, it may not be a real failure, and so the phone app just continues with subsequent steps.

I have done Wi-Fi provisioning of my board, but now I want to reset it to factory defaults. How do I do it?​

If your are using the standard examples, press and hold the BOOT button for more than 3 seconds to reset the board to factory defaults.

If you do not have the boot button, execute the following on the terminal.

$ esptool.py --port $ESPPORT erase_region 0x10000 0x6000

Please ensure that you have the correct ESPORT set.

How do I fix the "Invalid head of packet" error seen while flashing/erasing?​

If you have the wrong target platform selected, you may see errors like below while flashing/erasing.

Uploading stub...
Running stub...

A fatal error occurred: Invalid head of packet (0x50)
esptool.py failed with exit code 2

Please set the correct platform by using the idf.py set-target command. Eg.

$ idf.py set-target esp32s2

How do I fix the compilation errors seen while building the ESP RainMaker examples?​

Please ensure that you are using the latest esp-idf master branch and all submodules are in sync. Follow these steps

$ cd /path/to/esp-idf
$ git checkout master
$ git pull origin master
$ git submodule update --init --recursive
$ cd - # Come back to esp-rainmaker example
$ idf.py build

Some issues may also get resolved by clearing the example's build folder and the sdkconfig

$ cd /path/to/esp-rainmaker/examples/<your-example>
$ rm -rf build/ sdkconfig sdkconfig.old
$ idf.py set-target esp32s2
$ idf.py build

How do I fix the crashes seen during Wi-Fi initialisation?​

You may see error and a subsequent crash like below if your wifi submodule is out of sync

I (622) net80211: OS adapter function version error! Version 5 is expected, but it is 6
ESP_ERROR_CHECK failed: esp_err_t 0x102 (ESP_ERR_INVALID_ARG) at 0x40084e38
0x40084e38: _esp_error_check_failed at /Users/piyush/git-repos/idf/esp-idf/components/esp_common/src/esp_err.c:45

file: "/Users/<username>/.../esp-rainmaker/examples/led_light/main/app_wifi.c" line 134
func: app_wifi_init
expression: esp_wifi_init(&cfg)

abort() was called at PC 0x40084e3b on core 0

Please go to esp idf and synchronise the submodules

$ cd /path/to/esp-idf
$ git submodule update --init --recursive
$ cd - # Come back to esp-rainmaker example
$ idf.py build

Why does it take a long time for a device to appear offline?​

ESP RainMaker Devices connect to the cloud over MQTT, which uses a concept of keep-alive messages to detect if the connection is active. As per MQTT Specs v3.1.1, if the Keep Alive value is non-zero and the Server does not receive a Control Packet from the Client within one and a half times the Keep Alive time period, it MUST disconnect the Network Connection to the Client as if the network had failed. In ESP RainMaker, the keep alive time is 120 seconds and so, it can take upto 180 seconds for the server to know that the client has disconnected. A smaller value of keep alive will help in faster detection, but is undesirable as it can result in a lot of unncessary network traffic, and also cause frequent disconnect events if network strength is poor.

Is the login email address case sensitive?​

Yes, the login email address is case sensitive, primarily because RainMaker does not make any assumptions on how the email address should be. xyz@abc.com, Xyz@abc.com, xyz@Abc.com would all be treated as different accounts.