logo elektroda
logo elektroda
X
logo elektroda

[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight

morgan_flint 31497 241
ADVERTISEMENT
  • #211 21378297
    p.kaczmarek2
    Moderator Smart Home
    What sending of flags, what is it? Maybe there is something to correct.

    BatteryLevelPercent I will check in the Simulator right away and if there is seriously a bug I will fix it and upload the Release. Many people just do their Yaml because then there is 100% control over everything

    Ready channel settings - i.e. for the dpID of this device? My TH06 only offered humidity and temperature, no alarms, so I had no way to check that

    Added after 24 [minutes]:

    @GAAD added:
    
    setChannelType 2 BatteryLevelPercent
    setChannelLabel 2 MyBatteryABC
    
    .
    WinTest_3145CAFF diagnostic screen showing battery level at 67%, channel info, and MQTT status. .
    User interface of an application with device information and sensor status .
    Posted at:
    https://github.com/openshwprojects/OpenBK7231...mmit/3a1c3e9bbf6105e43d16653139a321a860de5207

    What is needed next? What else is missing?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #212 21379117
    GAAD
    Level 17  
    Generally, it is already ok.

    As for the rest, I think colleague @divadiow pasted the whole thing on the previous page
    I've experimented with these channels even started to configure them as read or text channels but it didn't really work out for me.

    
    {
      "1": {
        "name": "Temperature",
        "type": "obj",
        "mode": "ro",
        "trigger": "direct",
        "property": {
          "type": "value",
          "min": -200,
          "max": 600,
          "scale": 1,
          "step": 1
        }
      },
      "2": {
        "name": "Humidity",
        "type": "obj",
        "mode": "ro",
        "trigger": "direct",
        "property": {
          "type": "value",
          "min": 0,
          "max": 100,
          "scale": 0,
          "step": 1
        }
      },
      "3": {
        "name": "Battery level state",
        "type": "obj",
        "mode": "ro",
        "trigger": "direct",
        "property": {
          "type": "enum",
          "range": ["low", "middle", "high"]
        }
      },
      "4": {
        "name": "Battery level",
        "type": "obj",
        "mode": "ro",
        "trigger": "direct",
        "property": {
          "type": "value",
          "min": 0,
          "max": 100,
          "scale": 0,
          "step": 1
        }
      },
      "9": {
        "name": "Unit convert",
        "type": "obj",
        "mode": "rw",
        "property": {
          "type": "enum",
          "range": ["c", "f"]
        }
      },
      "10": {
        "name": "Set maxtemp",
        "type": "obj",
        "mode": "rw",
        "property": {
          "type": "value",
          "min": -200,
          "max": 600,
          "scale": 1,
          "step": 1
        }
      },
      "11": {
        "name": "Set minitemp",
        "type": "obj",
        "mode": "rw",
        "property": {
          "type": "value",
          "min": -200,
          "max": 600,
          "scale": 1,
          "step": 1
        }
      },
      "12": {
        "name": "Set maxhum",
        "type": "obj",
        "mode": "rw",
        "property": {
          "type": "value",
          "min": 0,
          "max": 100,
          "scale": 0,
          "step": 1
        }
      },
      "13": {
        "name": "Set minihum",
        "type": "obj",
        "mode": "rw",
        "property": {
          "type": "value",
          "min": 0,
          "max": 100,
          "scale": 0,
          "step": 1
        }
      },
      "14": {
        "name": "Temp alarm",
        "type": "obj",
        "mode": "ro",
        "property": {
          "type": "enum",
          "range": ["loweralarm", "upperalarm", "cancel"]
        }
      },
      "15": {
        "name": "Humidity alarm",
        "type": "obj",
        "mode": "ro",
        "property": {
          "type": "enum",
          "range": ["loweralarm", "upperalarm", "cancel"]
        }
      },
      "17": {
        "name": "Temperature report",
        "type": "obj",
        "mode": "rw",
        "property": {
          "type": "value",
          "min": 1,
          "max": 120,
          "scale": 0,
          "step": 1
        }
      },
      "18": {
        "name": "Humidity report",
        "type": "obj",
        "mode": "rw",
        "property": {
          "type": "value",
          "min": 1,
          "max": 120,
          "scale": 0,
          "step": 1
        }
      },
      "19": {
        "name": "Temp sensitivity",
        "type": "obj",
        "mode": "rw",
        "property": {
          "type": "value",
          "min": 3,
          "max": 20,
          "scale": 1,
          "step": 1
        }
      },
      "20": {
        "name": "Humidity sensitivity",
        "type": "obj",
        "mode": "rw",
        "property": {
          "type": "value",
          "min": 3,
          "max": 20,
          "scale": 0,
          "step": 1
        }
      }
    }
    


    It would be nice to complete:
    9 "Unit convert", this has already been tackled by colleague @smoeller95s
    10 "Set maxtemp",
    11 "Set minitemp",
    12 "Set maxhum",
    13 "Set minihum",
    14 "Temp alarm",
    15 "Humidity alarm",
    17 "Temperature report",
    18 "Humidity report",
    19 "Temp sensitivity",

    This would give the full functionality of the device and the convenience of configuration and, after all, we are reworking these devices not to lose but to gain. In most threads it is the case that if it works for someone, they write the rest either in OBK or in HA and no longer share it.
  • #213 21379148
    p.kaczmarek2
    Moderator Smart Home
    A lot of things like the alarm can be done in OBK itself, you don't have to do it on TuyaMCU, but if you need something I'll help. I can introduce new channels, and I'm also working on some more advanced options so that you can script the settings as you like. We already have an HTML Widgets system, so you can make any control you want, but it's probably too advanced for such a simple device....

    What was the problem with channels? You give a text field type then you can both receive and send. Unless you want to add a comma delimited text field type?

    Unit convert is supposed to be a radio button with two options?

    PS: Are you using the OBK simulator? It might be faster that way... for testing with HA
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #214 21379298
    GAAD
    Level 17  
    Do we stand a chance of something like this for example:
    
        visual:
          min_temperature: 10 °C      
          max_temperature: 30 °C      
          temperature_step: 0.1 °C
    
    switch:
      - platform: tuya
        name: "Power"
        icon: mdi:power
        switch_datapoint: 1           
        internal: True                
    
    sensor:
      - platform: tuya
        name: "Temperatura"
        device_class: "temperature"
        sensor_datapoint: 3
        unit_of_measurement: "°C"
        accuracy_decimals: 1
        filters:
          - multiply: 0.1
    
    number:
    - platform: "tuya"
      name: "Histereza"
      number_datapoint: 101
      min_value: 0.3
      max_value: 10.0
      step: 0.1
      multiply: 10
    
    - platform: "tuya"
      name: "Cool del"
      number_datapoint: 102
      min_value: 1
      max_value: 10
      step: 1
    
    - platform: "tuya"
      name: "Korekta T"
      number_datapoint: 103
      min_value: -10
      max_value: 10
      step: 0.1
      multiply: 10
    
    .


    User interface with thermostat settings .

    I know it takes more time in ESP it's not a web selector and probably autoexec won't solve the problem but maybe there are parameters for channels that can be set like range from to, divide by 10?
    Maybe it would be better to make one type for channels with data, e.g. temperature and as another option multiplier?
    With the development of the software, there will be more and more functions and options, so maybe it would be possible to sort this list alphabetically?
    You would certainly have to make a LowAlarm/HighAlarm channel for the alarm channels.

    My autoexec now looks like this:
    
    clearIO
    PowerSave 1
    startDriver NTP
    ntp_setServer 192.168.1.253
    waitFor NTPState 1
    ntp_timeZoneOfs 1
    startDriver TuyaMCU
    startDriver tmSensor
    // Flags 134743044
    
    setChannelType 1 temperature_div10
    linkTuyaMCUOutputToChannel 1 val 1
    
    setChannelType 2 Humidity
    linkTuyaMCUOutputToChannel 2 val 2
    
    setChannelType 3 ReadOnlyLowMidHigh
    setChannelLabel 3 "Batt_state"
    linkTuyaMCUOutputToChannel 3 val 3
    
    setChannelType 4 BatteryLevelPercent
    setChannelLabel 4 "Batt_level"
    linkTuyaMCUOutputToChannel 4 val 4
    
    setChannelType 10 TextField
    setChannelLabel 10 "Set maxtemp"
    linkTuyaMCUOutputToChannel 10 val 10
    
    setChannelType 11 TextField
    setChannelLabel 11 "Set minitemp"
    linkTuyaMCUOutputToChannel 11 val 11
    
    setChannelType 12 TextField
    setChannelLabel 12 "Set maxhum"
    linkTuyaMCUOutputToChannel 12 val 12
    
    setChannelType 13 TextField
    setChannelLabel 13 "Set minihum"
    linkTuyaMCUOutputToChannel 13 val 13
    
    setChannelType 14 ReadOnly
    setChannelLabel 14 "Temp alarm"
    linkTuyaMCUOutputToChannel 14 val 14
    
    setChannelType 15 ReadOnly
    setChannelLabel 15 "Humidity alarm"
    linkTuyaMCUOutputToChannel 15 val 15
    
    setChannelType 17 TextField
    setChannelLabel 17 "Temperature report"
    linkTuyaMCUOutputToChannel 17 val 17
    
    setChannelType 18 TextField
    setChannelLabel 18 "Humidity report"
    linkTuyaMCUOutputToChannel 18 val 18
    
    setChannelType 19 TextField
    setChannelLabel 19 "Temp sensitivity"
    linkTuyaMCUOutputToChannel 19 val 19
    
    .

    typing a value e.g. 240 for max. temp. in the text field to trigger an alarm saves it in the OBK but does not send it to the MCU because after a reboot the old values still entered in the cloud are shown again.

    Edit: the sensor is powered by batteries and the MCU switches on the wifi module when sending the data, so the parameter changes must rather be saved in the HA and sent when the wifi is switched on, therefore these channels must be "editable" and "writable" in the HA.

    I don't use the simulator it's not a problem I have the sensor next to my PC and am testing but you may need to - is it under windows or linux?
    You asked about flags.
    The problem with sending flags is quite troublesome and I have read about it already with blinds.
    When I send in the autoexec setting the flags for example.
    "Flags 134743044"
    then the flags should turn on: 2,10,19,27,43,47
    but, unfortunately, above the 30th one, completely different flags are switched on.
    With roller shutters it is similar - I send flags and they move and other flags are switched on, most often button locking, as my colleagues wrote about in threads about roller shutters.
    It looks as if one of the higher flags is not included in the counting/recounting from bin to hex because I think that is how it is done and then the shift occurs but as I wrote I am not a programmer, it is just my thoughts.

    I have checked on WBR1 that the 31st flag is the last one to change the value of the flags, if you select all the flags from 1-30 there are enough digits, adding 31 causes overflow.
  • #215 21382506
    GAAD
    Level 17  
    I apologise for re-writing the post below the post but this is probably more readable and easier to translate to a non-Polish version.

    I have set up the low/high temperature and humidity alarms:
    For channels 14 and 15 as "ReadOnly"
    exceeding the lower threshold - value 0
    exceeding of the upper threshold - value 1
    no alarms, i.e. normal state - value 2

    So we need e.g. the following channels: LowAlarm / HighAlarm / Normal
    I think this will be fairly universal.

    Still a question what are the errors and info in the logs?
    
    Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 881 changes count.
    Info:CFG:####### Flash Save Can't Get Channel 14 (not enough space in array) #######
    Info:CFG:####### Flash Save Can't Get Channel 15 (not enough space in array) #######
    Error:CMD:no file early.bat err -2
    
    .

    Before I can do the thermostat settings from HA or the web I wanted to set the alarm values from autoexec but the command:
    "SetChannel" does not work:
    
    setChannelType 10 ReadOnly
    setChannelLabel 10 "Set max temp"
    linkTuyaMCUOutputToChannel 10 val 10
    SetChannel 10 250
    
    .
    maybe because the channel is read-only?
  • #216 21384337
    p.kaczmarek2
    Moderator Smart Home
    Thank you for your submissions! Your comments are very much appreciated.

    I may think about a system in this style, although in principle a lot of this can already be done via HTML Widgets and a custom page in HTML hosted on LittleFS:
    Alternative HTML control page for TOMPD-63-WIFI .
    Still, I think it will be worth adding what you say.

    I'm working on the flags problem, but sprintf/sscanf on MCU is different than on Win32 simulator and I'm a bit stuck:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1494

    
    Info:CFG:####### Flash Save Can't Get Channel 15 (not enough space in array) #######
    
    .
    If you did SetStartValue to -1 for channel 15 then this won't work, only the first channels have flash writes, due to saving flash cycles (we have a system that does one erase for many writes over several sectors, but the side effect is that the flashvars structure has a fixed size and has to be quite small).

    
    Error:CMD:no file early.bat err -2
    
    .
    This could be changed to a warning, this means that there is simply no early.bat in LittleFS

    In my opinion, this code:
    
    setChannelType 10 ReadOnly
    setChannelLabel 10 "Set max temp"
    linkTuyaMCUOutputToChannel 10 val 10
    SetChannel 10 250
    
    .
    should work. I typed it into the simulator and it goes through:
    https://github.com/openshwprojects/OpenBK7231...mmit/b1f745deb151019878b0718bdb1b4cce9ba78831
    Helpful post? Buy me a coffee.
  • #217 21385809
    GAAD
    Level 17  
    p.kaczmarek2 wrote:
    My opinion is that this code:
    Code: [expand][collapse][select all][copy to clipboard].
    setChannelType 10 ReadOnly
    setChannelLabel 10 "Set max temp"
    linkTuyaMCUOutputToChannel 10 val 10
    setChannel 10 250

    should work. I typed it into the simulator and it goes through:
    https://github.com/openshwproj...51019878b0718bdb1b4cce9ba78831
    .

    Unfortunately the values appear on the web page for a while and then the MCU sends the old ones.
    I guess it just doesn't accept them.
  • ADVERTISEMENT
  • #218 21385904
    p.kaczmarek2
    Moderator Smart Home
    I have had no such problems, and have even recently operated an Atorch advanced meter in TuyaMCU:
    Advanced energy meter/thermostat with LCD Atorch S1TW-FR - cloudless operation .
    But that may be because the device in question here is a battery-powered device....
    I read somewhere that someone succeeded as he added:
    
    delay_s 0.5
    

    before sending the initial state.

    And yes you would have to look up how in the original firmware this is sent:
    TuyaMCU analyser - UART packet decoder for Tuya devices - dpID detector .

    You can also use tuyaMcu_sendState to send a packet directly.
    Here is the command documentation:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
    Instead of using setChannel then try while the device is running, live use tuyaMcu_sendState from the documentation to set the dpID (here 10) to a value of 250, complete its type itself, here you have a screenshot of the self-tests so that there is no doubt that it works and sends the packet:
    Screenshot of source code inside an editor, displaying tuyaMcu_sendState commands and test results. .


    Maybe it also needs to be sent via dpCache.
    The battery-powered TuyaMCU devices also have a so-called dpCache. In this case, this device queries the WiFi module itself at startup for these values:
    Code: C / C++
    Log in, to see the code
    .
    The WiFi module responds with a packet 0x10:
    Code: C / C++
    Log in, to see the code
    .
    I wrote about dpCache in this post:
    https://www.elektroda.com/rtvforum/topic3975583.html#20584330
    You use dpCache in two steps:
    1. you set a given channel to be remembered in Flash memory between reboots, here remember that only the first 10-12 channels are remembered, so use channels sequentially, not that you give the number 30....
    Suppose we use channel 5:
    
    // Make value persistant (stored between reboots), 
    // start value -1 means "remember last"
    SetStartValue 5 -1
    
    .
    2. when mapping a dpID to a channel you specify an additional argument, append 1, that is true for bDPCache:
    
    // link dpID 17 to channel 5, the type is val, extra '1' means that its dpCache variable
    linkTuyaMCUOutputToChannel 17 val 5 1
    
    .
    Configured this way, the device knows that when the MCU queries the dpCache, you need to send it the value of channel five in response.
    Helpful post? Buy me a coffee.
  • #219 21503091
    smoeller95s
    Level 3  
    Hello
    I have a strange Problem. My updated devices work fine and im very happy. But sometimes when the Battery runs out and i not change it fast enough (some days) the firmware seems lost.
    The wifi icon on the lcd allways flash but the obk never come alive. No Wifi connection no hotspot. The only solution is erase all and then re flash. Only re flash is not enough.
    Had someone had the same problem before? I have ~ 15 devices and today the 4. had this Problem.
  • #220 21503990
    GAAD
    Level 17  
    I have the same problem with one TH08. I haven't resuscitated it yet but the symptoms are the same: when the battery is discharged the Wifi module is dead. The thermometer itself measures and displays measurements correctly i.e. the Tuya MCU is working properly.
  • #221 21513410
    GAAD
    Level 17  
    I uploaded the OBK again yesterday. After connecting it, it gave programming but the WiFi network did not appear. I had to remove the CB3S upload the Tuya soft and again the OBK then worked. By the way the update to the latest version went. Now I am waiting for the battery to drain ;-) .
  • #222 21513752
    p.kaczmarek2
    Moderator Smart Home
    @insmod creates "fast wifi connect" modification, it should help with battery life in this type of device
    Helpful post? Buy me a coffee.
  • #223 21550631
    silver_mc
    Level 13  
    Hello,
    Has anyone encountered a version where the units are in °F and °C? In the Tuya app, it was possible to change them. In OpenBK, the units on the display are showing in °F. Is it possible to change this via a dpID? Unfortunately, I no longer have the original firmware as I lost it somewhere. :/
  • #227 21599220
    blacksun2
    Level 8  
    Hello,
    I'm new to openBeken.
    I bought this temperature and humidity sensor at AliExpress:


    [BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight

    [BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight


    I can't find the correct pins to flash OpenBeken.
    Are the marked pins correct: for 3.3V, GND, TX, and RX?
    Where is the pin for CEN?

    Thank you.
  • ADVERTISEMENT
  • #228 21599227
    DeDaMrAz
    Level 20  
    blacksun2 wrote:
    I can't seem to find the correct pins to flash OpenBeken.
    Are the marked pins correct: for 3.3V, GND, TX, and RX?
    Where is the pin for CEN?


    Those are for the TuyaMCU most likely, You have CBU module so use this for pinout and reference - https://images.tuyacn.com/goat/pdf/01J6RB48RJ...er%20Platform_Tuya%20Developer%20Platform.pdf

    We have a flasher tool that has read flash/backup option, it is important that you backup CBU module for reference and whatever need may be.

    Search the forum for TuyaMCU driver and how to use it after you have flashed the module. I also think this device was done before so do some searching as well before we can move on with config and the rest.
  • #229 21599265
    blacksun2
    Level 8  
    DeDaMrAz wrote:

    Those are for the TuyaMCU most likely
    CBU module so use this for pinout


    Sorry for the stupid question, but what is "TuyaMCU"?

    Regarding CBU, do I have to use the PINs at CBU-Board? Are there no contact-Point which I can use on the board? I am asking because of avoiding soldering.
  • #230 21599298
    DeDaMrAz
    Level 20  
    blacksun2 wrote:
    Sorry for the stupid question


    there is no stupid questions only stupid answers :)

    TuyaMCu is the other chip on the board near which you've fount Rx and Tx pads, it is used for communicating with the sensor and LCD and only uses CBU module for WiFi communication via that UART (Rx and TX) no way for me to verify and the picture is not revealing much - just from experience.
    We are not touching that chip, only CBU module, so you may try to flash the device via those pads but be prepared for interuptions form TuyaMCU and being unable to flash it because of it.
  • #231 21604667
    blacksun2
    Level 8  
    [postid:b622992f1e][/postid:b622992f1e]
    I have now successfully flashed OBK 1.18.134 on my device.
    As long as the CBU is powered via the TTL USB, there is a permanent Wi-Fi connection, and the values are also published to HomeAssistant.
    Since the MCU is not powered, the values are naturally 0.

    I assembled the device and let it run overnight on batteries. There was not a single transmission to HomeAssistant.

    I use this autoexec.bat.
    I use almost the same autoexec.bat on a TH01. The behavior is the same here, too.

    What's the problem?

    
    startDriver NTP
    ntp_setServer fritz.box
    ntp_timeZoneOfs 2
    waitFor NTPState 1
    mqtt_broadcastInterval 20
    mqtt_broadcastItemsPerSec 20 
    startDriver TuyaMCU
    startDriver tmSensor
    waitFor MQTTState 1
    PowerSave 1
    
    
    setChannelType 1 temperature_div10
    linkTuyaMCUOutputToChannel 1 val 1
    
    setChannelType 2 Humidity
    linkTuyaMCUOutputToChannel 2 val 2
    
    setChannelType 3 ReadOnlyLowMidHigh
    setChannelLabel 3 "Battery_Level"
    linkTuyaMCUOutputToChannel 3 val 3
    
    setChannelType 4 ReadOnly
    setChannelLabel 4 "Battery_Level_in_Percent"
    linkTuyaMCUOutputToChannel 4 val 4
    


    For commands like waitFor NTPState, mqtt_broadcastInterval, mqtt_broadcastItemsPerSec, waitFor MQTTState, etc., does the order in the autoexec.bat matter?
    Or does it matter where the commands are located in the file?
  • #232 21622917
    bogdanelhh
    Level 3  
    Hello, I flashed this bad boy
    Close-up of a printed circuit board with wires connected to RX, TX, GND, and 3V3 pins and visible reworked traces.
    By hooking to cen, rx tx gnd and 3v3. To have it programmable I had to strip 3v3 below right side of push button between the two free pads. I also cut the rx tx traces on the back and resoldered them after flashing.
    Now the only issue I have is that it's not reporting to homeassistant, and that's because I suspect that tuyamcu shuts down cbu before he manages to connect or anything.
    Is there a way to increase the time cbu stays on? or even keep it on always and enable deepsleep?
  • #233 21623129
    GAAD
    Level 17  
    My autoexec:

    
    clearIO
    PowerSave 1
    startDriver NTP
    ntp_setServer xxx.xxx.xxx.xxx
    waitFor NTPState 1
    ntp_timeZoneOfs 1
    startDriver TuyaMCU
    startDriver tmSensor
    Flags 2251937253164036
    setChannelType 1 temperature_div10
    linkTuyaMCUOutputToChannel 1 val 1
    setStartValue 1 -1
    
    setChannelType 2 Humidity
    linkTuyaMCUOutputToChannel 2 val 2
    setStartValue 2 -1
    
    setChannelType 3 ReadOnlyLowMidHigh
    setChannelLabel 3 "Batt_state"
    linkTuyaMCUOutputToChannel 3 val 3
    setStartValue 3 -1
    
    setChannelType 4 BatteryLevelPercent
    setChannelLabel 4 "Batt_level"
    linkTuyaMCUOutputToChannel 4 val 4
    setStartValue 4 -1
    
    setChannelType 10 TextField
    setChannelLabel 10 "Set maxtemp"
    linkTuyaMCUOutputToChannel 10 val 10
    
    setChannelType 11 TextField
    setChannelLabel 11 "Set minitemp"
    linkTuyaMCUOutputToChannel 11 val 11
    
    setChannelType 12 TextField
    setChannelLabel 12 "Set maxhum"
    linkTuyaMCUOutputToChannel 12 val 12
    
    setChannelType 13 TextField
    setChannelLabel 13 "Set minihum"
    linkTuyaMCUOutputToChannel 13 val 13
    
    setChannelType 14 ReadOnly
    setChannelLabel 14 "Temp alarm"
    linkTuyaMCUOutputToChannel 14 val 14
    setStartValue 14 -1
    
    setChannelType 15 ReadOnly
    setChannelLabel 15 "Humidity alarm"
    linkTuyaMCUOutputToChannel 15 val 15
    setStartValue 15 -1
    
    setChannelType 17 TextField
    setChannelLabel 17 "Temperature report"
    linkTuyaMCUOutputToChannel 17 val 17
    
    setChannelType 18 TextField
    setChannelLabel 18 "Humidity report"
    linkTuyaMCUOutputToChannel 18 val 18
    
    setChannelType 19 TextField
    setChannelLabel 19 "Temp sensitivity"
    linkTuyaMCUOutputToChannel 19 val 19
    
    .

    It is important that these flags are enabled:
    Flag 2 10 19 37 51

    The new version of OBK with fast WiFi connection and everything is hula and even the battery life has slightly improved although unfortunately still far from the original. But something for something at least the Tuya cloud is not needed.
    To turn on the WiFi you have to press the button every few seconds: it turns on the backlight and turns on the power supply to the WiFi module is an option for an update also without disassembly.
  • #234 21623283
    bogdanelhh
    Level 3  
    >>21623129 now it seems to cooperate more, many thanks for settings. Have a nice one!
  • #235 21624057
    blacksun2
    Level 8  
    GAAD wrote:

    
    setChannelType 4 BatteryLevelPercent
    setChannelLabel 4 "Batt_level"
    linkTuyaMCUOutputToChannel 4 val 4
    setStartValue 4 -1
    
    setChannelType 14 ReadOnly
    setChannelLabel 14 "Temp alarm"
    linkTuyaMCUOutputToChannel 14 val 14
    setStartValue 14 -1
    
    setChannelType 15 ReadOnly
    setChannelLabel 15 "Humidity alarm"
    linkTuyaMCUOutputToChannel 15 val 15
    setStartValue 15 -1
    
    .


    Are Channel 4, 14 and 15 original dp_ids from Tuya?
    How do you get them?
    I am asking because at https://iot.tuya.com, for my TH08b is only shown

    "code": "temp_current",
    "dp_id": 1,
    "code": "humidity_value",
    "dp_id": 2,
    "code": "battery_state",
    "dp_id": 3,
    "code": "temp_unit_convert",
    "dp_id": 9,
    "code": "temp_calibration",
    "dp_id": 23,
    "code": "hum_calibration",
    "dp_id": 24,

    Another question:
    How can I change time-format (12h AM-PM or 24h)?
  • #236 21624747
    divadiow
    Level 35  
    blacksun2 wrote:
    How do you get them?
    I am asking because at https://iot.tuya.com, for my TH08b is only shown

    how did you get these? usually you link a developer account with the Tuya app, pair device, then go into API explorer in dev portal to get dpID info. If you have factory fw dump or the Tuya config file downloaded I could check with that.
  • #237 21625533
    blacksun2
    Level 8  
    divadiow wrote:
    usually you link a developer account with the Tuya app, pair device, then go into API explorer in dev portal to get dpID info. If you have factory fw dump or the Tuya config file downloaded I could check with that.

    That's my situation too. That's exactly how I did it.
    If you were thinking about the ltchiptool, it also only says that there are only these dp_IDs:
    [BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight

    Therefore, the question to GAAD was where he got the other dp_IDs from
  • #238 21625539
    divadiow
    Level 35  
    yes, but this bit means it's matched it to the wrong schema

    [BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight
  • #239 21625542
    blacksun2
    Level 8  
    divadiow wrote:
    yes, but this bit means it's matched it to the wrong schema


    I know.
    Because you have other oppotunities, I attached the backuped Firmware tool.
  • #240 21625617
    GAAD
    Level 17  
    I knew the parameters I set on my thermometer were e.g. alarms. And when a channel reported the value I had set I knew that it was, for example, a maximum temperature alarm. I called up the alarms and took channel readings. These channels in the OBK don't do much anyway because so far I have not been able to send/edit these values. My version of this thermostat may also be different these devices change all the time. In ESPHome you can make the handling of the settings a little more convenient but for this sensor I have not tested

Topic summary

The discussion centers on the teardown, firmware modification, and protocol analysis of the TH08 LCD calendar/clock/temperature/humidity sensor powered by 3xAAA batteries with backlight, based on the BK7231N chip. The device is identified as a newer version of the TH06 model, featuring a TuyaMCU module communicating via a low-power Tuya serial protocol (version 00). Users successfully flashed OpenBK firmware without desoldering, enabling temperature, humidity, and battery monitoring with MQTT integration and NTP time synchronization. Key challenges included understanding the MCU-module communication, especially time synchronization commands and power management to optimize battery life. The MCU sends commands such as ObtainDPCache and ObtainLocalTime, with the WiFi module responding accordingly. Firmware updates improved battery consumption by ensuring the WiFi module powers down promptly after data transmission. The device’s RTC (U8) communicates with the MCU (U3) over a serial or I2C-like interface, with ongoing efforts to decode this traffic. Users experimented with modifying battery power sources, including LiPo and USB power mods with step-down regulators, confirming device operation at voltages between 3.3V and 4.5V. The Tuya app lacks options to adjust sensor reporting intervals, and attempts to change polling times via Tuya protocol commands were unsuccessful, likely due to firmware limitations. Serial sniffing and analysis tools like TuyaMCU Analyzer and SniffUART were used to decode dpIDs, confirming dpID 1 as temperature, dpID 2 as humidity, dpID 3 as battery state, and dpID 9 as Celsius/Fahrenheit setting. Firmware versions and MCU versions were compared, revealing some early versions had display update issues. The community contributed to improving OpenBK firmware to handle specific Tuya commands, including proper responses to WiFi signal strength queries, enhancing power management. MQTT integration with Home Assistant was refined, including battery level display improvements using LowMidHigh channel types. OTA updates and configuration changes require keeping the WiFi module powered, achievable via long button presses or hardware modifications. Attempts to use Tuya-cloudcutter for remote flashing were unsuccessful due to lack of matching profiles. Some users reported issues with sensor readings showing zero after flashing, possibly due to hardware revisions or firmware mismatches. Overall, the device is well-supported by OpenBK firmware with active community development focusing on power optimization, protocol decoding, and integration with home automation platforms.
Summary generated by the language model.
ADVERTISEMENT