[govee] Fix brightness vs. color synchronization

[andrewfg]

Resolves #17807
Resolves #17823

Also includes the following..

• Fixed: synchronization of brightness vs color channels (original issue)
• Fixed: communication issue when using textual host names rather than IP addresses
• Fixed: device discovery on machines with ethernet v6 and v4 on same interface.
• Fixed: prevent device overload due to refresh cycle less than 2 seconds
• New: faster update of channels when commanded
• New: support for many more light models
• New: support for configurable min/max color temperature ranges of lamps
• New: added dynamic state description provide to enhance color temperature UI experience
• Enhanced: read me enhanced to include all of the above
• Normalized thread name (see Normalize thread names #17804)
• Redesigned threading model using java.nio

Signed-off-by: AndrewFG [email protected]

[andrewfg]

You can download the jar for test purposes below. Uninstall the standard binding, then unzip the file below and drop it in your /addons folder. Note: there are two zipped Jar files -- namely for OH 4.3.1 on Java 17 and OH 5.0.0 on Java 21

org.openhab.binding.govee-4.3.1-SNAPSHOT.jar.zip

org.openhab.binding.govee-5.0.0-SNAPSHOT.jar.zip

[felixschndr]

Can we add the H60A1 to govee.properties? I guess that's why I get the error message thing Handler for 192.168.4.237 couldn't be found.

[felixschndr]

I also noticed something about color temp: The color temp abs works fine, I defined a min and max in the sitemap so I can only send values that are supported by the lamp.
However, the color temp relative only works partially. When sending high values, the lamp goes off because we are sending an abs color temp that is too high.
I don't know if there's anything we can do about this, as the bind probably doesn't know the min and max values for the color temp. In my case they are 2200 <= x <= 6500, but I don't know if they are the same for all Govee lamps.

[andrewfg]

Two things..

1. re the HSB update after brightness command: probably it is only updated on the next polling cycle (?) .. but I will see if I can fix this..

2. re the color temperature range: the binding constraints the limits to 2000 .. 9000 K so if the lamp is more constrained then odd results are expected .. but let me have another look at this..

[andrewfg]

PS you also mentioned that you have a lamp which is not (yet) supported .. can you provide more info about it .. and I will see if I can fix that too..

[andrewfg]

Is the H60A1 the one on 192.168.4.237 ?? You say it works fine. But you also say it reports an error..

[andrewfg]

problem is in both directions

Yeah, it would be..

[felixschndr]

Is the H60A1 the one on 192.168.4.237 ?

Yes it is.

But you also say it reports an error..

You mean the thing Handler for 192.168.4.237 couldn't be found.? I figured this was since the device type is not defined in the govee.properties, isn't it? The communication works flawlessly

[andrewfg]

I will add your H60A1 to the properties file. This simply allows to display a clear text label in the thing properties. However this DOES not solve the "thing Handler .. couldn't be found" error. If you say that 1) it works, and 2) it shows the error message, then this probably means that you have two duplicate things defined on the same IP address, and one is working, and the other is giving the error. Or something like that.

[felixschndr]

If you say that 1) it works, and 2) it shows the error message, then this probably means that you have two duplicate things defined on the same IP address, and one is working, and the other is giving the error. Or something like that.

That's not it. I double checked the MainUI and the config files. I only got this one Govee thing. Also, if I comment out the thing I got, the message disappears.

Edit: Weird… After removing the comment (adding the thing again) the message does not come up again. After restarting the binding the message appears again

[felixschndr]

Can you please create a jar from you last commit for me to test?

[felixschndr]

One thing that could be useful: A string channel which states whether the lamp is in color temp mode or in color color mode. I think that could become pretty useful in some rules. Would it be possible to implement that? Thank you very much for your work!!

[felixschndr]

I noticed that the color temp must be a Number:Temperature item. If it isn't the channel only sends e.g. 6500 (with no K) which leads to no change:

2024-11-27 22:05:27.456 [INFO ] [openhab.event.ItemStateChangedEvent                                             ] - Item 'Licht_Arbeitszimmer_Deckenlampe_Farbtemperatur' changed from 6000.0 to 4900
2024-11-27 22:05:27.463 [DEBUG] [org.openhab.binding.govee.internal.GoveeHandler                                 ] - handleCommand(govee:govee-light:Licht_Arbeitszimmer_Deckenlampe:color-temperature-abs, 4900)
# nothing

This is with the :Temperature attribute:

