Azure / iot-central-python-client

A Python SDK for connecting devices to Microsoft Azure IoT Central
MIT License
6 stars 9 forks source link

Failed to connect to Hub #3

Closed 5MarsR closed 3 years ago

5MarsR commented 3 years ago

Hi,

I'm using python 3.9 on Linux

I tried using the async_device_key example and it seems there is a problem with the client.connect() every time i start the code i get: Device connected Current twin: {'desired': {'prop': 50, '$version': 7}, 'reported': {'writeableProp': 50, '$version': 10}} ERROR: Failed to connect to Hub

it seems the problems comes from this line:

if i comment it the code runs normaly

lucadruda commented 3 years ago

Can't reproduce with Python 3.8. Tried with 3.9 and have a different error. I'm trying to see if it's related.

5MarsR commented 3 years ago

Weird,

because every time I try to run the code without the line commented I get disconnected.

lucadruda commented 3 years ago

can you provide more details on environment and credential type?

5MarsR commented 3 years ago

I tried in the visual studio code environment both on Linux and windows, I also tried on a raspberry pi running raspbian directly from the system terminal. I'm using the device key credentials to connect.

firedog1024 commented 3 years ago

I'm taking a look at this now and see if I can reproduce the error. This code is getting a bit old and needs a bit of a refresh, I'd highly recommend looking at this code as it is much newer and also wraps in support for our high availability feature of multiple hubs. However it is written using symmetric key only and does not have the code in it for x.509 if that is needed. You can find that sample here under the python folder https://github.com/iot-for-all/iot-central-high-availability-clients

5MarsR commented 3 years ago

okay thank you, I will take a look

firedog1024 commented 3 years ago

@5MarsR I was able to repro the issue here and as you suspected the problem is due to how we are processing the desired properties in the device twin. We made a change in a one of our releases some time ago to align our twin structure with that of the IoT Hub, and as such we removed the JSON object wrapping around desired properties. It appears that we did not change the IOTC SDK to accommodate that change and it is still expecting there to be an object wrapper around the desired property and that is causing the exception. I chatted with @lucadruda and we need to make some fairly extensive repairs in this code to fix up a number of issues to keep pace with changes in IoT Central and it's going to take a while. I'm going to make a simple fix for this specific issue but will not check it into the main branch as it's really a Band-Aid fix and not something I want to push to pypi. Once I have a fix in a branch I'll update the issue thread here so you can pull the library from that branch or patch your current copy.

I have to stress that if you are starting new development of a python IoT project I would advise using the official Azure IoT Python device SDK. This project was built when there was not a native python SDK for Azure IoT (it was a python wrapper on the C SDK) and some of our users needed a native python SDK for IoT Central. The official Python SDK is very stable and is fully funded by Azure so it is under constant development and maintenance. This is the SDK that most of our samples are written in today. The SDK can be found here https://github.com/Azure/azure-iot-sdk-python

firedog1024 commented 3 years ago

@5MarsR if you want to continue using this to connect your python code to IoT Central I made a couple of small fixes to the code so you should no longer see the disconnect issue and the desired properties should now be handled correctly. I made the change in this branch https://github.com/iot-for-all/iotc-python-client/tree/quickfix and the pull request can be seen here to see the exact fix I applied https://github.com/iot-for-all/iotc-python-client/pull/4. @lucadruda is going to take a closer look at this code when he returns from vacation and make a more substantial fix for a this and a number of other areas that need attention. Sorry for the inconvenience of this and hopefully this fix helps

5MarsR commented 3 years ago

thank you, I will try it this weekend

lucadruda commented 3 years ago

fixes are applied on #5. Advise is always to use official SDK for new developments of course

lucadruda commented 3 years ago

@5MarsR please let us know if your issue is fixed so we can close this

5MarsR commented 3 years ago

I will take a look as soon has I can, I should test it during the next few days.

5MarsR commented 3 years ago

seems all is working fine for me, thanks a lot for the support

lucadruda commented 3 years ago

closing as issue got fixed in 1.1.1