Tuya cover (yh002) not responding

[nick-disiere]

The problem

On a new flash of ESPHome via serial to the yh002-a Tuya blinds motor, no tuya output is received. Multiple combinations of the expected baud rates and GPIO configurations were attempted:

9600/115200 baud UART0 - TX: GPIO1, RX: GPIO3 UART0_SWAP - TX: GPIO15, RX: GPIO13 (Only on ESP8266) UART1 - TX: GPIO2, RX: None (Only on ESP8266)

The device does register as online in HA, and creates cover entries if specified. I'm curious to see if this device is still supported on the tuya platform?

Which version of ESPHome has the issue?

ESPHome version 2022.2.4 compiled on Feb 21 2022, 20:25:20

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

Home Assistant 2022.2.9

What platform are you using?

ESP8266

Board

TYWE1S

Component causing the issue

tuya

Example YAML snippet

esphome:
  name: -snip-

esp8266:
  board: esp01_1m

# Enable logging
logger:
  baud_rate: 0

# Enable Home Assistant API
api:

ota:
  password: -snip-

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

uart:
  rx_pin: GPIO3
  tx_pin: GPIO1
  baud_rate: 9600

# Register the Tuya MCU connection
tuya:

Anything in the logs that might be useful for us?

[20:25:57][C][logger:233]: Logger:
[20:25:57][C][logger:234]:   Level: DEBUG
[20:25:57][C][logger:235]:   Log Baud Rate: 0
[20:25:57][C][logger:236]:   Hardware UART: UART0
[20:25:57][C][uart.arduino_esp8266:102]: UART Bus:
[20:25:57][C][uart.arduino_esp8266:103]:   TX Pin: GPIO1
[20:25:57][C][uart.arduino_esp8266:104]:   RX Pin: GPIO3
[20:25:57][C][uart.arduino_esp8266:106]:   RX Buffer Size: 256
[20:25:57][C][uart.arduino_esp8266:108]:   Baud Rate: 9600 baud
[20:25:57][C][uart.arduino_esp8266:109]:   Data Bits: 8
[20:25:57][C][uart.arduino_esp8266:110]:   Parity: NONE
[20:25:57][C][uart.arduino_esp8266:111]:   Stop bits: 1
[20:25:57][C][uart.arduino_esp8266:113]:   Using hardware serial interface.
[20:25:57][C][mdns:084]: mDNS:
[20:25:57][C][mdns:085]:   Hostname: -snip-
[20:25:57][C][ota:085]: Over-The-Air Updates:
[20:25:57][C][ota:086]:   Address: -snip-
[20:25:57][C][ota:089]:   Using Password.
[20:25:57][C][api:138]: API Server:
[20:25:57][C][api:139]:   Address: -snip-
[20:25:57][C][api:143]:   Using noise encryption: NO
[20:25:57][C][tuya:028]: Tuya:
[20:25:57][C][tuya:030]:   Configuration will be reported when setup is complete. Current init_state: 0
[20:25:57][C][tuya:032]:   If no further output is received, confirm that this is a supported Tuya device.

Additional information

No response

[nick-disiere]

This is probably unhelpful, but I did get far enough with Tasmota to get positional data to report when pressing the physical buttons. However, no response from any of the commands issued from the web console. There may have been a protocol change preventing either solution from working.

[RichardGomer]

I've had a similar problem with Tasmota. The board appears to be different to older versions of the same model. In case it helps, I sniffed the serial connection on a device with the stock firmware, controlled via the SmartLife app.

These are the messages that the original Tuya firmware sends to the MCU:

Set the blind position to 30% 55 aa 00 06 00 08 02 02 00 00 00 00 1e 33 (1e = 30)

Set the blind position to 79% 55 aa 00 06 00 08 02 02 00 00 00 00 4f 64 (4f = 79)

Afraid that's as far as I've got so far!

[nick-disiere]

I've found the issue you posted in the Tasmota tracker. Looks like a simple solution, but I can't find an easy way to test it without being able having to rebuild either Tasmota or ESPHome, and I can't find where to manually install ESPHome if I recompiled it.

But for the ESPHome standpoint, there's a change to Tuya::send_rawcommand in Tuya.cpp. We need to substitute the two payload bytes to a single 00 byte. We'd also have to only have this communication method used as a fallback so we don't break existing devices using the old MCU. Probably.

[rojoricardo]

I have the same issue, has there been any updates or something to solve this issue? im sure im not the only one...

[nick-disiere]

I've got a dev environment set up, but the new checksum is calculated differently. If someone can sniff a 0 and 100 I can hardcode those, or if someone can explain how those new bytes are calculated, I can implement that.

[angryninja48]

Any luck with this? I've purchased new yh002's, flashed them and nothing works apart from the buttons on the device itself.

[pauly2805]

I got some new yh002 and have the same issue. I have tried sending the exact commands the original firmware sends and it isn't working for some reason. Not entirely sure but I have read apparently these use 'wifi low power' tuya protocol which is why there is no heartbeat (in esphome, it gets stuck in init because no heartbeat response). I played around with the code a bit to send raw telegrams and couldn't get anything to work. I know serial is set up correct because it reports positions correctly when pressing the physical buttons. [edit: it does not use low power mode. As per following posts, it uses normal tuya serial comms but unlike older tuya MCU, it ignores all comms until paired]

