logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

p.kaczmarek2 16587 48

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.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #31 21791988
    protectivedad
    Level 9  
    Posts: 40
    Help: 2
    Rate: 5
    >>21791984

    I like powerSave, now. Regardless of what it does its purpose is to save power and the battery devices will work without it being on. But I'll do what you think is best.

    EDIT:
    Can you test it on a non-battery device? What does it do?

    EDIT AGAIN:
    Maybe you are right. I can see the confusion that will come from the perspective of non-battery powered devices using the command.
  • ADVERTISEMENT
  • #32 21791998
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14493
    Help: 651
    Rate: 12502
    PowerSave 1, in OBK, is used to reduce energy usage of OBK. So, by extension, users would think that once you enable TuyaMCU powersave, then you will get smaller energy usage. That's not accurate. They would be trying to enable it on any TuyaMCU device.
    Helpful post? Buy me a coffee.
  • #33 21792109
    protectivedad
    Level 9  
    Posts: 40
    Help: 2
    Rate: 5
    >>21791998

    I've made the suggested changes the command is now tuyaMcu_batteryPoweredMode and it is ready to be released.
  • ADVERTISEMENT
  • #34 21792111
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14493
    Help: 651
    Rate: 12502
    Well, I guess it's acceptable. Thank you!

    Now, do we have a teardown for the device that requires it on our forum?
    Helpful post? Buy me a coffee.
  • #35 21792142
    protectivedad
    Level 9  
    Posts: 40
    Help: 2
    Rate: 5
    >>21792111

    I talk about the device here.
    protectivedad wrote:
    I purchased some ZY-D02 door sensors from AliExpress.


    I can rename the post and add some details with the new command once it is released. I will look at creating a template. One problem is that the "ZY-D02" devices have many different versions all the same name and they don't seem to be consistent. I've seen them mentioned a couple of times.

    daherbst85 wrote:
    I’m using the ZY-D02, which seems nearly identical to the D06 (mine uses a 2063P hall sensor and lacks the CB3S metal shield).

    They removed the TuyaMCU and directly wired the sensors to the WiFi module.

    meillagimeil wrote:
    I have this device ZY-D02-CB3S-V1.3, BK7231N, firmware 1.18.190.... and it's driving me nuts...

    They never got it working.
  • #36 21792144
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14493
    Help: 651
    Rate: 12502
    IF you have this device solved, please consider making a separate guide topic for it, so we can add it to our devices list here:
    https://openbekeniot.github.io/webapp/devicesList.html
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #37 21792369
    protectivedad
    Level 9  
    Posts: 40
    Help: 2
    Rate: 5
    Is there a way for the tuyaMCU driver to be automatically loaded? One of the issues I noticed trying to program these TuyaMCU battery operated devices is that if the WiFi module doesn't talk to the TuyaMCU in the first few seconds the TuyaMCU will turn it off an on repeatedly. On initial programming this leads to the device AP showings up but never being able to connect to it because it is never available long enough to get the web page. I know there are solutions when flashing the device to change the OBK settings to include a startup command "backlog startDriver tuyaMCU;". I just think assigning the tuyaMCU driver to the RX/TX pins and using that to automatically load the driver is a more elegant solution. Which has the added benefit of documenting in the module screen that the device is a tuyaMCU.

    Has this been discussed or thought about before? I was looking for a solution which will make the battery operated devices easier to setup and test.
  • #38 21792372
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14493
    Help: 651
    Rate: 12502
    You are the first one to bring this topic. What would be the use case of that? In order to use TuyaMCU, you have to create autoexec.bat anyway, otherwise you can't map channels, so there is no reason to start TuyaMCU anywhere else, hm?
    Helpful post? Buy me a coffee.
  • #39 21792423
    protectivedad
    Level 9  
    Posts: 40
    Help: 2
    Rate: 5
    >>21792372

    I get it. You need other stuff for it to function properly, but without the driver loading you can't get access to the battery device without taking it apart. So if you forget to create a backlog entry in the OBK on flash, or the autoexec.bat that loads the driver gets wiped, say on updating the firmware, you are taking the device apart. I also get that forgetting to assign the TuyaMCU to a dummy pin has the same problem, but I find remembering to make sure the pins are correct is more intuitive then looking at the Startup Command or the autoexec.bat. Especially when I am trying to access a device that is continually turning on and off.

    It was a bit of a learning curve which I think other new users can be saved if the driver is loaded automatically. How that would have been accomplished in other platforms is to assign the driver to a "dummy" pin. I mention the RX/TX (or just one) because we know they will never be used for anything else. I'm not actually saying use them in the driver. Just trigger driver loading.

    Having gone through the frustration of testing and pulling hair to figure out why all of a sudden my device is not accessible I use the "Startup Command" and NOT an autoexec.bat.

    So short answer, I think there is one main benefit:
    1) More resilient to firmware updates;
    - If you are using an autoexec.bat and it gets erase during a firmware update you will still be able to access the device through the AP.

    You already have drivers load based on assignment to a pin, so I figured adding the functionality would be simple. Add TuyaMCU to the pull down list and if it is assigned load the driver.

    Just a thought.
  • #40 21792464
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14493
    Help: 651
    Rate: 12502
    protectivedad wrote:

    I get it. You need other stuff for it to function properly, but without the driver loading you can't get access to the battery device without taking it apart.

    That's surely a new information. As far as I tested, I can keep up battery device AP or STA alive longer by pressing pair button many times, but I checked it in BK7231T/BK7231N era, when there was no sign of BK7238. Did something change, can you elaborate?
    Helpful post? Buy me a coffee.
  • #41 21792473
    protectivedad
    Level 9  
    Posts: 40
    Help: 2
    Rate: 5
    p.kaczmarek2 wrote:
    That's surely a new information. As far as I tested, I can keep up battery device AP or STA alive longer by pressing pair button many times, but I checked it in BK7231T/BK7231N era, when there was no sign of BK7238. Did something change, can you elaborate?


    That's interesting. I don't think it has anything to do with the WiFi module, but the TuyaMCU implementation. I have only one type of TuyaMCU device. With my devices if the TuyaMCU has not communicated with the WiFi module (no heartbeat/product id) it will turn off and back on the WiFi module. Pressing the button (I tried it many times) will keep the TuyaMCU on, but the TuyaMCU will still turn the WiFi module on and off. Annoyingly, it leaves it on long enough that the AP looks solid, but the phone/computer will say can't connect. Only after I hooked up a voltmeter to the WiFi module power pins did I find out the TuyaMCU was cycling the power.

    When the driver runs it will send a heartbeat or ask for product information and at that point the TuyaMCU will start flashing the device LED and pressing the button will keep it alive. With my device holding it for 5+ seconds cause the TuyaMCU to keep the WiFi module powered for a while, but ONLY if the WiFi module has already sent a heartbeat/product ID request.

    I assumed they were all like that, but obviously not. I wonder if that is leading to some frustration on people trying to test the battery operated devices.

    So to test stop the driver from loading and see if the device LED flashes on a boot. Mine won't. Allow the driver to start and it will.
  • ADVERTISEMENT
  • #42 21793333
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14493
    Help: 651
    Rate: 12502
    Then why not use short startup command? In both cases it will be in two places...

    Adding THIRD place that can start TuyaMCU will only confuse people even more.
    Helpful post? Buy me a coffee.
  • #43 21793343
    protectivedad
    Level 9  
    Posts: 40
    Help: 2
    Rate: 5
    p.kaczmarek2 wrote:
    Then why not use short startup command? In both cases it will be in two places...

    1) More elegant.
    2) Reduces the learning curve for new users used to Tasmota, like me.
    3) TuyaMCU detection and pin assignment can be added to GUI flasher again it is consistent with what the flasher already does.
    4) More efficient, reading a pin takes less resources than parsing a command.
    5) Documentation, you are documenting in the modules screen the pin is being used by the driver and you get double duty by using that to load the driver.

    p.kaczmarek2 wrote:
    Adding THIRD place that can start TuyaMCU will only confuse people even more.

    It's just a preference people used to looking in the modules page will put it there. People used to the startup will put it there. The idea is to automate the transition from the factory firmware to the use of OBK with as little chance to cause problems.

    The GUI flasher reads a device and assigns pins for most devices. The pin assignments cause drivers to automatically load. Why not try to make the TuyaMCU process as close to that as possible.

    Anyway, I think it will save people trouble let me know if you'd like me to close the https://github.com/openshwprojects/OpenBK7231T_App/pull/1919
  • #44 21793418
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14493
    Help: 651
    Rate: 12502
    Maybe... I didn't made final decision yet. One of the things I've been thinking about is adding live tuyamcu dpIDs preview to obk main http page.
    Helpful post? Buy me a coffee.
  • #45 21800902
    protectivedad
    Level 9  
    Posts: 40
    Help: 2
    Rate: 5
    p.kaczmarek2 wrote:
    One of the things I've been thinking about is adding live tuyamcu dpIDs preview to obk main http page.


    My use of the devices is to post to a MQTT broker. Anything that slows that down is counter to how I use the devices. I have been optimizing for my device and doing extensive timing testing. By making code optional through obk_config defines and some rearranging I have the TuyaMCU driver loading in 230 ms (initial product information is received in 340 ms), the startup command runs in 400 ms, connect to WiFi i 660 ms, connect to the MQTT broker in 1.4 s and post the pin change in 1.5 s. I think it can be made even faster if I could find an interface callback to run the initial MQTT connect.
  • #46 21800944
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14493
    Help: 651
    Rate: 12502
    That's interesting, what were the original timings? It could make a good separate tutorial - optimizing obk?
    Helpful post? Buy me a coffee.
  • Helpful post
    #47 21801342
    protectivedad
    Level 9  
    Posts: 40
    Help: 2
    Rate: 5
    p.kaczmarek2 wrote:
    That's interesting, what were the original timings?


    All tests are done with static IP assignment and IP address for MQTT broker.

    Without any flags:
    Start Command runs and loads driver 560 ms, first message from TuyaMCU 1.7 s, connect to WiFi in 9.2 s, MQTT connect 9.6 s pin published 10.77 s

    With Flag 37:
    Start Command runs and load driver 636 ms, first message from TuyaMCU 1.8 s, connect to WiFi in 1.8 s, MQTT connect 2.7 s pin published 3.8 s

    With Flag 37 and 51:
    Start Command runs and load driver 632 ms, connect to WiFi in 1.1 s, MQTT connect 1.7 s, first message from TuyaMCU 1.8 s pin published 2.8 s

    I still think ~3s is too long. That's enough time for someone to remove the batteries and the MQTT broker would have no idea what went on.

    For those interested I've post:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1939

    I also added tuyaMcu_sendProductInformation to the startup command which gets the TuyaMCU ready for sending information ahead of time.

    Times are:
    Start Command runs and load driver 632 ms, first message from TuyaMCU 740 ms, connect to WiFi in 1.1 s, MQTT connect 1.7 s, pin published 1.8 s

    The PR allows the MQTT broker to connect and then continue and process MQTT message in the same loop. Saving 1 s in the boot sequence.
  • #48 21802624
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14493
    Help: 651
    Rate: 12502
    I saw also you did Allow MQTT connection and processing in one every second iteration change. If it works, then it's a great addition! Hopefully it's stable. I'd love to merge it.
    Helpful post? Buy me a coffee.
  • #49 21805176
    protectivedad
    Level 9  
    Posts: 40
    Help: 2
    Rate: 5
    p.kaczmarek2 wrote:
    Maybe... I didn't made final decision yet. One of the things I've been thinking about is adding live tuyamcu dpIDs preview to obk main http page.


    I just realized how great this might be. I'm like the regular mail I may be slow, but I get there eventually. :)

    I had enough autoexec.bat creation and tuning in the 1980's with DOS. I really don't need to go back to that. You mentioned a good point about the driver if you have to link the dpID to channel in the startup command what's the problem with adding a startdriver? But of course I was stuck in the idea that dpID to channel to MQTT was the way it had to go. It doesn't of course. Channels can be dynamically created from dpID for posting to MQTT. Just like the battery driver posting directly to the website and publishing to MQTT voltage/get and battery/get, the TuyaMCU could do the same with dpID/get. Those who want can name there dpIDs to a channel number or name or whatever. But for those who don't want to create bat files, etc, they don't have to.

    Ideas?
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion provides a comprehensive guide on configuring TuyaMCU devices for cloudless operation with Home Assistant (HA). It emphasizes starting with research on the TuyaMCU protocol and official documentation before flashing devices, as some dpID extraction methods require unflashed devices. Multiple methods to obtain dpID lists are mentioned, including unpacking factory firmware and using Tuya API responses. Channel mapping is critical: OpenBeken firmware supports up to 64 channels, and channel numbers above 99 are unsupported in the GUI, so dpIDs must be mapped to valid channel numbers. Users can assign any dpID to any channel, allowing flexible configuration. Custom channel types such as toggles, text fields, and enums are used to represent device functions like temperature, humidity, battery status, and power. There is interest in creating custom channel types for complex dp values, such as multi-byte raw data representing multiple variables, with requests for types like Voltage_div10, Current_div10, Power_div10, and Percent_div10. Battery-powered devices require special handling to keep Wi-Fi active for configuration, with suggestions including safe mode activation and long button presses. The guide includes sample autoexec scripts demonstrating dpID-to-channel mapping and channel type assignments. The discussion also references tools like TuyaMCUAnalyzer and OpenBeken firmware for device integration and customization.
Generated by the language model.
Today's popular

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