Enroll all node devices remotely under 1 account

[djorr5]

Hi, I am wondering if the following is possible with vanilla Rainmaker, i.e. stock app and stock dashboard etc. The firmware on the ESP32 can be modified.

A board is shipped to an end user with a QR code printed on paper.
The end user downloads the Rainmaker app and once registered and logged in with their email address they scan the QR code.
This will allow the ESP board to connect to their local wifi
The ESP board will now enroll into a master Dashboard, different to the end user that initiated the enrollment.
Once enrolled the master account will share the node back to the end user.

Basically I am trying to retain control over all nodes that are shipped to end users so I can control the OTA etc. And the end users will only get the nodes/devices that I want to share with them. Hopeing to be able to do it only via firmware modification and not need to create a web app backend.

[ESP_Piyush]

We have concept of user roles which allows admin users to always have access to all the owned nodes via dashboard, irrespective of who the end user is. However, admins cannot control which users should be allowed to link a given node.

Can you let us know what your use case is?

[djorr5]

Use case is to be able to ship a custom esp32 board to an end user and they can use the rainmaker app to allow the esp32 to connect to their wifi and enrol into the Rainmaker backend.

However, I do want the node to enroll into my dashboard so I can control OTA updates etc. And to be able to do this with minimal interaction from the end user. The end user will not be very technical.

I don't mind enrolling the esp board into my dashboard first before sending out the board to the end user, and then the end user scans a printed QR code simply to allow the esp32 board to connect to their wifi.

[ESP_Piyush]

Claiming the nodes using host driven claiming will make you the admin user for these nodes, making them visible to you on the dashboard. The devices can then be sent to the end users to onboard on their app, but the admin access will still stay with you.

Meanwhile, I hope it is well understood that you can have just 20 such nodes linked to your account as an admin since public RainMaker is meant only for evaluation and hobby purposes. For any commercial use cases, a private RainMaker deployment will be required. The distinction between admin and end users would stay similar though.

[djorr5]

Appreciate the response and understood.

[djorr5]

Hi Piyush,

Can you elaborate on this one for me please? I setup the CLI and can successfully use my account to claim the device via CLI, it shows up in my dashboard no problems. However when I then use the Rainmaker app to provision the wifi creds the Assisted claiming takes over and changes the node ID. The board successfully connects to Rainmaker but not under the host claimed account. The only other option available under Menuconfig>ESP Rainmaker Config>Claiming type is self claiming. If I used self claiming the same thing happens, connects successfully to the wifi but changes node ID and I lose it in the admin dashboard. Anything I am doing wrong here?

I did notice that during boot after I have used host claiming it gives me this error:

Code: Select all

E (860) esp_rmaker_core: Failed to get device certificate.

Doesn't the cert get provisioned to the board during host claiming?

And just to add to this. I tried with Do not use Claiming but I was getting:

Code: Select all

E (846) esp_rmaker_core: Failed to get device certificate.
E (846) esp_rmaker_core: Failed to initialise Node Id. Please perform "claiming" using RainMaker CLI.
E (856) esp_app_rainmaker: Could not initialise node. Aborting!!!

abort() was called at PC 0x4200d755 on core 0
0x4200d755: esp_app_rainmaker_main at GitHub/esp-rainmaker/examples/zigbee_gateway/main/esp_app_rainmaker.c:449

which relates to:

Code: Select all

    err = app_network_start(POP_TYPE_RANDOM);
    if (err != ESP_OK) {
        ESP_LOGE(TAG, "Could not start Wifi. Aborting!!!");
        vTaskDelay(5000 / portTICK_PERIOD_MS);
        abort();
    }
}

I had actually done Host claiming through CLI and it appeared successful so not sure why it should ask again?

Code: Select all

Claiming process started. This may take time.
Claim initiate started
Previous Session expired. Initialising new session...
Previous Session expired. Initialising new session...Success
Generating CSR
Claim verify done
Claim certificate received

Saving claiming data info at location:  .espressif\rainmaker\claim_data\Google_blahblahblah\806599A4EDA0/
Claiming done
Time(s):8.614367485046387

Generating NVS Partition Binary from claiming data: .espressif\rainmaker\claim_data\Google_blahblahblah\806599A4EDA0/806599A4EDA0.bin

Creating NVS binary with version: V2 - Multipage Blob Support Enabled

Created NVS binary: ===> .espressif\rainmaker\claim_data\Google_blahblahblah\806599A4EDA0/806599A4EDA0.bin
Flashing binary onto node
esptool.py v4.7.0
Serial port COM10
Connecting...
Detecting chip type... ESP32-S3
Chip is ESP32-S3 (QFN56) (revision v0.2)
Features: WiFi, BLE, Embedded PSRAM 8MB (AP_3v3)
Crystal is 40MHz
MAC: 80:65:99:a4:ed:a0
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00340000 to 0x00345fff...
Compressed 24576 bytes to 3390...
Wrote 24576 bytes (3390 compressed) at 0x00340000 in 0.2 seconds (effective 1245.7 kbit/s)...
Hash of data verified.

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

When I went through the other examples I noticed that their partition.csv has a slot for an encrypted certificate

Code: Select all

esp_secure_cert,  0x3F,          ,    0xD000,     0x2000, encrypted

, however in the Zigbee gateway example it looks different

Code: Select all

sec_cert,  0x3F, ,0xd000,    0x3000, ,  # Never mark this as an encrypted partition

Should the Zigbee example be the same as all the others?

[ESP_Piyush]

It seems that the Zigbee example code does not fit into regular partition table and so, it has a different table with only a single partition for firmware. Please check what address is printed for "fctry" partition in your boot log and pass that address (using --addr) to the CLI claim command.

[djorr5]

That worked. Thanks Piyush.

By the way is there a way to remove Nodes from Insights like there is in Dashboard?

[ESP_Piyush]

No, Insights currently has no way to delete nodes like in RainMaker. There are technical reasons for that since Insights architecture is different. It is feasible, but a costly operation, hence not included.