jasonacox / tinytuya

Python API for Tuya WiFi smart devices using a direct local area network (LAN) connection or the cloud (TuyaCloud API).
MIT License
867 stars 157 forks source link

tuya_cloud.getconnectstatus is not working since yestarday, but it's my fault and I would have liked to see a better message error #475

Open leadvic opened 3 months ago

leadvic commented 3 months ago

Hi everyone!

I had a pipeline running every 2 minutes, and since yestarday I realized I have an issue when running it

tuya_cloud.getconnectstatus(device_id)

The error looks like this:

658 if not response_dict['success']:
659 log.debug("Error from Tuya Cloud: %r", response_dict['msg'])
--> 660 return(response_dict["result"]["online"])

So there might be some kind of change in the Tuya Cloud API that may be the function getconnectstatus isn't capturing well. Or that was what I was think at the beginning until I saw:

{'code': 28841002, 'msg': 'No permissions. Your subscription to cloud development plan has expired.'

Do you think it might be worth it to add a way that tintuya could show this kind of messages instead of showing an error which is not helpful as the one shown before?

jasonacox commented 3 months ago

Hi @leadvic - I think there are three ways to do this.
1) Exception - We could raise an exception with that language which would stop your code (unless you catch exceptions). We mostly try to avoid this except when it makes sense, which it might in this case. 2) Payload - We could respond with the error in the return payload (essentially passing back the msg from Tuya cloud) so you would need to look for that in your code. 3) Log - We could raise the log level to log.error() and set the debug mode to error by default. This is likely not what we want since it could have other noisy ramifications. And as you saw, if you turn on debug you see it anyway.

I'm interested in hearing what you and others community think might be the most helpful.

uzlonewolf commented 3 months ago

For this one I think we should at least return an error_json(), and it probably wouldn't be a bad idea to add an option like d.except_on_error(True) to tell it you want it to raise exceptions instead.