Keep in mind the difference between what level and v are.
v = the next potential change to level
level = what you are asking it to be set to.
The logic now says anytime the proposed next value is equal or less then level requested run a check if it requested value is 0 and turn off. Otherwise set the level to the final requested value.
I see what you're saying--if the desired end-level is 0, turn it off if 0 or set it to the desired end value on the last loop (I hadn't studied the calling code enough).
In "fadeDown", it sets "int delay = fadeRep". Shouldn't that be "fadeInt" (fadeRep is the number of repetitions, not the time). I don't even know that "fadeRep" has any value in the code tbh. But, I think the current logic will be running the next setting in a matter of a few milliseconds, rather than the expected duration.
Honestly though i understand you confusion. It works the way it is. The problem/confusion comes from how fadeup and fadedown are called from fade. The way it is called flips them. It probably would be a good idea to clean that up, but it works right now.
Thay said the timing logic hasn't been touched. Did it work for you when you tried it?
Looking at the device now, it says Level = "-660799" (a relic from the mess before). So, I did a 0 duration "set level = 100".
I then tried to change the preference "% Change each Increment of fade=30.0"
But got this:
It did fade down to 10 fine.
I changed the % fade to 20...then tried to fade from 10 to 100.
It never stopped.
Also, the level value in the "Commands" tab of the Device itself was incrementing to the current value--like "850, 870, 890, etc."
I also missed that--yeah, the variables in the "caller" don't align properly with those in the "called" routine. That is rather confusing, as you noted.
I'm totally lost by how it got past 100.
I made a minor change to the text of a couple debug lines (so I could be sure it was executing what I expected). Suddenly, I got these (doing just about anything):
So, I tried doing an HPM Repair. That undid the changes I made.
But, I still get the same error trying to setLevel.
(the ON & OFF commands work, though).
For giggles, I updated the "Govee v2 Color Lights 3 Driver" and added this:
That made the error go away, as that routine was called.
Not sure what happened to the "setLevel" routine--but it seems to have vanished.
So, I updated the "Govee v2 Color Lights 3 Driver" driver to add a "setLevel" routine like this:
def setLevel(BigDecimal setlevel, BigDecimal setduration)
{
log.debug "So many wow, in missing routine: Level: ${setlevel}, Duration: ${setduration}"
int setlevelint = setlevel.intValue()
float setdurationfloat = setduration
fade(setlevelint, setdurationfloat)
}
Interestingly enough, it picked up the debug log text changes I made--AND it incremented properly, stopping when it hit/exceeded 100 (10, 30, 50, 70, 90, final loop 100).
FYI: Nothing stops anyone from setting the target Level to > 100 or < 0. I used the device command page to set the level to 101--and it tried. It tried to increment the level from 100 to 120 then determined that was too high (aka, "Final Loop" test) & issued commands to set the level to 101. Likewise, I was able to command a level of "-5" and it tried.
Your occurrence with the above code getting what is shown in the image below concerns me.
I am not having the same experience as you are. I have tested it a few times. One thing to note though is that you will see one value beyond your desired value with the log message from fadeUp(), or fade down() as shown below
fadeUp(): v 105
But in the debug log you can see the command actually submitted your final value. I can probably move some of the logging around to remove that confusion actually. I will look into that.
I've got a mesh, with my RM apps on the hub. There are no drivers, libraries, or apps related to your Govee code on that hub.
I was doing all this testing on the hub running your app directly.
I was also wondering what was running and where, which is why I tried changing a few messages, to be sure I was looking at the executing code.
Any thoughts on how I can be sure I've got all the right pieces?
Given the mess when it's updated (leaving things pointing to the old versions), I suspect HPM may not be managing things totally correctly.
I went back and looked for through change logs for the drivers to see when the driver had the correct code to trigger that error with the "lightEffect_RGBIC_Strip" in it. I had to go all the way back to the beginning and it was posted on March 22 of 2024 and was removed from that spot on March 31. At the very least you are somehow running code from before that time.
At that time that code was part of the driver itself and not a library file. Please go into HPM and click on the option to "View Apps and Drivers". In the list that appears make sure you see the driver you are using and that it is 2.1.4. If it doesn't appear there you may need to unmatch the integration and then match it up again.
Also please go into the driver (Not the Library) and let me know what it shows on line 203.
Currently, I added a "setLevel" routine of 10 lines above line 203 in the driver, so this is what I have:
I did an "unmatch", a "match", then a repair.
Now, I get:
Note--it appears the following things are old/out of date/not updated (I just whacked them):
These Drivers:
This library file:
Thoughts?
Thanks--sorry for the hassle.
So, it does seem to be better behaved now (not sure how things got so messed up, but HPM clearly didn't get things properly updated).
However, a couple things:
The <0 and >100 values for "set Level" aren't enforced:
Not sure what's causing this:
I have something i need to test before i add code to prevent numbers above 100 and below 0. I use the standard device capability "switchLevel" and i suspect that should have prevented the situation you are concerned with being out of range.
Generally the error you called out is something bad being passed to the Cloud API. Either bad parms or malformed request. The call it was making at that time is very simple getdevicestate request. The only parms it passes is the deviceID and the API Token. Look at the device details and make sure those are valid. If not you may want to recreate the device to fix that.
It looks like the API key didn't get into the child.
Is there an easy way to stuff that in there? Could there be? That would certainly be easier than the hour(s) of changing every reference in every scene, etc. again.
EDIT: Turns out, changing the API key to something else--then back--updates the child device. Woot (seems to have solved that issue!)
Yea. The API Token is checked everytime you click on done in the app. If it changed it is pushed down to the devices that are integrated.
Glad to hear that has fixed that issue. I will let you know what i find after i revert one of my hubs and perform the test i have in mind for the last concern.
A new version has just been released.
This new version brings two things along with it.
If you try the new Scene Extraction process and it doesn't work for your devices please capture a few scenes using the tap to run method and forward them to me in a DM. I can then analyze the differences and hopefully add improvements to the process to properly capture them. Generally speaking there have only been a few tweaks that need to be identified and it works. I just don't have all devices to test and validate with.
Thank you @rob9 for all help with the LAN API Fade issue.
Woot! Thanks so much for all your work and patience!!!
I like a good challenge. That was a tough one to figure out what was going on. I am just glad we finally figured it out. It is also good to see that something like that can actually happen even after a repair from the standpoint of adding it is a possibility and a solution for it.
I replaced 1 with v2, and just installed 6 H601C down lights.
I can't figure out groups, scenes, tap to run. The verbage seems nebulous across your driver's and their app.
I have a group with all 6 lights, I can tap on/off on it in the govee app, how can I replicate that n hubitat? Morning important even when I add a tap to run thing.
Right now with the light apps on hubitat, even with a group, they turn on one after the other.
I don't disagree, and they are different between the platforms.
In Govee speak a Group are linked devices controlled at the same time from their cloud. A Scene is a light effect that involves animated lights, A tap to run is a kind of automation to trigger a action on a group of similar devices. Generally all of these are items that are on the Govee at Home screen.
In Hubitat a Group or Scene is a set of devices under the same control with the same settings. Generally this is used to set several devices to the same color, brightness, ect to create a consistant ambient light environment in a area. Hubitat doesn't have a tap to run, but you can create rules and virtual devices to create the same effect.
Generally speaking in Hubitat a Govee scene relates to a lightEffect though i do often refer to them as Govee Scenes.
Unfortunately, Govee doesn't make configured Groups available through their Cloud API so Hubitat has to talk to each device individually. Most of the time to improve this I would suggest moving to LAN API or local control, but i don't think those devices support it.
Unfortunately this is kind of the nature of the devices being separate, but associated in software. Even if you were using LAN API the Hub would talk to each device individually and there are a ton of factors that can cause them to activate at slightly different times. Lan API tends to make it better, but not perfect
That said there was one thing I figured out a while ago that has potential to improve this and provide a possible way to enable Govee Groups. I never perused it because there was so much other stuff that was needed first before addressing Govee Groups. No promises but I will try to revisit that and we can see if it makes a difference.
*** Update *** What I was thinking with my last above statement is not going to work. I should also point out that most likely you are controlling your devices with Bluetooth when using the Govee app and not their cloud api. That is generally how their group functions work. Sorry i don't have a better answer.
Download the Hubitat app
