Some Daybetter 800lm 9W RGB+2700-6500K bulbs don't turn off fully

[dwildstr]

I have OpenBeken flashed onto Daybetter RGBCT lights; these have a BK7231N chipset and use a BP5758D decoder on the light PCB, and a module setup with BP5758D_CLK on pin 7 and BP5758D_DAT on pin 8 works mostly well. It also needed the RGB channels remapped, thought --- blue is channel 0 and red channel 2. Sometimes, however, the lights exhibit a "leaky" behavior when turned off, and slowly brighten back up from dark up to maybe 10% brightness. This behavior persists for long enough that I'm reasonably confident it's not residual charge (and it stops promptly if I cut power to the bulbs). This happens regardless of the bulbs' color (or white temperature) and the color/temperature used before powering off is the one that appears after. It also happens regardless of initial brightness; indeed, if I turn the bulbs off from a very low brightness, the post-turn-off "creep" can end up brighter than it was before being turned off. With a few power cycles the behavior often seems to go away, although it returns when the bulbs are re-flashed with the most recent firmware.

It seems possible this might be at least in part a hardware issue, but there might be a way to control it with the firmware?

[DSchndr]

Same issue as #175 Bug is probably related to the code only enabling sleep mode but not setting outputs to off, it makes sense when one refers to the datasheet

@dwildstr Would you mind flashing a test firmware over ota?

[dwildstr]

Oof, misclick. Sorry about that. I would be happy to flash a test firmware!

[DSchndr]

BP5758D_Fix.zip

Go into webapp, then ota, upload the rbl and test; report on how it behaves :)

[dwildstr]

Looks like lights running this firmware turn fully off immediately. I can stress-test it a bit, try it on some of the lights which have been particularly stubborn about never turning off correctly, but early indications are good.

[dwildstr]

After a bit more experimentation:

Of the 7 bulbs I flashed this on, every single one of them turns off fully immediately, and shows no sign of the "slow creep on" I'd seen before, even after about an hour off. I haven't tested every bulb is every mode, but I've tried them in RGB mode, CT mode, and with various brightnesses, and in all those modes a disable request seems to reliably turn the bulb off. This definitely seems like a fix to the issue, from all that I can see!

When turning off groups with Home Assistant, there's a spread of maybe half a second in latency, which is well within my best expectations for wifi control and is probably more dependent on my network than any firmware particulars.

A few issues seem like retrogressions: for instance when the light is rebooted (either through the API or by power-cycling), it loses current settings and reverts to disabled, white mode, color temp 250, and brightness 100 regardless of what it was set to when rebooted. Flag 12 in release 1.12.56 changed that behavior --- is this firmware an earlier branch?

Thanks so much for your work on this. I eagerly await the merging of this fix into a release.

[DSchndr]

Nice, yes the fw is older since compile time is shorter when it was already built (can probably my codebase update again) Will add pr so it should be fixed in the upcoming releases ^^

[DSchndr]

By the way, are they the same brightness as original firmware or dimmer / brighter? A command to set the current per channel is missing

Also, Dimming could probably be hacked to go even dimmer (if people want it)

[jmacato]

@DSchndr that would be really welcomed, right now the dimming options is not matching the original afaik.

Also, i wonder if we can address the slow RGB color switching issue? I want to transition colors in between but the driver seems to be too bloody slow for it

[dwildstr]

AFAICT, both 1.12.74 and the DSCH_BP5758D_FIX_1 test firmware have the same apparent brightness as each other --- I assume you meant by "original firmware" the stock Tuya firmware that came with the bulbs, and that one does indeed seem to have a different brightness range than any OpenBeken firmware. I've set up a stock-firmware Tuya, an OpenBeken 1.12.74, and a test-firmware bulb of the same type in a single fixture for analysis. This is all by eye, of course --- I don't have any brightness gauging tools. Setting all three bulbs to brightness 100, the Tuya bulb is significantly brighter, and likewise if all three bulbs are set to brightness 1 (the ability OpenBeken has to dim below the bottom of Tuya's range is actually welcome). I then tried to adjust brightnesses, at both ends of the range, to get all three bulbs to the same brightness. Tuya brightness 1 is about the same intensity as something in the 13-16 brightness range for OpenBeken, Comparing at the upper end, however, is trickier. The OpenBeken bulbs I can look directly at even with brightness 100, but the Tuya bulb starts to become painful at about 36% (!), so it looks like the top end of Tuya's native range is way above OpenBeken's. These tests were first done with warm-white light, which I found easiest to differentiate brightness levels with, but those same numbers seem to be about right for cool white and red light as well (and I'd venture every other color and temperature). Some of what I'm seeing here may be subjective and unreliable, but hopefully better than nothing. With a filter of the right opacity I could probably have a more explicitly quantified comparison, but doing it with the tools I have is quicker.

