azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None caused by Paho returned rc==1 caused by None

SDK Version: 2.0.0 like this:

root@raspberrypi:/tmp# pip freeze
azure-iot-device==2.0.0
certifi==2019.11.28
chardet==3.0.4
edgetpu==2.12.2
idna==2.8
janus==0.4.0
netifaces==0.10.9
numpy==1.16.2
opencv-contrib-python==4.1.1.26
paho-mqtt==1.5.0
Pillow==5.4.1
redis==3.3.11
requests==2.22.0
requests-unixsocket==0.2.0
six==1.14.0
transitions==0.7.2
urllib3==1.25.8

I have just used the sample sender/receiver examples here: https://github.com/Azure/azure-iot-sdk-python/blob/master/azure-iot-device/samples/sync-samples/send_message_to_output.py https://github.com/Azure/azure-iot-sdk-python/blob/master/azure-iot-device/samples/sync-samples/receive_message_on_input.py

But my scripts output several error messages like these:

Any idea?

By the way, I had set the networking mode of this module as host by following this - https://github.com/Azure/iot-edge-v1/issues/517#issuecomment-407453239

[BertKleewein]

@openedhardware - Thank you for the video. That really helps. The problem that you’re seeing is caused by the way you’re using the single module identity.

An IoT Edge Module can only be used by a single process at a time. When you call create_from_environment() or create_from_connection_string(), you’re preparing a new network connection for your module. When you call connect() or send_event() or any other method that neds to use the network, it establishes the connection. If a different process already has a connection for the module, that connection gets closed by the server because there can only be one connection.

As a side-effect of this, if the processes are aggressive about keeping the connection alive (like this SDK is), there can be a ping-pong effect between the 2 processes. Say the first process is connected, then the second process connects which causes the first process’s connect ion to close. The first process notices the error and tries to reconnect, which causes the second process to disconnect. Then, the second process tries to reconnect which causes the first process to disconnect, and so on. This may be part of what you’re seeing.

The other factor is that the docker container for your module probably has a process that’s has it’s own network connection for the module. Or maybe not, I can’t say. But, if it does, that means you have three different processes all fighting to be the one that’s connected.

If you want to test sender and receiver together like this, you need two different modules and a routing rule to connect the output of one module to the input of the other module. You also need to ensure that that your don’t have any other processes trying to connect. This means creating your own docker images, either a single image with bash as an entrypoint, or two images, one with send.py and the other with receive.py as entrypoints.

I hope this helps. Please let me know if this isn’t clear.

[az-iot-builder-01]

@openedhardware, @BertKleewein, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey