logo elektroda
logo elektroda
X
logo elektroda

Multi-platform IoT firmware supporting up to 32 platforms - OBK 2025 summary

p.kaczmarek2 3426 80

TL;DR

  • OpenBeken/OBK is an open-source Wi‑Fi firmware for building-automation devices like relays, LED controllers, thermostats, energy meters, and sensors.
  • It flashes over UART, then uses auto-detected GPIO templates, Berry scripting, Home Assistant integration, REST hosting, and a simulator to speed setup and testing.
  • The project now supports 32 platforms and lists 817 devices, with separate binaries for families such as BK7231, ESP32 variants, Realtek, Winner Micro, and more.
  • Online builds, automatic OTA downloads from GitHub, and GitHub-run tests let developers compile, deploy, and flag bad commits without local toolchains.
  • Some platform features still vary: certain OTA paths are broken, WPA3 must be manually enabled on some ESP8266 builds, and several PWM or sleep features are partial.
Generated by the language model.
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
📢 Listen (AI):
  • ADVERTISEMENT
  • #32 21851787
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    DeDaMrAz wrote:
    bump - for house cleaning, PR status and issues....

    Closed some more old PRs. Still open:
    Open PR #SummaryStatus
    1998Extend SHT3x driver to work SHT4x (and GXHTV4) and allow multiple sensorsStill WiP. I'm currently working on a new (smaller) version
    1927Allow WPA AP with "#define ENABLE_WPA_AP 1"WiP. Allow to work not only as open AP but as WPA2 protected AP. Don't know if there's someone needing it ...
    1926Add a command to set a timeout for connecting to WiFiWas initially a request in issue 1923. But no more feedback...
    1911Driver for DCF77 radio controlled clockWill need update to current version. It was suggested to remove own "IORole" since driver will probably not be widely used...
    1889Max72xx clock driver wipWork‑in‑progress - playground, not updated recently
    1841Add all defines "ENABLE_XY" to "about" pageI thought it usefull, but will increase image size because of the strings
    1826Rolerework with python scriptThird try as Python script. Will need generat agreement, if a single file for all definitions is wanted.
    1773Rework of pin config pageCentralize IOroles and channles (like PR #1378) with an awk script
    1696Multi aht2xWould need some update to current version. Didn't work on it recently
    1688Try finding best BSSID for a SSIDAbandoned try to fix LN882H sometimes using a "weak" SSID instead of a stronger one. It didn't work out (yet) to use a found stronger BSSID
    1485Switch DST offset to minutes to allow regions with 30 minutes offsetProbably not needed.
    1448SSID retain with GUIAlmost forgott about it. Maybe it's of use for someone? But how often is "second SSID" used??
    1378Rework pins and rolesTry for rework / centralize IOroles and channles with C macros
    1358Ring buffer for graphI played with an own simple graph for temperatures using a ringbuffer. If merged, it would be good to share the ring buffer code. Probably outdated...
    1346Simple temperature graph on main pageAdds a simple temperature graph to the main UI page.
    1336Allow to publish channel labels instead of channel idsDon't recall if that was of use...
    1240Implement reset of configuration if http auth fails ("forgotten password")No clue if thats of some use, we have safe mode ...
    1216Add some information to status page – Works on LN882HDidn't convice this is usefull (yet?) Discussion is here
  • #33 21851984
    divadiow
    Level 38  
    Posts: 4928
    Help: 430
    Rate: 875
    I think https://github.com/openshwprojects/OpenBK7231T_App/pull/1999 is ready to go. Not sure about the os_ renames though that insmod suggested.

    Summary of changes made

    TuyaMCU driver
    - Added bounds checks in the incoming TuyaMCU parse paths so a DP sector cannot claim more bytes than actually remain in the packet.
    - This was added to:
    - TuyaMCU_ParseStateMessage() for normal STATE / 0x07 parsing
    - TuyaMCU_V0_ParseRealTimeWithRecordStorage() for the V0 realtime paths (including 0x05 and 0x08-style packets)
    - The new check compares sectorLen against the remaining bytes after the DP header and, if truncated:
    - logs an error with dpId/type/length details
    - stops parsing that malformed packet instead of reading/copying past the end
    - This prevents:
    - out-of-bounds reads
    - out-of-bounds memcpy/copies
    - bad downstream parsing from malformed/truncated TuyaMCU payloads
    - Added realloc hardening for raw DP storage in the STATE parser:
    - use a temporary pointer for realloc instead of assigning straight back to mapping->rawData
    - only replace mapping->rawData if realloc succeeds
    - avoids a NULL-pointer memcpy / crash if allocation fails while storing raw DP data

    Effect of the driver changes
    - No intended behaviour change for valid TuyaMCU packets
    - Malformed/truncated packets now fail safely instead of potentially corrupting memory or crashing
    - Under low-memory conditions, raw DP storage is handled more safely

    Self-test changes
    - Expanded the TuyaMCU self-test with a new robustness test covering the parser hardening
    - The new test exercises all 3 relevant parse cases:
    1. normal STATE / 0x07 parsing
    2. V0 realtime / 0x05 parsing
    3. V0 realtime with datetime prefix / 0x08 parsing
    - For each path, the test now:
    - sets up a mapping and a known starting channel value
    - injects a deliberately truncated packet where sectorLen says 4 bytes, but only 3 bytes remain for the parser
    - checks that the channel value does NOT change after the malformed packet
    - then injects a valid follow-up packet
    - checks that the valid packet is still parsed correctly and updates the channel
    - The self-test was tightened/fixed during iteration:
    - fixed an earlier dpId/mapping mismatch
    - corrected malformed packet construction so the parser really sees remaining=3
    - corrected packet checksums so packets pass framing/checksum validation and actually reach the truncation guards
    - added the missing valid follow-up for the V0/0x08 path
    - Final result:
    - malformed packets hit the new truncation guard
    - valid packets still work immediately afterwards
    - simulator / ASan / UBSan runs now show the expected truncation log messages and no self-test failures
  • #34 21863496
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    @max4elektroda
    Open PR #SummaryStatusExtra comment
    1998Extend SHT3x driver to work SHT4x (and GXHTV4) and allow multiple sensorsStill WiP. I'm currently working on a new (smaller) versionPlease finish and let's merge
    1927Allow WPA AP with "#define ENABLE_WPA_AP 1"WiP. Allow to work not only as open AP but as WPA2 protected AP. Don't know if there's someone needing it ...Please finish and let's merge with #define off
    1926Add a command to set a timeout for connecting to WiFiWas initially a request in issue 1923. But no more feedback...up to discussion
    1911Driver for DCF77 radio controlled clockWill need update to current version. It was suggested to remove own "IORole" since driver will probably not be widely used...top priority, I want this merged but disabled by default
    1889Max72xx clock driver wipWork-in-progress - playground, not updated recentlyplease finish and merge
    1841Add all defines "ENABLE_XY" to "about" pageI thought it usefull, but will increase image size because of the strings
    1826Rolerework with python scriptThird try as Python script. Will need generat agreement, if a single file for all definitions is wanted.
    1773Rework of pin config pageCentralize IOroles and channles (like PR #1378) with an awk script
    1696Multi aht2xWould need some update to current version. Didn't work on it recentlyif memory footprint is small, we can have it
    1688Try finding best BSSID for a SSIDAbandoned try to fix LN882H sometimes using a "weak" SSID instead of a stronger one. It didn't work out (yet) to use a found stronger BSSID
    1485Switch DST offset to minutes to allow regions with 30 minutes offsetProbably not needed.we can merge it if we prove it works and not breaks
    1448SSID retain with GUIAlmost forgott about it. Maybe it's of use for someone? But how often is "second SSID" used??
    1378Rework pins and rolesTry for rework / centralize IOroles and channles with C macros
    1358Ring buffer for graphI played with an own simple graph for temperatures using a ringbuffer. If merged, it would be good to share the ring buffer code. Probably outdated...
    1346Simple temperature graph on main pageAdds a simple temperature graph to the main UI page.
    1336Allow to publish channel labels instead of channel idsDon't recall if that was of use...
    1240Implement reset of configuration if http auth fails ("forgotten password")No clue if thats of some use, we have safe mode ...
    1216Add some information to status page – Works on LN882HDidn't convice this is usefull (yet?) Discussion is herehigh priority, we can have it on main page, but we need to protect it against strange bugs, maybe if failed reboots > 1 then do not show it?



    @divadiow while it seems good at first glance, I had one concern. I was wondering whether those checks are really needed, because initial ring buffer already checks for truncated packets and does not allow broken data to pass... but still, you are checking sectorLen, not the whole packet len... I think I'll accept it now but I don't think it will really occur. Those error messages could be shorter.


    What do we do about this? Does it help?
    Configure Git settings for network stability #2032
    https://github.com/openshwprojects/OpenBK7231T_App/pull/2032/changes
    GitHub diff of workflow.yaml showing added steps and cache-apt-pkgs-action version change

    Also, do we have a PWM issue on some Beken platforms?
    https://github.com/openshwprojects/OpenBK7231T_App/pull/2030/changes
    Code diff view: changes in hal_pins_bk7231.c adjusting #if conditions for BK7231N and BK7238 platforms

    @DeDaMrAz what is going on with RTL OTA code here?
    mDNS support for other platforms #2018
    https://github.com/openshwprojects/OpenBK7231T_App/pull/2018



    Fast connect LN882H - ready to merge? @insmod
    https://github.com/openshwprojects/OpenBK7231T_App/pull/2016

    Helpful post? Buy me a coffee.
  • #35 21863502
    divadiow
    Level 38  
    Posts: 4928
    Help: 430
    Rate: 875
    p.kaczmarek2 wrote:
    @divadiow while it seems good at first glance, I had one concern. I was wondering whether those checks are really needed, because initial ring buffer already checks for truncated packets and does not allow broken data to pass... but still, you are checking sectorLen, not the whole packet len... I think I'll accept it now but I don't think it will really occur. Those error messages could be shorter.


    appreciate you taking the time to look at it. I will review more.
  • #36 21863503
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    It's merged for now, however error messages could be shorter.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #37 21863536
    insmod
    Level 31  
    Posts: 1366
    Help: 163
    Rate: 429
    >>21863496
    LN is ready
    PWM is fine on 7238, and that pull request does nothing at all, since BK7238 has PLATFORM_BEKEN_NEW
  • #38 21863546
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    Helpful post? Buy me a coffee.
  • #39 21863552
    insmod
    Level 31  
    Posts: 1366
    Help: 163
    Rate: 429
    >>21863546
    Far from being properly done.
    But can be used already and is more or less stable.
  • #40 21863656
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    Thanks, I merged, however, I have little nitpick. Is ENABLE_BT_PROXY a correct define name? My assumption is that ENABLE_DRV_ prefix is for drivers (called from drv_main), and ENABLE_XYZ is for mechanism that resides outside drivers... I can see that indeed your define related to HAL, so maybe it's correct, but still, it's worth to consider it.
    Helpful post? Buy me a coffee.
  • #41 21863921
    DeDaMrAz
    Level 22  
    Posts: 600
    Help: 34
    Rate: 127
    p.kaczmarek2 wrote:
    what is going on with RTL OTA code here?


    You can disregard that anything RTL related as I was not been able to finish that up - RTL is excluded from mDNS for now.
  • #42 21865583
    divadiow
    Level 38  
    Posts: 4928
    Help: 430
    Rate: 875
    p.kaczmarek2 wrote:
    What do we do about this? Does it help?
    Configure Git settings for network stability #2032
    https://github.com/openshwprojects/OpenBK7231T_App/pull/2032/changes


    i put a question comment on the issue. no idea, but fixing awalsh128/cache-apt-pkgs-action to v1.4.3 kinda sounds a bit limiting. you'd miss out on all fixes/changes since that version without manual change to newer version
  • #43 21866070
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    First feedback:

    p.kaczmarek2 wrote:
    @max4elektroda

    1696 Multi aht2x if memory footprint is small, we can have it


    Updated. Additional Memory mainly ~+400-600bytes, ESP platforms ~ +730bytes. (minimum 0, once 1104 (RTL8710B)) :

    Spoiler:
    We have AHT2X enabled (if not OBK_VARIANT_TUYAMCU / OBK_VARIANT_POWERMETERING / OBK_VARIANT_IRREMOTEESP / OBK_VARIANT_HLW8112) with
    XR806, W800, BK7231N, BEKEN_NEW, ESPIDF, TR6260, REALTEK, ECR6600, RDA5981

    Size +/-    Filename                                                       1.18.276   1696_merge_ed9bff6683a1
    0           OpenXR806_XX.img                                                 876384                     876384
    0           OpenRTL8720D_XX.bin                                             1138688                    1138688
    64          OpenRTL87X0C_XX_btproxy.bin                                      958084                     958148
    128         OpenRTL87X0C_XX.bin                                              868484                     868612
    336         OpenECR6600_XX.bin                                               988081                     988417
    412         OpenRDA5981_XX.bin                                               511500                     511912
    496         OpenTR6260_XX.bin                                                663284                     663780
    512         OpenRTL8710A_XX.bin                                              690376                     690888
    520         OpenBK7238_XX_berry.bin                                          866297                     866817
    536         OpenBK7238_XX_btproxy.bin                                        968513                     969049
    544         OpenBK7238_XX.bin                                                765669                     766213
    544         OpenRTL8720E_XX.bin                                             1303904                    1304448
    552         OpenBK7231N_XX_berry.bin                                         928945                     929497
    552         OpenBK7231N_XX.bin                                               826585                     827137
    552         OpenRTL8710B_XX.bin                                              680244                     680796
    648         OpenW800_XX.fls                                                  707692                     708340
    704         OpenRTL8721DA_XX.bin                                            1400960                    1401664
    720         OpenESP32C2_XX_2M.factory.bin                                    934368                     935088
    720         OpenESP32C2_XX_2M.img                                            868832                     869552
    736         OpenESP32C2_XX_4M.factory.bin                                   1071376                    1072112
    736         OpenESP32C2_XX_4M.img                                           1005840                    1006576
    736         OpenESP32C61_XX_4M.factory.bin                                  1239440                    1240176
    736         OpenESP32C61_XX_4M.img                                          1173904                    1174640
    736         OpenESP32C6_XX_4M.factory.bin                                   1272704                    1273440
    736         OpenESP32C6_XX_4M.img                                           1207168                    1207904
    752         OpenESP32C3_XX_2M.factory.bin                                   1038976                    1039728
    752         OpenESP32C3_XX_2M.img                                            973440                     974192
    752         OpenESP32C3_XX_4M.factory.bin                                   1175936                    1176688
    752         OpenESP32C3_XX_4M.img                                           1110400                    1111152
    752         OpenESP32C5_XX_4M.factory.bin                                   1273472                    1274224
    752         OpenESP32C5_XX_4M.img                                           1207936                    1208688
    1104        OpenRTL8710B_UG_XX.img                                          1270432                    1271536
    


    p.kaczmarek2 wrote:

    1911 Driver for DCF77 radio controlled clock top priority, I want this merged but disabled by default

    Updated, disabled by default, ready to merge
  • #44 21867083
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    DCF seems acceptable, merged.

    What's the next step?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #45 21867120
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    @p.kaczmarek2
    Still not totally giving up the idea of an alternate way to give arguments to drivers I made a minimum version to extend tokenizer: search a string in tokens ad return it's index. All others are simply done by makro.
    While at it I found (I guess) a bug in tokenizer. I added safeguards to the index's argument not only to "reject" the index if it's >= arguments counter, but also if it's negative (we can discuss this but i think it's a necessary measure of safety).

    But: GetArgInteger had no safeguard at all!
    And after fixing this, one of the selftests failed. I added some debug output and it clearly states that one selftest is relaying on the wrong behavior:

    The actual (wrong?) implementation will simply answer with some previous values, even if tokenizer was called in between.

    So can you please take a look at
    https://github.com/MaxineMuster/OpenBK7231T_App/tree/_tokenizer_mini

    And the failing selftesst (I changed on in the way I think it should work and adde one logging to show there's a tokenizer call with no argument but later the test will rely on the argument from the previous call)

    https://github.com/MaxineMuster/OpenBK7231T_A...runs/23358853840/job/67956684162#step:5:58740

    
    Debug:CMD: temperature (CT) received with args 153
    Info:MQTT:Publishing val 153 to rgbcwBulb/led_temperature/get retain=0
    Debug:CMD: temperature (CT) received with args 
    Error:CMD:Tokenizer_GetArgInteger(0) called - g_numArgs=0 -- arg[0]=153
    Info:MQTT:Publishing val 0 to rgbcwBulb/led_temperature/get retain=0
    Info:MQTT:Publishing val {"CT":0} to stat/rgbcwBulb/RESULT retain=0
    Received JSON: {"CT":0}
    Test_GetJSONValue_Integer will return 0 for CT
    ERROR: SelfTest assertion failed for (Test_GetJSONValue_Integer("CT", 0) == 153)
    Check src/selftest/selftest_tasmota.c - Test_Tasmota_MQTT_RGBCW - line 493
    Total SelfTest errors so far: 1
    Debug:CMD:cmd [CT 444]
    Debug:CMD: temperature (CT) received with args 444
    Info:MQTT:Publishing val 444 to rgbcwBulb/led_temperature/get retain=0
    Debug:CMD: temperature (CT) received with args 
    Error:CMD:Tokenizer_GetArgInteger(0) called - g_numArgs=0 -- arg[0]=444
    Info:MQTT:Publishing val 0 to rgbcwBulb/led_temperature/get retain=0
    Info:MQTT:Publishing val {"CT":0} to stat/rgbcwBulb/RESULT retain=0
    Received JSON: {"CT":0}
    Test_GetJSONValue_Integer will return 0 for CT
    ERROR: SelfTest assertion failed for (Test_GetJSONValue_Integer("CT", 0) == 444)
    Check src/selftest/selftest_tasmota.c - Test_Tasmota_MQTT_RGBCW - line 499
    Total SelfTest errors so far: 2
    

    You see there's a second call to CT or dimmer commands without an argument, but later argument[0] is requested and obviously expected to contain the value of the previous call...

    I didn't figure out which command exactly called the integer argument, but I would think the changed code is correct now)

    Could you please check if this really is a bug?
  • #46 21869246
    divadiow
    Level 38  
    Posts: 4928
    Help: 430
    Rate: 875
    could api bulk close a few PRs that are just enable/disable driver/feature in obk_config.h? Maybe with some standard close comment saying its a tidy exercise and to reopen or make new PR if anything further is needed.

    Code: Text
    Log in, to see the code

    Code: Text
    Log in, to see the code


    Added after 2 [minutes]:

    #2038 — enable BRIDGE
    - or merge if considered popular enough now on BL602

    Added after 3 [minutes]:

    maybe even close all older than 1/2/3 years open
  • #47 21872992
    divadiow
    Level 38  
    Posts: 4928
    Help: 430
    Rate: 875
    @p.kaczmarek2 big PR accept/reject/merge/close session needed!
  • #48 21873381
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    Ok I've decided to keep Bridge enabled, just please make sure that OTA still works. OTA breaks when BL602 OTA file is too large.
    Helpful post? Buy me a coffee.
  • #49 21873449
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    max4elektroda wrote:
    While at it I found (I guess) a bug in tokenizer.


    I tried to fix this in PR#2058.

    If Index is out of range (negative or above number of arguments) it will now return 0 or 0.0 (for float).
    In case of "int Tokenizer_GetArgIntegerRange(int i, int rangeMin, int rangeMax)" it will return rangeMin (to be sure, we don't return an unexpected value).

    I also added son tests to tokenizer selftest.

    After the change to tokenizer, some tasmota selftests failed:

    ,  Received JSON: {"CT":0}
    Test_GetJSONValue_Integer will return 0 for CT
    ERROR: SelfTest assertion failed for (Test_GetJSONValue_Integer("CT", 0) == 153)
    Check src/selftest/selftest_tasmota.c - Test_Tasmota_MQTT_RGBCW - line 493
    Total SelfTest errors so far: 1
    --
    Received JSON: {"CT":0}
    Test_GetJSONValue_Integer will return 0 for CT
    ERROR: SelfTest assertion failed for (Test_GetJSONValue_Integer("CT", 0) == 444)
    Check src/selftest/selftest_tasmota.c - Test_Tasmota_MQTT_RGBCW - line 499
    Total SelfTest errors so far: 2
    --
    Received JSON: {"Dimmer":0}
    Test_GetJSONValue_Integer will return 0 for Dimmer
    ERROR: SelfTest assertion failed for (Test_GetJSONValue_Integer("Dimmer", 0) == 20)
    Check src/selftest/selftest_tasmota.c - Test_Tasmota_MQTT_RGBCW - line 554
    Total SelfTest errors so far: 3
    --
    Received JSON: {"Dimmer":0}
    Test_GetJSONValue_Integer will return 0 for Dimmer
    ERROR: SelfTest assertion failed for (Test_GetJSONValue_Integer("Dimmer", 0) == 88)
    Check src/selftest/selftest_tasmota.c - Test_Tasmota_MQTT_RGBCW - line 560
    Total SelfTest errors so far: 4
    --
    Received JSON: {"Dimmer":20,"Fade":"OFF","Speed":1,"LedTable":"ON","Color":"0,0,0,7,0","HSBColor":"0,0,100","Channel":[0,0,0],"CT":0,"POWER":"ON"}
    Test_GetJSONValue_Integer will return 0 for CT
    ERROR: SelfTest assertion failed for (Test_GetJSONValue_Integer("CT", 0) == 444)
    Check src/selftest/selftest_tasmota.c - Test_Tasmota_MQTT_RGBCW - line 586
    Total SelfTest errors so far: 5
    --
    Received JSON: {"Dimmer":100,"Fade":"OFF","Speed":1,"LedTable":"ON","Color":"0,0,0,255,0","HSBColor":"0,0,100","Channel":[0,0,0],"CT":0,"POWER":"ON"}
    Test_GetJSONValue_Integer will return 0 for CT
    ERROR: SelfTest assertion failed for (Test_GetJSONValue_Integer("CT", 0) == 444)
    Check src/selftest/selftest_tasmota.c - Test_Tasmota_MQTT_RGBCW - line 613
    Total SelfTest errors so far: 6
    


    So I changed these seftests, I hope this is what it's meant to be:

    --- a/src/selftest/selftest_tasmota.c
    +++ b/src/selftest/selftest_tasmota.c
    @@ -488,13 +488,13 @@ void Test_Tasmota_MQTT_RGBCW() {
            */
            CMD_ExecuteCommand("CT 153", 0);
            SIM_ClearMQTTHistory();
    -       SIM_SendFakeMQTTAndRunSimFrame_CMND("CT", "");
    +       SIM_SendFakeMQTTAndRunSimFrame_CMND("CT", "153");
            SELFTEST_ASSERT_HAS_MQTT_JSON_SENT("stat/rgbcwBulb/RESULT", false);
            SELFTEST_ASSERT_JSON_VALUE_INTEGER(0, "CT", 153);
            SIM_ClearMQTTHistory();
            CMD_ExecuteCommand("CT 444", 0);
            SIM_ClearMQTTHistory();
    -       SIM_SendFakeMQTTAndRunSimFrame_CMND("CT", "");
    +       SIM_SendFakeMQTTAndRunSimFrame_CMND("CT", "444");
            SELFTEST_ASSERT_HAS_MQTT_JSON_SENT("stat/rgbcwBulb/RESULT", false);
            SELFTEST_ASSERT_JSON_VALUE_INTEGER(0, "CT", 444);
            SIM_ClearMQTTHistory();
    @@ -549,13 +549,13 @@ void Test_Tasmota_MQTT_RGBCW() {
            */
            CMD_ExecuteCommand("Dimmer 20", 0);
            SIM_ClearMQTTHistory();
    -       SIM_SendFakeMQTTAndRunSimFrame_CMND("Dimmer", "");
    +       SIM_SendFakeMQTTAndRunSimFrame_CMND("Dimmer", "20");
            SELFTEST_ASSERT_HAS_MQTT_JSON_SENT("stat/rgbcwBulb/RESULT", false);
            SELFTEST_ASSERT_JSON_VALUE_INTEGER(0, "Dimmer", 20);
            SIM_ClearMQTTHistory();
            CMD_ExecuteCommand("Dimmer 88", 0);
            SIM_ClearMQTTHistory();
    -       SIM_SendFakeMQTTAndRunSimFrame_CMND("Dimmer", "");
    +       SIM_SendFakeMQTTAndRunSimFrame_CMND("Dimmer", "88");
            SELFTEST_ASSERT_HAS_MQTT_JSON_SENT("stat/rgbcwBulb/RESULT", false);
            SELFTEST_ASSERT_JSON_VALUE_INTEGER(0, "Dimmer", 88);
            SIM_ClearMQTTHistory();
    
  • ADVERTISEMENT
  • #50 21873452
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    Why those tests fail?
    Code diff view: SIM_SendFakeMQTTAndRunSimFrame_CMD calls changed from to 153 and 444
    They are supposed to test for Tasmota behaviour - if you send command without argument, it returns current value via RESULT. Your changes to them defeats their purpose.
    Helpful post? Buy me a coffee.
  • #51 21873508
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    O.k, I see, the "fix" to selftest only overwrote the problem.
    But where in the whole chain of commands is Tokenizer_GetArgInteger(0) called to get the JSON value?
    I didn't succeed in trying to figure that out and therefore asked if you might recall...
  • #52 21873522
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    I think CT is published by http_tasmota_json_CT via JSON_ProcessCommandReply. I am yet sure why it broke after your changes. Can you specify which line exactly broke?

    Also, do you have debugger set up? It can help a lot

    Added after 2 [minutes]:

    Update: it seems that arguments count in "CT" (temperature function) is not checked, maybe we should check it and bail early without setting if it has no arguments?

    Added after 26 [seconds]:

    That could mean it was broken and worked in self tests due to broken tokenizer... nice finding @max4elektroda !
    Helpful post? Buy me a coffee.
  • #53 21873536
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    You lost me, but good if it makes sense to you. It's not only CT, but also DIMMER which failed with an equal issue.
  • #54 21873845
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    O.k., I think I realized the problem. So I started to "safeguard" the functions inside src/cmnds/cmd_newLEDDriver.c.

    This shows quite a "mass" of other problems. Mainly: selftest_led.c will constantly call "add_dimmer" like this:
         CMD_ExecuteCommand("add_dimmer 1", 0);

    But add_dimmer needs two arguments:

    Documentation screenshot for “add_dimmer” showing [Value][AddMode] and AddMode 0–2 behavior.

    
       iVal = Tokenizer_GetArgInteger(0);
       addMode = Tokenizer_GetArgInteger(1);
    

    So I get litterally hundreds of failing tests:
    
    $ ./build/win_main -runUnittests 2 2>&1  | grep   -i asser | grep led_dimm
    ...
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i + 1)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i + 1)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i + 1)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i + 1)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i + 1)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i + 1)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i + 1)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i + 1)
    ERROR: SelfTest assertion failed for Float_Equals(CMD_EvaluateExpression("$led_dimmer", 0), i)
    ...
    $
    $
    $
    $ ./build/win_main -runUnittests 2 2>&1  | grep   -i asser | grep led_dimm | wc -l
    594
    

    Can I assume, addMode should be "0" by default? Then we could reduce safeguard to one argument and use
    
       iVal = Tokenizer_GetArgInteger(0);
       addMode = Tokenizer_GetArgIntegerDefault(1,0);
    


    I implemented it like this in my PR and all failures are gone now :-).
  • #55 21873906
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    I think, as we discussed earlier, Tokenizer_GetArgInteger should return 0 by default anyway, so Tokenizer_GetArgIntegerDefault is not needed
    Helpful post? Buy me a coffee.
  • #56 21873949
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    I see, but, honestly, disagree. Yes, we can misuse the failure behavior, but should we, just because the failure response is incidentally the default value we want?
    I think it should be clear, if a command call is with one, with two or with one mandatory plus an optional second argument.
    And for one with an optional second we should use the command which reflects this: return the value or a default, if it's not present.
  • #57 21877281
    divadiow
    Level 38  
    Posts: 4928
    Help: 430
    Rate: 875
    p.kaczmarek2 wrote:
    Ok I've decided to keep Bridge enabled, just please make sure that OTA still works. OTA breaks when BL602 OTA file is too large.


    checked this on 4mb board with force 2mb partition layout in EF https://github.com/divadiow/BK7231GUIFlashTool/tree/refs/heads/bl602force2mb

    App partition headroom: about 262 KB
    OTA partition headroom: about 164 KB (using 1.18.262 OTA file as reference)
    No evidence of spill into OTA, media, PSM, or factory partitions.
  • #58 21877363
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    @max4elektroda well, you are certainly correct for most of the situations and languages, but on embedded, manually providing default 0 value takes flash size, which is limited in this particular scenario :D still , I merged your PR

    @divadiow is this ok?
    https://github.com/openshwprojects/OpenBK7231T_App/pull/2067

    Added after 3 [minutes]:

    @insmod can you review?
    https://github.com/openshwprojects/OpenBK7231T_App/pull/2051/changes
    This seems a bit bloated for me, but maybe I'm wrong. It's a #define, after all. So transparent to compiler after initial pass.
    Helpful post? Buy me a coffee.
  • #59 21877372
    insmod
    Level 31  
    Posts: 1366
    Help: 163
    Rate: 429
    >>21877363
    I've never used http client in obk, so i can't properly test it.
    But, there are some things that need to be fixed:
    HTTPClient_Test_Malloc calls for malloc, not os_malloc
    No HTTPClient_Test_Free and free is used, instead of os_free
    Free is called only if ret != 0? https://github.com/divadiow/OpenBK7231T_App/b...fcca4f634a/src/httpclient/http_client.c#L1229

    I checked only changes for http_client.c, not the whole http client.
  • #60 21877411
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14489
    Help: 651
    Rate: 12497
    That free seems correct. It is used to free http client when thread creation fails. Without it, httpclient would be leaked if thread creation fails.
    Helpful post? Buy me a coffee.
