[Govee] Brightness Channel is not in sync with color channel #17807
Labels
bug
An unexpected problem or unintended behavior of an add-on
Comments
felixschndr
added
the
bug
|
Two things:
|
|
@stefan-hoehn I was looking at the code, and I certainly see some scope for improvement. So I am working on a PR |
|
@felixschndr in order for me to correctly debug it, can you please turn on |
This comment was marked as outdated.
This comment was marked as outdated.
@felixschndr many thanks for the logs. However I really need TRACE logs (not just DEBUG) please. |
|
Haha
I set the logs of the binding to First case second case |
Again many thanks; but I really really need TRACE on everything please. |
|
^ |
Yes. I am beginning to suspect that the binding has currently a big problem. Internally it has two control paths -- namely the color RGB and the brightness path. And it looks like the binding is commanding the brightness via BOTH paths -- i.e. by reducing the RGB values path AND by the brightness path. That would indeed result in a multiplication effect. I am working on a solution to resolve this. And I would very much appreciate to have your testing support. |
Sorry, bad communication from my side. The first logs were with incorrect loglevel. The second logs were with everything set to
Will try in the afternoon today and get back to you.
Thank you very much for your work! You can send me a debug build any time and I will try it ASAP :) |
|
Ok I am working on it today. I may have a new Jar this evening. I am building on OH V4.3 but it should probably work on your V4.2 system. |
|
@felixschndr see #17812 |
These are the logs for the old/stable binding: Logs of 100% brightness -> lamp off -> send color temp Logs of 19% brightness -> lamp off -> send color temp
Will eat something now, then try and come back to you |
|
^ |
|
See the comments in the PR. Let's stick to that for discussion. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I recently bought a Govee ceiling light and wanted to control it via the LAN API. The device (
H60A1) is not listed as a supported device, but I figured I'd give it a try and return it unsuccessful. Fortunately the device supports being controlled via the LAN API. Thus I was ready to implement it into OpenHAB.However I found a bug: The brightness channel is not in sync with the brightness component of the color channel.
I configured two items as decribed in the docs
Example:
0,100,100(100% brightness).50. The color channel is not updated (stays at0,100,100), however the lamp goes to 50% effective brightness (the actual brightness of the lamp).180,100,100results in a different color but still at 50% brightness.100results in the light ramping up to 100%.180,100,10). This results the lamp to go to 10% brightness while the brightness channel is still at100.0,0,50, brightness20, result: 50% of 20% = 10%) (tbh not entirely sure about how the calculation work, might need to re-check)These channels don't seem to update properly like the channels of other bindings do.
This itself is kinda a bummer but becomes even more problematic when working with color temperature as this only uses the
brightnesschannel.Example:
0,0,50.X(some amount of Kelvin), the light changes to white but starts at 100%.There seems to be a bug in the binding. I wrote three rules and added like some proxy items to build around this but I think this should be fixed in upstream.
@stefan-hoehn and @andrewfg I saw you as a contributor, would you mind taking a look at this? I'd be happy to install debug bindings and send you any logs you might need or provide you with further information.
Please forgive me for pinging (don't want to be rude^^).
The text was updated successfully, but these errors were encountered: