The logs are showing the same thing. The retry logic is running its course and then is reseting the device so you can submit new commands. That is expected behavior so a device doesn't get stuck in a pending change state indefinitely.
I think you are spot on that the problem is with those specific devices. Something about them is failing to talk back to the hub. I kind of wonder if they got a firmware update recently
I think i would start with looking at the state values on the Govee V2 Device Manager device. It is heavily involved with the multicast communication recieved from all Govee Lan API enabled devices. Scroll down and look at the state value "LanAPIDevices". Each device that is enabled for LAN API should have a entery in that state value. The key is the MAC Adress of the device and then It has values for sku, ip address, and last reaponse sent to the Govee V2 Device Manager. The last response timestamp shouldn't be more then 1 or 2 increments of the device scan interval setting behind current time at most. If the device is busy it may be much closer to current time. It the device isn't there at all, or way behind then the device is simply not talking to the hub/multicast socket.
If the device isn't talking to the multicast socket then check and make sure the device is on wifi. I suspect that since you could toggle the LAN API on it probably is, but check it. You may need to turn off bluetooth on your phone for a bit to verify the device is controllable that way.
Then try cutting power to the device completely for 30 seconds to a min so the controller fully reboots. See if that fixes it. I have a light bar device thay started having issues and started needing this treatment. The final solution was to pull back the device scan frequency on the Govee V2 Device manager from 30 seconds to 5 min.
Lastly reset the wifi on the device and set it back up and re enable Lan API.
If all of that doesn't do it i hate to say i would probably reach out to Govee at that point. None of what i suggested above is on the Hubitat side. The fact you have other devices working with LAN API points means the Govee integration stuff is working fine. Let me know how all that goes.
To prevent to much fall out you could switch back to the cloud API temporarily until you have time to work this LAN API if needed.
So, I tried to turn logging on the Govee v2 Device Manager off to remove the clutter.
However, I still get a bunch of parse messages every minute--and I guessing they are due to the "scan rate" setting.
I wish those messages would go away when logging is off.
But, I'm also trying to figure out what it's doing that requires scanning the LAN every minute.
I give my devices a fixed IP address when they relate to home automation, etc. So, it should be a very rare case (months to years rare) when I add a new device--and I'll be opening the device manager so it should force whatever scanning needs to happen at that time.
What am I missing? What is the downside of maxing that scan rate out?
The device scan is simply for device discovery. If you wanted to max it out, the only impact would be if you added new devices they wouldn't show up to enable local lan control for a while until thd next scan. You could always manually trigger the scan from the device manager.
This process also controlls updating the IP associated with the device. So it is possible if you don't have a iip assigned you could loose access for a bit until the new ip is discovered.
You may have other stuff talking to the multicast socket. I know i get a bunch of scan messages from Home Assistant.
If debug log is turned off for the Govee Device Manager that should limit the messages i think. If you post what you are seeing i will check to see why they are ahowing up.
I added a new Govee lightstrip today--and there seems to be a bit of wonkiness
For some reason, when I enter a hex RGB value into a Room Lighting (RL) table that corresponds to what I see being sent to another, identical Govee device that I added long ago (I see the values via debug logging), RL often magically changes the hex value to another one (close, but a few numbers off on the various colors). It's really odd, because the Room Lighting app accepted and saved those Hex values before and now it won't save the exact same values!
Also, I regularly see the Level value NOT being updated on the device. The RGB value has a corresponding "level" number, which shows up in the Room Lighting table--but when the scene is activated, the level doesn't get updated (neither on the device nor in the RL table). Given some of the conversions being done to map Hubitat's colors to what Govee wants, it seems like it's possible that your driver isn't bothering to calculate the proper level, perhaps?
It has to do with all of the conversions going on. It is something i have discussions with Hubitat staff multiple times about.
The first thing to understand is that Govee functions with RGB while Hubitat functions on a HSL with L being on a 0-100 scale. The 0 to 100 scale is important because it means that it isn't hard to pick a color in any other method and not have it match. You loose allot of color precision with the way Hubitat does it.
What makes this worse is that Hubitat allows you to use the other scales. So it is very easy to use any app/tool in Hubitat that allows another scale and simply select a color that can't be displayed.
Because i am converting everything to RGB no matter how you select it this makes it harder. It is very possible with all of the conversions to put in one color with the NON HSL color picker and end up with something a few shades off once the conversions are done and return data is presented back. I set the color based on the data returned no matter what is submitted. So what you are shown on the driver is what Govee actually set and converted back to the HSL scale minus the L part :P.
I would suggest only using the HSL color picker option in the apps if you need to ensure the values always match. The HSL Value that is fully supported by Hubitat should always match up, though there is still a chance for change because of rounding to come into play.
As far as brightness goes it is a bit complicated. RGB doesn't really have a brightness value per se. The brightness is simply represented by how much of each RGB are in the value. When my drivers change to any color no matter what you expect the brightness to be, it will set the brightness value in Hubitat to 100%. This gives at least a decent representation of the brightness value. If it wasn't done this way what you end up with is a % of a %. Think of it like this, if you use a color value that should have 5% brightness and then set the brightness in hubitat it is 5% of that. That is darn near off. That is ironically the exact situation that we discovered this issue. This was also a issue with the Hubitat Govee Built in integration as well, and i believe the implemented the same solution.
I hope that explains everything. I know it is a pain, but i have brought this up allot with the Hubitat staff. The problem is at this point it is a very difficult thing to change/fix
If your device supports MATTER you could try that. I believe MATTER devices have a better time dealing with this situation since both Hubitat and Govee are having to follow the MATTER standard. That is likely trading one problem for another though as MATTER can still be a bit flacky
