openshwprojects
LN822H has very poor wi-fi responsivity due to overheating when RGB is used
Describe the bug Most of the time, my two LN882H bulbs seem to be experiencing massive packet loss and as a result have very poor responsivity.
It does not seem to matter if the LED bulbs are actually off or on.
It seems that randomly toggling power on and on (physically) makes them sometimes go in a perfectly responsive state, but another reboot will be poor again.
I may be wrong here but I believe I did not reproduce this issue with the LED hat disconnected, I remember it always being responsive before connecting the LEDs - it might be a coincidence though.
Firmware:
- Version: 1.18.110 (second bulb is on a mildly older version with the same issue)
- Device:
- Chip/model: LN882H
- Device config: per device page is enough to reproduce
To Reproduce Steps to reproduce the behavior:
- Power the bulb on
- Ping it
Screenshots
Temp/signal does not seem to be the cause (signal would not make sense, it's meters away from the router):
Issue when it's not that bad, and with the light off - it's at least eventually loading the web UI and configuring is possible, it can be worse:
Often it can also outright dupe packets along with the massive PL:
Perfect connectivity which is what I expect to always happen:
Additional context
[(Tuya) 220v 9W E27 ES RGB+CCT Bulb (2800K-6500K) (W509Z2)](https://www.elektroda.com/rtvforum/viewtopic.php?p=21264807#21264807)
But 20W.
~~The entry is also wrong, it's 2700K, not 2800K, even as per the picture of the device in the entry~~ sent a PR
Try this version for example: https://github.com/openshwprojects/OpenBK7231T_App/releases/tag/1.17.650
I think there is a problem with newer firmwares, above >1.18.
Can I downgrade from the current version to the suggested release or higher without issues?
that is quite far back but I have just tested latest then OTA down to 1.17.650 and it worked. device was not configured with anything, no autoexec.
I have tested a fresh flash of 1.17.650 on a new device from the same batch and after a couple reboots(both SW and physical) I can confirm that I do not have issues there.
So it indeed seems like a regression.
I suppose I'll try flashing newer and newer 1.17.x builds and see what happens.
EDIT: .750 and the latest 1.17.822 seem to work fine too.
wait.... so which commit breaks stability? Currently I have no idea
Me neither, I can't even narrow the version down, right now it all decided to work decently.
I have noticed my most(?) problematic bulb is actually a different RGBCW bulb and the ones I am testing with now that don't seem to have large issues are RGBCCT.
I currently have E14 9W candle bulbs, E27 20W CCT bulbs and a E27 20W CW bulb if I am doing inventory correctly.
I found that spamming this test to be the best way to trigger the issue: watch -n 0.1 'time curl --silent http://192.168.1.219/index'
The results range from 60ms (which I get on another LN882H bulb consistently every time) to seconds when the issues happen.
Is it possible I somehow misconfigured the CCT bulb despite it seemingly working correctly and somehow the issues happen that way?
Atm visiting /app? just effectively hangs the thing and I can't even OTA it from .110 to the latest .122.
EDIT: Disabling the pins in cfg makes it still freeze upon loading effectively anything in the UI. Very weird I was able to browse the UI fine now that I was trying it again until I hit some point, and now no matter what I do it will be in this bad state.
Flashed 1.17.650 on another fresh bulb, could not eventually access /index without it instantly crashing, /about and /ota work fine.
Had to load the webapp directly and flash 1.17.882 ota as /ota at that version does not have the drag-and-drop update.
1.17.882 still crashes on /index instantly.
This is with configured LED driver, MQTT enabled, MAC and name changed, I recall doing nothing else.
I have another bulb on 1.18.110 which I flashed I believe exactly the same way as another identical bulb from the same batch and one of them works beautifully and the other one crashes on accessing /index.
ICMP(ping) always works flawlessly and is a good indicator of when the device is available again.
I recall seeing that LN882H does not overwrite everything, it it possible I have different SDK versions across two bulbs, if so, how would I check?
I believe I do have FW dumps but I am not sure if I can connect exact FW dumps to exact bulbs as my inventory is not that good.
~~Updating the 1.17.x crash bulb to 1.18.0 seemingly stopped the /index crashing.~~ Seems to have been due to me disabling pins and rebooting.
The problematic bulb(#004) that crashes after accessing the UI a few times also seems to have overheating issues, it gets too hot to the touch relatively quickly, but only when the LEDs are on.
#1675 complicated debugging, I am running into multiple issues it seems.
EDIT: It seems that my problem with LEDs #003 and #004 is brutal overheating when RGB is used(only tried max brightness), the CW/WW warm/cool light LEDs hold the temp at somewhat stable 83°C, the RGB I can see getting to 115°C+, which is probably the root cause of the unresponsiveness.
So it turns out I seem to be facing not one, not two, but three(3) issues at once when attempting to access /index across various devices.
- This one, which is the 20W Tuya bulb overheating when RGB (not CW/WW) is toggled on and OBK freezing as a result
- #1675, which is OpenBeken crashing when LED hat isn't connected or is otherwise damaged
- #1684 Lights having bad connectivity due to connecting to the wrong AP, opened #1683 to have an easier time debugging that one
I've added BP5758D_Current 6 6 to my startup command, which is now:
backlog startDriver BP5758D; BP5758D_Current 6 6; BP5758D_Map 2 1 0 3 4
This seems to have resolved the issue for me.
All of my bulbs has now been working fine in RGB at full intensity for >6 hours.
I got this suggestion from here, here, and here.
Getting these bulbs to connect for the first time, however, is always a pain; I usually have to flip a switch ~5 times. I figured out what was causing this! Setting a static IP via the configuration page has completely resolved all initial connection problems. Apparently it had something to do with DHCP. 🤔 🤷🏻♂️
This is the bulb I'm using (20W WiFi E27 RGBCCT, forum). I'm using the latest (as of writing) OpenBeken 1.18.134. (By the way, why isn't this repository named "OpenBeken"? "OpenBK7231T_App" is a bit of a mouthful!)
(By the way, why isn't this repository named "OpenBeken"? "OpenBK7231T_App" is a bit of a mouthful!)
https://github.com/openshwprojects/OpenBK7231T_App/issues/164
It's pretty much just waiting for someone with permissions to rename it.