logo elektroda
logo elektroda
X
logo elektroda

OpenBeken IoT device simulator - first early alpha version release for testing

p.kaczmarek2 7980 25
ADVERTISEMENT
📢 Listen (AI):
  • Connection diagram in OpenBeken IoT simulator with bulbs and LED strips.
    OpenBeken IoT device simulator allows you to run a virtual OBK device to try out OBK scripting, MQTT setup and Home Assistant pairing. You can also sketch connections of your virtual WiFi module to connect peripherals like buttons, relays, LED strips and even power metering modules and potentiometers.

    OBK simulator features
    - load and save sketches (JSON format) along with a simulated BK7231 flash memory dump (bin format; contains config, LittleFS, etc)
    - draw a circuit almost like you'd draw in Cadsoft Eagle
    - place and use buttons (they are simulated on voltage levels, so all Click, Double Click, Hold Start, Hold Release etc OBK events are working)
    - place relays/bulbs that you can control with buttons or OBK panel or scripts
    - whole OBK HTTP panel works on windows (as a HTTP server on port 80), the Javascript Web App also works, you basically get OBK device on Windows
    - MQTT is also working well, so you can pair your simulated machine with Home Assistant, experiment with HASS automation, test HA discovery
    place single color, CW (CCT), RGB and RGBCW strips and simulate their behaviour
    - use Tasmota Device Groups on Windows (fully functional, simulated OBK device can talk to real Tasmota/Beken devices on your network)
    - use OBK LittleFS to host HTML/javascript files and write OBK scripts
    - send GET packets with SendGET command (fully functional, your Windows OBK sim can send HTTP GET to any server)
    - and more....

    Basic OBK simulator usage
    Start the simulator executable. A basic window with sketch should appear:
    Screenshot of the OpenBeken IoT simulator with layout of components.
    At the same time, you should get a working OBK page on your local host, the default port is 80, just like with most HTTP programs:
    OpenBeken IoT simulator homepage with device status information and configuration buttons.
    As you can see, it's like a normal OBK device web page. Everything is functional there.
    Now, the basic OBK simulator is simple:
    - in the schematic editor window, you can place relays, buttons and other peripherals, basically to create your virtual OBK device
    - in the OBK simulator page, you can configure your device just like you would be configuring your physical device
    It is important to note that the schematic editor window is interactive, so all buttons there, relays, etc, are really working.


    Loading examples, creating new scenes, saving your work
    OBK schematic editor features a simple menu bar with schematic management options:
    OpenBeken Simulator window with File menu open.
    Load, save, etc options should be self-explanatory. Your current scene can be easily saved and loaded, just make sure to save manually after making changes to device flash memory - by default, they are NOT saved. To manage virtual devices, use FILE menu:
    - File->New (Empty) - will create an empty scene
    - File->Save - saves changes to current sketch
    - File->Save As - allows you to save current sketch to another file
    - File->Open Recent - provides a list of recently viewed sketches for your convenience:
    OpenBeken simulation window with file menu and circuit sketch.
    There are also available OBK simulator sample for download in our repository:
    https://github.com/openshwprojects/obkSimulator

    Changing startup resolution of schematic editor
    Just run your app with the command line parameters:
    
    -w 800 -h 600
    

    You can also create a bat file like:
    
    openBeken_win32.exe -w 800 -h 600
    

    and place it in the same directory as Simulator exe.
    You will also most likely want to skip the self test, so the final bat content will be:
    
    openBeken_win32.exe -runUnitTests 0 -w 800 -h 600
    

    You can change the port of HTTP page, this will allow you to run multiple instances of the simulator on your PC:
    
    openBeken_win32.exe -runUnitTests 0 -w 800 -h 600 -port 81
    


    Basic operations within schematic editor
    There is almost no GUI at all in the current alpha version of the OBK simulator, so you will need to use hotkeys. They are on the alphanumeric keyboard.
    - Key 1 is Use Tool, which allows you to press buttons, move sliders
    - Key 2 is Move Tool, which allows you to move objects
    - Key 3 is Wire Tool, which allows you to draw wires. Press LMB to draw, and press RMB to change draw mode
    - Key 4 is Delete Tool, which allows you to delete objects, labels and wires
    - Key 5 is Copy Tool, it can be used to quickly make a duplicate of clicked object
    - Key 6 is Info Tool, it prints debug information about object under mouse cursor
    - Key 7 is Text Tool, which allows you to print text on simulator sketch
    Currently active tool is displayed on GUI:
    OpenBeken Simulator interface showing the number of objects and wires, along with the active tool.

    Schematic editor interactions demo
    Let's load a sample scene first - the one with buttons and relays:
    Circuit diagram using elements such as bulbs, measurement modules, and LED strips.
    Now, note down which pins are used for relays and for buttons and configure them in OBK itself. P10 and P11 are relays (bulb icon):
    Table describing UART1 RXD and TXD pins and their serial interface functions.
    PWM2 and PWM3 are buttons:
    Technical documentation excerpt with information on PWM3 and PWM2 connectors.
    This is how I configured them:
    Screenshot of the configuration interface for the OpenBeken IoT simulator.
    Now, with left mouse button, click the virtual buttons:
    OpenBeken IoT module schematic with peripheral elements.
    As you can see, the relay (bulb icon) state changes, but with a delay. It's actually expected. It's long known "feature", it's the same in Tasmota. You need to consult our FAQ to read more about it:
    A section of the OpenBeken simulator instructions explaining settings for instant touch switch response.
    So let's enable this flag and try again.
    Screenshot of WinTest OBK user interface with various flag options.
    Now it works even better:
    Schematic diagram with various electronic components and connections on a grid.

    More detailed controls description and examples
    More details about the OBK simulator will be covered in the next topic. Check out our Smart Home Tutorials section for updates:
    https://www.elektroda.com/rtvforum/forum517.html

    Summary
    This is a very early test build of simulator, so there may be many problems and issues which are yet to be solved. Futhermore, the controls will be also improved soon. Still, if you have any feedback, let me know. I will do my best to adjust simulator to suit your needs.
    Attachments:
    • obkSimulator-20240331.zip (1.94 MB) You must be logged in to download this attachment.

    Cool? Ranking DIY
    Helpful post? Buy me a coffee.
    About Author
    p.kaczmarek2
    Moderator Smart Home
    Offline 
    p.kaczmarek2 wrote 14195 posts with rating 12076, helped 645 times. Been with us since 2014 year.
  • ADVERTISEMENT
  • #2 21027146
    divadiow
    Level 38  
    Wonderful thank you. I tried compiling this afternoon but it failed on stuff not being in c:\projects\... And I didn't pursue it yet. Will have a play with it.
  • ADVERTISEMENT
  • #4 21027906
    nielspiersma
    Level 9  
    I would also like to confirm it starts fine on my company managed Windows 11 Enterprise edition.

    Now my likely stupid question, can I and how would I use it for downloading the templates from existing devices?

    Niels
  • #5 21027910
    p.kaczmarek2
    Moderator Smart Home
    What do you mean by "downloading templates from existing devices"? I don't know....

    The only reasonable way I can think of is that when you know which GPIO is used for which role, you can set it in Simulator and then open Web App from Simulator, and then copy JSON template....

    but again, you can also write JSON by hand, if you know syntax...
    Helpful post? Buy me a coffee.
  • #6 21027994
    nielspiersma
    Level 9  
    Okay. no probs. I am just focused on flashing the devices.
    Not really the whole template thing, may need to give my self some time for investigating
    Niels
  • #7 21063768
    p.kaczmarek2
    Moderator Smart Home
    I am adding WS2812B driver self-tests and soon I will include them in Simulator as well:
    Screenshot of Visual Studio with code testing the WS2812B driver.

    Added after 1 [hours] 32 [minutes]:

    Screenshot of OpenBeken simulator showing the circuit schematic with WS2812B LEDs.

    Added after 36 [minutes]:

    Simulation of WS2812B wiring in OpenBeken Simulator with circuit schematic warning.
    Helpful post? Buy me a coffee.
  • #8 21066564
    p.kaczmarek2
    Moderator Smart Home
    I am working now on per-pixel LED animations:
    Circuit simulation with WS2812 LEDs in OpenBeken software.
    Helpful post? Buy me a coffee.
  • #9 21232905
    p.kaczmarek2
    Moderator Smart Home
    Simulator binaries should be now available in Releases, can anyone check if they are working?
    https://github.com/openshwprojects/OpenBK7231T_App/releases
    Helpful post? Buy me a coffee.
  • #10 21232919
    insmod
    Level 31  
    >>21232905 Haven't fully tested, but it starts and main page is working ok. v1.17.712
  • ADVERTISEMENT
  • #11 21232931
    p.kaczmarek2
    Moderator Smart Home
    Next step is probably running self tests once on Github Actions to chęck for breaking changes in each commit
    Helpful post? Buy me a coffee.
  • #12 21233922
    p.kaczmarek2
    Moderator Smart Home
    @insmod @divadiow now self tests are run on Github, github action will fail if any of self tests fails.
    For example, the following test checks WS2812 API:
    Code: C / C++
    Log in, to see the code

    Now, if anyone changes the WS2812 API and breaks it, we will immediatelly know.
    Helpful post? Buy me a coffee.
  • #13 21233963
    divadiow
    Level 38  
    excellent.
    Not that burning fw is a chore, but it's also nice to be able to just run an exe to check main app changes in a PR quickly.
  • #14 21235813
    p.kaczmarek2
    Moderator Smart Home
    Now virtual DHT11 has a "body", so there can be two or more of them:
    Screenshot from the OpenBeken simulator showing a test of two DHT11 sensors in a circuit.
    Helpful post? Buy me a coffee.
  • #15 21238382
    p.kaczmarek2
    Moderator Smart Home
    Progress towards simulation of WiFi module power on and off...
    Circuit simulation diagram of a WiFi module in OpenBeken Simulator.

    Screenshot of source code in C++ language.
    Helpful post? Buy me a coffee.
  • #16 21330476
    p.kaczmarek2
    Moderator Smart Home
    I love this Simulator, I can test OpenWeatherMap integration on Windows, without flashing any device:
    Screenshot of a Windows simulator testing OpenWeatherMap integration.
    Helpful post? Buy me a coffee.
  • #17 21759306
    p.kaczmarek2
    Moderator Smart Home
    And now simulator has a crude but working MAX7219 driver:
    LED display showing 12345 with circuit simulation software open on a monitor
    Helpful post? Buy me a coffee.
  • Helpful post
    #18 21862523
    max4elektroda
    Level 24  
    Just added some PRs I would like to be reviewed please @p.kaczmarek2 :

    Since long time I struggled with using OBK simulator was only possible with Windows binary - meaning using wine on Linux.
    Finally I found some time to investigate, also, why all Linux "selftest" tesitng was so slow.
    I found the two "culprits" (some wrong "#defines" for the MS "Sleep()" command, so Linux "sleep" was used leading to a x seconds(!) sleep instead of the intended x ms).
    And The simulator isn't started (hence no "Main_Init()), so neither commands were registered nor webserver was started.
    I added some more code to reflect it's Linux, not windows and changed the script setting device IP when calling webapp - using JS location will now not only fix e.g. W800 in AP mode but also allow to use it when using a port != 80.
    PR #2025
    A screenshot of GUI and one showing WebApp for the simulator

    Screenshot of LinuxSim_EECAFFEE status page showing MQTT info and buttons Config and Restart Screenshot of localhost “Config” page showing device info, device templates, and GPIO pin settings list.



    For my actual work I also suggest an extension to tokenizer for "named" arguments.

    I often struggle on the parameters order e.g. when starting a driver like AHT2x:
    is it <sda> <scl> <channel temp> <channel hum>?
    or <scl> <sda> <channel hum> <channel temp> ?
    or ...???

    So I'd like a call with "named" arguments like

    SDA=17 SCL=19 chan_h=3 chan_t=4
    which is totally equal to
    chan_h=3 SCL=19 chan_t=4 SDA=17

    so no need to remember the order and/or meaning of arguments.
    Code is in PR #2024





    Last PR here (some more to come, but they will rely on the above extension of tokenizer):

    If I use a driver without an own "IORole" selectable in config page, the usage is not shown there.

    e.g. startdriver aht2x 10 11 3 4 will start the driver, but I cant see it in the GUI:
    Screenshot of LinuxSim_EECAFFEE showing pins P0–P26 with dropdown role fields and channel index inputs

    My change will allow to call a new command

    setPinUsedString(int index, const char *str)

    which will show the pin as "used" in cfg config page, even if there is no "IORole" for this driver.

    Sample usage in AHT2x added in the PR:

       setPinUsedString(g_softI2C.pin_clk, "AHT2X SCL");
       setPinUsedString(g_softI2C.pin_data, "AHT2X SDA");
    

    which will show (for startdriver aht2x 10 11 3 4 as above)

    "Pin 10 used by AHT2X SCL" / "Pin 11 used by AHT2X SDA"

    Screenshot of LinuxSim_EECAFFEE showing pins P0–P26 with role dropdowns and channel index fields

    Code is in PR #2026

    Added after 9 [minutes]:

    Maybe a "teaser" about what might come:

    Spoiler:


    I2C simulator for some sensors: BMP280/BME28, AHT2X, SHT3x/SHT4x, CHT8305/CHT8310/CHT8315

    Screenshot of “WinTest_3145CAFF” status page with sensor readings and Config/Restart buttons

    VEML7700 driver (and VEML7700 simulated sensor)
    Screenshot of LinuxSim web panel showing VEML7700 readings: Lux292.05 and WHITE4780
  • #19 21863467
    p.kaczmarek2
    Moderator Smart Home
    Simulator fix merged, I also want to merge I2C emulation when ready.

    I am not sure about these named arguments, what is the memory footprint for that? I added Shutters drivers to obk core release today, and it will also certainly have flash memory impact...

    Maybe we could also merge pin usage string because it seems light and useful. Probably it could be used by WS2812 driver etc or TuyaMCU. I can see a point here. Just... I am not sure if it should be a hard lock. Maybe also introduce third argument? setPinUsedString(pin, string, driver) and clear on driver shutdown? But again... memory. I guess I will probably merge base version?
    Helpful post? Buy me a coffee.
  • #20 21863635
    max4elektroda
    Level 24  
    Thanks for merging and the first review.

    For the "tokenizer" I can lower footprint by giving up one "style", since for now you can use two possibilities: "SDA=PA1" or "-SDA PA1".

    I needed some extra handling for the very theoretic case STR="is a string" (the quoted value is "inside" tokenizers argument.

    If we give up this special case, both would be possible with similar extra memory.

    "-SDA PA1" has the advantage and disadvantage, that next arg is the value (no further calculation) - but we need to check, if a value is given at all
    "SDA=PA1" doesn't need to check for another arg, but needs to handle value itself.

    Which one would you prefer? I can probably make two versions and check the additional memory needed.


    p.kaczmarek2 wrote:
    Maybe we could also merge pin usage string because it seems light and useful.


    I can take another look. For now, it would be drivers responsibility to set the string to "NULL" (freeing memory fro string and remove the usage message)

    Will focus on finishing DCF77 as you gave it highest priority.

    Maybe you can decide on another point:

    I recently made an SHTXX driver (serving SHT3x and SHT4x) with included multi sensor possibility.

    While at it, I also made a first (working) prototype for an "xHTxx" driver to work for SHT3x/SHT4x/AHT2x/CHT38xx.
    It's larger than all 3 drivers selected but has (in my eyes) several advantages:

    - Introducing multi sensor for all three families (you only set an upper limit, an then can have any mix of sensors up to that limit)
    - And it will use some auto mode to test, which sensor is connected, so user can simply give SCL and SDA line:

    startdriver xHTxx SDA=10 SCL=20

    and driver will test all the known addresses and distinguish between the versions in case the calculation formulas or commands are different (like SHT3x/SHT4x or CHT8305/CHT831x.)

    So on the good side: No need trying figure out the used chip on your own...

    Do you think its worth continuing, or should I better abandon the work?
  • ADVERTISEMENT
  • #21 21863650
    p.kaczmarek2
    Moderator Smart Home
    Drivers have also high priority. I would lower priority of new commands syntax.

    On a second consideration, I would rather offer an alternative to commands syntax. Drop the firmware change and extend the web app:
    - let web app fetch the current commands JSON list from GitHub (if CORS allows)
    - when typing, autosuggest matching command names
    - under input field, show hints for arguments
    - in extended version, under command field, you can even show the required driver
    - the same mechanism could be applied to LittleFS, as a simple syntax helper...

    That way we'll get much better, more advanced and user friendly "command hints" at 0 memory footprint. The only downside would be that it requires Github (network) connection for work, but.... do you test your devices offline? I don't think so.... in worst case you can host web app locally.
    Helpful post? Buy me a coffee.
  • #22 21863781
    max4elektroda
    Level 24  
    I just updated DCF77 driver to actual code - ready to merge

    And I found, I use similar extended code since some time, only it's used in the driver hence no win from a common code base ;-)

    Further optional arguments are
    
        "fall" per default, a rising edge will mark the "bits",
            if you need a falling edge (e.g. if using an opto-isolator), use this argument
        "httpstat"        add some details from driver on main page
        "end0=<value>"    set max duration of 0 bit to <value> ms
        "start1=<value>"  set min duration of 1 bit to <value> ms


    My main reason (beside I often forget the arguments order) is you can easily have more optional arguments.

    If you want to give, lets say the cycle for the measurements of a sensor like AHT2x, actually we would be forced to put in all (optional/default) arguments "prior" to that one.

    now it's "startdriver aht2x <SCL> <SDA> <temperature channel> <humidity channel>"

    And we need to know this! There's no "args:" for drivers, so we need to look inside the drivers code to see:
    
       g_softI2C.pin_clk = Tokenizer_GetPin(1, 9);
       g_softI2C.pin_data = Tokenizer_GetPin(2, 14);
       channel_temp = Tokenizer_GetArgIntegerDefault(3, -1);
       channel_humid = Tokenizer_GetArgIntegerDefault(4, -1);
    


    So to add a new argument, we must add it as the fifth one - all other four must be present to set the next.

    The additional size for the extension is not easy to find. Here are some W800 builds without and with extension to "tokenizer" (only added the code - not used):

    ls -l output/*/*.fls
    -rw-rw-r-- 1 max max 705636 Mär 16 15:40 output/dev_20260316_154008/OpenW800_dev_20260316_154008.fls
    -rw-rw-r-- 1 max max 705624 Mär 16 15:41 output/dev_20260316_154037/OpenW800_dev_20260316_154137.fls
    -rw-rw-r-- 1 max max 705816 Mär 16 15:52 output/dev_20260316_160154/OpenW800_dev_20260316_155254.fls
    

    The smaller(!) one is the ones WITH the unused extension.
    Only using the new posssible code will add size, the last firmware (less than +200 bytes) is with

    diff --git a/src/cmnds/cmd_main.c b/src/cmnds/cmd_main.c
    index c5c5bc75..f6279ca6 100644
    --- a/src/cmnds/cmd_main.c
    +++ b/src/cmnds/cmd_main.c
    @@ -1321,6 +1321,12 @@ commandResult_t CMD_ExecuteCommand(const char* s, int cmdFlags) {
            const char* p;
            const char* args;
     
    +// START dummy code
    +       char * d1 = Tokenizer_GetArgEqualDefault("X",NULL);
    +       int d2 = Tokenizer_GetArgEqualInteger("X",1);
    +       int d3 = Tokenizer_GetPinEqual("X",1);
    +// END dummy code
    +
            char copy[128];
            int len;
            //const char *org;
    




    By writing here: Some dull but helpful work will be to add "args:" to drivers documentation (//drvdetail: )

    Will check the other open drivers (SHT4 / Multi AHT2x) next (SHT4 driver also uses new tokenizer, will rewrite), then turn to I2C simulator and then webapp...
  • #23 21863846
    p.kaczmarek2
    Moderator Smart Home
    max4elektroda wrote:

    My main reason (beside I often forget the arguments order) is you can easily have more optional arguments.


    I wasn't sure before, but right now I am almost 100% sure that we will use the way I described - fetch commands from github and have "autocomplete-like" hints.

    I also want to avoid = because I am thinking about extending math expressions for more arguments in more flexible manner.
    Helpful post? Buy me a coffee.
  • #24 21863863
    max4elektroda
    Level 24  
    But we don't know the commands, at least in case of a driver?!? From where should we know the order of pins/channels for a driver?

    Sure, we know there's "startdriver" followed by a valid driver name.
    We can, provided some good source present, know about all drivers, so we propose a driver name - but that's the end - or am I'm just missing some crucial point?
  • #25 21864257
    p.kaczmarek2
    Moderator Smart Home
    Ah, I see. You are referring to the "startDriver XYZ 1 2 3 4" syntax? Well, that's tricky one, we don't have this yet in our docs, we probably should introduce markers for that and include it in docs.

    Everything else (like syntax of led_basecolor_rgb) is available.
    Helpful post? Buy me a coffee.
  • #26 21864350
    max4elektroda
    Level 24  
    p.kaczmarek2 wrote:
    Ah, I see. You are referring to the "startDriver XYZ 1 2 3 4" syntax? Well, that's tricky one, we don't have this yet in our docs,


    Yes, exactly, I saw the same "issue"...

    max4elektroda wrote:
    By writing here: Some dull but helpful work will be to add "args:" to drivers documentation (//drvdetail: )


    I'll try if I can find a scripted approach to identify them...

    BTW: I tried with my "NEO6M" (GPS) driver, in which I also made use of this kind of arguments.

    Actual code will accept starting like:

    startDriver NEO6M setclock setlatlong fakelat=4190.5  fakelong=01245 


    I changed that to use the new tokenizer code (as you pointed out no "ARG=" but -ARG) so it is now including the extension of tokenizer and changing driver to use tokenizer insetad of "local code.

    startDriver NEO6M setclock setlatlong -fakelat 4190.5 -fakelong 01245 


    The resulting binaries (actually the driver is (probably unintended) always set for W800 and BL602, - I will fix that later) are "not significantly" changed.

    Why this word? Looking in the artifacts from the testing branch I made, the resulting binaries for W800/BL602 are changed like this:

    Size +/-    Filename                             neo_token_7ca5f04ca6bb    neo_token_42729cf3a8c0
    -144        OpenBL602_XX_berry.bin                          902364                     902220
    -128        OpenBL602_XX.bin                                777012                     776884
    ...
    136         OpenW800_XX.fls                                 707612                     707748



    my local build for W800 shows W800 size decreases 136 bytes with the tokenizer version and the "absolute" sizes are different, too :

    (first "Unchanged" next "Changed")
    
    $ ls -l output/dev_20260317_*/*.fls
    -rw-rw-r-- 1 max max 707692 Mär 17 11:11 output/dev_20260317_111126/OpenW800_dev_20260317_111126.fls
    -rw-rw-r-- 1 max max 707556 Mär 17 11:12 output/dev_20260317_111206/OpenW800_dev_20260317_111206.fls


    I can't really explain that, bu the change is "marginal", I would say.

    Added after 3 [hours] 35 [minutes]:

    Made PR #2034 to disable NEO6M driver for W800 and BL602 (and fixed some bugs and did some tuning while at it ;-))
    Ready to merge - driver works for me and otherwise it will only disable the defines for W800 and BL602.


    Screenshot of OpenW800 web interface showing time, GPS data, and buttons: Config, Restart, Launch Web Application, About

    Added after 4 [hours] 45 [minutes]:

    Before doing more work ...
    Here's my basic Idea for the docs: Add "init" to drivers //drvdetail: matching the drivers "Init" function called.
    Then in driver code, add the details for the drivers arguments. I think its much easier to do the "documentation" in the file with the actual driver code, not in "drv_main.c"...


    Screenshot of C source code with driver metadata comments and a documentation preview table below

    Added after 53 [minutes]:

    First try - see documentation for drivers here in my testing branch
📢 Listen (AI):

Topic summary

The OpenBeken IoT device simulator is an early alpha release designed to emulate OBK devices on Windows, enabling users to test OBK scripting, MQTT configuration, and Home Assistant integration without physical hardware. It supports loading and saving device sketches in JSON format alongside simulated BK7231 flash memory dumps, allowing virtual circuit design similar to Cadsoft Eagle. The simulator includes simulated peripherals such as buttons (with voltage-level event handling), relays, bulbs, LED strips, power metering modules, and potentiometers. The full OBK HTTP panel operates as a local server on port 80, and MQTT functionality is integrated for communication testing. Users confirmed compatibility with Windows 11 Enterprise and Home editions. Development progress includes adding WS2812B LED driver self-tests, per-pixel LED animations, multiple virtual DHT11 sensors, and simulation of WiFi module power cycling. Simulator binaries are available on GitHub Releases, with automated self-tests running on GitHub Actions to ensure stability. The tool facilitates rapid testing of firmware changes and integrations such as OpenWeatherMap without device flashing.
Summary generated by the language model.
ADVERTISEMENT