Azure IoT-Hub Device Twin with Azure Digital Twin using DTDL: are they complements or alternatives? How? - azure

There is some confusion between two aspects of Azure IoT-Hub. I see here that Azure Digital Twins (with DTDL) simplify device state management (reported, desired properties) when compared to Azure IoT-Hub Device Twins. However, I see here that they appear to be separate but linkable entities.
So the question: Can Azure Digital Twins (and DTDL) be seen/used as REPLACEMENTS for Azure IoT-Hub Device Twins. How? If not, why not, since having two separate Twins appears overly complex?
Note that we use the IoT-Edge and leverage its offline features of reported and desired properties in the Iot-Hub Device Twins.
Thanks!

Short answer: No
Longer and arguably more friendly answer: To leverage the Device Twins in IoT Hub, you need Device Twins in IoT Hub, but you can link it to your Digital Twin in Azure Digital Twins (ADT). If you want to include your Device Twin properties in ADT, you need to route your Device Twin messages to a Function that will make the translation to ADT. In this subsection of the docs, you can see the differences in notation.
If you want to let ADT 'drive' your Device Twin, you need to subscribe to ADT change notifications, consume them in another Function and apply the changes in the Device Twin in IoT Hub. This is currently all custom work, you can base some of the work on the link you provided in your question.
With regards to your question about complexity: it might seem a little complex to set up ADT as your single source of configuration, but when it's done, you have your config in one place. In practice, I'm not seeing this happen a lot.
Important to note
To make things a little more confusing, the first link you provided mentioned Digital Twins and Device Twins as if they're two different things, while in fact, it's three. You have the Device Twin in IoT Hub, the Digital Twin in IoT Plug and Play context and a Digital Twin within Azure Digital Twins. It's important to understand the differences between the three, as ADT is a separate system, but PnP Digital Twins and Device Twins are accessible through your IoT Hub.

Related

What is the difference between Microsoft Azure Digital Twins and Microsoft Azure IoT Central? When to use what?

I am trying to understand and try out the IoT Service Stack on Microsoft Azure. When reading through documentations and blogs i came across the Microsoft Azure Digital Twins and Microsoft Azure IoT Central service.
But what i didnt understand is:
What is the difference between Azure Digital Twins and Azure IoT Central?
When to use what?
Run combined? Is there any scenario for this or is there a need to use both in parallel? Any scanario for this?
Azure Digital Twins
https://azure.microsoft.com/de-de/products/digital-twins/
Azure IoT Central
https://azure.microsoft.com/de-de/products/iot-central/#overview
You could write a lot about the differences between these products, because they serve a different purpose.
Azure IoT Central is a Software as a Service application that allows you to register, manage and control devices. It stores the device state and provides bi-directional communication between the application and the devices. It's based on Azure IoT Hub for communication and Device Provisioning Service for device registration.
Azure Digital Twins (ADT) is a Platform as a Service offering that allows you to model anything using the Digital Twin Definition Language. While this language is also used in IoT Central to create device templates, the language can be used in ADT to model anything from buildings to people. ADT is used to create a graph-based information model that can be updated through the API. So if you want to include device data, you will need IoT Central or IoT Hub and write code to connect it to ADT. You can use any other data that you have and do the same. It's not limited to IoT devices.
In short, use IoT Central if you want a SaaS platform to manage devices and display telemetry. Use ADT to create a graph-based data collection using any input data you want.
Is there any scenario for this or is there a need to use both in parallel? Any scanario for this?
ADT needs information from a source. This could very well be IoT Central. You can export telemetry from IoT Central and populate the graph. There is no standard way of doing this.

Azure Digital Twins <---> The Things Network (2 way communication)

I am working on a project that requires two-way communication between Azure Digital twins and the Things Network. Right now I am able to connect my AZDT to the TTN via an IoT HUB to update the twin with "read variables" for example I have a CO2 sensor that sends data via the IoT HUB instance to the AZDT.
However I am not sure how to do the communication the other way around, when I send a signal to a "write" variable, and this message is carried over to the device, for example I have a smart plug that can be turned off via the AZDT.
anyone could give me some ideas? or support on that?
thanks
did you check out the TTI IoT Hub integration documentation page?
There is a section that explains Desired Properties for updating values between The Things Stack and IoT Hub
https://www.thethingsindustries.com/docs/integrations/cloud-integrations/azure-iot-hub/device-twin/#desired-properties
To generate a downlink you need to update the shadow of the device and save it, which will schedule a downlink for the device on The Things Stack.
To trigger this from the twin itself, you need to update the Digital Twin state that contains the property of the device in question
I would take a look at additional docs from MSFT on this
e.g.,
Updating device twin in IoT Hub: https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-device-twins
Updating Digital Twin: https://learn.microsoft.com/en-us/azure/digital-twins/how-to-manage-twin#update-a-digital-twin
Hope this helps

