Large scale, production installation issue

Help
1

I was wondering how others may have handled this issue in a large-scale, production scenario. Given that each individual field device submits a json payload to a device-specific url in Losant and that I have been planning to load our firmware at the board house that its created at, I was planning on activating the devices in the field and creating the device in Losant based on a device recipe at the point of installation.

It is seeming like we would have an issue with logistics in that scenario since the url would need to be in the firmware at that point. Is there a better way to handle device creation/url scenario for large installations?

2

We have a blog article that describes a pretty common technique that our users have found for seamless device onboarding. It allows every device to be flashed with the same firmware. When they come online, they hit a registration Experience Endpoint that then returns the authentication details and the unique device ID. Details here:

3

Hi Brandon, I would like to follow up on this post/article about device self-registration. Could you explain me briefly how to implement self-registration for a device with edge agent keeping in mind the fact that we need to have losant security keys at the moment of running (“docker run”) docker container. Should device register first with a host-based script and then use received keys to run a container with edge agent?

4

Here’s a high-level outline of an approach we’ve successfully helped implement for a customer that is doing self-registration for Edge Agents.

  1. Run the Edge Agent container and mount in an empty config.toml file. This will cause the Edge Agent to continually shutdown and restart waiting for a valid configuration file.
  2. A separate process, in this case running on the host OS, is performing the registration round-trip to Losant. That process then writes a valid config.toml file once it obtains the device ID, access key, and secret.
  3. When the Edge Agent restarts (which is every few seconds), it will pick up the valid config and connect to Losant.

For this particular customer, they’re using a signed JWT to validate the device. The registration process POSTs this JWT as part of the round-trip. Since the signature is secret, we can assume it’s a valid device if the JWT properly verifies. We have JWT: Decode and JWT: Verify nodes that can help with this.

What’s nice about JWT is that additional information can be added, which can instruct the application workflow to do different things. For example, you could put a device type in there, which cause the workflow to create a Losant device from a specific recipe.

1 Like
5

Hi Brandon, thank you for this explanation. It’s good to understand the whole process with containers for a large scale fleet. What does happend when docker container is updated/ a new version is pulled from Losant Docker repository? Do we “re-register” device one more time on losant cloud or keep security keys on device for future runs? I would include one additional follow-up question. How often do your clients update docker container? With every new release or only for critical errors? Just to understand how advanced host OS program/device orchestrating should be.

6

There’s no need to re-register the device on each Edge Agent update. We work very hard to maintain backwards compatibility, so the existing config.toml file written by the registration process will work for the updated agent.

We do keep a detailed changelog for the Edge Agent. Generally customers only update for security patches or new features or bug fixes that impact their environment. There’s typically no reason to update otherwise.

1 Like