Can I use OpenBK on a Tuya Aubess mini smart switch to drive a 16-channel relay board with chained 74HC595 shift registers, and how should I configure it?
Yes — OpenBK can drive a 16-channel relay board through chained 74HC595 shift registers, and the basic ShiftRegister driver was added and tested; two 74HC595 chips give you 16 outputs from three MCU pins [#20530051][#20530215][#20533505] Use the driver like `startDriver ShiftRegister [DataPin] [LatchPin] [ClkPin] [FirstChannel] [Order] [TotalRegisters]` and, in the later example, an extra invert flag is also shown: `startDriver ShiftRegister 24 6 7 10 1 1 0` [#20530215][#20533505] For a 16-channel setup, chain two registers and map channels 10–17, then set those channels to `Toggle` so they appear correctly in the HTTP panel [#20530215][#20533505] If your relay board is active-low, a global invert option was suggested as the simplest solution rather than per-bit flags [#20530381][#20530675][#20533505] The current implementation can handle up to 4 chained registers because the shift-out path is based on a 32-bit integer [#20530215][#20532809]
AI summary based on the discussion. May contain errors.
I have a tuya aubess mini smart switch (Belon2028N)
And I have a 16 channel relay board from aliexpress:
I also have some electronic junk that's useful for something.
I managed to flash OpenBK on the tuya module and it's working well, but the module has only around 9 IO pins...
My idea: use some shift registers, create 16 channels in the module and output these channels status sequentially so the shift registers can control all the relays.
Is this possible? Is there any script that could help?
Hello, I have did a similiar thing in the past with I2C port expander that provides up to 16 GPIO able to drive relays.
I2C port expanders are cheap:
And they are already supported.
Still, I can make that work for you with a shift register as well. Which approach do you prefer?
Thanks for the reply.
Do you have any thread about using those i2c modules?
Still, I would really like to have an option using the shift registers...
You see: I am Brazilian and the new president and his friends fucked up importing things from China for everyone. Shift registers I can buy for cheap in any electronics components store...
And I think that would be a cool option since using shift registers there's theoretically no limit to the number of outputs using only three IO in the processor
Ok. Thanks.
Is there any scripting examples for OBK?
I would like to analyze some to see if I can make some custom scripts
I know a little programming and I think it would be cool trying to make some custom codes for different modules
I am thinking about multichannel modules ...
I am studying the possibility of automating an entire home with only one smart module...
Tomorrow I plan on explaining better my plan, when I am in my shop with some of the modules I already have ..
I already made another thread about using RF 433Mhz modules...
Other things I am studying are:
I2C, UART, or other types of serial communication multichannel PWM controllers (for LED strips and dimmers)
Sending IR signals (to control TVs, and other devices that use IR sensors)
Using multiple buttons in one ADC (I already saw a thread talking about this one)
I am thinking about other options that might be useful while using the limited I/O I have in the Tuya module...
Later I will get some photos of what I have and explain better...
Yes, it should be possible to use one WiFi module to control lots of relays, but keep in mind that you will need a better power supply to driver those relays.
Let's do one feature at time.
I will look into that RF later, remind me if I forget.
For now, I am testing 74hc595:
So far hardcoded blink, but I will add a channels remap to 74HC595 now.
One 74HC595 has 8 outputs, but multiple 74HC595 can be chained. Are you going to chain 2 of them to get 16 IO?
Yes. I understand the need for a power supply that matches the usage of my modules... Doing one feature at a time is the way to go when making this kind of system. At this moment I am going to chain just two registers... But I think it would be a good feature if we could chain more.
I am going to have a general look in openBK source to see if I assimilate how it works... And if I figure it out I could even help coding some of the features I'm throwing here I didn't see much of the documentation on the system too... But I imagine I could help with it too if you want
You can easily fork OpenBeken and get it running with Github online builds on your fork. You don't even have to compile on your PC. It's very easy, you're welcome to help.
Currently port shift out function is working on 32 bit integer, so we can have 4 registers chained together
I have working basic driver, but only for a single register. Tomorrow I will add support to multiple ones.
There is a slight issue with HTML page style:
The current config approach for driver is following:
// startDriver ShiftRegister [DataPin] [LatchPin] [ClkPin] [FirstChannel] [Order] [TotalRegisters]
startDriver ShiftRegister 24 6 7 10 1 1
// If given argument is not present, default value is used
// First channel is a first channel that is mapped to first output of shift register.
// The total number of channels mapped is equal to TotalRegisters * 8, because every register has 8 pins.
// Order can be 0 or 1, MSBFirst or LSBFirst
// To make channel appear with Toggle, please also set the type:
setChannelType 10 Toggle
setChannelType 11 Toggle
setChannelType 12 Toggle
setChannelType 13 Toggle
setChannelType 14 Toggle
setChannelType 15 Toggle
setChannelType 16 Toggle
setChannelType 17 Toggle
More details tomorrow.
What would you like to know when it comes to source code? Do you know that OBK runs on Windows as well?
Since you told it can run in Windows... My first step would be setting it in my Windows machine. The I would figure your style of programming so I can keep the same style of code in my additions.
Assuming you are using C or C: You could set port shift to use a byte pointer so it could be used in any size the user wants.
I discovered OpenBK yesterday half an hour before going home, so I only managed to flash it in my module and didn't really get in the git page yet... Today is a holiday and I had to do the family visiting thing, so I am really limited in my studying. All my electronic and programming stuff is in my shop and I will only come back Thursday... So I will try to read what I can during the weekend so I can get to the shop and start doing hardware tests and building a decent PCB to house the shift registers and fix them in the relay board input.
Added after 9 [minutes]:
>>20530215 I saw that you set the command: startDriver ShiftRegister [DataPin] [LatchPin] [ClkPin] [FirstChannel] [Order] [TotalRegisters]
I think it would be better if you set the number of channels instead of the number of registers. Or set the start and end channels... Like: startDriver ShiftRegister [DataPin] [LatchPin] [ClkPin] [FirstChannel] [last channel][order] Or startDriver ShiftRegister [DataPin] [LatchPin] [ClkPin] [FirstChannel] [TotalChannels] [order]
Also, it should have a parameter to set it to active high or active low. Or can I set this in the channels individually?
Imagine if I have just 6 channels... It should be simpler to manage this way, I think.
And like in the relay board I am using: it is active low... So a parameter for that should be a good option
Shift register driver design tradeoffs and basic implementation
Assuming you are using c or c++:
You could set port shift to use a byte pointer so it could be used in any size the user wants.
It's C, and it's of course possible. I just have a habit of doing everything as simple as possible because OBK is multiplatform now and so platforms are limited by available flash size. I am trying to reduce the number of instructions in the binary ,etc.
smkassist wrote:
I think it would be better if you set the number of channels instead of the number of registers.
Or set the start and end channels...
Like:
startDriver ShiftRegister [DataPin] [LatchPin] [ClkPin] [FirstChannel] [last channel][order]
Or
startDriver ShiftRegister [DataPin] [LatchPin] [ClkPin] [FirstChannel] [TotalChannels] [order]
Hmm okay I will think about that, the number of registers was for the sake of simplicity, because when shifting out, the number of bits has to be a multiply of 8, and when user gives a number of shift register chips, it's easier to calculate.
smkassist wrote:
Also, it should have a parameter to set it to active high or active low. Or can I set this in the channels individually?
Is there a need to have per-bit swap flags? A global one could be added in a much more simple way.
There is still a lot of memory left on BK7231 platforms, but on WinnerMicro, which has only 1 MB flash, and on BL602 seemingly as well, we are pretty limited. Soon we will have to use the approach common in other firmwares and just create separate builds with separate features.
Some time ago I bought some units of this tuya module: tuya aubess mini smart switch (Belon2028N). I used some of them in my shop for testing and they work well.
Then, one day, I got a lightning strike in one of the external lights that were using the module and it fried.
So, last week I decided to analyse the damage and it turns out just the power supply part of the board is gone, and the wifi chip still works fine.
I decided to remove the wifi module from the relay board and tried to power it and it worked and I figured it had some IO not being used in the original board.
So I googled for some hacking for its chip (BL2028N). That's when I got to the OpenBK guide for the module Since I had one of those 16 channel relay boards laying around, I thought of reprogramming the tuya wifi module to drive it.
But tuya module hadn't enough IO and I remembered of the shift registers... That's when I started this thread.
I was thinking about starting a project using ESP32 to drive the relay board using home assistant and RF controller, but I think OpenBK plus the module from tuya is going to be a better and easier option.
@pkaczmarek262 You mentioned the possibility to run OpenBK in windows. Is there a guide for that?
Nevermind. I found the git page for building
Added after 1 [hours] 8 [minutes]:
So. I started trying to build it and I already see some missing important information on the guide:
First:
new_builtin_devices.c - this file is needed for building and VS gave me a missing file error... I saved a blank file and it stopped.
Second:
windows debug build uses SDL - I am familiar with the lib but it is not installed in my actual system. I will setup SDL in my machine and see if there's something else missing in the guide[/align]
Added after 6 [minutes]:
Third:
Glut lib is being used too
Added after 12 [minutes]:
Fourth:
Native File Dialog lib[/quote]
Added after 3 [minutes]:
Fifth:
Libdevil...
Added after 2 [hours] 8 [minutes]:
So... I managed to set all those dependencies, but I still have some problems to compile the windows test version.
looks like you linked some files that are in paths that are not in the project folder...
I got some undefined symbol errors and some files in solution manager are with the missing icon.
I inspected those files and they are referenced to paths outside of the project folder... So I don't have them...
Hello, sorry for the late reply, but it's 8AM morning in my country and I was sleeping earlier.
I can upload all dependencies to separate repository to make it easier, if you need it.
The important part is here:
You need to select Win32 build. This is because the posted list of files are not needed for Win32. They were just included in project for a reference.
Added after 48 [seconds]:
See how it looks for me:
they are excluded from build
Added after 1 [minutes]:
On windows, MQTT from Beken SDK is not used:
Windows has separate MQTT stub that works with Winsock (non-blocking sockets, single threaded):
There are tools bound to key 1, 2, 3, etc. Unfortunatelly there is no readme about it yet, and no icons for tools. I can try to write one today or tomorrow for you. In general, official release of simulator is on our TODO list. We are hoping to create a simulator tutorial for our Youtube channel someday:
https://www.youtube.com/@elektrodacom I will push shift register update today or tomorrow.
Can you tell me how do you get self test errors? I can see they relate to addClockEvent self test, but how? I tested right now and I get no self test errors.
Yes, I made OpenBeken and I made the simulator. It's my tool used to speed up development of OpenBeken.
I don't get self test errors, so it's strange, it's worth investigating, but maybe we can do it later.
There is no shift register component in the simulator indeed, but you can still play around with all other features of OBK, including MQTT and Hass Discovery. And you can test how scripts behave, etc.
And of course ShiftRegister driver is still running on Windows, so you can put breakpoints, etc, to debug and check how it works. It's very useful for the development.
I think those self test errors are not really important for now... The system seems to be running ok. I see that the simulator part is coded in C. I am reviewing the code and I think I can be useful with it.
I would really want to know why those self test errors happen. Maybe somehow your build is missing "addClockEvent" function?
The main idea of the simulator is to help speed up testing, development and debugging. Most of the issues we encounter are multiplatform and happen even on windows. Only a very tiny fraction of problems is BK7231-specific. That's why we can benefit from running OBK on Windows.
The ShiftRegister can now handle up to 4 registers, it should work well, although I haven't yet changed the number of registers to number of channels. I think that it doesn't give us much difference, especially that we have 64 channels (as far as I know) and I can't imagine a scenario where someone must use non-multiply-of-8 number of channels with shift register because he's running out of channels.... but maybe later I will change it, you can also do the change if you want (open a pull request).
It seems to work well:
I also saw your topic about RF addon, I will look into it.
What else can I do for you now? Is there any other peripheral you've got in mind?
I am focused on your simulator right now. I can try to track those errors and explain them to you later. About the number of registers, I think it's not a really important change. The way it's working seems to be exactly what I had in mind when I started the thread.
About the RF: I used my free time this weekend to understand better the usage of IR and RF and I concluded that the coding and encoding of them is practically the same. I didn't really test the IR option of OpenBK yet. But if it clones the remote codes like I've seen some Arduino examples I think I understand it. So, I think that turning the already existing IR in the system into a "remote-IR" and a "remote-RF", using mostly the same functions could be the way to go. It would be simple and wouldn't generate much more code
Added after 9 [minutes]:
Other than the RF integration, I think that's all for now. I am thinking of making some type of manager for Gate opening motors, but it's priority 0 right now... Maybe make a module to replace the entire board with some extra options, or simply sending the RF signal to mimic its RF remote... But it's just a popped idea with no importance for now
Our IR tries to mimic Tasmota behaviour. You can see an example here:
I don't know about RF behaviour. We would need to look how Tasmota handles it, I assume that it would require a single GPIO and some kind of driver. Probably an interrupt-based one, It's on my TODO list.
From my research, RF receiver sets its data pin the same way IR receiver data pin.
When receiving data, it sends the data through the data pin and the processor decodes it to a specific code that's bound to the pressed button... Really simple. I think it's even possible to just use your IR mode directly. Connecting RF data pin to where it would be the IR data pin.
The simulator seems to be working well. I am tracking the functions to draw things in the code so I can modify some things I see might be better. I had some issues with its resolution (my pc uses 1090x1080) but I found the line that sets the SDL resolution and changed it to fit my case.
The simulation surface is being rendered with an offset that makes part of it render outside my screen but I am already working around it too.
[
Info tool was listing subshapes index from 0 to last-1 and I changed the code so it's from 1 to last too.
Self-test error continues to appear every time I start the simulator. But nothing crashes or gets a strange behavior.
just to be sure: Which one is the root file for the simulator? Is it "sim_sdl.cpp"?
also: I think it would be a good practice to close this thread and start another to discuss the simulator, since shift register is done.
Create an account, log in here and be active on the forum — ads won't appear. Earn points for registering and replying.
The discussion revolves around integrating a Tuya Aubess Mini Smart Switch (Belon2028N) with a 16-channel relay board using shift registers. The user successfully flashed OpenBK firmware onto the Tuya module but faced limitations due to the limited number of IO pins. Suggestions included using I2C port expanders or shift registers, with a preference for the latter due to local availability. The 74HC595 shift register was identified as a suitable component for expanding IO capabilities. The conversation included technical details on wiring, scripting examples for OpenBK, and the potential for chaining multiple shift registers to control more outputs. The user also expressed interest in exploring other communication protocols and automation possibilities for home systems. AI summary based on the discussion. May contain errors.
TL;DR: Use 2 chained 74HC595 chips; “basic functionality” works for turning a Tuya Aubess Belon2028N with OpenBK into a 16-relay controller using only data, latch, and clock GPIO lines. This FAQ helps OpenBK users expand limited I/O safely and script it correctly. [#20533505]
Why it matters: A small Tuya WiFi module with about 9 I/O pins can control a full 16-channel relay board when outputs are serialized through shift registers.
Option
OpenBK status
Outputs discussed
GPIO use
Best fit
74HC595 shift register
Driver added in thread
8 outputs per chip; up to 4 chips
3 GPIO lines
Cheap local parts and relay expansion
I2C GPIO expander
Already supported
Up to 16 GPIO
I2C bus
Faster setup when parts are available
Key insight: The practical solution is to map OpenBK channels to 74HC595 outputs, then expose those channels as HTTP-panel toggles. For active-low relay boards, use the ShiftRegister invert parameter instead of rewiring every relay input.
Quick Facts
The Belon2028N Tuya module had only about 9 available I/O pins, so direct 16-relay control was not practical. [#20528489]
One 74HC595 provides 8 outputs, and chaining 2 chips gives the 16 outputs needed for the relay board. [#20530051]
The OpenBK ShiftRegister command uses 7 parameters after the driver name: DataPin, LatchPin, ClkPin, FirstChannel, Order, TotalRegisters, and Invert. [#20533505]
The implemented OpenBK driver can handle up to 4 chained 74HC595 registers, equal to 32 shift-register outputs. [#20532809]
For Windows simulation, the discussed setup used 2 GitHub repositories and required selecting a Win32 build in Visual Studio. [#20532101]
How can I use a Tuya Aubess Mini Smart Switch Belon2028N running OpenBK to control a 16-channel relay board with 74HC595 shift registers?
Flash OpenBK, chain 2 74HC595 registers, and start the ShiftRegister driver in autoexec.bat. Use 3 Tuya GPIO lines for data, latch, and clock. Map the first OpenBK channel to the first shift-register output. Then define 16 Toggle channels for the relay board. The thread’s final example starts at channel 10 and shows one 8-output register; use TotalRegisters 2 for 16 outputs. Expert quotation: “basic functionality of ShiftRegister seems to be working.” [#20533505]
What is a 74HC595 shift register and how does it expand the number of relay outputs from a Tuya/OpenBK module?
A 74HC595 expands OpenBK outputs by converting serial data from 3 GPIO lines into 8 parallel relay-control outputs. "74HC595 shift register is an integrated circuit that stores serial bits and presents them as parallel outputs, allowing multiple relay channels from few processor pins." The thread used it because the Belon2028N had about 9 I/O pins, while the relay board needed 16 control inputs. Chaining 2 chips gives 16 outputs. [#20530051]
How do I configure the OpenBK ShiftRegister driver in autoexec.bat for data, latch, clock, first channel, bit order, register count, and invert mode?
Configure it with startDriver ShiftRegister DataPin LatchPin ClkPin FirstChannel Order TotalRegisters Invert. Example: startDriver ShiftRegister 24 6 7 10 1 1 0. Here, GPIO 24 is data, GPIO 6 is latch, GPIO 7 is clock, channel 10 is the first mapped output, order 1 selects one bit order, 1 means one register, and 0 disables inversion. Set TotalRegisters to 2 for 16 outputs. [#20533505]
How should active-low relay boards be handled when using 74HC595 shift registers with OpenBK?
Handle active-low relay boards by using the ShiftRegister invert parameter when starting the driver. The relay board in the thread was active low, meaning a low-level output turns a relay on. The final OpenBK syntax includes an Invert argument after TotalRegisters. Use Invert 1 when the relay logic must be reversed globally. This keeps the hardware simple and avoids per-channel rewiring or custom logic. [#20533505]
What is the difference between using a 74HC595 shift register and an I2C GPIO port expander for controlling multiple relays in OpenBK?
A 74HC595 uses 3 GPIO lines and serial shifting, while an I2C expander uses the I2C bus and was already supported. The thread states that I2C port expanders are cheap and can provide up to 16 relay-driving GPIO. The 74HC595 option became useful because the user could buy those parts locally. The developer then added ShiftRegister support for OpenBK. [#20528766]
How many 74HC595 registers can OpenBK chain together, and how many relay channels does that provide?
OpenBK can chain up to 4 74HC595 registers in the implementation discussed. Each register provides 8 outputs, so 4 registers provide 32 relay-control outputs. The developer first mentioned a 32-bit shift function, then confirmed the driver could handle up to 4 registers. The thread’s 16-channel board needs only 2 registers. [#20532809]
Which OpenBK channel settings are needed to make shift-register-controlled relay outputs appear as toggles in the HTTP panel?
Set each mapped OpenBK channel type to Toggle after starting the ShiftRegister driver. For one 8-output register starting at channel 10, use setChannelType 10 Toggle through setChannelType 17 Toggle. For a 16-channel board starting at channel 10, continue the same pattern through channel 25. Without these channel-type commands, the relay outputs may not appear as clickable toggles in the HTTP panel. [#20533505]
What are the basic wiring connections between a BK7231/Tuya Belon2028N module, a 74HC595 shift register, and a 16-channel relay board?
Wire 3 OpenBK GPIO pins to the 74HC595 data, latch, and clock inputs, then connect each 74HC595 output to a relay input. The final example uses GPIO 24 for data, GPIO 6 for latch, and GPIO 7 for clock. Chain 2 74HC595 chips for 16 relay inputs. The developer summarized the connections as obvious according to the datasheet, so match each chip pin to its named function. [#20533505]
What kind of power supply is needed when one WiFi module controls many relays on a 16-channel relay board?
Use a power supply sized for the relay board, not only for the WiFi module. The developer warned that one WiFi module can control many relays, but the relays need a better power supply. A 16-channel relay board can energize many coils at once, so separate relay power from the small Tuya module supply when the board design allows it. Undersized power can cause resets or unstable switching. [#20530051]
Where can I find OpenBK scripting examples and documentation for creating custom automation scripts?
Use the OpenBK auto-generated documentation page and the examples shared in the thread. The developer pointed to the OpenBK GitHub README documentation when asked for scripting examples. The thread also shows commands such as startDriver, setChannelType, alias, addEventHandler2, SendGet, and startScript. These examples cover relays, IR events, HTTP commands, NTP, and MAX72XX clock scripts. [#20529763]
How do I build and run the OpenBK/OpenBeken simulator on Windows using the obkSimulator repository?
Build it by combining the OpenBK app repository with the obkSimulator repository, then selecting Win32 in Visual Studio. 1. Get OpenBK7231T_App and obkSimulator. 2. Copy the simulator contents into the OpenBK base directory. 3. Keep libs_for_simulator beside the .vcxproj file and build the Win32 target. The thread confirms localhost worked after this setup. [#20532101]
What are the required Windows dependencies for the OpenBK simulator, such as SDL, FreeGLUT, NFD, and LibDevil?
The Windows simulator setup discussed required FreeGLUT, LibDevil, NFD, and SDL. The user reported Visual Studio stopped asking for include or library files after adding those 4 dependencies. The simulator uses SDL for the windowed interface. The developer later provided a separate obkSimulator repository containing simulator support files, reducing manual dependency work. [#20532018]
Why might Visual Studio show missing files or linker errors like nfd_d.lib when building the OpenBK Windows simulator?
Visual Studio may show errors when the wrong build target or missing simulator libraries are used. The developer said several listed Beken SDK files were included only for reference and excluded from the Win32 build. Select Win32, not a firmware target. For LNK1104 cannot open file 'nfd_d.lib', the user resolved it by copying nfd_d.lib from a previous build into the expected library path. [#20532130]
What is OpenBK or OpenBeken, and how is it used to replace Tuya firmware on BK7231 and BL2028N smart modules?
OpenBK, also called OpenBeken, is firmware used to run custom local control on Tuya-style smart modules. In the thread, the Belon2028N module used a BL2028N chip, and the user flashed OpenBK successfully before adding relays. The project also runs on Windows for development. The developer noted that the simulator speeds testing because most issues are multiplatform, not BK7231-specific. [#20532809]
How do OpenBK IR remote features compare with possible 433 MHz RF remote support for controlling devices like lights or gate motors?
OpenBK IR support already existed, while 433 MHz RF support was still a future task in the thread. The developer said OpenBK IR tries to mimic Tasmota behavior and showed addEventHandler2 IR_Samsung examples. For RF, he found Tasmota used the rc-switch library and noted RF codes are similar to IR but different. He planned to buy an RF receiver before implementing it. [#20533323]
AI summary based on the discussion. May contain errors.
