This document is not up to date related to the Module identities. Today, we can create under each device identity up to 20 module identities - https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-module-twins
As that document stated, each module identity has own independent connection to the IoT Hub. In other words, for example, if the _Device1_ has two modules such as _ModuleA_ and _ModuleB_, we have 3 connections to the IoT Hub such as Device1, Device1/ModuleA and Device1/ModuleB, haven't?
Notice, that all of them has own identity, security, primary key, etc. and of course a connection string.
So, I have taken for test purpose a _MQTT.fx -1.7.1 client_ to test a connectivity, direct method, twins, etc. for all 3 identities.
After some time I have figured out how to connect module to the Azure IoT Hub using a MQTT protocol directly.
_Broker Address_: {iothubhostname}
_Broker Port:_ 8883
_Client ID_: {deviceId}/{moduleId}
enable ssl/tls, CA signed server certificate
_username:_ {iothubhostname}/{deviceId}/{moduleId}/?api-version=2018-06-30
_password:_ {sastoken}
Everything is working like is described in the document about the device identity, in other words, when is connected only one of them. Notice, that there are 3 difference clientIDs such as _Device1_, _Device1/ModuleA_ and last one _Device1/ModuleB_.
The behavior of these 3 identities are like they have the same clientID on the IoT Hub (probably only Device1), because only one connection can be created and stayed active for the same clientID, what is typically for MQTT protocol.
There are missing any information in the documents related for connection of modules using the MQTT protocol directly.
In my test, I have successfully using the clientID = _{deviceId}/{moduleId}_, but it looks like the Azure IoT Hub somewhere internally doesn't accept a separator '/' in the clientID, isn't?
Anyway, my fundamental question is:
Can we open and keep all MQTT connections active to the Azure IoT Hub for device identity and its modules?
Am I missing something?
Thanks
Roman
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Hi @romankiss Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate. @rezasherafat
@romankiss quick update that we are working on this and will provide some feedback end of this month. Thanks for your great feedback and patience.
Hi @romankiss, I was able to repro this issue. We are investigating and I will get back to you on this issue soon. Thanks.
@romankiss we will publish some changes to the doc soon to address how to connect a module using MQTT Protocol Directly.
As for your other questions: "Can we open and keep all MQTT connections active to the Azure IoT Hub for device identity and its modules?"
We will take some time fixing it, though as soon as the doc has the updates can you please confirm if it is properly documented? I or @rezasherafat will then come back to this thread whenever the concurrency issue is fixed.
Thanks!
Thanks Antonio,
That's great, the issue has been found and it is going to fix it. I have figured out this issue during an updating my Azure IoT Hub Tester. I will wait for its publishing when the doc and service have been fixed and of course, I will send you my feedback.
Please, have a look at also the other reported issue such as https://github.com/MicrosoftDocs/azure-docs/issues/23805#issuecomment-459104095, it is related to Module Stream and it looks like the problem is also on the service side.
Thanks again.
Roman
@romankiss, for the time being I have updated the docs with the workings of modules via an MQTT client. I will keep you posted on the issue of module vs. device concurrent connection. Thanks.
@rezasherafat, thanks for updated document how to connect a module using the MQTT protocol directly. It looks OK. I do recommend to update also other parts of this document such as _Sending device-to-cloud messages_ and _Receiving cloud-to-device messages_ related to the module. Maybe adding new paragraphs with a name _Sending module-to-cloud messages_ and _Receiving cloud-to-module messages_ will be more clear.
I would like to notice, that the other document such as the Invoke direct methods on a device should be updated for a module identity, also.
Beside that, there are missing a document for current preview related to the _device streams_, something similar to the document for invoking direct methods with a name like _Invoking direct streaming on a device (module)._ IMO, the concept of the device/module streaming is based on the invoking direct method pattern on device/module, where the both sides (invoker and device/module) received an url and auth metadata of the common streaming bridge endpoint.
Thanks
Roman
Hi Antonio & Reza,
Any progress on the issue of the concurrency for active multiple modules within the device?
Thanks
Roman
Hi Antonio & Reza,
Thanks for fixing this issue of the concurrency for active multiple modules within the device. It looks like this problem has been resolved.
Thanks again
Roman
@romankiss, this issue should now be resolved. Please let me know if you still have any issue regarding module/device connections. Thanks!
@rezasherafat, I have tested (included also for new streams feature) and it works with device and multiple modules.
Thanks
Roman