Bingo, that did it. I figured out the cloud api state. When I installed the lamp that does not show the cloud api, I switched on lan control before I used a command that triggered the cloud. So that was completely unrelated. You’re the best thank you for responding and doing what you do! Much appreciated
1 Like
@mavrrick58 First - excellent work on this integration! Its worked great for me, except that I'm trying to install one of their air quality monitors (H5106). I've confirmed that it shows in the app, and I can see on my router that its connected and moving data.
It doesn't show in Govee Integration v2 in the standard device list.
I have a different thermo/hygro installed and that does show, so I know the API key etc is working.
When I try to add lan-only, I get the error Error: Device type 'Govee Manual LAN API Device' in namespace 'Mavrrick' not found.
I did go into HPM, run a repair, and also confirm via HPM that Govee Manual LAN API Device v2.1.5 (driver) is installed along with Govee Integration v2 v2.1.28 (app)
Govee v2 Thermo/Hygrometer Driver v2.1.0 (driver).
Log shows errorcom.hubitat.app.exception.UnknownDeviceTypeException: Device type 'Govee Manual LAN API Device' in namespace 'Mavrrick' not found on line 1545 (method deviceLanManual2)
I have v1 installed in parallel - would removing that help?
Any next steps I can take?
Log after upping level to info:
app:1902025-03-10 15:37:58.416errorcom.hubitat.app.exception.UnknownDeviceTypeException: Device type 'Govee Manual LAN API Device' in namespace 'Mavrrick' not found on line 1545 (method deviceLanManual2)
app:1902025-03-10 15:37:58.389infogoveeLightManAdd(): configuring null
app:1902025-03-10 15:37:58.387debuggoveeLightManAdd(): null is a new DNI. Passing to driver setup if selected.
app:1902025-03-10 15:37:58.384infogoveeLightManAdd() DEVICE INFORMATION
app:1902025-03-10 15:37:58.382infogoveeLightManAdd() Adding Govee Air Quality Monitor Model: H5106 at 192.168.1.102 with Govee_192.168.1.102
Unfortunately there are no steps to take. The H5106 is not supported. Govee has not added it to the Cloud API and it has never had support for LAN API.
The only devices that support the LAN API are light devices so that really won't get you very far with that devices.
I have one as well and it would be nice, but Govee hasn't added it yet to be supported.
Well, 
. It was worth asking - thank you for the quick response!
i have led strip light H6159 for over a year and it has worked well with the intergration.. however, it now has stoped working via Hubitat but does through the Govee app.
the error log shows:
dev:1702025-03-12 22:58:44.765
error
groovy.lang.MissingMethodException: No signature of method: user_driver_Mavrrick_Govee_v2_Color_Lights_3_Driver_718.setLevel() is applicable for argument types: (java.math.BigDecimal, null) values: [50, null] on line 147 (method setColorTemperature)
anybody have any ideas?
thanks
That looks like you are using old code.
Please update everything through HPM and try it again. You may want to try to do a repair through HPM. Also make sure you are running the latest version of HPM as well.
I had to look back in the history of the code back to march 22nd of 2024 to have code that is even close to what could generate that error on that line of code.
thanks. i realize i have about 20 GOvee Drivers how do i know which one to use/pick?
how do i get around this when trying to update ?
also how do i know which driver to use for which Govee device ? other than the obvious ones. i am working various light strips, flood lights and ground lights
When you use the integration to setup a device it will pick the correct driver. It uses information from the Govee API to pick the driver.
That is a HPM Error. Try unmatching the app in HPM and then rematching it in HPM and see if that helps.
You can't really. The Integration will look at the device info provided by the API and then determine what is the best driver for the device. It does this by looking at the supported commands provided in the API. That isn't clear by the device itself.
so my issue and my fault, is i have manipulated them because a device didn't work so i tried changing the driver... this is true for several govee devices. do i have to delete the device then add it back to rest it ?
Well the easiest option would be to remove them and then reinstall them and let the integration figure out the best driver for it.
If you open the integration and click on the ? icon in the upper right corner you can also view the documentation. Toward the end of the document in Appendix A is a table that shows what driver has what commands. You could then review each devices data value for "supportedCommands" to the table to figure out what each device should have.
So i just noticed something that appears to have changed recently with the Cloud API. It looks like Sceneic Dreamview, and the various device group functions have now been added to the API. What it means is that know when the Cloud APi device list is retrieved it appears we get a list that includes a virtual device for those items. They come down as simple on/off switch devices. I will do some testing to make sure they are working as expected, but it may be nice for certain things like turning on and off a group of devices. Not sure how it will completely work since some of that stuff normally depends on Bluetooth to synchronize, but we will see. There is already a basic switch device available so it may already work, but i will try to fix any quirks for the next release.
1 Like
Has anyone run into any issues after a hub migration? I moved from a C5 to C8 Pro and have some issues with commands that worked previously throwing errors.
A lot were setup within Rule Machine and worked fine until I migrated. What’s weird is some commands work fine, such as On/Off or set segmented color. I also tried them through the individual device pages vs the custom command in RM and get the same errors.
I tried a repair on it via HPM but no luck. Would like to avoid reinstalling since I have a lot of automated tasks for these devices.
Devices are H7065 (spotlights) and H619A (RGBIC Light Strip)
Ex:
groovy.lang.MissingMethodException: No signature of method: user_driver_Mavrrick_Govee_v2_Color_Lights_3_Driver_1079.setLevel() is applicable for argument types: (java.lang.Integer, java.lang.Integer) values: [1, 30] on line 215 (method setColorTemperature)
org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_Mavrrick_Govee_v2_Color_Lights_3_Driver_1079.setLevel() is applicable for argument types: (java.math.BigDecimal) values: [100]
Possible solutions: lanSetLevel(float), setHue(java.lang.Object) (method setLevel)
Did the Repair through HPM not work, or did the repair works, but the issue remains?
Are these devices using LAN API or the Cloud API?
The repair completed successfully but the issue still occurs.
I’m assuming they’re using the cloud API as I never went through the manual setup outside of turning on LAN Control in the Govee app.
Basically everything was fine on my C5 yesterday and then the commands failed once it migrated to the C8 Pro. Just confused as to why a couple commands continue to work though.
Can you please open up the developer section of the UI, and then select the drivers icon and then open up the Govee V2 Color Lights 3 driver. Scroll down and copy out and send me what you see for the lines around 215. It should look something like this. The first line is on 214 of that driver with current released code.
def setEffect(effectNo) {
if (lanControl && lanScenes) {
lanSetEffect (effectNo)
} else {
cloudSetEffect (effectNo)
}
}
If the repair was successfull it should have worked as that re installs everything.
Also what version of HPM are you running?
You may want to try a Unmatch and then match again and tell HPM not to assume it is fully updated.
Well going into the driver menu seemed to present the issue - it looks like I have 2 versions of each v2 driver installed. One of which has a last updated date of 4/01/2024 1:54:34 pm while the other is 3/15/2025 7:33:44 pm. All of the devices with this issue are on the older one.
I went to the Device Info tab and swapped the type on one of the spotlights to the newer driver. Seemed to respond to the Set Level command that was not working before. Code on the newer version also matches on those lines with what you sent (where the older one is completely different, of course).
While I haven't tested all of the commands, I'm going to guess that's probably it. No clue how or why they switched to the older driver as I typically keep everything up to date (and they were likely on the newest version on my C5 before migration).
Seems like maybe something with the migration set the device type incorrectly. Either way, appreciate the help!
No worries glad to help.
1 Like
After preliminary testing with these new Group devices presented in the API it looks very limited.
It doesn't allow status updates to be received for the defined group and it doesn't restore the group configuration that was used last. It literally just turns the device on/off, or at least for now that is all it is doing. It is possible more functionality is coming, but that is all it is doing now.
I have a driver for this created and have already added proper support to the Govee Integration app to create the child device to control the group. It is a very limited driver considering what it does.
I think the biggest use case for this will be for those users that have several devices of the same type like a bunch of 4 or 6 inch can lights and want to turn them on/off together. In my case it could also be for H7075 Outdoor Lights.
This is also a way to help with API Rate limits for cases where a single call could be made instead of several to turn on/off a group of lights.
I will release this with the next hub firmware update. Allot is coming when that lands.
I was wondering if there might be a way to work around the limit of 40 DIYEffects. As you noted above there must be a problem with the API in returning all of the DIYeffects. Is there a way to access multiple groups or does the API only return the DIYeffects that are defined in the 'Default' group. I was considering organizing my DIYeffects in multiple groups and then possibly move them to default when I want to use them.
