Closed alkonosst closed 10 months ago
But if the device loses the credentials (saved in NVS) and start with a "fresh" uploaded firmware (NVS formatted), the cloud respond to the provisioning request with the message "Failed to provision device!"
The aforementioned behaviour is as expected if you plan to provision a device with the same id as an already existing device that will not work.
If you plan for the device to restore its own access token and connection somehow if it is lost from NVS
that will not be possible. Because the access token is the only way to ensure the device is the one initially authenticated and not any arbitrary device posing as such.
It is possible to receive the Access Token but not using the the MQTT
API, you would have to use the Rest API for that to fetch the credentials of a device with a given id. With the getDeviceCredentialsByDeviceIdUsingGET.
For your use case I would look into ensuring that the NVS
is not wiped instead. You can upload the firmware (.bin) file without overwriting the file system or NVS
portion. I'm not sure which toolchain you use, but the PlatformIO
upload does not overwrite the file system or NVS
portion per default.
Additionally if you update using Over the Air updates it will also not wipe the file system or NVS
portion of the partitions file.
Thank you for your answer.
The aforementioned behaviour is as expected if you plan to provision a device with the same id as an already existing device that will not work. If you plan for the device to restore its own access token and connection somehow if it is lost from NVS that will not be possible. Because the access token is the only way to ensure the device is the one initially authenticated and not any arbitrary device posing as such.
I imagined that would be the behavior of the cloud. Thanks for ensuring that.
It is possible to receive the Access Token but not using the the MQTT API, you would have to use the Rest API for that to fetch the credentials of a device with a given id. With the getDeviceCredentialsByDeviceIdUsingGET.
I also looked for it to see if it could be an alternative, but yes, the API asks for that ID generated by the cloud, so it is not viable either.
For your use case I would look into ensuring that the NVS is not wiped instead. You can upload the firmware (.bin) file without overwriting the file system or NVS portion. I'm not sure which toolchain you use, but the PlatformIO upload does not overwrite the file system or NVS portion per default.
Additionally if you update using Over the Air updates it will also not wipe the file system or NVS portion of the partitions file.
You are right, in our firmware the NVS
is not wiped on updates (using OTA with thingsboard). I forgot to mention this issue happens in a testing environment, where we use a CLI command (nvs -f
) to clean all settings from NVS
. It would be nice if I could have the same device on the cloud for telemetry purposes, and not having to delete this test device on the cloud.
I think I can overpass this issue with some modifications to keep Access Token not cleared after this wipe command.
Thank you, closing this issue.
Hello there, thank you for this good and comprehensive library!
First some context:
Provisioning device to obtain Access Token
This works well. The device provisions itself using its MAC as Device Name. But I have a issue...
Provisioning request and response (credentials replaced with ***):
Connection to Thingsboard with received credentials:
But if the device loses the credentials (saved in NVS) and start with a "fresh" uploaded firmware (NVS formatted), the cloud respond to the provisioning request with the message "Failed to provision device!":
This event forces me to delete the
25ef49c0
device in the cloud, because it already exists. Is there some way the device25ef49c0
could obtain its already created Access Token?Auto-provisioning with X.509 certificate
This also works well. I generate a Device Key with a unique
Common Name
using OpenSSL, which is used by the cloud to create a new device with a certain quantity of words in the Common Name (using regular expression).But, of course, this forces me to create a unique key file and upload to every device separately (I can't imagine the time it takes to do this to >100 devices).
So, is there a way a device could connect to Thingsboard for the first time, and the cloud creates this device?
Hope I've clear enough! Thanks again for the library and your help :)