Motion sensor with BK7231N and TuyaMCU battery powered devices protocol

This is not what I expected. It turns out that I communicate with the TuyaMCU chip without the need to power the board.
The connections are:
Tx --> Tx
Rx --> Rx
GND --> GND
CEN --> GND

It is actually normal. This is because MCU GPIO has clamping diodes to VDD and GND and the voltage drop on diode gives still enough voltage left to power MCU.
See:

Source: https://www.youtube.com/watch?v=2yFh7Vv0Paw&ab_channel=EEVblog

Regarding the motions sensor TuyaMCU - I have a little problem with getting full grasp on the issue, because earlier I've read something like "TuyaMCU still sends data with no tmSensor" and now you are saying that it doesn't send....

Are you using Google Translate?

Quote:

That is, MCU sends: AA 00 05 00 05 01 04 00 01 01 10 55 and BKN confirms with: AA 00 08 00 00 07 55. Wouldn't you have to answer?: AA 00 05 00 00 04 55.

I don't know, but you might be correct here. I will try to fix that in code soon.

As far as I know, there are two ways that sensors can report data.
- they can report it with timestamp:

- or they can report without time:

Source: https://developer.tuya.com/en/docs/iot/tuyacl...niversalserialaccessprotocol?id=K95afs9h4tjjh

So you are most likely correct that we have invalid reply for that packet. Let me fix it and we will try again.

You may drag the bug as a result of this modification on the fly.

------------------------------------
p.kaczmarek2
Moderador Hogar inteligente  
¿Publicación útil? ( 0 )
#20 06 dic 2022 09:07
Si esto:
https://www.elektroda.com/rtvforum/topic3937723.html#gallery-29
Sensor de movimiento con BK7231N
no estaba analizando 0x05 en absoluto antes.
------------------------------------

Added after 15 [minutes]:

Regarding the motions sensor TuyaMCU - I have a little problem with getting full grasp on the issue, because earlier I've read something like "TuyaMCU still sends data with no tmSensor" and now you are saying that it doesn't send....

Are you using Google Translate?

Yes, I agree that the language barrier is an issue despite Google translate. I am from Spain.

Summarizing:
The pir motion works fine with tmSensor driver loaded. Everything perfect, except that it does not activate BK7321N long enough to appear Log on the web or send via MQTT to HA.

Greetings

I think it may be possible that our system sends wrong 55 AA 00 08 00 00 07 packets which confuse TuyaMCU, because they should be send only in non-battery powered devices.

spin55 wrote:

Tx:


55 AA 00 00 00 00 FF
55 AA 00 01 00 00 00
55 AA 00 02 00 00 01
55 AA 00 01 00 00 00
55 AA 00 08 00 00 07
55 AA 00 00 00 00 FF
55 AA 00 08 00 00 07
55 AA 00 02 00 01 04 06
55 AA 00 03 00 01 00 03
55 AA 00 08 00 00 07
55 AA 00 00 00 00 FF
55 AA 00 08 00 00 07

Rx:

55 AA 00 00 00 01 00 00
55 AA 00 01 00 24 7B 22 70 22 3A 22 6C 79 64 77 6F 62 77 79 71 78 69 79 6F
62 39 68 22 2C 22 76 22 3A 22 31 2E 30 2E 35 22 7D 62
55 AA 00 02 00 00 01
55 AA 00 00 00 01 00 00
55 AA 00 02 00 00 01
55 AA 00 05 00 05 01 04 00 01 01 10
55 AA 00 05 00 08 04 02 00 04 00 00 00 64 7A
55 AA 00 00 00 01 00 00

If you enable extra debug log, what do you get in UART log?

Do you get:

?

Are you referring to this?



Added after 22 [minutes]:

This confirms that the communication with HA is correct, but because I force it to go into AP mode to start and maintain the connection:

Yes, this, but also use console command to set log level.

@spin55 big thanks for figuring this out, it might be a issue.

There was an incorrect packet being sent, but not as the reply, but because the non-tmSensor mechanism was running in the background.

I pushed a fix, can you wait 15 minutes for build and try it out?

