Azure IoT Serivce has a Device Template and a Device Twin. How are those two connected - I haven't found an article that clarifies that yet. What is the difference, how are they related? I assume the following: the device twin is derived from the properties,... of the device template.
Where can I find the raw device twin data in IoT Central?
You're correct that they're related - here's a summary:
The device template is an IoT Central only concept.
The device twins concept is applicable to both IoT Hub and IoT Central.
The Device Template defines the capabilities of a device that connects to IoT Central - the capabilities include the telemetry the device sends, the properties that represent the device state, and the commands that the device can respond to. IoT Central uses the device template to define a UI for the device letting you plot telemetry, manage properties, and call commands.
The Device Twin is an abstraction that lets you work with device properties both on the device and in the cloud. Conceptually, a Device Twin is a JSON representation of the device properties (state) that's synced between the device and the cloud. Some properties are read-only which means only the device can modify them. Some properties are read/write which means both the device and the cloud can modify them. A device twin is a useful abastraction for device and cloud developers writing code that interacts with device properties.
The part of the device template that defines the device properties, in effect defines the structure of the device twin that's shared between the device and IoT Central. In IoT Central, you can define views that let you see the device properties, and forms that let you manage read/write device properties. Because IoT Central has GUI tools that you can customize to work with device properties, the device twin concept is less important when you're working with IoT Central.
You can view the raw data that IoT Central receives from a device on the "Raw data" tab for a device:
Related
From https://learn.microsoft.com/en-us/azure/iot-develop/concepts-digital-twin#device-twins-and-digital-twins, it says "Along with a digital twin, Azure IoT Hub also maintains a device twin for every connected device. A device twin is similar to a digital twin in that it's a representation of a device's properties. An IoT hub initializes a digital twin and a device twin the first time an IoT Plug and Play device is provisioned".
I'm trying to understand where the digital twins and the device twins are kept. Are they part of the Azure IoT Hub?
There's another Azure service called Azure Digital Twins (https://azure.microsoft.com/en-us/products/digital-twins/). Is that where the IoT digital twins are kept? Even though I can see some devices and device twins in my Azure IoT Hub, I don't see any digital twins in Azure Digital Twins.
Your Azure IoT Hub maintains both the device twin and the digital twin - as the article you referenced describes, they use different JSON representations of the device state. There are separate APIs for each.
Azure Digital Twins is a separate Azure service that extends the concept of the digital twins maintained by IoT Hub. In ADT, the model can represent complex clients, such as smart buildings.
Is it possible to read events from IoT hubs in a way that we receive all status changes for IoT edge module installs? Possibly by receiving state changes to the edge agent reported properties of all connected devices?
Background: We are allowing users to "install" applications (represented by edge modules) on their edge devices on the fly through our own portal. We want to monitor changes to IoT devices and their modules, and note the changes in our database, so we can flag the corresponding apps as installed, removed, or failed.
Right now I can only find Event Grid based events for Device connected / disconnected events. I can also see that I can manually query the desired properties of each edge device's edge Agent separately. But since we will a large number of edge devices connected (>5000), polling them all just to see if something changed is not feasible.
Are the edge agent status changes of all IoT edge devices available as an event stream somewhere? Or is there a better solution?
IoT Edge's integration with Azure Monitor may help (docs). It has a module view that shows which modules are running and their availability. Since all the data is available in Log Analytics, you can create custom visualizations and processes using the data.
The Module twins in Azure IoT Hub shall help in below based on the information stored with it.
Monitoring the connectivity of the system
Monitoring the health of IoT Edge deployments
The Azure IoT Edge runtime has "IoT Edge Agent" as one of two modules that performs installation / initiation of modules and updating / reporting of the status of the modules to the IoT Hub. The $edgeAgent maintains the health and connectivity data about both the IoT Edge agent and IoT Edge hub runtime modules.
The Azure IoT Edge hub runtime maintains the data about communications between the "IoT Edge hub" running on the device and that of Azure IoT hub via the $edgeHub.
High level Overview :
Here is "Azure Monitor workbooks for IoT" that provides views couple of views :
An overview / state of active devices can be seen in the "Devices" View
Alerts display as per rules configured for the devices in "Alerts" View
Azure Monitor workbooks can be tuned for seeing data at any level (device state, app status) of interest. The public templates can be modified to meet the need/requirement in hand. The data shall fetched based on resource-centric KQL queries on the InsightsMetrics table.
Screenshot of Devices View :
Screenshot of Alerts View:
References :
Monitor Module Twins
Monitor Workbooks
I made a custom USB sensor device that runs on a Windows 8.1 / 10 desktop computer using the WinUSB driver (I implemented Microsoft extended USB descriptors in device firmware to automatically install the driver when the device connected).
Can I use a WinUSB device on HoloLens2? Or, if there is no WinUSB support on HoloLens2, how can I use my USB device with a “custom USB device class”?
At the moment, I do not have a hololens2, but I need to understand how the USB works on it.
Edit: I found this link: https://learn.microsoft.com/en-us/hololens/hololens-connect-devices#hololens-2-connect-usb-c-devices
It says that hololens2 supports the following device classes:
Mass storage devices (such as thumb drives)
Ethernet adapters (including ethernet plus charging)
USB-C-to-3.5mm digital audio adapters
USB-C digital audio headsets (including headset adapters plus charging)
Wired mouse
Wired keyboard
Combination PD hubs (USB A plus PD charging)
My device does not implement any of these classes (custom class). Is there a chance to make it work on hololens2?
I finally tested my code and USB device on real Hololens 2. The USB device works great there because Hololens2 supports WinUSB! The WinUSB driver was installed automatically (my device has WinUSB descriptors).
According to the documentation you referred, all classes HoloLens2 supports have been listed, and unlisted classes are not supported.
Could you provide more information about your business request and submit a feature request via feedback hub on new feature request to be considered in future releases of HoloLens OS and devices?
If it’s a hot impacted feature, it will be possible to be given priority to jump in the development schedule. Actually, the existing classed on HoloLens 2 are also based on user’s feedback in such way.
For how to post feedback request, you can follow this doc: Send feedback to Microsoft with the Feedback Hub app.
I need to connect some sensors to an Azure IoT Edge Runtime via MQTT.
I read here:How an IoT Edge device can be used as a gateway , that in the "Transparent" Pattern, devices who hold their own IoT Hub device identity can communicate directly with Azure IoT Edge via MQTT.
I am still in the planning phase and don't have the sensors (or Iot Hub devices) at the moment so I couldn't really start testing directly. I wanted to know if all devices/sensors can hold their IoT Hub device identity and if there are any hardware requirements in order to do so?
Thank you very much in advance!
In the transparent gateway case, the requirements for devices / sensors are the same as if the device would connect directly to an IOTHub using its identity. That is, if the device or sensor supports to Azure IOTHub via MQTT, it should work through the transparent gateway. When configuring the device, instead of using a connection string for the Azure IOTHub itself, you'd use a connection string that references the local Edge gateway.
There are 3 basic steps to take in the transparent gateway scenario - the article you linked steps into them, but I'll add in some color for 2 and 3.
Set up the gateway for connectivity from the downstream devices & routing to the upstream IOTHub. This article has good details.
For each device, create an identity in Azure IOTHub, using the device's unique ID (for example, device EUI for a lorawan sensor) as the IOTHub DeviceId, and set up auth per this article. This step is where you determine the Edge gateway connection string.
Connect the downstream device to the gateway device and start sending messages. That's this article. This is obviously dependent on the device itself and the operating code/configs (whether a 3rd party black box type device or something running your own code).
How do you add IOT Central credentials to a device (device id, scope id) - do you even need to do this?
In the following video a plugin and play device is just powered on, and then it is visible in IOT Central.
https://www.youtube.com/watch?v=rzTw1_AuxdQ
I don't understand how this works, as if no IOT Central specific credentials are added, wouldn't this device be available to everyone in their IOT central environments?
As this isn't the case, I presume these to be added to the device (somehow?)
You can find a summary of the options for connecting a device to IoT Central here.
This article illustrates the process with a specific device.
The recommendation for a production environment is to use X.509 certificates - you install a root or intermediate certificate into IoT Central and then configure your devices with leaf certificates generated from the root or intermediate cert.
You can also use SAS keys - you can use a group key to generate multiple device keys than you can use in a connection string.
As Matthijs mentioned, Plug and Play means that a device can be automatically associated with a device template so that a device can start sending data that IoT Central understands as soon as it connects.
You do need to add something to the device before you connect it. How this works differs per device, but the process involves generating an SAS key or leaf certificate. The picture below explains the general steps that are taken. In the case of Plug And Play, step 5 becomes obsolete because the device communicates its capability model and is automatically associated.