logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
UV printer on your desk?
UV printer on your desk? Discover eufyMake E1 »
ADVERTISEMENT
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

Uploading OpenBK software to MOES BHT-002-GCLW v4 thermostat with TUYA CB3S BK7231N chip

tomik67 22965 133
Best answers

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]
Generated by the language model.
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Report a violation of the law
Reply | New topic
  • #31 20762285
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    Some information is not published, it is such an optimization.

    You can change this behavior in the flags:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/flags.md
    Flag:
    Code: text Expand Select all Copy to clipboard
    [MQTT] Always publish channels used by TuyaMCU
    .
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 20762309
    tomik67
    Level 12  
    Posts: 111
    Rate: 11
    I enabled this flag and still no mention of MQTT, only the last line disappeared.
    Code: text Expand Select all Copy to clipboard
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 3 with value 42 is not mapped

    Could this be related to the fact that I do not have MQTT configured yet?
    If so, why in the case of this other change, however, the mention of MQTT publication is there?

    And another question, I have a bunch of such logs, are these attempts to publish / communicate MQTT ?:

    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 0 (Hearbeat) with 8 bytes
Info:MAIN:Time 442, idle 190061/s, free 74160, MQTT 0(28), bWifi 1, secondsWithNoPing 377, socks 2/38 
Info:MAIN:Time 443, idle 183271/s, free 74160, MQTT 0(28), bWifi 1, secondsWithNoPing 378, socks 2/38 
Info:MAIN:Time 444, idle 187831/s, free 74160, MQTT 0(28), bWifi 1, secondsWithNoPing 379, socks 2/38 
Info:MAIN:Time 445, idle 189711/s, free 74160, MQTT 0(28), bWifi 1, secondsWithNoPing 380, socks 2/38 
Info:TuyaMCU:TUYAMCU received: 55 AA 01 00 00 01 01 02 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 0 (Hearbeat) with 8 bytes
Info:MAIN:Time 446, idle 190004/s, free 74160, MQTT 0(28), bWifi 1, secondsWithNoPing 381, socks 2/38 
Info:MAIN:Time 447, idle 184056/s, free 74160, MQTT 0(28), bWifi 1, secondsWithNoPing 382, socks 2/38 
Info:MAIN:Time 448, idle 189605/s, free 74160, MQTT 0(28), bWifi 1, secondsWithNoPing 383, socks 2/38 
Info:MAIN:Time 449, idle 191359/s, free 74160, MQTT 0(28), bWifi 1, secondsWithNoPing 384, socks 2/38
    .
  • #33 20762528
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    If you don't have MQTT connected it changes the figure, a little strange that you report the problem that there is no publication on MQTT as there is no MQTT.... Connect MQTT and then check. Do a listen in HA and you will see what is published.

    What you show in the log has nothing to do with MQTT, it's just a cosecond message so that we know that everything is working and heartbeat messages TuyaMCU
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #34 20762575
    tomik67
    Level 12  
    Posts: 111
    Rate: 11

    Sorry if it looked like a problem report. It's more of a knowledge enhancement question as to why some things are in the logs and others aren't.
    Of course I'll check it after I run a broker or a listening program.
    Should each thermostat, if there are more in the same location, post in separate topics or create one common one?
    .
  • #35 20762593
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    As in Tasmot, the device name obviously has to be different, otherwise you won't be able to tell which is which. That is, short device name and long device name must be different. E.g. "BHT-Kitchen", "BHT-Bedroom", etc.

    If you want to have two thermostats in the same room and address them at the same time, then use the so called "BHT". group topic , by default it has the value bekens but you can change it to anything you want and thus get the effect that two different devices with different base topics will listen to an additional single, group, common topic
    Helpful post? Buy me a coffee.
  • #36 20762664
    tomik67
    Level 12  
    Posts: 111
    Rate: 11
    I experimented a bit and added the relay status, current temperature and expected temperature in the GUI.

    OpenBekenX application interface with control buttons and temperature information.
    Code: text Expand Select all Copy to clipboard
    // Start NTP Driver
startDriver NTP
// Set NTP Server
ntp_setServer 10.9.10.250
// Set timezone
ntp_timeZoneOfs +2:00
startDriver TuyaMCU
tuyaMcu_defWiFiState 4
waitFor NTPState 1
echo "NTP is ready"