NOTE: it still may not be a complete fix, but it's a step forward.....

p.kaczmarek2 wrote:

I pushed a fix, can you wait 15 minutes for build and try it out?

Of course, do it when it suits you.
I thank you for all the help received.

Greetings

The build should be ready now, but I am not sure how much it will help your device.

OpenBK7231N_1.15.654.rbl ??

Or do I have to wait for it to update?

Yes 1.15.654...

Still the same. The Tx channel has changed and no longer receives command 08. And the message from before does not appear in the Log.

Tx:


Rx:


Log:


Added after 8 [minutes]:

spin55 wrote:

Rx:

Please post logs as text... but I retyped and it looks like it's still rebooting quickly? After 10 or so seconds? So WiFi doesn't have time to connect well?
I see it sends dpIDs:

p.kaczmarek2 wrote:

Please post logs as text... but I retyped and it looks like it's still rebooting quickly? After 10 or so seconds? So WiFi doesn't have time to connect well?
I see it sends dpIDs:

Rx:
00FF0055AA00000001000055AA000100247B2270223A226C7964776F627779717869796F623968222C2276223A22312E302E35227D6255AA00000001000055AA000200000155AA0005000501040001011055AA0005000804020004000000647A55AA0000000100000055AA00000001000055AA000100247B2270223A226C7964776F627779717869796F623968222C2276223A22312E302E35227D6255AA00000001000055AA000200000155AA0005000501040001000F55AA0000000100000055AA00000001000055AA000100247B2270223A226C7964776F627779717869796F623968222C2276223A22312E302E35227D6255AA00000001000055AA000200000155AA0005000501040001011055AA0000000100000055AA00000001000055AA000100247B2270223A226C7964776F627779717869796F623968222C2276223A22312E302E35227D6255AA00000001000055AA000200000155AA0005000501040001000F55AA000000010000

Tx:
00FF0055AA00000000FF55AA000100000055AA00000000FF55AA00020001040655AA00000000FF0055AA00000000FF55AA000100000055AA00000000FF55AA00020001040655AA00000000FF0055AA00000000FF55AA000100000055AA00000000FF55AA00020001040655AA00000000FF0055AA00000000FF55AA000100000055AA00000000FF55AA00020001040655AA00000000FF

Hello,

Today I received another pir motion. I have paired it with Smart Life App.

Simultaneous capture of both Tx and Rx channels with RealTerm:



Canal Tx:
55 AA 00 01 00 00 00 (Query product information)

55 AA 00 02 00 01 03 05 (Report the network status) (Wi-Fi has been configured, and connected to the router)

55 AA 00 02 00 01 04 06 (Report the network status) (Wi-Fi has been connected to the router and the cloud)

55 AA 00 05 00 01 00 05 (Ack)

55 AA 00 05 00 01 00 05 (Ack)

Canal Rx:
55 AA 00 01 00 24 7B 22 70 22 3A 22 6C 79 64 77 6F 62 77 79 71 78 69 79 6F
62 39 68 22 2C 22 76 22 3A 22 31 2E 30 2E 35 22 7D 62 (Ack)

55 AA 00 02 00 00 01 (Ack)

55 AA 00 02 00 00 01 (Ack)

55 AA 00 05 00 05 01 04 00 01 01 10 (Report the real-time status) (sensor status)

55 AA 00 05 00 08 04 02 00 04 00 00 00 64 7A (Report the real-time status) (battery status)

When it detects motion, the only thing that changes is:
55 AA 00 05 00 05 01 04 00 01 00 0F

There is a reset time of approximately 2 minutes. During this interval it does not detect movement.

At the moment I don't flash it in case some test needs to be done.

Regards
NEO4_T..txt Download (5.65 kB) NEO4_R..txt Download (5.88 kB)

This seems very helpful, I will try to compare it 1:1 with Obk to see what are we missing.

It seems Tuya FIrmware is doing two packets for wifi config? Is that always that way?

Please do 2MB firmware backup.

p.kaczmarek2 wrote:

Please do 2MB firmware backup.

I can't post it because it's paired. I can send it to you privately.

