@mavrrick58 - So I did a thing!!! lol.. I don't know if you remember, but driver for the H7126 Purifier, was giving me some hinky issues because the "auto" isn't really the same as on the other air purifiers, so I my H7126 hasn't been switching to the custom settings I setup on the purifier itself. Keep in mind I am probably the only werido that has a custom fan "profile" within the govee app that i wanted to trigger from HE but couldn't. Well.. I went digging into your driver code (I hope you don't mind), and I figured out a way to make it work, and so far it appears that I haven't inadvertently broken anything else LOL.. Anyways, I wanted to provide you the code that I'm using so you can 1, proof it for royal f-up's I may have caused, and 2 in hopes if you bless it, you can add it to your repo and have it updated via HPM. Anyways, here it is, feel free to give me flack for messing with your glorious code and/or for messing up something hahah...
Customized H712 Driver Code
I added the following after line 44:
command "customMode"
I added the following after line 154:
def customMode() {
log.debug "custom(): Processing Working Mode command 'custom' "
sendEvent(name: "cloudAPI", value: "Pending")
values = '{"workMode":2,"modeValue":0}' // This is the string that will need to be modified based on the potential values
sendCommand("workMode", values, "devices.capabilities.work_mode")
}
If you want me to send you the whole code, just let me know.. I didn't want to paste the whole thing in this message, I am already long winded as it is hahah..
I had my lightstrip apparently using the old app and perhaps the newer driver.
I fixed all that & got everything going with the new app and driver.
Now, I can't leave the device enabled because it's in some loop sending commands to the lightstrip--it's flashing them bright and normal (probably repeating the commands I sent one time).
When I disabled the device, it continued sending commands for a long time--i rebooted the hub to clear that, which worked
As soon as I enabled the service and sent one command, it flooded the device with commands again
What command did you submit right before that started.
Logs indicate you submitted a change in brightness and included a time value to make it fade is that correct? If it is possible can you find the command that was submitted.
Hello, I am trying to set this up for my parents (I currently have a working setup for my personal house so I have a basic understanding of how this is supposed to work) but I cannot get it to show any devices to add even after hitting the device refresh button. It's almost like theres nothing linked between their account and the API key they were given. Is there anything you can suggest I check?
What are the model numbers you are trying to setup?
I have heard occasions on very new setups/accounts/api keys it takes a day or so to finish setup. Maybe give it a day or two and if that doesn't work requeat the API Key again.
I actually just did that process. Waited a couple days and it never showed up. Just requested a new API key earlier today. The light is an H7075 which I have working at my house already. I will give it another couple days and see how it goes.
That log output shows errors in two situations. One of them is when the drivers calls the Cloud API to poll for the device status. That hasn't changed in a while and if I remember right there isn't much to that call. Is your Govee API-Key valid and entered? Also how many Govee Devices do you have and are they all generating this error? The error of "Bad Request" generally means there was something wrong with the call, but in this case I would tend to look at it being a API Rate limit issue.
I know you have the device setup to use LAN API which it will for anything it can, but Polling unfortunately can only be done through the Cloud.
What driver is used on this device so i can check the other error. Without being able to look at the exact driver and code line related i would tend to think it is related to the Lan Scenes File. How did you migrate this device to the new integration? Did you just change the driver, or did you create the new device in the new app and then update your apps/rules to use the new device instead of the old one. Something isn't quite right as the error is trying to use a value of "lightEffect_RGBIC_Strip" which hasn't been used for some time. Are you sure you are running the latest version of the integration?
I somehow had both Govee versions installed (I almost certainly updated via HPM).
But, the App in use was the old one. So, I copied the API key over to the new one, deleted the old one, ran the new one to find/add the lightstrip. I added the new parent/child to the mesh.
Then (on my other hub) I went through and pointed to the new child device in all my rules.
The HPM Update found nothing. I ran the HPM Repair--and still have the same version of that driver.
I re-applied for an API key and put that into the app.
For some reason, I only have 1 device (in the drop down list & only 1 child), but the app says I have 2 (on the main page).
On that one device I have, the polling rate under preferences is set to 300 (seconds).
Really thinking about putting on my Govee on the LAN as in the cloud it’s slow . Sometimes I walk in a room and all my local lights turn on immediately but then the Govee lights take 2 to 4 seconds. I know I read some cons for the lan just don’t remember
The con for using LAN API is that it simply doesn't work for everything. Lan API officially works for on/off, brightness, color, and ct. It also doesn't get current state from the device. We have a way to support Govee scenes over LAN API but it isn't officially supported,
The way the regular drivers are written when you turn on LAN API it will use LAN API for what it can and then fall back to cloud for functions that don't have a LAN API option. That is why even though @rob9 was setup for lan API control on his device it was still calling the Cloud API for device status.
At this point if your device supports Matter and you are ok with it i actually suggest that route instead of going straight Lan API.
Another thing to note is If your wifi network isn't great LAN API may end up with lost commands and devices not changing state when you ask. The LAN API uses UDP protocal which is a fire and forget protocal unlike TCP.
I have updated the library code used for the fad up and down process. It should handle the situation you are talking about better now. To get the new code please perform a repair for the app through HPM and test again.
After you performed the repairs are you still seeing any errors like the one below
That really shouldn't occur in the most recent versions of the code.
It looks like the "Govee v2 Device Manager" driver was updated--based on the timestamp in the driver list, but the code itself doesn't seem to have any updated comments/versioning (v2.1.0 - 1/20/2025).
The "Govee v2 Color Lights 3 Driver" code is still the same (v1.0.20 - 3/3/2024)
I see an updated "Govee v2 Life Child Light Device", but the lightstrip isn't using that one (should that be "Life"??)
The drivers themselves don't actually change much. The change was in the LAN API Library file. That contains all of the code for LAN API stuff.
I use Libraries so that i can have standardized code for all of the drivers and don't have to worry about missing a change in one of them
Also if you are looking to know a version it is probably better to look at the version shown in HPM. There is no doubt i could do a better job documenting my versions in the app/driver code itself.
Perhaps, in fadeDown, the "if ( level == 0)" should be more like "if ( level < 1 )"?
And, on the final loop, perhaps it should force the v=level (same with the fadeUp routine) so the final level is actually the desired level. Perhaps, after the "int v - (curLevel-FadeInc).toInteger()" line, add an "if (v <= level) v=level" line (and ">=" for fadeUp).
Also, as an fyi, another guy (@MikeNYC) suggested adding the "misfire:ignore" option to all RunIn/RunInMillis commands to ensure they get called (without that, the hub will apparently just fail to do the event if it is too busy).