2024-11-27 22:06:04.506 [INFO ] [openhab.event.ItemCommandEvent                                                  ] - Item 'Licht_Arbeitszimmer_Deckenlampe_Farbtemperatur' received command 3600 K
2024-11-27 22:06:04.511 [INFO ] [openhab.event.ItemStateChangedEvent                                             ] - Item 'Licht_Arbeitszimmer_Deckenlampe_Farbtemperatur' changed from 4900 °C to 3326.85 °C
2024-11-27 22:06:04.517 [DEBUG] [org.openhab.binding.govee.internal.GoveeHandler                                 ] - handleCommand(govee:govee-light:Licht_Arbeitszimmer_Deckenlampe:color-temperature-abs, 3600 K)
2024-11-27 22:06:04.518 [DEBUG] [org.openhab.binding.govee.internal.GoveeHandler                                 ] - sendKelvin(3600)

Can we change this such that a Number without the :Temperature works as well?

[andrewfg]

Edit: Weird… After removing the comment (adding the thing again) the message does not come up again. After restarting the binding the message appears again

Could you provide a trace log around that sequence of events?

[andrewfg]

Can we change this such that a Number without the :Temperature works as well?

I would like to focus on fixing the bug(s) first, before we consider extending the features.

[andrewfg]

A .. channel which states whether the lamp is in color temp mode or in color color mode

Not really. If you look at the CIE color space you will see that color temperatures are points which lie on the Planckian locus within the color space. And when you command a Govee lamp to a particular CT it causes the lamp to select an RGB value (i.e. color XY value) for that point. Therefore when you send a new CT, both the CT channel, and ALSO the Color HSB channel will be updated to match. Or to say it in other words, there is no such thing as Color resp. Color Temperature mode.

---

EDIT: however the color temperature channels will be UNDEF if the color point is NOT on the Planckian locus. So that would perhaps be the indicator that you are looking for.

[andrewfg]

Can you please create a jar from you last commit for me to test?

The Jar in the post above has now been updated to the latest commit.

[andrewfg]

Apropos the "handler couldn't be found" .. when a lamp sends an update, the code takes one of two possible forks -- namely if the handler can be found it processes the update, and if it can't be found it outputs the error message. However you are saying that it does both, which is a kind of Schroedinger cat condition...

[andrewfg]

@lsiepel this one is (finally) ready.

[lsiepel]

Nice patch! Left two comments, otherwise LGTM

[stefan-hoehn]

