[BK7231N] Configuring Tuya CO400A-A004 (Carbon Monoxide Detector) with (OpenBeken)

Question

I just got a Carbon Monoxide Detector from AliExpress and wanted to free this thing from the cloud.  Basic Information: Brand: Tuya? Model: CO400A-A004 Chip: BK7231N (CBU) Local vendor:  AliExpress Teardown Photos: i already flashed OpenBeken on the device since i did this for my smoke detectors...

Samezrp1 · Accepted Answer

Today I came across this topic by chance, in a separate here .
have tried to understand the device a little.
A lot of information is repeated, but maybe my findings will inspire someone.

Below found commands sent by the MCU:


standard operation
[14:53:38:095] Read data (COM23)     aa 13 00 18 00 0a 01 36 00 00 03 48 00 00 00 01 01 55 b8 
[14:53:39:122] Read data (COM23)     aa 13 00 18 00 0a 01 36 00 00 03 1d 00 00 00 01 01 55 8d 
[14:53:40:149] Read data (COM23)     aa 13 00 18 00 0a 01 36 00 00 02 d5 00 00 00 01 01 55 44 
[14:57:21:570] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 
[14:57:22:595] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 
[14:57:23:619] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 
[15:00:41:652] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 
[15:00:42:689] Read data (COM23)     aa 13 15 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 6a 
[15:00:43:699] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 
[15:00:45:755] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 
[15:00:46:792] Read data (COM23)     aa 13 15 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 6a 
[15:00:47:808] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 
[15:04:12:111] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 
[15:04:13:147] Read data (COM23)     aa 13 15 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 6a 
[15:04:14:163] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 
test
[18:13:36:478] Read data (COM23)     aa 13 15 1b 00 0a 01 36 00 03 00 13 4b 97 00 01 01 55 7d 
[18:13:37:495] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 03 00 14 4b 97 00 01 01 55 7d 
[18:13:38:528] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 03 00 15 4b 97 00 01 01 55 7e 
[18:13:39:558] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 04 00 17 4b 97 00 01 01 55 81 
[18:13:40:596] Read data (COM23)     aa 13 15 1b 00 0a 01 36 00 05 00 19 4b 97 00 01 01 55 85 
[18:13:41:614] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 04 00 16 4b 97 00 01 01 55 80 
[18:13:42:641] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 04 00 16 4b 97 00 01 01 55 80 
[18:13:43:670] Read data (COM23)     aa 13 14 1b 00 0a 01 36 00 04 00 16 4b 97 00 01 01 55 80 
[18:13:44:708] Read data (COM23)     aa 13 15 1b 00 0a 01 36 00 04 00 16 4b 97 00 01 01 55 81

.

TuyaMCU only sends back:


55 07 03 01 00 00 60

.

edit1:
from the last log, there is a CO value on the place 10 string.

[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[1] = AA
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[2] = 13
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[3] = 14
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[4] = 1B
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[5] = 0
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[6] = A
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[7] = 1
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[8] = 5
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[9] = 0
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[10] = A8
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[11] = 39
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[12] = 41
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[13] = 0
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[14] = 88
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[15] = 1C
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[16] = 41
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[17] = 0
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[18] = 88
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[19] = 39
[01-01 18:12:20 TUYA Debug][lr:0x5ae59] g_hw_config.co_info.co_value = 168
[01-01 18:12:20 TUYA Debug][lr:0x5ae65] g_hw_config.co_info.fault_value = 0

.
recieve_uart_data[10] = 0xA8 = 168 .


[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[1] = AA
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[2] = 13
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[3] = 14
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[4] = 1B
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[5] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[6] = A
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[7] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[8] = 36
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[9] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[10] = 3
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[11] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[12] = 15
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[13] = 4B
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[14] = 97
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[15] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[16] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[17] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[18] = 55
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[19] = 7E
[01-01 01:00:05 TUYA Debug][lr:0x5ae59] g_hw_config.co_info.co_value = 3
[01-01 01:00:05 TUYA Debug][lr:0x5ae65] g_hw_config.co_info.fault_value = 0

.
g_hw_config.co_info.co_value = 0x03 = 3

edit2:
I have added my images, with the soldered TuyaMCU, so that you can trace the paths plus my findings.

edit3:
I pressed test 3x in a row and watched the outputs. You can see that the UART to TuyaMCU is sending messages 6 times. This is only reported once in the log, and presumably an average is calculated from this.


first test press
                                 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 CR
[22:13:55:004] Read data (COM23) aa 13 15 1b 00 0a 01 36 00 00 00 0a 4a 97 00 01 01 55 70        
[22:13:56:022] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 0a 4a 97 00 01 01 55 6f        
[22:13:57:054] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 0b 4a 97 00 01 01 55 70        
[22:13:58:084] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 0d 4a 97 00 01 01 55 72        
[22:13:59:122] Read data (COM23) aa 13 15 1b 00 0a 01 36 00 00 00 0e 4a 97 00 01 01 55 74        
[22:14:00:141] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 0d 4a 97 00 01 01 55 72        
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[1] = AA
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[2] = 13
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[3] = 14
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[4] = 1B
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[5] = 0
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[6] = A
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[7] = 1
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[8] = 5
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[9] = 0
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[10] = A8
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[11] = 39
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[12] = 41
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[13] = 0
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[14] = 88
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[15] = 1C
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[16] = 41
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[17] = 0
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[18] = 88
[01-01 18:12:20 TUYA Debug][lr:0x5ae3b] recieve_uart_data[19] = 39
[01-01 18:12:20 TUYA Debug][lr:0x5ae59] g_hw_config.co_info.co_value = 168
[01-01 18:12:20 TUYA Debug][lr:0x5ae65] g_hw_config.co_info.fault_value = 0

second test press
                                 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 CR
[22:15:43:341] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 03 4f 99 00 01 01 55 6f        
[22:15:44:368] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 03 4f 99 00 01 01 55 6f        
[22:15:45:399] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 03 4f 99 00 01 01 55 6f        
[22:15:48:485] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 03 4f 99 00 01 01 55 6f        
[22:15:49:512] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 03 4f 99 00 01 01 55 6f        
[22:15:50:550] Read data (COM23) aa 13 15 1b 00 0a 01 36 00 00 00 03 4f 99 00 01 01 55 70        
[01-01 01:00:04 TUYA Debug][lr:0x5ae3b] recieve_uart_data[1] = AA
[01-01 01:00:04 TUYA Debug][lr:0x5ae3b] recieve_uart_data[2] = 13
[01-01 01:00:04 TUYA Debug][lr:0x5ae3b] recieve_uart_data[3] = 14
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[4] = 1B
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[5] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[6] = A
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[7] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[8] = 36
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[9] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[10] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[11] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[12] = 3
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[13] = 4B
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[14] = 97
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[15] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[16] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[17] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[18] = 55
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[19] = 69
[01-01 01:00:05 TUYA Debug][lr:0x5ae59] g_hw_config.co_info.co_value = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae65] g_hw_config.co_info.fault_value = 0

third test press
                                 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 CR
[22:16:31:825] Read data (COM23) aa 13 15 1b 00 0a 01 36 00 00 00 03 50 98 00 01 01 55 70        
[22:16:32:845] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 03 50 98 00 01 01 55 6f        
[22:16:33:876] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 03 50 98 00 01 01 55 6f        
[22:16:34:906] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 03 50 98 00 01 01 55 6f        
[22:16:35:946] Read data (COM23) aa 13 15 1b 00 0a 01 36 00 00 00 03 50 98 00 01 01 55 70        
[22:16:36:966] Read data (COM23) aa 13 14 1b 00 0a 01 36 00 00 00 03 50 98 00 01 01 55 6f 
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[1] = AA
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[2] = 13
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[3] = 14
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[4] = 1B
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[5] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[6] = A
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[7] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[8] = 36
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[9] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[10] = 3
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[11] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[12] = 15
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[13] = 4B
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[14] = 97
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[15] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[16] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[17] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[18] = 55
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[19] = 7E
[01-01 01:00:05 TUYA Debug][lr:0x5ae59] g_hw_config.co_info.co_value = 3
[01-01 01:00:05 TUYA Debug][lr:0x5ae65] g_hw_config.co_info.fault_value = 0

.

Samezrp1 · Accepted Answer

Cd of exploration.

1. I disassembled the circuit and sent my commands instead of MCU messages:

.

2. I sent the same wo messages, in (almost) the same order, the change was due to the different behaviour of the application on the same commands.
I started by resetting the device and playing around after the reboot:

yesterday's results

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 CR
aa 13 14 1b 00 0a 01 36 00 01 01 03 4b 97 00 01 01 55 6B alarm 168
aa 13 14 1b 00 0a 01 36 00 20 01 03 4b 97 00 01 01 55 6A alarm 168
aa 13 14 1b 00 0a 01 38 00 20 01 03 4b 97 00 01 01 55 6A normal 32
aa 13 14 1b 00 0a 01 39 00 21 01 03 4b 97 00 01 01 55 8E normal 33
aa 13 14 1b 00 0a 01 50 00 21 01 03 4b 97 00 01 01 55 A5 no change
aa 13 14 1b 00 0a 01 36 01 21 01 03 4b 97 00 01 01 55 8C alarm 289
aa 13 14 1b 00 0a 01 36 01 21 00 03 4b 97 00 01 01 55 8B alarm 168
aa 13 14 1b 00 0a 01 36 01 23 00 03 4b 97 00 01 01 55 8D alarm 168
aa 13 14 1b 00 0a 01 36 01 23 01 03 4b 97 01 01 01 55 8F alarm 168
aa 13 14 1b 00 0a 01 36 01 23 01 03 4b 97 00 01 01 55 8E alarm 168
aa 13 14 1b 00 0a 01 37 01 23 01 03 4b 97 00 01 01 55 8F alarm 291
aa 13 14 1b 00 0a 01 38 01 23 00 03 4b 97 01 01 01 55 90 ponowne wysłanie stan 168 - tak jak test
aa 13 14 1b 00 0a 01 39 01 23 00 03 4b 97 01 01 01 55 91 uaktualnia 291
aa 13 14 1b 01 0a 01 40 01 23 00 03 4b 97 01 01 01 55 99 uaktualnia 291
aa 13 14 1b 00 0a 01 41 01 24 00 03 4b 97 00 00 00 55 99 uaktualnia 292
aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 reset to normal
aa 13 14 1b 01 0a 01 37 00 00 00 03 4b 97 01 00 00 55 6A no change
aa 13 14 1b 11 0a 11 37 00 00 00 03 4b 97 11 11 11 55 BC alarm 168
aa 13 14 20 00 0a 01 36 00 00 00 03 4b 97 00 01 01 20 39 tylko powiadomienie alarm 168 fault
aa 13 14 20 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 6E no change
aa 13 15 20 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 6F device fault
aa 13 15 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 6a normal, 0 ppm

today's:

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 CR
aa 13 14 1b 00 0a 01 36 00 01 01 03 4b 97 00 01 01 55 6B normal 1 ppm
aa 13 14 1b 00 0a 01 36 00 20 01 03 4b 97 00 01 01 55 6A normal 32 ppm
aa 13 14 1b 00 0a 01 38 00 20 01 03 4b 97 00 01 01 55 6A alarm 168 ppm
aa 13 14 1b 00 0a 01 39 00 21 01 03 4b 97 00 01 01 55 8E normal 33 ppm
aa 13 14 1b 00 0a 01 50 00 21 01 03 4b 97 00 01 01 55 A5 no change
aa 13 14 1b 00 0a 01 36 01 21 01 03 4b 97 00 01 01 55 8C alarm 168 ppm
aa 13 14 1b 00 0a 01 36 01 21 00 03 4b 97 00 01 01 55 8B alarm 168 ppm
aa 13 14 1b 00 0a 01 36 01 23 00 03 4b 97 00 01 01 55 8D alarm 289 ppm
aa 13 14 1b 00 0a 01 36 01 23 01 03 4b 97 01 01 01 55 8F alarm 168 ppm
aa 13 14 1b 00 0a 01 36 01 23 01 03 4b 97 00 01 01 55 8E alarm 168 ppm
aa 13 14 1b 00 0a 01 37 01 23 01 03 4b 97 00 01 01 55 8F alarm 291 ppm
aa 13 14 1b 00 0a 01 38 01 23 00 03 4b 97 01 01 01 55 90 ponowne wysłanie stan 168 - tak jak test
aa 13 14 1b 00 0a 01 39 01 23 00 03 4b 97 01 01 01 55 91 uaktualnia 291 ppm
aa 13 14 1b 01 0a 01 40 01 23 00 03 4b 97 01 01 01 55 99 uaktualnia 291 ppm
aa 13 14 1b 00 0a 01 41 01 24 00 03 4b 97 00 00 00 55 97 uaktualnia 292 ppm
aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 reset to normal
aa 13 14 1b 01 0a 01 37 00 00 00 03 4b 97 01 00 00 55 6A no change
aa 13 14 1b 11 0a 11 37 00 00 00 03 4b 97 11 11 11 55 BC alarm 168 ppm
aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69 nadal alarm 168 ppm
aa 13 15 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 70 normal 0 ppm
aa 13 14 20 00 0a 01 36 00 00 00 03 4b 97 00 01 01 20 39 fault/alarm
aa 13 14 20 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 6E fault/normal
aa 13 15 20 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 6F fault/alarm 168 ppm
aa 13 15 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 6a alarm 168 ppm
aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69

.

from the correlations noted:
- CO value in ppm is sent on bytes 09 and 10, int16;
-in order for the system to notice the change after the value has been updated, byte 08 must be changed (must be a different value than the previous one);
-generally byte 11 is responsible for triggering the alarm, but looking at command no. 6 from yesterday after triggering the alarm 11=0x01 and sending a different value on bytes 09 and 10 and setting byte 11 to 00 does not cancel the alarm, but only updates the CO value, but only if bit 08 is changed;
-in lines 18-20 you can see that if byte 03 is not changed (from 14 to 15 or vice versa), the system does not return to the normal state;
-Byte 04 is responsible for fault, 1b is normal, I changed it to 20 to give fault;

Logs from today with commands also in xls file.
You can see from it that in the alarm state the system is put to sleep for 180 seconds and reports an alarm every 3 minutes.
You can also see that there are commands appearing from somewhere that I definitely did not send. Very strange. It doesn't look like interference. I'm talking values in red in Sheet7. In such cases, regardless of the data I send, TuyaMCU sends as CO value 168ppm.

[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[10] = A8

.
The same one that is sent when pressing Test. At the same time, in my case pressing this button does nothing, because the Tx from the MCU is disconnected.

The way the system works is that after starting the system, passing the countdown, the system enters sleep mode for 28800 seconds.

Normal conditions: .
Rises after 28800 sec
Forces a report with the command:

55 07 03 01 00 00 60

.
repeated 3 times,
goes to sleep for another 28800 sec.

Alarm state: .
the system is woken up by the MCU via P26
here I am not sure if getting up forces a report or if the MCU itself sends a report
goes to rest for 180 seconds
and so on and so forth until an alarm condition exists

Reset/test .
Pressing reset wakes up TuyaMCU
waking up forces a report
for test additionally MCU performs test procedure (as after power-on, without countdown)

If you have ideas on what else to test let me know. Remember that it is best to run tests after the boot and standby procedure, which (it looks like) is done by a series of commands:

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 CR
aa 13 00 18 00 0a 01 36 00 00 03 48 00 00 00 01 01 55 b8
aa 13 00 18 00 0a 01 36 00 00 03 1d 00 00 00 01 01 55 8d
aa 13 00 18 00 0a 01 36 00 00 02 d5 00 00 00 01 01 55 44
aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69
aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69
aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69
aa 13 14 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 69
aa 13 15 1b 00 0a 01 36 00 00 00 03 4b 97 00 01 01 55 6a

.

the last two lines I am not sure of. With that said, I've actually been writing all along about how the Tuya application interprets the commands sent, de facto as we know which bytes correspond to fault and CO != 0 this should be enough to run the device without the cloud, the battery status is monitored and reported by the CBU.

DeDaMrAz · Answer

Create autoexec.bat file in webapp Filesystem tab.

startDriver TuyaMCU
//try with 9600 first if it doesn't work try 115200
tuyaMcu_setBaudRate 9600
tuyaMcu_defWiFiState 4

then go to webapp logging and send command - tuyaMcu_sendQueryState

monitor the output so we can maybe grab dpID's and try to figure something out.

sofaking · Answer

thanks for the quick reply. i only get the following log output when i do that (tried both baudrates with the same result)


ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 0, product_information_valid=0, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=0
ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 0, product_information_valid=0, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=0
ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 0, product_information_valid=0, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=0

also tried the config extract method from here but this only outputs the following json


{
   "abi":"0",
   "id":"null",
   "swv":"1.0.2",
   "bv":"40.00",
   "pv":"2.2",
   "lpv":"3.4",
   "pk":"uade6fhqmx2hbyna",
   "firmk":"null",
   "cadv":"1.0.3",
   "cdv":"1.0.0",
   "dev_swv":"1.0.2",
   "s_id":"null",
   "dtp":"0",
   "sync":"0",
   "attr_num":"0",
   "mst_tp_0":"0",
   "mst_ver_0":"null",
   "mst_tp_1":"0",
   "mst_ver_1":"null",
   "mst_tp_2":"0",
   "mst_ver_2":"null",
   "mst_tp_3":"0",
   "mst_ver_3":"null "
}

does this mean that it might not be a tuya mcu device?

DeDaMrAz · Answer

Your boot log lead me to believe it is a TuyaMCU device and so do the pictures but I can't clearly see where UART traces lead ( I thought it want to whatever that chip is). I am confused but form your log we can see some pin setup Code: text Expand Select all Copy to clipboard[01-01 18:12:16 TUYA Debug][lr:0x586b5] ##########firmware config########## [01-01 18:12:16 TUYA Debug][lr:0x586bd] hw_table->json_verson is:1.0.0CBU [01-01 18:12:16 TUYA Debug][lr:0x586c5] hw_table->module is:CBU [01-01 18:12:16 TUYA Debug][lr:0x586cb] ##########gate config########## [01-01 18:12:16 TUYA Debug][lr:0x586d5] io_driver_type is:0 [01-01 18:12:16 TUYA Debug][lr:0x586dd] io_pin is:26 [01-01 18:12:16 TUYA Debug][lr:0x586e5] gate led_type is:1 [01-01 18:12:16 TUYA Debug][lr:0x586eb] ##########tamper config########## [01-01 18:12:16 TUYA Debug][lr:0x586f5] io_driver_type is:2 [01-01 18:12:16 TUYA Debug][lr:0x586ff] io_pin is:255 [01-01 18:12:16 TUYA Debug][lr:0x5870b] tamper led_type is:1 [01-01 18:12:16 TUYA Debug][lr:0x58711] ##########key config########## [01-01 18:12:16 TUYA Debug][lr:0x5871b] key_driver_type is:0 [01-01 18:12:16 TUYA Debug][lr:0x58725] button.port is:24 [01-01 18:12:16 TUYA Debug][lr:0x5872d] key_press_time is:3 [01-01 18:12:16 TUYA Debug][lr:0x58733] ##########led config########## [01-01 18:12:16 TUYA Debug][lr:0x5873b] wifi_led io_driver_type is:1 [01-01 18:12:16 TUYA Debug][lr:0x58743] wifi_led io_pin is:17 [01-01 18:12:16 TUYA Debug][lr:0x5874d] wifi_led.led_type is:0 [01-01 18:12:16 TUYA Debug][lr:0x58755] status_led io_driver_type is:1 [01-01 18:12:16 TUYA Debug][lr:0x5875f] status_led io_pin is:6 [01-01 18:12:16 TUYA Debug][lr:0x58765] ##########adc config########## [01-01 18:12:16 TUYA Debug][lr:0x58771] adc_io is:20 [01-01 18:12:16 TUYA Debug][lr:0x5877d] samp_type is:1 [01-01 18:12:16 TUYA Debug][lr:0x58785] max_voltage is:6130 [01-01 18:12:16 TUYA Debug][lr:0x5878d] min_voltage is:5435 But there is also some UART traffic in there... Code: text Expand Select all Copy to clipboard[01-01 18:12:20 TUYA Notice][lr:0x5aa35] wifi_status:0 [01-01 18:12:20 TUYA Debug][lr:0x5accd] set_sleep_time wf_stat:1,stat:0 [01-01 18:12:20 TUYA Debug][lr:0xb3053] wifi netstat changed to:0

sofaking · Answer

I will try to make some better pictures tomorrow. I can also check the traces with the multimeter but as far as I can remember I did a little probing on the board today and the CBU RX2/TX2 pins are connected to the chip on the bottom right on the picture.

DeDaMrAz · Answer

I managed to order one of these to play around with, if nothing happens before when it arrives I will update you on the setup.

divadiow · Answer

Hi. I bought one a few months ago but never got round to looking at it.

That 48 pin chip is a Holtek BA45F6746

Log in, to see the code

https://www.holtek.com/page/vg/BA45F6746

in this device, in part, to drive the LCD on the front one assumes.

The fw version, 1.0.2, is not patched. A cloudcutter profile was added in April for it.

Added after 3 [minutes]:

looks like you got the battery-only version like me. Mine has a white rubber stopper where the USB connector would have gone.

Added after 1 [hours] 3 [minutes]:

divadiow · Answer

ha. should have checked underneath first re test pads

sofaking · Answer

when I press the test button (center front of the device) I get this output in the log


Info:TuyaMCU:Consumed 121 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 F8 00 FE 00 FE 00 FE 00 FE 00 00 F8 00 00 00 E0 00 00 00 E0 00 FE 00 00 00 E0 00 FE 00 FE 00 00 00 E0 00 00 00 00 00 00 00 00 00 00 80 00 FE 00 00 00 00 00 00 00 FE 00 00 00 00 00 00 00 00 F8 00 00 F8 00 FE 00 00 F8 00 00 00 00 00 00 00 00 00 00 80
Info:TuyaMCU:Consumed 62 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 FE 00 FE 00 FE 00 00 F8 00 00 F8 00 00 00 00 00 00 00 00 00 00 80 00 FE 00 00 00 00 00 00 00 00 F8 00 FE 00 00 00 00 00 00 00 00 F8 00 FE 00 FE 00 FE 00 FE 00 FE 00 FE 00 00 F8 00 FE 
ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 0, product_information_valid=0, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=0
Info:TuyaMCU:Consumed 183 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 F8 00 FE 00 FE 00 FE 00 FE 00 00 F8 00 00 00 E0 00 00 00 E0 00 FE 00 00 00 E0 00 FE 00 FE 00 00 00 E0 00 00 00 00 00 00 00 00 00 00 80 00 FE 00 00 00 00 00 00 00 FE 00 00 00 00 00 00 00 00 F8 00 00 F8 00 FE 00 00 F8 00 00 00 00 00 00 00 00 00 00 80

i also probed the connections now.

BA45F6746 PIN19 is connected to TX1 on the CBU
BA45F6746 PIN20 is connected to RX1 on the CBU

sofaking · Answer

i flashed back the stock firmware to check the DPids using this guide and got the following values


{
    "1": "Co State",
    "2": "Co Value",
    "11": "Fault",
    "15": "Battery Percentage"
}


co_status	Enum	
{
    "range": [
        "normal",
        "alarm"
    ]
}
co_value	Integer	
{
    "unit": "ppm",
    "min": 0,
    "max": 1000,
    "scale": 0,
    "step": 1
}
battery_percentage	Integer	
{
    "unit": "%",
    "min": 0,
    "max": 100,
    "scale": 0,
    "step": 1
}

piotrszulc1 · Answer

I've got this detector some time ago and I don't think it's tuya-mcu. The detection and the LCD are handled by a separate chip (probably the already mentioned Holtek) and only the following information is available to the CBU (at least that's what I found out so far):
P24 (inverted + pullup) - Button (the "pin button" at the side, not the big one in the front)
P26 (inverted) - Fire alarm active
P6 - status LED (only the blue one)
P20 - battery relay
P23 - battery ADC

The remaining two LEDs are and the big button in front are handled by Holtek.
I tested it a bit as follows:
- Holding the big front button activates the test alarm (blinking red LED and sound) and sets P26 (low)
- Burning a piece of paper under the detector makes it show some numbers on the LCD going up. Once they go above a threshold (I think it was 120 - what unit is this?), the alarm scenario activates (same as above) and does not deactivate until the values go back down below another threshold.

In esphome I was able to set up deep sleep on CBU to wakeup on P24 and P26 (button or fire).

divadiow · Answer

>>21267322

thank you for adding your findings

Added after 8 [minutes]:

>>21267187

just to echo this. here is the storage area info before pairing to Tuya app

Log in, to see the code

Added after 6 [minutes]:

and then after when config has been pulled to device. I had to attach as txt file because the site would not submit it as post text.

divadiow · Answer

indeed. TuyaMCU devices usually (always?) have a different MCU version number to the Main Module version in the app when paired. No TuyaMCU = same version listed for both. Added after 1 [minutes]:the question is, is the MCU talking to the CBU over RX/TX at all? Added after 6 [minutes]:certainly no TuyaMCU analyser hits

piotrszulc1 · Answer

Hmm if this is available via tuya API, then it must also be possible to get this value on CBU: Maybe there actually is a UART connection with Holtek?

divadiow · Answer

OK sure. yes. I have a logic analyser but haven't really mastered its use yet.

sofaking · Answer

i've had a few more test runs with the original firmware. the following communication seems to happen on boot/reset when i sniff on the rx/tx lines of the cbu

This is sent from the CBU to the MCU


00000000 01010101 00000111 00000011 00000001 00000000 00000000 01100000 01010101 00000111 00000011 00000001 00000000 00000000 01100000 01010101 00000111 00000011 00000001 00000000 00000000 01100000

or in hex


0 55 7 3 1 0 0 60 55 7 3 1 0 0 60 55 7 3 1 0 0 60

not sure what this does though maybe some init for the MCU to trigger the UART sends or is it something CBU specific (for flashing etc?)

when i press the test button on the front this data is sent from the MCU to the CBU


10101010 00010011 00010100 00011011 00000000 00000111 00000001 00110110 00000000 00000000 00000000 00000011 01010000 10010000 00000000 00000001 00000001 01010101 01100100
10101010 00010011 00010100 00011011 00000000 00000111 00000001 00110110 00000000 00000000 00000000 00000011 01010000 10010000 00000000 00000001 00000001 01010101 01100100
10101010 00010011 00010100 00011011 00000000 00000111 00000001 00110110 00000000 00000000 00000000 00000011 01010000 10010000 00000000 00000001 00000001 01010101 01100100
10101010 00010011 00010101 00011011 00000000 00000111 00000001 00110110 00000000 00000000 00000000 00000011 01010000 10010000 00000000 00000001 00000001 01010101 01100101

or in hex


AA 13 14 1B 0 7 1 36 0 0 0 3 50 90 0 1 1 55 64
AA 13 14 1B 0 7 1 36 0 0 0 3 50 90 0 1 1 55 64
AA 13 14 1B 0 7 1 36 0 0 0 3 50 90 0 1 1 55 64
AA 13 15 1B 0 7 1 36 0 0 0 3 50 90 0 1 1 55 65

now i also tested what happens when the CO value is not zero (don't ask me how i did it but it involved a plastic cup, a straw and cigarette smoke

). The uart part of the log looks like this with CO levels on 0


[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[1] = AA
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[2] = 13
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[3] = 14
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[4] = 1B
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[5] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[6] = 7
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[7] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[8] = 36
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[9] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[10] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[11] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[12] = 3
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[13] = 50
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[14] = 91
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[15] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[16] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[17] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[18] = 55
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[19] = 65
[01-01 01:00:05 TUYA Debug][lr:0x5ae59] g_hw_config.co_info.co_value = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae65] g_hw_config.co_info.fault_value = 0

and this happens when the CO value is higher


[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[1] = AA
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[2] = 13
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[3] = 14
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[4] = 5B
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[5] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[6] = 7
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[7] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[8] = 36
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[9] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[10] = 55
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[11] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[12] = DB
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[13] = 5C
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[14] = 91
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[15] = 0
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[16] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[17] = 1
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[18] = 55
[01-01 01:00:05 TUYA Debug][lr:0x5ae3b] recieve_uart_data[19] = DE
[01-01 01:00:05 TUYA Debug][lr:0x5ae59] g_hw_config.co_info.co_value = 85
[01-01 01:00:05 TUYA Debug][lr:0x5ae65] g_hw_config.co_info.fault_value = 0

this led me to believe that the CO value is set in uart data index 10 (55 hex = 85 dec)

also i saw that the tuya smartlife app won't report the CO value, I think unless the alarm limit is reached (not sure what that value is but certainly nothing you could trigger with a cigarette i guess). the only way i could get the original firmware to read out the co value was to reset the device. probably only the alarm will trigger the sleep timer to wake the device for a UART readout.

Added after 56 [minutes]:

so i'm back on OpenBeken after this debugging session and had success with doing the following

1) added autoexec.bat with the following content (not sure if the uartSendHex is needed at this point)


uartInit 9600
uartSendHex 00 55 07 03 01 00 00 60 55 07 03 01 00 00 60 55 07 03 01 00 00 60

2) went to log and sent the following command again


uartSendHex 00 55 07 03 01 00 00 60 55 07 03 01 00 00 60 55 07 03 01 00 00 60

then this happens on the OpenBeken log


Debug:CMD:cmd [uartSendHex 00 55 07 03 01 00 00 60 55 07 03 01 00 00 60 55 07 03 01 00 00 60]
Info:CMD:[WebApp Cmd 'uartSendHex 00 55 07 03 01 00 00 60 55 07 03 01 00 00 60 55 07 03 01 00 00 60' Result] OK
Info:CMD:UART received:
Info:CMD:UART received: AA 13 14 1B 00 07 01 36 00 00 00 04 5D 92 00 01 01 55 74
Info:MAIN:Time 361, idle 184173/s, free 74792, MQTT 0(22), bWifi 1, secondsWithNoPing 291, socks 2/38
Info:CMD:UART received: AA 13 14 1B 00 07 01 36 00 00 00 04 5D 92 00 01 01 55 74
Info:MAIN:Time 362, idle 188786/s, free 74792, MQTT 0(22), bWifi 1, secondsWithNoPing 292, socks 2/38
Info:CMD:UART received: AA 13 15 1B 00 07 01 36 00 00 00 04 5C 92 00 01 01 55 74
Info:MAIN:Time 363, idle 182937/s, free 74792, MQTT 0(22), bWifi 1, secondsWithNoPing 293, socks 2/38

