logo elektroda
logo elektroda
X
logo elektroda

[CBU / BK7231N] WS2811C, Microphone, 4 Switch : PROGLO Obi Smart Light Bars, 2 Pack

jwp_nz 5427 2

TL;DR

  • PROGLO Obi Smart Light Bars, 2 Pack H: 285mm Incl Base were flashed from Tuya to openBK on a CBU BK7231N controller.
  • The board drives SM16703P LEDs in GRB order and uses WS2811C 12V chips with 6 addressable segments per light.
  • The 4-button control board exposes pins 14, 15, 20, and 22, and pin14 produced continuous press spam in the console.
  • DDP works as the main integration path with existing WLED lights, while local dimmer and color controls currently override incoming DDP packets.
  • The USB-C output always carries 12V without a PD trigger, so it should only be used with the supplied lights.
Generated by the language model.
ADVERTISEMENT
📢 Listen (AI):
  • Two red LED light bars on a table, with a sleeping cat and a control board nearby.
    Kia ora/Hi all,

    I picked up several of these : PROGLO Obi Smart Light Bars, 2 Pack H: 285mm Incl Base

    Two vertical PROGLO Obi Smart Light Bars on a white background changing colors.
    Link

    on special about a year ago and finally got around to getting them flashed with something useful.

    They are a CBU BK7231N based PCB, with 12V input and step-up/down ladder along with a Microphone input (unused/untested as I never paired them to tuyacloud) and oddly a USB-C connector for 12V VCC and Data to the strips which use the SM16703P driver in openbk with GRB colour order.

    Everything seems to be working fine, except that I get continuous press SPAM from Pin14 which is SW1 in the console- I am wondering if this is possibly something to do with how the Microphone on the board is wired in? Inverting the pin doesn't resolve. It doesn't seem to affect functionality and you could just leave pin14 undefined If you want to silence it.

    The controller board is very nice to open, just pop from an easily priable gap along the USB-C connector, no hot-glue etc . There are convenient solder pads on the reverse of the board for initial flashing.

    Pin-map sketch with PCB

    Diagram and photo of the LED controller PCB.

    Reverse
    Pin diagram and reverse side of the LED light controller board.

    LED Strip inside case/diffuser:

    Close-up of an electronic circuit with LED components and mounting screws.

    For some brain-dead reason the output is a USB-C connector and the input a mini-12V DC barrel, this is actually relatively dangerous as the USB-C output port doesn't have any sort of PD trigger so just spits out 12V all the time when plugged; don't go using the USB-C port for anything other than the supplied lights. This should have been the Feeder in the original design , but am guessing they dropped the PD controller to save some money and used the connector on the output side instead.


    Cat approved result:
    Two red LED light bars on a table, with a sleeping cat and a control board nearby.

    They are using WS2811C 12V Controllers in Groups of 3 LED (for a total of 6 addressable segments per Light). For whatever reason (probably voltage drop) Each of the pairs are wired in parallel so the second light in a chain just mimics the first. You could probably, cut the 2nd light cord , drill a hole and solder the second light to the top of the first and get a single strip of 12 addressable, but I didn't try as the form factor and diffusion of these units is quite nice as is.

    I have these attached as DDP segments to existing WLED controlled lights. In the example I provide basic stand-alone dimmer and colour control (taken directly from https://www.elektroda.com/rtvforum/topic4036716.html ) as commented section in the attached autoexec.bat script. I would like to use the 4 switches and have local colour/brightness control along-side the DDP receiver. Currently however it appears that any local dimmer controls etc override the DDP. So I leave them configured as basic DDP targets OOTB. WLED handles this by poping up an overide when a DDP packet is received asking the user if they want to ignore DDP in tthe WebUI once or until reboot. Something like this could probably be scripted so that a button press for power down overrides the DDP until another press. But I haven't investigated how openbk handles button actions.

    Since there are 4 available momentary switches on the control unit, I would ideally like to map each one to a rolling over 0-255 per color channel control and the 4th as a On - Off + Long Press Dimmer. If anyone has an example for doing any of the above - would be keen to see how.

    There are some more photos and videos and commentary on my fediverse thread here:
    https://cloudisland.nz/@jwp/112317522315834359

    The only flag I have set is the MQTT one, if you want to use with local only you'll need to set flag4.

    Attached original firmware dump (no useful config for cloudcutter). Also I couldn't use the gui tool and used hid_downloader to flash along with openbk tools to dump the full original bin from Fedora40.


    Cheers

    -Joel

    example autoexec.bat
    
    ///By default we just run the driver for the LED and setup NTP and DDP(poorman's e1.31) which can be added to an existing WLED controller triple commented blocks can only be run individually
    
    startDriver SM16703P
    startDriver NTP
    startDriver DDP
    
    SM16703P_Init 6 GRB
    
    /// This will allow for basic WebUI control - currently will overide DDP so we disable it by default
    ///Also need to set flag Flag 4 - [LED] Force show RGBCW controller (for example, for SM2135 LEDs, or for DGR sender)
    //Dimmer
    //again:
    //SM16703P_SetPixel all $led_enableAll*$led_red*$led_dimmer/255 $led_enableAll*$led_green*$led_dimmer/255
    //$led_enableAll*$led_blue*$led_dimmer/255
    //SM16703P_Start
    
    //delay_s 1
    //goto again
    
    /// Dimmer only follows choose this or the above - can't use both
    // number of LEDs
    //setChannel 5 18
    
    // init
    //SM16703P_Init $CH5
    
    // on channel 1 dimmer change, refresh
    //addEventHandler OnChannelChange 1 startScript autoexec.bat refresh
    
    // refresh function
    //refresh:
    
    // iteration variable
    //setChannel 6 0
    
    // loop for each LEd
    //again:
    
    
    


    template.json

    
    {
      "vendor": "Proglo/OBI",
      "bDetailed": "0",
      "name": "PROGLO Obi Smart Light Bars, 2 Pack H: 285mm Incl Base",
      "model": "PGLSB100-2PK",
      "chip": "BK7231N",
      "board": "CBU",
      "flags": "1024",
      "keywords": [
        "WS2811C",
        "4 Buttons",
        "Microphone"
      ],
      "pins": {
        "14": "Btn_Tgl_All;0",
        "15": "Btn;0",
        "20": "Btn;0",
        "22": "Btn;0"
      },
      "command": "",
      "image": "https://obrazki.elektroda.pl/6705621000_1714016724_thumb.jpg",
      "wiki": "https://www.elektroda.com/rtvforum/topic4050771.html"
    }
    
    
    Attachments:
    • proglo-pgslb100-2pk.bin (2 MB) You must be logged in to download this attachment.

    Cool? Ranking DIY
    About Author
    jwp_nz
    Level 2  
    Offline 
    Pākehā with a strong Māori bi-cultural upbringing and Identity (Ngati Ngorongo - Taranaki hapu). Engineer, Geek, Psyc/Social researcher, Red hat employee. Always have an opinion, sometimes it's worth something ;-)

    Wellington, New Zealand based.

    May contain #dog #cat #electronics #linux & #social #psychology

    @aenertia on other things

    Unless otherwise noted any original media posted here is done so on a CC:BY:SA licence

    they/them/he
    jwp_nz wrote 2 posts with. Live in city Wellington. Been with us since 2024 year.
  • ADVERTISEMENT
  • #2 21059308
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14416
    Help: 650
    Rate: 12371
    Thanks for sharing. It's really not good to see them using USB-C connector for 12V. Using it for some other devices would certainly end badly.

    Regarding the buttons on the device, I am planning to make an extended version of per-pixel lights driver, but currently, if you are using RGBW method:
    
    SM16703P_SetPixel all $led_enableAll*$led_red*$led_dimmer/255 $led_enableAll*$led_green*$led_dimmer/255
    

    then you can use both button roles like SmartButtonForLEDs, Button_NextColor you can also use click events with commands like led_basecolor_rgb, etc. I would need to think about that wrap.

    Added after 8 [hours] 51 [minutes]:

    jwp_nz wrote:

    Everything seems to be working fine, except that I get continuous press SPAM from Pin14 which is SW1 in the console- I am wondering if this is possibly something to do with how the Microphone on the board is wired in? Inverting the pin doesn't resolve.

    So both Btn and Btn_b are spamming? But wait, is P14 really a button? Why do you think it's mic? Isn't mic on ADC, P23?
    Helpful post? Buy me a coffee.
  • #3 21060564
    jwp_nz
    Level 2  
    Posts: 2
    Thanks I am still a bit lost about button actions and mapping maybe lets try and achieve the most basic use case I want. Which is to turn the lights off on a button press when they are connected to DDP only and then turn them on again on second press.

    Using Switch4 (p22) to avoid the spammy p14 pin for the moment.

    The Pseudo code would be something like:

    ///
    on P22 press trigger statechange
    
    //statechange
    check current state of pixels ;
     if  ( current state is anything other than off )
      then
        save current state to variable;
        disable DDP listener;
        turn off all pixels;
    else 
     read state from variable;
     set pixels to variable state;
     re-enable DDP listener;
    //
    ///


    Now how to implement this using openbk's scripting and bindings - I am a little lost in, even after reading through examples and docs. I basically want to expand my existing autoexec.bat with the above logic.
📢 Listen (AI):

FAQ

TL;DR: For OpenBK7231N users modding PROGLO Obi Smart Light Bars, this board exposes 4 switches and 6 addressable segments per bar pair. "It’s really not good to see them using USB-C connector for 12V," the thread warns. This FAQ explains flashing, pin mapping, DDP setup, and the Pin14 spam issue on the CBU/BK7231N hardware. [#21059308]

Why it matters: This thread documents a rare BK7231N light-bar design that is easy to open and flash, but mixes useful local controls with a potentially unsafe 12 V USB-C output.

Topic Option What the thread reports
Flashing method OpenBK7231N GUI flasher Did not work for this device on Fedora 40.
Flashing method hid_downloader / hid_download_py Worked, and was used to flash and dump the original full firmware.
Runtime control DDP-only Works as a target attached to existing WLED-controlled lights.
Runtime control Local RGB/dimmer control Overrides DDP input, so it was left disabled by default.

Key insight: The hardware works well with OpenBK7231N once flashed, but the cleanest real-world setup in the thread is DDP-only control plus carefully chosen local button logic that avoids Pin14.

Quick Facts

  • The controller uses a CBU BK7231N board, takes 12 V input, and drives the strips through the SM16703P driver with GRB color order in OpenBK. [#21059212]
  • Each two-bar kit behaves as 6 addressable segments per light, but the second bar is wired in parallel, so it mirrors the first instead of adding extra independent pixels. [#21059212]
  • The bars are about 285 mm high including the base, and the author bought several units roughly a year before flashing them. [#21059212]
  • The enclosure opens from a gap near the USB-C connector, and the PCB has convenient solder pads on the reverse side for initial flashing. [#21059212]
  • The USB-C port outputs constant 12 V without any USB PD trigger, so the thread warns not to connect anything except the supplied light bars. [#21059212]

How do I flash the PROGLO Obi Smart Light Bars with OpenBK7231N on the CBU/BK7231N board using the solder pads on the back?

Use the reverse-side solder pads for an initial wired flash, because the board exposes convenient pads and the enclosure opens easily near the USB-C side. 1. Pry open the case at the gap by the USB-C connector. 2. Solder to the rear flashing pads on the CBU BK7231N board. 3. Flash OpenBK7231N, then boot the device and load the template or script you need. The thread confirms this hardware was easy to open and suitable for pad-based flashing. [#21059212]

Why does Pin14 on the PROGLO Obi Smart Light Bars keep generating continuous button press spam in OpenBK7231N?

The thread does not confirm the exact cause, and Pin14 may not be the microphone line at all. The reported symptom is continuous press spam on Pin14 as SW1, and inverting the pin did not fix it. A reply questions whether Pin14 is really a button and points instead to the microphone being on ADC Pin23. In practice, the safe workaround in the thread is to leave Pin14 undefined or avoid it for local button handling. [#21059308]

What is the correct pin mapping for the 4 switches on the PROGLO Obi Smart Light Bars PGLSB100-2PK?

The posted template maps the four switches to GPIO14, GPIO15, GPIO20, and GPIO22. In that JSON, Pin14 is Btn_Tgl_All;0, while Pins15, 20, and 22 are each Btn;0. The model name is PGLSB100-2PK, the board is CBU, and the chip is BK7231N. That mapping is the only explicit switch map shown in the thread. [#21059212]

How do I configure the SM16703P driver in OpenBK7231N for these light bars with GRB color order and 6 addressable segments?

Start the SM16703P driver and initialize it for 6 segments in GRB order. The thread’s working script uses startDriver SM16703P followed by SM16703P_Init 6 GRB. That matches the hardware description: each light has 6 addressable segments, and OpenBK uses the SM16703P driver with GRB color order for this device. [#21059212]

What is DDP in OpenBK7231N and how is it used to attach these PROGLO light bars as segments to an existing WLED setup?

DDP is the protocol used here to make the bars behave as receiver segments under an existing WLED controller. The thread’s autoexec starts startDriver DDP, then the author attaches these bars as DDP segments to existing WLED-controlled lights. In that setup, the PROGLO bars act as standalone DDP targets out of the box rather than as the main controller. [#21059212]

How can I use one of the local buttons in OpenBK7231N to turn the light bars off and back on while they are running as DDP receivers?

Use a non-spammy button such as Pin22 and script a state toggle that disables DDP, turns pixels off, then restores state and re-enables DDP. The thread gives this exact target behavior in pseudocode for Switch4 on P22. It does not provide a finished OpenBK script, but it clearly defines the intended flow: press once to save state and power off, press again to restore the saved state and resume DDP. [#21060564]

Why do local dimmer or color controls in OpenBK7231N override DDP input on these SM16703P light bars?

Because the local WebUI-style LED control path writes pixel values directly, it takes priority over incoming DDP data in this setup. The author states that basic local dimmer and color control currently override DDP, so those controls were disabled by default. As a result, the bars were left configured as basic DDP targets for reliable use with an existing WLED controller. [#21059212]

What is the difference between SmartButtonForLEDs, Button_NextColor, and click-event commands like led_basecolor_rgb in OpenBK7231N?

SmartButtonForLEDs and Button_NextColor are built-in button roles, while click-event commands such as led_basecolor_rgb are custom actions you bind to click events. The thread says both button-role methods can work when you use the RGBW-style SM16703P_SetPixel all ... approach. It also notes that click events give you direct command control, which is useful when you want custom color behavior instead of a fixed built-in role. [#21059308]

How should I script autoexec.bat in OpenBK7231N to add local button control for color, brightness, and power on these 4-switch light bars?

Build on the existing autoexec and assign the four momentary switches to power, brightness, and color actions, but avoid Pin14 until the spam issue is resolved. The thread’s target design is three color-channel controls that roll over 0–255, plus a fourth switch for on/off and long-press dimming. It also shows a working base script with startDriver SM16703P, startDriver NTP, startDriver DDP, and SM16703P_Init 6 GRB, which is the right foundation for added button logic. [#21059212]

What is WS2811C in a 12V grouped-by-3 LED strip, and how does that affect addressable segment count in the PROGLO bars?

"WS2811C is a 12 V LED control scheme that drives LEDs in grouped sections, with several LEDs sharing one control channel instead of each LED being independently addressable." In these bars, the thread says the strip uses WS2811C controllers in groups of 3 LEDs, giving 6 addressable segments per light. Because the paired bars are wired in parallel, the second bar mirrors the first instead of doubling the independent segment count. [#21059212]

Why is using a USB-C connector for constant 12V output on the PROGLO Obi Smart Light Bars considered dangerous?

It is dangerous because the USB-C port outputs constant 12 V with no USB PD trigger, so another device could receive raw 12 V unexpectedly. The thread explicitly warns not to use that port for anything except the supplied lights. A reply reinforces the risk: using that USB-C connector with other devices “would certainly end badly.” [#21059308]

How does WLED handling of incoming DDP packets compare with OpenBK7231N when you also want local button overrides?

WLED handles the conflict more gracefully in the thread’s example. The author says WLED pops up an override prompt when a DDP packet arrives, letting the user ignore DDP once or until reboot. OpenBK7231N, by contrast, lets local dimmer controls override DDP directly, so the author left local controls disabled and used the bars as DDP receivers only. [#21059212]

What role does the microphone play on this BK7231N/CBU light bar board, and is it likely wired to ADC Pin23 rather than Pin14?

The microphone exists on the board, but its function was unused and untested because the device was never paired to Tuya Cloud. A reply challenges the assumption that Pin14 is tied to the microphone and asks whether the mic is instead on ADC Pin23. That makes ADC23 the stronger candidate in this thread, while Pin14 remains unresolved and noisy in OpenBK. [#21059308]

Which flashing method works better for this device when the GUI tool fails: hid_download_py or the OpenBK7231N GUI flasher?

hid_downloader worked better for this device. The author states the GUI tool could not be used, while hid_downloader was used successfully to flash the unit and dump the full original firmware binary from Fedora 40. The thread also says the original dump contained no useful Cloudcutter configuration. [#21059212]

How could I rewire the second PROGLO light bar so it becomes a single 12-segment strip instead of mirroring the first bar in parallel?

The thread suggests a physical rewire: cut the second bar’s cord, drill a hole, and solder that bar to the top of the first so both bars form one longer chain. That change could turn the mirrored pair into a single strip with 12 addressable segments instead of 6 mirrored segments. The author did not test it, so treat it as a hardware mod idea rather than a verified procedure. [#21059212]
Generated by the language model.
ADVERTISEMENT