[jmacato]

@dwildstr Yeah I meant the stock Tuya firmware, they seem to have more brightness range as far as i can tell at least.

[openshwprojects]

@dwildstr thanks, do you think that may relate to that current setting? I can make it user configurable, but you see.... I don't know the current requirements of each particular IoT device, and setting too large current may decrease LED life... Anyway, I will make it configurable, will you find some time to check? Thanks!

[dwildstr]

I have a few sacrificial Daybetter bulbs (I got a good price on 12 of them) and can certainly give anything which implements variable current a try. It looks like any current from 1mA to 93mA is possible? (side note: why is that high bit in the current specification 30mA instead of 64mA? Tuya design is so weird...)

I'm not much of a hardware guy, or I'd attach traces to a stock bulb somewhere and measure current flow while it's live, but even though I can disassemble a bulb, I don't see easy pads to test current flow to the LEDs.

As a population of 1, I at least would welcome a current-modification option somewhere on the user-facing configuration --- with appropriate warnings on degrading the device life, but anyone flashing OpenBeken is hopefully savvy enough to acknowledge those tradeoffs.

What could be really cool, but might be obnoxiously difficult to do right, is for the user-facing current configuration to be regarded as a maximum, and for lower brightness levels to utilize lower current, because the stock Tuya minimum brightness (and, I would wager, the minimum brightness on OpenBeken configured for a higher current) is actually not all that dim.

[openshwprojects]

I will do it, this will be in a form of console command, wait

[openshwprojects]

@dwildstr done https://github.com/openshwprojects/OpenBK7231T_App/commit/387a3a4ff3d19ec729c95ad73153865333609f6f Tested, it indeed changes the brightness, but I have not tested what happens in higher current modes, I don't want to burn the LEDs.

Btw, what kind of Daybetter bulbs do you have? Can you post some teardown photos on our forums and add a device template? https://www.elektroda.com/rtvforum/forum507.html https://github.com/OpenBekenIOT/webapp/blob/gh-pages/devices.json

[dwildstr]

Awesome, I'll flash that firmware and play with current changes. The template for the Nous P3-A60-RGB-CCT is identical to this bulb's module configuration. It doesn't have a really nice model number; "800lm 9W RGB+2700-6500K" is a direct transcription of the closest text appearing on the bulb itself to a model identifier.

I can post teardown photos at some point, probably after I stress-test a working bulb to death by playing with the current. They're held together with a lot of glue and I don't think they would remain functional after disassembly. Aspects of it look a lot like the aforementioned Nous; one big difference is that it has a 4-pin rather than a 6-pin connection between the lighting circuit board and the MCU circuit board.

[openshwprojects]

Wow, a stress-test to death would be a great ending for the teardown article! I'm eager to see the results, if you're really willing to sacrifice a bulb, do it and post it on our forums.

For the record, is the flash dump submitted for tuya-cloudcutter?

[dwildstr]

