Yep that is exactly it. I wish the drivers were more dynamic when it came to commands and attributes, but they just aren't.
If i tried to go down the rabbit hole with this big change i am kicking around in my head, i have a feeling a bunch of new drivers would be needed. There would also be a bunch of new devices potentially being supported that are not now, but i am not sure i want to go down that path.
Thanks for this great integration. I had successfully extracted some DIY scenes, and things were working well. But realized I forgot two scenes. I added those two scenes, tried to extract them, but they wouldn't work. I cleared the DIY scenes and tried to re-extract everything but still no luck. Looks like I'm getting an error. Any idea?
@JustinL
It appears that the parser method is not finding a scene name or command in one of the Tap-To-Runs you are trying to import.
Can you adjust logging to "trace" and recreate these errors. That will give me a little bit more detail as to what the parser is trying to deal with.
It is faling on your Tap to run trying to added DIY BRBB. It looks like you also included a step to change the brightness to 8%.
If you remove the brigtness change i bet it would work. I will think of a way to prevent this from being a concern going forward.
Money. That did it. Thank you!
The next set of code should keep this issue from occurring.
One thing I just found out is it is possible for us to also use the sleep function from the tap to runs. I may be adding something to allow that to function. This would allow the fading off of devices from a given %brightness. Does anyone see any use for that?
OK everyone i just release 1.0.33 of the integration. This upgrade has 2 things.
Per @JustinL's situation I have updated the code to remove some assumptions and now look at each rule that is part of the Tap-To-Run setup in the Govee Home App. Once it finds one that is either a Scene Effect, DIY Effect, Or Sleep rule it will process the extraction. This should prevent situations were things get out of sync in the rules, or you have more then just the scene on the rule as was the case with @JustinL
Along with that as mentioned above it was found that we can setup Sleep rules for Govee and I have added the ability to recognize that to the extraction process. Now you can setup a sleep rule on a device and extract the commands for that action into the app. The advantage of this is that it removes the fade up /fade down methods in the driver from that action which should be less load on the hub. I didn't try to preload sleep functions because there are to many variables.
@mavrrick58 Hello. Love the driver and appreciate the hardwork. I like govees variety of products. Have only recently tried changing colors on a few devices; usually use there app for this but have been moving devices over to hubitat for use. Anyway im getting this error when changing colors, and the colors dont change and also noticed a slew of what may be polling issues? Any help would be much appreciated. thanks
dev:2242023-07-06 04:48:11.574 PMerrororg.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'null' with class 'null' to class 'float'. Try 'java.lang.Float' instead on line 165 (method setColor)
dev:3072023-07-06 04:48:41.040 PMerrorjava.lang.NullPointerException: Cannot get property 'H7062' on null object on line 895 (method poll)
dev:2912023-07-06 04:48:40.878 PMerrorjava.lang.NullPointerException: Cannot get property 'H6062' on null object on line 895 (method poll)
dev:2222023-07-06 04:48:40.870 PMerrorjava.lang.NullPointerException: Cannot get property 'H6172' on null object on line 895 (method poll)
dev:2902023-07-06 04:48:40.857 PMerrorjava.lang.NullPointerException: Cannot get property 'H7060' on null object on line 895 (method poll)
Okay void that first error. I updated drivers and it went away and color changes work in hubitat. I use sharptools on my phone and it reflects color changes in hubitat, but wont change colors when i send the command there?
What error message do you see in the Hubitat logs when you control the device from SharpTools.io?
Edit: from a quick look at the code from my mobile, it looks like the setColor command for the driver is requiring the level which isn't sent from the dashboard color picker control if you're only adjusting the color. The code could be updated to use the existing device level if it's not included with the setColor command.
There are a few things going on with that section of code.
This is because when converting to RGB if the brightness is also set to the same value as Level ( in reguards Brightness) and the L value is low the settings compound. Think of it like 5% brightness of 5% is basically not on.
If i using the color picker you need to specify all the values for whatever method you are using.
Thanks for the reply! What I'm suggesting is that a normal Color Wheel does not include the value (level) property and only adjusts the hue and saturation. So the setColor(COLOR_MAP) command should be capable of accepting a COLOR_MAP without the level parameter in it.
The Color Control capability definition in the docs supports this, noting the level attribute as optional. In that case, it should just fallback to using the existing device level value which is a common approach in many color drivers.
def setColor(value) {
unschedule(fadeUp)
unschedule(fadeDown)
if (debugLog) { log.debug "setColor(): HSBColor = "+ value }
if (value instanceof Map) {
def h = value.containsKey("hue") ? value.hue : null
def s = value.containsKey("saturation") ? value.saturation : null
- def b = value.containsKey("level") ? value.level : null
+ def b = value.containsKey("level") ? value.level : device.currentValue("level")
setHsb(h, s, b)
} else {
if (debugLog) {log.debug "setColor(): Invalid argument for setColor: ${value}"}
}
}
Notice that the only change here is the setColor() command falls back to using the device.currentValue("level") if the level key was not included rather than using null. This is similar to the approach you use in setSaturation, setHue, etc.
Otherwise null is passed forward and will fail in the setHsb() command when it attempts to do the conversion to RGB.
I realized that most of this was probably side-discussion compared to the main issue of setColor() command needing to make the level attribute optional rather than required. I've left it here for posterity sake.
--
Just want to make sure we're on the same page as I can't tell if it's just a matter or wording/typos or something more.
level, it's actually a lightness value where 50% (0.5) is equivalent to full saturation (closer to 0 is closer to black, closer to 1 is closer to white)level being set to 100 with the color picker
level (value) when appropriateThe 'value' (level) from the HSV model is important when converting to RGB. Take the following example:
| H, S, V | R, G, B | Sample | Note |
|---|---|---|---|
| 0, 100, 100 | 255, 0, 0 |  |
Red, full saturation and intensity |
| 0, 100, 50 | 128, 0, 0 |  |
Red, full saturation, half intensity |
Notice that when we cut the value (level) in half, the intensity of the red in the RGB model is also cut in half. As you alluded to, this moves us toward a dimmer version of the 'same' color.
I will test this out to make sure it doesn't break any of the other stuff.
Ok so a few things have been found.
The Level needs to be set to 100% if the set color option is used so that if a user submits a color value like Hue:40, Saturation: 85, Brighthnes:5 from the UI It actually shows a very dim color. If the brightness was set 20 and then that same set of values was submitted it is likely it would look as though the device is off.
The problem is we want to treat the B part of HSB the same as Level and that really isn't possible when converting to RGB. I spent a good amount of time pulling hair out about this previously
I will leave this code in though as I don't see it causing problems per se. But it doesn't fix the problem of the conversion just jacks brightness/level up.
@murv82
I looked at the logs you have above and there are two things i think happening. The first issue is that it looks like for some reason I had the driver trying to refresh scenes with each refresh. That isn't a good thing so I removed the code that triggers that. It will only be done on driver initialization going forward.
Then i think your are getting a error when the driver is reaching out to the parent to retrieve it's scenes. Please go into the Govee Integration app, Scroll down to where the button for "Scene Management" and click on it. Once that is done click on the button labeled "Click her to reload preloaded scene information" and then lastly click on the button labeled "Click Here to update all devices awareness of scenes"
Those steps will basically get the Govee Integration app to reload the scenes if any new ones were added since it was installed, and then then the last button submits a initialization to every Govee device integrated to so they will retrieve the scenes from the main integration app
The update for suggested by @josh and the cleaning up of the scene retrieval from refresh will be included in the next release though it is not exactly needed. You can get them now by doing a repair through HPM
That error should only happen if they DIY is no longer loaded in the Govee Integration app. Did you clear the DIY Effects recently? If you did do you still show the DIY on the device? If you do will it still be there after you do a initialize.
Also the error on line 880 is old code at this point. Please update to latest release. I will see about adding some code in that will prevent it from completely breaking if you cleared the DIY's.
Ohh. That does make sense. Cause I didn't clear the diy scene. How do I select a scene from the list of scenes that where preloaded to the strip? Also, I'm on automatic updates, it's the latest version.
EDIT: Nvm, it appears my set scene button was MIA. Just reloaded the preloaded scenes and now I'm seeing the option to set scene. Ty!
Look underthe state variables for the device. It show a variable called scenes with a list next to it of all the preloaded scenes. That list will show a number along with the scene name from the Govee Home app. take the number next to the scene and put that in the setEffect button and click on it.
You were submitting to activate a DIY which would be done with the Activate DIY button.
@mavrrick58 is there anyway to add a button to randomly select a preloaded scene? Would I have to set local variables for each scene within a BC/RM rule?
Download the Hubitat app
