What is re-onboarding?

Re-onboarding allows an endpoint to get new client certificates and updates on URLs / topics for measures and commands

Internally, the endpoint gets the same identification (deviceAlternateId, sensorAlternateId and capabilityAlternateId remain the same), thus all rules, filters and buffered messages remain valid and do not get lost.

It is vital to have re-onboarding functionality implemented when not using router devices. Certificates are currently valid for ten years

Why should an endpoint be re-onboarded?

The current solution is that the onboarding certificates are valid for ten years. After that, the respective endpoint will still be displayed in the Control Center, but cannot be used any more. At this point, the same endpoint needs to be re-onboarded so that it can be further used.

Additionally, if an app instance loses parts of its onboarding information or some other unforeseen errors occur, it can be re-onboarded using the onboarding process.

Also, the endpoint URLs might change. Even though this is currently not planned, it could be a result of scaling.

How does re-onboarding work?

The client needs to send the same onboarding request as for its first onboarding, including a new registration code provided by the end-user.

The endpoint id provided in the request must be the same as for the initial onboarding, as this is used to map the endpoint to the existing

Capabilities may be sent, but do not have to (these are stored within the agrirouter from initial onboarding)

For CU re-onboarding only a new TAN is needed. Simply send the same onboarding request again and use the new TAN.

For the farming software and telemetry platform we suggest to calculate the valid time and renew the agrirouter automatically before the certificates will be invalid.

DKE advises to visualize the validity period of the certificate to inform the user about required re-onboarding in advance.