search

rospogrigio / localtuya

local handling for Tuya devices
GNU General Public License v3.0
2.91k stars 557 forks source link

Tuya cover no respond to any command #164

Closed kspijkers closed 3 years ago

kspijkers commented 3 years ago

My Tuya Smart Curtain controller (product id: 75zgxageqaovbtgg) does not respond to any command. I've tried all different command combinations in the configuration flow.

postlund commented 3 years ago

Do you get past the initial dialog, so you can pick which entity to add? If you do, please attach a dump of all datapoints. You can just take a screenshot when expanding the dropdown menu.

kspijkers commented 3 years ago

Do you get past the initial dialog, so you can pick which entity to add? If you do, please attach a dump of all datapoints. You can just take a screenshot when expanding the dropdown menu.

Yeah, I can complete the whole proces, but there's just no response from the device to the up and down buttons in HA. I've tried all combinations of commands (open-close-stop, on-off-stop ect.)

2020-11-17 220959

2020-11-17 221054

postlund commented 3 years ago

back sounds like a new command set to me. @rospogrigio, you might want to go undercover on this one! 😎

kspijkers commented 3 years ago

back sounds like a new command set to me. @rospogrigio, you might want to go undercover on this one! 😎

Hmm I didn't noticed that, but I'm pretty sure the first few attempts I tried to get the thing working, I saw the ID's: 1 [value: stop], 2 [value: forward] and 3 [value: 34]

postlund commented 3 years ago

You mean you say DP 1 with value stop and DP 2 with value forward? DP 1 wasn't in the list in the screenshot you posted, was that a one-time-thing or does that usually happen?

If you feel like it, you can open cover.py and toy around with one of the existing command sets. Try changing the value of this line:

https://github.com/rospogrigio/localtuya/blob/0531a284c72c2750ff69ca9400cbf3dbd260dc8e/custom_components/localtuya/cover.py#L29

To for instance "back_forward_stop", add your cover and pick DP 2 as ID and try it out. Maybe you have some luck.

rospogrigio commented 3 years ago

back sounds like a new command set to me. @rospogrigio, you might want to go undercover on this one! 😎

Ahahahah 🤣

If you feel like it, you can open cover.py and toy around with one of the existing command sets.

OR you can try the commands using YAML configuration. Let us know how it goes, I believe the back_forward_stop combination might work!

kspijkers commented 3 years ago

You mean you say DP 1 with value stop and DP 2 with value forward? DP 1 wasn't in the list in the screenshot you posted, was that a one-time-thing or does that usually happen?

I've found out that when I try to control the device from HA nothing happens, but the buttons in the Smart Life then suddenly work in reverse (so the open button closes the cover and vice versa). Also the physical buttons then work in reverse. If I push the down button, the up button lights up and the cover opens. I can restore this by going in to the settings in the Smart Life app and change Motor reversal to 'back' and then back to 'forward'.

If I delete and add the cover again in Local Tuya, I get DP1 with value stop and DP2 with value forward again.

If you feel like it, you can open cover.py and toy around with one of the existing command sets. Try changing the value of this line:

https://github.com/rospogrigio/localtuya/blob/0531a284c72c2750ff69ca9400cbf3dbd260dc8e/custom_components/localtuya/cover.py#L29

To for instance "back_forward_stop", add your cover and pick DP 2 as ID and try it out. Maybe you have some luck.

I've tried "back_forward_stop" and "up_down_stop" but no luck so far. Any suggestions?

Frans1960 commented 3 years ago

I have the same issue with cover switches from Lolatap SC400 V3. I have configured the Switch and the only command that seem to work is the Stop Command. This is the Debug Logis attached. LocalTuyaDebugLog.txt

kspijkers commented 3 years ago

Just checked my order from AliExpress and mine are LoraTap SC400W-EU devices

leomarquezd commented 3 years ago

