Open dkby opened 3 years ago
I'd like to give this a vote as well. For my use case I want to dynamically provision new devices on the fly. I am using PnP and IoT Central but I need to set the device ID in the incoming message and provision the device if needed. I think my issue really is that this is an IoT Device Node and I need an IoT Central Node, however I do not see anything out there for this use case.
I see the need for being able to manipulate the Azure IoT Central device registry and provision devices. Though, this will need Azure IoT Central API keys to be exposed.
The focus of this node-red-contrib-azure-iot-device if for a single device, complete with D2C and C2D communication both for Azure IoT Hub and Azure IoT Central.
Please have these two abilities kept separately.
This feature request would fit "node-red-contrib-azure-iot-hub" better because that node is all manipulating the IoT Hub (not IoT Central yet).
@sandervandevelde I completely agree with your comments. I also agree that node-red-contrib-azure-iot-hub has all of the components and capabilities I am asking for, however since it does not support PnP it cannot be used with IoT Central from my understanding. From what I can tell node-red-contrib-azure-iot-hub is no longer being maintained. I am very surprised there are not better maintained libraries for connecting Node-Red to Azure. It almost makes me wonder about the validity of Azure IoT to be honest. Node-Red is hugely popular. If there are no well maintained Node-Red libraries for Azure then is anyone actually using Azure IoT and should we spend time developing product support for it?
Ideally I would like to setup a Node-Red flow that can on the fly provision new devices on an IoT Central application so they automatically appear there. Then data for those devices would feed into that IoT Central application via the newly created devices. If this were possible it would be amazing.
Hello @telliottosceola ,
Keep in mind, NodeRed is most of the time running on devices or services, outside Azure. This means, the 'masterkeys' of your Cloud service are put somewhere in an uncontrolled environment. See also my blog.
Microsoft provides a lot of SDKs and Rest API solutions for automating their services, including Azure IoT Central. If you can make HTTPS calls, you can control Azure IoT Central already, even from NodeRed.
You are always free to submit a feature request to Microsoft regarding NodeRed support for Azure IoT (Central). The team behind it has an very open mindset about how their platform can support customers.
@sandervandevelde thank you very much for your responses and your time. It is greatly appreciated. I know security is a big concern for IoT these days so I understand apprehension to store keys off of Azure resources. I am just trying to wrap my head around how the system we offer can be integrated to Azure in a simple to use way for the customer. The goal is to create a gateway devices which our sensors connect to. The user enters credentials onto the gateway device which allows it to provision devices and report their telemetry so when new sensors are powered up they automatically populate on IoT Central.
I will attempt reaching out to the Azure IoT Central team to see if they can provide insight as to how we can accomplish our vision.
For reference I am a design engineer for https://ncd.io. We have a large line of sensors we are trying to integrate into Azure.
If anyone should run across this thread in the future I am moving the discussion to stack overflow here: https://stackoverflow.com/questions/69904192/dynamically-create-devices-on-iot-central-from-node-red
Great stuff. Would like to try out this so I can blog about it :-)
Check out this this Azure Feedback forum for IoT Central.
Please share the link to the submission.
@sandervandevelde thank you very much for pointing that site out. I created a post there: https://feedback.azure.com/d365community/idea/b370e30c-ab41-ec11-a819-000d3ae2bec9
For certain applications, it makes sense to dynamically set parameters during runtime, independent from a re-deploy.
One example might be that the application wants to choose if mqtt, mqtt_ws, amqp oder amqp_ws should be used, depending on the environment a particular device is used in currently.
Generally, this feature would allow for more flexible applications integrating the node.
Following settings should be set via msg: