62 votesstarted · 9 comments · Azure IoT Edge » Installing IoT Edge runtime · Flag idea as inappropriate… · Admin →
@Supreet, the changes for x509 certs shouldn't effect modules. The x509 cert is used for the device to connect to IoT Hub. Please file a bug on our GitHub issues page (https://github.com/azure/iotedge/issues) if you're seeing differences in module behavior when you switch to using x509 certs.
@Hubert, we found a couple issues in RC4 which is going to push the release out to early February.
Servicing releases for 1.0.8 have taken priority over releasing 1.0.9. We're now shooting to have 1.0.9 out in mid January.
Hi Andreas, I'm just catching up on work after getting back from vacation. I hope you enjoyed the holidays.
Let’s try a concrete example to make sure we’re both on the same page. We have moduleFoo which sends messages to one output. A rule on Edge Hub then routes messages from moduleFoo to moduleBar; however it sends them to different input paths on moduleBar depending on some property set on the message. moduleBar then registers for all messages and takes different action based on the input path to which a message is sent.
Routing rules would look something like:
FROM /messages/modules/moduleFoo/* WHERE NOT IS_DEFINED(<message property>) INTO BrokeredEndpoint("/modules/moduleBar/inputs/input1")
FROM /messages/modules/moduleFoo/* WHERE IS_DEFINED(<message property>) INTO BrokeredEndpoint("/modules/moduleBar/inputs/input2")
moduleBar would register for all messages using SetMessageHandlerAsync. The callback registered would inspect InputName to determine if the message came in on input1 or input2 and then take action accordingly.
Hi Andreas, I believe this scenario should be unblocked today; however it will require a little custom code. You can register a default message handler using SetMessageHandlerAsync. This will receive all messages, regardless of which input a message is received on. From there you can inspect the full input hierarchy which is stored in the system property InputName. With that info the generic handler can delegate to more specific handlers.
1 voteAdminChipalo (Product Owner, Microsoft Azure) shared this idea ·
20 votesunder review · 3 comments · Azure IoT Edge » Connectivity issues · Flag idea as inappropriate… · Admin →
Hi Anonymous, this is still a feature gap for IoT Edge.
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.
This is still a very high priority for our team and we're trying to align all of our dependencies to deliver this. Progress has been far slower than desired as we've improved product stability and deliver fundamental features like device update, observability (the ability to collect logs and metrics from an IoT Edge device), and improved certificate management.
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.
This is a gap that we are aware of, want to fix, and are currently discussing with the Azure Sphere team.
We are making slow progress on this. The first step was fixing a bug dealing with how TLS certs are handled. There is additional feature work necessary to make this scenario work end to end.
35 votesplanned · 7 comments · Azure IoT Edge » Developing custom modules · Flag idea as inappropriate… · Admin →
Does the blob storage module not work for your scenario?
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.
We are aware of this OS and want to get to it; however CentOS 7.5 and Yocto are currently higher on our priority list.
We are discussing with Canonical how IoT Edge and Ubuntu Core can work well together. There is still no ETA for resolution on this.
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
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.
15 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.
12 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.