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

p.kaczmarek2 27 Nov 2024 21:53 4 2334 Cool? (+4)

📢 Listen (AI):

TL;DR

Troubleshoots TuyaMCU devices like the Tuya DIN 4P 1-63A and MGF-T3-SMART that were not sending all dpIDs after flashing OpenBeken.
The key finding is "Processing by the Wi-Fi module" mode: a non-empty 0x02 MCUConf payload makes P08 act as the WiFi LED/state pin and pairing button.
The MCUConf payload is 0807, and the Wi-Fi module resets when the GPIO input stays low for more than 5 seconds.
Setting the WiFi LED pin to AlwaysHigh or AlwaysLow unlocks the full dpID set, while tuyaMcu_defWiFiState 4 and state queries do not.

Generated by the language model.

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.

Tuya DIN 4P 1-63A device with WiFi features on a green measurement mat.

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

Smart energy meter MGF-T3-SMART with LCD display and control buttons

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:

Screenshot of communication analysis between WiFi module and MCU.

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:

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:


// 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:


// 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:

Screenshot of a settings interface for outputs P7 and P8 on a TuyaMCU device.

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):

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...

Diagram of a device with a Tuya Wi-Fi module and connected red LED.

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

Attachments:

Guide-to-Interworking-with-the-Tuya-MCU.pdf (1.93 MB) You must be logged in to download this attachment.

About Author

p.kaczmarek2 wrote 14416 posts with rating 12371 , helped 650 times. Been with us since 2014 year.

Comments

Add a comment

DeDaMrAz 27 Nov 2024 22:01

So for such devices tuyaMcu_defWiFiState 4 is not necessary or? [Read more]

p.kaczmarek2 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: https://obrazki.elektroda.pl/7508915600_1732736910_bigthumb.jpg Please... [Read more]

Samezrp1 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: tuyaMcu_defWiFiState 4 . The WiFi connection marker would appear and disappear,... [Read more]

p.kaczmarek2 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... [Read more]

FAQ