Azure IoT Central architecture - how are Digital Twins implemented and managed?

I have a system with IoT Hub to ingests events from devices and Device Provisioning Service to provision devices. IoT Hub C# SDKs are used for the management of device tags and desired properties (IoT Hub device twins), and to invoke direct methods or schedule jobs.
Recently I've been experimenting with Azure IoT Central. While I don't plan to use it, I've found Digital Twins (that are being used on Azure IoT Central) to offer a very good way of managing IoT devices and I would like to emulate the same kind of functionality and capabilities on my IoT system.
The high-level architecture of IoT Central does not seem to indicate the services or logic used to manage Digital Twins.
As far as I understand, there are two ways you can start using Digital Twins:
Plug and Play Digital Twins
Azure Digital Twins service
Question - is Azure IoT Central purely based on Plug and Play Digital Twins and/or does it also use Azure Digital Twins service?
Yes, IOT Central is purely based on plug and play Digital Twins
plug and play Digital Twins enables solution builders to integrate IoT devices with their solutions without any manual configuration.
Azure Digital Twins can be used to design a digital twin architecture that represents actual IoT devices in a wider cloud solution, and which connects to IoT Hub device twins to send and receive live data.
Reference link: https://learn.microsoft.com/en-us/azure/iot-develop/overview-iot-plug-and-play
https://learn.microsoft.com/en-us/azure/digital-twins/overview#:~:text=What%20is%20Azure%20Digital%20Twins%3F%201%20Azure%20Digital,solution.%203%20Service%20limits.%20...%204%20Terminology.
IoT Central and Azure Digital Twin (ADT) are different, one is an aPaaS or application platform service while other is PaaS offering. IoT Central does not use ADT but the service can be integrated via the extensibility features of IoT Central, similar to PowerBI or custom web pages.
What is common to both is the use of open standard device modeling language called DTDL (https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/dtdlv2.md). It is based on Json-ld format and can be used in any IoT solution, not just Azure. This is what allows IoT Central application to understand device capabilities and automatically render related charts and control options (PnP)
ADT on other hand allows modeling and creating instances of large physical environments including but not limited to IoT devices and their relationships. The relationships between entities allows rich contextualization which is not possible with device centric view in IoT.

When Azure IoT Hub can be preferred over Iot Central?

