Govee integration

Share your Projects! Custom Integrations
83

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 :slight_smile:

You might also look into the ./config/govee_learning.yaml which will contain the learned values.

Link? Here: https://drive.google.com/file/d/1iyjeiZNVzeK1o9fS0OPy_zOy6IwDBFFf/view?usp=sharing

1 Like
84

Nice one, so will that one work with he integration ootb or to I need to do something beside install the integration?

85

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.

86

How do I know if it does support the groove api?

1 Like
87

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.

88

H6159 seems to be working great now, slider is accurate: (I have two)

image
image937×936 85.1 KB

govee_learning.yaml generated as expected:

0D:D7:A4:C1:38:xx:xx:xx:
  set_brightness_max: 100
  get_brightness_max: 100
E0:EF:A4:C1:38:xx:xx:xx:
  set_brightness_max: 100
  get_brightness_max: 100

Fabulous work!!! :slight_smile:

1 Like
89

I guess this one won´t work, because it´s bluetooth only

2 Likes
90

If you need testing / logs for bluetooth only lights I will help. I have two H61381A1 I would like to get working.

91

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.

92

Did you try it with the latest version? Should be fine now.

93

Hi,

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.

94

It works for H6104, but as expected there is no response from the lights so the learning_storage.yaml remains unchanged after using the lights.

95

Also because it is so much work to get the integration into core, I decided to aim a bit higher

for Silver Quality Scale

Why? Because it’s fun :smiley:
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
histoy_state

Offline looks like this:
chrome_jsj8mn2Drp
And log shows this warning:

chrome_doe5qAzhoI
chrome_doe5qAzhoI1393×231 15 KB

And if you watch the detailed log you will also see this information:
chrome_pq4e6RuQ8M

1 Like
96

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.

1 Like
97

This is strange, these are basically the same commands. Debug logs will be needed, thanks.

98

Any chance of getting this turned into a custom repository for HACS?

1 Like
99

I didn’t look into this, what needs to be done? And does this make sence when I want it in core?

100

I’m actually not sure. Maybe this will help https://hacs.xyz/docs/publish/start. I’m going to install it manually and give it a try. Thanks!

1 Like
101

Clarification,
The ‘on’ command does turn it on, however, regardless of what brightness is set to the LEDs are off until I do some other action such as hit video mode in the app or select a color for HA.
I had the app open and I could see that it turned on the Govee LED and said brightness was at 70% but they were not actually on until I did something else. If I turn it on from the app then it functions as it previously did.
I could not find anything in the logs concerning Govee.
I will revert to the previous revision and report result.

2 Likes
102

Actually @LaggAt is working on getting it at a integration into HA proper.

1 Like