TL;DR: If MCUConf carries a 2-byte payload like 0807, setting tuyaMcu_defWiFiState 4 alone will not unlock all dpIDs. "No 0x03 packet is sent" in Wi-Fi-processing mode, so OpenBeken users must drive the WiFi LED GPIO, often P08, to AlwaysHigh or AlwaysLow to expose extra telemetry for MQTT or Home Assistant. [#21322921]

Why it matters: This explains why some flashed TuyaMCU devices show only a few channels, ignore state queries, or reconnect endlessly despite apparently correct UART settings.

Case	Detection in capture	What controls connectivity	What usually fixes missing data
MCU handles WiFi state	`0x02` MCUConf has no payload; `0x03` WiFi state appears	WiFi state packet	`tuyaMcu_defWiFiState 4`
Wi-Fi module handles processing	`0x02` MCUConf has a payload, e.g. `0807`; no `0x03`	GPIO pins for LED/reset	Set WiFi LED pin to AlwaysHigh or AlwaysLow
Time-gated behavior	Device reconnects about every 1 minute; channels appear late	Correct time from NTP	Start NTP and send current time

Key insight: On some TuyaMCU devices, the WiFi LED pin is not only an indicator. The MCU also reads that GPIO as a connectivity signal, and it may withhold extra dpIDs until that pin stays in the expected state. [#21322900]

Quick Facts

The documented Wi-Fi-processing mode resets when a GPIO input stays low for more than 5 s, and the relevant pins are announced through command word 0x02 MCUConf. [#21322900]
In the demonstrated case, MCUConf payload 0807 mapped P08 to WiFi LED/WiFi state output and 07 to the pairing button, which explained why packet 0x03 never appeared. [#21322900]
Before the GPIO fix, the capture exposed only 4 dpIDs: 8, 1, 102, and 16; after forcing the WiFi LED pin state, the device reported a much larger set including 101, 15, 19, 13, 18, 7, 6, 9, and 17. [#21322900]
A repeated query every 10 seconds using tuyaMcu_sendQueryState did not reveal extra dpIDs on the Wi-Fi-processing device, so polling alone was insufficient. [#21322900]
In a separate failure mode, one flashed device reconnected to WiFi about every 1 minute until NTP was enabled and tuyaMcu_sendCurTime sent valid time to the MCU. [#21324901]

Why does a TuyaMCU device fail to send all dpIDs even when tuyaMcu_defWiFiState 4 is set in OpenBeken?

Because some devices do not use packet-based WiFi state at all. When MCUConf 0x02 contains a payload such as 0807, the MCU expects connectivity through GPIO status, not through 0x03 or tuyaMcu_defWiFiState 4. In the shown capture, 0x04 state forcing still left only 4 dpIDs visible until the WiFi LED pin was driven to a fixed level. [#21322900]

How can I make a TuyaMCU device in "Processing by the Wi-Fi module" mode publish more data points to MQTT or Home Assistant?

Set the WiFi LED GPIO announced by MCUConf to the expected fixed state. 1. Read the 0x02 payload and identify the WiFi LED pin, such as P08. 2. Test that pin with GPIODoctor or OpenBeken pin settings. 3. Set it to AlwaysHigh or AlwaysLow, depending on the device, and recheck dpIDs. That change unlocked extra telemetry in the demonstrated capture. [#21322900]

What is the MCUConf 0x02 packet in the TuyaMCU protocol, and what does it mean when it contains a payload like 0807?

"MCUConf" is a TuyaMCU configuration packet that tells the WiFi module how connectivity-related GPIOs are assigned, a key characteristic is that a non-empty payload switches behavior from packet-based WiFi state to pin-based signaling. Payload 0807 means P08 is used for WiFi LED and WiFi state output toward the MCU, while 07 is the pairing button pin. [#21322900]

What is a dpID in TuyaMCU, and how do I identify missing dpIDs from a UART communication capture?

"dpID" is a TuyaMCU datapoint identifier that labels one reported function or value, a key characteristic is that each id is tied to a type and payload seen in UART packets. You identify missing dpIDs by comparing the small set actually reported, such as ids 8, 1, 102, and 16, with the fuller list that appears after the right connectivity condition is met. [#21322900]

How do I tell from a TuyaMCU analyzer capture whether WiFi state is handled by packet 0x03 or by GPIO pins from MCUConf?

Check the 0x02 MCUConf packet first. If 0x02 has no payload, WiFi state is handled by packet 0x03. If 0x02 has a payload, such as 0807, the payload defines GPIO pins for WiFi status and reset, and no 0x03 packet is sent. That split is visible in the two compared captures from the thread. [#21322921]

What's the difference between TuyaMCU devices that use WiFi state packet 0x03 and devices that use GPIO-based WiFi processing mode?

The difference is where the MCU looks for connectivity. In the 0x03 model, the WiFi module reports state over UART, so tuyaMcu_defWiFiState 4 can be enough. In GPIO-based Wi-Fi-processing mode, MCUConf carries 2 bytes of pin mapping, no 0x03 is sent, and the MCU reads a physical pin such as P08 instead. [#21322921]

How do I use GPIODoctor or OpenBeken pin settings to find and set the WiFi LED pin to AlwaysHigh or AlwaysLow?

Use the pin named by MCUConf, then test whether changing it unlocks telemetry. In the example, the 0807 payload pointed to P08. GPIODoctor showed that the MCU was physically connected to that pin, and setting P08 to AlwaysHigh or AlwaysLow in OpenBeken immediately exposed more dpIDs. This is the correct practical test for undocumented GPIO behavior. [#21322900]

Why doesn't tuyaMcu_sendQueryState return additional dpIDs on some TuyaMCU devices?

Because the MCU is blocking telemetry until a separate connectivity condition is satisfied. On the demonstrated device, querying state every 10 seconds did nothing, even though heartbeats and some relay control worked. The missing condition was not a poll request but the correct WiFi LED GPIO level in Wi-Fi-processing mode. [#21322900]

When should I use tuyaMcu_defWiFiState 4, and when is setting the WiFi LED GPIO state the correct fix instead?

Use tuyaMcu_defWiFiState 4 when MCUConf 0x02 has no payload and packet 0x03 carries WiFi state. Use a fixed GPIO level when MCUConf has a payload, because those devices move WiFi-state handling to pins and stop sending 0x03. The thread shows both cases clearly and treats payload presence as the decision point. [#21322921]

How does the WiFi LED pin on some TuyaMCU devices also affect whether the MCU sends extra telemetry data?

The MCU appears to read that LED pin as a connectivity gate. The thread author states, "the MCU is also reading the WiFi state (LED) pin," which explains why extra dpIDs stayed hidden until P08 was forced high or low. In other words, the LED line doubles as a logic input, not just a visual indicator. [#21322921]

What troubleshooting steps help when a flashed CB3S or TuyaMCU device keeps reconnecting to WiFi and stops sending MQTT updates?

Check time sync as well as WiFi-state handling. One reported device dropped and rebuilt WiFi roughly every 1 minute, and MQTT data stalled until NTP was started and current time was sent to the MCU. If the capture also shows MCUConf payload, verify the WiFi LED GPIO state next, because packet 0x04 alone may still fail. [#21324901]

How do NTP time sync and tuyaMcu_sendCurTime influence TuyaMCU connectivity and channel reporting on OpenBeken?

They can satisfy a third connectivity check based on valid time. Starting the NTP driver and sending tuyaMcu_sendCurTime stabilized one device's WiFi behavior and caused CB3S-defined channels from TuyaMCU to appear. The follow-up post suggests some non-battery devices verify that the time is not stuck at 1970 before fully reporting data. [#21324964]

Why would a TuyaMCU device start sending more channels only after correct time is provided through NTP?

Because some devices treat valid time as proof of real connectivity. In the reported case, the MCU did not fully update data until OpenBeken supplied current time through NTP and tuyaMcu_sendCurTime. Once time became valid, WiFi stabilized and additional channels began reporting, which indicates a time-gated firmware check. [#21324901]

Which connectivity check matters more for non-battery TuyaMCU devices: WiFi state 0x04, GPIO WiFi status, or NTP time?

The one implemented by that device matters most, and the thread shows at least 3 methods. Non-battery TuyaMCU units may validate 0x04 WiFi state, GPIO status from a 2-byte MCUConf payload, or correct NTP time. No single method wins universally; payload presence in 0x02 and reconnection symptoms are the fastest clues. [#21324964]

What is the safest way to test undocumented TuyaMCU GPIO behavior on mains-powered devices like a Tuya DIN 4P breaker?

Use software-side pin testing first and avoid hardware rewiring on live mains equipment. Read the UART capture, identify the announced GPIO from MCUConf, then change only that pin's logical role in OpenBeken or GPIODoctor. The demonstration used a Tuya DIN 4P breaker rated 1–63 A, so non-invasive testing is the safest starting point. [#21322900]

Generated by the language model.