Govee integration

Share your Projects! Custom Integrations
61

Quick video showing the behavior:

1 Like
62

Thanks @GlennHA eventually it showed up and it works perfectly! Thanks for your work building this integration!

1 Like
63

for the H6104:
We know that this model will not return status so:
ON and Off work (actual actions)
Brightness works now and is accurate and timely.
Color selection works.
Temperature control still does not appear to have any effect (there is no temperature control in the Android app for Govee, so probably not an issue.

I contacted Govee API team requesting that the API response for devices give that available commands as it does for other models but not currently for H6104. I also asked if we can get remote mode selection (currently only via Bluetooth connection and not via wifi on app so probably not possible, but who knows). I got a response:

Iā€™m sorry to tell you that the H6104 could not return available commands from the API becuase it has old protocal version.

This answers half the question.

1 Like
64

I can not take credit for any of this.
LaggAT is the one you should be thanking.

1 Like
65

Most of my scripts are all in python 2.7; I just donā€™t like the formatting changes in 3.7 (in my opinion they are less reader friendly) and havenā€™t even looked at 3.8.

I will ā€˜maybeā€™ move to 3.7 when PIP no longer lets me pull down 2.7 dependencies.

1 Like
66

I thought a bit about the brightness issue @Scope666 thankfully sent a video and debug logs so that I can understand it better, tracked here:

I think about a solution which basically should work for all LED strips, and requires no special configuration. Maybe you guys could comment your thougts on it.

Home assistant is always controlling brightness in a range of 1-255. We always need -1.

Theoretically we may have some variants of LED with different properties:

Control:
a) 0-100
b) 0-254
Feedback:
a) no feedback (manage state locally)
b) 0-100
c) 0-254

I think of a small state machine procedure per LED strip:

Not too complicated, and we do not have to know different model variants in code. Usually you just have to use brightness once at max, and all should be set.

Caveats:

  • where to persist such config details when restarting home assistant?
  • too low brightness on control 0-100 strips on LEARNING_CONTROL
  • some delay on first use

If you think thru it - is there a LED strip not supporting that procedure?

edid: did a rewrite as chart and changed some orders

1 Like
67

This approach seems very logical to me. As to where to store the data, can it be a part of the integration itself, like how your storing the API key now? That seems to survive reboots just fine. Maybe it can even be configurable once weā€™ve done the ā€œLearningā€ and know which range our strip(s) support.

1 Like
68

api key is stored in the config flow, which happens on init. I need to read some docs.

1 Like
69

save_yaml(), load_yaml() sounds good :slight_smile:
http://dev-docs.home-assistant.io/en/master/api/util.html

1 Like
70

Hi firstly I wanted to say thank you for integrating this into home assistant. Really awesome work guys. Secondly I wanted to add that the H6117 strips also do the 40% thing in home assistant when adjusting brightness to 100%. The app shows brightness at 100% though.

3 Likes
71

Good morning and thank you for testing.
Iā€™m currently working on the inclusion as core component. As soon as this is done I will start a new feature branch and implement this learning algorithm which should fix these issues.

I will need testers then :wink:

1 Like
72

One general question about the integration: The strips I have (H6163) will be controlled with a mixture of Wifi and Bluetooth connection, Wifi for the basic features like on/off and Bluetooth for example changing modes from fixed color to music .
Will it ever be possible to control these from your integration?

IĀ“m asking because because one of my beloved H6163 strips is somehow malfunctioning. The Govee support was so kind to send me an replacement, but canceled it one day later, as they told me the H6163 wonĀ“t be available here in Germany anymore. :frowning:
A similar RGBIC strip would be the one without Wifi, but then I guess I have to stick to the govee app only?

Thanks,
Philipp

1 Like
73

For now I stick with ā€œwhat the API providesā€, which is just basic functionality. So I assume the LED strip needs WIFI and needs connect to this API service Govee provides. I already had and like the idea of controlling them locally, e.g. using a Bluetooth-Adapter, if someone wants to do this we need abstract the library and support different connection variants. This might be done by me or someone else, but not in the near future.

So to give a clear statement: Currently out of scope for me, contributors welcome!

edit:
if someone wants to dig into this:

1 Like
74

Installed HACS, via https://www.youtube.com/watch?v=aJTTCAvzpIU
Used Samba to copy this integration into my config/custom_components folder.

Cleared my browser in Chrome - It wasnā€™t showing the Integration in Home Assistant.
Logged into Home Assistant via Safari - as the cache was ā€œcleanā€ it showed this as an Integration in the UI (Configuration > Integrations)

The API key from Govee needs to go in the first box, then I pressed finish, and it recognised my lights :smile:

Thankyou for making the API :smiley:

1 Like
75

I didnā€™t make the api, I wrote a library using the api and an integration. But thanks.
Did anything work well?

76

I thought about it again. I dump the idea from above. Itā€™s really simple.

First: the pull request to core is in a state where I hope it will be merged.
This was a lot of work to get all that linters to say yes, now it needs someone to remove the docs-missing label and review the work. That said, we also have a PR for documentation, and another PR for icons and logos, all links here:

These are all open and waiting - so if someone here can review in these repos: give it a go - thank you.

Back to the issue above:
As I do not want to touch the PR above i started a new feature branch on both code projects. Iā€™ll implement it as follows:

  • When controlling a light, I assume the light can be controlled between 0 - 254.
    When I control > 100 AND get this error 400 (Input parameter wrong) Iā€™ll learn 0 - 100 is control range (and will control the light again).
  • For Feedback I assume 0 - 100 as default.
    As soon as I see the first Brightness reported above 100 Iā€™ll learn the feedback range is 0 - 254.
  • Also, these learned values cann be saved/restored in the library, and the integration will save/store these (most likely as govee_learned.yml)

(when I say ā€œIā€ i mean my library)
This process is much simpler and less error-prone, needs no locking, and the user shouldnā€™t recognize it is learning (maybe the first time light is too bright until you get that error 400)

Iā€™ve implemented parts of this, and hope I could do some more coding on weekend. So stay tuned for the next ZIP to test :smiley:

1 Like
77

Iā€™m getting an ā€œunknown Errorā€ when I try to register the api key for version govee-20200923-pr. Everything is up to date for my HA installation on a PI 4

Any ideas?

thanks

2 Likes
78

Could you provide debug logs as described here: Govee integration - #28 by LaggAt
Could be anything from connection issues to a bug.

79

Once I added a device to the govee home app the error went away - so it appears that at least one device must be configured in govee to complete the HA integration activity.
thanks

1 Like
80

Thank you, Iā€™ll check that.