@rospogrigio If I were to mail you one of the switches, would you be able to work on the code? I have an extra one because one of the switches in my house didn’t have a neutral wire.
@OfWonder One cheaper and quicker option would maybe to give me access to your system so I can try to debug remotely, but I will do it in my spare time (which is not much since I have a 2 yo daughter 
) so I cannot guarantee on the timing.
Write me in pvt in case,
rospogrigio
1 Like
@rospogrigio thanks so much for the quick response. Yes, please do send me the command line script you use to debug, that would be great.
Cheers
I’ve just pushed a PR to your repo @rospogrigio which should enable dimmable and colour temp controlled lights through this integration. I could only test with dimmable, but working great here. Also updated the manifest to pull the latest crypto dependencies and it seems to be running faster in my environment than it was.
1 Like
@djtimca I am a Home Assistant novice. To get this working, do I just overwrite all of the code in my light.py file with yours?
You should grab both the light.py and the manifest.json file which were both changed in my file. I can’t be sure that you need the manifest.json file, but it wouldn’t work in my development environment without that small change. Then to set up a light add the following to your configuration.yaml:
light:
- platform: localtuya
host: IP_ADDRESS
local_key: localkey
device_id: deviceid
name: light_name
friendly_name: Light Name
protocol: 3.1
All my dimmers are protocol 3.1 so I wasn’t able to test with anything that had a newer firmware, but I think it should work. It should also support lights with a color_temp setting. I didn’t get to looking at the color_rgb settings (since I don’t have any to test and that looked a bit more complicated), but it should still allow the other two settings.
@djtimca I am having no luck getting this to work. Please see below for my issues:
Updating localtuya light took longer than the scheduled update interval 0:00:30
12:26:13 AM – Light (WARNING) - message first occurred at 12:23:13 AM and shows up 6 times
Something is blocking Home Assistant from wrapping up the start up phase. We’re going to continue anyway. Please report the following info at http://bit.ly/2ogP58T : config, homeassistant, binary_sensor, group, automation, websocket_api, sensor.upnp, script, http, zeroconf, weather, cloud, onboarding, input_text, stream, light.tuya, search, webhook, binary_sensor.updater, notify.mobile_app, light.localtuya, auth, input_number, mqtt, media_player, system_log, logger, history, lovelace, input_boolean, logbook, scene, tuya, notify, upnp, tts, person, mobile_app, alexa, scene.homeassistant, device_automation, zone, sensor, weather.met, sun, cast, default_config, input_select, persistent_notification, system_health, updater, light, map, ssdp, hassio, recorder, input_datetime, media_player.cast, api, met, frontend
12:26:00 AM – core.py (WARNING)
Update of light.test is taking over 10 seconds
12:25:53 AM – /usr/local/lib/python3.8/asyncio/events.py (WARNING) - message first occurred at 12:22:12 AM and shows up 3 times
Setup timed out for bootstrap - moving forward
12:25:45 AM – bootstrap.py (WARNING)
Failed to get color temp after 3 tries
12:25:43 AM – localtuya (WARNING) - message first occurred at 12:20:05 AM and shows up 10 times
Failed to get brightness after 3 tries
12:24:13 AM – localtuya (WARNING) - message first occurred at 12:21:13 AM and shows up 2 times
Failed to get status after 3 tries
12:23:43 AM – localtuya (WARNING) - message first occurred at 12:21:13 AM and shows up 2 times
Updating zone zone took longer than the scheduled update interval 0:00:15
12:23:13 AM – Zone (WARNING)
Failed to set status after 3 tries
12:21:12 AM – localtuya (WARNING)
Waiting on integrations to complete setup: zeroconf, mqtt, tuya, mobile_app, zone
12:20:35 AM – bootstrap.py (WARNING)
Timeout fetching Home Assistant update data
12:20:35 AM – Updater (ERROR)
Setup of light platform localtuya is taking over 10 seconds.
12:20:35 AM – Light (WARNING)
Setup of zone is taking over 10 seconds.
12:20:35 AM – /usr/local/lib/python3.8/asyncio/events.py (WARNING)
Updating state for light.test (<class ‘custom_components.localtuya.light.TuyaDevice’>) took 60.135 seconds. Please report it to the custom component author.
12:20:35 AM – helpers/entity.py (WARNING)
You are using a custom integration for localtuya which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
12:19:35 AM – loader.py (WARNING)
So, for any developer who might be interested, I am attaching the scripts I am using for debugging.
Credits go to @jasonacox, since I actually downloaded his repo https://github.com/jasonacox/tuyapower , integrating it with my pytuya library.
He uses it within a docker environment, I actually launch it on command line, check the run.sh script: it runs test.py with the parameters for different devices (device_id, IP, localKey, “s/c” for switch/cover, list of dps used and protocol).
The test.py command just tries to connect and get the status of the device, returning it or showing errors. It is then possible to add debug lines or change code and then simply relaunch the script, until you get the communication running.
Hope this might help @loaxley or anyone else to get things working: if you find improvements for the localtuya library just send them to me and I’ll try to integrate them.
Edit: could not attach scripts here, I uploaded them in my repo: you should find the tuyadebug.tgz archive at https://github.com/rospogrigio/localtuya-homeassistant .
Bye
rospogrigio
EDIT: Nevermind, you added the link to your GitHub. Thank you!
Hi @rospogrigio, I do not see an attachment of the “run.sh” script. Could you try posting/uploading it again?
1 Like
@djtimca I found your and another PR request, will test them and if everything is working I’ll publish a new release.
Bye
rospogrigio
@rospogrigio, I have run your debug scripts. I also went and ran the debug scripts from the original tuyapower repo. Here are the results:
First, I installed tuyapower via pip, and when I run:
python3 -m tuyapower
My output is:
TuyaPower (Tuya compatible smart plug scanner) [0.0.22]
Scanning on UDP ports 6666 and 6667 for devices (15 retries)...
FOUND Device [Valid payload]: 192.168.1.29
ID = 31xxxxxxxxxxxxxxxxf8, productKey = 3rxxxxxxxxxxxx1g, Version = 3.3
Device Key required to poll for stats
Scan Complete! Found 1 devices.
So, good news, is that tuyapower can successfully scan and find my device. The IP is correct, the ID is correct. (However, the productKey does not match up with the Key that I extracted using tuya-cli, and with which I can set and get data using tuya-cli. But let’s set that aside because I don’t think it’s relevant).
When I run:
python test.py 31xxxxxxxxxxxxxxxxf8 192.168.1.29 87xxxxxxxxxxxxf8 3.3
I get back:
ERROR: Timeout polling device
TuyaPower (Tuya Power Stats) [0.0.22]
Device 31xxxxxxxxxxxxxxxxf8 at 192.168.1.29 key 87xxxxxxxxxxxxf8 protocol 3.3:
Switch On: False
Power (W): -99.000000
Current (mA): -99.000000
Voltage (V): -99.000000
Projected usage (kWh): Day: -2.376000 Week: -16.632000 Month: -72.072000
{ "datetime": "2020-09-03T09:05:29Z", "switch": "False", "power": "-99", "current": "-99", "voltage": "-99" }
This leads me to two conclusions:
(1) There’s a timeout, so something is wrong
(2) Even if there wasn’t a timeout, my device is a cover, not a switch, so the output here would be irrelevant
Then, I switched over to your code and your debug scripts and ran:
python test.py 31xxxxxxxxxxxxxxxxf8 192.168.1.29 87xxxxxxxxxxxxf8 c
I got back:
INFO:localtuya:localtuya version 0.0.19
INFO:localtuya:Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
INFO:localtuya:Using pytuya version '7.0.8'
COVER DEVICE
localtuya.pytuya version 7.0.8
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
('Using PyCrypto ', (2, 6, 1, 'final', 0))
('Using PyCrypto from ', '/usr/lib/python2.7/dist-packages/Crypto/__init__.pyc')
INFO:localtuya:Requesting status of device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29], protocol 3.3.
DEBUG:localtuya.pytuya:status() entry (dev_type is device22)
DEBUG:localtuya.pytuya:json_payload='{"devId":"31xxxxxxxxxxxxxxxxf8","dps":{"":null},"uid":"31xxxxxxxxxxxxxxxxf8","t":"1599124438"}'
Failed to receive data from 192.168.1.29. Raising Exception.
COVER DEVICE
localtuya.pytuya version 7.0.8
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
('Using PyCrypto ', (2, 6, 1, 'final', 0))
('Using PyCrypto from ', '/usr/lib/python2.7/dist-packages/Crypto/__init__.pyc')
INFO:localtuya:Requesting status of device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29], protocol 3.3.
DEBUG:localtuya.pytuya:status() entry (dev_type is device22)
DEBUG:localtuya.pytuya:json_payload='{"devId":"31xxxxxxxxxxxxxxxxf8","dps":{"":null},"uid":"31xxxxxxxxxxxxxxxxf8","t":"1599124451"}'
Failed to receive data from 192.168.1.29. Raising Exception.
COVER DEVICE
localtuya.pytuya version 7.0.8
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
('Using PyCrypto ', (2, 6, 1, 'final', 0))
('Using PyCrypto from ', '/usr/lib/python2.7/dist-packages/Crypto/__init__.pyc')
INFO:localtuya:Requesting status of device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29], protocol 3.3.
DEBUG:localtuya.pytuya:status() entry (dev_type is device22)
DEBUG:localtuya.pytuya:json_payload='{"devId":"31xxxxxxxxxxxxxxxxf8","dps":{"":null},"uid":"31xxxxxxxxxxxxxxxxf8","t":"1599124453"}'
Failed to receive data from 192.168.1.29. Raising Exception.
INFO:localtuya:TIMEOUT: No response from device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29] after 2 attempts.
For the record, I have tried passing in the dps, and that doesn’t resolve the issue, nor does using the alternative Device Key that tuyapower outputted (though I know that’s the wrong Device Key, and the one I got from tuya-cli is correct, I still wanted to try it).
Any thoughts or ideas on what might be causing the problem? I’ve been playing around with the debug scripts, but haven’t figured it out yet.
@loaxley I would not use TuyaPower, since it was meant for switch devices.
Getting to my scripts, your device is a device22 (22 is the length of the deviceId), so it definitely should use protocol 3.3 and need the dps to be sent in the payload. Can you post the output after setting protocol 3.3 and providing the full list of dps ?
Re: Unique ID - I did nothing to change that in my update. All of my lights/switches do not have unique ID, but that doesn’t affect their function.
Re: The warnings in your logs
None of these on their own are a concern necessarily, whether I use the cloud or local control I periodically have delays connecting to the lights when I send a command or request status. I’m more concerned with whether the light controls work at all.
My hunch from you posting the logs is that they don’t in your situation. Can you let me know what type of lights they are? (Mine are dimmer switches, not light bulbs, so I expect there may be differences). If you click on the error “Failed to set status after 3 tries” are there any other details?
@djtimca Mine are also dimmer switches. See below for link:
Switch Link: https://www.amazon.com/gp/product/B07K67D43J/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
I would think those would work similar to mine. The one thing I see in your logs that I solved on mine was the Colour Temp timing out. On mine I had to catch an error to detect whether the light supported Colour Temp changes, but that catch doesn’t appear to be working for yours. When you ran tuya-cli what version(s) did you try and what dps were returned. Mine returned a result with both 3.1 and 3.3 in tuya-cli but only work in protocol 3.1 in the integration.
Hi everybody, just released the new v1.0.2 of localtuya, integrating:
- the work from @djtimca on the
lightcomponent: could not test it since I don’t own those devices but I trust him and I believe it should work, looking at the code modifications - the work from @postlund , introducing the “available” status and the unique_ids for the devices. In particular, using unique_ids is more compliant to HomeAssistant, but will probably require that you remove your current entities (from Configuration-Entities) if they are no longer visible and have them recreated (at least, I had to do it so).
Let me know any feedback.
Bye,
rospogrigio
Hi @rospogrigio, here is the output when setting 3.3 and using the full list dps. One thing to note is that even though i’m showing “device22”, the length of my deviceId is 20 characters (31xxxxxxxxxxxxxxxxf8). Also, I notice my device Key (87xxxxxxxxxxxxf8) does not get passed into the json.payload, that’s probably normal but want to point it out just in case it is not normal.
Command run:
test.py 31xxxxxxxxxxxxxxxxf8 192.168.1.29 87xxxxxxxxxxxxf8 c 1,2,3,5,7,8,9,10,11 3.3
Result:
INFO:localtuya:localtuya version 0.0.19
INFO:localtuya:Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
INFO:localtuya:Using pytuya version '7.0.8'
COVER DEVICE
localtuya.pytuya version 7.0.8
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
('Using PyCrypto ', (2, 6, 1, 'final', 0))
('Using PyCrypto from ', '/usr/lib/python2.7/dist-packages/Crypto/__init__.pyc')
INFO:localtuya:Requesting status of device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29], protocol 3.3.
DEBUG:localtuya.pytuya:status() entry (dev_type is device22)
DEBUG:localtuya.pytuya:json_payload='{"devId":"31xxxxxxxxxxxxxxxxf8","dps":{"11":null,"10":null,"1":null,"3":null,"2":null,"5":null,"7":null,"9":null,"8":null},"uid":"31xxxxxxxxxxxxxxxxf8","t":"1599147993"}'
Failed to receive data from 192.168.1.29. Raising Exception.
COVER DEVICE
localtuya.pytuya version 7.0.8
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
('Using PyCrypto ', (2, 6, 1, 'final', 0))
('Using PyCrypto from ', '/usr/lib/python2.7/dist-packages/Crypto/__init__.pyc')
INFO:localtuya:Requesting status of device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29], protocol 3.3.
DEBUG:localtuya.pytuya:status() entry (dev_type is device22)
DEBUG:localtuya.pytuya:json_payload='{"devId":"31xxxxxxxxxxxxxxxxf8","dps":{"11":null,"10":null,"1":null,"3":null,"2":null,"5":null,"7":null,"9":null,"8":null},"uid":"31xxxxxxxxxxxxxxxxf8","t":"1599147995"}'
Failed to receive data from 192.168.1.29. Raising Exception.
COVER DEVICE
localtuya.pytuya version 7.0.8
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
('Using PyCrypto ', (2, 6, 1, 'final', 0))
('Using PyCrypto from ', '/usr/lib/python2.7/dist-packages/Crypto/__init__.pyc')
INFO:localtuya:Requesting status of device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29], protocol 3.3.
DEBUG:localtuya.pytuya:status() entry (dev_type is device22)
DEBUG:localtuya.pytuya:json_payload='{"devId":"31xxxxxxxxxxxxxxxxf8","dps":{"11":null,"10":null,"1":null,"3":null,"2":null,"5":null,"7":null,"9":null,"8":null},"uid":"31xxxxxxxxxxxxxxxxf8","t":"1599148007"}'
Failed to receive data from 192.168.1.29. Raising Exception.
INFO:localtuya:TIMEOUT: No response from device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29] after 2 attempts.
OK, I think I know the error. For the cover entities, I forced them to be device22 since mine are 22 chars long, and I thought that probably all covers were like this. In any case, I could not test other situations (while I do have both device20 and device22 switches).
Yours are device20, so they need to be controlled differently… so try to replace, in pytuya/init.py , within the CoverEntity class (row 453):
the line
dev_type = 'device22'
with (copy it from rows 436-439:
if len(dev_id) == 22:
dev_type = 'device22'
else:
dev_type = 'device20'
and I believe it should work, finally…
It works! When I run:
python test.py 31xxxxxxxxxxxxxxxxf8 192.168.1.29 87xxxxxxxxxxxxf8 c 1,2,3,5,7,8,9,10,11 3.3
I now get:
INFO:localtuya:localtuya version 0.0.19
INFO:localtuya:Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
INFO:localtuya:Using pytuya version '7.0.8'
COVER DEVICE
localtuya.pytuya version 7.0.8
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
('Using PyCrypto ', (2, 6, 1, 'final', 0))
('Using PyCrypto from ', '/usr/lib/python2.7/dist-packages/Crypto/__init__.pyc')
INFO:localtuya:Requesting status of device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29], protocol 3.3.
DEBUG:localtuya.pytuya:status() entry (dev_type is device20)
DEBUG:localtuya.pytuya:json_payload='{"devId":"31xxxxxxxxxxxxxxxxf8","gwId":"31xxxxxxxxxxxxxxxxf8"}'
DEBUG:localtuya.pytuya:status received data='\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\n\x00\x00\x00\x9c\x00\x00\x00\x00H7L6\xf0\xd4\xcc\x11f\x8e\xbaI\xd1\xf1\x19%\x89m\xe8cB\xd6\x9cI\t8#\x8b\x1f\x1a\x07\x91N\x86-\xf62\x85p)R,\x8bg\x03"\xb2\xb5\x98\xb18\xcd\x16\xd0\xe7\x1f\xa9\xa4\xcb*\x10\x92B\xe7\x14M\r\x1b\x9cJ\xc4f\x87\x0b\x05H\xe2\xd7\x90.\xaa\x0e\x8as\x12oO\xa7;yS\xed~?\x9b~\x85\xd2P\xe3t\x0f\xc4\xa9\xdf\xe8d\xf0\xd6[\xed\x1dq$\x98\x1c)\xee\xd6/\x9a?\x9b\xbd`^\xb3\xd0\xc8\xe6\x9dl\x86\xbf\x83Z\xab^\x83\x8e\x82\x00;\xbf3\x9ac$\x00\x00\xaaU'
DEBUG:localtuya.pytuya:result='H7L6\xf0\xd4\xcc\x11f\x8e\xbaI\xd1\xf1\x19%\x89m\xe8cB\xd6\x9cI\t8#\x8b\x1f\x1a\x07\x91N\x86-\xf62\x85p)R,\x8bg\x03"\xb2\xb5\x98\xb18\xcd\x16\xd0\xe7\x1f\xa9\xa4\xcb*\x10\x92B\xe7\x14M\r\x1b\x9cJ\xc4f\x87\x0b\x05H\xe2\xd7\x90.\xaa\x0e\x8as\x12oO\xa7;yS\xed~?\x9b~\x85\xd2P\xe3t\x0f\xc4\xa9\xdf\xe8d\xf0\xd6[\xed\x1dq$\x98\x1c)\xee\xd6/\x9a?\x9b\xbd`^\xb3\xd0\xc8\xe6\x9dl\x86\xbf\x83Z\xab^\x83\x8e\x82\x00;\xbf'
DEBUG:localtuya.pytuya:decrypted result=u'{"devId":"31xxxxxxxxxxxxxxxxf8","dps":{"1":"open","2":100,"3":100,"5":false,"7":"closing","8":"cancel","9":0,"10":0,"11":38610}}'
INFO:localtuya:COMPLETE response from device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29].
COVER DEVICE
localtuya.pytuya version 7.0.8
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
('Using PyCrypto ', (2, 6, 1, 'final', 0))
('Using PyCrypto from ', '/usr/lib/python2.7/dist-packages/Crypto/__init__.pyc')
INFO:localtuya:Requesting status of device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29], protocol 3.3.
DEBUG:localtuya.pytuya:status() entry (dev_type is device20)
DEBUG:localtuya.pytuya:json_payload='{"devId":"31xxxxxxxxxxxxxxxxf8","gwId":"31xxxxxxxxxxxxxxxxf8"}'
DEBUG:localtuya.pytuya:status received data='\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\n\x00\x00\x00\x9c\x00\x00\x00\x00H7L6\xf0\xd4\xcc\x11f\x8e\xbaI\xd1\xf1\x19%\x89m\xe8cB\xd6\x9cI\t8#\x8b\x1f\x1a\x07\x91N\x86-\xf62\x85p)R,\x8bg\x03"\xb2\xb5\x98\xb18\xcd\x16\xd0\xe7\x1f\xa9\xa4\xcb*\x10\x92B\xe7\x14M\r\x1b\x9cJ\xc4f\x87\x0b\x05H\xe2\xd7\x90.\xaa\x0e\x8as\x12oO\xa7;yS\xed~?\x9b~\x85\xd2P\xe3t\x0f\xc4\xa9\xdf\xe8d\xf0\xd6[\xed\x1dq$\x98\x1c)\xee\xd6/\x9a?\x9b\xbd`^\xb3\xd0\xc8\xe6\x9dl\x86\xbf\x83Z\xab^\x83\x8e\x82\x00;\xbf3\x9ac$\x00\x00\xaaU'
DEBUG:localtuya.pytuya:result='H7L6\xf0\xd4\xcc\x11f\x8e\xbaI\xd1\xf1\x19%\x89m\xe8cB\xd6\x9cI\t8#\x8b\x1f\x1a\x07\x91N\x86-\xf62\x85p)R,\x8bg\x03"\xb2\xb5\x98\xb18\xcd\x16\xd0\xe7\x1f\xa9\xa4\xcb*\x10\x92B\xe7\x14M\r\x1b\x9cJ\xc4f\x87\x0b\x05H\xe2\xd7\x90.\xaa\x0e\x8as\x12oO\xa7;yS\xed~?\x9b~\x85\xd2P\xe3t\x0f\xc4\xa9\xdf\xe8d\xf0\xd6[\xed\x1dq$\x98\x1c)\xee\xd6/\x9a?\x9b\xbd`^\xb3\xd0\xc8\xe6\x9dl\x86\xbf\x83Z\xab^\x83\x8e\x82\x00;\xbf'
DEBUG:localtuya.pytuya:decrypted result=u'{"devId":"31xxxxxxxxxxxxxxxxf8","dps":{"1":"open","2":100,"3":100,"5":false,"7":"closing","8":"cancel","9":0,"10":0,"11":38610}}'
INFO:localtuya:COMPLETE response from device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29].
COVER DEVICE
localtuya.pytuya version 7.0.8
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
('Using PyCrypto ', (2, 6, 1, 'final', 0))
('Using PyCrypto from ', '/usr/lib/python2.7/dist-packages/Crypto/__init__.pyc')
INFO:localtuya:Requesting status of device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29], protocol 3.3.
DEBUG:localtuya.pytuya:status() entry (dev_type is device20)
DEBUG:localtuya.pytuya:json_payload='{"devId":"31xxxxxxxxxxxxxxxxf8","gwId":"31xxxxxxxxxxxxxxxxf8"}'
DEBUG:localtuya.pytuya:status received data='\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\n\x00\x00\x00\x9c\x00\x00\x00\x00H7L6\xf0\xd4\xcc\x11f\x8e\xbaI\xd1\xf1\x19%\x89m\xe8cB\xd6\x9cI\t8#\x8b\x1f\x1a\x07\x91N\x86-\xf62\x85p)R,\x8bg\x03"\xb2\xb5\x98\xb18\xcd\x16\xd0\xe7\x1f\xa9\xa4\xcb*\x10\x92B\xe7\x14M\r\x1b\x9cJ\xc4f\x87\x0b\x05H\xe2\xd7\x90.\xaa\x0e\x8as\x12oO\xa7;yS\xed~?\x9b~\x85\xd2P\xe3t\x0f\xc4\xa9\xdf\xe8d\xf0\xd6[\xed\x1dq$\x98\x1c)\xee\xd6/\x9a?\x9b\xbd`^\xb3\xd0\xc8\xe6\x9dl\x86\xbf\x83Z\xab^\x83\x8e\x82\x00;\xbf3\x9ac$\x00\x00\xaaU'
DEBUG:localtuya.pytuya:result='H7L6\xf0\xd4\xcc\x11f\x8e\xbaI\xd1\xf1\x19%\x89m\xe8cB\xd6\x9cI\t8#\x8b\x1f\x1a\x07\x91N\x86-\xf62\x85p)R,\x8bg\x03"\xb2\xb5\x98\xb18\xcd\x16\xd0\xe7\x1f\xa9\xa4\xcb*\x10\x92B\xe7\x14M\r\x1b\x9cJ\xc4f\x87\x0b\x05H\xe2\xd7\x90.\xaa\x0e\x8as\x12oO\xa7;yS\xed~?\x9b~\x85\xd2P\xe3t\x0f\xc4\xa9\xdf\xe8d\xf0\xd6[\xed\x1dq$\x98\x1c)\xee\xd6/\x9a?\x9b\xbd`^\xb3\xd0\xc8\xe6\x9dl\x86\xbf\x83Z\xab^\x83\x8e\x82\x00;\xbf'
DEBUG:localtuya.pytuya:decrypted result=u'{"devId":"31xxxxxxxxxxxxxxxxf8","dps":{"1":"open","2":100,"3":100,"5":false,"7":"closing","8":"cancel","9":0,"10":0,"11":38610}}'
INFO:localtuya:COMPLETE response from device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29].
INFO:localtuya:TIMEOUT: No response from device 31xxxxxxxxxxxxxxxxf8 [192.168.1.29] after 2 attempts.
I’ve updated localtuya to 1.0.2, made the change in init.py, restarted Home Assistant, and my device is now connected to and added as a device & entity! Of course, the buttons don’t work yet–it looks like pressing up or down on the blind in lovelace UI is mapped to trying to get dps ‘1’ to ‘on’, when in fact it should be setting dps ‘3’ to a particular number. I’m pretty confident that I can fix that mapping myself later tonight.
Thanks so much for your help!
1 Like