logo elektroda
logo elektroda
X
logo elektroda

[LF686C20] [BL602] Magic Home RGBW 12-24v 5-pin LED Strip Controller

divadiow 9873 84
ADVERTISEMENT
  • #61 21368686
    divadiow
    Level 35  
    I have not seen any evidence this is being looked into
  • ADVERTISEMENT
  • #62 21369299
    matthewk_dd
    Level 4  
    I was able to compile the examples of the latest sdk under Link
    In that sdk version, the
    components/network/wifi/include/supplicant_api.h
    clearly lists WPA3 as option for authentification.
    WPA3_AUTH_PSK        = 0x09,
    .
    But now we need to use this sdk revision to build the OpenBeken FW...
  • #63 21369309
    p.kaczmarek2
    Moderator Smart Home
    Did BL break compatibility with their samples?
    OpenBL602 is basically a fork of older BL602 SDK version:
    https://github.com/openshwprojects/OpenBL602
    If they didn't break anything, our "shared app" (OpenBeken port) should work with new SDK out of the box:
    https://github.com/openshwprojects/OpenBL602/tree/master/customer_app/bl602_sharedApp
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #64 21369555
    matthewk_dd
    Level 4  
    >>21369309 Before I try to build the app, I checked whether the old demo apps of the OpenBL602 SDK would complile in the new SDK revision. Sure enough, they don't. Looks like they do not find the essential header files. I compared the Makefiles of both versions and noticed that more components had to be added to fix the missing header files. For the "helloworld" demo those were "newlibc hosal mbedtls_lts lwip coredump"

    INCLUDE_COMPONENTS += freertos_riscv_ram bl602 bl602_std newlibc hosal mbedtls_lts lwip vfs yloop utils cli blog blog_testc coredump
    # INCLUDE_COMPONENTS += freertos_riscv_ram bl602 bl602_std hal_drv vfs yloop utils cli blog blog_testc


    With that change it worked for this simple program. I guess there may be more for the app...
  • #65 21370635
    matthewk_dd
    Level 4  
    >>21369555
    After some patching (mostly references to renamed h-files and a compiler flag settings, down to a just a few compile errors.

    (venv) MyTest@Virtual-Ubuntu-24:~/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp$ ./genromap 
    use existing version.mk file
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c: In function 'aos_loop_proc':
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c:753:9: error: too few arguments to function 'vfs_uart_init'
      753 |         vfs_uart_init(fdt, offset);
          |         ^~~~~~~~~~~~~
    In file included from /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c:54:
    /home/MyTest/dev/bl_iot_sdk-master/components/fs/vfs/include/device/vfs_uart.h:91:5: note: declared here
       91 | int vfs_uart_init(uint32_t fdt, uint32_t dtb_uart_offset, const char *node[], int node_max);
          |     ^~~~~~~~~~~~~
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/shared/src/driver/drv_openWeatherMap.c: In function 'sendQueryThreadInternal':
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/shared/src/driver/drv_openWeatherMap.c:163:10: error: 'return' with a value, in function returning void [-Werror=return-type]
      163 |   return 1;
          |          ^
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/shared/src/driver/drv_openWeatherMap.c:137:13: note: declared here
      137 | static void sendQueryThreadInternal() {
          |             ^~~~~~~~~~~~~~~~~~~~~~~
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/shared/src/driver/drv_openWeatherMap.c:167:10: error: 'return' with a value, in function returning void [-Werror=return-type]
      167 |   return 1;
          |          ^
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/shared/src/driver/drv_openWeatherMap.c:137:13: note: declared here
      137 | static void sendQueryThreadInternal() {
          |             ^~~~~~~~~~~~~~~~~~~~~~~
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/shared/src/cmnds/cmd_main.c: In function 'CMD_PowerSave':
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/shared/src/cmnds/cmd_main.c:111:3: error: implicit declaration of function 'wifi_mgmr_sta_powersaving'; did you mean 'wifi_mgmr_sta_ps_exit'? [-Werror=implicit-function-declaration]
      111 |   wifi_mgmr_sta_powersaving(2);
          |   ^~~~~~~~~~~~~~~~~~~~~~~~~
          |   wifi_mgmr_sta_ps_exit
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c: In function '_dump_boot_info':
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c:864:10: error: 'BL_SDK_VER' undeclared (first use in this function)
      864 |     puts(BL_SDK_VER); // @suppress("Symbol is not resolved")
          |          ^~~~~~~~~~
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c:864:10: note: each undeclared identifier is reported only once for each function it appears in
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c:868:10: error: 'BL_SDK_STDDRV_VER' undeclared (first use in this function)
      868 |     puts(BL_SDK_STDDRV_VER); // @suppress("Symbol is not resolved")
          |          ^~~~~~~~~~~~~~~~~
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c:872:10: error: 'BL_SDK_PHY_VER' undeclared (first use in this function)
      872 |     puts(BL_SDK_PHY_VER); // @suppress("Symbol is not resolved")
          |          ^~~~~~~~~~~~~~
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c:876:10: error: 'BL_SDK_RF_VER' undeclared (first use in this function)
      876 |     puts(BL_SDK_RF_VER); // @suppress("Symbol is not resolved")
          |          ^~~~~~~~~~~~~


    The undeclared BL_SDK* errors should be fixable in the mk file.
    Openweather map - no clue.
    Wifimanager - I presume some stuff that was previously not in the SDK has been done in the app, but now is conflicting with the newer version of the wifimanager in the new SDK
    vfs_uart_init - they changed the structure of the uart implementation quite a bit in the new SDK version.

    For the last 2 elements, the demo programs should help to fix it.
  • #66 21370675
    p.kaczmarek2
    Moderator Smart Home
    
    /home/MyTest/dev/bl_iot_sdk-master/customer_app/bl602_sharedApp/bl602_sharedApp/shared/src/driver/drv_openWeatherMap.c:167:10: error: 'return' with a value, in function returning void [-Werror=return-type]
      167 |   return 1;
    

    This means that function type is void but is has a return 1, a small oversight on our part.
    Fix: https://github.com/openshwprojects/OpenBK7231...mmit/c30027db5afc826ee8a6210ed2b1a2c60d7a79f4
    Helpful post? Buy me a coffee.
  • #67 21371840
    miegapele
    Level 15  
    New sdk changed a lot of stuff, because they support more chips, so they moved chip specific code to components.
    I made adjustments to support new sdk and created PR here https://github.com/openshwprojects/OpenBK7231T_App/pull/1487
    It requires sdk to be updated also https://github.com/openshwprojects/OpenBL602/pulls . Biggest app changes are actually in there

    I can build it on linux and it works. HOWEVER, build in github it seems stuck.

    WPA3 and powersave works with new sdk, but it's bigger by 8kb currently. I still looking into what else can be removed
  • ADVERTISEMENT
  • #68 21371859
    p.kaczmarek2
    Moderator Smart Home
    Good job, which new chips could be supported with that?

    I've checked your build run here:
    https://github.com/giedriuslt/OpenBK7231T_App/actions/runs/12570703820/job/35040863378
    Your build log ends with:
    overriding recipe for target 'freertos_riscv_ram'
    /home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp/../../make_scripts_riscv/project.mk:570: warning: ignoring old recipe for target 'freertos_riscv_ram'
    /home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp/../../make_scripts_riscv/project.mk:570: warning: overriding recipe for target 'hosal'
    /home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp/../../make_scripts_riscv/project.mk:570: warning: ignoring old recipe for target 'hosal'
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: execvp: mkdir: Argument list too long
    make[1]: *** No rule to make target '/home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp/build_out/bl602', needed by '/home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp/build_out/bl602/component_project_vars.mk'.  Stop.
    make[1]: Leaving directory '/home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp'
    make: *** [Makefile:177: OpenBL602] Error 2
    

    However, it seems to be an error related to make process itself, and not to the C code, and I don't know make very well. Maybe there are left over rules from older SDK in app? We can also try to ping @insmod , he know Github workflows, maybe he can spot the error?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #69 21372171
    matthewk_dd
    Level 4  
    >>21371840 Thanks for the work, you did get much further than I could even see. :-)
    I tried to use your fork of the OpenBL602 SDK Link, but I cannot compile anything due to a very basic error:
    riscv64-unknown-elf-gcc: fatal error: cannot execute 'cc1': execvp: No such file or directory

    I am pretty sure that I have have correctly set the SDK-Path variable BL60X_SDK_PATH.
    Any hint is welcome.
    BTW, when I set the SDK-Path to the unpatched factory SDK, I can compile all examples, but compile of the shared_App fails first to due to missing <cli.h> (can be fixed by adding cli component, and then at linking due to:
    /home/MyTest/dev/bl_iot_sdk-master/toolchain/riscv/Linux/bin/../lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld: /home/MyTest/dev3/OpenBL602-master/customer_app/bl602_sharedApp/build_out/bl602_sharedApp/libbl602_sharedApp.a(main.o): in function `app_delayed_action_init':
    /home/MyTest/dev3/OpenBL602-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c:71: undefined reference to `Main_Init'
    /home/MyTest/dev/bl_iot_sdk-master/toolchain/riscv/Linux/bin/../lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld: /home/MyTest/dev3/OpenBL602-master/customer_app/bl602_sharedApp/build_out/bl602_sharedApp/libbl602_sharedApp.a(main.o): in function `app_delayed_action_1000ms':
    /home/MyTest/dev3/OpenBL602-master/customer_app/bl602_sharedApp/bl602_sharedApp/main.c:76: undefined reference to `Main_OnEverySecond'
    

    Must be something wrong on my setup, as I saw the autobuild report above.
    For reference, I am using Ubuntu 24.04 and downloaded the code as zip files, not using git clone.
  • #70 21372204
    miegapele
    Level 15  
    My fork is bad, I made that on windows, so executable permissions did not carry over, sorry for that.
    You can fix it by running
    
    find ./ -type f -exec chmod 644 {} \;
    

    On sdk dir, andalso some files were missing for some reason, now added.[/code]

    Added after 46 [minutes]:

    Fixed some of the mess, now build in the PR works, and also OTA works, so you can try my build
  • #71 21372478
    divadiow
    Level 35  
    nice work.

    here is OBK boot log of old SDK vs new

    Code: Text
    Log in, to see the code


    Code: Text
    Log in, to see the code


    Added after 39 [minutes]:

    also, no change with 1mb BL602s with this new SDK. I guess 1mb flash and some partition info needs adjusting somewhere when building. No room for OTA either
  • #72 21372625
    miegapele
    Level 15  
    could also be littlefs, I think I added checks, but maybe it still reads something after 1mb boundary which is where littlefs usually is. Try build without littlefs.
  • #73 21372766
    matthewk_dd
    Level 4  
    >>21372204 Oh, thanks for letting me know that your SDK branch is used on windows. I already found the missing permissions, but that did not fix the missing cc1 error.
    But! Not really needed anymore, because I was able to flash your build on my device and it works! I can confirm Wifi connection using WPA3. Thanks for the great work. From my perspective mission accomplished :-)
  • #74 21376213
    p.kaczmarek2
    Moderator Smart Home
    What's the state of the binary size now? Is it safe to merge? How much size is left until OTA breaks?
    Helpful post? Buy me a coffee.
  • #75 21376234
    miegapele
    Level 15  
    I'm still running it watching if it's stable. Also, I need to backport some fixes from the old sdk, so better to wait a bit.
    Binary size increases from 776 to 780kb, leaving 20kb still
  • #76 21376242
    p.kaczmarek2
    Moderator Smart Home
    Like the MQTT password fix for mqtt.c from LWIP and the threading stability improvement for the LWIP as well?

    Those are the two fixes I remember, but I also remember increasing buffer sizes a bit.

    Is there anything in the firmware that takes much space but we can take it out?

    Or maybe we should split firmware into "BL602-LEDs" and "BL602-power", where first one would have SM2235 and similiar LED drivers, and second would have BL0942 and BL0937? There is no chance that someone would need both those drivers at the same time.
    Helpful post? Buy me a coffee.
  • #77 21376259
    miegapele
    Level 15  
    Yes, there is password fix, there is also some igmp flag to add. I already added all the mqtt buffer changes. Don't see anything thread related.
    Biggest not needed thing looks to be all the tls support with mbedtls, but I was not able to remove that.
  • #78 21376309
    p.kaczmarek2
    Moderator Smart Home
    Ah, the IGMP flag! That's the third required fix indeed. That's needed for multicast/broadcast, as far as I remember. So it needed for SSDP protocol and so also for that Wemo or Alexa integration, I guess.

    I'd rather to keep mbedtls with a #define to enable and disable it easily.
    Helpful post? Buy me a coffee.
  • #79 21556199
    alex113
    Level 3  
    HI, I have this controller, but it's a variant. Mine is not RGB, but a dimmer to compatible leds strips. I think it controls the voltage level on output. The board and chip are the same (looks like).
    Does anybody has a clue if I can control ir with Tasmota FW ?
    Thanks
    Small green printed circuit board with a white cable and electronic components, held between fingers.
    Electronic module with meander-shaped PCB antenna and power wires.
    Electronic module circuit board with visible wires and electronic components, held in a hand.
  • #80 21556222
    p.kaczmarek2
    Moderator Smart Home
    This does not adjust voltage, it's a PWM based dimmer. It should be easy to flash. You can also extend it by soldering extra wires, because transistors are already in place.
    Helpful post? Buy me a coffee.
  • #82 21557939
    alex113
    Level 3  
    >>21556222

    Makes sense...forgot about the PWM...
    One last question before I start: does this FW will work with HA only by MQTT ? Thats because I dont use it.

    Thanks.
  • #83 21561748
    alex113
    Level 3  
    Hi again,

    I'd like some advise.
    I have this LF686C20 RGB controller (it's not RGBW).


    [LF686C20] [BL602] Magic Home RGBW 12-24v 5-pin LED Strip Controller


    Flashed using this tutorial. Everything done with no problem at all (got backup of original).

    But my device is acting strange.
    The MQTT communication between HA and the device is OK, but sometimes the device looses the control over the led strip.
    Ignoring HA, I go directly on web page and change color, but the strip does not follow the commands. The web shows the right color even when coming from HA.

    Also, the PWM pin config are correct, because sometimes it works, changes to the right color, but when it looses the "connection", even the ON/OFF (toogle light) command fails, the strip stays ON. Sometimes, when it is working, I change the color (I don't know if the color matters, but normally to RED) and the device seems to reboot and stay frozen on one color.

    Initially I thought that it could be a energy problem (my USB could not be strong enough), but I connected it to a dedicated power supply (from a router) and I still have the same problem.
    The logs does not say much, exept some INFO about secondsWithNoPing MQTT messages:

    
    Info:MAIN:Time 1375, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1296, socks 2/21 
    Info:MQTT:Publishing val 1 to homeassistant/led_enableAll/get retain=0
    Info:MQTT:Publishing val -1 to homeassistant/led_dimmer/get retain=0
    Info:MAIN:Time 1376, idle 0/s, free 100640, MQTT 1(1), bWifi 1, secondsWithNoPing 1297, socks 3/21 
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/led_enableAll/get
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/led_dimmer/get
    Info:MAIN:Time 1377, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1298, socks 2/21 
    Info:MQTT:Publishing val 0 to homeassistant/led_enableAll/get retain=0
    Info:MAIN:Time 1378, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1299, socks 2/21 
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/led_enableAll/get
    Info:MAIN:Time 1379, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1300, socks 2/21 
    Info:MQTT:Publishing val 1 to homeassistant/led_enableAll/get retain=0
    Info:MAIN:Time 1380, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1301, socks 2/21 
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/led_enableAll/get
    Info:MAIN:Time 1381, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1302, socks 2/21 
    Info:MQTT:Publishing val 590D0D to homeassistant/led_basecolor_rgb/get retain=0
    Info:MAIN:Time 1382, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1303, socks 2/21 
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/led_basecolor_rgb/get
    Info:MQTT:Publishing val 610505 to homeassistant/led_basecolor_rgb/get retain=0
    Info:MAIN:Time 1383, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1304, socks 2/21 
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/led_basecolor_rgb/get
    Info:MAIN:Time 1384, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1305, socks 2/21 
    Info:MQTT:Publishing val 1 to homeassistant/led_enableAll/get retain=0
    Info:MQTT:Publishing val 052161 to homeassistant/led_basecolor_rgb/get retain=0
    Info:MAIN:Time 1385, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1306, socks 2/21 
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/led_enableAll/get
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/led_basecolor_rgb/get
    Info:MAIN:Time 1386, idle 0/s, free 112408, MQTT 1(1), bWifi 1, secondsWithNoPing 1307, socks 2/21 
    Info:MQTT:Publishing val 30509C to homeassistant/led_basecolor_rgb/get retain=0
    Info:MAIN:Time 1387, idle 0/s, free 100640, MQTT 1(1), bWifi 1, secondsWithNoPing 1308, socks 3/21 
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic homeassistant/led_basecolor_rgb/get
    Info:MAIN:Time 1388, idle 0/s, free 88872, MQTT 1(1), bWifi 1, secondsWithNoPing 1309, socks 4/21 
    Info:MAIN:Time 1389, idle 0/s, free 100640, MQTT 1(1), bWifi 1, secondsWithNoPing 1310, socks 3/21 
    Info:MAIN:Time 1390, idle 0/s, free 100640, MQTT 1(1), bWifi 1, secondsWithNoPing 1311, socks 3/21 
    Info:MAIN:Time 1391, idle 0/s, free 100640, MQTT 1(1), bWifi 1, secondsWithNoPing 1312, socks 3/21 
    


    Has someone here clue of what I may have done worng ?

    [LF686C20] [BL602] Magic Home RGBW 12-24v 5-pin LED Strip Controller
  • #84 21563995
    davnozdu
    Level 1  
    >>21561748
    Same problem, afer reflashing my Magic Home with same chip stopped to connected.
    I am erase chip in Flash tab 0x00000000 - 0x001FFFFF
    Then restore backup https://www.elektroda.com/rtvforum/topic4024917.html#20906673
    And then install again firmware for BL602 (uart) but WITHOUT CHIP ERASE (False) and only after this adapter start accepted connect.
  • #85 21564366
    alex113
    Level 3  
    >>21563995

    In my case (I don't remember if I seleções erase option), I could connect perfectly. Web page opened, MQTT configured and the device appeared on HA. But the device was rebooting often.

    Tried another unit and the same problem occurred.
    Got back the original FW on one of them , but on the other I damaged the TX pad. It istill has Beken, need to find a way to access TX on chip to flash it back.. or keep it to test more.

Topic summary

The discussion centers on the Magic Home RGBW LED Strip Controller featuring the LF686C20 chip, which is compatible with BL602 firmware flashing. Users report challenges flashing the device via pogo pins and USB-TTL adapters, with success achieved only when using an external 3.3V power supply directly connected to the V33 pad and BOOT pin, bypassing onboard resistors. Post-flash, stable WiFi operation requires powering the device through the 12V DC barrel jack rather than relying solely on USB-TTL power. Firmware backup before flashing is strongly recommended, with tools like BLDevCube and blflash used for dumping firmware, though full 2MB dumps require specific command parameters. Users experience boot loops and watchdog resets if power supply is inadequate. Configuration of PWM pins is critical due to color channel mismatches; swapping PWM channel assignments corrects color order issues. Integration with Home Assistant (HA) requires enabling specific flags (e.g., flag 24) and re-running discovery to expose light controls properly. WiFi connectivity issues are prevalent, especially with WPA3 security; BL602 devices reliably connect only with WPA2 or mixed WPA2/WPA3 modes, while pure WPA3 causes connection failures. The OpenBL602 SDK used in OpenBeken firmware is older and lacks full WPA3 support, but recent efforts to update the SDK show promise for WPA3 and power-saving features, though compilation challenges remain. IR control is not supported in current BL602 firmware ports, despite some hardware variants including IR remotes or receivers. Variants of the controller exist, including non-RGB dimmer versions using PWM for voltage control. Users report occasional device freezes and loss of LED strip control post-flash, sometimes resolved by restoring original firmware or adjusting flashing parameters (e.g., disabling chip erase). Overall, stable operation depends on correct power supply, accurate pin configuration, appropriate firmware version, and WiFi security compatibility.
Summary generated by the language model.
ADVERTISEMENT