I am sorry if this is maybe the wrong place to ask, but would you be able to walk me through how to make the multicast call in order to obtain the LAN control IP's? I have read the Govee documentation on it and I don't even know where to begin to send the call to have it spit IP addresses back for me to enter into Hubitat. If this isn't the place, could someone send me a link on how to do this from scratch? Thanks all!
EDIT: Per Garz's responce below I ended up going to router and pulling the information from there. Don't know why I didn't think of that in the first place. Thanks!
You can download a free ip scanner tool for your phone or pc. It'll show you the IP's of all devices on your network. https://www.advanced-ip-scanner.com/
I personally use my router's DHCP table. In a quick pinch, "FING" app on my phone.
PM me if you need further assistance to avoid cluttering up the topic.
I just posted a small update to the code which is now on version 1.0.19. This update allows you to update the API Key if needed. Once you update the API Key in the main app it will push it down to each device. This is in direct response to one concern raised when working with @Hus. It is entirely reasonable to think users may need to change their API key on occasion.
For the last week or so (maybe longer?) my govee integration has been completely broken. When I started looking into it last night I noticed the current state of the cloud API shows "retry", and in the logs I see "CloudAPI already in retry state. Aborting call."
I only have 1 govee device and unfortunately it doesn't support local lan, so I'm stuck with cloud control. I only have 2 automations that turns it on/off at sunrise/sunset, and toggles it on/off on a button press. These are outdoor patio lights, so they don't get turned off and on often.. I have the polling rate set at 1000 seconds (bumped up from 300 for troubleshooting) and currently my state variables show as MinRateLimitRemaining: 9 , and DailyLimitRemaining 9967. I'm not entirely sure how to read this but I would think I should be fine as far as the rate limiting goes. In the apps device info it says I should be able to poll as frequently as 8.7 seconds.
Yesterday I applied for a new API Key and changed it in the app's integration menu, but that didn't change anything. I noticed this thread mentions a recent api outage, but it sounds like that was resolved earlier this week.
Any thoughts?
So the flow of events to lead up to a cloud retry state should be something like this.
You attempt a change
The Govee api returns a failed message for some reason
The Hub takes that message and schedules the change to occur again in 60 seconds.
It will continue this until there is a succssful API call.
Along with the above actions it will also ignore new calls until the APi is in a better state
So here are my questions. 1. If you leave the device alone and don't trigger anything is the device in Hubitat showing CloudAPI state in Retry? If it is and then you go look at Live Logging does it show it is attempting the retry call.
Basically what i am trying to validate is if somehow we got in a unrecoverable state where it is in that retry state, but the attempt to run the next attempt has been lost due to some activity.
I have been pondering the idea of a reset to essentially break that loop and reset it.
Can you also tell me what driver it is that your device is using. I have a idea of something to allow you to get out of that state. I will put it out for you to test first before publishing to everyone else.
Thanks, The driver is the "Govee Lights, Plugs, and Switches Driver".
The device has been left alone and nothing has been triggered for over 9 hours but it still shows in retry state. I'm only seeing log entries (Cloud API already in retry state. Aborting call) when hubitat tries to control the device... (a handfull of entries from yesterday) Nothing in the logs regarding my govee stuff for the past 9 hours since hubitat tried to turn it off at midnight last night.
OK so i just posted the update to that driver. Once you confirm you are in a better state then i will make it avaliable to everyone else. I added two ways this will get reset.
It will automatically reset when the device Poll is done. This will be automatic for everyone
You will be able to click on Initialize and that should trigger the device to reset the status as well
To get the new code you just need to go into HPM and perform a repair on the Govee Integeration so it will download all the code again.
You may want to go and set the polling to a more reasonable value 30 or 60 seconds. Then I would ask that you want that time to see if the device reset and starts working. If it doesn't then click on the Initialize button for the device.
That worked! I actually saw the code change on github and pasted the new driver code in. As soon as I hit "initalize" i saw the state update from retry to success. I actually didn't see your comment here about changing the polling time and waiting until I had already hit initialize.
You are amazing! Thanks!
Fantastic, I will go ahead and do a little bit more testing before i publish this change to the rest of the drivers and to everyone.I would prefer this to not require you to have to manually hit initialize which was the purpose of my above ask about waiting. I can test that out though. Thanks for posting this so we could get this taken care of.
I had exactly the same issue as adam3 except I use the TV immersion lighting. Just like him, I also got a new API with the same results (also use the same driver). Since this has been going on for at least a few days and didn't have anything better to do at midnight I removed then reinstalled the app, that fixed it. Of course it hosed up rule machine a little but got the rules fixed and all is good, so far.
I feel like when the API went down earlier this week or last week... whenever it was... that something got out of sync with the api state for some of us. Thanks again for getting this sorted, sounds like next time there is an outage this shouldn't be an issue for anyone on the latest version.
I always want to try to prevent the need ot remove and reinstall. Please feel free to hit me up for resolution before you have to do that.
I think this largely related to their major outage a few days ago. Govee's entire cloud API was down. Then because of how i modified the driver due to another issue the driver could get into this condition.
A user above had a situation where he had a yong family member generate so many pending api calls it took his hub hours to recover. So i added this to prevent that build up. After that though i didn't account for if the driver somehow lost it's retry and then was just stuck in Retry state. It will be accounted for shortly in the drivers with this change.
I am still not exactly sure how the device got to this point though. Only thing i can think of is that something like a hub restart or driver reset occured while it was in this bad state causing it to loose the pending action. As long as the driver kept running it shouldn't have done this.
One more thing to add is that it isn't like the Cloud api doesn't hiccup allot. I keep live loggin in a database and short blips with the Cloud api happen nearly daily, but a prolonged outage for 12 hours hasn't happen for as long as i can recall.
I am still not exactly sure how the device got to this point though. Only thing i can think of is that something like a hub restart or driver reset occured while it was in this bad state causing it to loose the pending action. As long as the driver kept running it shouldn't have done this.
I did have my hub lockup at some point recently and had to reboot it, so that's probably what caused it.
Looks like Rate Limits have been removed from the Cloud API. or atleast in my case they have.
First i had to reload the app on my dev hub as I must have removed it for something. As i was starting the test to make it fail i couldn't get it to do so. Upon looking at the logs the API parts of the header which are used to determine rate limits of a device were missing. I easily did more then 10 calls to trigger this device to fail and it didn't do so.
@cjselby can you look at your devices and tell me if they show any API Rate limit values under the "State Variable" section for the driver.
I wonder if this was somehow related to the outage a few days ago.
I do know some stuff is happening with the API's as I have been in on/off contact with what i think is a "Govee Ambasador". He has taken up the mantle of explaining the API in the Govee Community forums and we have had a few talks about it. He has followed my posts there and appearently has reiterated most of my/our grievences with them in his capacity. This is important because he actually has their ear and as I understand it they actually asked him what would make it better. Hopefully they will produce a new API Document that will go into further detail if there are changes.
He is also suppose to be sending me some new information that he recently discovered, so hopefully we will have some big/good changes here in the not so distant future.
