Govee / Dreamcoulour LED Strips

IĀ“m already on 4.1.0M1 and I get my Govee-Stuff mid next week so Iā€™m VERY keen to get the .jar to test :wink:

Me too. Iā€™ll have to update to M1. I use a simple scripted put request to execute on-off on my govee devicesā€¦

curl --location --request PUT ā€˜https://developer-api.govee.com/v1/devices/controlā€™ --header ā€˜Govee-API-Key: ā€™ --header ā€˜Content-Type: application/jsonā€™ --data-raw ā€˜{ā€œdeviceā€: ā€œā€,ā€œmodelā€: ā€œā€,ā€œcmdā€: {ā€œnameā€: ā€œturnā€, ā€œvalueā€: ā€œonā€}}ā€™

But itā€™s still reliant on cloud. Would love to use the binding to control these directly via api.

You both have a private message.

Have fun
Stefan

Hi, many thanks for the download.
I copied the jar into the add-on-folder, but nothing happened, so I used the karaf console to look whatā€™s going on and found the bundle installed but not ā€œactiveā€. I then tried to start the bundle, but get an error

What did I have missed?

I saw that @wborn has bumped up Karaf to 4.4.4 at the 30/09/23 and with that he also bumped up slf4j.version to 2.0.6 which makes, I guess, all bindings compiled for 4.1 incompatible to be deployed with 4.0. @wborn, is that something we take into account for 4.1?


Does it mean that Andreas must be on the latest snapshot to try out the plugin and that even 4.1 M1 doesnā€™t work? (I guess so)

Andreas, would you mind updating to the latest snapshot (warning: snapshots are by definition unstable and even I probably wouldnā€™t do that myself for my openHAB production system) ?

I have a spare-PI, which I use for testing from time-to time, but currently it has to be setup completely new. This may take a while. But anyhow, yes I will test it, IF there is a chance to get it running then.
Especially as I got the Govee-lights delivered earlier than expected :wink:

1 Like

To be honest, even I have not updated my prod system to the snapshot, even though production is what I developed the Govee binding for. This is why I am so eager to get it out as soon as possible and do all the reviews ASAP when I get them from @laursen :pray:

Do not really understand: If it runs on your production-system (which should be openHAB 4.1.0.M1), why is it then not working on my equal system??

ā†’ for clarification: I run it on a pi, but not native OpenHabian. IĀ“ve installed Raspian native and installed the openhabian-packages afterwards. I know, not the ā€œusual wayā€, but I run some other stuff on the same pi, which do not run well on pure openhabian.

Anyhow; I do not promise, but I try to make an image-klon of my production-system today afternoon, test it on this one, do an switch to the actual snapshot afterwards.

ā†’ Another info, pretty sure not relevant: The Homebridge on the productive PI is able to work with the Govee-Stuff. So IĀ“m sure, the surroundings are ok.

There was a change that Wouter did after the build of M1 which is only on the snapshot version from the 30/09/23 which my binding is built on. However, I am just sending you a ā€œspecialā€ version that I backported which should run even on 4.0 (unlikely that we will be able to officially backport the binding for 4.0 but Iā€™ll ask the maintainers).

I guess, all bindings compiled for 4.1 incompatible to be deployed with 4.0. @wborn, is that something we take into account for 4.1?

Thinking about it myself it is actually wrong. The way it works is that bindings that are installed with an openHAB version ARE compatible with the version the come along. The only situation that is not compatible is if you take a compiled jar that was compiled e.g. in my case against the latest snapshot and you install it manually isnā€™t necessarily compatible with an older installation of openHAB.

Yes the openHAB dependencies are starting to require SLF4J 2.x nowadays like Xtext. Without upgrading Xtext we can also not upgrade Gson to a version that can use records. See: Upgrade Gson to 2.10 Ā· Issue #3321 Ā· openhab/openhab-core Ā· GitHub

Which I highly appreciated because I used records intuitively for the binding and had to include gson 2.1 to make it work until Jacob told me that it was now available via core :star_struck:

1 Like

Just a few cents from me:

  • 4.0 compatibility: It would probably be safest to check out branch 4.0.x and build the binding relative to that. In this case the Gson 2.10.1 dependency must be declared.
  • 4.1 compatibility: There will be a new milestone release later today. Your current builds should be compatible with M2 when ready.

Thanks, Jacob.

Ok, then my bad I didnā€™'t start earlier with the addon to have it released with M1. Sorry, guys, youā€™ll need to wait for M2 then.

Iā€™ve finally updated to 4.1.0.M2 and Iā€™d like to give this a test on my H6163 devices. Stefan Iā€™ve tried both the jar link above and the one you imā€™d. Link above errors out and the link imā€™d is expired unfortunately.

Would you mind posting/resending the jar link?

Thx

Hi Stefan, I would also like to try the Govee Binding. Could you also provide me with the jar file or a link to it? Thank you in advance!

1 Like

Hello!
IĀ“m also interested in trying the Govee Wifi Binding. Can I get the URL to download the jar file please?
Many thanks in advance, Mario

hi would love to try give Binding can I have the url thanks

Are you on 4.1 already? The binding is only compatible with 4.1. Which device are you using? Please provide the Artikel Number starting with Hā€¦? Does ist support LAN-API in the Wifi-Settings?

Iā€™m on openhab 4.0.4 and using h6054 dreamview

There are about 50 Govee devices that supported the Govee LAN-API but it seems this one isnā€™t - all other devices can only be controlled via the internet which I havenā€™t implemented (yet :thinking:)

Check if you have the following setting available in the app: