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, as certificates are currently only valid for one year

Why should an endpoint be re-onboarded?

The current solution is that the onboarding certificates are valid only one year! 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 used for another year.

Additionally, if an app instance loses parts of its onboarding information, 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 external Id 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 the 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 bevor 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.