📢 Listen (AI):

FAQ

TL;DR: OBK supports 32 platforms and lists 817 devices; “firmware is fully open source.” Flash via UART, test in a PC simulator, and integrate with Home Assistant. [Elektroda, p.kaczmarek2, post #21794531]

Quick Facts

What is OpenBeken (OBK) and who should use it?

OBK is an open‑source firmware for Wi‑Fi IoT devices like relays, LEDs, thermostats, and meters. It targets users who want local control, added sensors, scripting, HA integration, and freedom from vendor clouds. The author states it is “fully open source, free.” [Elektroda, p.kaczmarek2, post #21794531]

Which chips and platforms are supported right now?

As of December 31, 2025, OBK ships binaries for about 32 platforms, including Beken BK7231/T/N/38/52, Espressif ESP8266/ESP32 families, Realtek Ameba series, Bouffalo BL602, Winner Micro W600/W800, XRadio XR806/XR809, Lightning Semi LN882H, ESWIN ECR6600, and others. Check the platforms matrix and linked docs. [Elektroda, p.kaczmarek2, post #21794531]

How do I flash OBK via UART?

You upload the firmware over UART using a USB‑to‑UART adapter and the BK7231 GUI Flash Tool. After flashing, join Wi‑Fi and configure GPIOs. The flasher can auto‑detect GPIO on many devices, reducing guesswork versus Tasmota. 1. Connect UART pins and power. 2. Use the GUI tool to write the binary. 3. Join Wi‑Fi and set roles. [Elektroda, p.kaczmarek2, post #21794531]

Can I run devices 100% locally without any cloud?

Yes. A core goal is freedom from vendor clouds and surveillance. After flashing, devices work fully offline, with local control, REST, MQTT, and HA connectivity. This avoids outages, surprise subscriptions, and vendor lock‑in. The author lists cloud independence as a key motivation. [Elektroda, p.kaczmarek2, post #21794531]

Does OBK integrate with Home Assistant and MQTT?

Yes. OBK connects to Home Assistant without limits and supports MQTT. The simulator even pairs with Home Assistant, letting you validate virtual devices before flashing hardware. This streamlines testing scenes, sensors, and lighting. [Elektroda, p.kaczmarek2, post #21794531]

How do online builds and automatic OTA updates work?

You can compile firmware entirely online via GitHub CI, so no local toolchain is needed. An OBK OTA tool can fetch artifacts on each build and update target devices automatically, including from pull requests and commits. “Build online, deploy OTA” describes the workflow. [Elektroda, p.kaczmarek2, post #21794531]

Is there a PC simulator for designing and testing devices?

Yes. The OBK Simulator for Windows/Linux implements a HAL with a visual schematic editor. You can test advanced circuits, Berry scripts, and HA pairing on your computer. Automatic tests also run on GitHub; failing commits get flagged. [Elektroda, p.kaczmarek2, post #21794531]

How many ready device templates or articles exist?

The community device list shows 817 entries dated 2025‑12‑31. You can filter by platform and by template versus full article. This accelerates onboarding and reduces wiring mistakes. [Elektroda, p.kaczmarek2, post #21794531]

What scripting language and automations does OBK support?

OBK supports Berry scripts across target hardware and in the Simulator. You can add logic, timers, and behaviors without recompiling. The driver list includes complex automations like PixelAnim, DMX, shutters, IR, and data logging helpers. [Elektroda, p.kaczmarek2, post #21794531]

Can OBK host custom web pages and a REST API on the device?

Yes. OBK integrates LFS file storage and a REST interface. You can build HTML/JS control panels, with optional GZIP compression to fit more content. This enables fast local dashboards without external servers. [Elektroda, p.kaczmarek2, post #21794531]

Any known OTA or platform edge cases I should watch out for?

Yes. Examples: XR809 OTA attempts crash the device; ESP8266 uses software PWM and may flicker; some bootloaders block OTA on certain Tuya BK7252 units; web‑based OTA can be corrupted on some chips, so use HTTP OTA instead. Review notes before updating. [Elektroda, p.kaczmarek2, post #21794531]

Does OBK support WPA3 and low‑power modes?

WPA3 support exists on many platforms, sometimes requiring specific ALT builds or sdkconfig flags. Deep sleep varies by MCU; some support only timed sleep and lack GPIO wake. Always check the platform table footnotes when planning battery builds. [Elektroda, p.kaczmarek2, post #21794531]

What drivers and sensors are already supported?

The list includes TuyaMCU (regular and battery), DMX, WS2812 animations, IR/RF, energy chips (RN8209, BL0942, HLW8112), environmental sensors (SHT3X, BMP280, DS18B20), LED drivers (SM2135, BP5758D), displays (MAX72XX, TM1637), shutters, and many more. “Drivers keep expanding.” [Elektroda, p.kaczmarek2, post #21794531]

What do terms like TuyaMCU, OTA, and Berry mean in OBK context?

In OBK, TuyaMCU denotes the driver family for Tuya‑based devices, including battery variants. OTA refers to updating firmware from built artifacts without disassembly. Berry is the embedded scripting language used by OBK and its Simulator. [Elektroda, p.kaczmarek2, post #21794531]

How do I contribute, request drivers, or support OBK?

Share device findings, propose drivers, or test platforms using the GitHub and forum links. You can also support development via the provided PayPal link. The author invites sensor and platform suggestions and thanks major contributors. [Elektroda, p.kaczmarek2, post #21794531]
Generated by the language model.
ADVERTISEMENT