@andrewfg Do you think that this is going to be 5.0 only, or will there be a backport for 4.x? (In the meantime I cherry picked to 4.3.x locally and I will install probably this weekend on my production system.

[andrewfg]

Do you think that this is going to be 5.0 only, or will there be a backport for 4.x?

According to OH principles only bug fixes shall be back ported. So following those principles I guess it should not be (officially) back ported. However nevertheless I see some benefit for "selected" users to be able to run it on OH 4.3. Fortunately, if you follow the code in the message below, it is easily possible to (unofficially) back port it.

https://community.openhab.org/t/openhab-5-x-snapshot-requires-java-21/160890/5

 mvn install -Pj17 -Dohc.version=4.3.0 -pl :org.openhab.binding.govee

[andrewfg]

it isn't working. I get

2024-12-22 16:16:21.764 [TRACE] [govee.internal.GoveeDiscoveryService] - After try

There is no "After try" log message any more in the latest version. So whatever version you are testing is probably the standard OH 4.3.x release version. You need to uninstall the release version. Probably clean-cache in order to remove the release version entirely. And then drop the new version into you addons folder. The backported version needs to have been compiled for Java 17 and a target version of OH 4.3.x If the Jar was built in the new OH 5.0 build system it will be built with Java 21 for OH 5.0 .. which will not load on OH 4.3 (and that may force OH to go out and look for a compatible (i.e. prior) version.

do you have a pre-compiled version I should try out?

There is one in the post at the top of this thread. (It does not have the change I made today for @lsiepel but it should work for you). I will build a final final jar when we are done.

[stefan-hoehn]

There is no "After try"

Sorry, my bad, I messed up with the merge and then rebuilding. I finally checked out your PR and mvn install -Pj17 -Dohc.version=4.3.0 -pl :org.openhab.binding.govee and it works well (btw, in this case I intentionally used an RP3! to try around with that) and it nicely detected my devices. 🥳

[lsiepel]

mvn install -Pj17 -Dohc.version=4.3.0 -pl :org.openhab.binding.govee and it works well (btw, in this case I intentionally used an RP3! to try around with that) and it nicely detected my devices. 🥳

Slightly offtopic. Afer each release i have this issue. The given command does not build 4.3.0 jar's from main branch. It shows this error:
Unknown lifecycle phase ".version=4.3.0". You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>. Available lifecycle phases are: pre-clean, clean, post-clean, validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-site, site, post-site, site-deploy.

PS C:\oh-dev\openhab-addons> mvn -version Picked up _JAVA_OPTIONS: -Xmx4096m Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) Maven home: C:\ProgramData\chocolatey\lib\maven\apache-maven-3.9.9 Java version: 21.0.5, vendor: Azul Systems, Inc., runtime: C:\Program Files\Zulu\zulu-21 Default locale: nl_NL, platform encoding: UTF-8 OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"

[andrewfg]

The given command does not build 4.3.0 jar's

Maybe add the clean switch too?

mvn clean install -Pj17 -Dohc.version=4.3.0 -pl :org.openhab.binding.govee

[andrewfg]

^
I built two new Jars based on my todays' commit. They are in the post at the top of this thread.

[stefan-hoehn]

I have updated my production system and I would say so far that it looks pretty good. The only thing that happened in the logs is "Failed to normalize configuration for new thing"

Failed to normalize configuration for new thing during update 'govee:govee-light:28_A5_D0_18_CB_B0_D4_BA': {thing/channel=Type description govee:color-temperature-abs for govee:govee-light:28_A5_D0_18_CB_B0_D4_BA:color-temperature-abs not found, although we checked the presence before.}
2024-12-22 20:05:26.415 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'govee:govee-light:28_A5_D0_18_CB_B0_D4_BA' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2024-12-22 20:05:26.418 [INFO ] [core.thing.internal.ThingManagerImpl] - Updating 'govee:govee-light:28_A5_D0_18_CB_B0_D4_BA' from version 0 to 1
2024-12-22 20:05:26.440 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'govee:govee-light:c3a2d5d16f' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2024-12-22 20:05:26.442 [INFO ] [core.thing.internal.ThingManagerImpl] - Updating 'govee:govee-light:c3a2d5d16f' from version 0 to 1
2024-12-22 20:05:26.464 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'govee:govee-light:0B_12_D6_39_32_35_18_7F' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2024-12-22 20:05:26.466 [INFO ] [core.thing.internal.ThingManagerImpl] - Updating 'govee:govee-light:0B_12_D6_39_32_35_18_7F' from version 0 to 1
2024-12-22 20:05:26.491 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'govee:govee-light:2F_C6_CE_32_32_33_66_58' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2024-12-22 20:05:26.492 [INFO ] [core.thing.internal.ThingManagerImpl] - Updating 'govee:govee-light:2F_C6_CE_32_32_33_66_58' from version 0 to 1
2024-12-22 20:05:26.518 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'govee:govee-light:33_5F_60_74_F4_08_77_21' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2024-12-22 20:05:26.519 [INFO ] [core.thing.internal.ThingManagerImpl] - Updating 'govee:govee-light:33_5F_60_74_F4_08_77_21' from version 0 to 1

[andrewfg]

^
Apropos the channel type updates, I am not sure why you got the WARN messages but the subsequent INFO messages seem to indicate that the channels did (finally) update OK. Or??

[andrewfg]

@lsiepel apropos the channel type xml update instructions issue above: I checked my xml syntax again and it seems OK to me. But perhaps you can have an independent look at it again? I am wondering if the issue might have been related to dropping the jar in addons rather than the normal jar loading process. In which case there may be an edge case issue in PH Core??

[lsiepel]

pe updates, I am not sure why you got the WARN messages but the subsequent INFO messages seem to indicate that the channels did (finally) update OK. Or??

Can't test due to not havintg any govee devices. Would be best if you install a fresh openHAB with the shipped binding version and drop the jar after all is setup. For the update process it should not matter if itis shipped or placed in the addon folder.

[lsiepel]

Thanks, LGTM.
The warnings might be due to the development. I don;t see a clear casue in the code or update instructions. Let me know if you have tested enough.

[andrewfg]

I don't see a clear cause in the code or update instructions.

Me neither.

The log says "Channel types or config descriptions .. are missing" -- which is really helpful since it is not clear if the problem is due to the channel types (and if so which of them) or the config descriptions (and if so which of them). And furthermore the log gives no clue if it relates to the attributes provided by the prior binding version, or the respective same attributes provided by the new binding version after the update. As I said: really helpful indeed.

But anyway comparing the before and after thing code in UI it seems that everything was, and is now, all as it should be.

So I don't know if this issue is a bug in the binding (either before or after) or a bug in OH core. The log message comes from the registry, and only appears on the first update run, so I am inclined to think the issue is not in the new binding.

Old

New

[andrewfg]

Many thanks @lsiepel .. as you can see I opened a new issue about the ThingManagerImpl warning..

[stefan-hoehn]

And many thanks to you, Andrew, to refactor and improve the binding 🙇‍♂️