That's all kinds of awkward to configure, but it works perfectly! Thanks for taking the time to make an example @mavrrick58!
I posted 2.0.23 of the Govee Integration
Thanks to help from @KurtSanders numerous improvements were made to how the Working mode is displayed to Govee Life products. He provided many improvements to the Kettle driver as well. He contributed allot to this latest update.
A bug was identified with the method to turn off Debug Logging for Govee Life Devices. That has been resolved now and debug logging should turn off as expected after 30 min.
Devices like space heaters that receive temp when their state is retrieved will now retrieve the correct temp. A needed conversion appears to no longer be needed and was removed.
The standardized Working mode command was removed as some problems were found in further testing that were going to make it hard to work across all devices.
1 Like
any update from govee on getting hardware fade implemented in lighting devices?
Thanks for working we me through many iterations to make sure that these new features work across all the Govee projects.
@mavrrick58 Your Govee Hubitat Integration work is outstanding!
I am having issues with HPM and the Govee V2 app so tried to do a manual update of the bundle and am not sure what I have loaded. I just downloaded the V2 bundle from GitHub and imported it.
I wanted to check the version of the V2 app and what I'm seeing is version info for V1 in the code. I'm confused. I even when to look at the code on GitHub and it looks the same.
I have been updating the V2 app using HPM since inception but it has disappeared from my HPM. It won't match up, Since the bundle import Its trying to match up my code to the V1 app.
I can install the V2 code from HPM but not match up or repair. I'm assuming if I install it will just give me another copy and then I'll have a mess.
Anyway, can you tell me what I have loaded? Here is a screenshot of part of the code.
I think on busy hubs the 300 second timeout value that HPM uses may not be enought.
My dev hub never has a issue, but my main hub lately has consistently failed. I changed the timeout value from 300 to 600 and it started installing again. I will post directions tomorrow about how to change the value manually in the HPM code. I will reach out to csteel to see if we can get the value adjusted.
The hpm install just pulls the bundle from my git hub repo so if you downloaded the bundle file under the current V2 folder you have the latest code. That first code page of info should be ignored. i need to ho clean it up to only show v2 data.
1 Like
If you go to line 3717 as shown in the image below and change the number from 300 to 600 then you will give it more time to complete the install. I changed it recently on my prod hub as it was having a hard time completing the install.
Thank you for the detailed answer. My problem with HPM isn't the timeout, though I did change to 600 and try, it's that HPM doesn't know that I already have the V2 app installed, even though HPM installed it at the beginning, and it won't match it back up. For some reason it wants to match up my V2 app with the V1 in HPM. I am not sure how HPM works but I think a file that it stores on the hub has to be messed up. I thought about it last night and the obvious fix is to delete HPM and reinstall. When I get a chance I'll do that later this week along with a database cleanup.
2 Likes
RE-Installing HPM won't help with this.
This has caused me to do a bit more digging and it does appear that for some reason the "Matchup" Function of HPM to the Govee Integration V2 doesn't seem to function. My guess is that it is some how related to everything being packaged in a bundle vs the app and drivers being their own objects.
I just completely cleaned off my dev hub and remove the Govee Integration from HPM. Then i did a clean install from my bundle file and tested the match up. What it found was what is shown below.
What it found was the Govee Manual Lan Driver which is part of the Govee V1 integration as well. Is that what you are seeing when you are saying it is matching to the Govee Integration V1.
Now the good news. Bundles are designed to be installed overtop of themselves. When a bundle is installed overtop itself it will simply overwrite the same objects. If you have Govee Integration v2 installed manually you can just install it again from HPM and it will overwrite the bundle that is present. You will not have any duplicate items show up. It also won't break your current install either.
My suggestion would be to do as follows
- Make sure you are running 1.9.3 of HPM then go into the code and update like 3717 as shown above to a 600 second timeout
- Go into HPM and run the install of Govee Integration V2 which should get you the latest information in HPM and it should ensure you are on the current version.
2 Likes
Thanks Craig. I am really curious as to why HPM just dumped the tracking of my V2 installation. It happened sometime between the last and most current update of the V2 app as I stay pretty current with your app.
I'll will do an install of the V2 app tonight and hopefully everything will be all matched up again
Thanks again.
1 Like
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?
