How to make TuyaMCU device send more data points? Why are dpIDs not sent? Processing by the Wi-Fi...
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
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:
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
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.
p.kaczmarek2 wrote 11842 posts with
rating 9938 , helped 566 times.
Been with us since 2014 year.
Comments
So for such devices tuyaMcu_defWiFiState 4 is not necessary or? [Read more]
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]
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]
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]