Which esp-idf version and esp-rainmaker commit are you currently on? Are you trying this with some default RainMaker project? Which MCU are you using?

An issue was identified with the recent changes in firmware for using the new Network provisioning component instead of the earlier Wi-Fi provisioning component. The apps were able to provision the nodes after this change. Can you confirm if things started failing for you just on app update, or had ...

In the original issue, the node was unable to connect, hence the question regarding claiming. If you use host driven claiming, followed by assisted claiming and then again followed by host driven claiming, it is possible that a stale certificate gets written to the device, which will never be able t...

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 ...

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?

The public as well as private deployments of ESP RainMaker indeed have admin and end user roles. You can read more about these roles here. On private deployments, the differentiation is much clearer though, since the node registration itself happens differently and is managed by the admin users.

Please try the following - Add esp-rainmaker component dependency in your project using idf.py add-dependency "espressif/esp_rainmaker^1.4.0" - Copy all folders from examples/common into a components/ folder in your project or esp-idf/components. - Remove this line from your project's CMakeLists.txt...

The examples typically are meant to serve as a starting point and the ones for RainMaker Arduino cater to different use cases like standard device, custom device and multi device. Depending on your use case, you can start with one. The "issue" regarding using these is not clear from your description...

The python CLI is for claiming and end user operations whereas the dashboard is for admin operations, meaning that their feature sets would mostly be mutually exclusive. So, the requirement is still not clear. If you can elaborate with specific points, we can check what can be added/improved.

Parameter settings will be under "Actions" in schedules. Did you check there? Also, schedules need to be explicitly enabled in the firmware. They are enabled by default in all examples using esp_rmaker_schedule_enable(). Please ensure that your project has the same.