Persistently cache brightness, color temp, and RGB - #59
Draft
zacharee wants to merge 1 commit into
Draft
Conversation
zacharee
force-pushed
the
fix-color-brightness
branch
from
January 31, 2026 00:42
fd8fc2e to
d066dfb
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change adds a cache object to persist the RGB, color temperature, and brightness values the integration sends to lights across Home Assistant restarts so it doesn't have to recalculate inaccurate values every startup.
For brightness, I added a sanity check for the cache where if the difference between the cached value and the returned value is greater than 3, the integration will assume the cache is stale. I think 3 is a safe threshold value since the ratio of 100:255 is just about 2.5.
For color temperature, I think we could probably also have a sanity check threshold but I don't understand the logic used to calculate the value from the API, so right now it just always assumes the cached value is correct if it exists.
For RGB, I made use of those functions Gemini made discussed in #54 to both do a sanity check comparison and improve the best-guess reversal calculation if there's no cache or the cached value is determined to be stale. From my testing, the function the AI generated to convert RGB to whatever Sengled's values are occasionally flips the weakest channel's value from 0 to 1 and vice-versa compared to the light's behavior, so the comparison ignores it altogether. For the middle channel, scaling by brightness doesn't always get it back to the right value, so there's some tolerance built in.
I haven't had a chance to test this, so it probably needs some changes before it's merged.