Hello, I also have problems to make a loratap cover switch work (SC500W v2 in my case). It works fine with the smart life app, but the entity generated in home assistant is always unavailable. I configured it through yaml because I don't find the config flow option (not sure if it is because of running HA in docker, any clues?). I also tried to detect the device with tuya utilities. Tuyapower only detects a smart plug, which is already working fine in HA through localtuya. And this is the information I get when I run test.py against the cover switch IP:

INFO:localtuya:localtuya version 1.0.0 INFO:localtuya:Python 3.7.9 (v3.7.9:13c94747c7, Aug 15 2020, 01:31:08) [Clang 6.0 (clang-600.0.57)] on darwin INFO:localtuya:Using pytuya version '8.1.0' INFO:localtuya:Detecting list of available DPS of device 18843388b8f0090040c8 [192.168.1.152], protocol 3.3. DEBUG:localtuya.pytuya:Sending command status (device type: type_0a) DEBUG:localtuya.pytuya:paylod=b'{"gwId":"18843388b8f0090040c8","devId":"18843388b8f0090040c8"}' DEBUG:localtuya.pytuya:DATA RECEIVED! DEBUG:localtuya.pytuya:decode payload=b'\xebc\xd0v\xa2p\xd22\xb9tC\x854\xe3;\xdb\xf4N\x14~\xa5\xf30\xeey\x05&H>\xbc[\x87' DEBUG:localtuya.pytuya:decrypted result='' DEBUG:localtuya.pytuya:Failed to connect to 192.168.1.152. Raising Exception. WARNING:localtuya.pytuya:Failed to get status: Expecting value: line 1 column 1 (char 0) INFO:localtuya:Detecting list of available DPS of device 18843388b8f0090040c8 [192.168.1.152], protocol 3.3. DEBUG:localtuya.pytuya:Sending command status (device type: type_0a) DEBUG:localtuya.pytuya:paylod=b'{"gwId":"18843388b8f0090040c8","devId":"18843388b8f0090040c8"}' DEBUG:localtuya.pytuya:DATA RECEIVED! DEBUG:localtuya.pytuya:decode payload=b'\xebc\xd0v\xa2p\xd22\xb9tC\x854\xe3;\xdb\xf4N\x14~\xa5\xf30\xeey\x05&H>\xbc[\x87' DEBUG:localtuya.pytuya:decrypted result='' DEBUG:localtuya.pytuya:Failed to connect to 192.168.1.152. Raising Exception. WARNING:localtuya.pytuya:Failed to get status: Expecting value: line 1 column 1 (char 0) INFO:localtuya:Detecting list of available DPS of device 18843388b8f0090040c8 [192.168.1.152], protocol 3.3. DEBUG:localtuya.pytuya:Sending command status (device type: type_0a) DEBUG:localtuya.pytuya:paylod=b'{"gwId":"18843388b8f0090040c8","devId":"18843388b8f0090040c8"}' DEBUG:localtuya.pytuya:DATA RECEIVED! DEBUG:localtuya.pytuya:decode payload=b'\xebc\xd0v\xa2p\xd22\xb9tC\x854\xe3;\xdb\xf4N\x14~\xa5\xf30\xeey\x05&H>\xbc[\x87' DEBUG:localtuya.pytuya:decrypted result='' DEBUG:localtuya.pytuya:Failed to connect to 192.168.1.152. Raising Exception. WARNING:localtuya.pytuya:Failed to get status: Expecting value: line 1 column 1 (char 0) INFO:localtuya:TIMEOUT: No response from device 18843388b8f0090040c8 [192.168.1.152] after 2 attempts.

I'm not sure if it helps, but I ran a nmap against the ip of the cover device and I found the 6668/tcp and 49154/udp ports opened.

Please let me know if I can help debugging this problem, I'm really interested in having loratap cover switches working in HA.

Thank you very much!

leomarquezd commented 3 years ago

Here is also the HA log error. The IP shown is the correct IP of the cover switch:

