RichardGHubert-4565 avatar image
0 Votes"
RichardGHubert-4565 asked asergaz commented

Azure IoT-Edge "Device Move" Scenario

Hi. We use Azure IoT-Edge with both the Transparent-Gateway pattern to new IoT-Devices and Identity-Translation-Gateway pattern to legacy devices. We need to find the best solution to "Move" a device between two IoT-Edge instances.

The Device-Move could be frequent between the IoT-Edge instances, not just once, so the procedure cannot be too complicated/intrusive. Some of the Device-Twin data needs to be common across the "Moves" but this can be handled in the IoT-Hub directly (via an Azure Function, for example).

What we are looking for here is ideas or suggestions for the best (supported) "Move" options.
- Online-Move: move an IoT-Device between two IoT-Edge instances when both IoT-Edges are online.
- Offline-Move: move an IoT-Device when the IoT-Edges are offline.
- Hybrid approach: Move offline after the IoT-Device has been online-registered once on both IoT-Edge instances.
- Other options?

Thanks for any thoughts on this! It is an important requirement in many real-world IoT-Edge constellations.

· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hi @RichardGHubert-4565 thanks for joining Microsoft Q&A and the very interesting question :)!

I am researching on this and wanted to cross check if you have came accross this doc Import and export IoT Hub device identities in bulk before? Would that help answering some of your current questions?

"Each IoT hub has an identity registry you can use to create per-device resources in the service. The identity registry also enables you to control access to the device-facing endpoints. This article describes how to import and export device identities in bulk to and from an identity registry."

Thank you!

0 Votes 0 ·

Thank you António,

Actually, I'd seen but never really considered that link as a solution to our challenge since it is IoT-Hub specific and we use the IoT-Edge gateway. However, I certainly will read it and see. We have some ideas of how to solve our challenge but they are a bit convoluted -- involving quite some backend code to sync up Twins etc. In any case, we appreciate your (Team's) attention here since we have to get this working in our IoT (healthcare) solutions or "bust". i.e. failure is not an option for us. I'll let you know here what I learn from the article. We can also exchange design ideas, but I would indeed like to see what you all come up with before I start with our potential "hacks". Best!

0 Votes 0 ·

@RichardGHubert-4565 ,
In the hope we helped you with the initial steps of your project, can you please mark the below as accepted answers? :)

- Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.
- Want a reminder to come back and check responses? Here is how to subscribe to a notification.

0 Votes 0 ·
KevinSaye-6088 avatar image
3 Votes"
KevinSaye-6088 answered RichardGHubert-4565 commented

@RichardGHubert-4565 interesting use case. As @asergaz states, there few options for what you are accomplishing -- with the biggest challenge being the offline move.

I agree that there are limitations in accomplishing what you want. The base limitation being that there is a 1:1 relationship for child to parent when associating a leaf device with an edge device and that IoT Edge has to be online to see the change. The PG has heard this 1:1 relationship feedback and you can vote on it here:

Being familiar with the Nested Edge feature that @asergaz speaks of, there are also other features that will release that will solve your issue. At the Ignite conference, it was announced that there would be a public preview of the Nested Edge on ~10/30, so I think you will soon have options!

· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thank you Kevin, I sure will vote on that, and we are scouring the net for as much information as we can find on the Nested Edge Feature. We haven't found much besides the tidbit in the ignite infos, so if you have a pointer, much appreciated. We'll live with the "online on first connection" scenario above for starters and hope for some improved capabilities later.

Background as to why this Use Case is significant: You see, the equipment that we attach to the edge is very expensive and it may need to be shared across edges or we may require temporary replacement devices since it is a mission critical device. So, this makes a "device move" scenario necessary even in an environment that cannot always be online.

1 Vote 1 ·
RichardGHubert-4565 avatar image
1 Vote"
RichardGHubert-4565 answered RichardGHubert-4565 edited

Ok. I read it. The created and update as shown here will certainly be of use iot-hub-bulk-identity-mgmt We already sync between reported and desired-state Twin content. However, the main challenge in our "Offline Move" scenario are the following. Maybe your team can help here:

  • Although we'd love to have a "pure offline" option, we'd currently be happy if we can make this work after the device has initially been connected to the Iot-Edge gateways -- call them EdgeA and EdgeB -- online and can then be moved at random between EdgeA and EdgeB after these have gone offline.

  • It looks like we'll need to create a unique IoT-Hub-ID in our backend (on the Iot-Hub) for the device for each EdgeA, EdgeB etc. (EdgeN) when the device is connected the first time to an EdgeN (online required). So we end up with N IDs/Twins for the same device. So, we're thinking of putting a "SyncedCommonTwinData" in these Twins and having to locate and sync this portion of the Twins each time a Reported state is changed (in the IoT-Hub). This is because the end IoT-device may have, for example, calibration data changed via Edge-A (locally) and it must find this same calibration when it is attached to Edge-B. This sync operation will have to be kicked-off (somehow) when device-critical (CommonTwinData) is changed locally. Our application will have to warn the user to go online or such in this case.

  • A significantly simpler solution to this could be supported by Azure IoT if the Iot-Hub would allow us to share the SAME Iot-Hub-Device-ID across multiple IoT-Edge gateways, then we would not have a bunch of redundant IDs and Twins to manage. For example, add a property (and portal checkbox) "Share this device across multiple IoT-Edges?

That is our first design cut in any case ... that we'll try unless we find a better idea. Thoughts?

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

asergaz avatar image
0 Votes"
asergaz answered RichardGHubert-4565 edited

Hello @RichardGHubert-4565, thank you for taking time and read the shared doc (Import and export IoT Hub device identities in bulk).

I have also researched further and to address your main challenge where "failure is not an option for us." and "move an IoT-Device between two IoT-Edge instances" offline and online I believe that the best approach would be to use IoT Edge on Kubernetes (Preview)

  • IoT Edge can integrate with Kubernetes using it as a resilient, highly available infrastructure layer... IoT Edge manages the edge application platform running on top, continuously reconciling the desired state specified in IoT Hub with the state on the edge cluster.

As to the specificities of your project and north star "to have a 'pure offline' option" I am afraid I can't guarantee that IoT Edge on Kubernetes will address all the needs. See as well how @KevinSaye-0746 approaches similar challenges as yours here:

Finally another possibility is to use IoT Edge Nested Edge that is now in private preview

  • Nested Edge is a new feature of the open-source Azure IoT Edge product that allows customers to deploy IoT Edge nodes across networks organized in hierarchical layers, where only the top layer has connectivity to the cloud... that help them reduce unplanned downtime, increase equipment efficiency, and reduce defects in the manufacturing process.

Thank you!

· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thank you very much. We will study all of these and get to the best solution...

... If I'm understanding Nested properly, we could perhaps still have a single Iot-Device (IoT-Hub-ID) that routes its messages to more than one IoT-Edge in the LAN?

See you back here as the situation evolves.

1 Vote 1 ·