Simply put
Hubitat defines color with HSL or Hue,Saturation,Level
Govee defines color with RGB or Red,Green,Blue
Notice the total lack of Brightness/Level with RGB. What happens is when a conversion is made between HSL and RGB the l level value is calculated as part of the RGB value. That means the color is already darkened to that %. So if the Level value on HE was also set to the % value of specified in the color picker it would be lets say 10% of 10%, or really really dim. I had users initially experiencing problems were they thought the device was off when this was happening. At the time my solution was to let the conversion occur as it was but then just set the level in HE to 100%.
There has been more thought put into this. Mainly the idea being to ignore the level value provided by color picker initially for the conversion and then set the level after the color is processed with the one provided. This has it's own issues though. Largely it prevents very dim color options. For some reason setting 5% the current way is much dimmer then 5% with the Level value only.
The Govee Cloud or Lan API's don't allow color and level to be set at the same time. So the current method is the only way to achieve that in one command. Ironically though it is never one command as the level is always set to 100%
Unfortunately, the conversion kind of messes stuff up. Ironically "Matter" uses HSL so if you use that this is a non issue :). I believe both of those devices support Matter so you could go that route and use my driver to continue to enable scene activation. Matter has it's own quirks though.
There are a tons of Govee RGBIC strips that will work with Hubitat. Which one you want will depend on your needs.
The best way to confirm is look at the packaging. They will tell you if they support wifi, alexa, google home, Matter, ect. As long as they support wifi there is a very strong chance they will be supported by this integration.
I noticed the difference in level settings as well, and it confused me. I thought it was a "me" thing Thanks for the explanation. At least I know I'm not going insane ... at least not for this reason.
Looks like I"m going to have to take a little bit of a walk of shame...
I had started seeing the same errors again yesterday, and after doing some calculations based on the number of calls I was making it seemed there was no way I was anywhere near 10,000 calls in 24hours.
Earlier today I decided to re-check everything involved, and found an error I had made in one of my scene files used in my rule...where there should have been a "-" (expected delimiter) there was a "=" (unexpected confuser). So the rule was getting thrown off w/bad data-in.
I restored the expected "-" in the scene file and uploaded it to my hub, and things are running for a couple hours tonight w/out errors.
Hi - First, thanks for this great app - just sent you a contribution. I got one of the Strip lights 2 Pro and it immediately worked in your app. Sorry about not realizing the first model was Bluetooth only. If you didn't already you might want to highlight in your documentation that some of their devices don't support wifi. (If you already have that, apologies for not reading the instructions carefully. ). And by the way, THANK YOU not only for this app - but for the very well-written documentation, which so many developers don't bother with.
One question on the LAN API. If one has already set up the cloud API, does using the LAN API for supported functions provide any benefit, such as faster response? Obviously it allows you to not depend on the Govee cloud, which I prefer in principle but if I'm going to use the cloud for advanced functions, just wondering if it's still useful to set up the LAN connection. (I do like that they've made it available, should they ever start charging for the cloud).
Sidenote: I was impressed that the Govee android app still works if I connect the lights to my IOT VLAN. So many other devices - like Roku - won't talk to the App if you don't put it on the same subnet as your phone.
No Worries, it happens. There is a section in the documentation that talks about supported devices.
The thing is the integration had gotten so complicated it was really needed.
It really is about limiting the use of the cloud API and hitting the Rate Limit. There may be some performance benifit as well. One thing to consider is if you have good wifi and are able to use MATTER then the Matter driver may be a better choice than the LAN API. Here is the table from the documentation that talks about the differences
The app falls back to a variety of communication. It can use Bluetooth, Local Lan or Cloud. most likely if you are on a separate subnet you are using Cloud, or Bluetooth to control it.
Thanks for this. Yes - I need to read up on Matter. Don't feel like I get what it's about yet. As far as the subnet thing in general, I have firewall rules to allow devices on my primary LAN to talk to my IOT VLAN and I've enabled every kind of broadcast capability I can find that these devices rely on, but I find a lot of IOT devices still won't work this way - ROKU and LG being two examples. But that makes sense that the Govee app may be just going via Cloud or BT.
I have this set up and working well. I can set effects from the device driver using the effect number. However I'm trying to do the same from an automation.
I tried using RM to set an effect using a custom action - I was able to find the command to set an effect number - but it doesn't seem to do anything when I run the rule.
Can you remove the , and let me know if that does it.
As far as snapshots go, that is likely because of how snapshots are retreived. Please go into the integration app and open the "Standard Device Setup" menu. That should retrieve the latest device info from the Govee Cloud and that contains Snapshot data. Once that is done go back to the device and have it reload it's scenes. They should appear.
This might help you... Link below to a drop-dead simple Govee Effect Player app that @thebearmay recently (and kindly) created for Govee device users.
Easy-peasey as they say. Allows you to cycle through a set of scenes, triggered by a switch or scheduled time.
If you just want to set a single scene that likely is best done w/a rule. An example of a simple rule setting an effect, triggered by a switch turning on:
The field is entering the comma automatically. I just entered 1-2-3-4-5-6 (no comma) and this is what is in the field. I noticed that the other day but kept forgetting to post about it.
This example uses a string rather than a number for the parameter. I just tried that and it works.
So even though it's a number in the Device details effects field, in RM, you need to enter it as a string.
I resolved the first issue by using a string in RM rather than a number. However going into Standard Device Setup didn't retrieve any snapshots. I tried hitting Load Scenes in the device, as well as Initialize and Refresh - and refreshing the page. None of that pulled in any Snapshots.
Thanks for the explanation. At least I know I'm not going insane ... at least not for this reason.