`Logger: custom_components.localtuya.common Source: custom_components/localtuya/pytuya/init.py:240 Integration: LocalTuya integration (documentation, issues) First occurred: 26 de diciembre de 2020 22:01:14 (467 occurrences) Last logged: 17:22:22

[188...0c8] Connect to 192.168.1.152 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 451, in exchange msg = await self.dispatcher.wait_for(seqno) File "/config/custom_components/localtuya/pytuya/init.py", line 240, in wait_for await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout) File "/usr/local/lib/python3.8/asyncio/tasks.py", line 498, in wait_for raise exceptions.TimeoutError() asyncio.exceptions.TimeoutError`

postlund commented 3 years ago

@leomarquezd The problem you are seeing is usually happening because of incorrect local key (like 99% of the time).

leomarquezd commented 3 years ago

Thank you very much Pierre, you are right! I probably copied & pasted the wrong one :-) Now the entity shows the up/stop/down buttons enabled in HA but nothing happens when I click them. I guess I have to fix something in the configuration.

postlund commented 3 years ago

Thank you very much Pierre, you are right! I probably copied & pasted the wrong one :-) Now the entity shows the up/stop/down buttons enabled in HA but nothing happens when I click them. I guess I have to fix something in the configuration.

You probably need to configure the correct command set. You have the ones we currently support here:

https://github.com/rospogrigio/localtuya/blob/d8de7e36b1e129d867ebafb927fce04858c2c6b5/custom_components/localtuya/__init__.py#L24

leomarquezd commented 3 years ago

Thank you very much again Pierre. First I was using the old configuration parameter open_close_cmds instead of command_set. Then I tried until 1_2_3, which made the job.

leomarquezd commented 3 years ago

Hello again, after some weeks working fine, today I was adding a second tuya cover switch (SC500W v2) and I realised that in the HA UI, the down button is no longer enabled, even when the cover is up. So, from HA, I'm able to open the cover but I can't close it. I'm not sure since when this is happening because I was managing the cover through Alexa. From the smart life app the covers are working fine (up & down). I haven't modified the command set, which was working fine previously 1_2_3. Any idea about what could be happening?

Thank you very much

leomarquezd commented 3 years ago

I confirm this is happening in 3.2.0, switching back to 3.1.0 is working fine

rospogrigio commented 3 years ago

Are you using the "timed" positioning? If so, what is the current position you can see in the slider? You may want to try the "inverted" parameter, also...

leomarquezd commented 3 years ago

I see 3.2.0 includes breaking changes for the positioning mode, but I'm not defining it in the yaml so I assume it is 'none' in my case. I'm a little bit lost with the positioning mode so I left it as default. BTW, is there any extra doc than the one in the readme about positioning? I don't understand what currpos_dp or setpos_dp mean for the position mode, or if it's preferable going for the timed mode.

rospogrigio commented 3 years ago

Some devices keep track internally of the cover position using an encoder, and provide the position value in one of the DPs (currpos_dp). Moreover, they allow to be operated by setting a target position in another DP (setpos_dp), and this is done with the slider. Other devices don't have this feature, so I created this "timed" (previously called "fake") positioning mode, that keeps track of the position by measuring the time between events, and also allows to use the slider for positioning my sending commands with proper time intervals. This said, if you are not using the "timed" mode, you should not see the slider (please confirm) and both open and close buttons should be always available. If it's not happening, you may try to log something in the is_open and is_closed methods and help us debug what's going on...

rospogrigio commented 3 years ago

OK @leomarquezd I think I nailed it, please try PR #301 and report feedback, thank you...

leomarquezd commented 3 years ago

Thank you very much @rospogrigio for the explanation about the positioning and for looking into the problem. Although I'm not familiar with HA development, I can help testing the fix. What would be the easiest way in this case? I was thinking in updating to 3.2.0, and then copy the new cover.py with your modifications into it.