setChannelType 1 toggle
setChannelLabel 1 OnOff
setChannelType 2 toggle
setChannelLabel 2 EnergySaving
setChannelType 3 toggle
setChannelLabel 3 ButtonLock
setChannelType 4 toggle
setChannelLabel 4 ManualMode
setChannelType 5 ReadOnly
setChannelLabel 5 RelayState
setChannelType 6 Temperature_div2
setChannelLabel 6 CurrentTemperature
setChannelType 7 Temperature_div2
setChannelLabel 7 SetTemperature
// linkTuyaMCUOutputToChannel dpId verType tgChannel
linkTuyaMCUOutputToChannel 1 bool 1
linkTuyaMCUOutputToChannel 5 bool 2
linkTuyaMCUOutputToChannel 6 bool 3
linkTuyaMCUOutputToChannel 4 enum 4
linkTuyaMCUOutputToChannel 3 val 6
linkTuyaMCUOutputToChannel 2 val 7
    Code: text Expand Select all Copy to clipboard
    // Start NTP Driver
startDriver NTP
// Set NTP Server
ntp_setServer 10.9.10.250
// Set timezone
ntp_timeZoneOfs +2:00
startDriver TuyaMCU
tuyaMcu_defWiFiState 4
waitFor NTPState 1
echo "NTP is ready"

setChannelType 1 toggle
setChannelLabel 1 OnOff
setChannelType 2 toggle
setChannelLabel 2 EnergySaving
setChannelType 3 toggle
setChannelLabel 3 ButtonLock
setChannelType 4 toggle
setChannelLabel 4 ManualMode
setChannelType 5 ReadOnly
setChannelLabel 5 RelayState
setChannelType 6 Temperature_div2
setChannelLabel 6 CurrentTemperature
setChannelType 7 Temperature_div2
setChannelLabel 7 SetTemperature
// linkTuyaMCUOutputToChannel dpId verType tgChannel
linkTuyaMCUOutputToChannel 1 bool 1
linkTuyaMCUOutputToChannel 5 bool 2
linkTuyaMCUOutputToChannel 6 bool 3
linkTuyaMCUOutputToChannel 4 enum 4
linkTuyaMCUOutputToChannel 3 val 6
linkTuyaMCUOutputToChannel 2 val 7
  • #37 20762750
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    When I find a moment I might try to make a better page under this config in REST API according to:
    https://www.elektroda.pl/rtvforum/topic3971355.html
    Okay, now test with MQTT. What are the next steps and what is missing (except for those "fatter" features what you mentioned in the above posts, summer/winter time type)?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #38 20762790
    tomik67
    Level 12  
    Posts: 111
    Rate: 11
    I also played around with sending tuyaMcu_sendState commands to change the temperature, for example tuyaMcu_sendState 2 2 40 sets the expected temperature to 20C, do I need to map the temperature values somehow ?
    The next step will be to listen to MQTT what will appear in the published topic, I will see what I am missing.
  • #39 20762810
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    You have to multiply before sending. If you have already mapped the dpID to the channel, you might as well use setChannel or the theme with set , so even better, because tuyaMcu_sendState skips the channel.
    Helpful post? Buy me a coffee.
  • #40 20768797
    tomik67
    Level 12  
    Posts: 111
    Rate: 11

    I've been testing the thermostat's command behavior using the MQTT server for a few days now, and everything seems to work except for one interesting peculiarity.
    The ON/OFF command after a reboot seems to work only after one full cycle of sending the ON/OFF command, then it's fine until the next reboot. And this is true regardless of the settings in the Configure Startup tab.
    After a reboot, I poll the status with the GET command and it shows the ON status. I send the OFF command, the status after the poll points correctly to OFF, but the thermostat remains ON. I send the ON command again, the thermostat lights up as if it had just been turned on, and from then on the switch is already working correctly until the next reboot. It looks like the MCU needs to receive the ON command at least once to wake up the communication for this function. Curious.
  • #41 20768815
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    Hello, can you try in autoexec.bat to add a wait of a few seconds and then manually send there, for example, rigidly ON or OFF?
    Something like:
    Code: text Expand Select all Copy to clipboard
    
