Govee integration

GlennHA · October 12, 2020, 7:08pm

Edited above post with comments.
Automations as follows:

# On with default "0"
type: turn_on
device_id: 9c47418f0c0b11eb80f6af0639fb12d6
entity_id: light.h6104_22dc
domain: light

OFF

# Off
type: turn_off
device_id: 9c47418f0c0b11eb80f6af0639fb12d6
entity_id: light.h6104_22dc
domain: light

ON 100

type: turn_on
device_id: 9c47418f0c0b11eb80f6af0639fb12d6
entity_id: light.h6104_22dc
domain: light
brightness_pct: 100

ON 0

# ON with "0" typed in
type: turn_on
device_id: 9c47418f0c0b11eb80f6af0639fb12d6
entity_id: light.h6104_22dc
domain: light
brightness_pct: 0

The issue may not entirely be with your integration since it is using the light domain, HA may assume that any brightness command with turn on the light so that it only send the brightness. In the H6104’s case a brightness command will NOT turn on the light. So maybe a way around this is the send an “on” command with each brightness change

As you can see above if someone does not look at the YAML it is impossible for them to know when brightness is “0” if they are sending an ‘ON’ or a brightness to “0” command.

At least my issues are helping you build a better integration.

LaggAt · October 12, 2020, 7:39pm

Ah thanks, just saw your comments on the mobile and moved to my laptop for testing - perfect timing

LaggAt · October 12, 2020, 8:56pm

So, I did your tests.
I’ve some details for your that might help you with your automations:

Here I agree with you - showing 0 brightness here, when NO brightness is set, is a bit confusing. Anyhow nothing I could handle in the Govee integration. If you call me with the brightness_pct: 0 as here:

type: turn_on
device_id: 620340a3fc4411ea9b5a796102a41718
entity_id: light.hallway_h6163_7a1c
domain: light
brightness_pct: 0   <-- this line is added entering a 0 once.

home assistant is calling the

async def async_turn_off(self, **kwargs)

Well, I also tried to send brightness 0 to the govee lights, which also turns them off. For the UI showing the same no matter “brightness_pct: 0” is there or not, you may search for or open an issue in the core project here: Issues · home-assistant/core · GitHub
Anyhow: you know it now, if you want to remove the 0 quickly switch to yaml view and remove the line.

I configured all your automations in my test envoronment, and saw no action failing or results, I didn’t expect. Here are my details:

# On command via automation brightness at default "0"
2020-10-12 20:00:54 DEBUG (MainThread) [homeassistant.components.govee.light] async_turn_on for Govee light 40:83:FF:FF:FF:FF:FF:FF, kwargs: {}
2020-10-12 20:01:20 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] control 40:83:FF:FF:FF:FF:FF:FF: {'name': 'turn', 'value': 'on'}
## result: light is turning on with last brightness value
## the integration doesn't get this brightness == 0 information, which seems legit, as allowed range on home assistant is 1-255 and this is not in the automation yaml.

# Off command via automation
2020-10-12 20:09:50 DEBUG (MainThread) [homeassistant.components.govee.light] async_turn_off for Govee light 40:83:FF:FF:FF:FF:FF:FF
2020-10-12 20:09:50 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] control 40:83:FF:FF:FF:FF:FF:FF: {'name': 'turn', 'value': 'off'}
## result: light turned off

# On command via automation brightness set to "100"
2020-10-12 20:14:08 DEBUG (MainThread) [homeassistant.components.govee.light] async_turn_on for Govee light 40:83:FF:FF:FF:FF:FF:FF, kwargs: {'brightness': 255}
2020-10-12 20:14:48 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] control 40:83:FF:FF:FF:FF:FF:FF: {'name': 'brightness', 'value': 100}
## result: light was off, it turned on with full brightness
## result: light was on already, brightness is changed to full

# On commnad via automation, brightness set to "10"
2020-10-12 20:19:36 DEBUG (MainThread) [homeassistant.components.govee.light] async_turn_on for Govee light 40:83:FF:FF:FF:FF:FF:FF, kwargs: {'brightness': 26}
2020-10-12 20:19:45 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] control 40:83:FF:FF:FF:FF:FF:FF: {'name': 'brightness', 'value': 9}
## result: brightness is set to 10% (26 on the 1-255 scale, 9 in the 1-100 scale)
## flooring from 10% to 9/100 is a bit ugly, but works and is close enough. 

# On Command via automation with Brightness set to "0"
2020-10-12 20:23:19 DEBUG (MainThread) [homeassistant.components.govee.light] async_turn_off for Govee light 40:83:FF:FF:FF:FF:FF:FF
2020-10-12 20:23:19 DEBUG (MainThread) [govee_api_laggat.govee_api_laggat] control 40:83:FF:FF:FF:FF:FF:FF: {'name': 'turn', 'value': 'off'}
## result: as described above we're called with off. This is a bit confusing with turn_on, but as stated above nothing the integration handles. As seen in the first debug line our entry point is the "async_turn_off"

Only real difference I see is in the state results, as I get results from the api, and your device probably doesn’t support api results and isn’t even requesting them.

So besides the view issue with the existing or missing 0 line, all is fine here and worked as expected.

GlennHA · October 12, 2020, 9:12pm

I agree it works, it just is not intuitive due to the brightness.
Can you send a Turn On command before all brightness requests?

LaggAt · October 12, 2020, 9:51pm

Well, why do you need that?
Brighness > 0 does power the lights.

LaggAt · October 12, 2020, 9:54pm

oh, do you mean: light doesn’t turn on for you when you e.g. set brightness to 100?

GlennHA · October 12, 2020, 10:20pm

Yes, for me (H6104) a brightness command will not turn on the lights.
I don’t see any issue (other than if someone has too much polling) with sending an “ON” and then a brightness; for most this will have no effect, but for those with lights similar to H6104 it has a huge effect.

GlennHA · October 12, 2020, 10:25pm

LaggAt · October 13, 2020, 5:41am

Well, sending a on command before brightness > 0 (0-254 range of govee) has some downsides:

this would hit the api limit faster (especially if you have more led strips, as we must send two commands instead of one, and
the latency to set brightness is a bit higher.
the lights would flash bright if turned off whti a high brightness before.

But there is an easy and intelligent solution to this:
We already have this govee_learning.yaml, which is autocreated and remembers the ranges to set/get values from api as they differ in some led strips.
I would introduce a third value here:

govee_learning.yaml:

40:83:FF:FF:FF:FF:FF:FF:
  set_brightness_max: 100
  get_brightness_max: 100
  before_set_brightness_turn_on: false

Then - as soon as the library supports this - you could just set this to true and configure the client to send turn_on before the brightness command.

ToDo:

add this to library (Option to send a "turn on" command before any brightness control. · Issue #67 · LaggAt/python-govee-api · GitHub)
check if we still can read/write the govee_learning.yaml as we introduce our first optional parameter
add this to documentation, and to the supported bulbs on first post here

disforw · October 16, 2020, 12:04am

Please add the H6195 to the perfectly working list.

However, I am noticing an issue with displaying in the dashboard. When the light is off, the entity on/off switch shows normal, but when on it changes. See images below.

When OFF:

When ON:

short4bmoney · October 16, 2020, 5:04am

Sort of new to the Govee brand, but my H6190 LED strips aren’t compatible with the mobile app, so I believe the API is off the table.

Does anyone know whether (or recommend) Zigbee or z-wave LED controllers for use with Govee LED strips?

Literoya · October 16, 2020, 7:02am

Was the “on” automation fixed?

I can control turning my govee off but not on within automations.

I can turn the govee off and on fine from the UI but the “on” automation won’t fire.

LaggAt · October 16, 2020, 7:31am

Hi and welcome onboard!
We manage state in locally by tracking what has been set. As long as we do not get a state from API this picture is shown, with the blue “on” and inactive black “off” button. If your led supports getting state, this will be updated from API on next request.
I assume your device doesn’t support getting state, and added it to the first post.

LaggAt · October 16, 2020, 7:35am

Could be this open issue:
Option to send a "turn on" command before any brightness control. · Issue #67 · LaggAt/python-govee-api · GitHub (I’ll work on it next week)
or more likely this one:
Light On command in Automation UI may have different YAML code and show same in UI · Issue #41739 · home-assistant/core · GitHub (home assistant’s glitch with a workaround)

As far as I know on automation do work, if not please provide a description with debug logs.

LaggAt · October 16, 2020, 9:14am

Then I think you’re out of luck here, If the LED has no connectivity I can only think of something like an Arduino/XBee hack or something.

disforw · October 16, 2020, 11:36am

I was looking in to the Shelly RGBW2 if this integration wouldn’t have worked for me. Although they seem to be back ordered everywhere right now.

short4bmoney · October 16, 2020, 3:30pm

Thanks for the input. I’m going to test a Zigbee LED controller and see if I can get them accessible in HA. I’ll update here if I get them working with the controller model.

jesse-schein · October 20, 2020, 2:24pm

Thanks for your hard work on this @LaggAt. I had made my own led controller using ESPhome but sadly it got a bit crispy last night… and caused a big issue at my house.

I just bought the govee based on your integration, I see its still not in the main repo, but I would love to help where I can with this integration.

I recently made my own integration with another product in my house that calls an API so I am familiar with how to develop for home assistant. Let me know if you need any help testing or finalizing the PR.

LaggAt · October 20, 2020, 4:46pm

Hi and welcome onboard, I should take money from them

I think for the PR there isn’t much I could do, it’s in ‘Needs review’ in Dev. So a core developer needs to pick up here.

The feaure/option to send a turn on before a brightness change is developed in the lib, just needs some testing (and tests), I’m just busy setting up some camera gear here for another project.

When the above mentioned is done, I consider it complete for now.

What could be done are unit tests for the integration (config_flow is tested 100%, library is tested well, integration itself needs some work here). Also if someone wants to jump in on some bluetooth control (best in a second library/package, by turning the current lib in a handler for both variants) we could add some value here. What else? Are there other devices than lights from govee to support? Documentation?

What do you think you want to help on? I just wanted to give some ideas here, but you are probably best suited by adding your needs.

Thanks in advance.

short4bmoney · October 21, 2020, 5:33am

Got the HUE Bridge connected to the Zigbee controller after cutting the Govee strip up and learning that the RGB + 12V lines were not color-coded intuitively…

Unfortunately after the power was connected, only green LEDs would reliably appear based on HUE controls. Seemed like cheap wiring on the part of Govee.