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.
Related
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.
I want to implement the following system.
There are users and each user will have an IoT device. The user should be able to do the following:
Login with their email and password.
Control the IoT device in real time (the user will perform some operation on the IoT device and the result will be displayed instantly on the app).
See the state of IoT device in real time. If something changes on the IoT device it should reflect on the app in real time.
I was wondering if this is doable using azure IoT Hub. I came across an architecture where the device is connected to IoT hub and the app is connected to signalR. The messages from IoT device will go to IoT Hub which will update the app using signalR.
But is there any way we can not have additional component like signalR? Can IoT device and mobile app be connected directly to azure IoT hub and exchange data between them without an entity in between other than IoT hub?
Connecting mobile app to IoT hub seems like an option but I did not find any way to implement email and password based authentication to allow users to connect to IoT hub.
Any help in this regard is appreciated.
You could absolutely go without SignalR. You can use the IoT Hub Service SDK to send C2D messages to your device from your phone, and also listen to the device telemetry with the same SDK.
However, it would probably be a better idea to have some restrictions on what you can do with that SDK. If the user first has to log in, I take it that they don't get access to every device in your application? Using some kind of role-based access might be preferable, you would build an API for that, which then uses the Service SDK to give you the data.
Also, even though you could listen to the device data directly from your phone, that means that if you have bad reception/wifi, data might not be received. You might want to consider storing it somewhere? I don't know the details about your application, but if you would then want to listen to events from that storage and send it to your app... SignalR might not be the worst idea.
"See the state of IoT device in real time. If something changes on the IoT device it should reflect on the app in real time."
For this EventGrid integration (https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-event-grid ) would help. For realtime telemetry as Matthijs said SignalR would be a better choice.If you are fine with some delay (say 10 sec) then Azure Time Series Insights can also be used.
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.
Consider a device placed in no GSM area, i.e. underground or in a pipe or similar. Those devices needs to be updated, checked, enabled/disabled via smartphones of workers passing by. Does Azure IoT support some kind of solution to this? Meaning a smartphone would store a command to a device or to Azure IoT till it reaches connection to Web.
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.