The last call that caused the warning for me was about 7 hours ago. So maybe they took Roy's advice and turned off and on again!
1 Like
Just an FYI.
I get these on a reboot, assuming it's just an init thing as it seems to go away after the boot.
Looks like they did do something:
Hello,
Thank you for your message.
We have added additional resources to the Cloud API, which should help resolve the delay.
Please try your requests again and let us know if the issue persists or if it has been resolved.
We appreciate your fe-edback!
2 Likes
That is good to know they didn't stop with that initial response.
Yesterday I received an update from the Govee Cloud API team about the slow response time while using a Hubitat controller. They replied with "the development team has implemented capacity enhancements."
While my Govee Cloud API devices are responding to on/off commands again in the 80 - 150 ms range, the device status is not updating unless I manually refresh each individual Govee device using Interation V2. Status updates fine on the Govee mobile app. Any Govee Cloud API device where I depend on status for command execution obviously does not behave properly.
LAN API devices work fine. Did the Govee Cloud API team not correct the response issue completely? Not sure how to respond to them.
Can you provide some specifics about what exactly is failing.
- What is the device model number
- what driver is it using
- What attribute are you seeing that is not updating as expected.
- Are there any logs that indicated something failed
The way the Govee Integration works is as follows. It submits the commands and then based on the api response from Govee Does one of two things. It either gives a successful status for the Cloud API Attributes and then updates other attributes based on the commands submitted. or changes the Cloud API to retry and then submits it again 1 min later.
- Do you see the Cloud Status Attribute stay in Pending or Retry?
To test the problem it may also be good to take a device and turn on debug logging. Then send a command to change it's state via the Cloud API. Then send me the logs for the device and tell me what the state should of changed to. I can then review the logs generated to see what Govee actually responded with.
After digesting your message, I did a little more troubleshooting and found the problem was of my own making. With the Govee Cloud API having a 10+ sec response time, I tried to minimize the issue by switching from individual light control to using Govee control groups. In doing so, I created my own issue.
I was controlling groups but still checking individual light status, I didn't realize there was a delay in updating status across groups and individual lights. I updated my lighting apps so individual lights check individual status and control group lights check control group status. Stupid move on my part. Everything is working fine now.
Thanks
1 Like
Okay, that does make sense. The Govee Group Control devices do make sense to use at times but I can see how that would throw off the status until the individual devices are polled.
Another potential option is to look into my "Light Effect Tools" App. It includes two child apps, one of which is to create groups of devices for control. If you create your group with that smart app, and it create a child device. The child device it creates will then submit the command to each device. It does allow you to control all the normal stuff as well as create a Custom scene list between different Govee Models.
It isn't perfect though. I have two things I know I need to enhance.
- I need to enhance how the scene management is done for next and previous device,
- I need to add some logic to handle when a device in the group is changed outside of it. Basically disable the group and reset it I believe.
I just noticed that the H5106 gained Cloud API Support recently. That is the older Govee Air Quality Monitor device. I added it and mine installed using the temp/humidity sensor which seems to work fine with it.
There is one more possible attribute for it which is AirQuality, but until i understand it better not going to worry about it. The other sensor in the device is a PM monitor, so not sure how that is relating to the AirQuality metric.
Suddenly, my Govee lights aren't working.
When I go through the "Standard Device Setup", both of them are there so I click next.
I see this in the logs:
However, prior to doing that, I don't notice any errors--just that the lights weren't responding.
That seemed to be an issue about a year ago as well.
I did a "Save" from the Preferences tab for both devices and they started working again.
Any thoughts?
I need to change the verbiage on that error. It isn't a actual failure and not a problem. It simply means the device was already installed.
Was it all devices or a specific device.
Is it being controlled via LAN API or Cloud API.
Do have your device set with a reserved IP, or is it allowed to change occasionally
I just published a small update to everyone. It is the update for the Ice Maker Pro that has been in Beta for a while.
It was all (both) devices.
The IPs are supposed to be static with a reserved IP, but the other day I was playing with a different router that was dynamic before I swapped back. From my router, they appear to be on the assigned IP address. I don't see anything in the actual Govee mobile app that tells me the IP address they are using--but your device driver (at least now) shows them using the right IP address.
The Govee Device manager gets the IP from the device when it does a device scan. It is suppose to tell the device if the IP changes what its new IP is. It is possible in that process there is a short time that things get out of sync. Without something in the logs indicating a problem it is near impossible to know for usre what the issue is though.
1 Like
I just pushed a new beta update.
All it includes at the moment is a way to reduce the amount of logs coming from the integration. Simply put the general logging for API Call process times has been put behind the Debug loggs toggle. That said if a call takes more then 10 seconds it will still generate a log entry as a warning. This should significantly reduce the amount of log entries from the integration
3 Likes
I installed Govee Integration V2 from HPM and then discovered that my devices (floating pool thermometers) is not suported. I've been trying to Uninstall through HPM but I'm getting "Fatal error occurred, rolling back". I tried a Repair which was successful but always getting fatal error on attempting uninstall.
Can you DM and list the items that you have installed. I will check a few things to see what i can come up with.
@mavrrick58 good day.. I am seeing something odd.. i have done everything i can think of, but i'm at a loss... Out of the blue today every one of my Govee devices are no longer able to be communicated with, however when i look at the logs i can see the LAN IP connection is established.. I just have zero control of any of my devices from HE. I can control them from the Govee app without issue. Here's a snippet of the log output of one of my devices i tried to control and can't.
Snippet of Log
dev:13942026-04-11 00:18:03.594
info
lanRetry(): Max retry reached, resetting API state.
dev:13942026-04-11 00:18:03.589
info
devStatusWait(): Max wait for Device status reached. Resetting Device Status state to ready
dev:13942026-04-11 00:17:56.983
info
devStatusWait(): Max wait for Device status reached. Resetting Device Status state to ready
dev:13942026-04-11 00:17:50.476
info
Starting retry for retryOn.
dev:13942026-04-11 00:17:50.472
info
lanOnVal(): Couch Light in off failed to turn on. Retrying
dev:13942026-04-11 00:17:29.341
error
java.lang.NullPointerException: Cannot get property 'switch' on null object on line 1106 (method loadState)
dev:13942026-04-11 00:16:27.468
info
lanRetry(): Max retry reached, resetting API state.
dev:13942026-04-11 00:16:27.463
info
devStatusWait(): Max wait for Device status reached. Resetting Device Status state to ready
dev:13942026-04-11 00:16:20.010
info
Starting retry for retryOn.
dev:13942026-04-11 00:16:20.000
info
lanOnVal(): Couch Light in off failed to turn on. Retrying
dev:13942026-04-11 00:16:19.738
info
devStatusWait(): Max wait for Device status reached. Resetting Device Status state to ready
dev:13942026-04-11 00:16:16.039
info
lanOff(): Couch Light is unable to turn off. API Busy pendingOn
Any thoughts or info would be greatly apprechated..
As always, thanks.
Did you possibly have a network reset and all your devices get new IP's
The logs show the retry logic being active and then resetting the API State after the retry logic fails to get a goood response in the specified number of retries.
For whatever reason it seems the hub is not getting responses from the devices.
Maybe reset your network as well as a reboot the hub to re open the multicast socket.
I set all the devices with ip reservations just so there aren’t IP change/issues when I connected them the first time. I have noticed that the only devices affected are H600A bulbs and H60A1. My H600D, H7075, H6056, H6199 lights and even my H7123, and H7126 air filters are good, it’s just the H600A and H60A1’s..
I have double verified that my IP reservations were still set and I’m able to ping the IP’s of each device so I know the IP’s are correct and working. It’s really odd, to say the least. I’ve rebooted the hub and network about 6 times when I realized i was having issues lol. I also validated that the multicast is active for the network the devices are connected to, and alls fine there too..
It’s just really odd it just all of the sudden started, but thanks for the thoughts.. I completely came off all my Phillips Hue bulbs/hub and have been loving the Govee replacements with your HE drivers. I’m hoping I don’t have to revert back to Hue lol.
@mavrrick58... You won't believe this..... I looked at everything for hours over the week. Posted Friday.. Saw you're response, and validated everything on the network and all we fine. I started screwing with things again and still nada. But then I opened the Govee app to look at one of the affected devices. Mind you, I haven't even opened the Govee app for almost a month, and while I was looking at one of the blubs, somehow, the "LAN Control" was disabled on the select bulbs I've been having issues with. I re-enabled the LAN Control for each device, I tried one of the bulbs from the Govee app and no issue, but I went to my Hubitat and nada. So I did yet another HE reboot and still i'm not able to control the bulbs. Here's the current logs when I tried to turn on one of the issue bulbs..
Logs
dev:13942026-04-12 21:04:16.512
info
lanRetry(): Max retry reached, resetting API state.
dev:13942026-04-12 21:04:16.510
info
devStatusWait(): Max wait for Device status reached. Resetting Device Status state to ready
dev:13942026-04-12 21:04:09.993
info
devStatusWait(): Max wait for Device status reached. Resetting Device Status state to ready
dev:13942026-04-12 21:04:03.497
info
Starting retry for retryOn.
dev:13942026-04-12 21:04:03.491
info
lanOnVal(): Couch Light in off failed to turn on. Retrying
dev:13942026-04-12 21:04:03.238
info
devStatusWait(): Max wait for Device status reached. Resetting Device Status state to ready
I know it's not the network since I can control other bulbs without issue, its just the ones i mentioned earlier. I'm hoping something gives your expert brain a "Ah-Ha" moment cause I'm lost at this point. I just hope I can get this figured out by Tuesday or I'm gonna have some highly mad people in my home. Luckliy I'll be out of town for the rest of April, but on my return I may not be alive for long once I get back HAHHAAH..
Thank you as always.
