Yes. Just the Tuya firmware backup. If you're worried your files might contain WiFi credentials feel free to send to me directly. I can reset/sanitise with test network credentials.
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
mvz0209 wrote:alias FaltHeartbeats backlog setChannel 0 1; addChannel 10 1; delay_s 2; setChannel 0 0 addChangeHandler MissedHeartbeats > 4 FaltHeartbeats
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.
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]autoexec.bat. [#20874147]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]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]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]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]Temperature_div2 channels as generic entities, not a full climate model. One user saw the relay payloads reversed as `pl_on: