How to make TuyaMCU device send more data points? Why are dpIDs not sent? Processing by the Wi-Fi...

p.kaczmarek2 1791 4

Reply Cool? Ranking DIY | New topic

Notify about new articles

Helpful post? (+4)

Post #1
21322900 27 Nov 2024 21:53

I've recently stumbled upon interesting TuyaMCU device which was not sending all dpIDs despite me setting 0x04 WiFi state in autoexec.bat. Following the communication captured from original firmware also didn't trigger the dpID publish. It wasn't even replying to the TuyaMCU state queries! It has turned out that the reason was totally unexpected, so I've decided to document it here. Hopefully it will help more people to get their device cloud-free.

Basic reading
This topic is an extension to the previous topics covering TuyaMCU protocol, so I will assume here that reader is familiar with the basics:
TuyaMCU protocol - communication between the microcontroller and the WiFi module
TuyaMCU flashing, setup and configuration guide - configure dpIDs for Home Assistant
TuyaMCU analyzer - UART packet decoder for Tuya devices - dpID detector
Extracting DpIDs for TUYA MCU devices
How to get dpID list of types and values for flashed TuyaMCU devices with OpenBeken

Device used for demonstration
The following demonstration is based on Tuya DIN 4P 1-63A which was donated to me by a reader. However, here I will just focus on Raw format from TuyaMCU packets, the full teardown will be posted separately.

The following issue also happens on MGF-T3-SMART, which was also submitted to me by another reader:

Thank you for sending those devices and helping me with such discovery!

Initial communication capture
At first I've decided to use my TuyaMCU analyzer to take a basic communication capture between MCU and the WiFi module:

The first interesting thing here is that the WiFi state packet is not sent at all! This is because this device is using something called Processing by the Wi-Fi module, as indicated by the presence of payload of 0x02 packet (MCUConf).
Quote:

Processing by the Wi-Fi module - the GPIO pins of the Wi-Fi module change status of the Wi-Fi indicator (LED indicator). The Wi-Fi module is reset based on the GPIO inputs.
In processing by the Wi-Fi module mode, the Wi-Fi module triggers a reset when it detects that the GPIO input is at a low level for more than 5s. GPIO pins used by the Wi-Fi indicator and Wi-Fi reset button are configured by using command word 0x02.

The command payload is 0807, which means that P08 is a WiFi LED and also WiFi state output for the MCU, and 07 is the pairing button...
Note: if the 0x02 packet (MCUConf) has no payload, then processing is done by the MCU, and everything works out of the box, no extra pins are required.

First autoexec.bat configuration and many problems
I've flashed the WiFi module with OpenBeken, I've set autoexec.bat with a basic script and tried to get TuyaMCU to send more data, however, all my attempts were failing so far. Heartbeats were received correctly (so UART baud was OK) and I was able to control the main relay and get few readings, but not more than this:
Code: JSON
Log in, to see the code

and I didn't get any futher dpIDs...
I've tried the usual approach, 0x04 WiFi state, but it seems the mentioned device does not use it at all:
Code: text Expand Select all Copy to clipboard
// set TuyaMCU default wifi state 0x04, which means "paired", // because some TuyaMCU MCUs will not report all data // unless they think they are connected to cloud tuyaMcu_defWiFiState 4

neither the query replied with more data:
Code: text Expand Select all Copy to clipboard
// every 10 seconds, request update from TuyaMCU addRepeatingEvent 10 -1 tuyaMcu_sendQueryState

Everything was failing so far, until I decided to try setting the WiFi LED pin...

Simple solution to the problem
It turned out that the already mentioned P08 is not just used for WiFi LED - it has a LED connected, but it also enables sending of more dpIDs. I've tested it with GPIODoctor:

This means that MCU is physically to connected to this pin as well and it's reading this pin state...
So once I've set it's state to AlwaysHigh (or AlwaysLow, depending on the device):
Code: JSON
Log in, to see the code

Now, it looks like we have a full set of data! That's what we needed for the futher processing.

Summary
If your TuyaMCU device is reporting MCUConf packet with non-zero length, the reported byte values are WiFi state and reset button pins. The WiFi state pin is not only just used for LED - it's also used to enable sending futher dpIDs from the MCU. So, in order to get all the values from it, you need to set it to either AlwaysLow or AlwaysHigh in OBK setting. Only that way will work for devices in WiFi processing mode, no "WiFistate 0x04", neither "querying the state" will work here.

I've attached related TuyaMCU doc in PDF format, you can check it out for more details. Interestingly enough, it DOES NOT show that the MCU is also reading the LED state...

So I guess they didn't bother to document well the case I described here.

Attachments:

Guide-to-Interworking-with-the-Tuya-MCU.pdf Download (1.93 MB)

Cool? Ranking DIY
Helpful post? Buy me a coffee.
About Author
p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Offline

Joined: 26 Dec 2014

Posts: 11842

Help: 566

Posts rating: 9935

Points: 113307
p.kaczmarek2 wrote 11842 posts with rating 9935, helped 566 times. Been with us since 2014 year.
ADVERTISEMENT
#2 21322909 27 Nov 2024 22:01

DeDaMrAz DeDaMrAz

Level 19

Helpful post? (0)

Post #2
21322909 27 Nov 2024 22:01

So for such devices tuyaMcu_defWiFiState 4 is not necessary or?

If you like my work, support me at: https://paypal.me/openshwprojects
ADVERTISEMENT
#3 21322921 27 Nov 2024 22:10

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Topic author Helpful post? (+1)

Post #3
21322921 27 Nov 2024 22:10

Very good question! As you can see on the mentioned capture, there is no WiFi state packet at all in WiFi-processing exchange:

Please compare it with other communication dump (WiFi to MCU only):

As you can see, there are two cases:
- if MCUConf (0x02) has no payload, then WiFi state is reported by 0x03 packet
- if MCUConf (0x02) has payload, then payload of MCUConf specified the pins used for WiFi state and reset, and no 0x03 packet is sent

You can find out the same if you check out Tuya docs:

My only problem was that Tuya documentation does not show that MCU is also reading the WiFi state (LED) pin to check if it can send more dpIDs!.
The correct schematic should be:

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
#4 21324901 29 Nov 2024 11:14

Samezrp1 Samezrp1

Level 13
» | Helpful post? (0)

Post #4
21324901 29 Nov 2024 11:14

I am uploading information from this thread .
Problem: the device is not sending data to MQTT, despite being set up:
Code: text Expand Select all Copy to clipboard
tuyaMcu_defWiFiState 4
.
The WiFi connection marker would appear and disappear, the device would establish a WiFi connection from the beginning every 1 minute or so.
The solution was to set the driver to support NTP and the correct time on the device previously added:
Code: text Expand Select all Copy to clipboard
startDriver NTP //ntp_timeZoneOfs 1 //optional tuyaMcu_sendCurTime //wysyła czas z TuyaMCU do MCU, bez tego jak zgubił czas to nie uaktualniał
.
This automatically set the time and stabilised the WiFi connection. A side effect was that the transmission of CB3S-defined channels from TuyaMCU appeared.
#5 21324964 29 Nov 2024 12:08

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Topic author Helpful post? (0)

Post #5
21324964 29 Nov 2024 12:08

So it seems that there are at least 3 methods used by TuyaMCU (non-battery powered version) to check for correct connectivity:
- WiFi state packet (0x04 means connected to cloud and paired)
- GPIO output (if MCUConf length is 2?)
- NTP data (I guess it checks for correct, non 1970? time sent there):

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Create an account, log in and become active in a forum and ads will not appear. You will receive points by participating in discussions.
Join this discussion.

Install the application

Didn't find an answer? Ask Artificial Intelligence

*I agree to send the question to OpenAI, Anthropic PBC, Perplexity AI, Inc., Kagi Inc., Google LLC - owners of language models in order to prepare the best response. The companies may monitor and log information entered into the form.

*I agree to publicly display my question and answer. The question and answer will be publicly available to everyone. The process may take a few minutes. Upon completion, you will be redirected to the page with the answer.

Wait...(2min)