logo elektroda
logo elektroda
X
logo elektroda

Arlec Grid Connect Smart Desktop Bar Lights - Twin Pack - Teardown

wolfieeewolf 2937 24
ADVERTISEMENT
  • #1 20804796
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20
    Device Name: Arlec Grid Connect Smart Desktop Bar Lights - Twin Pack - ALP223HA
    Device Type: Desktop Bar Lights
    Device Chip: CBU - BK7231N
    Device Purchased Bunnings Warehouse - $49AUD

    Close-up of a circuit board with electronic components. A single Arlec Grid Connect Smart Desktop Bar light with a height of 300 mm and a base width of 90 mm. Two vertical LED light bars emitting multicolored light, positioned on black bases. A person holding a phone with a control app for Arlec Grid Connect Smart Desktop Bar Lights in the background.


    Flashing of Main Chip

    CloudCutter Profile - Profile.json

    I created a CloudCutter profile using LightLeak.

    Configuration of Module

    So far I haven't put OBK on device. I think I'll wait until I can see if OBK can do what the mobile app can do.

    The device have two separate addressable RGB strips inside with 10 led per strip. It has a mic for music mode as well.
    Arlec Grid Connect app interface for controlling desktop bar lights. Arlec app interface for controlling RGB desktop lights with various lighting themes. Arlec app interface for desktop lights with music mode. Screenshot of the Arlec app showing music modes for light synchronization. Arlec app interface displaying color options and night mode for RGB light strips.

    As far as I can tell OBK does not have the fuctions that the mobile app has. I could use WLED but to keep all my devices the same I would like to use OBK.

    I'm not sure OBK will ever get all the functions that the mobile app has and I would have to create a custom entity in Home Assistant as well to handle this device.

    For now I am not converting this device. The app has some nice transitions and functions that work well for now. Would be great to not have it cloud based though.

    If OBK should these features in the future I will update this post with configuration settings.
  • ADVERTISEMENT
  • #2 20804874
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14604
    Help: 654
    Rate: 12620
    Hello, which GPIOs are used to control the strips?
    Are you sure that they are separate?
    I am asking because we are working on WS2812B driver and on similiar devices and as far as we know at the moment is that due to timing requirements only P16 (MOSI) can be used to drive that kind of LEDs, no other pin will work for that.

    If you want to help with development, you could just make 2MB backup, flash OBK for some testing, and once we're done, restore back to Tuya. What do you think? We could check if current SM16703 driver can handle your device, maybe I could try to help with adding some effects, etc.
    Helpful post? Buy me a coffee.
  • #3 20805149
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20

    I will have to tear down the device again and see if I can get a better photo of the LED strip. It is the one thing I forgot to take a photo of.

    I do have the light leak profile that has the bin file. Not sure if that will help.

    BIN and JSON Files
    deskrg..zip (1.12 MB)You must be logged in to download this attachment.

    If I can revert back to the original firmware again I'll try some testing and see what happens. Will try and dump the firmware tomorrow using BK Flasher.
  • #4 20806233
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20
    Managed to get the firmware dumped using BK Flasher

    readResult...-28-10.bin (2 MB)You must be logged in to download this attachment.

    also took a few photos of the LED strip and IC chip. There are 30 LEDs and depending on what mode you use it will split them up into lots of 3 or if using the custom themes you can set each LED to a different colour

    Circuit board with two USB-C ports and three buttons. Addressable LED strip displaying green-lit diodes. Close-up of an LED on an LED strip with visible soldered wires. Close-up of a single LED on a circuit board. Close-up of an LED strip marked CYTT-279/V1.0 with a date 2022-12-12 and Chinese characters. Close-up of a circuit board with integrated circuits and connectors, marked with VWDG. Close-up of a circuit board showing the CYTT-279 and AMS1117 chip markings on a green PCB.

    I also captured a video of the strip so you can see the addressable LEDs in action





    Still haven't put OBK on the device yet. That will be next.
  • ADVERTISEMENT
  • #5 20814177
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20

    I have flashed the device with OBK.

    So far no luck in getting this to output anything.

    I used the GPIO finder and I'm getting something on pins 22, 24, and 7.

    Pin 22 is the power on/off button.
    Pin 24 is the color change button.
    Pin 7 is the mode change button.

    I have tried setting Pin 16 to SM16703P_DIN as suggested, but nothing is happening.

    I'm slowly working my way through the list of LED drivers in hope that one of them does something.

    I'm thinking I might have to go back to the stock firmware and see if I can debug it to see if that reveals anything worthwhile.

    I read the Tuya GPIO config from 0x1EE000 and import the BIN file into BKflasher - I get this

    Device configuration, as extracted from Tuya: 
    - Control Pin (TODO) on P26
    Device seems to be using CBU module, which is using BK7231N.
    And the Tuya section starts at UNCOMMON POSITION 0

  • #6 20814302
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14604
    Help: 654
    Rate: 12620
    Please include the raw Tuya JSON, which can contain much more information

    No one suggested that:
    
    SM16703P_DIN 
    

    To test SM16703, you do:
    
    //Start driver, CHANGE [[pixelcount]] to number of leds
    startDriver SM16703P
    
    //Init Driver
    SM16703P_Init [[pixelcount]]
    
    //Set Pixel
    SM16703P_SetPixel 1 255 0 0
    SM16703P_SetPixel 2 0 255 0
    SM16703P_SetPixel 3 0 0 255
    
    //Start Output (each call will trigger one
    SM16703P_Start
    

    I will remove that DIN role because it seems to confuse people
    Helpful post? Buy me a coffee.
  • #7 20814361
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20
    p.kaczmarek2 wrote:
    No one suggested that:
    Code: text Expand Select all Copy to clipboard
    SM16703P_DIN


    p.kaczmarek2 wrote:
    We could check if current SM16703 driver can handle your device


    Sorry I just assumed that's what you meant by this.

    I tried the code and the led's light up white but the first few leds are green and red and the end led's are green. There are 30 led per strip and both strips are lit up. In the mobile app you can set the colours different on each strip so not sure if I should be using 60 for the pixel count or not. It didn't make a diffenece setting it to 60.

    From my experince working with leds for my christmas light display the mixed up of colours usually means the wrong pixel type. I guess I could try and put wled on the chip and see if i can work out what pixels it has unless you have another suggestion.

    Added after 10 [minutes]:

    This is the JSON from the stock firmware

    {
    	"rgbtows":"700",
    	"Jsonver":"1.1.1",
    	"gmwb":"100",
    	"title20":"0",
    	"cdtime1":"60",
    	"1err":"40",
    	"cdtime2":"120",
    	"totallen":"30",
    	"gmwg":"100",
    	"knum":"3",
    	"k3pin_lv":"0",
    	"leaderr":"30",
    	"rgbtoch":"220",
    	"wfcfg":"spcl_auto",
    	"colormin":"10",
    	"bitseq":"0",
    	"pmemory":"1",
    	"gmkb":"60",
    	"pairt":"606",
    	"cmod":"rgb",
    	"slidemod":"0",
    	"micpin":"23",
    	"rgbtocs":"0",
    	"customcode":"00ef",
    	"rstbr":"50",
    	"ktime":"5",
    	"0err":"70",
    	"colormax":"58",
    	"module":"CBU",
    	"ctrl_lv":"1",
    	"rstmode":"2",
    	"irpin":"20",
    	"sfunc":"1",
    	"key_lv":"0",
    	"wfct":"3",
    	"rgbtowh":"35",
    	"defbright":"100",
    	"starterr":"40",
    	"rstnum":"3",
    	"rstcor":"r",
    	"sensimax":"50",
    	"micproc":"500",
    	"k2lfunc":"0",
    	"k3sfunc":"6",
    	"miso":"17",
    	"mosi":"16",
    	"k1dfunc":"0",
    	"keyfunc":"1",
    	"irfunc":"1",
    	"brifollow":"1",
    	"ctrl_pin":"26",
    	"adclimit":"1500",
    	"k2pin_pin":"24",
    	"sensimin":"1",
    	"ismusic":"1",
    	"k3pin_pin":"7",
    	"prodagain":"1",
    	"key_pin":"22",
    	"k2dfunc":"0",
    	"k2sfunc":"4",
    	"brightstep":"20",
    	"remdmode":"1",
    	"k3lfunc":"0",
    	"colorpfun":"0",
    	"CS":"15",
    	"gmwr":"60",
    	"rgbt":"1",
    	"gmkg":"60",
    	"onoffmode":"0",
    	"k3dfunc":"0",
    	"colororder":"2",
    	"k2pin_lv":"0",
    	"LedNum":"30",
    	"irfunset":"[[6",
    	"aging":"1",
    	"category":"0503",
    	"SCL":"14",
    	"gmkr":"80",
    	"defcolor":"r",
    	"crc":"95",
    	"}qihAgw_diAmf_test_closev":"40.00",
    	"pv":"2.2",
    	"lpv":"3.3",
    	"pk":"keyj3w8cmutjmwk5",
    	"firmk":"keyj3w8cmutjmwk5",
    	"cadv":"true3",
    	"cdv":"1.0.0",
    	"dev_swv":"1.0.18",
    	"s_id":"null",
    	"dtp":"0",
    	"sync":"0",
    	"attr_num":"0",
    	"mst_tp_0":"0",
    	"mst_ver_0":"null",
    	"mst_tp_1":"0",
    	"m05Atls_ca_cnter_2":"null",
    	"mst_tp_3":"0",
    	"mst_ver_3":"null "
    }


    Device configuration, as extracted from Tuya: 
    - Control Pin (TODO) on P26
    Device seems to be using CBU module, which is using BK7231N.
    And the Tuya section starts, as usual, at 2023424


    and this is the JSON with the OBK firmware

    {
    	"rgbtows":"700",
    	"Jsonver":"1.1.1",
    	"gmwb":"100",
    	"title20":"0",
    	"cdtime1":"60",
    	"1err":"40",
    	"cdtime2":"120",
    	"totallen":"30",
    	"gmwg":"100",
    	"knum":"3",
    	"k3pin_lv":"0",
    	"leaderr":"30",
    	"rgbtoch":"220",
    	"wfcfg":"spcl_auto",
    	"colormin":"10",
    	"bitseq":"0",
    	"pmemory":"1",
    	"gmkb":"60",
    	"pairt":"606",
    	"cmod":"rgb",
    	"slidemod":"0",
    	"micpin":"23",
    	"rgbtocs":"0",
    	"customcode":"00ef",
    	"rstbr":"50",
    	"ktime":"5",
    	"0err":"70",
    	"colormax":"58",
    	"module":"CBU",
    	"ctrl_lv":"1",
    	"rstmode":"2",
    	"irpin":"20",
    	"sfunc":"1",
    	"key_lv":"0",
    	"wfct":"3",
    	"rgbtowh":"35",
    	"defbright":"100",
    	"starterr":"40",
    	"rstnum":"3",
    	"rstcor":"r",
    	"sensimax":"50",
    	"micproc":"500",
    	"k2lfunc":"0",
    	"k3sfunc":"6",
    	"miso":"17",
    	"mosi":"16",
    	"k1dfunc":"0",
    	"keyfunc":"1",
    	"irfunc":"1",
    	"brifollow":"1",
    	"ctrl_pin":"26",
    	"adclimit":"1500",
    	"k2pin_pin":"24",
    	"sensimin":"1",
    	"ismusic":"1",
    	"k3pin_pin":"7",
    	"prodagain":"1",
    	"key_pin":"22",
    	"k2dfunc":"0",
    	"k2sfunc":"4",
    	"brightstep":"20",
    	"remdmode":"1",
    	"k3lfunc":"0",
    	"colorpfun":"0",
    	"CS":"15",
    	"gmwr":"60",
    	"rgbt":"1",
    	"gmkg":"60",
    	"onoffmode":"0",
    	"k3dfunc":"0",
    	"colororder":"2",
    	"k2pin_lv":"0",
    	"LedNum":"30",
    	"irfunset":"[[6",
    	"aging":"1",
    	"category":"0503",
    	"SCL":"14",
    	"gmkr":"80",
    	"defcolor":"r",
    	"crc":"95",
    	"}ujfAgw_diAmf_test_closev":"40.00",
    	"pv":"2.2",
    	"lpv":"3.3",
    	"pk":"keyj3w8cmutjmwk5",
    	"firmk":"keyj3w8cmutjmwk5",
    	"cadv":"true3",
    	"cdv":"1.0.0",
    	"dev_swv":"1.0.18",
    	"s_id":"null",
    	"dtp":"0",
    	"sync":"0",
    	"attr_num":"0",
    	"mst_tp_0":"0",
    	"mst_ver_0":"null",
    	"mst_tp_1":"0",
    	"m0Atls_ca_cnter_2":"null",
    	"mst_tp_3":"0",
    	"mst_ver_3":"null "
    }


    
    Device configuration, as extracted from Tuya: 
    - Control Pin (TODO) on P26
    Device seems to be using CBU module, which is using BK7231N.
    And the Tuya section starts at UNCOMMON POSITION 0


    Added after 17 [minutes]:

    Running the JSON through the OBK template Converter gives me this

    Device seems to be using CBU module, which is BK7231N chip.
    - Control Pin (TODO) on P26
    - Pair/Toggle All Pin on P22
  • #8 20814499
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14604
    Help: 654
    Rate: 12620
    I can see a lot of useful information here! Good job, @wolfieeewolf , this is very helpful.
    I can see you discovered new JSON keys, for example:
    
    "k3pin_pin":"7",
    

    I will add them to our flasher soon. For now, please wait, I may try to alter the LEDs driver to work better for you.
    To be clear, do you know what specific kind of LEDs is used in this device?
    Helpful post? Buy me a coffee.
  • #9 20815636
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20

    I have connected the strip to my ESP32 with WLED running and managed to work out the strip is a 5v WS281X with a color order of GRB. All effects work perfectly with WLED.

    Considering that Arlec are known for making cheap devices with cheap parts. I'm guessing the strip is probably a WS2812 or WS2812B. They seem to be the standard.
  • #10 20815639
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14604
    Help: 654
    Rate: 12620
    Very well, please wait if you can, I can't say at the moment when, but I will try to adjust timings for that WS format and we will retry.

    So the current code lights LEDs at random? In the incorrect way?
    Helpful post? Buy me a coffee.
  • #11 20815643
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20

    Correct.

    LED lamp emitting blue-violet light on a desk.
  • #12 20966216
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14604
    Help: 654
    Rate: 12620
    The SPI DMA driver bug has been fixed. The SM16703P/WS2812B/etc LEDs should work good now. Please update your devices. For scripting configuration, please see:
    OpenBeken WS2812B driver (compatible with SM16703P, etc) - short scripting presentation
    We can continue discussion there. The more advanced animation will be added soon, stay tuned!
    Helpful post? Buy me a coffee.
  • #13 21036024
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20

    Have managed to get this device somewhat working with the following

    autoexec.bat

    -- Start NTP driver and set time zone offset
    startDriver NTP
    ntp_timeZoneOfs +10:00
    -- Enable power saving
    powerSave 1
    startDriver DDP
    startDriver SM16703P
    SM16703P_Init 60
    again:
    if  $led_enableAll>0 then goto color
    SM16703P_SetPixel all 0 0 0
    SM16703P_Start
    led_temperature $led_temperature*$led_enableAll
    led_dimmer $led_dimmer*$led_enableAll
    goto end
    color:
    SM16703P_SetPixel all 1*$led_green*$led_dimmer/255 1*$led_red*$led_dimmer/255 1*$led_blue*$led_dimmer/255
    SM16703P_Start
    end:
    delay_s 1
    goto again


    Home Assistant doesn't discover the device fully.
    So far only build, RSSI and uptime are being discovered.

    Add this to your config.yaml

     light:
       - unique_id: "PC_light"
         name: "PCRGB Light"
         rgb_command_template: "{{ '#%02x%02x%02x0000' | format(red, green, blue)}}"
         rgb_value_template: "{{ value[0:2]|int(base=16) }},{{ value[2:4]|int(base=16) }},{{ value[4:6]|int(base=16) }}"
         rgb_state_topic: "obk55706EEB/led_basecolor_rgb/get"
         rgb_command_topic: "cmnd/obk55706EEB/led_basecolor_rgb"
         command_topic: "cmnd/obk55706EEB/led_enableAll"
         state_topic: "obk55706EEB/led_enableAll/get"
         availability_topic: "obk55706EEB/connected"
         payload_on: 1
         payload_off: 0
         brightness_command_topic: "cmnd/obk55706EEB/led_dimmer"
         brightness_state_topic: "obk55706EEB/led_dimmer/get"
         brightness_scale: 100
         color_temp_command_topic: "cmnd/obk55706EEB/led_temperature"
         color_temp_state_topic: "obk55706EEB/led_temperature/get"



    So far things are kinda working ok. I have an issue turning it ON/OFF and some colour-changing quirks.

    Have changed "if $led_enableAll>0 then goto color" to "if $led_enableAll<1 then goto color" but it gets confused with home assistant so I have to change the payloads around from "payload on: 1" to "payload on: 0"

    I'm sure it's just my script that is causing the issue but I have tried it a few different ways and it will not turn off if you have MQTT linked to Home Assistant. I have also found that OBK will say it's OFF when it's ON depending on what way you have the script which is where I think Home Assistant is getting confused.

    I have flags 0, 4, 10, 16, 23 and 27 turned on. I found it has issues with colour changes in Home Assistant without the MQTT flags turned on. I have messed about with turning these on and off but still have ON/OFF issues.

    The colour-changing works okay. It's a little slow and jumpy between colours. LED smoothing flag appears to do nothing.

    I haven't had a chance to see how it functions with the DDP driver running and using WLED to control the lights. Will update this when I do.

    Hopefully, with some more work on the drivers it will be working as intended. Till then this gets it working well enough for me.
  • ADVERTISEMENT
  • #14 21036040
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14604
    Help: 654
    Rate: 12620
    Your script is a bit strange. Have you tried my script, the one I posted in the article?

    Why are you checking manually for the value of $led_enableAll instead of just multiplying the color by $led_enableAll? $led_enableAll can be only 1 or 0 so that would basically turn off the strip when $led_enableAll is off.

    By the way, you don't have to use > and < operators, I think we have == and != .
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #16 21036101
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14604
    Help: 654
    Rate: 12620
    Maybe try that one, but I am not sure how good will it fit for you:
    p.kaczmarek2 wrote:

    Class LED controller (single color only)
    Another interesting possibility is 'hacking' the OBK script to control LEDs with old OBK single-color LED interface. For that, you need to enable the following flag:
    Screenshot of OpenBekenX settings with Flag 4 option highlighted regarding RGBCW controller.
    Then, add the following script:
    startDriver SM16703P
    SM16703P_Init 60
    
    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

    This will make OBK panel able to control the LEDs:
    Interface for managing LED lighting settings on the OpenBekenX platform.
    Everything except CW controls will work, even the dimmer and color picker:
    RGB color palette with selected green color.
    Helpful post? Buy me a coffee.
  • #17 21036148
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20
    It works much better using that script. The color-changing is still a little slow and jumpy between colors but works for what I'm using it for.

    Will have to try and make a color cycle effect. I have also tried to link this to OpenRGB but unfortunately, DDP doesn't work with it. I can use a workaround and run it with WLED then link WLED to OpenRGB and have it work that way. Yet to see if this works. Would be good to see OBK have E1.31 capabilities Then I can link everything together on my computer desk. Will see how my workaround goes. There shouldn't be too much lag.



    Just to add even with the updated script. Only build, RSSI and uptime are being discovered in HA so still need to add the config.yaml script for it to work.
  • #18 21037566
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20

    Got around to doing some testing with WLED and OpenRGB.

    I have WLED on a Duinotech ESP32 board. I have set up WLED to receive DDP from my device.

    As soon as it connects to WLED the lights start to flicker. It will output all the effects fine but with flickering. As soon as you disconnect WLED it works fine. I'm guessing new driver and still has a few little bugs to iron out so hopefully will get better over time. Right now the flickering is very noticeable and makes the device unusable with WLED.

    Another issue is that my lights are GRB ordered but WLED will not set them correctly. I have changed it on the WLED interface as well as the autoexec.bat and several combinations of both but the colours are still wrong so not sure what is happening there. They are correct when WLED is not connected.

    I was able to link WLED to OpenRGB using E1.31 and all the effects from OpenRGB work. There is a slight issue when changing solid colours that it will revert to whatever WLED's last set colour was but this could be an issue with WLED and OpenRGB, not OBK. Will have to do some more testing on this to see where the issue lies.

    Would be interested in seeing if adding UDP could fix these issues. This would also open up OBK to a few other programs like Hyperion and Prismatik

    Would be great to see as in Australia we have a pretty good brand called Genio and the crappier Arlec branded LED's that I could sync up with OpenRGB/Hyperion for a cheap whole room Ambilight alternative.



    I'll try and get a video of the flickering and upload that when I can
  • #19 21038424
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20

    I've had a chance to do some testing with DDP and some of the software I want to use with these lights.


    First video is the LED's through WLED with DDP. You can see the green flickering. The lights are also meant to be green not red.
    An interesting point is that when you change the LED colour the flickering colour also changes.





    Second video is the LED's running directly through Hyperion.NG. I found that I can link it with UDP DDP.
    The video is a bit washed out but I have it running a colour cycle animation. It does work ok but you can see some slight flickering every few seconds. It also has the colours mixed up. Should be GRB. There could be a way to fix this in Hyperion but it must be in some advanced menu that I haven't found yet.





    The last video is of a pair of downlights running with OpenRGB using WLED with DDP. You can see that the colours change very smoothly and there is a slight lag in the video. It's not that bad just my phone camera sucks.

    The LED light bars kept locking up and I had to reboot them but in the end I couldn't get them to work. Seems they don't play well with OpenRGB. I did get them working the other night so maybe it's just a setting that is wrong somewhere.






    I would like to try to run a few lights directly through Hyperion to see if I can get the lights to copy the screen colours better. Could then have ceiling lights, wall lights, strip lights, and LED Bar all grabbing a different part of the screen. If I get this setup I'll try to get a decent video of it.
  • #20 21038695
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14604
    Help: 654
    Rate: 12620
    Thank you for testing!

    Regarding flickering, are you saying this happens in OBK? Are you using latest version?
    How to reproduce the problem? Maybe you're just sending too much data? Can you reduce the interval of DDP packets?

    wolfieeewolf wrote:

    Another issue is that my lights are GRB ordered but WLED will not set them correctly. I have changed it on the WLED interface as well as the autoexec.bat and several combinations of both but the colours are still wrong so not sure what is happening there. They are correct when WLED is not connected.

    There is option to change byte order:
    Screenshot of a table with LED driver setup instructions, highlighting the text SM16703P_Init.

    wolfieeewolf wrote:

    Would be interested in seeing if adding UDP could fix these issues. This would also open up OBK to a few other programs like Hyperion and Prismatik

    What do you mean by "adding UDP"? DDP protocol for LEDs is already using UDP, so there is no way to "add" it.
    Helpful post? Buy me a coffee.
  • #21 21038704
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20
    It's completely ridiculous I know but I did get it to work.

    All the lights are running OBK with DDP. Have set up multiple LED light instances in Hyperion. The two downlights are capturing the bottom corners of the screen and the LED light bar is grabbing the colors from the middle of the screen.






    Added after 23 [minutes]:

    p.kaczmarek2 wrote:
    What do you mean by "adding UDP"? DDP protocol for LEDs is already using UDP, so there is no way to "add" it


    UDP is confusing as it can be called so many other things. From what I understand E1.31, ArtNet, H801, DRGB(I believe this is DDP - max 490 LEDs), DNRGB(1500 LEDs) and WARLS(max 255 LEDs) all use UDP they just have different methods of communicating this. Each one has its strengths and weaknesses.

    Having a few more options other than just DDP would allow a bit more freedom. E1.31 is a standard in most lighting software so I guess if that could be added it would help with linking things together a bit easier but I do understand there are storage limits on the chips so adding it just for one person might be a bit silly.

    Added after 13 [minutes]:

    Forgot to add

    p.kaczmarek2 wrote:
    Regarding flickering, are you saying this happens in OBK? Are you using latest version?
    How to reproduce the problem? Maybe you're just sending too much data? Can you reduce the interval of DDP packets?


    It doesn't happen in OBK it only happens when you link the DDP to WLED, etc. It only does it with the SM16703P driver. All the other devices with DDP seem to not have the issue.

    To reproduce the problem

    startDriver DDP link the led to WLED and it will start flickering. I don't have another SM16703P device to test to see if it's firmware or device-related

    I'll have to look into how to reduce the packet interval. It's nowhere as bad with Hyperion.

    As for the colour option, I have changed the byte order in OBK but WLED still gets it wrong. I have also changed it in WLED and still no change. I found a setting in the advance menus in Hyperion that allows me to change the colour order and it works fine. So could be a WLED issue, not OBK
  • #22 21039818
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20

    I worked out how to stop the flickering.

    When you have this in your autoexec.bat it conflicts with WLED, etc. It looks like OBK is trying to set the light color and WLED is trying to set its own light color. They appear to be fighting it out which in turn is causing the flickering.

    startDriver SM16703P
    SM16703P_Init 60
    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


    When you remove that code with this it all goes away.

    startDriver DDP
    startDriver SM16703P
    SM16703P_Init 30 GRB


    Not a big issue but doing this means you now can't change the lights with OBK and have to use WLED, etc. I'm guessing when the driver of the LEDs no longer needs a script to run it should solve the issue.
  • #23 21082111
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20

    Please note you no longer need to have anything in the autoexec.bat. Everything runs on the firmware side and works it all out for you.

    You also don't need any flags set either. I did try setting flag 18 - Smooth transitions but it appears it does nothing.

    Home Assistant will pick up temperature mode but this device only outputs RGB and not RGBCW.

    This device is now working how it should.

    To get any LED effects you will have to use WLED via DDP for now.
  • #24 21082142
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14604
    Help: 654
    Rate: 12620
    You are right, except the animations - actually we have a PixelAnim driver which will be released in few days. It has some simple animations like rainbow, fire, etc.
    Helpful post? Buy me a coffee.
  • #25 21448123
    wolfieeewolf
    Level 11  
    Posts: 93
    Help: 7
    Rate: 20
    Is there any way we can control each LED or send the number of addressable LED's to Home Assistant? At the moment Home Assistant will only pick up this as one light. The PixelAnim Driver works properly and can change the addressable LED but just can't manually control it. That would be nice.