No flash dump submitted (and unlikely to be; I'm not much of a hardware guy and was relieved to no end that I could reflash these bulbs away from stock firmware OTA, because I am not good at soldering), but the bulbs respond well to the "Tuya-Generic/E27-RGBCW-Smart-Life-WB2L_M1" profile. If at some point I do a full teardown on a stock bulb, maybe then I might solder up the means to take the firmware off, but since a generic profile works, there doesn't seem to be much urgency.

[openshwprojects]

Wow, they respond to the profile that used flash submitted by me. I'm happy that I helped! Please remember to note that in teardown. There is no need for second flash dump if they already respond to existing profile.

[dwildstr]

On my exceedingly unscientific "painfulness to look at" measure, a current setting of 252 (which corresponds to 90mA, if I'm reading the report on how the current bits are interpreted correctly, although there's something weird about the high bit --- a current of 128 should be 30mA according to the comments, but it's dark. Does the high bit only work in combination with the next bit, to describe a total current of 62?) has a comparable max brightness with the Tuya-stock bulb, but at the low end it's much dimmer. But Tuya's 1% dimness, frankly, is way too bright, and I can honestly imagine OpenBeken is straight-up better.

This does seem to suggest that these bulbs use 90mA in their stock configuration, so that that nothing I can do with making the BP5758D use a high current will cause any entertaining failure modes, because their normative use is already about as high as we can command a BP5758D to produce (AFAICT, that's 93mA, with all bits on in the current spec). But I'll run one at 93mA for a few hours, see if there is heat buildup or burnt-out LEDs or anything like that.

[dwildstr]

Followups: the base gets very hot. It felt painful to touch, which wasn't a very scientific standard, so I jammed a meat thermometer up in there and got a reading of 126.3 degrees (Fahrenheit). The stock Tuya was similar, clocking in at 124.9. The base of a bulb running at 14mA came in at a considerably cooler 102.5.

Just for fun, I tried executing BP5758D_RGBCW FFFFFFFFFF on the bulb running 93mA, just to max out everything I could --- so now it's not only running at 93mA; it's doing it on all 5 channels. I don't know, however, whether the amperage is per channel or total; if the latter, than obviously this not-real scenario (since in standard usage the bulb would never run more than 3 channels simultaneously) isn't even a good stress test. It's not noticably hotter than the stock bulb, even doing that.

Anyways, this test suggests that making the current user-selectable can bring these bulbs at least up to parity in brightness with their stock-firmware peers without damage, but that it might not actually be a good idea to do so. I can well imagine that the stock firmware pushes the LEDs harder than is really good for their long life.

[jmacato]

@dwildstr idk if you noticed it but is your bulbs outputs good enough white color on RGB mode? I noticed that it's a bit too bluish on my bulbs... That's i always had a command to turn on all channels (RGB+CW) on startup so that it has better daylight color. Not sure if that's a good way to go though lol

[dwildstr]

On the current: it occurred to me I was perhaps overthinking things. The bulbs are labeled right on them as 9W bulbs, and the BP5758D apparently moderates the current on mains voltage (rectified to DC, I assume?) delivered to the lights themselves in series. They're US bulbs, so mains voltage here is 120V, and 9W/120V=75mA. That's pretty close to the upper range --- I'm not sure I could eyeball the difference between 93mA and 75mA.

@jmacato Yeah, I don't like the color temperature of an RGB #FFFFFF from these bulbs. I'm frankly pretty comfortable with the CT control provided by the two white channels, so don't see much reason to go into these both-at-once states except as a gimmick.

[jmacato]

@dwildstr right now the toggle on/off feature only restores the RGB lights, it would be great if it can restore the states of the CW channels as well.. any thoughts @openshwprojects @DSchndr ? Should i make a feature request for this?

[dwildstr]

Woop, guess I'm doing that teardown a little sooner than expected. I was trying to get a multimeter read on the voltage across the two pins which provide voltage to the LEDs, and accidentally shorted them out. Flash, pop, and there's now a scorched spot labeled "R2" on the mainboard where an SMD resistor used to be.

Taken lots of pictures, identified pretty much every component. I'll write it up this weekend.

[DSchndr]

@jmacato huh, does the color get set when you manually set the channels? (after turning all channels off) if so the bug is probably not in the driver (since it just takes its rgbcw values and writes them) Yeah, open a new issue since this one is pretty much completed :)

[jmacato]

@DSchndr please check https://github.com/openshwprojects/OpenBK7231T_App/issues/249

[openshwprojects]

@jmacato huh? for my bulbs On/Off button remembers all stuff, including brightness, color, and CW slider state.

[dwildstr]

Here's the promised teardown: https://www.elektroda.com/rtvforum/topic3925050.html

[openshwprojects]

Thanks, I will add this to devices.json.

Is the issue now resolved, can I close this?

[dwildstr]

Thanks. It's long resolved, really (was as of release 1.12.76). Even though the discussion was continuing with new issues, the original concern was definitely addressed.