Feature request: Thermal throttle for lightbulbs (LN882H, BP5758D)

[kamilsss655]

Describe the problem
First of all thank you for this great firmware! It is really impressive what you've done!

Currently I am using it on https://openbekeniot.github.io/webapp/devices/Tuya_W505Z2.html E14 9W bulbs. They work great, but they do get hot 90-130C depending on current configuration and unit. Some units when idle show 22C (at 21C ambient temperature) while others show 50C, and another shows 45C at the same time.

Firmware:

• Version 1.18.276
• Device: Tuya E14 9W RGBCCT bulb
• Chip/model: LN882H, BP5758D
• Device config:

startDriver BP5758D
PowerSave 2
BP5758D_Current 7 7 7 7 7 // reaches 90C max temp
BP5758D_Map 3 4 2 0 1

startDriver BP5758D
PowerSave 2
BP5758D_Current 10 10 10 10 10 // reaches 100-110C max temp
BP5758D_Map 3 4 2 0 1

Proposed solution
Considering that these bulbs get hot and temperature reading is already available it might be useful to implement a safety feature (already present in flashlights for example) called "thermal throttling". This could be enabled/disabled by a flag. Basically user could set a certain temperature threshold i.e 100C. In such case if the temp is > 100C, light bulb brightness would be decreased by let's say 5-10% every 10-60 seconds (best if user could configure these params).

This would greatly improve safety of these bulbs, as they would adapt to environment conditions such as ambient temperature, wear parameters drift, accidental physical covering of light bulbs by a blanket etc.

I am not really familiar with the project codebase, so I'd be mostly offering help in testing and feedback. If you decide to follow up on this idea I'd really appreciate it.

[kamilsss655]

I started looking into it and for testing added:

void LED_RunOnEverySecond() {
	if(g_brightnessScale > 0.1)
	{
		g_brightnessScale-= 0.01;
		apply_smart_light();
	}

	addLogAdv (LOG_INFO, LOG_FEATURE_CMD, "g_brightnessScale: %.2f%%", g_brightnessScale);

in src/cmnds/cmd_newLEDDriver.c.
It is dimming down to 9% as expected every 1 second, but after it is dimmed I can no longer turn it back up from web UI - brightness gets stuck at 9%. Probably I should do it a bit differently. Also the brightness change is not shown in web UI. Any ideas?

[kamilsss655]

Ohh LED_SetDimmer((int)(LED_GetDimmer() - 0.01f)); works ! 🎉

I will create some new class related to safety i.e SafetySupervisor or simillar, so it can be extended to other devices in the future. I heard smart sockets have temp sensors as well so it could be a nice addition.

[openshwprojects]

good idea, maybe we coul have it in core obk, but i am not sure now if we want this mechanism to reduce dimmer (the one seen on ui and HA), or to reduce dimming internally (without changing public dimmer). I can see upsides of both approaches

[kamilsss655]

Great to hear you'd be open to this. In such case I will submit a PR once done and tested!

So far I tested both approaches and from my subjective personal user experience I like the throttling being visible in the UI and that's my current approach. It actually looks really cool, and is very distinct as the slider is moving slowly, so this probably will reduce amount of false-positive bug reports etc. With flashlights users can also override throttling by power cycling, so I guess it would match already established industry standard. Of cours appropriate logging will be likely needed like SAFETY throttling triggered! etc.

Haven't figured out higher level config and persistence for this feature, so I will keep it very basic so it could get merged and then maybe you could suggest/shape configuration options like fine adjustment the:

• temp threshold (60-130C),
• step of throttling (0.1-100%),
• time period for throttle step (1-60s)
• etc.

And also whether enabling it would be behind a flag or hidden like PowerSave.

[kamilsss655]

Lol it works.
I will submit a PR with some sane defaults once I test it a bit more, but this is awesome 😄

[kamilsss655]

I should note that I added 3 layers of 1mm thermal pads between the LN882H chip and the aluminum LED board essentially thermally coupling them. This does 2 things:

• when LED is off aluminium LED board acts as a heatsink to the LN882H chip removing hotspots in enclosure
• when LED is on it allows LN882H chip to better measure ambient temperature inside enclosure

@openshwprojects not sure if this is something that could be included in readme as a tip?

[kamilsss655]

@openshwprojects PTAL: #2059

[MaxineMuster]

While I really like the basic idea, I don't know if your "thermal coupling" is a good idea: you rely on the MCU to reduce "heating" but heat the MCU. Yes, it claims to work up to 105 degrees, but how exact is the internal temperature measure? I would at least propose to start throttling well beyond 100!

[kamilsss655]

While I really like the basic idea, I don't know if your "thermal coupling" is a good idea: you rely on the MCU to reduce "heating" but heat the MCU. Yes, it claims to work up to 105 degrees, but how exact is the internal temperature measure? I would at least propose to start throttling well beyond 100!

I am not sure I understand. Can you elaborate?

As I said:

when LED is off aluminium LED board acts as a heatsink to the LN882H chip removing hotspots in enclosure
when LED is on it allows LN882H chip to better measure ambient temperature inside enclosure

For devices without the thermal coupling of LED board to the MCU there might be need to adjust the settings as I said before. And yes, as you've mentioned it might require raising the max temp threshold. However this needs to be tested by more people - I have only 3 same model bulbs, and I proposed defaults that I determined best during my testing. Have you tested it?

Ideally in the future these should be configurable by the users to match their devices thermal properties. It shouldn't be hard to add configuration options to the fields I defined, so you can add such feature @MaxineMuster if you'd like.

[MaxineMuster]

I'll try to explain:
Your setup will be good in case the lamp is off: additional cooling for the MCU, that's fine.
But on the "downside" you use internal temperature sensor in the chip to measure the lamps temperature. So you are probably heating up an MCU, which is better as cool as possible.
I would fear this could drastically reduce lifetime of the chip if it's operated at "higher temperatures as needed", especially if operated near the maximum ratings.

Just an extreme example (you said somewhere temperature is up to 130 °C) but maximum operating temperature for LN882H is 105°C so the temperature can be easy beyond maximum operating temperature (not to mention that it will be no good for a chips lifetime to operate near the limits):
The lamps temperature is rising. You start throttling, if MCU temperature reaches 100° (but it's rising).
If the MCU now fails to reduce heat (fast) enough, temperature might increase even more, and it might stop working (not sure, what will happen then?), and/or (worst scenario possible) it might simply "die".

Or, with other words: these lamps are stress enough for the chips even without increasing the stress ;-)
So maybe just do the throttling, but without coupling the MCU to the aluminum (and accept a much bigger hysteresis) ?

But that's just my theoretical ideas, I don't have such a device...

[kamilsss655]

Yea in theory you are right, but in this particular bulb model there was tendency for the MCU to heat up on idle due to air pocket (as reported by other users on forums). After thermally coupling MCU to LED board this issue is gone. In fact the chip temperatures (both at idle and when LED is on) have dropped due to increased thermal mass. I guess both approaches have their pros and cons, so I guess it is personal preference to decide what works best for you. For me thermally coupling MCU to LED board was a better than not doing it.

However I think we are getting off-topic of the main issue though, which is not hardware, but software related thermal throttling :)