The motor driver is a PT5126. This is easy to control - 2 input logic pins that are just logic high/low combos to drive motor forward/reverse/stop. Quick test directly shorting these pins to 3v3 works - could just bridge these to ESP and GPIO drive (it's not PWM or anything fancy - just straight high/low on/off). Problem with this is no position report and the endstops are overridden, would need to handle that as well

So there's a few individual things that are easily achievable that perhaps can be combined...

1. Drive PT5126 inputs direct from esp gpio. Motor drive easy, endstops/position report more work
2. Activate physical buttons, then can get position feedback via tuya mcu and endstops are respected. Could do rough position commands with some logic
3. Not yet investigated - use the RF 433mhz to control via rf bridge, receive position status from tuya mcu. Apparently there's also a 2-way RF protocol on some blinds where position can be received via RF. I haven't currently got any RF devices or bridges so first need to research bridges and buy one :)

[pauly2805]

Scratch that - I now have it fully working just talking to tuya MCU, without esphome code changes needed. TL;DR: after flashing esphome, to get it to initialise correctly:

1. Factory reset (hold up and down button together for 8 sec)
2. set the device endstop limits (hold stop for 5 sec, press down, press stop)
3. Power cycle After this all of a sudden it went through initialisation and all functions worked. Relevant info: Exact device is Kogan SmarterHome Blinds: https://www.kogan.com/au/buy/kogan-smarterhome-smart-blinds-driver-kogan/ TYWE1S chip: firmware v3.1.4 (before esphome) Tuya MCU firmware: 3.1.7

uart: rx_pin: GPIO13 tx_pin: GPIO15 baud_rate: 9600

cover:

• platform: "tuya" name: "${friendly_name}" device_class: shade control_datapoint: 1 position_datapoint: 2 position_report_datapoint: 3 direction_datapoint: 5

Additional info: All of the MCU and wifi module info can be obtained from tuya, including their serial protocol debugging app - this was my next step, fortunately not needed. With this it will emulate either esp chip OR tuya MCU to test serial comms. On Tuya product development:

1. Create Product
2. Curtain -> wifi only
3. Hardware Development: MCU SDK -> select chip TYJW2S-3.3V-BL Wi-Fi Module with firmware 3.1.4
4. Download debug assistant and device config file
5. Also available: pdf of serial protocol etc (turns out it's actually unchanged on device I have - just doesnt do anything until factory reset)

[pauly2805]

Further update: From flashing more modules the main step seems to just be pairing mode which resets tuya MCU (while wifi module on), and then initialises and begins working. This is achieved by holding up and stop buttons together for ~5sec. Output:

10:48:13	[E]	[tuya:409]	Initialization failed at init_state 0
10:48:25	[E]	[tuya:217]	WIFI_SELECT is not handled
10:48:27	[I]	[tuya:151]	MCU restarted
10:48:27	[D]	[tuya:456]	Sending WiFi Status
10:48:27	[D]	[tuya.cover:100]	Setting direction: normal
10:48:27	[D]	[tuya:547]	Setting datapoint 5 to 0
10:48:27	[D]	[tuya:300]	Datapoint 1 update to 1
10:48:27	[D]	[tuya:288]	Datapoint 2 update to 0
10:48:27	[D]	[tuya:288]	Datapoint 3 update to 100
10:48:27	[D]	[cover:170]	'3D Printer Room Blinds' - Publishing:
10:48:27	[D]	[cover:173]	Position: 0%
10:48:27	[D]	[cover:186]	Current Operation: IDLE
10:48:27	[D]	[tuya:280]	Datapoint 5 update to OFF
10:48:27	[D]	[tuya:280]	Datapoint 6 update to OFF
10:48:27	[D]	[tuya:300]	Datapoint 7 update to 1
10:48:28	[D]	[tuya:300]	Datapoint 8 update to 0
10:48:28	[D]	[tuya:288]	Datapoint 9 update to 0
10:48:28	[D]	[tuya:317]	Datapoint 10 update to 00000000
10:48:28	[D]	[tuya:288]	Datapoint 11 update to 5365
10:48:28	[C]	[tuya:033]	Tuya:
10:48:28	[C]	[tuya:054]	Datapoint 1: enum (value: 1)
10:48:28	[C]	[tuya:050]	Datapoint 2: int value (value: 0)
10:48:28	[C]	[tuya:050]	Datapoint 3: int value (value: 100)
10:48:28	[C]	[tuya:048]	Datapoint 5: switch (value: OFF)
10:48:28	[C]	[tuya:048]	Datapoint 6: switch (value: OFF)
10:48:28	[C]	[tuya:054]	Datapoint 7: enum (value: 1)
10:48:28	[C]	[tuya:054]	Datapoint 8: enum (value: 0)
10:48:28	[C]	[tuya:050]	Datapoint 9: int value (value: 0)
10:48:28	[C]	[tuya:056]	Datapoint 10: bitmask (value: 0)
10:48:28	[C]	[tuya:050]	Datapoint 11: int value (value: 5365)
10:48:28	[C]	[tuya:068]	Product: '{"p":"ebt12ypvexnixvtf","v":"YHF23.1.7.1","m":0}'

[nick-disiere]

I've confirmed this solution works on the aliexpress yh002-a as well. It persists through power cycling and even an esphome reflash. That's maddening, but thank you, Pauly

[angryninja48]

Confirmed working here as well - Thanks @pauly2805