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.
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.
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.
A similar RGBIC strip would be the one without Wifi, but then I guess I have to stick to the govee app only?
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!
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
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
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
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
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.
