logo elektroda
logo elektroda
X
logo elektroda

TuyaMCU flashing, setup and configuration guide - configure dpIDs for Home Assistant

p.kaczmarek2  48 17103 Cool? (+11)
📢 Listen (AI):

TL;DR

  • It guides configuring TuyaMCU devices in OpenBeken, from extracting dpIDs and mapping them to channels to publishing them in Home Assistant.
  • The workflow starts before flashing: identify TuyaMCU, read baud settings, sniff or query dpIDs, then start the TuyaMCU driver in autoexec.bat.
  • TuyaMCU baud rates are 9600 and 115200, and linkTuyaMCUOutputToChannel can map dpID 24 to channel 1 or raw MQTT topics.
  • Flash access is often blocked because TuyaMCU shares the serial port, so you may need to cut traces, desolder parts, or use reset tricks.
  • Optional features include LittleFS-hosted custom REST pages, flag 46 DP JSON access, and Home Assistant discovery or manual YAML integration.
Generated by the language model.
Block diagram of MCU and Wi-Fi module cooperation.
Here I will show you step by step how to configure a TuyaMCU device, how to get dpID list, how to map dpIDs to channels and publish them to Home Assistant and how to create custom page for the device. This topic will cover most of TuyaMCU topics required to get your Tuya device running cloudless with HA.

But first of all - do not flash device first, start with reading this guide. This is because one of dpID extraction methods requires an unflashed device

0. Do generic research
The first step is obviously to figure out what TuyaMCU is. This is why some basic reading is recommended first.
- read our writeup: TuyaMCU protocol - communication between the microcontroller and the WiFi module
- read Tuya docs: https://developer.tuya.com/en/docs/iot/tuya-c...-serial-port-access-protocol?id=K9hhi0xxtn9cb
- open our devices list, tick "detailed" checkbox and search for "TuyaMCU", read the found teardowns
- read our autoexec samples page, at least ones related to TuyaMCU https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
For generic OBK knowledge, please:
- read our docs: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/README.md
- watch our flashing guides: https://www.youtube.com/@elektrodacom

1. Check is your device using TuyaMCU
Now you need to know is your device using TuyaMCU. So,
tTry to answer the following questions:
- when you open device case, is there an extra MCU in SOIC or TQFP case (or similiar) near WiFi module?
- is WiFi module connected to MCU via RX1/TX1 (UART1) lines?
- when you do a config extraction with our flasher, does it find a baud setting in the flash?
- when you have flashed your device already, does your device has still functional buttons, even without configuring them in OBK?
- does your device has a screen?
If you answered YES to some of the questions, there is a chance your device is TuyaMCU.

2. Determine baud setting
The best way to find out baud setting is to use our flash tool: our flasher, just get a 2MB flash backup of device taken by UART or just download Tuya config partition via Tuya config extraction in OBK and drag and drop it on the flasher:
BK7231 Easy UART Flasher interface with settings and TuyaMCU device information
TuyaMCU baud rates are 9600 (default) and 115200 (high speed)

