logo elektroda
logo elektroda
X
logo elektroda

[BK7231N] TIMEGUARD WLFLB22 - 10W RGB/W/WW - Colour Temperature Issues

Rectified4939 1386 6
ADVERTISEMENT
  • #1 20583579
    Rectified4939
    Level 2  
    Hi all,

    This is my first time trying anything like this so apologies for any stupidity in advance. I've had a couple of the bulbs pictured for a while using Tuya Local in Home Assistant but got fed up with them disconnecting so decided to have a try using tuya-cloudcutter and flashing with Openbeken.

    I successfully flashed with BK7231N and determined that it is a BP5758 using P6 as DAT and P9 as CLK.

    This work but I didn't really consider the fact this bulb is RGBW rather than RGBCW. I've used the Flag 24 ("Flag 24 - [LED] Emulate Cool White with RGB in device with four PWMS") which works, but the colour temperature is way off, with far too much cold white being used. This is also additionally problematic because when the device appears in Home Assistant the lowest Kelvin that's available in the controls is 2702K, compared with 2000K when using OpenBeken directly.

    Are there are settings that I can use to help resolve these issues?

    [BK7231N] TIMEGUARD WLFLB22 - 10W RGB/W/WW - Colour Temperature Issues [BK7231N] TIMEGUARD WLFLB22 - 10W RGB/W/WW - Colour Temperature Issues [BK7231N] TIMEGUARD WLFLB22 - 10W RGB/W/WW - Colour Temperature Issues [BK7231N] TIMEGUARD WLFLB22 - 10W RGB/W/WW - Colour Temperature Issues [BK7231N] TIMEGUARD WLFLB22 - 10W RGB/W/WW - Colour Temperature Issues [BK7231N] TIMEGUARD WLFLB22 - 10W RGB/W/WW - Colour Temperature Issues [BK7231N] TIMEGUARD WLFLB22 - 10W RGB/W/WW - Colour Temperature Issues
  • ADVERTISEMENT
  • #2 20583913
    p.kaczmarek2
    Moderator Smart Home
    Hello, thank you for your interest in OpenBeken.
    The 'emulated' color is currently not perfect, because there are not many such devices in the market.
    If you have some concrete ideas how to fix it, maybe know the formula for the colour calculation, please share, I can implement it in code for you maybe even within a day. I am ready to help, although I don't have personally much knowledge when it comes to colours, I know C.
    I can also give you some API for calibration, I don't know, give the ability to set the white fraction (if you think it's too much), but I would need to know the math behind it.
    Regarding HA temperature range - the display range is currently customizable, but it's purely for GUI/HA display:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
    Search for the "CTRange" command.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #3 20585249
    Rectified4939
    Level 2  
    Hi there,
    Thanks so much for your quick response. I'd love to help try and figure this out a bit but you will have to bare with me as my C is not so good.
    My understanding from the code is that when you set a value on the temperature slider (not sure what this value is, 0-100?, or how it maps to Kelvin, linearly?) this value is used as a brightness for the CW and WW LEDs. So if it was set at 75 the CW would be at 75% brightness and the WW at 25% brightness. When the cool colour is emulated using the RGB then the brightness setting for CW is instead applied to each of the R , G & B LEDs. Is this all correct?

    This causes a few problems with this bulb. I suspect that all the RGB LEDs (which there are more of than on most other bulbs I've seen) were never intended to be driven at full brightness - the bulb gets VERY hot if I set the Kelvin to 10000K full brightness. So, yes as you suggest simple API settings to limit maximum brightness when CW is being emulated, and also to scale the proportion of CW being emulated (probably just linearly would be sufficient) would be a potential quick fix.

    In terms of figuring out a better way, I wrote a function (at bottom of post) in R code that the moment (sorry!) adapted from this site https://tannerhelland.com/2012/09/18/convert-temperature-rgb-algorithm-code.html - I’ve no idea how well it will work with light, but hopefully it’s a start, the input is Kelvin and the output RGB values between and 255, but I can adjust the maths once I understand what the input and output values are to be. Eventually it will need to be altered to correct for the fact that the WW LEDs are also on.

    Is there a way I can directly control the brightness of the R,G,B and WW LEDs individually in the app so that I can play around with combinations?

    predict_rgb <- function(Kelvin, r=255,b=255,g=255){
      t<-Kelvin^(-1/2)
      if(Kelvin <= 6500){
        g <- (428 -16183 * t + 144106 * t^2)
        b <- (639 - 35597 * t + 353836 * t^2)
      }else{
        r <- (177 -11199 * t + 1401602 * t^2)
        g <- (196 -5534 * t + 789215 * t^2)
      }
      if(Kelvin < 2000){
          b <- 0
        }
      c(ceiling(r), ceiling(g), ceiling(b))
    }
  • ADVERTISEMENT
  • #4 20585278
    p.kaczmarek2
    Moderator Smart Home
    Thank you for this function, I will try to somehow integrate it with an option to enable it, so you can test with it in reality.

    If you want to control raw PWM values, you can enable "Show Raw PWM controls" in the Flags menu. This should show per-PWM sliders on the WWW panel. Please check if it works for you.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #5 20586491
    Rectified4939
    Level 2  
    Amazing thank you. Once I see how you go about implementing it I can probably play around with further tweaks.

    That flag doesn't appear to do anything for me - is it possibly because they are using I2C and not PWM?

    I also wondered, how difficult would it be to change how the WW LED's behave when emulated CW mode is being used. I ask because how these bulbs appear to work is to use the WW for a large portion of the Kelvin scale, compensating by only turning on the green and blue LEDs to achieve a cooler light.
  • #6 20586529
    p.kaczmarek2
    Moderator Smart Home
    Ah, sorry, I haven't taken in the account the fact that your bulb is I2C-like based. Showing raw PWMs is not possible in this case because there are no PWMs to be shown.

    So, assuming that your bulb BP5758 , just as you said in the first post, the correct way to do it is:
    
    BP5758D_RGBCW FF00FF00FF
    

    By the way, you can find those commands in docs, here:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
    Search for BP5758 .



    Rectified4939 wrote:

    I also wondered, how difficult would it be to change how the WW LED's behave when emulated CW mode is being used. I aks because how these bulbs appear to work is to use the WW for a large portion of the Kelvin scale, compensating by only turning on the green and blue LEDs to achieve a cooler light.

    The interface is currently very crude:
    [BK7231N] TIMEGUARD WLFLB22 - 10W RGB/W/WW - Colour Temperature Issues
    Here is how it is called, we could plug other function here...
    [BK7231N] TIMEGUARD WLFLB22 - 10W RGB/W/WW - Colour Temperature Issues
    But you could do something like:
    
    void LED_CalculateEmulatedCool(float inCool, float *outRGB) {
    	outRGB[0] = inCool * FRACTION_FOR_R;
    	outRGB[1] = inCool* FRACTION_FOR_G;
    	outRGB[2] = inCool* FRACTION_FOR_B;
    }
    

    This would be very simple to do and may be nice, but what kind of fractions would we set? Also maybe we need also to weight somehow more the influence of W channel, and that may require further modifications.

    Regarding your code with Kelvin, we are internally using Mireds, just like HA:
    Code: C / C++
    Log in, to see the code

    If you are able to give me for example formula for mireds, that gives results for R, G, B, and W, then I could try to implement it in code for you.
    Helpful post? Buy me a coffee.
  • #7 21097077
    ahmedaltaani400
    Level 1  
    كيف أعرف التطبيق لمصباح واي فاي

Topic summary

The discussion revolves around issues with the Timeguard WLFLB22 RGBW bulb after flashing it with OpenBeken firmware using the BK7231N chip. The user experiences incorrect color temperature settings, particularly with the emulation of cool white light, leading to excessive cold white output. Suggestions include implementing a calibration API to adjust the white fraction and controlling raw PWM values, although the bulb operates on an I2C-like basis, complicating direct PWM adjustments. The conversation also touches on the need for better control over the WW LEDs during cool white emulation to achieve a more accurate Kelvin scale representation.
Summary generated by the language model.
ADVERTISEMENT