delay_s 5
setChannel 1 1
delay_s 1
setChannel 1 0

    Index of the channel to change, I do not know what you use. Documentation:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md

    The second option: yesterday we added TuyaMCU queueing support, if you feel like testing it let me know, in general you would have to do OTA to the latest version and then in flags enable TuyaMCU queue, the last flag, this is supposed to in theory increase the stability of TuyaMCU.
    Helpful post? Buy me a coffee.
  • #42 20768902
    tomik67
    Level 12  
    Posts: 111
    Rate: 11
    Putting a flag did not help with this affliction, I will leave it on for now to test.
    Below I paste the startup sequence from the logs, as the first is read ON/OFF, dpID 1 and at it and, however, also at dpID 4 (manual/programmable mode) instead of the value is square:

    Code: text Expand Select all Copy to clipboard
    Info:MAIN:Module reboot in 1...
00 01 01 10 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 1, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 02 02 00 04 00 00 00 2A 41 
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: 42
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
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 05 04 04 00 01 01 16 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 4, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 05 05 01 00 01 00 13 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 5, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 05 06 01 00 01 00 14 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 6, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 3A 65 00 00 36 19 0F 24 01 08 1F 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 32 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 65 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 101, dataType 0-DP_TYPE_RAW and 54 data bytes
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
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 05 68 01 00 01 00 76 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 104, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:MAIN:Time 5, idle 0/s, free 72104, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:TuyaMCU:TUYAMCU received: 55 AA 01 00 00 01 01 02 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 0 (Hearbeat) with 8 bytes
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MQTT:mqtt_userName 0000000
mqtt_pass 0000000
mqtt_clientID 0000000
mqtt_host 10.9.20.250:1883
Info:MAIN:Time 6, idle 56381/s, free 72656, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Boot complete time reached (5 seconds)
Info:CFG:####### Set Boot Complete #######
Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to Testowy/+/set
Info:MQTT:mqtt_subscribed to bekens/+/set
Info:MQTT:mqtt_subscribed to cmnd/Testowy/+
Info:MQTT:mqtt_subscribed to cmnd/bekens/+
Info:MQTT:mqtt_subscribed to Testowy/+/get
Info:TuyaMCU:TUYAMCU received: 55 AA 01 03 00 00 03 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 3 (WiFiState) with 7 bytes
Info:NTP:Seconds since Jan 1 1900 = 3906178364
Info:NTP:Unix time  : 1697196764
Info:NTP:Local Time : 2023/10/13 11:32:44
Info:MAIN:Time 7, idle 224397/s, free 72888, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:CMD:"NTP is ready"
Info:GEN:Channel 1 type changed to toggle
Info:GEN:Channel 2 type changed to toggle
Info:GEN:Channel 3 type changed to toggle
Info:GEN:Channel 4 type changed to toggle
Info:GEN:Channel 5 type changed to ReadOnly
Info:GEN:Channel 6 type changed to Temperature_div2
Info:GEN:Channel 7 type changed to Temperature_div2
Info:GEN:Channel 8 type changed to Temperature_div2
Info:GEN:Channel 9 type changed to ReadOnly


    Maybe the reading is too early ?.
  • #43 20768909
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    Thanks, you just made me realize that I had an error. This int should not be displayed as a stamp, but as a number.
    I posted a fix:
    https://github.com/openshwprojects/OpenBK7231...mmit/ae0329436f1db0110b34722fec7428927db203e3
    Sorry for the problem. Could you wait until the build is done and test everything again?

    From the latest version (the one that will appear in a few minutes or so) this 1 byte should already be displayed as a number, not as a signifier.
    Helpful post? Buy me a coffee.
  • #44 20768966
    tomik67
    Level 12  
    Posts: 111
    Rate: 11
    Sure I will test
  • #45 20768969
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    Only that this is only a cosmetic change. The channel values themselves will not be affected.

    Wait, I found the problem. After all, you have:
    Code: text Expand Select all Copy to clipboard
    
