Just a question, but when this is incorporated into HA: How do we proceed if we have the custom component installed.
I (up to this point) have never had a custom component that became a full integration. I assume that on the release of the HA version that contains Govee that a notification of some type or something gets logged (just guessing). Do we just delete the custom integration at that time? I assume also that settings (API key) will need to be reentered and not imported. I don’t know if you even know at this time, but I thought I’d ask anyway.
Well, I’m doing this the first time, probably you just need to delete the custom_component/govee folder.
I havn’t analyzed this, I think worst case scenario is you have to add the integration again, and enter the api_key once. ID’s of the lamp’s will stay the same, so your automations should work.
Finally the version with auto-adjusting brightness ranges is here to test.
There are some heavy changes, so keep a backup of your working version.
It simply needs a high-enough brightness value set, and a high-enough brightness status received, then all should work great for any led strip.
Until you hit 101+ on both, sending and receiving, following effects are expected:
after controlling to a low brightness, the slider jums to another position
slider position does not match illumination.
After this procedure there should be no jumping (well - maybe a small because of 254 has a higher resolution than 100) and no wrong led brightness
Here is the catch:
I only own one led strip up to now: Could you report which models are working and which do something strange? If possible (and if there are errors) enable debug logging
You might also look into the ./config/govee_learning.yaml which will contain the learned values.
I cannot test every model, but as long as they supoort the Govee API (which you must request an api key from Govee Home app) you could do basic control. If the device supports it we have on/off, color, color temperature and brightness.
The api docs say:
The device models supported by the current version are H6160, H6163,
H6104, H6109, H6110, H6117, H6159, H7021, H7022, H6086, H6089,
H6182, H6085, H7014, H5081, H6188, H6135, H6137, H6141, H6142,
H6195, H6196, H7005, H6083, H6002, H6003, H6148.
testing/logs isn’t an issue here. Time is. For me it’s currently out-of-scope. I’m not saying I’m not doing it, but not right now (and probably not in the next weeks).
If some developer here wants to jump in I’m ready to discuss and help with some refactoring, to support both variants. I focus on the core pull requests and some small features and fixes for now.
I started a compatibility list in the First Post. So:
If you own a device which is working tell us here in the thread, and I’ll add it.
If you own a device which has some issues or is not working (but should) also tell us, I’ll try to fix it and will add these information too.
Why? Because it’s fun
And most of it was there from the beginning.
Connection/configuration is handled via a component. was always there.
Set an appropriate SCAN_INTERVAL (if a polling integration) configurable in Config Flow since first version, polling has been re-worked to a single point in code.
Raise PlatformNotReady if unable to connect during platform setup (if appropriate) I added this while ago, while fixing a bug not reconnecting if it fails once.
Handles expiration of auth credentials. Refresh if possible or print correct error and fail setup. If based on a config entry, should trigger a new config entry flow to re-authorize. Our API_KEY never expires, so not necessary. And yes, on setup we fail when the API key is wrong since the first version
Handles internet unavailable. Log a warning once when unavailable, log once when reconnected. This is a new feature in the latest version (link below)
Handles device/service unavailable. Log a warning once when unavailable, log once when reconnected. Devices have an ‘online’ property, service unavailable is handled the same way as internet unavailable above
Set available property to False if appropriate (docs) added in latest version
Entities have unique ID (if available) (docs) again something we had in first version
So you see why I decided to go the silver path? Keep your fingers crossed to get the pull request included this time!
To enjoy these latest updates, before the inclusion in core, use this:
new feature not mentioned above is a flag showing if the state is computed, or from api.
you will see the new symbols home assistant provides next to the bulb name
The ‘on’ command is not working. ‘off’ works.
This is for H6104.
I tried with automation and manually.
If I select a specific color it will turn on, but that is not the behavior I want, I want it to mimic TV.
I will see if anything in logs, but thought I would send this off to you.
I tried the version just prior to this and had no issues.