We have a gateway device(not running IoT edge runtime). We want to connect multiple BLE or Zigbee sensors to the gateway and provision/register them through our gateway device to IoT Central as different devices using group symmetric key approach.
We have seen multiple sample codes for the provisioning and registering the devices using group symmetric key to generate device-specific SAS key. But these don't have an approach for handling multiple device clients after registering and connecting to IoT Central
python sdk provisioning with group symmetric key
iot_central_python_sample
After connecting the device we need to use device client of the SDK to send telemetry and receive commands to/from IoT Central.
Consider if we want to use the same code for multiple sensors, we need to have multiple device clients(threads) running.
Please suggest a better approach to handle multiple devices for sending telemetry and receiving commands to/from IoT Central
This might help with your use case: https://github.com/Larouex/IoTCNanoBLE33
Related
We're moving our Azure IoT Edge devices from manual provisioning to DPS with symmetric key. One of the modules deployed to our devices needs to manage the Device Twin - we have been using this for state properties that persist across updates to modules. To connect to the device twin, I've been creating a DeviceClient from connection string which is loaded as an environment variable on a per device basis. This is using the C SDK.
Now I want to request the device credentials during provisioning so that the symmetric key is the only secret pre installed on the device.
A number of posts suggest that this isn't possible with best practices, most succinctly:
Access IoT Edge Device Twin from Edge Module when using X.509 Authentication
Is this still the case? If so, what is the intended use for the device twin on IoT Edge, if user modules aren't supposed to access it in a production setting?
A number of posts suggest that this isn't possible with best practices, most succinctly: Access IoT Edge Device Twin from Edge Module when using X.509 Authentication. Is this still the case?
This is still the case. Modules accessing device twin information is not supported or recommended. There are other ways to achieve what is desired - like one you described in your comment.
what is the intended use for the device twin on IoT Edge, if user modules aren't supposed to access it in a production setting?
The use case for device twins in IoT Edge is ADM deployments.
You create a deployment manifest and then define which devices it applies to based on tags in the device twin.
Ref: Understand IoT Edge automatic deployments for single devices or at scale
Context:
I have a real device that only uses MQTT and only accepts a TCP connection (The only things I can modify in the real device are the cloud address, cloud ID (username), cloud password, machine cloud ID and cloud port).
Question:
How can I connect this device to the azure IoT hub?
Can I use azure IoT edge runtime w/ transparent gateway?
In case if you want to try connectivity with IoT hub and if there is no feasibility for usage of device SDK in your device, you can try the option of using MQTT protocol directly (as a device), using which the device can still connect to the public device endpoints using the MQTT protocol on port 8883.
However, for using the MQTT protocol directly, the device must connect over TLS/SSL. Since your device has constraints in using TLS/SSL or installing certificate, the best option is usage of gateway.
In a typical IoT system, gateways are used to overcome the limitations of device capabilities. You may need to decide the suitable deployment type based on these three patterns of using IoT Edge device as a gateway as per your device capabilities and requirement in hand.
There is a scenario where you don't have to use the device SDK and connect your MQTT device directly to the IoT Hub. It is documented here. Azure IoT Hub is not a full-featured MQTT broker though, so results may vary. As per your suggestion, yes you can use a transparent gateway for this if you don't want your device to connect directly to the IoT Hub. But it's not a prerequisite.
In the case that your device needs more MQTT features than IoT Hub (or Edge for that matter) can offer, you can also consider creating an Edge module with an MQTT broker inside.
I want to enable IoT in the devices (inverters) which currently supports only serial communication. Through serial port I'm able to view statistics of the device, configure device and do firmware updates. I want to do all these remotely by enabling IoT. I have just gone through Azure IoT hub, iBOT etc.
How will I enable communication between my serial port with IoT hub?
Is there any supporting device for that?
You can use another device as a gateway, this device is networkable and has serial port. Azure IoT Edge lets you build IoT solutions tailored to your exact scenario. You can refer to the document and get start.
In addition, here is a tutorial to implement a device firmware update process. This tutorial shows how you can start and monitor the firmware update process remotely through a back-end application connected to your hub.
I am creating a few function app samples and one use case is updating software for a device on the international space station. Anyone know what protocol is used?
Azure IoT Hub supports three protocols: AMQP, MQTT, and HTTPs.
Choose AMQP or MQTT except for the device only support HTTPs.
Choose AMQP if that require connecting multiple devices over the same TLS connection.
Choose MQTT if the device has limited resources (for example, less than 1-MB RAM) because it has a smaller footprint than the AMQP libraries.
It depends on your concern.
Reference - choose a communication protocol
I'm assuming your devices are connected through IoT Hub.
You can follow the device management patterns: https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-device-management-overview
Specifically: Firmware Update. Which should be similar to updating software.
Device Twin should be used for IoT devices regarding management since devices can't guarantee "always online" connection. In the case of device twin, a state cache is stored in IoT Hub, when the device reconnects it can retrieve the updated state from cloud and update the device accordingly.
Goal: Send messages to a group of Azure IoT Hub Devices that are connected via MQTT WebSocket.
Initial Idea: Have a group of IoT Hub Devices (group X) subscribe to messages with topic X.
Problem:
On the Communicate with your IoT hub using the MQTT protocol docs, I don't see a way to subscribe a device to additional topics. I only see examples of a subscription to a device specific endpoint devices/{device_id}/messages/devicebound/#.
The page goes on to say "IoT Hub is not a general purpose pub-sub messaging broker, it only supports the documented topic names and topic filters." I think those topics are
devices/{device_id}/messages/devicebound/
devices/{device_id}/messages/devicebound/#
My Conclusion: I can't have a group of IoT Hub Devices (group X) subscribe to messages with topic X.
Questions:
Is my conclusion correct?
If my conclusion is correct, is there another way I can send messages to a group of Azure IoT Hub Devices that are connected via MQTT WebSocket?
Your conclusion is correct. Azure IoT Hub is not an MQTT broker per se.
If you want to send messages to a group of devices connected to Azure IoT Hub (independently of the protocol they are connected with), you need to look into one of the Cloud 2 Device features of IoT Hub.
Depending on your scenario you can use one of the following: Cloud 2 Device messages, Twins or Methods. IoT Hub exposes APIs on the back-end side (easily used with the Service Client SDKs) allowing to use any of those.
C2D messages are used to send raw data to devices, meaning you implement your own "protocol" between cloud and device. C2D messages are also persistent in the Cloud as IoT Hub will retain them (for a certain time defined in settings) if the device is not connected.
Device Twins allows to synchronize a configuration of a device with the Cloud and allows for batch operations on devices (certainly one you want to look closer into).
Device Direct Methods allows to call a function running on a device from the cloud and like Twins supports batch operations.