Cannot connect to devices when local key has special characters in it.

IamGimli commented 1 week ago

Description

Ever since the last Tuya-local update my devices that have local keys that include special characters (such as @ ! ] + [ _ ) can no longer be connected to. Devices of the same make/model that have local keys that do not include special characters work fine. The devices that Tuya-local won't connect to are still accessible through the cloud services. Before the last Tuya-local update those same devices worked correctly.

Steps to reproduce

Create a new device.
If the device only has alphanumeric characters in its local key, the device is created properly.
If the device has special characters in its key, Tuya-local says it cannot communicate with it.

Expected behaviour

Adding a local device should be successful wether the local key includes special characters or not.

Additional context

The following appears in the HA logs: `This error originated from a custom integration.

Logger: custom_components.tuya_local.device Source: custom_components/tuya_local/device.py:464 integration: Tuya Local (documentation, issues) First occurred: 12:34:49 (6 occurrences) Last logged: 12:35:35

Test protocol error 904: Unexpected Payload from Device Test protocol error 914: Check device key or version`

Confirmation

[X] I am sure this is a bug or improvement, that is well enough described that it can be implemented.
[ ] If this is for a specific device, the device config is mentioned above, or diagnostics are included.
[X] Log messages or diagnostics relevant to the issue are included.
[X] This is not requesting addition of a new device.

IamGimli commented 1 week ago

I believe this behaviour started either in 2024.11.1 or 2024.11.2

mvso commented 1 week ago

Same issue here, i cannot connect my new device

make-all commented 1 week ago

There was no change in the handling of local key in those versions. The only change to connection handling is that the integration can now recover from connections which previously would hang without returning any error, so perhaps if your protocol is set to Auto, the device was previously hanging trying to connect on one protocol and now it is getting past it to try the correct protocol to find another error. You can avoid protocol related problems and improve reconnection performance drastically by explicitly specifying the correct protocol version.

Handling of "special characters" is a frequent conclusion that users jump to, but it has always turned out to be something else in the past. I suggest that you go through the other possibilities in #522.

Also if there really is a problem with a specific character somewhere, re-pairing your device will assign a new key, which is unlikely to trigger the same issue.

IamGimli commented 1 week ago

The local key is the only thing I can see that's different between the 6 devices that no longer work and the 3 that still do, all the same make/model, all were working as of last week. It's possible that it's something else but both the error message and examining the configuration of the devices points to the local key being the only difference in configuration.

Isn't one of the changes in 2024.11.0 "support for base64 encoded UTF-16 text fields"? Wouldn't changing the handling of text fields possibly affect the handling of the local key field?

make-all commented 1 week ago

`No, that change does not affect the config text fields (they are always UTF-8). It only affects decoding of dps coming from the device that have been explicitly marked as that encoding.

make-all / tuya-local