I'm looking into Azure IoT Hub and IoT Edge to understand capabilities and potential use cases roughly. One of the projects I had worked in the past had a strict requirement to disable cloud initiated contact and make things to work based on device initiated polling. For example, when certain settings are changed on the device management portal or new firmware is made available, rather than pushing this down to the devices, each device would become aware of this by polling periodically.
I have no control over this requirement but if that project is to be moved to Azure IoT, I'm certain that the same is going to be requested. Is there an easy way to achieve this with Azure?
I thought about tempering with the network access of the relevant containers but would this lead to the IoT hub going crazy and trying to communicate with 'unresponsive' devices continuously and flag all these failed attempts?
There are two parts to this quest: connections, and messages.
Connections
As far as connections are concerned, one of the security principles of IoT Hub is that the device is responsible for setting up the connection. Azure IoT devices by default do not accept incoming connections. The device sets up an AMQP or MQTT connection with IoT Hub, which will then allow bi-directional communication.
An exception to this is the HTTPS connection, if you use that method, the device will poll IoT Hub for new messages.
Messages
When the bi-directional connection is initiated from the device, this allows the device and IoT Hub to send messages to each other. For a non-edge device, if you don't use the SDK and write your (for instance MQTT) code yourself, you can decide not to listen to any of the incoming messages. You won't subscribe to topics like direct methods and twin updates and only look for them when you want.
For IoT Edge devices, bi-directional communication is handled by the Edge Hub. So your other containers (modules) don't talk to the cloud directly.
That leaves the Edge Agent, which also deals with outgoing connections only, it reports the status of the modules to the cloud.
In the comment of your question, you mention that the requirement is that the cloud can't initiate a connection with the device. In short, that doesn't happen, IoT Hub isn't designed that way.
Related
In our scenario, we have a bunch of devices that communicate locally with a gateway. The gateway is responsible to aggregate events from the devices and send it to the cloud. It should also receive device configuration changes from the the cloud and transport it to the specific device.
Based on my reading I would think that this is actually a typical IoT Hub scenario. And we would very much like to use the device management, messaging and maybe even twins that IoT Hub provides.
However, the way the devices communicate is already implemented and shall not be changed. That means the devices themselves cannot create connections and provide IoT Hub credentials. This rules out using the azure-iot-protocol-gateway or similar.
We would rather need the gateway to act as a device that can act on behalf of other devices. The gateway would detect which devices are in his local network and subscribe to their topics (via MQTT or AMQP).
Is this even possible? Can devices send events or listen to Cloud-To-Device messages in place of other devices?
Your scenario is a perfect fit for Azure IoT Edge:
https://learn.microsoft.com/en-us/azure/iot-edge/
"Azure IoT Edge is an Internet of Things (IoT) service that builds on top of IoT Hub. This service is meant for customers who want to analyze data on devices, a.k.a. "at the edge", instead of in the cloud. By moving parts of your workload to the edge, your devices can spend less time sending messages to the cloud and react more quickly to changes in status."
And I would suggest that you use IoT Edge as an identity or protocol translation Gateway:
https://learn.microsoft.com/en-us/azure/iot-edge/iot-edge-as-gateway
"Gateways in IoT solutions provide device connectivity and edge analytics to IoT devices that otherwise wouldn't have those capabilities. Azure IoT Edge can be used to satisfy all needs for an IoT gateway regardless of whether they are related to connectivity, identity, or edge analytics. "
I'm working on a IoT-solution that includes some physical devices where we don't control the hardware, and all communication is done via API:s. I would still like to utilize Azure IoT-hub for the messaging and management of these devices.
My idea is to create I device client and that runs in the cloud and integrates with the IoT-hub and the API:s. Is this a feasible strategy or am I on the wrong path? If, not what is the appropriate resource in azure for spinning up the clients?
If your devices are not capable of directly connecting to your Azure IoT hub then you have some alternatives. Yes theoretically you could create a device in the cloud that talks to the real device and forwards that data to your IoT hub. There are a couple of other alternatives. You could use an Azure IoT Edge Gateway. This will connect to the IoT hub and can represent multiple devices. You create an Edge Gateway module that can talk to your devices which will allow you to pass on the data for transmission to the IoT hub. It has a plug in module type of architecture. A product called the Protocol Gateway performs a similar function which might also meet your needs.
Our existing IoT Platform uses Azure Protocol Gateway and is working well. I just realized that MS Azure has launched a newer version for Protocol Gateway called IoT Edge. I was just looking for the new feature available in IoT Edge and now I'm completely confused between both components:
IoT Edge majorly supports local connectivity between device and
gateway. What if this is not part of my requirement? Should I still upgrade to IoT Edge?
I don't see any performance improvements -
Protocol Gateway vs Iot Edge
I understand that the answer could be a broader discussion but can anyone provide a simple explanation?
I recommend you read a bit about Edge Computing. IoT Edge is the MS solution for Edge Computing. It allows data processing and analysis nearest the IoT devices. This shortens the latency regarding some requests which have "critical time" requirements, since the data do not need to reach the cloud.
The IoT Hub is a protocol gateway. I think the main requirement here is not "performance". So, the point is not to compare between IoT Edge and IoT Hub. The key point about IoT Hub is the interoperability it provides between some common protocols used by IoT devices: AMQP, MQTT and HTTPS. It is more related to the ease of integration among IoT system components that may be using different protocols to communicate.
Azure Protocol gateway is required for conversion of protocols and ease of interoperability.
For example devices that do not hold their own IoT Hub identity but speak in different protocols, to make the conversation in a common meaning, the identity translation is required. The Azure Protocol gateway does this extensively. Once the uncommon protocols (i.e., Bacnet, OPC-UA, BLE, Proprietary) are used from several devices in the field, the Azure Protocol Gateway translates to IoT Hub Primities and send the data using MQTT, AMQP to the IoT Hub premises. This gives data transparency as well.
So in simple words azure protocol gateway helps in protocol translation while azure iot edge provides transparency and IoT Hub identity to the field devices.
It depends on the type of requirement or use case and the devices that you have with you.
In general, edge device is a device that sits closer to hardware but far away from cloud, which brings computation and data storage closer to the location where it is needed, to improve response times and save bandwidth. In scenarios where the latency could be high to send it to cloud and process it, the edge device shall be helpful in doing quick processing / analytics. Edge device brings out part of the activities that were done in cloud computing capabilities to local devices and hence reduce delays, increase processing and reduce security issues etc. Typical use cases are time critical scenarios like notification of key equipment malfunction or for a autonomous car to stop immediately, it is felt that to process immediately by having a node nearby and act upon rather than sending it all the way to cloud and act on it.
However, if there is a use case that the latency or bandwidth usage is not a constraint and there is processing hardware limitation, then it is preferred to send the data to cloud and have it processed. Here, a gateway is a device that collects data from sensors for the purpose of analytics, aggregation and translates to protocol that is required to communicate with cloud. Also, note that the protocols such as HTTP, AMQP, and MQTT are the default protocols that Azure IoT Hub supports for communication over the internet with devices or gateways. Few devices or field gateways might not be able to use one of these default protocols and will require protocol supports and in such cases, you can use a gateway that can enable a protocol wrapper for IoT Hub endpoints by bridging the traffic to and from IoT Hub, hence, avoiding any impact on your IoT implementation. This is where Azure IoT protocol gateway is helpful.
The Azure IoT protocol gateway is a cloud feature or framework for protocol adaptation and is a pass-through component that accepts device connections over a specific protocol and it bridges the traffic to IoT Hub. It is designed for high-scale, bidirectional device communication with IoT Hub.
The main difference is that protocol gateway is a cloud feature so whichever protocol your device uses, it needs to at least be able to send its messages to the cloud for protocol translation. However, the IoT Edge, as the name suggests it is part of edge computing and it sits closer to device. It runs locally and can communicate with devices on the local network before sending information to the cloud. And, of course, IoT Edge enables additional scenarios if you're looking to do other edge computing. Azure IoT Edge can also be used to satisfy any need for an IoT gateway as well, whether it's related to connectivity, identity, or edge analytics. Hence, there are three patterns for using an IoT Edge device as a gateway such as transparent, protocol translation, and identity translation which you can choose as per your deployment use case or requirement. IoT Edge device accomplishes this with the help of IoT Edge runtime .
In our scenario, we have a bunch of devices that communicate locally with a gateway. The gateway is responsible to aggregate events from the devices and send it to the cloud. It should also receive device configuration changes from the the cloud and transport it to the specific device.
Based on my reading I would think that this is actually a typical IoT Hub scenario. And we would very much like to use the device management, messaging and maybe even twins that IoT Hub provides.
However, the way the devices communicate is already implemented and shall not be changed. That means the devices themselves cannot create connections and provide IoT Hub credentials. This rules out using the azure-iot-protocol-gateway or similar.
We would rather need the gateway to act as a device that can act on behalf of other devices. The gateway would detect which devices are in his local network and subscribe to their topics (via MQTT or AMQP).
Is this even possible? Can devices send events or listen to Cloud-To-Device messages in place of other devices?
Your scenario is a perfect fit for Azure IoT Edge:
https://learn.microsoft.com/en-us/azure/iot-edge/
"Azure IoT Edge is an Internet of Things (IoT) service that builds on top of IoT Hub. This service is meant for customers who want to analyze data on devices, a.k.a. "at the edge", instead of in the cloud. By moving parts of your workload to the edge, your devices can spend less time sending messages to the cloud and react more quickly to changes in status."
And I would suggest that you use IoT Edge as an identity or protocol translation Gateway:
https://learn.microsoft.com/en-us/azure/iot-edge/iot-edge-as-gateway
"Gateways in IoT solutions provide device connectivity and edge analytics to IoT devices that otherwise wouldn't have those capabilities. Azure IoT Edge can be used to satisfy all needs for an IoT gateway regardless of whether they are related to connectivity, identity, or edge analytics. "
I want to create a 'hierarchy' of edge devices and using therefore the gateway mechanism. For the moment the gateway is just a transparant gateway, which passes the messages to the IoT Hub. (https://learn.microsoft.com/en-us/azure/iot-edge/how-to-create-transparent-gateway-linux).
Situation: I have two edge devices, say 'Sensor' and 'Gateway'. How do I specify the route in the deployment that the output of Sensor needs to go to the Gateway before going upstream to the IoT Hub?
Sensor route: "route": "FROM /messages/* INTO ???"
Gateway route: "route": "FROM /messages/* INTO $upstream"
For the current release of v2 IoT Edge (1.0, released in late June 2018), you can't chain edge devices together into a hierarchy. It's a needed feature for many scenarios, but not one we support yet (I'm on the Azure IoT Edge team). We plan to enable it, but I don't have a timeline.
The most immediate problem is this: The IoT Edge runtime builds a SAS-based connection string which it uses to establish a connection to the cloud on behalf of a device. The runtime only knows how to build a connection string that contains the hostname of your IoT hub:
HostName=<hub>;DeviceId=<device>;SharedAccessKey=<secret>
To connect to another edge device instead of your IoT hub, the connection string would need an additional piece of information--the hostname of the other edge device:
HostName=<hub>;DeviceId=<device>;SharedAccessKey=<secret>;GatewayHostName=<edge>
Because of the connection string, the edge device can only communicate with IoT Hub in the cloud, not the IoT Hub-like interface of another edge device.
That's an easy enough problem to solve, however beyond that we don't yet know if there are other blocking issues. Also there's work to be done to ensure the whole experience of creating edge hierarchies works and makes sense.