IDEA: add support for LDR (for automatic brightness adaption)

[c64emulator]

Adding support for LDR would be vary handy. Brightness could be adjusted automatically depending on the brigthness of the environment. Needs an 10k Resistor, a light-dependent resistor (e.g. GL5528), free analog input and some logic.

For more details see https://theorycircuit.com/esp32-projects/interfacing-photoresistor-with-esp32/

[JanPetterMG]

Nice! Such a simple and inexpensive hack. 👍

I think I might have one lying around somewhere, so I might test it some day. Do you think it's possible to mount it behind the panel, or will it suffer from light pollution from the display itself? Currently I'm using Home Assistant for this specific purpose.

EDIT: It's also possible to mount an IR sensor hidden behind the display, that way it's possible to use a TV-remote (or similar) to control it.

[c64emulator]

I have one on the left side below the button:

[JanPetterMG]

What LDR did you mount? Doesn't look like an GL5528.

[c64emulator]

Its a GL5528 inside a LED -Cap

The Caps are from bay or Ali, don't remember.

[c64emulator]

see also at ph1p/ikea-led-obegraensad#74

[JanPetterMG]

Interesting — thank you for the valuable feedback.

In principle, this workload should not be particularly demanding; it operates at roughly four updates per second. For comparison, the Microphone extension performs a similar type of processing at up to 1 000 updates per second, and one of my IKEA Frekvens devices has been running it for some time with good stability. Typically, it only displays the clock or weather — neither of which is computationally intensive — so perhaps I have simply been fortunate.

Both GPIO 2 and 5 are on ADC1 on the S3, which rules out Wi-Fi interference as a cause.

I could imagine issues occurring with the Metaballs effect, as rendering at 60 fps is more demanding. That said, even my ESP32-C3 test unit — significantly slower than the original first-generation ESP32 — handles 60 fps reliably.

---

I have a new draft ready for the LDR/Photocell extension and can open a pull request, though I’m not certain this will be the final version. I’ve removed the threshold slider too, but I’m still evaluating whether the current threshold value strikes the right balance.

[JanPetterMG]

Did you set the threshold value to something very low? Changes in brightness (and many other things) triggers API messages e.g. Web-UI (websocket) and Home Assistant (MQTT).
I've experienced in the past that if I stress the device with a large amount of messages in a short time interval, that it sometimes struggles, crashes and reboots.

Usually there's no issues handling this, but if you're running a relatively demanding mode (like Metaballs) or are unlucky with the timing and it happens during a weather refresh (especially Wttr.in), the watchdog sometimes can trigger if things take too long to process.

[c64emulator]

Did you set the threshold value to something very low? Changes in brightness (and many other things) triggers API messages e.g. Web-UI (websocket) and Home Assistant (MQTT). I've experienced in the past that if I stress the device with a large amount of messages in a short time interval, that it sometimes struggles, crashes and reboots.

Gamma is set to 0,4, Threshold to 50. I have set these values once, the mode was set to Ticking Clock (this is the most selected mode on most of my seven panels). I left the panel alone over night. Just want to make sure that long term stability is rock solid. Important for acceptance (esp. wife and children). How can I see reboots during the night?
I do a scheduled reboot of the WiFi-Router at 4h15 (AM) for stability reasons. WiFi is not available for at least 2 minutes. Could this be a problem?

I have seen that the raw value is on "0.0" during the night. Could this be a problem in some calculations?

[c64emulator]

Changes in brightness (and many other things) triggers API messages e.g. Web-UI (websocket) and Home Assistant (MQTT). I've experienced in the past that if I stress the device with a large amount of messages in a short time interval, that it sometimes struggles, crashes and reboots.

Yeah, happened to me too.
Will try some tweaks (F_INFO vs F_VERBOSE ? Disable HA & MQTT ?) next week. But I like the information in Home Assistant , would miss this.
BTW.: would it be possible to get the Uptime of the device in Home Assistant?

[JanPetterMG]

Gamma is set to 0,4, Threshold to 50.

That’s a perfectly reasonable configuration. In theory, it should generate a message roughly every 13 seconds at most, which is well within safe limits. Under normal conditions, the actual frequency should be much lower.

I have set these values once, the mode was set to Ticking Clock (this is the most selected mode on most of my seven panels).

I haven’t used that mode extensively, but it’s unlikely to have caused any issues.

How can I see reboots during the night? I do a scheduled reboot of the WiFi-Router at 4h15 (AM) for stability reasons. WiFi is not available for at least 2 minutes. Could this be a problem?

Interesting observation. About a month ago, I experienced a few unexpected nighttime reboots over several consecutive nights on an IKEA Frekvens device. The ESP32 USB port on that unit is not easily accessible without dismantling the enclosure, but I noticed via Home Assistant that it would briefly go offline—typically 15 minutes to an hour after my Wi-Fi performed a scheduled channel scan (which causes a 1–2 minute interruption and sometimes a channel change). No crash logs were captured, but the random reboots stopped after a firmware update. I never identified the root cause, and it hasn’t recurred since.

I have seen that the raw value is on "0.0" during the night. Could this be a problem in some calculations?

This should not cause any issues. The code accounts for zero readings.

Will try some tweaks (F_INFO vs F_VERBOSE ? Disable HA & MQTT ?) next week.

F_INFO, F_DEBUG, and F_VERBOSE primarily control the level of logging output to the Serial interface. In a few parts of the code, F_VERBOSE also enables additional diagnostic routines that aren’t generally needed outside of debugging. If you haven’t tried it yet, I recommend enabling F_VERBOSE; it exposes a few extra entities in Home Assistant (e.g.,"Reset reason" and heap/stack tracking) that can help with troubleshooting.

BTW.: would it be possible to get the Uptime of the device in Home Assistant?

Yes, that’s technically possible and something I’ve considered. For my own use, the "device unavailable" timestamps in Home Assistant have been sufficient, and I haven’t found an uptime counter particularly useful beyond curiosity or bragging rights. Still, it would indeed be nice to see something like “Uptime: 100 days.”

The "Reset reason" entity is also a good indicator of reboots, as it updates only during startup.

---

Stability remains the top priority. I regularly fix issues and minor cosmetic bugs as I discover them, but some problems—such as those without crash logs or with unhelpful stack traces—can be difficult to resolve.
There are also occasional quirks specific to certain ESP32 variants. My primary testing is done on a slower single-core ESP32-C3, with occasional validation on the more powerful dual-core ESP32-S3 once the code appears stable. I keep multiple boards of each type readily available, including the first-gen ESP32, though only two devices are currently connected to actual hardware (a third is planned). A fourth device exists within the family but is running an early development build; given its sensitivity to software issues, I’ve avoided updating it despite its age.

[JanPetterMG]

Done! #124

EDIT: See also #129

[c64emulator]

Will try this new V2 in next week. TNX!