Old device name after delete_and_create the same device (MEGH-4192)

[jacek12345]

I create device with dev_name "X" and add name parameter with value "A", change device's name parameter to "B" and delete device. Next, create device one more time with dev_name "X" and add name parameter with value "A" one more time, but it has name B (that i changed for, last time, before deleting). The only way to clear this, is calling esp_rmaker_factory_reset(). Even "Remove" node from app does not clear this information.

Deleting device like this, without any errors:

     err = esp_rmaker_node_remove_device(node, sensor_device[sensnum]);
        if(err)
                ESP_LOGE(TAG, "Device remove ERROR");
        if(!err)
        {
            err = esp_rmaker_device_delete(sensor_device[sensnum]);
            if(err)
                ESP_LOGE(TAG, "Device delete ERROR");
            err = esp_rmaker_report_node_details();
            if(err)
                 ESP_LOGE(TAG, "esp_rmaker_report_node_details() failed: %u", err);
        }

[shahpiyushv]

@jacek12345 , this is more like a feature, allowing users to free up memory for operations like OTA, yet ensure that the names given by end users stay intact. For newer devices not related to their earlier instances, a different name is generally recommended. Even then, if you want the name to be deleted, would an API likeesp_rmaker_param_clear_value(char *device, char *param) or some similar variant of this be useful for you?

[jacek12345]

Is this related with PROP_FLAG_PERSIST ? When I create name parameter by esp_rmaker_param_create(), not by esp_rmaker_name_param_create() and didn't set PROP_FLAG_PERSIST, the name is cleared after device delete.

I suppose that can create name parameter with this manner but please clarify if there are some other issues related with using or not PROP_FLAG_PERSIST. I have RMAKER_NAME_PARAM_CB=y and manage in cb function like other parameters.

this is more like a feature, allowing users to free up memory for operations like OTA

So can it be problem with OTA if there is to many devices in node? If this is true, so what is recommended flow for OTA success in this case?

[sanketwadekar]

Hi, by using PROP_FLAG_PERSIST, the updated value of that parameter is stored in the nvs. If you want your device parameter to retain its state across reboots, then you should use PROP_FLAG_PERSIST.

[jacek12345]

On each boot i create devices from the beginning and use params (also name) from my NVS storage. Can I resign from PROP_FLAG_PERSIST in this scenario?

this is more like a feature, allowing users to free up memory for operations like OTA

So can it be problem with OTA if there is to many devices in node? If this is true, so what is recommended flow for OTA success in this case? Is it the same issue like this #213 ?

[sanketwadekar]

You might omit PROP_FLAG_PERSIST if you are manually reading and writing values to the nvs flash. PROP_FLAG_PERSIST is a flag added to eliminate the developer's overhead of manually writing/reading from the flash. Adding too many devices to the application will take up heap memory, which might cause OTA to fail. Rainmaker OTA events provide you with a way to execute your code before OTA starts, so you may delete some of the devices if you are currently facing issues during OTA updates.

[jacek12345]

thank You @sanketwadekar