logo elektroda
logo elektroda
X
logo elektroda

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

p.kaczmarek2 8304 25

TL;DR

  • OpenBeken IoT device simulator runs a virtual OBK device for scripting, MQTT setup, Home Assistant pairing, and simulated peripherals like buttons, relays, LED strips, metering modules, and potentiometers.
  • It lets you load and save JSON sketches plus BK7231 flash dumps, draw circuits, and interact with buttons, relays, bulbs, and RGB/RGBCW strips in Windows.
  • The simulator exposes the OBK HTTP panel on port 80 and supports features like LittleFS-hosted files, SendGET, MQTT, and Tasmota Device Groups.
  • MQTT and Home Assistant discovery work, and the simulated Windows device can talk to real Tasmota/Beken devices on your network.
  • This is a very early alpha, so many problems remain and the controls still need improvement.
Generated by the language model.
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 14409 posts with rating 12350, helped 650 times. Been with us since 2014 year.
  • ADVERTISEMENT
  • #2 21027146
    divadiow
    Level 38  
    Posts: 4851
    Help: 421
    Rate: 854
    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  
    Posts: 60
    Help: 3
    Rate: 20
    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
    Posts: 14409
    Help: 650
    Rate: 12350
    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  
    Posts: 60
    Help: 3
    Rate: 20
    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
    Posts: 14409
    Help: 650
    Rate: 12350
    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
    Posts: 14409
    Help: 650
    Rate: 12350
    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
    Posts: 14409
    Help: 650
    Rate: 12350
    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  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21232905 Haven't fully tested, but it starts and main page is working ok. v1.17.712
  • #11 21232931
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14409
    Help: 650
    Rate: 12350
    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.
  • ADVERTISEMENT
  • #12 21233922
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14409
    Help: 650
    Rate: 12350
    @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  
    Posts: 4851
    Help: 421
    Rate: 854
    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
    Posts: 14409
    Help: 650
    Rate: 12350
    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.
  • ADVERTISEMENT
  • #15 21238382
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14409
    Help: 650
    Rate: 12350
    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
    Posts: 14409
    Help: 650
    Rate: 12350
    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
    Posts: 14409
    Help: 650
    Rate: 12350
    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  
    Posts: 745
    Help: 47
    Rate: 183
    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
    Posts: 14409
    Help: 650
    Rate: 12350
    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  
    Posts: 745
    Help: 47
    Rate: 183
    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?
  • #21 21863650
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14409
    Help: 650
    Rate: 12350
    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  
    Posts: 745
    Help: 47
    Rate: 183
    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
    Posts: 14409
    Help: 650
    Rate: 12350
    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  
    Posts: 745
    Help: 47
    Rate: 183
    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
    Posts: 14409
    Help: 650
    Rate: 12350
    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  
    Posts: 745
    Help: 47
    Rate: 183
    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.
Generated by the language model.

FAQ

