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

Name: Arlec Grid Connect Smart Desktop Bar Lights - Twin Pack - Teardown
Uploaded: 2023-11-09T03:02:35+01:00
Description: 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 Flashing of Main Chip CloudCutter Profile - Profile.json I created a CloudCutter profile using LightLeak ....

Question

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 Flashing of Main Chip CloudCutter Profile - Profile.json I created a CloudCutter profile using LightLeak ....

p.kaczmarek2 · Answer

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.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

wolfieeewolf · Answer

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 Download (1.12 MB)

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.

wolfieeewolf · Answer

Managed to get the firmware dumped using BK Flasher

readResult...-28-10.bin Download (2 MB)

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

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.

wolfieeewolf · Answer

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 thisCode: text Expand Select all Copy to clipboardDevice 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

p.kaczmarek2 · Answer

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

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

wolfieeewolf · Answer

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 Code: text Expand Select all Copy to clipboard{ 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  } Code: text Expand Select all Copy to clipboardDevice 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 Code: text Expand Select all Copy to clipboard{ 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  } Code: text Expand Select all Copy to clipboard 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 Code: text Expand Select all Copy to clipboardDevice seems to be using CBU module, which is BK7231N chip. - Control Pin (TODO) on P26 - Pair/Toggle All Pin on P22

p.kaczmarek2 · Answer

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?

wolfieeewolf · Answer

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.

p.kaczmarek2 · Answer

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?

wolfieeewolf · Answer

Correct.

p.kaczmarek2 · Answer

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!

wolfieeewolf · Answer

Have managed to get this device somewhat working with the followingautoexec.batCode: text Expand Select all Copy to clipboard-- 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 againHome Assistant doesn't discover the device fully.So far only build, RSSI and uptime are being discovered.Add this to your config.yamlCode: text Expand Select all Copy to clipboard 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/getSo 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

p.kaczmarek2 · Answer

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 != .

wolfieeewolf · Answer

I just used the script that was posted by igfotfrank on the following post. It was the last script on the post.

OpenBeken WS2812B driver (compatible with SM16703P, etc) - short scripting presentation

Which script should I follow? The ones that are in the first post?

p.kaczmarek2 · Answer

Maybe try that one, but I am not sure how good will it fit for you:

wolfieeewolf · Answer

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.

wolfieeewolf · Answer

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

wolfieeewolf · Answer

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.

p.kaczmarek2 · Answer

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? There is option to change byte order: What do you mean by adding UDP? DDP protocol for LEDs is already using UDP, so there is no way to add it.

wolfieeewolf · Answer

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

wolfieeewolf · Answer

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.

wolfieeewolf · Answer

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.

p.kaczmarek2 · Answer

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.

wolfieeewolf · Answer

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.

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

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Topic summary