Topic summary

✨ The Arlec Grid Connect Smart Desktop Bar Lights (Twin Pack, model ALP223HA) use a CBU module with a BK7231N chip and contain two addressable RGB LED strips, each with 30 LEDs, likely WS2812 or WS2812B type with GRB color order. The device includes a microphone for music mode and is controlled via GPIO pins, with pins 22, 24, and 7 assigned to power, color change, and mode change buttons respectively. Initial attempts to flash and control the LEDs using OpenBeken (OBK) firmware involved testing various LED drivers, notably SM16703P, but encountered issues such as incorrect color output and flickering. The LED strips respond correctly when connected to an ESP32 running WLED firmware, confirming the LED type and color order. The OBK firmware was updated to fix SPI DMA driver bugs, improving LED control compatibility. Scripts for LED control were refined, with the best results achieved using the SM16703P driver initialized for 60 LEDs and proper color multiplication by control variables. Integration with Home Assistant is partial, detecting only build, RSSI, and uptime, requiring manual YAML configuration for full functionality. The device supports DDP protocol for LED control, but flickering issues arise when OBK and WLED simultaneously attempt to control the LEDs; removing conflicting scripts resolves this. Attempts to link with OpenRGB via WLED and DDP show promise but with some color order and flickering challenges. The discussion highlights the need for additional protocol support like E1.31 for broader compatibility. The PixelAnim driver in OBK firmware introduces simple LED animations. Full individual LED control and addressable LED count reporting to Home Assistant remain desired features. Overall, the device is functional with OBK and WLED, with ongoing firmware and scripting improvements addressing initial limitations.
Generated by the language model.

