I performed a small change that i believe will address this for you. Please do another repair now. Though the error looks the same it now has the correct line number for where the error occurred.
Error is gone and now reporting humidity, but is not polling every 300 seconds.
Click on initialize to trigger the refresh of the polling scheduled job. Then make sure the scheduled job is there.
Hey i have a question for folks that lean heavily on the LAN API for device control. Do you all mostly integrate your devices with the option to use the Cloud API with it, or do you install the device as a Manual LAN API device without any access to Cloud API.
I am working on some changes for the LAN API side of the house and curious about how folks are deploying their LAN Controlled devices.
For the one device I have that uses the LAN API I integrated it with the option to use the Cloud API with it.
1 Like
I'm using strictly the LAN API.
1 Like
@mavrrick58 I recently completed my transition from Vera and was delighted to discover the Govee app. I'm using v.1 for mostly H6006 and H6008 bulbs and I don't think they can be controlled with a manual LAN API, but I havent confirmed that yet. My recollection was that the recommendation was to also stick with v.1 unless v.2 was specifically needed, but perhaps that is out of date advice.
In any case - moving forward my preference (and a factor in purchasing decisions) will be the ability to avoid the cloud wherever possible.
My two cents - hope it's helpful AND many thanks for creating the Govee apps!
Govee does have a bunch of devices that support LAN API, but none of them are bulbs.
That is old info. The V1 integration has been deprecated and hasn't recieved updates for quit some time. Allot of improvements have come out for V2.
The new v2 app will support both the Govee Cloud API and the LAN API id the device supports it.
1 Like
@mavrrick58 Thanks for the info! When I set up the bulbs I read the initial post in this thread and a follow up webpage search didnt find a reference to my H6008 or H6006 bulbs. I do have the v.2 app installed but without guidance on which driver was best I just stuck with the v.1 and its single driver ( I had a lot of devices to transfer from Vera 
).
Can you clarify strategy for testing the multiple v.2 drivers with my bulbs? Does the latest version have the most flexibility and thus I should try that one first? Or does each similarly named driver work for a specific subset of devices? I apologise if I have missed this info somewhere. Your time working on this app is most appreciated!
If it's trial and error time and someone else has already done work - I'd most appreciate a driver recommendation - cheers!
The older Cloud API used by the V1 integration was very limited with that it told us about the device. That ment all i could do was create a single driver that would have all functions a device could have event if it didn't actually support it. That generally wasn't a problem though as the options were fairly limited in the Old Govee API.
The new Govee Cloud API in the v2 integration added a ton of new features. It also tells us exactly what commands/functions a device supports. Because it can get so granular with the commands a variety of drivers were created based on potential supported command combinations. This allows me to ensure when you look at the device page the optiona that are there are all supported by the device. I generally tell everyone to install all the light drivers. Then the integration when performing the install looks at the supportes commands and picks the right driver for you. If by chance you dont have a driver loaded though you will have a message displayed on the screen when attempting to set it up telling you which one is missing so you can install it.
At this point the code in v1 has been frozen for over a year and V2 has been actively worked on for about a year and 4 months. All of the devices that originally has issues have been resolved as far as i can tell as well. I would certain recommend using V2 only now as so many improvements have been made with it, it is by far the better options.
A ton of improvements were made as well to really help with the efficiency of the app. If you haven't ever used v2 but installed it a long while ago i would uninstall it alll and start from scratch. There have been a few big changes along the way to help with certain functions.
Also unlike V1 there is documentation written for V2. In the V2 integration app there is a icon in the upper right with a ? In it. If you click that icon it takes you to the documentation.
- Just uninstall it.
- Reinstall through HPM and install all the light deivers
- Then install the app to the hub from the Hubitat UI.
- Open the App.
- Add your API Key
- Click done at the bottom
- Open app again and this time select the box to do the Standard device setup
- Select the devices from the drop down and click on next. It should install the device or tell you what deiver is needed. The click on next or done in the lower right corner until out of the aintegration.
- Go to your device page and expand the Govee Device Manager to see your integrated devices.
How many Govee devices do you have? Is it not just the bulbs mentioned. I have a major change coming for LAN API stuff with the next Hubit firmware release.
At some point i would like to get back down to one driver for light devices, but unfortunately the current state with the number of drivers is based on how Hubitat works
2 Likes
Thanks @mavrrick58 for the further detail. You beat me back to the thread.
PLEASE NOTE: I have heavily edited this post after answering a number of my original questions by tinkering far too late into the night
I installed v.2 from scratch, connected all my devices and moved all my bulbs on to a v.2 driver. At this point all the devices had two references in the device table. However when I removed the v.1 app all the devices were removed from my fairly extensive set of "complex' basic rules. While the devices could still be controlled through the new v.2 app/driver combo, they are now also bundled as child devices of a v.2 "device" in the device list. So I will have to figure out what happens to device list room sorting and if my device identification naming strategy needs to change, as I'm unfamiliar with handling of child devices etc.
For the time being I have reverted back to my original v.1 back up until I can find the time to deprecate v.1 and redo all my rules. If there is a way to avoid breaking my rules in the transition, please do let me know, though I suspect it is the price of progress On that note, you mentioned a major update coming. Would I be better to wait until after the v.2 update to transition from v.1?
As to other devices: The only other govee wifi device I have is the Flood Sensor - Smart Gateway 2 H5043, but disappointingly, I don't think the Govee API covers controlling that.
Cheers!
The v2 version is designed to be able to be run side by side with the V1 version. Other then Rate limits there is nothing to worry about running them together.
The migration process recommended in the past was to installl the V2 integration. Then simply pick a device in the v1 integration open it up and go the "in-use by" tab and modify each associated app to use the new decice created by the V2 integration instead of the old one. Once all associated apps have been moved and that tab is empty simply remove the old v1 device and move to the next one. Then once all the V1 devices are removed, remove the app. Yes it is a bit time consuming, but reall was the best way to make the change and ensure nothing gets lost.
The upcoming update won't make a difference for you since those bulb devices do not support LAN API as far as i know. If you had other devices that did the new features would be enabled by the update automatically
The use of the Gove Device Manager device to manage all of the installed Govee devices shouldn't make a difference for devices tagged as in rooms. Those tags will just need to be applied to the new child devices as well on the device's "Device Info" tab . In your case the Govee Device Manager actually isn't doing to much. In some cases it is used to help with processing communication thay has limitations with on how many connections can be made. The best current example is MQTT messages for certain Gove Life devices. It also manages certain things on reboot to minimize impact of the devices in CPU. Depending on the number of devices that may not be a bigg deal, but in my case with over 30 of them my hub was being crushed for 15 min after a reboot.
1 Like
Considering the content of my last post it is probably a good time to tell everyone that for LAN API Connected devices the next version will require those devices to be under the Govee Device Manager to enable the upcoming features.
This presents a problem for those devices setup with the Manual LAN API setup Method without even loading the API Key. Those devices installed using the Manual Lan API setup method outside of the Govee Device Manager will have to be recreated. I haven't finalized code on how to fix the Manual LAN API setup method yet but regardless those existing devices will need to be recreated under the Govee Device Manager if possible. Currently the easiest way to do that will be to load a API key if you have one available and then create the devices using the standard method. Then go back in and change the poll rate to 0
@mavrrick58 thank you for the further explanation and clarifications. Recognising much was general and not specific to your app / drivers, it is most appreciated and helped solidify my understanding of the hub. In particular, a reminder of the "in use by" functionality was most helpful. It took a few hours to complete but I have transitioned to v.2. While it may not have brought specific benefits to my current use case, I suspect it would be far more work in the future as further rules are added and new devices / govee api's evolve.
Have a day, and thanks again!
1 Like
Hi @mavrrick58 thank you for the Govee V2 integration. Do you have any idea what these errors mean? I tried to turn on my Govee lights (H601Bs) last night but they did not turn on. Did I hit my API rate limit? My polling is set to the default at 300, and I currently have 9 of these lights. Any help is appreciated! Thank you.
Honestly i don't have a clue. Is that error still occurring? A response code of 200 generally means everything is good.
If it was a Rate limit you would normally see a error code 429.
Hasn't happened again (yet). This happened yesterday in the late evening, so I just assumed I reached the API limit even though I'm pretty certain I didn't. The lights worked just fine this morning, so it's definitely strange.
So, I just took a closer look at the code to make sure I was interpreting that properly. The top line in the image you provide is from my code. It simply means I haven't coded for the error. The comment about a retry in one min is inaccurate actually. I deactivated that code as it was causing some folks issues. The other lines are what the error returned from Govee. The middle one is the raw data and the bottom one is the error code. Either way neither actually points to a real problem. Simply put what those errors say is the information in the command was good.
The one big drawback to the new API is that it isn't great at letting us know if the API Rate limit is hit or even close to being hit. That said it isn't impossible you did have some kind of rate limit issue. Just take note of how many devices you have and check your polling interval. That by far is the most like thing to bite you once add allot of devices. If the polling interval is set to low you can consume to much of your rate limit and leave very little for actual activity.
Lastly you could look at migrating some stuff to LAN API if the devices supports it. That would be for other devices though as if i remember right those H601B's don't support LAN API. The next release of the Govee Integration will have huge improvements for LAN API
Thank you for taking a look into it.
Unfortunately, the H601B's don't support LAN API, so it's giving me great hesitation to continue adding more in the rest of my house. I guess I'll just have to decrease polling frequency so that I don't run up against the API limit.
Thank you again!
How many devices do you actually have and what is your polling rate that is set on the drivers. By default i set it to 5 min.
The Rate limit is 10k in 24 hours for a given API Key.
