Can I flash the MOES BHT-002-GCLW v4 thermostat with OpenBK without damaging it, and what do I need to know first?
Yes — the device is based on TuyaMCU, and OpenBeken supports this class of BK7231N/TuyaMCU thermostats, but you must first identify and map the device’s dpIDs if you want the thermostat functions to work properly [#20744725] Before flashing, the UART connection to the MCU has to be broken; otherwise the firmware upload will not start [#20748515] The recommended approach is to capture TuyaMCU traffic on the original firmware, figure out which dpID controls which function, and then upload OBK and map those dpIDs to channels [#20744725][#20744898] In the thread, the user later confirmed the device was working with OBK after mapping dpIDs for on/off, eco mode, manual mode, temperatures, and relay state, and reported stable operation with Home Assistant [#20748861][#20874147]
I purchased a MOES BHT-002-GCLW version v4 thermostat hoping to upload Tasmota. It turned out that there is a TUYA CB3S BK7231N chip inside.
With the BK7231Flasher program I read the contents (details attached), having previously soldered out the two components marked in red in the picture, without this it did not work.
The thermostat is managed by the MCU from the picture below:
Question to the experts: can I sflash this device with OpenBK software without dire consequences ?
Thank you and regards tomik67
Attachments:
MOES_BHT-002-GCLW_v4.txt(15.66 KB)
You must be logged in to download this attachment.
This device is based on TuyaMCU. OpenBeken supports devices with TuyaMCU at a fairly good level, but you need to know the dpID of the variables you want to support. Then again, it's the same with Tasmota. Without knowing which dpID is which variable you won't get started. This topic about TuyaMCU: https://www.elektroda.pl/rtvforum/topic3880546.html
You need to either find the documentation of this device e.g. for Tasmota (maybe the dpIDs match the version on BK), or on the dev account of Tuya approach what dpIDs are there (I've never done it this way, but it was mentioned on the forum) or capture the dpID e.g. with my analyzer: https://github.com/openshwprojects/TuyaMCUAnalyzer
Then in OpenBeken you map dpID to channels and script anything you want.
If you haven't already flashed, I advise you to do so: 1. solder everything in place 2. connect to Tuya application 3. while disconnected from mains power, only supplying from safe 3.3V or there 5V (before LDO), perform in UART (on U1TX and U1RX of WiFi module) packet capture at separate operations e.g.. temperature setting, relay switching on, etc. so that you can determine which dpID is the relay, which dpID is the temperature - you can analyze the packets in TuyaMCUAnalyzer 4. once you capture these packets and know which dpID is which variable, you can upload OBK and I will help you configure it
I see that in this code there are mentions of dpID and of TuyaMCU, even there are fragments of packages in the commentary (55 AA etc), but I have not yet found there a list of all the dpID from this device. Maybe you know where it is there? And if not, you need to capture the packets and that will do too....
From their project on which I also shared my misery, I received this response today:
Quote:
OpenBeken runs on BK7231 (and BL602, and W800, and W600, and more....) and supports TuyaMCU well in a scriptable and customizable manner, we can also have custom pages hosted on OBK LittleFS, so it should be possible to support it easily.
Today I had some time so I eavesdropped on what is happening on RXD1 and TXD1 of the BK7231N module, the details are attached. In the files at the bottom there is also communication right after powering up the thermostat.
Unfortunately, neither on RXD1 nor TXD1 did I find any trace of the relay on/off commands, nor its current state, I suppose that such communication takes place only between the MCU and the relay board without the participation of the BK7231N. Are we closer to solving the problem ?
PS. Additional information The capture results partially agree with this table : Link
55 AA 00 1C 00 08 0117091913010B01 7D
HEADER VER=00 Date LEN bOk=1 23/9/25 19:1:11 CHK
55 AA 00 1C 00 08 0117091912000201 72
HEADER VER=00 Date LEN bOk=1 23/9/25 18:0:2 CHK
55 AA 00 1C 00 08 0117091911003401 A3
HEADER VER=00 Date LEN bOk=1 23/9/25 17:0:52 CHK
Confirm no relay status, even the TUYA application relies on comparing the desired temperature vs. the actual temperature, it happens that in the application switching every 0.5 degree the contactor is supposedly off, and in fact on the thermostat is still on due to the Deadzone Temperature set, here they also write about it: Link
1 -. enable-disable 2 - doubled target temperature 3 - doubled current temperature (internal or external sensor it regard to your settings on device) 4 - 0 - auto mode; 1 - hand mode 5 - eco mode 6 - input blocking 102 - doubled current temperature of external sensor 104 - dont know. always "true" for me
PS3. However, it is possible to obtain the relay state by modifying the hardware and firmware of the module .: Link While the hardware mod I can grasp (voltage divider and passing 3.3V to CB3S on P7 or P8), the firmware modification (pushing GPIOP_7 or GPIOP_8 state as dpID) I will not undertake due to lack of such skills.
Attachments:
TXD1_MOES BHT-002-GCLW_v4.txt(15.09 KB)
You must be logged in to download this attachment.
RXD1_MOES BHT-002-GCLW_v4.txt(8.59 KB)
You must be logged in to download this attachment.
Based on this, you could already create OpenBeken configurations. You can make a copy of the original batch and upload OBK. Too bad there is no relay exposed to dpID, but are you sure? I see in the quote hand mode , what is it based on?
No problem, you can outside the MCU use the free GPIO for this, then you don't need dpID at all.
Unfortunately there is definitely no relay exposed to dpID in this model, they elaborate on this in the link I provided in the last post, so hardware and firmware modification is necessary. I would love to play with this mod so being able to use this outside of the MCU would make me very happy.
Hand mode (Manual mode) dpID 4, V=1 Manually set the expected (desired) temperature on the thermostat Auto mode (Programmable mode) dpID 4, V=0 Using pre-scheduled heating time and temperature intervals
There is also ECO mode, (Energy saving) dpID=5 Bool V=1 (ON), dpID=5 Bool V=0 (OFF) that is, energy saving mode, activates the default expected heating temperature of 20 *C, but it can be modified.
Included is the instruction manual EN.
Attachments:
BHT002_PL.pdf(2.27 MB)
You must be logged in to download this attachment.
Received by WiFi module: to prawdopodobnie zassanie z serwera TUYA programów grzania, 6 przeziałów czasowych w dni pracujące, 6 w sobotę i 6 w niedzielę.
55 AA 01 07 00 3A 65 00 00 36 190F2601081B1D0B1E1E0D2200112C00161E0006280008281E0B281E0D2800112800161E0006280008281E0B281E0D2800112800161E 30
HEADER VER=01 State LEN dpId=101 Raw V=19 0F 26 01 08 1B 1D 0B 1E 1E 0D 22 00 11 2C 00 16 1E 00 06 28 00 08 28 1E 0B 28 1E 0D 28 00 11 28 00 16 1E 00 06 28 00 08 28 1E 0B 28 1E 0D 28 00 11 28 00 16 1E CHK
Do you need support for this data format and is the meaning of each byte known?
It seems to me that these variables could be ignored because if we integrate such a thermostat with Home Assistant and say goodbye to the TUYA servers, we set the applicable heating schedule in HA. The only hassle would be power outages, HA would have to periodically push out info about the expected state of the thermostat (or thermostat request) because I'm not sure if it remembers the last state before the power outage (without contacting TUYA), I would have to check. Without this, the update would only occur during the next schedule change or after a manual adjustment. I assume that without receiving these variables, the default schedule remains in it and HA will take care of the rest. Do I think correctly ?
From OBK you can send variables to the thermostat at any time. In the same way, if you correctly pin in, you could try a three-state control of the relay: - forced high state - forced low state - acquiescent control of TuyaMCU over the relay But I didn't have this device, so I won't give a guarantee either. I think that if we know the dpID then you can try to upload in OBK and write autoexec.bat
Make a copy of the batch, upload OBK, and specify what baud is used here (9600 or the 115200 one?).
The mod is only to control the presence of the supply voltage to the coil of the relay, and this real and not simulated state is important for further automation of the device. Through the mod we can not control the relay. Only commands to the MCU. I don't know what the actual speed is, in the CH340G controller I have it set to 115200, in the file downloaded from the thermostat it says baud 9600 (I think it's the same as in the CB3S specification) and in the BK7231 Flasher it's set to 921600 and that's how it worked for me.
Chaos... Flashing speed is a different thing than communication with TuyaMCU. I was asking about what you set as you captured packets. But it doesn't matter much, upload OBK and fire up autoexec.bat, for a test:
I'm trying to upload OBK but it won't start, I guess I'll have to solder these two components again.
I succeeded but after re-soldering the components Now they are back in place. These commands I fired in Execute custom command, is that right or were they supposed to be in Startup command ? First logs attached.
Attachments:
first_log.txt(7.97 KB)
You must be logged in to download this attachment.
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 03 02 00 04 00 00 00 28 40
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 3, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 40
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 3 with value 40 is not mapped
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 66 02 00 04 00 00 00 F8 73
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 102, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 248
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 102 with value 248 is not mapped
# Po trzykrotnym zwiększeniu temperatury na panelu.:
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 02 02 00 04 00 00 00 30 47
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 48
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 2 with value 48 is not mapped
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 02 02 00 04 00 00 00 31 48
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 49
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 2 with value 49 is not mapped
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 02 02 00 04 00 00 00 32 49
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 50
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 2 with value 50 is not mapped
# Zmiany temperatury od 5*C do 35*C co pół stopnia.:
Type Val, Values min=10 max=67
Received by WiFi module:
55 AA 00 06 00 08 020200040000000A 1F
HEADER VER=00 SetDP LEN dpId=2 Val V=10 CHK
Received by WiFi module:
55 AA 00 06 00 08 020200040000000B 20
HEADER VER=00 SetDP LEN dpId=2 Val V=11 CHK
10 corresponds to 5C, and 11 is 5.5C? I have not encountered this yet, I will add to the firmware of this support immediately.
Yes, here these values are doubled temperature. This is certainly a silly question but since I have with OBK as well as with Tasmota only the first experience, where should I enter these commands ?.
It looks like the MCU needs to be informed of the current time every hour, the manually set clock resets after this period. With the original software it looks like this: RAW.:
Sorry for the slow response, sometimes it's hard to grasp the whole forum. I see you handled that, yes?
There is still a command to send the time "on demand" from the script, but I don't think that's needed, because the firmware also sends the time itself when TuyaMCU asks for it.
What else is needed? Do I need to prepare some missing GUI for the dpID from this thermostat?
Quote:
While locking works, Manual/Programmable Mode does not. Maybe because of the variable type "Enum".
When mapping, you can set the enum type, then the enum value will go to the channel (and back).
Thank you for your response, I realize that the topic is growing and there is not enough day for everything, so I am very grateful to you for your help so far, I am educating myself hard and I miss a lot. I am not a programmer but an electronics technician, but with automation in various forms (SATEL, Fibaro, etc.) I have been dealing with for many years, this topic is the next step.
If I could have a small wish list then I testify to the following:
1. Manual/Programmable Mode works as I mentioned in one of the last posts, it was necessary to update the clock, then it went off. 2. It would be nice to be able to implement summer/winter time, I found that in Tasmota it is done like this.:
It would be smart to have something similar, it would save manual adjustment in each thermostat (and other devices) when changing the time.
3. In one of the posts treating Tasmota in previous versions of the thermostat there was a reference to the instability of WiFi connections with b/g/n standards, the way out of the situation was to force communication only b/g, no n.
I also have blackouts once an hour, perhaps because of this, it looks like this:
Info:NTP:Seconds since Jan 1 1900 = 3905648534
Info:NTP:Unix time : 1696666934
Info:NTP:Local Time : 2023/10/07 08:22:14
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:Seconds since Jan 1 1900 = 3905648666
Info:NTP:Unix time : 1696667066
Info:NTP:Local Time : 2023/10/07 08:24:26
4. You once mentioned that:
Quote:
Check if it works what I gave. And now I think I need to add a special channel type under this device. Do I see correctly: Code: text Expand Select all Copy to clipboard
# Temperature changes from 5*C to 35*C in half degree increments.: Type Val, Values min=10 max=67
Received by WiFi module: 55 AA 00 06 00 08 020200040000000A 1F HEADER VER=00 SetDP LEN dpId=2 Val V=10 CHK
Received by WiFi module: 55 AA 00 06 00 08 020200040000000B 20 HEADER VER=00 SetDP LEN dpId=2 Val V=11 CHK
10 corresponds to 5C, and 11 is 5.5C? I haven't encountered this yet, I'll add support for this to the firmware right away.
Point 4. - is this type of channel under the native GUI for this temperature to be read-only (just convert to C and show), or is it to be something that also allows you to set this temperature from the GUI?
What about the rest I'll think about, 3. requires checking whether we have such an option at all in the SDK on which we rely.
As for pt. 4.: As for me, changing the temperature in the GUI is not necessary, it can be done manually while being at the thermostat, the GUI is rarely used on a daily basis. What is important, however, is the ability to receive commands to change the temperature setpoint (and other switches) via MQTT from HA and convert to understandable numbers for the thermostat.
I forgot to add two more points:
5. Relay status - since this thermostat does not report relay status, I added a wire to the pin 14 P7 I/O GPIOP_7, which corresponds to P7 of the IC, PWM 1 a wire on which if the relay is on, there is a voltage of 3.25V, when off there is no voltage. It would be great to send information over MQTT about a change in the state of the relay (and possibly a light - indicator in the GUI). In one case I soldered a wire to 13 P8 I/O GPIOP_8, which corresponds to P8 of the IC, PWM 2 , because through inattention while soldering I got rid of the solder pad on P7
6. Would it be possible to apply an additional function in the form of a flag that would cause after a restart or restoration of power and communications to send queries about switch states and temperature settings to the HA? I know that there is an option via -1 to keep the settings from before the restart, but during the power outage something could have changed in the HA and only the next command would give changes in the thermostat. With debugging, the thermostat would be up to date right away. Is this kind of debugging practiced at all?
As for me, changing the temperature in the GUI is not necessary, it can be done manually while being at the thermostat, the GUI is rarely used on a daily basis. What is important, however, is the ability to receive commands to change the temperature setting (and other switches) via MQTT from HA and convert it to understandable numbers for the thermostat.
All that is on the channels is published, as far as I know. Worse, for now it's in the form without multiplication, although it would probably be possible to script multiplication as well. Although, for example, in OnChannelChange publish multiplied.
Where number 5 is the channel with temperature. Multiplication to be corrected.
Similarly, whatever you send to OBK on the channel through the set topic, it will go to TuyaMCU. Automatically.
tomik67 wrote:
5. Relay status - since this thermostat does not report relay status, I added a wire to pin 14 P7 I/O GPIOP_7, which corresponds to P7 of the IC, PWM 1 a wire on which if the relay is on there is a voltage of 3.25V, when off there is no voltage. It would be great to push out info over MQTT about relay state change (and possible indicator light - indicator in GUI).
Set the free channel to ReadOnly type (I guess, but you could give a better one too), give it RelayState label, and set the selected GPIO to dInput (or dInput_noPullUp, depends).
tomik67 wrote:
6. Would it be possible to apply an additional function in the form of a flag that would cause after a reboot or restoration of power and connectivity to send queries about switch states and temperature settings to HA ? I know that there is the possibility of -1 to keep the settings from before the restart, but during the power failure in the HA something could have changed and only the next command would give the changes in the thermostat. Are such ways of querying practiced at all ?
I'm not sure what it is about yet, but in autoexec.bat you can add anything like this:
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 03 02 00 04 00 00 00 2A 42
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 3, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 42
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 3 with value 42 is not mapped
...or at least there is nothing about it in the logs.
✨ The discussion centers on uploading OpenBK firmware to the MOES BHT-002-GCLW v4 thermostat, which contains a TUYA CB3S BK7231N WiFi module and a separate MCU managing the relay and sensors. Users confirmed that OpenBK supports TuyaMCU devices but requires knowledge of device-specific dpIDs to map variables correctly. The thermostat’s relay status is not exposed via dpID, necessitating hardware modification by wiring the relay coil voltage to a free GPIO pin for accurate relay state reporting. Communication occurs over UART at a non-standard baud rate (38400 or 34800), with some devices requiring desoldering or voltage level adjustments for proper flashing and MCU communication. The OpenBK autoexec.bat script is used to configure channels, map dpIDs, start drivers (TuyaMCU, NTP), and set WiFi state to paired (defWiFiState 4). Users integrated the thermostat with Home Assistant (HA) via MQTT, facing challenges such as inverted relay state reporting and temperature scaling (values divided by 2). Solutions include custom YAML configuration for HA, channel type adjustments (toggle_inv, read-only), and scripting for temperature setpoint commands with multiplication factors. The MCU occasionally freezes, requiring hardware resets; users implemented MCU reset via GPIO or power cycling using optocouplers or MOSFETs. A new OpenBK feature tracks missed heartbeats to trigger automatic MCU resets. Time synchronization via NTP is essential for correct thermostat operation, with suggestions to implement automatic daylight saving time adjustments. The community shared firmware backups, dpID lists, and scripts to improve stability and integration. Some users noted that original Tuya firmware is more stable, and freezing issues may stem from MCU firmware or hardware faults. Overall, OpenBK firmware provides stable operation and flexible integration with HA after proper configuration and occasional hardware modifications. Generated by the language model.
TL;DR: With dpIDs 1, 2, 3, 4, 5, 6, 101, and 102 identified and the UART path restored after flashing, this OpenBK workflow solves MOES BHT-002-GCLW v4 setup for Home Assistant users. One maintainer summed it up: "make a copy of the batch, upload OBK"—but only after packet capture and correct autoexec ordering. [#20768815]
Why it matters: This thread turns a risky BK7231N thermostat flash into a repeatable OpenBK, TuyaMCU, and Home Assistant integration path.
Variant
Wi-Fi module
Typical UART/Tuya notes
Main risk from thread
BHT-002-GCLW v4
CB3S / BK7231N
TuyaMCU over UART, usually 9600 baud
Must break MCU-UART path for backup/flash
Earlier BHT-002
TYWE3S / ESP8266
Existing ESP thermostat projects exist
Different firmware path
Some WHT/BHT revisions
WB3S
Some boards use 5 V MCU-UART levels
May need voltage divider and different wiring
Key insight: OpenBK works on this thermostat when you treat it as a TuyaMCU device, not a direct-relay device. The flash itself is only half the job; dpID discovery, correct channel mapping, and script order determine whether controls work after reboot.
Quick Facts
The thermostat reported these working dpIDs in the thread: 1 power, 2 target temperature, 3 current temperature, 4 manual/program mode, 5 ECO, 6 button lock, 101 schedule raw, 102 floor or external temperature. [#20774147]
Temperature values are doubled: 10 = 5.0°C, 11 = 5.5°C, and the usable setpoint range shown was 5°C to 35°C in 0.5°C steps. [#20748861]
A working relay-state hardware mod used a free CB3S GPIO to sense about 3.25 V when the relay coil was energized and 0 V when off, because this thermostat does not expose real relay status by dpID. [#20761670]
The maintainer later added MissedHeartbeats handling; one tested reset rule triggered when missed heartbeats became greater than 4, then pulsed a reset channel for 2 seconds. [#21330239]
For one alternate thermostat board, TuyaMCU traffic was captured at 38400 baud on UART2, while the earlier CB3S/WB3S-backed BHT thread repeatedly referenced 9600 baud TuyaMCU communication. [#21253455]
How do I flash OpenBeken onto a MOES BHT-002-GCLW v4 thermostat with a TUYA CB3S BK7231N module without breaking TuyaMCU communication?
Yes—flash it as a TuyaMCU device, but restore the MCU-UART path afterward. 1. Back up the original CB3S firmware before writing OpenBK. 2. Temporarily break the MCU UART connection so BK7231 flashing tools can talk to the module cleanly. 3. After flashing, resolder the removed parts, boot OpenBK, start TuyaMCU, set tuyaMcu_defWiFiState 4, and verify dpIDs in the log. The thread showed OpenBK booting only after the removed components were soldered back, because TuyaMCU communication needed the original path restored. [#20748487]
What is TuyaMCU, and why do dpIDs matter when configuring a MOES BHT-002 thermostat with OpenBK or Tasmota?
"TuyaMCU" is a serial control protocol layer that lets a Wi-Fi module exchange typed data points with a separate thermostat MCU, using numbered dpIDs for each function. dpIDs matter because OpenBK and Tasmota cannot map power, temperature, ECO, or mode controls until each function’s dpID is known. The maintainer stated that without knowing which dpID matches which variable, you will not get started. On this thermostat, that meant capturing UART traffic before building the final OpenBK mapping. [#20744725]
Which dpIDs are used by the MOES BHT-002-GCLW thermostat for power, target temperature, current temperature, ECO mode, button lock, and manual/program mode?
The working map was: dpID 1 = power, 2 = target temperature, 3 = current temperature, 4 = manual/program mode, 5 = ECO mode, and 6 = button lock. The thread later confirmed 101 as the heating schedule raw block and 102 as external or floor temperature. For mode, the thermostat used dpID 4 enum, with 0 = programmable/auto and 1 = manual. These values were confirmed through captures, logs, and a final shared autoexec.bat. [#20874147]
What is the safest way to capture TuyaMCU UART packets on a MOES thermostat before flashing OpenBK?
The safest method is to capture packets while the thermostat still runs original firmware and is powered only from a safe low-voltage bench supply. 1. Resolder the UART path and pair the thermostat with the Tuya app. 2. Power the board from 3.3 V, or 5 V before the LDO, with mains disconnected. 3. Listen on the Wi-Fi module’s U1TX/U1RX during actions like setpoint changes or relay events, then decode the packets in TuyaMCUAnalyzer. That approach lets you identify dpIDs before flashing and avoids guessing. [#20744725]
Why do I need to disconnect or desolder the UART path to the MCU before backing up or flashing a CB3S/WB3S module?
You need to do it because the MCU shares the serial lines and interferes with the flashing session. The thread explicitly notes that firmware upload required the UART connection to the MCU to be broken first, and one user had to remove two nearby parts before BK7231 readout worked at all. After flashing, those parts were soldered back so TuyaMCU communication could resume. If you skip this, backup reads can fail with CRC or communication errors, and OpenBK may flash but not boot correctly with the thermostat logic. [#20748515]
Where should OpenBK TuyaMCU mapping commands be placed on this thermostat, and how do I build a working autoexec.bat file?
Place the TuyaMCU startup and channel mapping commands in autoexec.bat, not only in one-off command execution. A working file started NTP and TuyaMCU, set tuyaMcu_defWiFiState 4, declared channels 1 to 9, and linked dpIDs with linkTuyaMCUOutputToChannel, including 1 bool 1, 5 bool 2, 6 bool 3, 4 enum 4, 3 val 6, 2 val 7, 102 val 8, and 101 raw 9. That file became the stable baseline later shared for Home Assistant use. [#20874147]
Why did the ON/OFF command only start working properly after reboot when the channel mapping was moved before waitFor NTPState in autoexec.bat?
It started working because waitFor NTPState 1 delayed channel creation until after the MCU had already sent its initial state. When mapping came late, OpenBK missed the first dpID values, so the power channel was not initialized correctly after reboot. The maintainer identified this ordering bug and advised placing mapping first, or removing waitFor entirely. After that change, the user reported that ON/OFF and other functions worked immediately after reboot. [#20768969]
How can I map doubled temperature values on the MOES BHT-002 to OpenBK Temperature_div2 channels and Home Assistant MQTT topics correctly?
Map the thermostat’s value dpIDs to Temperature_div2 channels, then scale MQTT values in Home Assistant. In OpenBK, the working mapping was dpID 3 -> channel 6 for current temperature and dpID 2 -> channel 7 for target temperature. In Home Assistant YAML, the thread used current_temperature_template: '{{ float(value)*0.5|round(2) }}' and temperature_command_template: '{{ float(value)*2 }}'. That converts OpenBK channel traffic into real Celsius readings and sends the thermostat the doubled integer it expects. [#20874147]
What is Temperature_div2 in OpenBeken, and how does it convert the thermostat's doubled temperature values into real °C readings?
"Temperature_div2" is an OpenBeken channel type that stores a thermostat’s doubled integer temperature and presents it as a Celsius value divided by two, preserving 0.5°C steps. In this thread, 10 meant 5.0°C and 11 meant 5.5°C, so OpenBK needed a special type instead of a plain value channel. The maintainer added support after confirming this scale on the BHT thermostat, and later users showed it displaying correct temperatures in both the OpenBK GUI and Home Assistant. [#20748861]
How do I send time updates from OpenBK to a TuyaMCU thermostat and configure a custom NTP server for the MOES BHT-002?
Start the NTP driver, set your server, and let OpenBK feed time to the MCU. The working example used startDriver NTP, ntp_setServer 10.9.10.250, and ntp_timeZoneOfs +2:00. The thermostat’s MCU asked for time about hourly, and a user confirmed that a manually set clock reset after roughly 1 hour if no update arrived. The maintainer also noted that OpenBK can send time on demand from script, but regular NTP plus TuyaMCU time handling was enough for normal operation. [#20761117]
Why does Home Assistant Discovery show the relay state inverted or create a read-only temperature entity for this thermostat, and how can I fix it with manual YAML?
It happens because Discovery treats this thermostat’s relay-state and Temperature_div2 channels as generic entities, not a full climate model. One user saw the relay payloads reversed as `pl_on:
