logo elektroda
logo elektroda
X
logo elektroda

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

p.kaczmarek2 1548 24
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
📢 Listen (AI):
  • Set of Wi-Fi development boards connected via USB, ready for programming
    For several years, Elektroda has been developing universal, open-source software for various types of Wi-Fi-controlled building automation devices, such as relays, LED lamp and LED strip controllers (including WS2812), thermostats, energy meters, or there temperature, humidity, motion sensors. Along with the firmware, a list of supported devices and extensive documentation of their internals is created. Here I will show the status of this project as of 2025.12.31.

    Why change the firmware?
    Let us now consider what the overall purpose of this project is. Why change the firmware when the products already come with the manufacturer's software? Is there any point in combining? Motivations may vary, below I list the reasons in random order:
    - extending functionality - after changing the firmware you can add sensors, scripts, mechanisms at will. Then you have full control over GPIO, you can add a temperature sensor to every light switch, etc., or even an IR receiver, whatever you prefer
    - freedom from the cloud and potential surveillance - the reprogrammed device operates 100% locally and does not report data anywhere
    - security in case of problems at the manufacturer - many devices are dependent on the cloud, so if something goes wrong at the supplier, we may end up with useless equipment. The supplier has also been known to introduce a paid subscription after the fact....
    - connecting to different ecosystems and Home Assistant - not every device can be easily connected to HA or this is limited, OBK supports HA without limits
    - use the device as an Arduino-style DIY platform - once the firmware is changed, any project can be realised on a supported Wi-Fi chip
    - energy saving and product life extension - e.g. for LED lamps ( presentation )

    Repository and project name
    The project was started as firmware for BK7231 chips and christened as OpenBeken/OBK . At the moment the name has remained, but the whole thing is a multi-platform application supporting around 32 platforms.

    Platforms supported as of 2025.12.31
    Here is the status of platform support as of 2025.12.31. For the latest version, see GitHub .
    I made the platform count according to the criterion of separate binary files. This means that e.g. the W800 / W801 is counted as one platform, because it has a common batch, and the ESP32 is counted as several platforms, because there are separate versions of C3, C6, etc.
    ✅ ✅¹² ✅ ✅ ✅ ✅ ✅ ✅ ✅⁴ ✅ ✅ ❌ ❌ ✅ ✅ ❌ ✅ ❌ ❌ ✅ ❌
    Platform Family WPA3 OTA GPIO GPI Interruption UART PWM ADC Deep Sleep WDT SPI LED IR
    BK7231T Beken ✅¹² ✅¹²
    BK7231N Beken ✅¹²
    BK7231S / BK7231U Beken ✅¹
    BK7238 Beken
    BK7252 BK7252 Beken ⚠️¹'¹⁴
    BK7252N Beken
    XR809 XRadio ❌⁵ 62705↩ ✅⁸
    XR806 XRadio ✅⁸
    XR872 / XF16 XRadio ✅² ✅⁸
    BL602 / LF686 Bouffalo Lab ✅⁴
    W800 / W801 Winner Micro
    W600 / W601 Winner Micro Winner Micro
    LN882H Lightning Semi ✅⁴ >❗️
    ESP8266 / ESP8285 Espressif ⚠️¹³ ✅²'⁴ ✅⁴ ✅⁷ ❗️
    ESP32 / C2 / C3 / C5 / C6 / C61 / S2 / S3 Espressif ⚠️¹³ ✅⁴ ✅¹⁰
    TR6260 Transa Semi ❗️³'⁴ >❌ ✅⁸ ✅⁹
    RTL8711AM (Ameba1) Realtek ❗️ ✅⁴ ✅⁸
    RTL8710B (AmebaZ) Realtek ✅⁴ ✅⁸
    RTL8710C / RTL8720C (AmebaZ2) Realtek ✅⁴ ✅⁸
    RTL8720D / RTL872xCSM / RTL8720CS (AmebaCS) Realtek ✅⁴ ✅⁸ ❗️
    RTL8721DA / RTL8711DAF (AmebaDplus) Realtek ❗️
    RTL8720E / RTL8710ECF (AmebaLite) Realtek ❗️
    ECR6600<br> ESWIN ✅⁸ ❗️ ❗️¹¹
    TXW81X Taixin ❗️
    RDA5981 RDA5981 RDA 62ba66ba5f
    [/table:1a437e6cef]
    Quote:
    ✅ - Works
    ❓ - Not tested
    ❌ - Not implemented
    ❗️ - Defective / not working
    ⚠️ - Warning
    ➖ - Not applicable

    Quote:
    ¹ Success dependent on partition layout set in bootloader. SPI flash QIO firmware required for a certain OTA
    ² Excluding 1 MB variant
    ³ Implemented, but no file generation tool
    ⁴ No OTA HTTP, only via web application
    ⁵ OTA attempt crashes the device
    ⁶ OTA in web application is corrupted, use HTTP OTA
    ⁷ Software PWM - possible flickering
    ⁸ Note pin assignment - some PWM channels overlap
    ⁹ WDT configured in SDK
    ¹⁰ Timed sleep only, no wake-up via GPIO
    ¹¹ After waking up, device does not connect to Wi-Fi until power is removed again
    ¹² Only in _ALT builds
    ¹³ Must be manually enabled (CONFIG_ESP8266_WIFI_ENABLE_WPA3_SAE / CONFIG_ESP_WIFI_ENABLE_WPA3_SAE = y in sdkconfig.defaults)
    ¹⁴ OTA on Tuya BK7252 is not supported (the stock bootloader does nothing, the custom one does not encrypt the main - brick partition)


    How is the batch uploaded?
    The batch is uploaded via UART, a USB to UART converter is needed. We have our own flasher for this:
    https://github.com/openshwprojects/BK7231GUIFlashTool
    BK7231 Easy UART Flasher interface with expanded chip type selector
    Once uploaded, we connect the device to our Wi-Fi and configure the GPIO. Our Flasher often knows how to auto-detect the GPIO - you don't have to guess, you don't have the problem you have with Tasmota.
    And even if you did have to guess - we still have a tool that makes it easy:
    GPIODoctor in OpenBeken - a convenient way to learn about GPIO roles in an IoT device [EN]
    GPIODoctor in OpenBeken - a convenient way to learn about GPIO roles in an IoT device [EN]

    Online and automatic OTA compilation
    The project can be compiled fully online. This is used even in normal firmware development. Toolchain on the local computer is unnecessary.
    More information:
    System online builds OpenBeken - firmware compilation for all platforms on Github [EN]
    System online builds OpenBeken - firmware compilation for all platforms on Github [EN]
    In addition, we have a tool that with each compilation downloads and updates the firmware itself on the target devices:
    How to programmatically access pull requests, commits and download artifacts from Github[EN] How to programmatically access pull requests, commits and download artifacts from Github?
    How to programmatically access pull requests, commits and retrieve artifacts from Github? [EN]
    https://github.com/openshwprojects/OBKotaTool


    Windows-based simulator and automated testing
    Another distinguishing feature of this project is the OBK Simulator on Windows/Linux. It is an implementation of HAL for these platforms combined with a visual schematic editor.
    Connection diagram in OpenBeken IoT simulator with bulbs and LED strips.
    OpenBeken IoT device simulator - first early alpha version for testing [EN]
    OpenBeken IoT device simulator - first early alpha version for testing [EN]
    This allows you to test advanced circuits directly on your computer. Everything you need is supported - even pairing with Home Assistant, so you can connect a virtual device via MQTT.
    The other obvious consequence of the Windows port is that automatic tests can be used easily:
    OpenBeken automated testing on Windows and target platforms [EN]
    Automatic OpenBeken tests on Windows and target platforms [EN]
    These are fired up on GitHub with each compilation. If tests detect a problem, commit is flagged as incorrect.


    Device list
    In addition, the OBK community maintains a list of devices. Most of these are either supported or in development, although I've recently put Zigbee devices on there as well - just for information.
    https://openbekeniot.github.io/webapp/devicesList.html
    Devices can be grouped by platform and by description type (GPIO template or full article).
    As of 2025.12.31 we have 817 devices there .

    Berry scripts
    OBK can be scripted Berry - of course this also works in the Simulator, so you can test without the target device. Information:
    Berry scripts for various IoT platforms - OBK scripting tutorial, part 1 [EN]
    Berry scripts for various IoT platforms - OBK scripting tutorial, part 1 [EN]

    Fi-Fi module as hosting
    OBK has LFS integrations and can host files. A REST interface is also present, so you can make your own panel in HTML and Javascript:
    OpenBeken as mini HTTP hosting - writing pages in Javascript, REST API Tasmota etc [EN]
    OpenBeken as mini HTTP hosting - Javascript page writing, REST API Tasmota etc [EN]
    LFS supports GZIP compression for files downloaded by the browser - you can fit a lot of text that compresses really well:
    Efficient hosting of a simple HTML page on a microcontroller - GZip compression in HTTP [EN]
    Efficient hosting of a simple HTML web page on a microcontroller - GZip compression in HTTP [EN]


    supported drivers
    Here is an incomplete list of supported drivers. Many of them support several devices of this type each, so even if something is not on the list, it may still be supported.
    TuyaMCU (regular and battery-powered) GirierMCU, TCA9554, DMX, PIR, PixelAnim (WS2812 animations), Drawers, HGS02, PinMutex, GosundSW2, TCL (climate control), OpenWeatherMap, Widget (HTML controls), Charts, NTP, DS3231, HTTPButtons, SimpleEEPROM, MultiPinI2CScanner, I2C, RN8209, BL0942, PWMG, BL0942SPI, HLW8112SPI, ChargingLimit, BL0937, CSE7761, CSE7766, MAX6675, MAX31855, PT6523, TextScroller, SM16703P, SM15155E, IR (infrared), RC (radio), IR2, DDPSend, DDP, SSDP, DGR, Wemo, Hue, PWMToggler, DoorSensor, ADCButton, MAX72XX_Clock, SM2135, BP5758D, BP1658CJ, SM2235, BMP280, MAX72XX, BMPI2C, CHT83XX, MCP9808, KP18058, ADCSmoother, SHT3X, SGP, ShiftRegister, AHT2X, DS1820, DS1820_FULL, HT16K33, TM1637, GN6932, TM1638, HD2015, Battery, Bridge, UartTCP, TXWCAM, DHT11, DHT12, DHT21, DHT22, Shutters (curtains).
    Status as of 2025.12.31 , more will be added soon!

    Additional materials
    The OBK documentation is available in our repository:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/README.md
    For example, here is a list of drivers:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/drivers.md
    A lot of loose material on OBK is in our tutorial section:
    https://www.elektroda.pl/rtvforum/forum517.html
    Some of the material is in the form of videos - e.g. on YouTube:
    https://www.youtube.com/@elektrodacom


    Summary
    Shown firmware is fully open source, free, and supports 32 platforms at this point. It is uploaded via the UART, although detailed instructions depend on the platform in question. It allows the device in question to be free from the cloud, freely scripted and programmed, and linked to Home Assistant.
    The firmware has many drivers (sensors, communication protocols, LED controllers, etc.) and integrations (DDP, DMX, Tasmota Device Groups).
    In addition, the whole thing has numerous facilities to facilitate development and testing, such as online testing and compilation, a simulator on Windows, or there tools for automatic OTA from a given PR (pull request - change proposal) on GitHub.
    If you want to support the project, feel free to:
    https://paypal.me/openshwprojects
    Do you have suggestions as to what interesting sensors or peripherals can still be supported and supported? Or do you know of any other useful platforms?


    Special thanks to @insmod, @divadiow , @DeDaMrAz , @max4electrode for their huge contribution to the project!

    Cool? Ranking DIY
    Helpful post? Buy me a coffee.
    About Author
    p.kaczmarek2
    Moderator Smart Home
    Offline 
    p.kaczmarek2 wrote 14025 posts with rating 11814, helped 635 times. Been with us since 2014 year.
  • ADVERTISEMENT
  • #3 21811063
    divadiow
    Level 38  
    >>21810808

    echoing those words. It's been amazing watching this develop and, where possible, contribute to the advancement of the project.
  • #4 21811089
    rb401
    Level 39  
    p.kaczmarek2 wrote:
    The firmware shown is fully open source, free, and supports 32 platforms at the moment.


    Since such a sizable number of devices can be reprogrammed to unified OBKs I am interested in a niche issue about which it is difficult to find any specific material.
    That is, is there any possibility of using devices with unmodified OBK software as simple inputs, outputs for simple minimalist automation without the need to build a Smart Home infrastructure i.e. MQTT etc. ?

    For example, some ESP with a program written under Arduino, with an AP set up, to which a socket with OBK is logged and the program is able to control the socket and read its status. Or, for example, a thermometer from the OBK where the aim is to read the temperature remotely and, for example, display it on the display or use this thermometer as a thermostat sensor.
  • #5 21817824
    p.kaczmarek2
    Moderator Smart Home
    @rb401 I'd be happy to help you with this and do some presentation, but I think you need to specify what you mean.

    OBK is very simple in terms of input/output, you have a channel system there, you can read them and set them via the API. Plus you have scripts in there, there's a version with Berry too.

    So much so. you can do minimalist automation on the OBK itself. E.g. using Tasmota Device Groups or using SendGET to send status. No need for an intermediary. The light switch will drive the LED strip itself.

    You can connect a thermometer (DS18B20, DHT11, others) to any OBK device and encrypt this as a thermostat. You can connect this thermometer physically (to free pins), or send the value from the other device via SendGET.

    You can connect a display to the OBK device (although here you need to make a build with a driver on GitHub) and display the measurements on it - fully scripted, simply from the DHT11 the measurements go to the so-called "channel" and then from the channel to the display.

    An additional ESP is not needed, but of course you can use it as a coordinator if you want. But this is unnecessary.

    Can you write me in more detail what effect you would like to achieve? I'd be happy to elaborate in the form of a "tutorial", but I need to know what the goal is.

    I myself have, for example, 3gang (three-button) switches at my place, but I only have one wire in the boxes for the light, and the other two touch buttons control, for example, the LED strip on the other side of the room, without intermediaries, directly, without a coordinator.
    Helpful post? Buy me a coffee.
  • #6 21822818
    rb401
    Level 39  
    p.kaczmarek2 wrote:
    I'd be happy to help you with this and do some presentation, but I think you need to specify what you mean.



    The idea is to be able to easily obtain with Smart Home devices (specifically from OBK) similar functionality to, for example, a system with Modbus.
    That is, addressable devices, each with addressable bit variables for writing and reading and addressable registers also for writing and reading. This is all controlled from the controller, where there is a control algorithm with the addresses of the devices used and their internal addressing. The WiFi network is only used as a two-way radio connection, exclusively for the devices and the controller.
    From the software side of the controller, the control is also similar to Modbus. So, for example, if you want to switch on a relay in a network socket, you specify the socket ID and write the bit where the relay is connected (WRITE SINGLE COIL).
    If, say, we need to read the temperature from a sensor then we read the appropriate registers and decode the number, the temperature value.
    Of course, it's not about full Modbus compatibility (although that could have been interesting) but the same philosophy of the system, where all the intelligence sits in the controller and the devices only work as simple inputs, outputs with two-way radio communication. No need to configure them beforehand etc. .

    And why OBK?
    Because Smart Home devices are becoming increasingly common and, more importantly, cheap (thermometers, switches and sockets already cost around PLN 10). This makes them a very attractive alternative to stand-alone construction. The only major problem is the lottery of what sits inside them as a microcontroller. The OBK elegantly unifies such issues and, above all, you know what is and what is not in them.


    p.kaczmarek2 wrote:
    But. minimalist automation is what you will do on the OBK itself. E.g. using Tasmota Device Groups or using SendGET to send state. No need for an intermediary. The light switch will drive the LED strip itself.


    This is also very interesting, although, as you write minimalist automation is not really what I have in mind.
  • #7 21822963
    p.kaczmarek2
    Moderator Smart Home
    And isn't it enough to use, for example, ESP32 as an MQTT broker?
    Helpful post? Buy me a coffee.
  • #8 21823637
    rb401
    Level 39  
    p.kaczmarek2 wrote:
    And isn't it enough to use, for example, ESP32 as an MQTT broker?


    If there was a broker put in place, the whole thing wouldn't be there. MQTT client libraries are available for various languages and in this way the control of such devices, from a central controller, becomes trivial. The thing is that for one or up to a few devices where no functionality beyond simple control is needed, the system gets considerably hardware complicated and loses practical sense.
    The other thing is that I haven't come across an implementation of an MQTT broker for something weaker than a Linux raspberry. If there's one for ESP32 as you write, that's cool, but I don't really feel like it would fit together with the controller program. So that means MQTT is out.
    You would need some other protocol for low level control of the Smart Home device and supposedly there are some other methods of access but no specific material or examples.
  • ADVERTISEMENT
  • #10 21833298
    p.kaczmarek2
    Moderator Smart Home
    Nice feature. With this custom build system in Docker, anyone will be able to create OBK build for any platform with any driver enabled (via obk_config.h).
    “OBK Build Tool” window with build settings, BK7231N selected, and a drivers list.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #11 21833311
    insmod
    Level 30  
    Excellent work! I'll probably switch from WSL1 to that.

    Would it build TXW? It must execute some .exe to finish build. (i once saw python replacement to them on gh, don't remember where though)
  • #12 21833317
    DeDaMrAz
    Level 21  
    insmod wrote:
    Would it build TXW?


    Love it, thank you, I haven't tested all the platforms atm but TWX will not build yet, I'll fix that now.
  • #13 21833382
    PRL
    Level 41  
    Great stuff and I think I'll be dismantling all my sockets for reprogramming. I have a dozen of them.
    With the software mentioned, is it possible to configure the devices myself so that, for example, the consumption of a few selected sockets is summed up, as in the picture?
    Software such as eWelink or Tuya shows the energy consumption, but lacks a simple function to add up the consumption of selected devices. Well, unless I haven't noticed such functionality.


    White smart plug with power button, plus Tuya, Google Assistant, and Amazon Alexa compatibility icons
    Helpful post? Buy me a coffee.
  • #14 21833608
    p.kaczmarek2
    Moderator Smart Home
    Video for the topic:





    @PRL where do you want to add up these values? The firmware shown is for individual devices, it's not Home Assistant. We don't have a control panel here, or at least at the moment.... because I might think about giving support for one of the devices to have this role....

    Do you want to aggregate this data on the Home Assistant panel?
    Helpful post? Buy me a coffee.
  • #15 21834131
    DeDaMrAz
    Level 21  
    Guys @insmod @max4elektroda @divadiow @p.kaczmarek2

    Can you point out which PR's are ready to be merged, tested, meaningful etc. - we have a lot of open PR's so some type of house keeping should be in order?

    thanks!
  • ADVERTISEMENT
  • #16 21834139
    PRL
    Level 41  
    p.kaczmarek2 wrote:
    Do you want to aggregate this data on the Home Assistant panel?


    Anywhere. I have part eWelink and part Tuya and unfortunately nowhere have I found the ability to add up the consumption from all/selected outlets. It's a bit tiresome to click on each socket in each app and read the energy/amount consumed.
    Helpful post? Buy me a coffee.
  • #17 21834340
    divadiow
    Level 38  
    >>21834131

    I haven't anything open in main app :(

    Not sure if @max4elektroda's W600 flashvars one is finished

    Added after 1 [minutes]:

    Also @protectivedad has some
  • #18 21834343
    DeDaMrAz
    Level 21  
    Nice ping, thanks!

    Let's focus on the "house cleaning" as much as possible for a bit so we can all get a good enough starting point for more work and improvements - 2026 should be amazing for OBK.

    Feel free to ping anybody who can contribute.
  • #19 21834348
    p.kaczmarek2
    Moderator Smart Home
    This ready?
    Quote:


    Btw: digitalWriteFast could be faster... read as well. On Beken, I think it goes through Beken driver api?

    Added after 1 [minutes]:

    This is awaiting third party confirmation:
    Quote:

    new_pins: fix for inconsistent pin value on wake after sleep#1922
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1922

    Anyone can greenlight/redlight? @insmod @max4elektroda
    Helpful post? Buy me a coffee.
  • #20 21834357
    insmod
    Level 30  
    I did 'greenlight' it earlier, at least because logic is sound.
    But i've nothing to test it on, because none of my devices requires this.

    My IR pr is ready https://github.com/openshwprojects/OpenBK7231T_App/pull/1979
    Tested on W800. Both arduino IR and IRRemoteESP receive and send just fine.

    Added check for IR in powersave for beken. Only RF sleep if BL0937, IR or RC. RF + MCU in all other cases.
  • #21 21834363
    DeDaMrAz
    Level 21  
    I decided to create a test_all script for all platforms and all available drivers and save logs from the builds so I can fix it all, here is the first log out form it:


    Terminal screenshot showing test summary: 33 total, 17 successes and 16 failures, with OK and FAIL platform lists.
  • #22 21834375
    p.kaczmarek2
    Moderator Smart Home
    Nice, merged both. Good idea with isBKSensitiveDriversRunning. Just... is the issue only on BK? Maybe other platforms are also affected by powersave + interrupt combo?
    Helpful post? Buy me a coffee.
  • #23 21834386
    insmod
    Level 30  
    On RTL8710B if powersave > 2 - bl0937 values are halved. Same should be on RTL8720D if > 1.
    Potentially on ESP32s if cpu clock is manipulated.
  • #24 21834499
    max4elektroda
    Level 23  
    divadiow wrote:
    Not sure if @max4elektroda's W600 flashvars one is finished

    Yes, PR#1936 is ready to merge. Thanks to @insmod introducing easyflash here, too, it's no more than enlarging the config (and zeroing the new area).
    Don't know if that case happens often, but we might clear memory in any case when updating from V3 to V4/V5 with it's larger are. Actually only WiFi password is set to "" in this case for all other platforms exept W600.

    Screenshot of a C code diff adding PLATFORM_W600 conditional block with memset and strcpy_safe calls.

    And we might think of removing (or using) the two defines ALLOW_SSID2 and ALLOW_WEB_PASSWORD:
    If I'm correct, after this PR they are now unconditionally set
    Screenshot of a C code diff in src/new_pins.h highlighting changes to platform-related macros.

    If the webgui is right (I don't recall it in detail) and second SSID only works on Beken, we might also use the ALLOW_SSID2 to disable it (even in webif) for non Beken platforms...

    But, back to the first topic:
    PR#1936 is ready to merge
  • #25 21834676
    p.kaczmarek2
    Moderator Smart Home
    Ok, merged 1936. Thank you.
    Helpful post? Buy me a coffee.
📢 Listen (AI):
ADVERTISEMENT