UnicodeDecodeError: 'utf-8' codec can't decode byte 0xYY in position Z: invalid start (or continuation) byte #424
Comments
|
Hmm, that's interesting. In the failing example, retcode is 1 which indicates an error. I think we need to get data that successfully decodes with tuyadebug but don't work with my changes, so we can compare. Basically raw data sent and received as well as the local key. Do you think you can reproduce this behavior by re-provisioning a device? |
|
Sorry but at the moment I am too busy to play with this but I believe that KixMan28 is still in this situation (see #330 (comment) in #330 ) so maybe he can provide the data you neeed. Moreover, I experienced it only once so it could need several re-pairings before the issue comes out again so it would be better to use a device that is already showing the problem. |
|
@postlund What information do you need from my side to have this moving forward? |
|
@postlund @rospogrigio do you need anything from my side to have this solved? |
|
Is this ticket looked at? I'm getting below; |
1 similar comment
|
Sorry guys but this goes beyond my knowledge and skills, so I'm afraid only @postlund can give a hand but he looks very overwhelmed recently. Moreover, my devices do not have this problem so I cannot test it: it happened once, but after I re-paired the device the problem disappeared, so my suggestion is to try re-pairing. If it persists, then it's only postlund that can provide a fix. |
|
@postlund I have been trying to get a smart plug integrated with LocalTuya and I have seen different failures. One of them was "... invalid continuation byte ...", like mentioned in this post. Another one was something like bad payload (I'm not at home at the moment, can't find the exact error message). I got the device working with LocalTuya only for once but when plugged off the device, it started failing again. |
|
Facing the same problem with a chinese smart plug: [bf8...vmr] Connect to 192.168.X.X failed
Traceback (most recent call last):
File "/config/custom_components/localtuya/common.py", line 149, in _make_connection
status = await self._interface.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 472, in status
status = await self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 457, in exchange
payload = self._decode_payload(msg.payload)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 557, in _decode_payload
payload = payload.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb9 in position 1: invalid start byteFunny thing is that it's sibling plug is getting integrated without any problem. They both have the same firmware version (1.0.6), as I can see from the Smart Life app. |
This was referenced Nov 6, 2021
|
I'm having this issue on and off with a Mirabella Genio-branded light globe (GENIO A60 9W LED GLS BK, I002605). This is with Home Assistant 2021.9.6 [update: same on 2021.11.1] on Docker, with localtuya installed via HACS 1.16.0 (it says localtuya is at v3.2.3). Somehow, it seems my mileage varies depending on whether I allow outbound internet access to the light (with or without DNS access). The type also varies: Also worth noting is that HA and the light globe aren't on the same LAN segment. All traffic from HA to the IoT segment is allowed, but only related/established from the IoT segment to HA is let through. Notably, the light globe broadcasts messages to 255.255.255.255 those aren't allowed through. At some point during my tests, I managed to get HA to find some DPs, but I was crucially missing the On/Off switch (id 20). @postlund does the below contain enough payload data for you? Full internet accessIt works fine with but not with HA/localtuya (docker): No internet accessAfter a power-cycle with a 60s wait before turning back on. DNS traffic to router disabled (but I still see traffic for remote IP addresses, so I'm thinking that 60s might not be long enough to clear the globe's memory; I'll retry tomorrow and update; UPDATE: same behaviour after ~10 hours off).
HA complains that “Connection to device succeeded but no datapoints found, please try again. Create a new issue and include debug logs if problem persists.” |
|
Shocking, huh? (:
To be honest, I'm not sure what those types are, couldn't find anything in the code from a cursory glance. What are the differences?
That said, this seems to vary depending on whether any functional internet access was available when the globe was turned on. Otherwise, the DPs found seem nonsensical, regardless of whether DNS is accessible or not (blocking both TCP and UDP).
It's a fairly recent globe, say mid-2021. I could not flash it with Tasmota, and I fear it might have updated the firmware to something even more recent when I paired it to Tuya Smart. Still, they can't be completely disabling offline operation... I guess this is a completely separate issue at this point.
Nonetheless, there is a discrepancy between localtuya and test.py in tuyadebug. The latter is happy and finds DPs as desired when the globe is allowed internet access. I assume they are not using the same lib/version?
If you can share any pointers or ideas about the differences between the two, I could try to dig in myself [time allowing, of course].
--
Olivier Mehani ***@***.***>
Sent from my mobile, please excuse my brevity.
|
In PR #6 you will find a (pretty long) discussion that explains what type_0a and type_0d are and how they behave differently.
test.py is still using some old code, localtuya has been developed more recently and is more refined, however probably this behavior is some corner case not correctly handled. Localtuya's code is from postlund and is a bit too complicated for me to handle, however by comparing the behaviors of the two codes you might end up understanding what is going wrong. When I had this issue, I was having it with both codes so I cannot be of any help (re-pairing the device solved the issue, for me). |
|
Ok, on a hunch, I commented those two lines https://github.com/rospogrigio/localtuya/blob/master/custom_components/localtuya/pytuya/__init__.py#L532-L533 because
and... 🎉 (using hints from #374 and #33);
Now to disconnect it from the cloud... |
|
FWIW, those lines came from this commit e6538a4, but it somehow appears like, despite being encrypted, my globe still responds with a leading |
1 task
shtrom
added a commit
to shtrom/localtuya
that referenced
this issue
Nov 24, 2021
Signed-off-by: Olivier Mehani <shtrom@ssji.net>
|
Hi, I also encountered a UnicodeDecodeError, though I'm not sure if the root cause is the same. (If I need to split it off in a separate ticket, then let me know.) The error I encountered is: I encountered this while installing a Tuya pet feeder (an identical of one that I installed earlier, but maybe the firmware differs). Tuya product category: cwwsq. Tuya-cli was able to use the device without problems: My workaround has been to patch the decode() function in decrypt() to use latin-1: This is not a proper solution (clearly), but it works for me for the time being. The output of test.py from tuyadebug (with the patched function is): (Note the \0xe9 in the data from DPS 104.) For reference, the older pet feeder works fine with the unpatched code: (Note that the output from DPS 104 is different.) |
|
Same. Cannot get DPs of ANY of my five Tuya devices. I can control them with LocalTuya from Home Assistant just fine. I'm getting either an error 104 or the "failed to get status: 'utf-8' codec can't decode byte 0xe9 in position 0: invalid continuation byte" one. MacOS and Ubuntu. |
|
@Stooovie: as a workaround you could try to patch the code to use |
shtrom
added a commit
to shtrom/localtuya
that referenced
this issue
Apr 18, 2022
Signed-off-by: Olivier Mehani <shtrom@ssji.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@postlund , I have some more info regarding the error in the subject, that was reported in several Issues: #330, #313, #282, #201, #193 .
I had to reset and re-pair one of my type_0d cover devices. As we all know, its localKey changed in the process but when I updated it the cover remained unavailable. In the logs I found that error. Now, curious facts:
So, I don't know what generates this situation, but I believe it has to be something with your implementation of pytuya because the one included in tuyadebug was not giving the same error. I am attaching the logs in case you are able to investigate.
Failing device:
Succeeding device:
Hope it might help, bye!
Edit: now my device works so I cannot test any solution, but most of the people in the Issues I've mentioned are probably still struggling with this problem so they might test on their hardware.
The text was updated successfully, but these errors were encountered: