The limit has indeed been raised to 20. We’re interested to learn about scenarios that require more than 20 modules.
Hi Leon, you have a very valid scenario we refer to as identity translation (you can read more at the link below). In this setup you would have 4 modules, one for each sensor type. Each module would then span a new process for each instance of the particular type of device that connects. That new process would use a device identity to connect. This way each downstream device will have its own twin that can be used for configuration.
That said, we also have not provided a code sample for identity translation yet. This is an item that's high on our list. You can track our progress at the User Voice request for it - https://feedback.azure.com/forums/907045-azure-iot-edge/suggestions/32497981-code-sample-for-identity-translation-pattern
Edge device as a gateway - https://docs.microsoft.com/en-us/azure/iot-edge/iot-edge-as-gateway
29 votesplanned · 6 comments · Azure IoT Edge » Developing custom modules · Flag idea as inappropriate… · Admin →
The Blob Storage team has released a module for IoT Edge devices. This is a good option for some solutions until more native support for upload to Blob Storage is built into the product.
Here's a temporary workaround that I know folks have used.
Write a custom module with the Blob SDK for communication with Azure Blob Storage. Use the module twin to send the credentials for the blob down to the module. Use those credentials from the twin in the module to establish a connection to your storage and upload the desired data.
The problem with this solution is that the network must expose multiple ports to your Edge device (port for communication with IoT Hub and port for communication with Blob Storage). This is not case for many locked down networks. Our long term solution will allow communication with Blob Storage to be conducted over the port used for communication with IoT Hub.
Unfortunately we do not have a good timeline for you on this feature.
17 votesunder review · 2 comments · Azure IoT Edge » Connectivity issues · Flag idea as inappropriate… · Admin →
The scenario you describe is correct.
To be explicit, the only thing that is not supported right now is C2D messages to a module in an Edge device. C2D methods to a module in an Edge device are supported. Also, both C2D messages and C2D methods to devices behind an Edge device acting as a transparent gateway are supported.
8 votesneed-feedback · 5 comments · Azure IoT Edge » Connectivity issues · Flag idea as inappropriate… · Admin →
Are you trying to achieve high availability/disaster recovery? The feature here would be making sure groups of edge devices have the same view of messages queued for the cloud?
Just to make sure I understand the scenario...
You have multiple edge devices that need to share data. This is usually done by sync it to the cloud and letting each edge device retrieve the desired data from that cloud store. You are asking for a feature that lets these edge devices share data locally only while the devices do not have a connection to the cloud.
14 votesplanned · 8 comments · Azure IoT Edge » Developing custom modules · Flag idea as inappropriate… · Admin →
We do not have an ETA for this item.
Hi Remco, we hoped to have the sample out by now; however we hit some issues around hardware access from containers. These are features that I'm sure others are hitting and need to be addressed first.
1. Yes, we plan on publishing a sample for the SensorTag device which speaks BLE.
2. Correct, use Container Create Options to elevate privilege of a container.
A temporary work around is sending the connection strings in the twin of the module. The longer term approach requires integration with Device Provisioning Service. That is work in progress.
10 votesunder review · 2 comments · Azure IoT Edge » Deploying modules · Flag idea as inappropriate… · Admin →
A BACnet module is something we're considering; however it is not a goal for Microsoft to provide a variety of protocol adapters. There are numerous protocols, many of which are proprietary. Folks have many years of expertise dealing in these and Microsoft is not looking to replace that.
We've designed Azure IoT Edge to be extensible so that the community and partners can provide their expertise in the form of modules.
This is definitely a feature which is on our radar. Additional dev experience improvements we're considering are tools to help you debug modules and unit test modules.