3. Determine the meaning of dpIDs
This is where having a not yet flashed device is handy, but there are mutliple ways. If you haven't flashed device yet:
- you can just get them from Tuya
- if you have an isolated USB to UART converter, and know how to connect it in a safe manner (because device power supply may not be isolated from mains), you can use our TuyaMCU analyzer to sniff the communication and observe which dpIDs are sent when you are doing a particular action in Tuya app, for example, change relay and observe which dpID is sent
If you already flashed OBK:
- you can start the driver and set the TuyaMCU baud in autoexec and then use tuyaMcu_sendQueryState command to get dpIDs from the MCU. Then, you have to observe their values and guess their meanings (for example, if thermometer is showing 21.5C, and one dpID has value 215, then you can suspect it's the temperature)
- you can also search our devices list for similiar devices, maybe some dpID are matching
- you can also use tuyaMcu_sendState command to send something to TuyaMCU, for example, relay value, and observe if it changes on the physical device, see command docs

5. Start the driver and check is there a communication
This is when you already have to flash the device. Earlier steps could be completed without flashing, but now it's the time to change the firmware.
The main issue with changing firmware of TuyaMCU devices is that TuyaMCU uses the same port as the flashing.
This means, that you will have to done something to sever the connection of MCU for the time of the flashing, at least in the most cases.
There are multiple ways to do it:
- cut the traces (RX and TX) leading to MCU and repair them after flashing
- disconnect board with TuyaMCU (if possible, if boards are separate)
- desolder either TuyaMCU or WiFi module (sometimes it's possible)
- desolder resistors on RX/TX traces (if present, some devices don't have them)
Alternatively, you could also try to look up the datasheet of the MCU and check whether it's possible to put it into the RESET state via pulling it low or high.
Futhermote, there are also OTA flashing solutions, but they are not reliable and most of the new devices are patched.

6. Start the driver and check is there a communication
Now it's time to setup a basic autoexec.bat in OBK:



Here is a starting config:

// Start TuyaMCu driver
startDriver TuyaMCU
// set TuyaMCU baud rate
//tuyaMcu_setBaudRate 115200
// 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

The tuyaMcu_setBaudRate is commented out, please remove comment if needed. This should give you basic TuyaMCU heartbeats and communication in the OpenBeken Web App Log. This should also make tuyaMcu_sendQueryState work.
Do not forget the tuyaMcu_defWiFiState 4 line. By default, OBK sends "paired" state (0x04) only when MQTT is on, but some devices always require the WiFi state to be "paired" (0x04) before sending data. This will control the WiFi LED of the MCU and even may control buzzer. Some devices will send buzzer audio signals when not paired.


7. Map the dpIDs
In OBK, you can map dpIDs to channels.
Channel is like a variable, they can store integers.
You can adjust the way channels are displayed by setting their types, for example:

setChannelType 1 Toggle

This will create a toggle on GUI, and this:

setChannelType 1 temperature

this will create a temperature display.
To see full list of channel types, check: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/channelTypes.md
Still, to get data from MCU, you need to map dpID to channel, so:

// Map given dpID to channel 1
// dpID type value
linkTuyaMCUOutputToChannel 24 val 1

Code above maps dpID 24 to channel 1, with type value.
There are multiple possible types.
There are Tuya types:
- 0-raw
- 1-bool
- 2-value
- 3-string
- 4-enum
- 5-bitmap
And there OBK-specific types. For example, if you want given dpID to always publish over MQTT in the hex form, you can do:

linkTuyaMCUOutputToChannel 24 MQTT

This will publish the value under tm/TYPE/dpID topic every time that TuyaMCU sends it.

There are also special types for compound raw data packets, the sample below is for Voltage + Current + Power raw packet for TAC2121C device:

linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP

The code above will automatically set Voltage, Current and Power channels.
To see complete config samples, check our autoexec samples:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
You can also use our devices list:
https://openbekeniot.github.io/webapp/devicesList.html
Enter "TuyaMCU dimmer" in the search field (for example) and search.

So, if you don't know the meaning of dpIDs, the workflow is the following:
1. try to query state from the MCU
2. write config to map received dpIDs to channels
3. save config and reboot
4. observe if the config works, if something is missing, do the adjustements
Do a little steps, one at time, that way you can figure even a complicated device. Don't hesitate to ask on forum if there is a problem.

8. Create a custom GUI
This is purely optional, but if you want to have a custom gui on your device, you can create your own page with HTML and JS and host it on LittleFS:
OpenBeken as a mini HTTP hosting - writing pages in Javascript, Tasmota REST
There is a very useful feature that can be used for this purpose, it's called DP. It can be sent via HTTP from the Javascript on REST page:
Screenshot of JSON with dpID data
In order for it to work, you need to enable the following flag: flag 46.
This will store last values of dpIDs in hex and allow you accessing them in JSON.
The same command works via MQTT, it will send reply under stat/TuyaMCU/DP.


9. Pair with Home Assistant
There are multiple ways to do the pairing and they strongly depend on your personal preference and your particular device.
The most simple way is to just use automatic HASS Discovery which is creating Hass entities that are based on OBK channel types and their respective name:



The more advanced way is to write YAML config yourself and just put it in the configuration.yaml of your Home Assistant.
There are few good tricks that may help with that, for example, you can use a special argument for linkTuyaMCUOutputToChannel to enable dpID publishing in raw hex form, so it can be processed by HA later:

linkTuyaMCUOutputToChannel 6 MQTT

Set it, save and reboot, and observe what happens in Home Assistant log. You can also use Home Assistant MQTT tool to watch for MQTT packets.

Can you show sample teardown topic for TuyaMCU dimmer?
Well, as I said, please use our devices list, but still, here is a one sample:
OpenBeken and TuyaMCU dimmer - configuration guide/tutorial
And here is a fan device configuration:
BK7231T Treatlife DS03 Fan/Light Dimmer Switch: OTA Flash & Setup Guide (TuyaMCU dpIDs)
And here is power meter teardown:
[BK7231N ] Teardown and flashing of Tomzn TOMPD-63 WIFI (not to be confounded with TOMPD-63LW)

Can you show a sample of custom REST page for device
You can check out our BW-AF1 tutorial:
OpenBeken on BW-AF1 fryer with WiFi - interior, TYWE3S/WB3S, configuration
It has a custom REST page for the fryer control.


Can you show a sample of custom script for device?
Check out our TAC2121C-like setup with charging limit controller:
Home Assistant Integration: Reflashing BK7231N in Tuya Smart DIN-rail Energy Meter TAC2121C
The final script is at the end of the topic.

What about battery powered devices?
Battery powered TuyaMCU devices are special - the MCU controls the power of WiFi module there. MCU only enables WiFi module when it needs to report data. This requires a special driver called tmSensor.
Please see a sample tmSensor guide for more information:
Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
[CB3S/BK7231N] Temperature/Humidity Sensor with TuyaMCU - Diagram, Reverse Enginering



Summary

There are many ways to configure and flash TuyaMCU devices. TuyaMCU dpIDs can be extracted before flashing, either manually (by sniffing the protocol) or automatically from Tuya cloud side. TuyaMCU dpIDs can be also requested and investigated after flashing, with a query state command. TuyaMCU can be configured in a flexible way, either with stock OBK page, or with fully custom REST interface that can be hosted on any OBK device with LittleFS. TuyaMCU devices configured with OBK can be also paired with Home Assistant, both by automatic Home Discovery or by more advanced and flexible manual YAML config. There are also multiple ways to get TuyaMCU data out of OBK device - you can just use OBK channels, or you can use special MQTT dpID link, or you can use DP command to request all dpID values per request. The DP command works both via HTTP and MQTT. You can also script OBK devices to automate your setup, either with or without Home Assistant.
Let us know if you have any TuyaMCU-related questions, we will do our best to help you configure your devices!

About Author
p.kaczmarek2
p.kaczmarek2 wrote 14587 posts with rating 12609 , helped 654 times. Been with us since 2014 year.

Comments

p.kaczmarek2 24 Apr 2024 09:15

TuyaMCU update! Please see the following topic for the details of new OBK TuyaMCU feature: How to get dpID list of types and values for flashed TuyaMCU devices with OpenBeken [Read more]

morgan_flint 18 Jul 2024 14:15

Hello @pkaczmarek2 ! Maybe there are two more possibilities, although I'm unsure about how to make them work, or if they're redundant with the other ones... perhaps the members referred below can give... [Read more]

io2345 16 Sep 2024 11:59

Channel numbers greater than 99 seem not to be supported. I tried to use 101 and 102, as these were my corresponding dpID's, but the controls were not displayed in GUI until I changed channel number to... [Read more]

p.kaczmarek2 17 Sep 2024 18:45

There are 64 available channels in OBK: https://obrazki.elektroda.pl/2810984600_1726591551_bigthumb.jpg [Read more]

erdeidominik1999 24 Jan 2025 15:32

Hy! Is tehre any way to create channel type like select menu? So I need to have for example 4 fixed selection options. Another question: I have a solar charge controller which works with tuyamcu, my... [Read more]

doudouni100 16 Feb 2025 14:55

Hi Is there any way to change it ? I have a Temperature and humidity sensor and the battery channel is 101 so it cannot be displayed. [Read more]

erdeidominik1999 16 Feb 2025 15:03

Do you have more than 64 channels? Why would you like to use ch101? [Read more]

p.kaczmarek2 16 Feb 2025 15:05

You don't need to change it. You can map any dpID to any channel. For example: startDriver TuyaMCU // cook on/off setChannelType 1 Toggle setChannelLabel 1 "Cook" linkTuyaMCUOutputToChannel... [Read more]

erdeidominik1999 16 Feb 2025 15:13

Yes the same with RAW_TAC2121C_VCP with 6 bytes. The types need to be Voltage_div10, Current_div10, Power_div10. But I think Current_div10 is not exists. Another type that is not exists but it needs is... [Read more]

doudouni100 16 Feb 2025 15:25

Thanks ! That did it.! I tried it before but I didn't change the number after "enum" So for anyone that has a sensor this is the autoexec: startDriver TuyaMCU startDriver tmSensor // dpID 27 is... [Read more]

erdeidominik1999 16 Feb 2025 15:28

You can also use channel 1,2,3, I think it is cleaner. It is not needed to have the same channel as tuya dp. [Read more]

morgan_flint 17 Feb 2025 12:08

Do you really need to start tmSensor? As long as the Tuya MCU manages the interface with the sensor, Open Beken doesn't need to take care of that, I think [Read more]

doudouni100 17 Feb 2025 14:32

Hey ! Your probably right ! It makes sense. After trying everything I found on this forum and others with no success, I thought I'd give it a go myself and also learn something on the way. The... [Read more]

morgan_flint 17 Feb 2025 14:54

No, it won't make any harm, but you don't need to take it apart, you can edit the autoexec.bat from the web interface [Read more]

doudouni100 17 Feb 2025 16:01

Like I said it is battery powered and it stays on for a few seconds to send whatever it sends and the Wi-Fi turns off to save battery, I will have to take it apart to force power to the Wi-Fi module... [Read more]

erdeidominik1999 17 Feb 2025 16:19

If you power it off and on 3 times it will goes to safe mode, and not run the autoexec, so the wifi won't turn off. [Read more]

morgan_flint 17 Feb 2025 16:38

In the case of some of my battery-powered Tuya devices (also temperature - humidity sensors) pushing the backlight button for a long period also forces WiFi to stay for a longer time. From the photos,... [Read more]

erdeidominik1999 10 Mar 2025 17:02

@pkaczmarek2 Can you include this type? [Read more]

blacksun2 10 Jul 2025 14:00

Hello, I'm still very new to OpenBeken and am having a hard time. One of the issues is the topic of TuyaMCU. The question above is exactly the right one – how do you know if a device is using TuyaMCU? Isn't... [Read more]

FAQ

TL;DR: OpenBeken TuyaMCU setup revolves around 64 channels and correct dpID mapping. As one maintainer put it, "You can map any dpID to any channel." This FAQ helps OBK and Home Assistant users identify TuyaMCU devices, extract dpIDs, choose baud, and avoid flashing mistakes when RX/TX is shared with the MCU. [#21441973]

Why it matters: TuyaMCU devices often look normal after flashing, but without correct UART setup, dpID mapping, and WiFi-state handling, buttons, sensors, MQTT, and Home Assistant entities may never appear.

Option Best use Main advantage Main limitation
Tuya cloud / API / JSON methods Unflashed devices Gets dpIDs before firmware changes Needs original firmware access or cloud data
UART sniffing / analyzer Unflashed devices Shows real dpID activity during actions Unsafe on mains unless fully isolated
tuyaMcu_sendQueryState after OBK flash Flashed devices Queries MCU directly from OBK You must infer meanings from returned values
Tasmota approach Existing Tasmota users Similar TuyaMCU support exists Still requires manual dpID work and command entry

Key insight: dpID numbers are not GUI channel numbers. In OBK, you map any Tuya dpID, including 101 or 111, onto a valid local channel such as 1, 2, or 10, then assign the display type you want. [#21441973]

Quick Facts

  • TuyaMCU baud rates mentioned in the thread are 9600 baud as default and 115200 baud as high speed; BK7231GUIFlashTool can detect the setting from a 2 MB UART flash backup or a Tuya config partition dump. [#20975937]
  • OBK exposes 64 available channels, so GUI controls will not appear for channel numbers above that limit; dpID 101 or 102 must be remapped to a valid channel like 10 or 3. [#21229830]
  • The highest-risk hardware step is probing RX/TX on mains-powered devices: a maintainer warns never to measure while connected to 230 V, because you may short mains to the PC. [#21603621]
  • For battery TuyaMCU devices, entering safe mode by powering the unit off and on 3 times can keep Wi-Fi available long enough to recover settings without running autoexec. [#21443630]
  • Optimization data posted in 2026 reduced a battery-device publish path from 10.77 s to 1.8 s by changing flags and startup flow, showing large latency gains are possible on MQTT-first builds. [#21801342]

1. What is TuyaMCU in OpenBeken, and how does it communicate with the WiFi module over UART?

TuyaMCU in OpenBeken is a UART-linked companion MCU that handles device logic while the WiFi module runs OBK. "TuyaMCU" is a device-control architecture that splits work between a main microcontroller and a WiFi module, using serial UART messages to exchange state, commands, and dpIDs. In the thread, the expected wiring is MCU-to-module over RX1/TX1, and devices often keep local buttons working even before OBK pin setup because the external MCU still drives them. [#20975937]

2. What are dpIDs in TuyaMCU devices, and how are they mapped to OpenBeken channels for MQTT or Home Assistant?

dpIDs are Tuya data-point identifiers, and OBK maps them to channels with linkTuyaMCUOutputToChannel. "dpID" is a Tuya data-point identifier that labels one reported value or command, such as relay state, temperature, or a raw packet, and each dpID can be linked to any OBK channel and display type. Example mappings in the thread include linkTuyaMCUOutputToChannel 24 val 1 and linkTuyaMCUOutputToChannel 101 enum 10. Once mapped, channels can feed MQTT, Home Assistant discovery, or manual YAML entities. [#20975937]

3. How can I tell whether a Tuya device is using TuyaMCU before flashing it with OpenBeken?

You identify a likely TuyaMCU device by checking hardware, UART behavior, and extraction clues before flashing. Use this 3-step test: 1. Open the case and look for an extra MCU in SOIC or TQFP form near the WiFi module. 2. Check whether that MCU connects over RX1/TX1. 3. Run extraction tools and see whether they find a baud setting instead of ordinary pins. A maintainer later clarified that all TuyaMCU devices found so far used an MCU connected by UART, but some UART MCUs are not TuyaMCU protocol devices. [#21603621]

4. Which methods work best for extracting TuyaMCU dpIDs from an unflashed device, including Tuya cloud, firmware JSON, and UART sniffing?

The best unflashed methods are Tuya cloud extraction, firmware-derived JSON, and UART sniffing with isolation. The guide lists Tuya cloud extraction and live sniffing with a TuyaMCU analyzer as primary options. Later discussion adds two more routes: unpacking or decrypting factory firmware to obtain a JSON with dpID data, and using a Tuya API response that includes more descriptive dpID information. UART sniffing is the most direct, but only if the serial adapter is isolated and the power supply is safe to probe. [#21159305]

5. How do I find the correct TuyaMCU baud rate with BK7231GUIFlashTool or Tuya config extraction?

You find the baud rate by dragging a device backup or Tuya config dump into BK7231GUIFlashTool. The thread recommends either a 2 MB UART flash backup or the Tuya config partition extracted through OBK. The tool then reveals the stored baud setting, with 9600 listed as the default TuyaMCU speed and 115200 as the high-speed option. If the flasher finds no pins but does find baud, that is treated as a strong TuyaMCU clue. [#20975937]

6. What is the safest way to flash a TuyaMCU device when the MCU shares the same RX/TX lines as the flashing interface?

The safest approach is to isolate or temporarily break the MCU connection before flashing. The guide says TuyaMCU usually shares the same port used for flashing, so the WiFi module and MCU must be separated first. Practical methods include cutting RX/TX traces, unplugging a separate MCU board, desoldering the MCU or WiFi module, or removing resistors on the serial lines. You can also check whether the MCU can be forced into reset. Never probe serial on a mains-powered board unless the whole setup is safely isolated from 230 V. [#21603621]

7. Why does tuyaMcu_defWiFiState 4 matter in autoexec.bat, and what problems does it solve on some TuyaMCU devices?

tuyaMcu_defWiFiState 4 matters because some TuyaMCU devices only report full data when they believe Wi-Fi is paired. In OBK, state 0x04 means “paired.” The guide says some MCUs will not send all data unless they see that state, and the setting can also affect the WiFi LED or even buzzer behavior. Without it, a flashed device may show heartbeat traffic yet still hide sensor data or emit pairing-related sounds until MQTT is active. [#20975937]

8. How do I use tuyaMcu_sendQueryState and tuyaMcu_sendState to identify unknown dpIDs after flashing OpenBeken?

Use tuyaMcu_sendQueryState to read current values and tuyaMcu_sendState to provoke changes. A practical workflow is: 1. Start the TuyaMCU driver and set the correct baud. 2. Run tuyaMcu_sendQueryState and note returned dpIDs and values, such as 215 for a temperature that may mean 21.5°C. 3. Send test values with tuyaMcu_sendState, such as a relay toggle, and watch the physical device react. This lets you match unknown dpIDs by observation rather than guessing blindly. [#20975937]

9. Why are dpIDs like 101 or 102 not shown as GUI controls in OBK, and how should they be mapped to valid channel numbers?

dpIDs like 101 or 102 are not shown because GUI controls depend on OBK channel numbers, not Tuya dpID values. One user found channels above 99 did not display, and the maintainer then clarified OBK has 64 available channels total. The fix is to map dpID 101 or 102 onto a valid channel such as 10 or 3, then assign a channel type like ReadOnly or Toggle. A posted example maps dpID 101 battery state to channel 10 successfully. [#21442008]

10. What's the difference between a Tuya dpID number and an OpenBeken channel number, and why don't they need to match?

A Tuya dpID identifies MCU data, while an OBK channel is just a local variable slot for display, MQTT, and automation. They do not need to match because linkTuyaMCUOutputToChannel explicitly links one to the other. The maintainer answered the confusion directly: “You can map any dpID to any channel.” Their sample maps dpID 111 to channel 1, dpID 101 to channel 2, and dpID 103 to channel 3, proving one-to-one number matching is unnecessary. [#21441973]

11. How can I publish TuyaMCU dpIDs in raw hex over MQTT and consume them in Home Assistant with manual YAML?

Map the dpID with the MQTT mode so OBK publishes the raw hex payload directly. The thread gives the exact example linkTuyaMCUOutputToChannel 6 MQTT, which publishes under the tm/TYPE/dpID topic whenever the TuyaMCU sends that dpID. From there, Home Assistant can consume the payload with manual YAML and parse the hex into template sensors or automations. The author explicitly recommends watching the MQTT packets in Home Assistant logs or MQTT tools after saving and rebooting. [#20975937]

12. OpenBeken vs Tasmota for TuyaMCU devices: which setup is easier when you need to identify and configure dpIDs?

Neither platform removes the dpID work; OpenBeken is easier if you prefer reusable autoexec.bat files. A maintainer pushed back on the idea that Tasmota is simpler, noting that Tasmota TuyaMCU setup also requires dpID knowledge and manual commands. He wrote that in Tasmota, “you type those commands manually,” while OBK users can copy a prepared autoexec. If your exact device already has a working OBK example in the device list, OBK reduces repetitive command entry and speeds reuse. [#21603621]

13. What is the tmSensor driver, and when should it be used instead of the regular TuyaMCU driver for battery-powered devices?

Use tmSensor for battery devices where the MCU controls Wi-Fi power and only wakes the radio to report data. The original guide says battery-powered TuyaMCU devices are special because the MCU powers the WiFi module only when needed, and that “This requires a special driver called tmSensor.” Later discussion shows not every battery sensor actually needs tmSensor once TuyaMCU mapping works, but it remains the recommended path for classic power-gated battery devices in the thread’s older model. [#20975937]

14. How does the new tuyaMcu_batteryPoweredMode for version 3 battery-powered TuyaMCU devices work, especially with 0x34 sensor updates?

It adds support for version 3 battery TuyaMCU devices that push sensor data with command 0x34 after Wi-Fi and MQTT status are announced. A contributor described devices where the MCU will not answer normal sensor-status requests and only transmits updates after the WiFi module reports network and MQTT connection. Their patch processes 0x34 packets and adds tuyaMcu_batteryPoweredMode to reduce unnecessary UART traffic so the module stops wasting battery on repeated heartbeat chatter after publishing changes. [#21792109]

15. How can I create a select-menu style channel type or a custom 6-byte RAW parser like RAW_TAC2121C_VCP for solar charge controller dp packets in OpenBeken?

The thread does not provide a finished select-menu type or a released 6-byte parser, but it clearly states the requested format. The request was for a fixed 4-option select-like control and a 6-byte RAW parser splitting 00 77 00 04 00 53 into three 2-byte values, similar to RAW_TAC2121C_VCP. The proposed output types were Voltage_div10, Current_div10, Power_div10, and a missing Percent_div10. As of the cited discussion, this remained a feature request rather than documented functionality. [#21441988]
Generated by the language model.
%}