TL;DR: With 7 editor hotkeys and a local web panel, the early OpenBeken simulator lets Windows users test OBK scripting, MQTT, and Home Assistant pairing before flashing hardware. One tester said, "it starts fine" on Windows 11 Enterprise. It solves fast validation, scene building, and LED-driver experimentation from one executable. [#21027130]

Why it matters: This simulator shortens OpenBeken setup, debugging, and driver-testing time by moving early validation from physical devices to a virtual OBK environment.

Option Strength Limitation Best use
Named tokenizer arguments Easier to remember driver parameters Adds firmware/parser complexity Driver commands with many optional arguments
Web-app autocomplete hints Better UX at 0 memory footprint Needs docs and usually network access General command discovery and syntax help

Key insight: The simulator is most valuable as a pre-hardware test bench: it runs the OBK HTTP page, MQTT, scenes, and virtual peripherals locally, then expanded into LED, sensor, and Linux-related improvements over 2024-2026.

Quick Facts

  • The simulator exposes the OBK HTTP panel on port 80 by default and can run additional instances on other ports, such as 81, from the command line. [#21027130]
  • Startup window size is configurable at launch with -w 800 -h 600, so the schematic editor can open at 800 × 600 px instead of the default size. [#21027130]
  • The alpha schematic editor relies on 7 alphanumeric hotkeys: Use, Move, Wire, Delete, Copy, Info, and Text. That keeps the GUI minimal but functional. [#21027130]
  • LED self-tests shown later validate virtual strips with a 128-byte DDP packet, pixel assertions, and a 6-pixel initialization example for SM16703P and PixelAnim. [#21233922]
  • Release testing progressed from forum-shared binaries to a reported working simulator build labeled v1.17.712, with GitHub self-tests added afterward to catch regressions automatically. [#21232919]

How do I get started with the OpenBeken IoT device simulator for testing OBK scripting, MQTT setup, and Home Assistant pairing on Windows?

Start the simulator executable on Windows and open the local OBK page in your browser. The thread says the HTTP panel works like a normal OBK device and uses port 80 by default. Then use the schematic window to place virtual parts and the web panel to configure them. This gives you OBK scripting, MQTT setup, and Home Assistant discovery testing without flashing hardware. [#21027130]

What steps are needed to create a virtual OBK device with buttons and relays in the simulator and make them work through the OBK web panel?

You need to place parts, map pins, and configure roles in OBK. 1. Load or build a scene with buttons and relay or bulb icons in the schematic editor. 2. Note the assigned pins, such as P10 and P11 for relays and PWM2 and PWM3 for buttons in the example. 3. Set those roles in the OBK web panel, then click the virtual buttons with the left mouse button. The relay state will follow the configured logic. [#21027130]

Why do virtual relay or bulb icons in the OpenBeken simulator change state with a delay after a button click, and which setting improves the response?

The delay is expected and matches a known behavior also seen in Tasmota. The author explicitly says the lag after a button click is a long-known “feature,” not a simulator-only bug. Enabling the referenced flag from the FAQ improves the response and makes the virtual relay react better in the demo. [#21027130]

How can I save and reload an OpenBeken simulator scene together with the simulated BK7231 flash memory and LittleFS data?

Use the File menu and save manually after any flash-memory changes. The simulator can load and save sketches as JSON and keep a simulated BK7231 flash dump as a BIN file containing config and LittleFS data. File > Save writes the current sketch, Save As writes a new file, and Open Recent lists previous sketches. Flash changes are not saved automatically. [#21027130]

Which keyboard hotkeys control the alpha-version OBK schematic editor, and what does each tool do?

The alpha editor uses keys 1 through 7 on the alphanumeric keyboard. Key 1 selects Use, 2 Move, 3 Wire, 4 Delete, 5 Copy, 6 Info, and 7 Text. Wire uses the left mouse button to draw, and the right mouse button changes draw mode. The active tool is shown in the GUI. [#21027130]

What is LittleFS in OpenBeken, and how is it used inside the simulator to host HTML, JavaScript, and OBK scripts?

"LittleFS is a small embedded filesystem that stores files inside device flash, keeping persistent web assets and scripts." In this simulator, the thread says LittleFS content is part of the simulated flash dump and can host HTML and JavaScript files plus OBK scripts. That lets a virtual OBK device serve web content and script logic on Windows like a real device. [#21027130]

What are Tasmota Device Groups, and how do they interact with a simulated OpenBeken device on a real network?

"Tasmota Device Groups are a network-control feature that lets compatible devices exchange state and commands directly across the same network." The simulator supports them on Windows, and the author says the simulated OBK device can talk to real Tasmota or Beken devices on your network. That makes the simulator useful for mixed virtual-and-physical testing before deployment. [#21027130]

How do I change the OpenBeken simulator startup resolution, skip self-tests, and run multiple instances on different HTTP ports?

Launch the executable with command-line parameters. Use -w 800 -h 600 to set a startup size of 800 × 600 px. Add -runUnitTests 0 to skip self-tests, and add -port 81 to move the web panel off port 80. That combination lets you open multiple simulator instances on one PC. [#21027130]

What is the best way to use the OpenBeken simulator for downloading or recreating templates from existing devices when I already know the GPIO roles?

Use it to recreate the template, not to automatically extract one from a live device. The author says the practical method is to enter the known GPIO roles into the simulator, open the simulator web app, and then copy the resulting JSON template. If you already know the syntax, you can also write the JSON by hand. [#21027910]

Why might compiling or running the OBK simulator outside a default Windows-style path like c:\projects fail, and what should I check first?

A build can fail if project paths or assumptions are hard-coded for a Windows-style layout. One tester said compilation failed on items not being in c:\projects\..., then stopped investigating. Check the build scripts, include paths, and any absolute-path assumptions first. If you only need testing, use the provided executable or later release binaries instead of compiling immediately. [#21027146]

How does the OpenBeken simulator help test WS2812B, SM16703P, PixelAnim, and per-pixel LED animations without flashing real hardware?

It provides a virtual LED test bench with self-tests, driver commands, and later animation work. Posts across 2024 show WS2812B driver self-tests, SM16703P pixel assertions, PixelAnim checks, and then per-pixel animation work. The author later said, “I love this Simulator,” because it lets him test integrations on Windows without flashing any device. That speeds driver validation and UI checking. [#21330476]

What does DDP packet parsing mean in the OpenBeken LED self-tests, and how is it used to validate virtual pixel data?

DDP packet parsing means feeding a simulated lighting-data packet into the LED code and verifying the resulting pixels. In the shown self-test, a 128-byte fake DDP packet is created, pixel data begins at offset 10, and the parser updates three virtual pixels. Assertions then check exact RGB results like 0xFF, 0x00, and 0xFF. That confirms the virtual LED pipeline works end to end. [#21233922]

Named tokenizer arguments versus web-app autocomplete hints in OpenBeken: which approach is better for driver commands and why?

The thread favors web-app autocomplete hints over new tokenizer syntax. The project maintainer said he was “almost 100% sure” they would use GitHub-fetched command metadata with autocomplete-like hints. His reason was better usability at 0 memory footprint, while named arguments increase firmware complexity and still need driver documentation for startDriver XYZ 1 2 3 4 syntax. [#21863846]

How can Linux support for the OpenBeken simulator be improved so the GUI, web server, and self-tests work properly without relying on Wine?

Fix the timing macros, start the simulator correctly, and detect Linux-specific behavior. A contributor said Linux tests were slow because wrong Sleep() defines caused second-long sleeps instead of millisecond delays. He also found the simulator was not started fully, so Main_Init() never ran, commands were not registered, and the web server stayed down. His PR aimed to make native Linux use possible instead of relying on Wine. [#21862523]

Which new virtual peripherals and drivers have been added or proposed for the OpenBeken simulator, such as DHT11 bodies, WiFi power control, MAX7219, GPS, and I2C sensor emulation?

The simulator expanded well beyond buttons and relays. Posts mention virtual DHT11 bodies, WiFi module power on and off simulation, a working MAX7219 driver, GPS-related NEO6M command work, and proposed I2C sensor emulation for BMP280 or BME280, AHT2x, SHT3x or SHT4x, CHT8305 or CHT831x, plus VEML7700. That shows a clear move toward broader sensor and display validation inside the simulator. [#21862523]
Generated by the language model.
ADVERTISEMENT