I’m looking at updating our OS code to leverage the new auto-provisioning-overrides.sh file supported in 6.7+.
Previously, we had customized the auto-provisioning.sh script to generate these values based on the hostname (in the format PRODUCT-SERIAL which was unique on a per-device basis.
However, at that time we had issues when devices were being re-flashed via TEZI and registration would fail due to the device already existing in the cloud platform.
Our fix was to append some random bytes to the end of the hostname when constructing the value to be used as a unique identifier.
With 6.7 and up, the documentation (Production Programming in Torizon | Toradex Developer Center) suggests these values should still be unique, but the example code will deterministically generate a result based on the device’s MAC, which does not change if the device is wiped and re-flashed.
Thus, my question in the context of this example: What currently happens if there is a collision between the device name or device ID with one already registered in the cloud? Will registration fail, and/or is there a way to “replace” the existing entry with the current one on the assumption it is the same device?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello BW908,
Thank you for your question. In Torizon OS 6.7 and later, the auto-provisioning-overrides.sh script allows customization of device names and IDs for registration with Torizon Cloud. If a collision occurs—meaning a device name or ID already exists in the cloud—the registration process will typically fail, as each device must have a unique identifier.
To prevent such collisions, you can append a unique suffix to the device name or ID, such as a random string or timestamp, similar to your previous method. This can be implemented within the get_device_name and get_device_id functions in your overrides script.
Currently, Torizon does not have a built-in mechanism to automatically replace an existing device entry if a collision occurs. Therefore, ensuring unique identifiers during provisioning is crucial. If you need to replace an existing entry, you would typically need to manually remove the old entry from the cloud platform before re-registering the device with the same name or ID.
By managing device identifiers carefully and ensuring their uniqueness, you can avoid registration issues and maintain a smooth provisioning process in Torizon Cloud.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
If you try to provision another device with the exact same ID and name as an already existing device, there should be an error. I believe you should get some HTTP 4XX error or something similar from the server in this conflicting case.
There is no mechanism to “replace” an existing device on the server. The old device on the server would need to be deleted in such a case. Since it’s not exactly a good idea to correlate what is essentially a new device to an old entry on the server. There are many possible issues that could occur from this. For one we’d be allowing a new device to assume an old identity which is problematic.
Is this a concern for your devices? Or were you just looking for clarification?
Thanks - I was mostly just looking for clarification since the example code given doesn’t seem to account for this. We’ll continue appending some data to ensure that even a re-provision on the same device will be unique.
Well the example wasn’t really considering the possibility one would re-provision the same exact device, with the same method. It was more an example to create some data that is unique per device.
In any case, glad I was able to help clarify. Do you have any other questions/issues on this topic?
