Help with Tuya Cover component and Zemismart ZM79E-DT curtain motor

Has anyone else tried to use the Tuya Cover component with a Zemismart curtain motor? Specifically the ZM79E-DT? The docs say that ZM79E-DT is supported, but so far I haven’t been able to get any response from my motor.

I’m trying to use an esp8266 D1 Mini to run the Tuya cover component. The example in the component docs show using GPIO13 and GPIO15; I’m using D7 and D8 on my D1 mini, so my YAML looks exactly like the example.

I connected D7 and D8 to the pins that the ZM79E-DT says are 485A and 485B. I’m not sure which of those is RX and which is TX, but I’ve tried it both ways.

The component docs say that I should see some logs that indicate what has been discovered by the Tuya component, so since I never see anything, I’m wondering if the 485A/485B pins aren’t actually what I want? The ESPHome logs show:

[18:29:46][C][tuya:031]:   Configuration will be reported when setup is complete. Current init_state: 0
[18:29:46][C][tuya:032]:   If no further output is received, confirm that this is a supported Tuya device.

Here’s the ZM79E-DT docs showing the RS-485 pins:

And here’s the chip in my motor:

The cable plugged into the RJ45 jack is what I’m using to try and connect to the RS-485 pins.

I don’t know how common this model is, or if there’s any hope that anybody else out there has already conquered this problem; but the fact that it’s mentioned in the docs gives me hope.

Thanks for any help!

That is odd, as a google search points me to it being a zigbee device. Zemismart Curtain motor ZM79E-DT Zigbee compatibility. Zemismart do wifi and zigbee, so maybe they have two different devices with the same model number.

Even if they have a wifi version and it once contained an esp8266/32, yours doesn’t. Your photo shows a WBR1 chip, which is a TUYA in-house chip, and not esp compatible.

Also I don’t think you connect to the tuya MCU chip. It says it is RS485 so maybe it will work with this Modbus Controller — ESPHome

Yeah, I was surprised to find that there is a Zigbee version with the same model number… weird.

I’ll play with the modbus stuff and see if I can get anything to work. Thanks!

In the meantime, Zemismart responded to my question about the RS-485 interface. I haven’t quite figured out how to interpret what they sent me… but here it is:

0. UART Communication format
Baud rate: 9600 
Start bit : 1 
Data bit: 8 
Stop bit: 1 
Parity: none 

1,Control the motor with the same address code to turn on, off and stop.
Checksum = 3 + 4 + 5 
0    1   2     3     4     5    6       
FF  AA  Len  Addr  Type  cmd   checksum       
FF  AA  04    00    11    01    12
FF AA 04 00 11 01 12        On (corresponding to the up key of the remote control) //Address 00 
FF AA 04 00 11 02 13        Off (corresponding to the down key on the remote control) 
FF AA 04 00 11 03 14        Stop

// 0    1   2     3     4     5       6       7      8   
// FF  AA  Len  Addrs  Type  cmd   addr   addr_num  checksum
0    1   2   3   4   5   6   7   8
FF  AA  06  00  17  01  01  01  XX

6, for the address    01~05
7,for the address code  00~FF
8, Checksum = 3 + 4 + 5 + 6 + 7 
Write the 01 address to the motor (before writing the address code, short press the setting button on the motor, the blue light on the motor will be long on, and then send the write code command, and the write code command is only valid during the blue light long on)
FF AA 06 00 17 01 01 01 1A
FF AA 06 00 17 01 02 08 22                            use when grouping

Write 02 address to the motor
FF AA 06 00 17 01 01 02 1B
FF AA 06 00 17 01 02 08 22    //use when grouping

. . . . . .
FF AA 06 00 17 01 01 03 1C
FF AA 06 00 17 01 01 04 1D
FF AA 06 00 17 01 01 05 1E
FF AA 06 00 17 01 01 06 1F
FF AA 06 00 17 01 01 07 20

(Before deleting the address code, short press the setting button on the motor, the blue light on the motor will be on, and then send the delete code command, and the delete code command is only valid when the blue light is on)
FF AA 06 00 17 11 00 00 28    delete all address codes

 1   2    3   4   5   6   7
FF  AA  04  00  11  01   12

4,for the address code  00~FF
7, Checksum = 4 + 5 + 6 


FF AA 04address code 11 01 12

Control address 01 motor
FF AA 04 01 11 01 13        open (Corresponding to the up key of the remote control) //Address 00
FF AA 04 01 11 02 14        Off (corresponding to the down key on the remote control)
FF AA 04 01 11 03 15        stop

Control address 02 motor
FF AA 04 02 11 01 14        On (corresponding to the up key of the remote control) //Address 00 
FF AA 04 02 11 02 15        Off (corresponding to the down key on the remote control)
FF AA 04 02 11 03 16        stop

Simultaneously control motors with addresses 01 and 02
FF AA 04 08 11 01 1A        On (corresponding to the up key of the remote control) //Address 00
FF AA 04 08 11 02 1B        Off (corresponding to the down key on the remote control)
FF AA 04 08 11 03 1C        stop

I got things working using the open/close/stop pins on the RJ45 connector instead of the RS-485 stuff.

I didn’t go with this route originally because the open/close/stop pins have to be connected to ground, so I figured that’d mean 3 transistors and 3 resistors, and a breadboard or something to tie it all together. I was hoping to keep things a bit more compact.

But then I realized I could just switch GPIO pin modes between input (disconnected) and output low (connected to ground). So now I have it working with this:

cover:
  - platform: template
    name: "Curtains"
    id: curtains
    assumed_state: true
    open_action:
      - lambda: |-
          pinMode(14, OUTPUT);
          digitalWrite(14, LOW);
          delayMicroseconds(1000000);
          pinMode(14, INPUT);
    close_action:
      - lambda: |-
          pinMode(12, OUTPUT);
          digitalWrite(12, LOW);
          delayMicroseconds(1000000);
          pinMode(12, INPUT);
    stop_action:
      - lambda: |-
          pinMode(2, OUTPUT);
          digitalWrite(2, LOW);
          delayMicroseconds(1000000);
          pinMode(2, INPUT);

Recent units were shipped with the WBR1 module, that is a bit tricky to flash, at least because the A_0 pin is on the back and requires the module to be desoldered properly. Btw, I’ve read the TYWE1S was easier to deal with.

Found my way by removing it completely and instead solder a CB2S (taken from a smart plug). You may also use the ESP02s chip (yaml to be adapted then).
Since it is not the same form factor, you may use short wires for connecting CON1 and the module, and finally apply some hot glue to secure the module and the breakout board.

Connector 1 on the breakboard :

     CON1
     _____
GND | . . | VIN (5V)
GND | . . | 3.3V
 TX | . . | RX

YAML :

bk72xx:
  board: cb2s

uart:
  rx_pin: P10
  tx_pin: P11
  baud_rate: 9600

tuya:
  id: house

# https://www.esphome.io/components/cover/tuya#supported-devices
# Zemismart ZM79E-DT and YH002 (curtain motor)
# Supported datapoints: control (1), position (2), position_report (3) and direction (5).
# tuyaDatapoint 1 : open:0x00 stop:0x01 close:0x02

cover:
  - platform: tuya
    name: ${friendly_name} Position
    control_datapoint: 1
    position_datapoint: 2
    position_report_datapoint: 3
    direction_datapoint: 5
    icon: mdi:curtains

CON1 <-> Module
_______________
3.3V <-> VCC
GND  <-> GND
TX   <-> RX1
RX   <-> TX1

Now the position can be controlled and reported.

For information, the ESPHome logs :

[22:47:35][C][tuya:041]: Tuya:
[22:47:35][C][tuya:062]:   Datapoint 1: enum (value: 2)
[22:47:35][C][tuya:058]:   Datapoint 2: int value (value: 100)
[22:47:35][C][tuya:058]:   Datapoint 3: int value (value: 100)
[22:47:35][C][tuya:056]:   Datapoint 5: switch (value: OFF)
[22:47:35][C][tuya:064]:   Datapoint 10: bitmask (value: 0)
[22:47:35][C][tuya:074]:   Product: '{"p":"qsz87tjgccxlahal","v":"1.0.0","m":1}'