tobi/KDEAmbi
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Docs: Add WLED API information to lessons_learned.md

Browse Source 
Documented findings from WLED API research, including JSON API for configuration and UDP Realtime protocol details, highlighting the default port mismatch.
This commit is contained in:
Tobias J. Endres 2025-08-15 22:46:13 +02:00
parent 1411eff48e
commit b0e4f24f0a
1 changed files with 34 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
lessons_learned.md
View File

@ -150,6 +150,17 @@ This configuration is still primarily handled **within the WLED device itself**.
**Conclusion:** The issue was a mismatch between the sent color order (RGB) and the WLED's expected color order (RGB, confirmed by configuration). The `wled_test` program now correctly demonstrates full color control.
### Current Problem: Flickering with Static Screen
**Observation:** When running `Hyperion_Grabber_Wayland_QT`, some LEDs change color even when the screen is visually static, leading to flickering.
**Diagnosis:**
* Analysis of `output.log` revealed that the `scaledImage` (the input to `WledClient`) is *not* perfectly static, even when the screen appears still. The `WaylandGrabber` or underlying system introduces subtle pixel variations, causing the image checksum to constantly change.
* Our initial image difference threshold (`_changeThreshold_m = 100`) was too low, allowing these minor, visually imperceptible changes to trigger new frames to be sent to WLED.
**Proposed Solution:**
* Increase the `_changeThreshold_m` significantly to filter out the noise from the screen capture. This will prevent sending new frames to WLED unless there's a visually significant change on the screen.
## Ambilight TV Concept
Ambilight TV, primarily a Philips technology, enhances the viewing experience by projecting dynamic, colored light onto the wall behind the television. This is achieved using intelligent LED lights positioned around the edges of the screen.
@ -182,4 +193,26 @@ Given the Ambilight concept, if the LEDs on the left side are not showing colors
1. **Incorrect Sampling/Mapping in `WledClient`:** The `WledClient` might be iterating through the `scaledImage` pixels in an order that doesn't correspond to the physical layout of the LEDs. For example, it might be reading pixels from the top-left to bottom-right of the `scaledImage` and sending them sequentially, but the physical LEDs might be arranged starting from the bottom-left, then up the left side, across the top, and down the right.
2. **WLED Configuration Mismatch:** Even if the `WledClient` sends the data correctly, the WLED device itself needs to be configured to interpret that incoming stream of RGB data correctly for its physical LED layout. If WLED expects a different order (e.g., starting from the top-left LED and going clockwise), but our client sends data starting from the bottom-left, there will be a mismatch.
3. **Scaling/Aspect Ratio Issues:** While less likely to cause a complete side mismatch, incorrect scaling or aspect ratio handling could subtly distort the sampled colors.
3. **Scaling/Aspect Ratio Issues:** While less likely to cause a complete side mismatch, incorrect scaling or aspect ratio handling could subtly distort the sampled colors.
## WLED API Information
Based on research of WLED API documentation (JSON and UDP Realtime):
* **WLED JSON API (HTTP - `/json/info`):**
* Provides detailed, read-only information about the WLED device via a GET request to `http://<WLED_IP_ADDRESS>/json/info`.
* Key information available:
* `leds.count`: Total number of configured LEDs.
* `info.udpport`: The UDP port WLED is listening on for Realtime data (default 21324, but can be changed).
* **WLED UDP Realtime API (WARLS/DNRGB):**
* Confirms that DNRGB (protocol type 4) is the correct protocol for sending LED data.
* The default UDP port for Realtime data is **21324**, not 4048 (which is DDP). This is a critical finding and a potential mismatch with our current code, which uses 4048 by default.
**Implications for Diagnostic Script:**
To improve the diagnostic script, we can:
1. **Fetch `json/info`:** Use `web_fetch` to get the `json/info` from the WLED device.
2. **Extract `leds.count` and `info.udpport`:** Parse the JSON response to get the total LED count and the configured UDP port.
3. **Use extracted values:** Use these values in our diagnostic flashing commands, potentially overriding user-provided `-p` or providing a default `count` for `--flash`.