For the regular strip lights, is it ok to Cut and use a 90* connector like this to go around corners?
I don't see why not as long as those connectors are the right width and has the right number of pins.
When you cut just make sure you connect them in the right direction if they are RGBIC.
I can see my devices in "device selection" but when i click to see my appliances, it gives me an error.
Any idea whats going on?
thank you
That error above means you have made to many calls to the API and have hit the rate limit. How many times did you go into the device selection screen? You can either make 10 per min or 100 per day for the V2 api the appliances use.
I was able to reproduce this exact error condition by inducing to many calls.
This integration should make 2 calls to each api (v1 for lights, ect and v2 for appliances) when setting up devices. One when you click on the device selection option and then a final one when you click on done and the integration adds all of the devices. It doesn't matter how many devices you add at one time. Did you go in and out of the device selection option multiple times. That is how recreated the error.
How many times did you go into the device selection screen?
A few, trying to re-add my humidifiers, when I found out that they weren't paired anymore.
I had 1 piston on Webcore that overwhelmed my hub (i thing it was the reason the Zigbee radio turned off a few times during the last week. But this "I think" comes from a person who is a beginner to this things). Can it be another reason?
How can I correct this error so I can re-add my humidifiers?
Thank you for your help 
So there are two levels of rate limits for the appliance API
10 calls per device per min and 10 devices lists per min. If this is the rate limit you hit you just need to wait 60 seconds.
100 calls per day for all appliance API calls. Depending on how many devices you have this one can be hit easier. This means waiting 24 hours.
My first suggestion is just to wait 24 hours from your last attempt and then try to add all the devices at once. 100 calls is not allot if you have several devices. This as I said previously will limit the setup to just two calls to the cloud api and minimize the rate limit impact.
Just out of curiosity how many devices are we talking about for govee appliances?
Thank you. I'll wait and see what happens.
I have 2 humidifiers (H7141).
Well that isn't to many. If either is already configured you could go into the device in the hubitat UI and see what the Rate limits show. It should show what it was the last time it executed. You can also see the last reported number for both APIs when you open up the Govee Integration smartapp.
I just added a option to enable notification when your Daily API Limits with Govee Cloud get low. So look for that in the next release. I have one more idea for a feature add related to the space heaters that i am pondering. I will release this update once I finish testing and coding that feature.
Thank you so much for your support!
What you did is amazing!
1 Like
This is why it is important to understand the difference between the local and cloud APIs -- they are very different. I consider the cloud API almost useless because of the rate limit, but not all operations are supported locally.
I kind of agree and disagree with your statement.
This isn't true though. The commands are a little different, but the functions are identical, for the devices that support local API control or cloud API control. Both API's allow you to do the follow actions: Turn the device on/off, change the brightness level, set color temperature, or set the RGB color. I added a method in the driver to send multiple commands for fade over time though. The only item that we can't do over Local lan is the device status lookup, but this is a limit of Hubitat and how they let use use UDP listeners as Govee supports it.
The only function that isn't supported via the API's is setting a scene.
Ultimately Local Lan APi is better as it reduces the chance of a failing action, but the cloud api does work pretty darn well. They both are more then sufficient for making a device do one thing at a given time. With that understanding all commands that set a condition like brightness, Color Temp or RGB also all turn on the device. The problem occurs when you want to do something that requires multiple calls over time or the device will have very quick changes in state. An example of this would be trying to do a fade over time with the cloud api. That is why this driver simply doesn't allow it.
The APi's rate limits are pretty straight forward as well.
For Lights, Plugs, and switches it is as below(APIv1):
For the total day = 10k
For device list = 10 per min
For device control = 10 per min per device
For device state = 10 per min per device
For the Appliance API (APIv2)
For the total day = 100
For device List = 10 Per min
For Device Control = 10 per min per device
The Device List rate limit really shouldn't be to much of a problem. The only time I have hit it was when I was intentionally trying to induce it. I literally had to go in and out of the device selection for appliance screen 10 times to trigger it. This is why I suggested above to do all at once instead of splitting it up.
The Device Control rate limit should be fine as long as you submit the right command to execute the change you really want. So don't turn on on a device and then set it to 50% brightness, just tell it to set level at 50% and that action will also turn on the bulb. I will also add for appliances this likely also means using appropriate buffers or auto modes when possible. What I mean by this is that for example is if you use a space heater use a different value to turn it on and off. If you goal is 67 degrees have it come on at 66 and off at 68.
That said there are use cases where they can be consumed. I am fairly certain putting a Govee Cloud API based strip in my pantry could at times hit the rate limit. Not frequently though, but occasionally. There are busy times of the day where we open and close it repeatedly.
The daily limits are a little bit different based on which version of the APi you use. Both API's can be dramatically impacted by the total number of devices you have. The Light, Switch, Plug(v1) api with 10k is pretty large and generally only gets crushed when you have polling set to run very frequently. The default value in the Drivers is 300 seconds or 5 min. That should prevent any issues from polling, but if you set this down to lets say 8 second and have a dozen devices it will be a bad day. This is why I have a suggested polling interval minimum shown in the app when setting it up. I will stick with the 5 min interval because simply put I have never switched between my phone and Hubitat that quickly. If anything I have started something in Hubitat, and then finished it in the Govee home app.
The Appliance API(v2) is limited to 100 and that is likely ok for a number of devices. The Appliance APi doesn't allow for a status lookup which reduces the need for such a large rate limit for the daily max. That said do believe that 100 may be a little to small as your number of devices grow.
My suggestions are as follows.
- When possible get and use devices that have the ability to use the Local Lan API. This means they will only use the cloud API for status updates.
- Set reasonable values for status updates. If you don't need to know the status of a device within 30 seconds of a change from Govee Home or Alexa then don't set it so low. I like 300 seconds, If you are unsure open the Govee Integration app and check what the suggest value is for the number of devices you have integrated.
- Use buffer values for Appliance devices to activate and deactivate as shown above and even better use Auto modes on those devices if available.
Govee Home 5.4 was released last night. Along with it there were many additions to local LAN control. Several more strips were added from when I had previously checked. A few lamps were added including their new nightlight, and the ground lights. I also identified several more Led strips that appear to only be available on Amazon.
@garz One of the devices added to lan control Was a Night Light devices. Not sure if it is the one you have, but if it is you may be able to control it now locally.
1 Like
Thanks for the update. I'm maintaining my own code so will try to catchup next time I focus on it.
I have been playing with Node-Red today a bit and found I can reliably use it as well to send and receive the UDP packets for the LAN APi. If someone really wanted to i am sure a flow to regularly query the local devices and then update the devices in HE to completely eliminate the cloud could APi be done.
There are a few quirks like Node-Red if in docker needs to be on the host IP network and not behind a NAT in Docker. Once I got it working though it ran like clockwork.
Nope, not my night light. 
It's alright. Serves its purpose and works fine with Alexa routines to trigger.
Does anyone have this integration loaded and has homekit working?
I am a android only house, so can't test it here.
Is this list available somewhere? Turns out the lights I bought are way too much, and I can't use them like i thougnt I would. I need to find a smaller set that work with LAN.
I updated the first thread in this post with the list of devices from the documentation as of the other day. You can also look at this spreadseet where I have each device and a URL to buy it if I could find it.
Some devices seem to only be available through certain channels. It also looks like the supported list of lan devices was updated since they published 5.4. I have updated my spreadseet to reflect it. It looks like several devices were removed, but most of them were devices I couldn't find in the first place.
I am not sure if anyone is interested in using Node-Red to fully remove the cloud, but here is a flow to do just that. It is able to poll the device with the LAN API and then update Hubitat of the relevant local LAN API items without using the cloud. The only benefit to this is to removing polling from the cloud API and since this is all local it can be a very short interval like 5 seconds.
With this you could have it poll the device as frequently as you want.
In theory you can also then automate through Node-Red as well
Though the flow has allot of stuff only a few changes would be needed for this to work for anyone.
- Update your source IP for the "The device Ip Scan section" to reflect your Node-Red Servers IP address
- Create a Govee Outbound connection for each device you have that is detected in step 1
- Add a Switch in the "Rout based on device IP" node for each devices IP found in step 1.
- Copy the batch of nodes after the swtich and attach them to the new switch connection in the previous updated node
- Update the Hubitat command node to reflect the correct device for that IP.
- Lastly update the repeat interval in the "devStatus" node for the frequency you want to poll the device for status.
Once this is done it should allow you to make changes to the device with Govee home and have that update replicated to Hubitat fairly quickly.
I haven't had enough time to test if any impact is caused on Hubitat from this, but will post of there are any issue creeping up with it.
** I found a issue with using Node-Red to keep things in sync. Simply put as you change values certain other things don't change but are still passed ie color mode. This normally isn't a problem as long as the Flow doesn't get republished, but when it does all values are new and then potentially send unneeded updates to the devices in HE. One partial fix for this has been to adjust all of the updates to flow through a switch node that only sends updates if the switch value is 1(on). This only prevents the devices from turning on in the middle of the night if a color value was set. I would suggest possibly avoid keeping color in sync between HE and Govee over the lan APi. I am still experimenting with the flow.
1 Like
