Unfortunately, not the way i think your thinking of. Technically every driver is needed for the Integration so there are no unneeded drivers to be removed. For your individual use maybe that is the case, but it isn't good for the integration to have drivers missing.
I may need to redesign the whole device add process to change this to allow drivers to be missing. That assumes I can create a progomatic way to catch if the driver is missing durring device setup and then notify the user of the situation.
The reason is right now the device add process searches the govee provided cloud data for the device selected and submits the command to add each device with its appropriate driver. It is just the way the Hubitat method to add devices works. I guess I could work in a routine to check if the driver is present, but that could add a fair amount of complexity into a fairly already complex routine. Then i need a way to notify the user what drivers are needed.
Though i know some folks only want to see drivers for devices they use the reality is the additional resources used to keep the extra drivers loaded is minimal. Most of the code for all the drivers is in the library codes with the exception of device specific stuff like metadata, avaliable commands, and device specific methods.
I will look at trying to see if i can figure out a way to do it, but it is far from a simple package manifest setting. Please realize i need this to work for everyone at all skill levels in a way to prevent/minimize the chance for it to just error out.
So 
in mouth. It is amazing what you can do once you put a bit more thought into it. My big concern was finding a good way to identify the drivers that were loaded. I found some code that does it. Already managed to tweak it a bit and got something that will pretty much allow the device to validated prior to actually doing the add. Next code drop of the integration app will include this. I will change the package manifest at that point to allow all drivers to be optional. I still recommend loading everything, but this will at least allow those that don't want to to remove them from their setup and prevent breaking errors from occurring.
I may still change the method that is used to add the devices though as it looks like there can be room for optimization.
1 Like
I just updated only the Govee Integration app to 2.0.25 and updated the install manifest used by HPM. Because just the Integration app was updated the upgrade will be smaller then normal 
The changes allow the following.
- You can no manage which drivers you have loaded during install
- Now if you try to install a device that needs a missing driver a log message will be creating telling you which driver is needed. This will not cause the rest of devices to fail to install.
- Now you can uninstall drivers from HPM if you decide you don't want them installed.
Be careful about adding/removing drivers outside of HPM as it caused me a bit of a headache getting my install back in a good state. If you already matched your install with all of your drives and then removed some of them HPM may not be happy after this change. You may need to un-match the Govee integration in HPM and then match it up again to cleanup HPM's config.
This changed touched every devices routing in the device add process. If anyone has any issues adding devices please hit me up asap so i can look into it and resolve it. Thanks.
1 Like
Great that worked and was much faster!
Question what the difference between the RGB 3 and 4 my devices are on 3 should I move them to 4?
The difference is related to the supported commands. You dont want to change it from what is selected during setup because the device add process reviews what commands that are supported and selects the appropriate driver.
The only exception to this could be if you had installed a device some time ago before i added the dreamview command. That command hasn't even beed added to the documentation yet. If your device can be a dreamview sync controller for a movie or music mode changing the driver to the Dreamview sync variant will enable that command.
I will review the code later and see about building a matrix that explains what drivers support what commands. I would of loved to use more descriptive names then just adding 2,3,4 to the name but the name was already getting stupid long.
| Name |
On/Off and Brightness |
Color Temp |
RGB |
Segement Brightness |
Segement color |
Dreamview |
Notes |
| Govee V2 Color Lights Dreamview Sync |
Y |
Y |
Y |
Y |
Y |
Y |
|
| Govee V2 Color Lights 3 Driver |
Y |
Y |
Y |
Y |
Y |
|
|
| Govee V2 Color Lights 2 Driver |
Y |
Y |
Y |
Y |
|
|
|
| Govee v2 Color Lights 4 Driver |
Y |
Y |
Y |
|
Y |
|
|
| Govee v2 Color Lights 4 Dreamview Sync |
Y |
Y |
Y |
|
Y |
Y |
|
| Govee V2 Color Lights Driver |
Y |
Y |
Y |
|
|
|
|
| Govee V2 White Lights with CT Driver |
Y |
Y |
|
|
|
|
|
| Govee V2 White Light Driver |
Y |
|
|
|
|
|
|
| Govee V2 Galaxy Projector |
Y |
|
Y |
|
|
|
Matched by model number |
Hope that explains the driver layout for lights.
1 Like
I just update the integration again.
I updated the Main app to v2.0.26 which includes a few changes manly in optimization.
- Updated several variables to function at a different scope. This will help with certain functions including device add/create
- Update the device add process to be less system intensive. This was enabled by some recent changes
Driver "Govee v2 Color Lights 4 Dreamview Sync" 2.0 released
This is simply the normal Govee v2 Lights 4 driver with the ability to utilize the Dreamview Sync command. This will allow such devices to activated with movie/music dreamview sync and control devices connected from the Govee Home app.
Hey, I am trying to add a couple of H61E1 light strips using the lan option and keep getting an unexpected error has occurred trying to load the app. Check Logs for more information. When I check the logs this is what is shown.
"com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'Govee Manual LAN API Device' in namespace 'Mavrrick' not found on line 1108 (method deviceLanManual2)"
C-8 Pro running 2.3.8.139. Using v2.0.26 of the app.
Thanks.
That error is saying you are missing a the driver "Govee Manual LAN API Device" Please make sure you have it installed.
In one of the recent updates you were given the option to install only the drivers you need/wanted. Please make sure that as part of the install you have the Govee Manual LAN API Device Driver. If not please install it from HPM.
Not sure how I missed it but that was the issue. Everything working now. Thanks for the quick reply.
Now I am having another issue. I was able to add 1 set of lights but when I try to add another I get.
Error: A device with the same device network ID exists, Please use a different DNI
Log shows: java.lang.IllegalArgumentException: A device with the same device network ID exists, Please use a different DNI on line 1108 (method deviceLanManual2)
By chance dos you use the same IP address the second time? The DNI is derived from it.
If you didn't i will take a look in a bit.
I just reviewed the code and it appears one of the recent changes did break that small routine. I will see about releasing 2.0.27 soon with a fix for this.
Part of it is already done as i was working on more optimizations and one of the problems i see i fixed earlier today. I just need to make sure there isn't more in the manual device add routine to fix.
If you don't mind me asking why are you going this route instead of the regular install and enabling manual control on the device. This will limit you control options if the device is able to be installed that way.
I am not sure I understand the question of this route vs regular install. What am I missing ?
The Govee Integration's main device setup procedure uses the Cloud. Then once the device is setup you can open the device in HE and set it to use control over the LAN. This requires you to get a Cloud API from Govee first though and to enter it in the integration.
Based on what you show above you are taking the alternate method to install a device without cloud access and only local control. This was designed for users that either have devices that dont work with the cloud API or dont want to have the cloud connected at all.
The key is this second method has some limitations. Mostly it only works woth light devices and it has no way to get device updates.
I would suggest you try to request an API Key from Govee and then install the strips with the main method.
@jedwards0087
2.0.27 is now released and you can download. Two things were adjusted in it.
There was clearly a problem with the Manual LAN Device add. That has been resolved. You will want to remove the any devices added between 2.0.26 and 2.0.27 of the integration app.
I removed some optimizations that were added in the previous release. Upon further thought they put additional burden on the hub in a different way and as such i chose the cost wasn't worth it.
This is ongoing attempts to optimize the code so hopefully the integration will gradually take less and less resources.
@jedwards0087 let me know hot this goes for you after the update. I apologize for the trouble.
Thanks for the clarification on the install methods. I am using the strips on some built-in shelves and really only use one color so I went with the local only option.
After installing the latest version everything is working great. I was able to add both light strips with no issues. And no need to apologize for issues. Without community developers like you this home automation stuff would not be as much fun. Thanks again.
1 Like
I just wanted to pass along a few recent observations going on in the Govee world. If you have been waiting for more Matter devices you will be pleased to know one new Matter device just got released and another is on the way.
The just released Govee Lyra Smart Lamp 2 is Matter enabled. The device is a upgrade from last years v1 and now puts out 1780lmns with additional light effects around the bottom.
Govee also just started a their Trial for a new Fan device that will support matter as well. Generally speaking it can be anywhere from a few weeks to months after this trial for the product to go live so that is on the way as well.
Unfortunately I just received the upgraded new Lyra Lamp Pro and it doesn't support Matter, but is a fantastic otherwise. Put out more light then even the new v2, has a illuminated base, a speaker in the base to either be white noise maker or a Bluetooth speaker, and the light component can have it's angle turned easily. It is a really nice device. For a short time there was a $70 discount to bring the price down to $149. It expires today unfortunately. use code "LampPro" in the Govee Store to use it
Does the Integration V2 support the Govee TV backlight (H6099 (the lite), or H6098 (s3)?), at least for basic light functions such as on/off and maybe brightness?
Backstory: I got a backlight for my sister, and noticed that it doesn't turn off well, as the camera can pick up ambient light, and so the LEDs stay on (albeit very dim). I did a (weak) amazon routine to turn off the backlight at a certain time of day (midnight) so that it wasn't on all the time.
Other than that, the device was amazing, and was thinking of getting one for myself... but, I'd want it to turn on and off with my TV (based on TV power consumption), so, I'm hoping the device is supported by the V2 drivers...
I'm sure I can find some other way to get it if necessary via Google Home (virtual switches and what not), but, having the direct access from Hubitat would be ideal...
Is the backlight part of the consolidated API?
Have you tried to add it to the integration?
I have the 2 of the T1 H6199 kits and 1 of the T2 H605C kits both of which are supported. There is a history of these items being added to the integration. That said i just looked at the supported device list and neither of the model numbers you provided appear to be on it. That doesn't mean the T3 kits will not work though, just that they haven't been put on the list. There are allot of stuff that isn't on it but work.
I would suggest you get the API Token for the account with it and then try to add it. If it shows up then it is available. The integration will then look at the commands and add it with the right driver. If it doesn't show up with the V2 integration you may want to try the V1 integration just to be sure.
I have my kits setup to use power reporting plugs to know when the TV's are on and then based on power draw will turn on the T1 or T2 kit. I look forward to hearing how it is goes.
1 Like
FYI to anyone with a with a MQTT device
I have noticed MQTT being very unreliable in the time since I released the driver. It seems to work sporadically and then fail for a time. I suspect this is related to a limitation on Govee's side. I am working on a way to work around their limitation, which will likely involve bringing back the MQTT Listener driver.
I suspect the limitation is around how many connections can be made to their MQTT server in a given time. Bringing back the MQTT Listener driver will allow us to use one connection for all integrated MQTT supported devices. As of right now I have it working, but it isn't very performant. So trying to come up with a good way to improve responsiveness.