FAQ

TL;DR: With 2 strips, 30 LEDs per strip, the ALP223HA can be backed up, flashed, and restored; after OBK driver fixes, one tester said "This device is now working how it should." This FAQ helps modders choose between stock Tuya, native OBK, and WLED-over-DDP control without losing recoverability. [#21082111]

Why it matters: This thread shows the full path from safe firmware backup to stable addressable-LED control on a cheap BK7231N desk light.

Option Restore stock firmware Built-in effects Home Assistant behavior Best use
Stock Tuya / Grid Connect Yes, if you dump first Strong app effects Works through vendor app Keep mobile scenes and music mode
OBK native control Yes, after backup Basic first, later PixelAnim Often needs manual HA setup Local control and tinkering
WLED over DDP Yes Strong external effects Controlled through WLED/Hyperion path Ambilight, OpenRGB, advanced animations

Key insight: The breakthrough was not just flashing OBK. Stable results came only after the WS2812B/SM16703P driver bug was fixed and the conflicting autoexec.bat color loop was removed when DDP control was used.

Quick Facts

  • The light uses a CBU module with BK7231N, was bought at Bunnings for AUD $49, and includes a microphone for music mode. [#20804796]
  • Hardware layout reported in the thread: 2 addressable strips, 30 LEDs per strip, and app modes that can split effects into groups of 3 LEDs or set per-LED colors. [#20806233]
  • Key Tuya JSON values include mosi: 16, miso: 17, micpin: 23, ctrl_pin: 26, key_pin: 22, k2pin_pin: 24, k3pin_pin: 7, and colororder: 2. [#20814361]
  • Early OBK testing lit both strips but showed wrong colors; later testing identified the LEDs as 5 V WS281X, GRB order, and WLED drove the strip correctly from an ESP32. [#20815636]
  • By 2024-05-14, the tester reported no autoexec.bat entries and no flags were needed, while PixelAnim support was announced as arriving within a few days. [#21082142]

How do you flash an Arlec Grid Connect Smart Desktop Bar Lights Twin Pack ALP223HA with CloudCutter or BK Flasher without losing the ability to restore the stock firmware?

Back up the original firmware before any permanent change. 1. Use a CloudCutter LightLeak profile to obtain the device-specific files. 2. Dump a full firmware backup with BK Flasher; the thread explicitly mentions a 2 MB backup path. 3. Flash OBK only after the dump, so you can restore stock Tuya later if testing fails. The tester first built a CloudCutter profile, then dumped firmware with BK Flasher, and only after that moved to OBK experiments. [#20806233]

Which GPIO pins are used on the Arlec ALP223HA for the power, color, and mode buttons, and how do you identify them in OpenBeken?

The buttons map to P22 for power, P24 for color change, and P7 for mode change. In OBK, the tester found them with the GPIO finder, then confirmed the same values in the Tuya JSON as key_pin: 22, k2pin_pin: 24, and k3pin_pin: 7. That gives you both a live discovery method and a firmware-side cross-check. [#20814361]

Why do the LEDs on the Arlec Grid Connect bar lights light up with the wrong colors or random-looking output when testing the SM16703P driver in OBK?

They misbehaved because the driver timing did not yet match the strip format. The first SM16703P test lit LEDs white with red and green errors at the ends, which is a classic sign of a wrong pixel protocol or byte order. Later, the OBK maintainer reported that the SPI DMA driver bug had been fixed and that SM16703P/WS2812B/etc. should then work correctly after updating. [#20966216]

What LED type and color order are used in the Arlec Grid Connect Smart Desktop Bar Lights, and how was GRB WS281X identified with WLED?

The strips were identified as 5 V WS281X with GRB color order. The tester disconnected the strip from the original controller, connected it to an ESP32 running WLED, and verified that all effects worked properly there. From that test, the thread concluded the strip behaves like a WS2812 or WS2812B-class device with GRB ordering. [#20815636]

What is CloudCutter, and how is a LightLeak profile used for Tuya-based devices like the BK7231N CBU module?

"CloudCutter is a flashing method that targets Tuya-based devices, using a device profile to identify and deliver the right exploit and firmware path." In this thread, the tester created a CloudCutter profile with LightLeak for the CBU / BK7231N light, then shared that profile as Profile.json. That makes CloudCutter the starting point for a device-specific, reversible mod workflow. [#20804796]

What is DDP in OBK and WLED, and how does it differ from E1.31, ArtNet, and other UDP-based LED control protocols?

DDP is the OBK-to-light streaming method used here, and the thread states it already runs over UDP. The maintainer explicitly corrected the idea of “adding UDP,” because DDP already uses it. The same post also lists E1.31, ArtNet, DRGB, DNRGB, and WARLS as other UDP-based approaches with different packet formats and limits, so the difference is protocol design, not transport. [#21038704]

How do you configure OpenBeken and Home Assistant so an Arlec ALP223HA RGB light appears as a usable light entity instead of only exposing build, RSSI, and uptime?

Use a manual MQTT light definition in config.yaml. The tester reported that Home Assistant auto-discovered only build, RSSI, and uptime, then solved usability by creating a light: entry with explicit RGB, brightness, color temperature, state, command, and availability topics. That manual entity turned the device into a working RGB light even before full native discovery was available. [#21036024]

Why did the autoexec.bat SM16703P script cause flickering when the device was linked to WLED over DDP, and how was that conflict fixed?

It flickered because two controllers were writing colors at the same time. The tester found that the looping autoexec.bat script kept calling SM16703P_SetPixel while WLED sent DDP updates, so OBK and WLED effectively fought over the strip. Removing the loop and leaving only startDriver DDP, startDriver SM16703P, and SM16703P_Init 30 GRB stopped the flicker, but then OBK no longer acted as the live color source. [#21039818]

What’s the best way to run the Arlec Grid Connect desktop bar lights with OBK if you want effects: native OBK control, WLED over DDP, or stock Tuya firmware?

Use stock Tuya for polished app effects, native OBK for simple local control, and WLED over DDP for the richest effects. The tester initially stayed on stock firmware because the vendor app had transitions and music features OBK lacked. By 2024-05-14, OBK worked properly, but the same tester still said you needed WLED via DDP for LED effects at that stage. [#21082111]

How do you initialize the SM16703P or WS2812B-compatible driver correctly in OpenBeken for a 30-LED-per-strip or 60-pixel total setup?

Initialize it with the total pixel count you want the controller to address. The maintainer’s test method was: startDriver SM16703P, then SM16703P_Init [[pixelcount]], then set sample pixels and call SM16703P_Start. Later working examples used SM16703P_Init 60 for both strips together and SM16703P_Init 30 GRB in a DDP-focused setup. Choose 60 for both bars as one chain, or 30 when your active path addresses one 30-pixel sequence. [#21039818]

What does the Tuya JSON from this device reveal about the CBU/BK7231N configuration, including mosi, micpin, ctrl_pin, and colororder values?

It reveals a surprisingly complete hardware map. The JSON shows module: CBU, mosi: 16, miso: 17, micpin: 23, ctrl_pin: 26, key_pin: 22, k2pin_pin: 24, k3pin_pin: 7, LedNum: 30, totallen: 30, and colororder: 2. It also confirms music support with ismusic: 1, which matches the physical microphone noted earlier in the teardown. [#20814361]

Why do colors appear correct in OBK or Hyperion but still come through wrong in WLED even after changing the byte order settings?

Because the mismatch likely sat in the WLED path, not the OBK strip definition. The tester changed byte order in both OBK and WLED, yet WLED still rendered the GRB strip incorrectly. In contrast, Hyperion had an advanced color-order option, and once adjusted there, the colors worked correctly. That makes this an integration-specific failure, not proof that the ALP223HA itself uses the wrong order. [#21038704]

How can you use Hyperion, WLED, DDP, and OpenRGB together with Arlec or Genio smart lights for a cheap whole-room ambilight setup?

Use OBK lights as DDP endpoints, then let Hyperion or WLED feed them. The tester ran multiple OBK lights, mapped different screen regions to different lamps, linked WLED to OpenRGB using E1.31, and used Hyperion to drive the desk bars directly over UDP DDP. That created a low-cost ambilight setup using Arlec and similar lights, with downlights on screen corners and the desktop bar on the center region. [#21038704]

What is the PixelAnim driver in OpenBeken, and what kinds of built-in animations like rainbow or fire does it add for addressable LEDs?

"PixelAnim is an OpenBeken LED animation driver that generates built-in addressable effects locally, without needing an external controller, and adds simple preset patterns for strips that OBK already drives." In this thread, the maintainer said PixelAnim would bring simple effects such as rainbow and fire. Later, the tester confirmed the PixelAnim Driver works properly for changing the addressable LEDs. [#21448123]

How can you control each individual addressable LED from Home Assistant, or expose the LED count properly, instead of having the Arlec light show up as just one light entity?

You currently cannot expose each pixel natively through the Home Assistant setup shown in this thread. By 2025-02-20, the tester said Home Assistant still picked it up as one light, even though PixelAnim could address the LEDs internally. The open request was to expose the number of addressable LEDs or individual LED control to Home Assistant, but no finished method appears in the thread. [#21448123]
Generated by the language model.
ADVERTISEMENT