Logs do not contain useful info when there are low level network issues during connection configuration

[robinhood-code]

This form is for reporting bugs. If you have encountered a bug, you should
generally have some log messages or device diagnostics to show something is
going wrong. If your problem is more of a question or a request for help,
then Discussions is
probably a more suitable venue.

Describe the bug
A clear and concise description of what the bug is.

Unable to add a Tuya WIFI device while Device ID, IP address, Local Key have all been specified.

To Reproduce
Steps to reproduce the behavior including the device the issue was observed with:

1. Click "Add Device" under Local-Tuya
2. Enter info including Device ID, IP address and Local Key
3. After a while the error "Unable to connect to your device with those details. It could be an intermittent issue, or they may be incorrect.

Expected behavior
Device can be added.

Additional context
Add any other context about the problem here.

If the bug involves a device, then please include device diagnostics from
Settings / Devices & Services / Tuya Local (your device) / "1 device"

Please check if there are messages from Tuya Local in the Home
Assistant log (Settings / System / Logs), and include those too.

If applicable, add screenshots to help explain your problem.

Device is connected to the router:

Device is online on Tuya IOT website:

Device is pingable within the network:

Error entry in HA:

Logger: homeassistant.util.async_
Source: util/async_.py:141
First occurred: 3:21:52 PM (5 occurrences)
Last logged: 3:54:29 PM
Detected blocking call to sleep inside the event loop by custom integration 'tuya_local' at custom_components/tuya_local/device.py, line 77: self._api = tinytuya.Device(dev_id, address, local_key), please create a bug report at https://github.com/make-all/tuya-local/issues

[make-all]

The error message you are reporting only appears when the IP address is blank or "Auto", so this log message does not match the described scenario. The connection issue is most likely covered in #522 already, or if not, can be added there when you figure out what the problem is. Possibly you are using the uuid instead of device id, or one of the other entries is not matching what it needs to be.

[robinhood-code]

Thanks for the quick feedback.

It was indeed not related to Auto IP settings.

After a few trials and errors apparently there was no log generated when the error occurred so I was blind guess at the beginning.

After a while I figured I could enable the debug logging for the integration and in the debug log I found the following entry:

2024-02-05 19:00:54.642 DEBUG (SyncWorker_0) [custom_components.tuya_local.device] Test refreshed device state: {"Error": "Check device key or version", "Err": "914", "Payload": null}

from search I was brought to this issue #1576

And this was the same issue where I needed to select v3.5 instead of using Auto.

For anyone who has connection issue in the future it is worth to enable debug logging which gives you more logs to help your troubleshooting.

[robinhood-code]

Just curious, why the versioning "Auto" is not a simple for loop to loop through all the versions (or after an unsuccessful attempt of guessing) and see which one works?

[make-all]

It is a simple loop, which worked reasonably reliably when the common protocols were 3.1 and 3.3, but the 3.4 and 3.5 devices seem to get into funny states where they will fail for some time after a wrong protocol was tried even when the correct protocol is used.

[robinhood-code]

that makes sense thanks. hopefully the error message can be improved but I know I can't be asking too much here : )

[make-all]

I'm thinking to make a special case when the Device name is "Test" to output the low level messages from the tinytuya library with higher priority. The reason the network errors are debug messages is that they happen quite frequently when the tuya device is busy, and these are handled by retries so don't need to be cluttering up the log at high level.

[robinhood-code]

or only during the add device process?

[make-all]

I'll hijack this report to track the log improvements.

[make-all]

Basically the warning log was there in the main receive loop, but was missing from the one-time device poll that is used during configuration.

This was due to a behaviour change in tinytuya some time back, from throwing exceptions to just reporting the errors through the json response, and I missed updating this second location.

[robinhood-code]

sent you coffee to keep you awake while you're indulged in coding : )