logo elektroda
logo elektroda
X
logo elektroda

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

tomik67 12792 133
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
  • #31 20762285
    p.kaczmarek2
    Moderator Smart Home
    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:
    [MQTT] Always publish channels used by TuyaMCU
    .
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 20762309
    tomik67
    Level 12  
    I enabled this flag and still no mention of MQTT, only the last line disappeared.
    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 ?:

    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
    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.
  • #34 20762575
    tomik67
    Level 12  

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

    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
    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:
    
    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  
    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:

    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
    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.
  • ADVERTISEMENT
  • #44 20768966
    tomik67
    Level 12  
    Sure I will test
  • #45 20768969
    p.kaczmarek2
    Moderator Smart Home
    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:
    
    // 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  

    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.
  • ADVERTISEMENT
  • #47 20769504
    p.kaczmarek2
    Moderator Smart Home
    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  

    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?

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

    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)

    {
      "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.:

    {
      "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:

      "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  

    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?
  • #52 20770390
    p.kaczmarek2
    Moderator Smart Home
    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  

    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
    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
    "{{ float(value)*0.5|round(2) }}"


    The whole thing looks like this:

    {"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
    Fact, I forgot that this relay is read only

    It can OpenClosed_Inv?
    Helpful post? Buy me a coffee.
  • #55 20770576
    tomik67
    Level 12  
    No change, it is also a kind of RelayState
  • #56 20770609
    p.kaczmarek2
    Moderator Smart Home
    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  

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

    Thank you for your reply and I remain waiting for further instruction.
  • #60 20859525
    p.kaczmarek2
    Moderator Smart Home
    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.

Topic summary

The discussion revolves around uploading OpenBK software to the MOES BHT-002-GCLW v4 thermostat, which contains a TUYA CB3S BK7231N chip. Users share their experiences with flashing the device, including the need to identify dpIDs for proper functionality. The conversation highlights challenges such as the absence of relay status reporting, the necessity of mapping dpIDs to channels, and the importance of configuring the autoexec.bat file correctly. Users also discuss issues with the thermostat freezing and potential solutions, including using a MOSFET for power control and implementing a reset script. Additionally, there are inquiries about integrating the thermostat with Home Assistant and managing temperature settings through MQTT.
Summary generated by the language model.
ADVERTISEMENT