Tuya device not supported but TuyaMCU responds to heartbeat

[crespum]

The problem

I've ordered a few Tuya S06Pro sensors online (Wi-Fi IR remote + temperature & humidity) but I received two different PCB versions (in theory with the same functionality). The IR is working fine on both versions, however, the sensor (AHT20) is not responding on the oldest version. See attached pictures for reference.

I'm using the same configuration on both devices but the logs of the non-working one (marked as 2023-08-04) claim that the Tuya device is not supported:

[20:45:00][C][tuya:041]: Tuya:
[20:45:00][C][tuya:046]:   Configuration will be reported when setup is complete. Current init_state: 4
[20:45:00][C][tuya:049]:   If no further output is received, confirm that this is a supported Tuya device.

I've enabled UART debug and it's parsing what seems to be the heartbeat:

[20:45:00][C][lt.component:013]: LibreTiny:
[20:45:00][C][lt.component:014]:   Version: v1.5.1 on wb3s, compiled at Jun  9 2024 20:42:21, GCC 10.3.1 (-O1)
[20:45:00][C][lt.component:015]:   Loglevel: 3
[20:45:00][C][tuya:041]: Tuya:
[20:45:00][C][tuya:046]:   Configuration will be reported when setup is complete. Current init_state: 4
[20:45:00][C][tuya:049]:   If no further output is received, confirm that this is a supported Tuya device.
[20:45:01][D][uart_debug:114]: >>> 55:AA:00:08:00:00:07
[20:45:01][D][uart_debug:114]: >>> 55:AA:00:08:00:00:07
[20:45:01][D][uart_debug:114]: >>> 55:AA:00:08:00:00:07
[20:45:01][D][uart_debug:114]: >>> 55:AA:00:08:00:00:07
[20:45:02][E][tuya:434]: Initialization failed at init_state 4
[20:45:04][D][api:102]: Accepted 192.168.1.15
[20:45:04][W][component:237]: Component api took a long time for an operation (124 ms).
[20:45:04][W][component:238]: Components should block for at most 30 ms.
[20:45:04][D][api.connection:1321]: Home Assistant 2024.6.0 (192.168.1.15): Connected successfully
[20:45:13][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF
[20:45:13][D][uart_debug:114]: <<< 55:AA:03:00:00:01:01:04
[20:45:28][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF
[20:45:28][D][uart_debug:114]: <<< 55:AA:03:00:00:01:01:04
[20:45:43][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF

The logs of the working device (marked as 2023-09-19) are the following (again, configuration is the same):

[21:03:19][C][lt.component:013]: LibreTiny:
[21:03:19][C][lt.component:014]:   Version: v1.5.1 on wb3s, compiled at Jun  9 2024 20:59:28, GCC 10.3.1 (-O1)
[21:03:19][C][lt.component:015]:   Loglevel: 3
[21:03:19][C][tuya:041]: Tuya:
[21:03:19][C][tuya:058]:   Datapoint 101: int value (value: 223)
[21:03:19][C][tuya:058]:   Datapoint 102: int value (value: 68)
[21:03:19][C][tuya:070]:   GPIO Configuration: status: pin 9, reset: pin 6
[21:03:19][C][tuya:074]:   Product: '{"p":"whs3cty93fzrqkpt","v":"1.0.0","m":0,"ir":"26.8"}'
[21:03:22][D][api:102]: Accepted 192.168.1.15
[21:03:23][W][component:237]: Component api took a long time for an operation (126 ms).
[21:03:23][W][component:238]: Components should block for at most 30 ms.
[21:03:23][D][api.connection:1321]: Home Assistant 2024.6.0 (192.168.1.15): Connected successfully
[21:03:23][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF
[21:03:24][D][uart_debug:114]: <<< 55:AA:03:00:00:01:01:04
[21:03:38][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF
[21:03:39][D][uart_debug:114]: <<< 55:AA:03:00:00:01:01:04
[21:03:53][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF
[21:03:54][D][uart_debug:114]: <<< 55:AA:03:00:00:01:01:04
[21:04:08][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF
[21:04:09][D][uart_debug:114]: <<< 55:AA:03:00:00:01:01:04
[21:04:15][D][tuya:313]: Datapoint 101 update to 224
[21:04:15][D][main:040]: on_datapoint_update (temp) 224
[21:04:15][D][sensor:093]: 'Temperatura': Sending state 22.40000  with 1 decimals of accuracy
[21:04:15][D][climate:396]: 'HVAC' - Sending state:
[21:04:15][D][climate:399]:   Mode: OFF
[21:04:15][D][climate:404]:   Fan Mode: AUTO
[21:04:15][D][climate:416]:   Swing Mode: OFF
[21:04:15][D][climate:419]:   Current Temperature: 22.40°C
[21:04:15][D][climate:425]:   Target Temperature: 24.00°C
[21:04:16][D][uart_debug:114]: <<< 55:AA:03:07:00:08:65:02:00:04:00:00:00:E0:5C
[21:04:16][D][tuya:313]: Datapoint 102 update to 67
[21:04:16][D][main:045]: on_datapoint_update (hum) 67
[21:04:16][D][sensor:093]: 'Humidade Estudio': Sending state 67.00000  with 0 decimals of accuracy
[21:04:16][D][uart_debug:114]: <<< 55:AA:03:07:00:08:66:02:00:04:00:00:00:43:C0
[21:04:23][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF
[21:04:24][D][uart_debug:114]: <<< 55:AA:03:00:00:01:01:04

Which version of ESPHome has the issue?

2024.5.5

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

No response

What platform are you using?

BK72XX

Board

Tuya S06Pro

Component causing the issue

TuyaMCU

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[szupi-ipuzs]

Hi, could you post the yaml config you use for these devices?

The first log suggests that tuyamcu does not respond to heartbeat at the beginning, but starts to respond after wifi connects. I suspect this could be because the "wifi ready" state is sent to tuyamcu too late. I have created a pull request esphome/esphome#7028 in which this state is faked and it should be forwarded to tuyamcu very early at startup. You can try this PR and see if the behavior got better.

[crespum]

That was my first guess too. I tried to delay the startup of the Tuya component using some ESPHome configuration but unfortunately I haven't saved the configuration I used in those test.

Anyway, find -part of- the current configuration below:

uart:
  tx_pin: P11
  rx_pin: P10
  baud_rate: 9600
  debug:

tuya:
  on_datapoint_update:
    - sensor_datapoint: 101
      datapoint_type: int
      then:
        - lambda: |-
            ESP_LOGD("main", "on_datapoint_update (temp) %i", x);
    - sensor_datapoint: 102 # sample dp
      datapoint_type: int
      then:
        - lambda: |-
            ESP_LOGD("main", "on_datapoint_update (hum) %i", x);

sensor:
  - platform: "tuya"
    id: temp
    name: "Temperatura"
    sensor_datapoint: 101
    icon: "mdi:thermometer"
    accuracy_decimals: 1
    filters: 
      multiply: 0.1
  - platform: "tuya"
    name: "Humidade"
    sensor_datapoint: 102
    icon: "mdi:water-percent"
    accuracy_decimals: 0

status_led:
  pin:
    number: P9
    inverted: true

remote_transmitter:
  pin: P26
  carrier_duty_percent: 50%

remote_receiver:
  id: irrecv
  pin:
   number: P8
   inverted: true
   mode:
     input: true
     pullup: true
  #dump: all

climate:
  - platform: fujitsu_general
    name: "Clima"
    sensor: temp
    receiver_id: irrecv

[szupi-ipuzs]

Hmm, have you noticed that tuyamcu requires wifi status to be reported via a pin?

GPIO Configuration: status: pin 9

I don't see it set in your yaml. If I understand the esphome documentation correctly, you should specify it manually. I believe it should look like this in your case:

tuya:
  status_pin: P9
  on_datapoint_update:
...

If that doesn't help, you can also try adding add the time component and set:

tuya:
  time_id: your_time_id
  status_pin: P9
  on_datapoint_update:
...

I don't know if there's a way to tell if your device needs it, but it shouldn't hurt to add it.

[ssieb]

The first device isn't responding to the datapoint request. It responded to everything before that, including the heartbeat.

[crespum]

Adding status_pin: P9 doesn't fix the issue:

[18:57:56][C][lt.component:013]: LibreTiny:
[18:57:56][C][lt.component:014]:   Version: v1.5.1 on wb3s, compiled at Jul 19 2024 18:54:03, GCC 10.3.1 (-O1)
[18:57:56][C][lt.component:015]:   Loglevel: 3
[18:57:56][C][tuya:041]: Tuya:
[18:57:56][C][tuya:044]:   Initialization failed. Current init_state: 4
[18:57:56][C][tuya:049]:   If no further output is received, confirm that this is a supported Tuya device.
[18:57:59][D][api:102]: Accepted 192.168.1.15
[18:57:59][W][component:237]: Component api took a long time for an operation (122 ms).
[18:57:59][W][component:238]: Components should block for at most 30 ms.
[18:57:59][D][api.connection:1375]: Home Assistant 2024.6.3 (192.168.1.15): Connected successfully
[18:58:00][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF
[18:58:00][D][uart_debug:114]: <<< 55:AA:03:00:00:01:01:04
[18:58:15][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF
[18:58:15][D][uart_debug:114]: <<< 55:AA:03:00:00:01:01:04
[18:58:30][D][uart_debug:114]: >>> 55:AA:00:00:00:00:FF

Note that it's not sending the 55:AA:00:08:00:00:07 packet anymore, but I think it has to do with some esphome update because I've tried with and without status_pin and I don't see it anymore...

[ssieb]

It depends on how long it takes you to connect for logs. That command might have already been tried before you connect.

[szupi-ipuzs]

There's an option to print logs from before wifi connection was estabilished using my buff_log component. This will hopefully let you see the exchange of commands with tuyamcu from the very beginning and maybe this will tell us more.

[szupi-ipuzs]

Adding status_pin: P9 doesn't fix the issue:

I've just noticed that P9 was already used in your setup for status led:

status_led:
  pin:
    number: P9
    inverted: true

Doesn't this create a conflict with the tuya status pin? Could you try again without this status_led part?

[crespum]

Sure, there's a conflict with status_led. I had to disable it before using it in status_pin.

BTW, I have not been able to try the my_buff_log component yet.