I am not understanding when Azure IoT Hub can be preferred over Azure IoT Central. From the readings done so far, IoT central seems better over all the aspects.
Anybody can explain me where are the situations where IoT hub is better than IoT Central?
Thanks
There is no definitive answer to that question, neither are "better", but most of the times one will fit your use case more than the other.
If you want a complete, managed way of connecting devices to the cloud and create dashboards (within the product's limits), a Software as a Service solution like Azure IoT Central can be a match. Think about the requirements of the project you're looking to do, and if it's all supported by IoT Central, go for it! If there are some features you can build by leveraging data export from IoT Central, it might still be a great fit.
If you want to build bi-directional communication and device registration for IoT devices into your own cloud platform, IoT Hub comes into play. Maybe you need better control of the data, or maybe the data insights you need aren't supported by IoT Central. There are a lot of cases where it might not be the best choice. IoT Hub gives you a lot more flexibility that you can use to create almost any IoT scenario.
Both are not directly comparable, there are specific advantages of IoT Central which you may need to consider.
IoT Hub is a PaaS service which can be used with other services to create an IoT solution while IoT Central is IoT Application platform which can be used as-is or extended via companion application. Even addressing basic functionality in IoT Central you will need over dozen other services and you own responsibility to design, manage and administer the orchestration yourself.
IoT Central internally uses multiple IoT Hubs (HA/DR) and bunch of services to bring the functionality that you see in the application. This includes App Service to host the UX, Rules Engine, Fast Storage, API layer, Data Export, RBAC, in-app Multi-tenancy , etc. etc. The key advantages you get -
Full featured IoT solution with high availability, security, scalability that is available in < 10 secs under 99.9% SLA
Simplification, easy to connect any device or simulate basic capabilities using the built-in plug-n-play support. Just select any device from the pnp catalog and try it out even before purchasing the devices.
Create user or app level dashboards with device specific views. Device specific view can be auto-generated with PnP devices.
Rule creation, alerting and integration with other applications via Logic Apps, Functions
Data Export functionality to Event Hub, Service Bus, Blob Storage or Web hooks
Rich Job's interface allowing updating device configurations or firmware
RBAC in combination with Organizations allow giving specific permissions to user.
The big advantage is all this is available with a very simpler per device per month pricing that starts as low as 8 cents per device per month ($2 a year) + additional messages https://azure.microsoft.com/en-us/pricing/details/iot-central/
In general unless you already have UX, Storage, Rules engine, etc. elements required for IoT Solution and need to add IoT Hub to ingest and manage IoT devices it will make more sense to start with IoT Central and build with it. It will save time, efforts and you can focus on specific differentiation than build the underlying plumbing and owning the management and sustenance. It is difficult to come to that price point given the high cost of cloud engineers required to support and maintain it.
It is recommended that all customers begin their IoT journey with our aPaaS offering Azure IoT Central. IoT Central is a ready-made environment for IoT solution development. As an aPaaS offering it is built to simplify and accelerate IoT solution assembly and operations, by preassembling PaaS services from the IoT Platform (including IoT Hub and the IoT Hub Device Provisioning Service) and across Azure. A customer that starts with IoT Central builds valuable expertise regardless of whether they go to production with IoT Central, or later build a custom solution to meet complex business needs using PaaS services. To learn more about onboarding to Azure IoT check out this documentation: https://aka.ms/azureiotarch and stay tuned for a session at Microsoft Ignite Nov3-4th Entitled Onboarding to Azure IoT

How to differentiate the data in IoT Central coming from multiple similar sensors(Philips hue bulbs) to a gateway device connected to IoT Central

We have a Gateway device which is registered in IoT central application. This gateway device is connected to multiple similar Sensor devices such as Philips hue bulbs via ZigBee.
We are sending telemetry from sensors to IoT central via simple JSON
{"mac":"<mac address>","illumination":"200","bulb_status":"1"}
In IoT Central, we have registered our Gateway device as the IoT device with a device template which has telemetry properties related to Philips bulb and other sensors as well.
Now the challenge we are facing is, how to differentiate the data that is being sent by Philips bulb in room1 and Philips bulb in room2 in the IoT central as we have only 1 device registered in IoT Central.
The JSON has similar properties for both the bulbs and the telemetry values in IoT Central are being replaced by whichever device sends the last message.
Please provide me with the correct scalable approach for this kind of scenario.
Note: Consider our gateway device can't run IoT Edge runtime as of now. So we can't use it as Edge device.
There are two ways to tackle this. The first would be to program your gateway device to supply an identity to each of your bulbs. This means all your lamps will become a separate device in IoT Central (and you will be charged for them). Your gateway device will need to have the connection details for all of the devices it is sending telemetry for.
A second (not so pretty) way is to add a telemetry point to your interface for each lamp. So instead of brightness you would have lamp1_brightness and lamp2_brightness. I'm only including this in my answer because it is feasible and will result in seeing dashboard per lamp in IoT Central. It does not scale well either.
Eventually Azure IoT Edge will support Identy Translation, which can solve this and other questions
I have put up an E2E example of Nano BLE devices with data captured via a Central Gateway based on a Raspberry Pi using the Azure IoT Python SDK. This example is "in-progress", but I think you might find two files useful...
Main Project
https://github.com/Larouex/IoTCRaspberryPiProtocolTranslationGateway
BLE Project
https://github.com/Larouex/IoTCNanoBLESense33
File you might want to check out...
scandevices.py
https://github.com/Larouex/IoTCRaspberryPiProtocolTranslationGateway/blob/master/scandevices.py
This script uses BLEScan to find the BLE devices matching a naming pattern and writes them to a configuration file.
provisiondevices.py
https://github.com/Larouex/IoTCRaspberryPiProtocolTranslationGateway/blob/master/provisiondevices.py
This script and associated class use the Azure IoT SDK for Devices to read the devices in the configuration file and provision them in Azure IoT Central. The current code does a transparent approach and uses the identity of the BLE Device to provision and looks like a real device in Iot Central.
Over the next couple weeks I will continue to add the other scenarios like Opaque and Protocol Translation (which looks like the scenario you are interested in).
You may want to consider your differentiations of the Hues by modeling the locations and separate the telemetry values (versus plotting mac addresses), but you will hit some brittleness in versioning as you add or try to delete bulbs.
I recommend identify translation and associate each bulb with a model. Use the Device Groups for aggregate views. Then device properties because useful for location, etc.

Resources