// Start NTP Driver
startDriver NTP
// Set NTP Server
ntp_setServer 10.9.10.250
// Set timezone
ntp_timeZoneOfs +2:00
startDriver TuyaMCU
tuyaMcu_defWiFiState 4
waitFor NTPState 1
echo "NTP is ready"


    After all, you perform waitFor before setting the channel mapping! That's why the original values are not mapped, because by waitFor you are already mapping them after TuyaMCU sends them. That's hardly what you want to do.

    I would suggest setting everything up at the beginning, and possibly waitFor give it to the end of the script, so as not to block it....

    Actually. you don't need this waitFor at all, it's not needed rather in your case, unless I don't know about something.
    Helpful post? Buy me a coffee.
  • #46 20769461
    tomik67
    Level 12  
    Posts: 111
    Rate: 11

    So far it looks good, after a reboot it works immediately ON/OFF and the other function, and it helped.


    Quote:
    You do waitFor before setting the channel mapping!


    Thank you. Testing continues.
  • #47 20769504
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    All in all, I don't know how the waitFor got there, but it's definitely a good idea to analyze the code you paste in, especially with regard to the order of operations.

    If you can, edit the previous posts of yours so that waitFor is commented out so that someone else doesn't copy it....
    Helpful post? Buy me a coffee.
  • #48 20769540
    tomik67
    Level 12  
    Posts: 111
    Rate: 11

    Wait for I found in some thread about OBK regarding cooperation with NTP servers, now I moved this command to the very end of the script.
    How to most advantageously add this thermostat to Home Assistant so that all switches and sensors appear at once?
    Will the proposed YAML code in the thermostat menu suffice?

    Code: text Expand Select all Copy to clipboard
    mqtt:
  binary_sensor:
  - unique_id: "OpenBekenX_C8263D_binary_sensor_5"
    name: 5
    state_topic: "Testowy/5/get"
    qos: 1
    payload_on: 1
    payload_off: 0
    retain: true
    availability:
      - topic: "Testowy/connected"
    .
  • #49 20769592
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    Unfortunately, this code from the view is not valid, it works only for relay/toggle.

    Either you need to write the yaml itself, or use fully automatic Discovery according to this guide:
    https://www.youtube.com/watch?v=pkcspey25V4&ab_channel=Elektrodacom
    Additionally, I think this temperature split into 2 is not plugged in, but check it and if something I will add.
    Helpful post? Buy me a coffee.
  • #50 20769709
    tomik67
    Level 12  
    Posts: 111
    Rate: 11

    I added the thermostat to HA, the temperature surprisingly shows correctly divided in half, but I have two problems:

    1. Inverted relay state.: (RelayState, Channel 5)

    Code: text Expand Select all Copy to clipboard
    {
  "dev": {
    "ids": [
      "OpenBK7231N_799F00054"
    ],
    "name": "obkN_799F00054",
    "sw": "1.17.273",
    "mf": "Beken Corporation",
    "mdl": "BK7231N",
    "cu": "http://192.168.110.43/index"
  },
  "name": "RelayState",
  "~": "BHT_B_gabinet",
  "avty_t": "~/connected",
  "pl_on": "0",
  "pl_off": "1",
  "uniq_id": "OpenBK7231N_799F00054_binary_sensor_5",
  "qos": 1,
  "stat_t": "~/5/get"
}


    On the configuration page of the thermostat the state shows correctly, in HA it is reversed, it should be on: 1, off: 0, where can I modify this config?.

    2. Channel 7 is used to send a request to set the expected temperature, in the config is GET and should be SET.:

    Code: text Expand Select all Copy to clipboard
    {
  "dev": {
    "ids": [
      "OpenBK7231N_799F00054"
    ],
    "name": "obkN_799F00054",
    "sw": "1.17.273",
    "mf": "Beken Corporation",
    "mdl": "BK7231N",
    "cu": "http://192.168.110.43/index"
  },
  "name": "Temperature",
  "~": "BHT_B_gabinet",
  "avty_t": "~/connected",
  "uniq_id": "OpenBK7231N_799F00054_temperature_7",
  "qos": 1,
  "dev_cla": "temperature",
  "unit_of_meas": "°C",
  "stat_t": "~/7/get",
  "stat_cla": "measurement",
  "val_tpl": "{{ float(value)*0.5|round(2) }}"
}


    Channel type to: Temperature_div2.
    I also question where to change it?

    PS. Channel Types temperature is missing which would allow not only reading but also sending values, just like Toggle:

    Code: text Expand Select all Copy to clipboard
      "stat_t": "~/1/get",
  "cmd_t": "~/1/set"



    I guess I missed any of the channel types that would meet such a condition.
  • #51 20770382
    tomik67
    Level 12  
    Posts: 111
    Rate: 11

    Do I have any possibility to change the values in the config files sent by Home Assistant Discovery or is it a complicated rummaging in the software?
  • ADVERTISEMENT
  • #52 20770390
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    Ad 1 - maybe the Toggle_Inv type will help?
    Ad 2 - I need to add a new type because Temperature_div2 is read only unfortunately now....
    Additional question: you can capture this YAML and paste it into configuration yaml and edit there as you wish, generally HA discovery is for simpler devices, for advanced users it is recommended to write yaml manually in configuration.yaml

    I will try tomorrow to add at least for temperature_div2 the ability to write to these types, I will think how.... temperature at this point is read-only because I haven't met a thermostat of this type before.
    Helpful post? Buy me a coffee.
  • #53 20770412
    tomik67
    Level 12  
    Posts: 111
    Rate: 11

    I'll try it out, except that toggle_inv will create a switch for me that will probably show up correctly in HA but will be reversed on the http page of the thermostat.
    I wonder if all switch/relay identifies correctly "pl_on": "1", "pl_off":"0" and binary_sensor vice versa "pl_on": "0", "pl_off": "1" .

    What about the temperature sensor, I am able to send a manual request from the MQTT server via
    Code: text Expand Select all Copy to clipboard
    BHT_B_gabinet/7/set
    with the expected temperature value and it works, the temperature changes.
    I would like to add the possibility of using the SET command but in the case of Temperature_div2 with multiplication of the value *2, because in the case of receiving the value is already beautifully implemented division
    Code: text Expand Select all Copy to clipboard
    "{{ float(value)*0.5|round(2) }}"


    The whole thing looks like this:

    Code: text Expand Select all Copy to clipboard
    {"dev":{"ids":["OpenBK7231N_799F00054"],"name":"obkN_799F00054","sw":"1.17.273","mf":"Beken Corporation","mdl":"BK7231N","cu":"http://192.168.110.43/index"},"name":"Temperature","~":"BHT_B_gabinet","avty_t":"~/connected","uniq_id":"OpenBK7231N_799F00054_temperature_7","qos":1,"dev_cla":"temperature","unit_of_meas":"°C","stat_t":"~/7/get","stat_cla":"measurement","val_tpl":"{{ float(value)*0.5|round(2) }}"}
    .
  • #54 20770441
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    Fact, I forgot that this relay is read only

    It can OpenClosed_Inv?
    Helpful post? Buy me a coffee.
  • #55 20770576
    tomik67
    Level 12  
    Posts: 111
    Rate: 11
    No change, it is also a kind of RelayState
  • #56 20770609
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    I don't think we understand each other.
    If you want to invert at the read stage (because you're polling the relay state with the input, right?) then you have a choice:
    - dInput
    - dInput_n
    See:
    Table showing digital input options and their descriptions.


    Analogously, if you want to swap payload_on and payload_off, then you choose the "inverted" channel type, e.g.:
    - Toggle
    - Toggle_inv
    Helpful post? Buy me a coffee.
  • #57 20857970
    lizi0
    Level 12  
    Posts: 201
    Rate: 19

    Gentlemen, as you say, hats off to you for your commitment and knowledge. I, on the other hand, am one of those who want but do not have the knowledge, and therefore the question to you is whether on this thermostat BHT-02 with TYWE3S on board, it is possible to throw, for example, SUPLE in which recently appeared just the functionality of the thermostat?

    If so, will flashing according to https://www.youtube.com/watch?v=imKZbhJ8lvU&ab_channel=digiblurDIY (only without pogopins) and Generic from supli work?
  • #58 20858068
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    I haven't checked Supli for this, and I don't know if they support TuyaMCU, but on ESP (TYWE3S) I think it can run this:

    tomik67 wrote:
    in earlier versions of this thermostat "sat" ESP8266 and two great designs were created:
    https://github.com/klausahrenberg/WThermostatBeca and an even more interesting fork:
    https://github.com/fashberg/WThermostatBeca
    .
    Helpful post? Buy me a coffee.
  • #59 20858581
    lizi0
    Level 12  
    Posts: 201
    Rate: 19

    Thank you for your reply and I remain waiting for further instruction.
  • #60 20859525
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14667
    Help: 656
    Rate: 12683
    Just make a copy of the TYWE3S batch and then try to upload it from their repo. After all, you can always restore the original soft. You won't mess anything up.
    Helpful post? Buy me a coffee.
Reply | New topic
Report a violation of the law

Topic summary

✨ 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.
Today's popular

FAQ

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:
Generated by the language model.
ADVERTISEMENT