Azure IoT Edge
Azure IoT Edge moves analytics and logic out of the cloud and onto your on-premises devices. Using a cloud interface, you can deploy either Azure service logic or your own code to devices without having to physically access them. And offline capabilities mean that you can extract business insights anywhere, without worrying about maintaining constant communication with a cloud service.
More details about the services are available in the documentation.
-
Make IoT-Edge (V2+) usable (again) in products which require both OnPrem and OnDemand deploy
In many industries (e.g. medical, energy, aeronautics) companies must produce products that can also be installed in environments where no internet connectivity is available/permitted. These same products however, are also often installed in places where they can leverage cloud (OnDemand) capabilities. If IoT-Edge ist to be applicable for such products, it must (by design) provide for:
1. Installation from download or USB-stick including configuration via config file or local API (as did Edge V1)
2. Provide and abstraction layer to the external communication (as was done via Edge V1 Modules) enabling a configurable routing to use OnPremises endpoits (REST) or…56 votesHi Richard, item #3 has been addressed with the public preview of extended offline feature work. You can find out more about it at the blog post below. The rest of the issues you raise will take longer for us to add to the product.
https://azure.microsoft.com/en-us/blog/extended-offline-operation-with-azure-iot-edge/
-
Support Ubuntu Core
Add Ubuntu Core as supported Operating Systems. It is becoming a preferred "secure by default" OS which is preinstalled on many IoT Gateways. E.g. Dell Edge Gateways
41 votesWe are aware of this OS and want to get to it; however CentOS 7.5 and Yocto are currently higher on our priority list.
-
(Cloud-triggered) IoT Edge Runtime Updates
Provide a way of an (automatic) cloud-triggered update mechanism for the IoT Edge Runtime through IoT Hubs Device Management. Providing update capabilities not only for the containers but for the runtime and even the underlying OS is crucial for IoT Scenarios.
16 votes -
More options, or configuration parameters, of storeAndForwardConfiguration
storeAndForwardConfiguration has a parameter, timeToLiveSecs to specify offline period to retain data.
Preferable to add following 3 parameters to storeAndForwardConfiguration
1. Limit the amount of disk usage to be used for SnF feature.
2. Specify the directory/path of storage for SnF feature
3. Flush un-forwarded messages in SnF memory out to specified files11 votes -
Add Raspbian Buster as a Tier 1 OS
Add Raspbian Buster as a Tier 1 OS
8 votesRaspbian Buster definitely works with IoT Edge; however CentOS, Debian, and Yocto currently have higher priority in terms of getting them into the test gates.
-
Force reprovisioning of the IoT EDGE Daemon locally
Provide some kind of configuration of the IoT Edge runtime where I can select the provisioning scenario which works for me. That means, forced reprovisioning is facilitated by the IoT Edge Runtime.
This way, eg. an IoT Edge on the move can start reprovisioning on its own to find the nearest IoT Hub without interrupting local compute (data ingest, transformations, executing ML, Executing actions).
Rebooting an IoT Edge just to force reprovisioning is not an option. The logic on the device has to run 24/7. Lack of internet connectivity (either no internet connection of during reprovisioning to a new IoTHub)…
7 votesWe’ve completed our feature planning for the second half of 2020. We’ll consider this when we do feature planning for the first half of 2021.
-
Any plans to support Yocto on ARM32?
This post: https://docs.microsoft.com/en-us/azure/iot-edge/support indicates that Yocto on ARM32 is not supported. Will it be? And, if so, will the ARM Python SDK for IoT Edge (suggested here: https://feedback.azure.com/forums/907045-azure-iot-edge/suggestions/34976278-arm-python-sdk-for-azure-iot-edge) work on Yocto?
6 votesWe have published preview layers for IoT Edge on Yocto – https://github.com/azure/meta-iotedge. There is still work to be done before this becomes a Tier 1 OS; however you can start playing with it and providing feedback now.
As far as Python support, you should probably be able to build a Yocto image that supports Python. You’ll have to include the layers required by the Python SDK. This SDK is going through a rewrite at the moment; however you can see a preview at – https://github.com/Azure/azure-iot-sdk-python-preview
-
Support for aarch64 based platforms
It would be great if support could be extended for deploying the run time on aarch64 based platforms, a lot of industrial platforms being launched on the market are based on Cortex-A53.
5 votesPreview support for ARM64 is available in the 1.0.8 release.
-
Raspberry Pi Zero W / ARMv6 support
Please add support for Raspberry Pi Zero W / ARMv6
4 votesNo one on our team has explicitly tried this. It may work but we’re not hopeful. The biggest issue is that .NET Core doesn’t support armv6-hf.
-
IoT Edge for Azure Sphere
I know currently MediaTek Azure Sphere chips aren't very powerfull. But, it looks like the NXP Azure Sphere chips will have more compute power. It would be pretty sweet to be able to combine the enhanced security features of the Azure Sphere platform with building Azure IoT Edge devices and gateways.
Are there any plans to support running the Azure IoT Edge runtime on Azure Sphere devices?
4 votesRunning IoT Edge on an Azure Sphere device would be interesting; however it’s not planned at the moment. I’m not sure how powerful the NXP chips are; however you are correct that we would need a more powerful Azure Sphere chip than are available today. Additionally there may be some other issues we need to address in terms of authenticating with the Azure Sphere Security Service.
The first step for integration with Azure Sphere will be allowing them to gracefully connect to an Azure IoT Edge device.
-
Iot Edge on Windows 10 Iot Core on RaspBerry Pi 3B
Windows ARM architecture is not yet supported by IoT Edge. AMD64-based IoT Core platforms should work. I want the iot edge can work anywhere iot core was installed.
4 votes -
Need better parent child relationship with IoT Edge
• The Parent/Child relationship between edge and leaf devices is too restrictive for our application. We have customers that are load balanced across and within physical locations, and our devices need to roam both with and without internet connectivity. If the child device concept could be extended to contain entire deployment groups based on a certificate chain, that would be preferred. Then each of our customers could have their own intermediate certificate with each of their devices as a leaf; and that intermediate certificate could be tied to each of their Edge appliances
3 votes -
Provide placeholders for modifying config.yaml in Linux IoTEdge CLI
In Windows IoTEdge installation, we can provide values for placeholders in config.yaml file while initializing iotedge. For example:
. {Invoke-WebRequest -useb https://aka.ms/iotedge-win} | Invoke-Expression; ` Initialize-IoTEdge -Dps -ScopeId {scope ID} -RegistrationId {registration ID}
In case of Linux, there is no way to do this. If we automated IoTEdge installation using a script, we have to manually search and replace the corresponding lines in config.yaml. It would be better to have CLI level arguments to modify the config.yaml.
2 votes -
Allow installation of IOT Edge (runtime) on Windows to a different directory and drive location.
In an enterprise environment we are often restricted to where we are allowed to install software. For example all installed software should be on the D drive in Programs directory.
This is currently not possible with the iot edge runtime without modifying the IOT Edge standard installation scripts.
2 votes -
Provision of IoT Edge Security Damon package for Tire 2 system
For the Tier 1 system, the latest IoT Edge Security Damon package is provided in the package repository (https://packages.microsoft.com/)
But for the Tire 2 system, it is not provided.
For example, for Ubuntsu 18.04 of Tire 1, iotedge1.0.4-1amd64.deb is provided, Regarding Debian 9, it still iotedge1.0.0-1amd64.deb yet.
Our products use Debian 9, and we are asked to provide packages that fix bugs from customers.
We will to build it localy and provide it at our own repository, What do you think?2 votesWe plan on hosting the Debian packages on packages.micrsoft.com once we move Debian to Tier 1 support.
I like your temporary workaround of publishing them to your own repository. You don’t even need to build them locally. We provide them with each release. For example, you can find the rpms for the 1.0.6 release at – https://github.com/Azure/azure-iotedge/releases/tag/1.0.6.1
-
change default communication ports used for amqp https
We have a shared endpoint NGNIX where all device communication is ending on our network. Based on protocol and ports we configure forwarding rule towards the iot hub.
Is this supported to configure https mqtt to custom port rangens instead of the following
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-protocols1 voteI didn’t quite understand your question. Are you trying to use NGNIX as a proxy for your network traffic? If so, does this documentation help?
https://docs.microsoft.com/en-us/azure/iot-edge/how-to-configure-proxy-support
-
Installing IoT Edge Runtime on Core OS.
CoreOS is one of the popular container OS in the market.It will be great idea to install Azure IoT Edge Runtime(EdgeAgenet,EdgeHub,iotedged bootstrap security daemon) on Core OS.
As per https://docs.microsoft.com/en-us/azure/iot-edge/support#operating-systems CoreOS is neither in Tier-1 nor tier-2 OS list for IOT EDGE RUNTIME.
1 voteWe do not have plans to support CoreOS. CentOS, Debian, and Yocto currently have higher priority.
-
Support powerpc architecture
Does Azure Iot Edge Support powerpc architecture ?
If not, do you plan to support it ?1 voteWe do not support power pc and there are no plans to do so.
-
Environment variable $IOTEDGE_CONF needed instead of hard-coded path in scripts and executables
With respect to your declared environment variables (given in "./edgelet/iotedged/src/lib.rs", and "./edgelet/iotedge/src/main.rs"), they cover almost every aspect, except, an environment variable, which could replace the hard-coded path "-c /etc/iotedge/config.yaml" to something like "-c $IOTEDGE_CONF". The variable could either be set in scripts, or the iotedged service/daemon/manager, itself, with a default path, if its value is not already given by an argument or defined in an environment variable.
1 voteHi Henrik, at this time we don’t plan on adding an environment variable to control this; however you may not be blocked.
This is already configurable in the `iotedged` executable via the `-c` option. The `iotedge check` has a `-c` option as well for setting this file location, because it reads the config file. (none of the other iotedge subcommands read the config file).
The only scripts related to this are in the packages and installer. However, the installer places this file in a very specific place and the executable needs to have a matching location. We actually don’t use the default anywhere. The linux packages directly specify the location: https://github.com/Azure/iotedge/blob/master/edgelet/contrib/systemd/iotedge.service#L8 And, the windows service directly specifies the location: https://github.com/Azure/iotedge/blob/master/edgelet/build/windows/iotedge.wm.xml#L60
- Don't see your idea?