at the moment no it's working ok. not sure if API rate limit reset or what as i didnt change anything else.
The problem with rate limits is sometimes once you hit them you can Really struggle to get back in a good state.
The rate limits they have are 10 per min for device status lookup and changes per device. 10k api transactions per day. So the reset is either per min or day. Something was triggering ever 5 seconds it seemed based in your log snippet. That is enough to kill the API rate limit for a device. I am glad it worked itself out.
The actions the API does are on/off, set color, set color temp, set brightness. Some actions in Hubitat will generate two calls. For instance if you set a color the color command will be sent and the brightness is set to 100. Or if you change color temp to 5500 and set the level to 65 that is two commands. It is just the nature of how the commands work with their API.
I think I have an idea as to why you may have gotten in such a bad state. I am going to make a small change to the driver to alleviate what i think cause it to get so bad for you.
My theory is that after you hit the rate limit you kept trying to make changes for a bit and this triggered a bunch of retries. I am going to adjust the code to try to minimize the potential for a bunch of pending retries getting build up.
1 Like
Ya, every time someone flips the light switch in either of the kids room. So I'm sure those retries started piling up. I'm still not sure how that got me in a bad state to begin with, but I'll continue to monitor that. Maybe I should setup an ELK log stack to query the logs, wouldn't be able to get to that for a week or so though.
My gut says that something is making API calls more frequently than we intend. I'll try and poke through logs when I have more time.
Well things just added up. The driver has a retry function built into it. I did that largely for Appliances to ensure they go to the expected state incase rate limits are hit.
I proved here you can just stack those up and the driver will let you. I have made a small addition to the driver to prevent that going forward. Simply put after the first API call hits the rate limit it will abort following calls. It will also tell you what command is causing the failing call to occur. So if someone is just sitting there flipping the switch on and off you will see that 
I will post this soon so you can have this next time.
I just need to roll it into the rest of the Light drivers. I am not going to change this behavior for appliances because i kind of feel it is more important they go the last requested state.
1 Like
Will this also clear pending actions on devices that are local too?
I was trying to get my outside lights to ramp down, change color, then ramp back up and managed to rack up thousands of pending actions that took the hub a very long time to clear. I did this week's ago but, if my memory is correct, it was in excess of 10 minutes to clear. Several times I just deleted the device.
I gave up on the idea as it was too hard to try and work through.
@oldcomputerwiz
Lan and Cloud API's follow different paths in the drivers.
The Lan API's unfortunately won't be adjusted by this change. As things stand right now the drivers have no way to know what the status of the commands are that are sent. This is why the Cloud APi is still used on even LAN Devices to do device status lookups.
When I added the ability to do Ramp Up/Down to the driver for lan control there is no doubt that it has the ability to overwelm the communication between the Hub and the device. My standard for myself is don't send more then 1 command every 2 seconds. And if you need to ramp up or down faster then 1% every 2 seconds then adjust the % Change value in the driver.
Think of it like this.
If you want to fade a bulb from 100 to 10% over 10 min then everything is fine right. 10 min is 600 Seconds and you are fadding 90% or 90 times 600/90. That is a change every 6 and 2/3 I doubt you would get any pending hub actions( I haven't in testing atleast)
If you want to fade from 100 to 10% over 10 seconds though that is a different story right. In effect you only have 5 2 second intervals so 90/5. to keep that to 2 second intervals you would need to adjust the change% to 18% per interval.
I don't see the Fad over time option being practical for short intervals and probably wouldn't use it myself for intervals less then 1.5-2 minutes.
All that said what exactly where you trying to do that generated thousand of pending hub actions. Even in the worst case scenario I performed it was always less then 100.
I have a rotating color rule (changes colors every 15 secs) and am not a fan of the abrupt color change. My bride thinks it's fine. I was trying to dim the lights to 1%, change color, and bring them back up to 100%. Regardless of the % I put in the driver, the system was overwhelmed. These lights just aren't set up to change color the way my Lightify garden spots do.
It's not a big deal. I've had other issues with these WiFi devices too and may pull them and replace with something that is Z-Wave or zigbee unless govee gives us access to scenes from HE. I really want access to scenes from within a rule.
I generally stay away from wifi devices but with the features, price point and your local control driver I had to try them. They do appear to be a solid product. I really do appreciate all of your work on this driver though. You have done a great job with it
Thanks for replying.
You could try a switch that Alexa has access to. Alexa does have the ability to set the scene.
1 Like
Do I actually have to have an Alexa device? I'm a "Google" guy but have no issues setting up Alexa in software.
Now you have me thinking though, I wonder if Google has access to the scenes? I prefer local but this isn't anything critical and the world wouldn't end of something didn't fire correctly.
Thanks for pointing me in a direction I hadn't considered.
Unfortunately Google doesn't have access to it. So far it is only the Govee Home app, or Alexa. I don't think you need an Alexa device to trigger it .
As soon as Govee does decide to open it up you can be sure I will be adding it. Your welcome.
2 Likes
I played with the Alexa skill and this looks promising. I'm guessing I'll have to use virtual switches as a go between HE and Alexa to trigger scenes. Thanks for the tip @mavrrick58. I appreciate all of the help with this.
1 Like
Are these changes available? I'm definitely having rate limit issues still. It works each day until I get cut off.
Sorry about that. I got distracted by another project. It has been added and published so you should be able to update it through HPM now if you like.
1 Like
Thank you for the Alexa scene tip. I have it all set up and working like I want without needing a physical Alexa assistant. It's also opened up some other uses too.
I do have an issue that I have had since the beginning I'm trying to track down. Maybe you can help. I'm finding that sometimes a light strip will turn back on after being turned off. This is not isolated to one single device, I've seen it on both H6172's running via local in the driver. It saw it happened on one strip this morning so I captured the event logs for both strips.
Here is the event log of the device, Govee North, that worked correctly and stayed off.
Here is the event page for the device, Govee South, that turned itself back on.
What stands out to me is when the switch on command is issued at 7:08:14 it is from the strip itself (not the valentines rule in rule machine), there is also no command-off in the logs. I manually turned the strip off at 10:58.
I did not turn the strip on manually at 7:14:08 via the device page (if that's what this is indicating). This does not happen each time the lights are turned off nor does it even happen everyday. I can do a second check to make sure the lights are still off but I don't want to do that unless I have too.
Any ideas? Thanks!
When you noticed that were the lights actually on, or were they just reported as on in HE.
I suspect this is related to timing of polling the Govee Cloud API vs the device taking place. What is your polling interval?
What i am thinking happend is that the Govee api didn't get the update for the device to be turned off. So HE sent the command to turn it off and then 8 seconds later it polled the cloud API and got a on state and then the driver updated the device state in HE back to on, but the device was not actually turned on.
These are outdoor strips are they using Local Lan API's?
The light was on and the valentine scene was doing its thing.
This has me stumped. I'm not really sure how to troubleshoot this. Would debug logs be of any help? I can set an alarm to turn on debug before the lights turn off at 10pm in the evening.
Polling is set to default
Using local
debug logs may help. Or more completely the logs from the whole hub. It may be good to see what is happening on the entire hub.
The Polling process, based on the code shouldn't change state, which is why I asked about that timing. But if it is actually turning on then something has to be telling the device driver to turn it on. Only other time I have seen something similar was when I was experimenting with using Node-Red to replace cloud polling by polling the device directly with the LAN. I found that because of how the LAN polling worked with Node-Red that anytime the node red instance restarted it would turn on the lights.
The sporadic nature of this means it has to be something strange and a timing thing. Could you try turning off polling completely and see if that will solve it? The logs don't actually show a command being submitted, but just the event being sent. That shouldn't exactly turn the lights on.
I'll turn off polling. I'm also going up see if I have some camera footage ofThat period and see if the light actually turned off.
I don't know if this helps or not. The light did not shut off when instructed to to at 7:14. I confirmed this by watching camera footage.
