I am designing a solution for connected devices and have a requirement to re-provision a device before sending a message to ensure it is always connected to the nearest IoT Hub (based on latency).
Based on the Microsoft documentation, it is possible to register a device using MQTT by publishing a message to the DPS. However, is it possible to re-provision a device with MQTT?
https://learn.microsoft.com/en-us/azure/iot-dps/iot-dps-mqtt-support
Also, when registering a device for the first time via MQTT, is there a topic to subscribe to obtain the connection of the IoT Hub that DPS assigned the device?
Yes. The same API (Register message) triggers re-provisioning. The device is unaware as to whether it is being provisioned or re-provisioned.
The results of provisioning (or re-provisioning) including the name of the IotHub and the corresponding credential are published in the DeviceRegistrationResult
object. This object is part of the RegistrationOperationStatus object returned in response to the get-operation-status operation.
As per the documentation page you are referring to, you can subscribe to dps/registrations/res/# to be notified of the progress of your (re-)registration request.
Related
I am working on device update or OTA implementation with azure. Azure has device update feature with IOT hub.
I am utilizing same service for my task.
I want to customized the IOT device update code for OTA operation.
Normally IOT HUB Service initiate the all action(Download, Install, Apply) and based on request device will be acted, once requested action done ,device will update the state to IOT hub service and go ideal state where wait for next action..
I want to add one additional layer or confirmation layer for each action[Download, Install, Apply)] , mean when IOT hub Service request for any action,
device will received as twin properties update. Instead executing the respective process(e.g. downloading the Firmware), device will wait for confirmation/ approval (which is customization part to be implemented ) from external/manual resource.
Once confirmation/approval received, device will resume with flow and execute the respective process( device will start downloading the firmware and update response to IOT HUB Service).
My Question based on above scenario as follow
Does it possible to implement above follow with current IOT HUB
device update implementation from azure.
What will happen if device not reply to IOT hub service for requested action ? Does it discard
the whole OTA process ?
What is time period of waiting for IOT hub service when it request for any action and waiting for reply ? My target to make wait for 30 days and if no approval or confirmation
receive the, reply back to IOT hub service with fail/Discard
response.
Can I make 30 days waiting period for IOT hub service API
response ?
Please answer me as soon as possible. As most of development depend on it.
Regards,
Gaurav Choubey
The Device Update Agent (installed on your device) will be responsible to set the "update status" as started succeeded , failed or idle.
As per your scenario and since Device Update Agent is open-sourced you can customize the Interface and Platform Layers to achieve it. IoT Hub should not be impacted by 30 days or more waiting period for the update to be completed.
I have an Azure IoTHub with thousands of devices registered. These devices communicate through a Telco provider who sends messages through an Azure Storage Queue. This Storage Queue triggers an Azure Function which needs to parse the messages and Send an Event to the IoTHub as below.
Currently, we use the Azure IoTHub SDK to create a DeviceClient for each payload and we send the event. Because the DeviceClient represents a device in the IoTHub and is carrying the context of the source of the events, we are having to recreate a device client for each event. This quickly exceeds the threshold of the number of Connections allowed on Azure Functions.
We have tried using the IoTHub Output bindings for Azure Functions, but could not get to work and I do not think it would work because we need to make sure that the events get to the IoTHub with the right context (messages are sent by the right device).
What's the right way to solve this? Can the connections to the IoTHub be reused? Should we abandon Azure Function in favour of something else?
I assume that Telco is some kind of custom device management solution(vendor lock solution), that can also communicate with the device and receive the device telemetry, and eventually forward it to the specified endpoint, correct?
If I may ask and if my assumption is correct, why do you need to deliver the events to IoT Hub, if you are not managing Telco devices through IoT Hub(the arrows on your diagram are only in one direction)?
Using the IoT Hub just as a message broker for essentially cloud-to-cloud communication is not beneficial if that is the only purpose. Also conceptually what you described is cloud-to-cloud communication, and IoT Hub is intended to be used for devices.
Here is what I would do. Setup the API Management(or http triggered Azure Function) as a front door for Telco and pass the messages to the Event Hub.
You can choose here to pass request body for example where your telemetry data is - I assume again.
Keep the IoT Hub, and setup the routing to previously created Event Hub.
Now, in case you have devices that are not vendor locked and that can talk directly to IoT Hub, messages will be re-routed to Event Hub. Also Telco device messages will be routed to exactly the same Event Hub.
Now you can have for example Azure Stream Analytics that can analyze data stream just from the Event Hub, and for both, Telco devices and potentially non-Telco devices.
After trying a few things, I ended up moving away from using the SDK for pushing messages to IoT Hub. This is because the SDK uses AMQP, and creating a DeviceClient for each payload is not viable.
We switched to using HTTPS instead to push the messages to IoT Hub and using HttpClientFactory, we are able to do connection pooling.
I thought I would put this here in case someone has the same issue.
Here is an example of the Http request to send message to IoT Hub
Host: https://<iothubname>.azure-devices.net/devices/<deviceId>/messages/events?api-version=2018-06-30
Authorization: SharedAccessSignature sr=<iothubname>.azure-devices.net&sig=abc123;12344iweoippweruea=iothubowner&se=1570574220
Body: <normal Interval or alarms payloads> // example {"deviceid": "abc", "hello": "world"}
Lastly, thanks #kgalic for the answer but your suggestion would not work. This is not pure B2B integration. Our implementation have to allow for both devices connecting directly to the IoT Hub and devices connecting through the Telco. This is why every device needs to have its own identity and digital twin.
I am currently looking for a way to revoke the device session of a device that is connected to the Azure Iot Hub.
For example, when a device connects using a certificate and the certificate expires, the device can still send and receive data while it has a valid token.
Our case is if a device overloads our IoT Hub for whatever reason, we would like to be able to revoke the connection immediately.
We want to be able to revoke such token in order to immediately disconnect a certain device.
Is it even possible to do so? If not, are there workarounds for that?
You can disable a device to connect to the IoT Hub. I just tried this with a simulated device (using the .NET SDK) that was actively sending data. After I turned the switch to Disabled, the connection broke off after a few seconds. This was using the device key, not certificates but I would assume this might work as well.
There is no such as the REST API in the Azure IoT Hub to disconnect connected device. However the following workarounds can help it:
Based on the MQTT Device protocol, only one device with the same ID can be connected to the Azure IoT Hub, so connecting the same device (simulated the same ID) will automatically disconnect a connected one. This workaround doesn't require any change in the device code. You can test it using a tools such as MQTTBox, MQTT.fx, etc.
This workaround is based on invoking a device method to perform closing a device from the device side. You can create a job for Azure IoT Hub background process to "invoke device method". Note, that this workaround needs to built this feature into the device code.
Also, using a notification event on the twin desired property change received by device side can be used for your workaround to perform a closing or re-connecting connection with an Azure IoT Hub.
Edit:
Like #silent answered, changing the state Enable to Disable, the device is going automatically disconnect from the Azure IoT Hub. You can use a REST API to change this status.
I do recommend to built in the device some retrying policy for re-connecting a device to the Azure IoT Hub based on the disconnecting reason such as connection lost, user disconnected, etc.
In my case I have 1000+ of devices that stores activity inside. I need to send a http get request to this device to get those data in csv or json format and save it in a storage hosted on azure.
Cab IOT hub require data using get request and can it be scheduled to read daily/weekly?
What other azure services would you suggest to facilitated this scheduled reads?
You have not mentioned which the Azure IoT Hub scale tier is used. Basically there are two price groups such as Basic and Standard with a significant different cost and capabilities. The Basic tier offers only services for one-way communications between the devices and Azure IoT Hub.
Based on that, the following scenarios can be used for your business case:
1. Basic Tier (non event-driven solution)
The device pushs periodicaly a telementry and non-telemetry messages based on the needs to the Azure IoT Hub, where the non-telemetry messages are routed to the Azure Function via the Service Bus Queue/Topic. Responsibility for this non-telemetry pipe is to persist a real device state in the database. Note, that the 6M messages will cost only $50/month. The back-end application can any time to query this database for devices state.
2. Standard Tier (event-driven solution) In this scenario you can use a Device Twin of the Azure IoT Hub to enable storing a real-device state in the cloud-backend (described by #HelenLo). The device can be triggered by C2D message, changing a desired property, invoking a method or based on the device edge trigger to the action for updating a state (reported properties).
The Azure IoT Hub has a capabilities to run your scheduled jobs for multiple devices.
In this solution, the back-end application can call any time a job for ExportDevicesAsync to the blob storage, see more details here. Note, that the 6M messages will cost $250/month.
As you can see the above each scenario needs to build a different device logic model based on the communications capabilities between the devices and Azure IoT Hub and back. Note, there are some limitations for these communications, see more details here.
You can consider using Device Twin of IoT Hub
https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-device-twins
Use device twins to:
Store device-specific metadata in the cloud. For example, the deployment location of a vending machine.
Report current state information such as available capabilities and conditions from your device app. For example, a device is connected to your IoT hub over cellular or WiFi.
Synchronize the state of long-running workflows between device app and back-end app. For example, when the solution back end specifies the new firmware version to install, and the device app reports the various stages of the update process.
Query your device metadata, configuration, or state.
IoT Hub provides you with the ability to connect your devices over various protocols. Preferred protocols are messaging protocols, such as MQTT or AMQP, but HTTPS is also supported. Using IoT hub, you do not request data from the device, though. The device will send the data to the IoT Hub. You have to options to implement that with IoT Hub:
The device connects to the IoT Hub whenever it has some data to be sent, and pushes the data up to IoT Hub
The device does not send any data on its own, but stays always or at least regularly connected to IoT Hub. You then can send a cloud to device message over IoT Hub to the device, requesting the data to be sent. The device then sends the data the same way it would in the first option.
When the data then has been sent to IoT Hub, you need to push it somewhere where it is persistently stored - IoT Hub only keeps messages for 1 day by default. Options for this are:
Create a blob storage account and push to that directly from IoT Hub using a custom endpoint This would probably be the easiest and cheapest. Dependening on how you need to access your data, a blob might not be the best option, though
Create a function app, create a function with an EventHubTrigger, connect it to IoT Hub and let the function process incoming data by outputting it into any kind of data sink, such as SQL, CosmosDB, Table Storage...
From Azure development guide https://azure.microsoft.com/en-us/documentation/articles/iot-hub-devguide, there is a small section (shown as below) talking about device anti-spoofing. It is not clear for me, it says IoT hub stamps every message with properties, but for me device anti-spoofing is that IoT hub to stop receiving messages sent from any spoofed device. Please help to explain how does this work?
Anti-spoofing properties
To avoid device spoofing in device-to-cloud messages, IoT Hub stamps
all messages with the following properties:
ConnectionDeviceId
ConnectionDeviceGenerationId
ConnectionAuthMethod
In IoT Hub there is a device registry that is used to authorize devices to the gateway. After authentication the device is checked against the registry.
When a device is registered with IoT Hub, the device's identity and key are saved in the device registry. This device and key is what the device uses to authenticate to the service.
The generation ID is a key part of this too. When the device is first registered with IoT Hub, a generation ID is assigned to the device. The purpose of this is to distinguish between identity registrations of the same device ID (added, removed, and then later added).
If you're interested in a deeper dive into the IoT Hub architecture see Clemen's 2015 Build talk here.