Hmm ok, please do, btw I think it should be possible for you to find your SSID string with XVI32 and just replace each byte with random ASCII letter.

So, what do you think, what is OBK missing in comparison to original firmware?

p.kaczmarek2 wrote:

So, what do you think, what is OBK missing in comparison to original firmware?

Canal Tx:
55 AA 00 01 00 00 00 (Query product information)

55 AA 00 02 00 01 03 05 (Report the network status) (Wi-Fi has been configured, and connected to the router)

55 AA 00 02 00 01 04 06 (Report the network status) (Wi-Fi has been connected to the router and the cloud)

55 AA 00 05 00 01 00 05 (Ack)

55 AA 00 05 00 01 00 05 (Ack)

Canal Rx:
55 AA 00 01 00 24 7B 22 70 22 3A 22 6C 79 64 77 6F 62 77 79 71 78 69 79 6F
62 39 68 22 2C 22 76 22 3A 22 31 2E 30 2E 35 22 7D 62 (Ack)

55 AA 00 02 00 00 01 (Ack)

55 AA 00 02 00 00 01 (Ack)

55 AA 00 05 00 05 01 04 00 01 01 10 (Report the real-time status) (sensor status)

55 AA 00 05 00 08 04 02 00 04 00 00 00 64 7A (Report the real-time status) (battery status)

I'm going to look at xavi32 and I'll tell you.

Added after 13 [minutes]:

p.kaczmarek2 wrote:

Hmm ok, please do, btw I think it should be possible for you to find your SSID string with XVI32 and just replace each byte with random ASCII letter.

I have changed it. I send it to you privately?

Please send. I will try to analyze those packets today or tomorrow and update OBK.

I am doing clocks stuff so far.

sent backup.

p.kaczmarek2 wrote:

I am doing clocks stuff so far.

You're a "machine".
Thanks for everything.

So to sum it up, we have following conclusions:
1. OBK was sending extra data from vanilla TuyaMCU driver, which is now disabled
2. OBK was always sending the same confirmation type, but for 0x08 we have to respond with 0x08 confirmation and for 0x05 with 0x05
3. your device first report "connected to router" and then separately "connected to cloud", while OBK immediately reported "connected to cloud"

I will add this to my tool and then we can check:

Here's how GUI looks:


I am testing on my devices, but I still to seem have problem with one device. Maybe MCU thinks it's not paired. Can you give a packets dump what happens when you press a pair button?

Or maybe I am too slow with clicking....
Here's a successful transaction (I simulated closing of door sensor):

Here, just a moment later, I simulated opening:

The door sensor used for testing:


Here is the second sensor used for testing. Let's simulate closing the door:

It behaves strangely. It done Received: Ver=0, Cmd=ReportRealtimeStatus, Len=5, [dpID=1, type=1, len=1, val=0], CHECKSUM OK and powered off without waiting for me to reply.
But... if I use the automatic mode.... i got it right?

another try:


So the open questions are:
- if the door sensor is already paired and we press the button, how does the button tells WiFI module that we want to re-pair it?
- do we really need to first report wifi state 0x03 and then 0x04, or just only we can report 0x04 and it's all?
- why sometimes my tests with PC fail? is this timing issue?
I need few hours more.

Added after 31 [minutes]:

WAIT, sorry, it seems I solved one more issue! More information soon

Added after 48 [minutes]:

It seems to work now in a stable way. I am attaching my PC tester program. OBK update is still TODO.

Hello,



I just connected pir motion and see this in Realterm. Simultaneous captures of Tx and Rx channels (Tx->Left Rx->Right):



The command 03 that I point to with the arrow appears when I switch it to AP mode following these instructions:

------------------------------------

This is what the manual for the device says:

Main function
Operate status: alarma/ normal (the device can be triggered only once 1 minute)

Device Status-----------------LED State

Smart Wi Fi ------------------Indicator flashes quicly
AP mode ---------------------Indicator flashes slowly
Triggered ---------------------LED will rapidly blink and OFF after scheduled time
Suspend mode ---------------Indicator OFF
Reset --------------------------Indicator lights up for 4s and after 2seconds ligths OFF. Device goes
into configuration mode

How to reset?

(1) Press the reset button for 6 seconds till the indicator flash rapidly. The device turns to Smart Wi-Fi mode.

(2) Press the reset button again for 6 seconds till the indicator flash slowly. The device turns to AP mode.

-------------------------------------

Looks like I'll have to re-pair. I will delete the device from Smart Life and pair it again.

I will try your attachment.

Regards

you are very helpful, thank you, let me check.

spin55 wrote:

How to reset?

(1) Press the reset button for 6 seconds till the indicator flash rapidly. The device turns to Smart Wi-Fi mode.

(2) Press the reset button again for 6 seconds till the indicator flash slowly. The device turns to AP mode.

I only checked short press for button. Let me check long press now. Short press was only waking up device, no pairing.

Added after 1 [hours] 17 [minutes]:

I can confirm that I get 0x03 command on long press:

so this:

means "enter pairing mode"

I couldn't re-pair it to Smart Life with the original firmware, it didn't detect movement or coherent communication between chips, except when I forced it to AP mode, so I did another backup before flashing with OpenBeken. Now it works the same as the other three. With TuyaMCU drivers and tmSensor it works perfectly except wifi.

I think we have enough data to know what happens and why. I will try to update the OpenBeken to mimic our conclusions soon.

p.kaczmarek2 wrote:

I think we have enough data to know what happens and why. I will try to update the OpenBeken to mimic our conclusions soon.

OK.

Hello,

According to the diagram, TuyaMCU keeps the wifi module ON for a minimum of 30 seconds under any circumstances. But I have verified that it does not keep it active for more than 15 seconds. Measuring with a multimeter on the CEN pin of BK7321N and placing a led diode for visual verification.

This time is extended up to 37 seconds if the Wi-Fi module notifies that it is connected to the router and cloud.

Any firmware to try?



Regards

Hello,

Firmware version OpenBK7231N_QIO_1.15.631.bin does not work well. I'm back to 592. And from what I've seen there are very significant differences between versions 03 and 00 of the Tuya protocol.

Command format in version 03:
WiFi module: 55 AA 00 .......
MCU: 55 AA 03 ......

Command format in version 00:
WiFi module: 55 AA 00 .......
MCU: 55 AA 00 ......

What we see in the captures:

WiFi module --> Tx

55 AA 00 00 00 00 FF -> Valid but unnecessary because module Sleeping
55 AA 00 01 00 00 00 -> Ok
55 AA 00 02 00 00 01 -> Version 03
55 AA 00 01 00 00 00 -> Redundant. No need to send it again
55 AA 00 08 00 00 07 -> Version 03
55 AA 00 00 00 00 FF -> Valid but unnecessary
55 AA 00 08 00 00 07 -> Version 03
55 AA 00 02 00 01 04 06 -> Ok
55 AA 00 03 00 01 00 03 -> Version 03
55 AA 00 08 00 00 07 -> Version 03
55 AA 00 00 00 00 FF -> Valid but unnecessary
55 AA 00 08 00 00 07 -> Version 03

It seems that you have started from the commands of version 03 and have adapted them by setting the version to 00 and correcting the checksum, but this does not seem correct because the protocols are different. The same command number does not always do the same in both versions, nor are they sent and received in the same way.

For example, the 08 command of version 03 has a format similar to that of version 00 but in version 03 it is sent by the WiFi module and is asynchronous (it does not need an immediate response), and in version 00 it is sent by the MCU and the reply of the WiFi module is different: 55 AA 00 08 00 01 00 08.

Another example, in version 03 the 03 command sent by the module is:
Report network status: 55 aa 00 03 00 01 04 07
MCU reply: 55 aa 03 03 00 00 05

But in version 00 it is:
Report network status: 55 aa 00 02 00 01 04 06
MCU reply: 55 aa 00 02 00 00 01

If Report network status - MCU reply: 55 aa 03 03 00 00 05 passes it to version 00, it would be: 55 aa 00 03 00 00 02, which is Reset Wi-Fi - MCU send in version 00.

It is a different command. And there are more commands that are also different.

Tx WiFi module: -----------------------Rx WiFi module: