The install went perfectly and I learned how bundles work. I wish everything was fixed so easily.
1 Like
I just published 2.0.24
Updates are:
- Added needed code to create a randomized offset for polling. This should help prevent Govee integrated devices from polling all at once. The offset be between 0 and the Polling rate set of the device.
- Upgraded the process to retrieve the Temp when using the getDeviceState method. This is in response to a change by Govee where temp values were standardized.
- Update the retrieveScenes2 to set scene values as part of it's routine.
- Updated appropriate drivers to use the new poll offset when device is initialized and remove the scene values that were added to retrieveScenes2.
If you are worries about spikey load on system from the polling with Govee a reboot of the hub will trigger the use of the offset for all govee devices.
1 Like
Hey guys I need some help. When i started the V2 integration I wanted a better way to manage the code and started to lean heavily on the Library functionality of HE. It is great in many ways, but it didn't have a good way for distribution. With HPM the only way I saw to manage libraries was in Bundles. The bundle functionality is kind of cool as it packages everything together in a kind of transparent way to pretty much everything on the hub. The problem is also that because it packages it all together it can get large and take a while to process the install.
I have started to experience occasions where I can't update the software through HPM on my prod hub, and i know others have been experiencing the problem as well. I have talked with the person that takes care of HPM and he advised me that the timeout value increase I mentioned above may not be doing anything as in his testing it appears to be hard limited in the firmware to 300 seconds or 5 min. He is waiting on news from Hubitat as to if that value can be increased higher but as of yet he hasn't heard either way. Because of the size of the integration and the fact it keeps getting bigger we are faced with two options.
- We can continue to wait until HE returns a firm answer as to if this timeout value can be increased for HPM to properly work.
- I can break out the parts to a more traditional use of HPM with the App and Drivers configured as such and then use a bundle just for the libraries that are needed.
The only downside to breaking it out would be everyone would need to do a matchup. Not optimal, but very doable.
What I need from users is some kind of grasp as to how much of a problem this is. I now frequently experience this on my prod hub, while by dev hub seems to not have this issue which I think is just because it isn't as busy. I also know I am a bit of an extreme case with over 30 devices. This also seems to be a bigger issue on updates vs initial installs.
I would love it if @support_team could chime in as well about the time out value for the HPM call that monitors the bundle install. Basically, if that value has a hard limit regardless of the value passed and if so could it be increased to something like 10 min instead of 5.
1 Like
i prefer just using hpm anyway vs libraries which dont seem to be highly used. and also makes it more complicated to piece the code together if i want to take a look.
Since you are asking for a suggestion, this works for my developed Hubitat applications via HPM that have multiple drivers and libraries based on the users configuration.
In my opinion, and just spit balling here, but why not ONLY have the required core Govee V2 libraries in the bundle and then designate separate Govee drivers in the HPM manifest json which we users can choose to have loaded down based on the Govee devices that we own when we use HPM! I only run with these files of yours below right now, as all the other device drivers in your large bundle are not needed for my specific Govee product.
I, because I like to keep things minimal (OCD), only have your Govee Application and kettle driver (right now) and only need these 3 library files to control the kettle:
Application Required for the Govee V2 Application
- Govee Integration V2 (Application)
Libraries Required for the Govee V2 Suite (based on #includes)
- Govee_Cloud_Api (Library)
- Govee_Cloud_Life (Library)
- Govee_Lan_Scenes (Library)
Driver Required for the Govee device I own and want to control:
- Govee v2 Kettle Driver (Driver)
So as I see it for one option to reduce the download and install load on HPM and hub, your required Govee_Integration_v2 bundle would only need to have the 3 required groovy libraries. The Govee Integration V2 (Application) would be specifically listed in your package manifest, would have a json value of "required": true. The other Govee device drivers would also be listed separately in the same manifest file and would have a json value of "required": false which makes them optional and the user would be prompted to select the drivers during the HPM installation depending on the specific driver(s) that matches with the Govee device they want to control.
If down the road, one of your users adds an additional Govee product, they only need to go into HPM and add the additional driver and rerun the Govee Application.
2 Likes
I think this is the same thing that @KurtSanders is saying, but there are some packages in HPM where you can optionally install certain component or child devices.
Maybe look at these and see if either of these help? [DRIVER] Zooz ZEN Switches Advanced (and Dimmers) or [RELEASE] IKEA Zigbee drivers
2 Likes
Ok guys thanks for the suggestions. Much of what you have brought up has crossed my mind.
I reviewed the thread and honestly there is no doubt it is a issue. I will look at bumping the version soon and deploying the a new manifest file to change the deployment method for non library items.
1 Like
I have updated the install manifest for HPM this does require an actions for each user.
At this time or at least before you install any updated I need you to go into HPM and perform a MATCH UP.
This is critical to prevent duplicate items on your hub. Performing a update prior to doing matching up will install duplicate copies of the Govee Integration app and all drivers. If you find that you have duplicate drivers and the app, you will need remove the duplicate items, perform a matchup again, and then repair of the install package.
This change to the install and management process as discussed in the above threads will provide a few items that should help reduce upgrade time and reduce failures due to the previously large bundle size. This should help reduce the upgrade time going forward as each piece of the install will be versioned to hopefully reduce the upgrade to only needed items each time. Overall this probably won't change the install time if everything needs to be touched, but when only a few items are touched it should reduce the time needed to just those smaller parts.
1 Like
I did the above and everything went perfectly.
should this let you uninstall the bits that are not needed now then?
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)