so this seems to be the command to read out the current CO value *yay*.

also when the test button is pressed i get


Info:CMD:UART received: AA 13 14 1B 00 07 01 36 00 00 00 04 5D 92 00 01 01 55 74
Info:CMD:UART received: AA 13 15 1B 00 07 01 36 00 00 00 04 5D 92 00 01 01 55 75

piotrszulc1 · Answer

@sofaking that's a very interesting find, thanks! I have found that Holtek actually offers a reference design and it comes with an example implementation. This code actually sends a bunch of values via uart and the content starts with 0xAA: I wonder if Tuya implementation is based on this code :) Added after 36 [minutes]:The last byte in @sofaking's data sets really seems to be a checksum, calculated exactly the same as it is in the reference design code, ie.: Add up all preceding bytes and get the lowest byte of the sum.

divadiow · Answer

The SWS pad is interesting. SWS labelled pads I thought were for Telink Single Wire Slave protocol communications. It traces to RX2 on the CBU.

piotrszulc1 · Answer

So I've noticed that this: Is just the same command sent 3 times (checksum 60 matches) and all is preceded with a single 0. Also I have found that this: holds the current temperature. I yet don't know how exactly it is encoded, but I experimented a bit with high (heater) and low (outside) temperatures and I've noticed it changes consistently. The lowest value I observed so far was 0x90 (chilly), the highest was 0xA2 (hot to the hand). Now I've put it into the freezer (-17 C), we'll see how low it can go Btw. I've build an esphome-based setup for testing, if anyone is interested - here it is: Code: text Expand Select all Copy to clipboard uart:   - id: holtek_uart     rx_pin: RX1     tx_pin: TX1     baud_rate: 9600     debug:       direction: BOTH       dummy_receiver: true       sequence:         - lambda: UARTDebug::log_hex(direction, bytes, ' '); button:   - platform: template     id: holtek_trigger     name: Trigger Holtek     on_press:       then:         - lambda: |-             std::vector data_to_write = {0x00, 0x55,                                                   id(byte_1).state,                                                   id(byte_2).state,                                                   id(byte_3).state,                                                   id(byte_4).state,                                                   id(byte_5).state                                                   };             uint8_t checksum = 0;             for (auto & byte: data_to_write)             {               checksum  = byte;             }             data_to_write.push_back(checksum);             id(holtek_uart).write_array(&data_to_write.front(), data_to_write.size()); number:   - platform: template     id: byte_1     name: Byte 1     optimistic: true     min_value: 0     max_value: 255     initial_value: 7     step: 1   - platform: template     id: byte_2     name: Byte 2     optimistic: true     min_value: 0     max_value: 255     initial_value: 3     step: 1   - platform: template     id: byte_3     name: Byte 3     optimistic: true     min_value: 0     max_value: 255     initial_value: 1     step: 1   - platform: template     id: byte_4     name: Byte 4     optimistic: true     min_value: 0     max_value: 255     initial_value: 0     step: 1   - platform: template     id: byte_5     name: Byte 5     optimistic: true     min_value: 0     max_value: 255     initial_value: 0     step: 1 Pressing the Trigger holtek button sends the following values to the Holtek chip: [00 55 Byte1 Byte2 Byte3 Byte4 Byte5 Checksum] I've noticed it sometimes takes a few retries for the chip to answer (maybe it sleeps?). And so far I was not able to make the chip answer to anything but exactly the bytes that @sofaking discovered (bytes 7 3 1 0 0) Added after 3 [minutes]: Oh, an I believe the temperature is actually the internal temperatre of the chip itself, because there was a significant time delay (up to a minute?) in reaction: the ambient temperature was already at room temperature, but the values reported via uart were still getting up. Added after 36 [minutes]: Unfortunately, after visiting the freezer, the device went into fault state for a while (. When it finally recovered, the value reported on byte 14 was initially 0, then 8A and going higher up to 91 (room temperature, ca. 23 degrees celsius). Some more observations: The device chip sends always exactly 3 separate responses, and usually it coincides with the fire alarm pin (P26) to go low. The second response has also always the same (lowest) bit of the 3rd byte toggle: high->low->high: Code: text Expand Select all Copy to clipboard 19:32:54 [D] 'Trigger Holtek' Pressed. 19:32:55 [D] >>> 00 55 07 03 01 00 00 60 19:32:55 [D] 'Fire': Sending state ON 19:32:56 [D]

[BK7231N] Configuring Tuya CO400A-A004 (Carbon Monoxide Detector) with (OpenBeken)

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Topic summary