Govee Integration V2

[mavrrick58]

@kahn-hubitat

does govee have a way to save diy/custom effects and thus share them with others..

Govee has a way to share DIY's through the Govee home app. It is simple as a user creates the Diy and then someone publishes it. Then as a end user you go to the DIY section of effects and click on the shared icon. Then a random list of DIY effects appear. You maybe able to do a targetd search in the explore section of the app as well.

The scene import options in the Govee integration v2 app are for LAN only scenes. It would require us to share the command code.

@kahn-hubitat

i have made some custom changes to the lan driver specifically to have a desclog option

If you create a push request on github or send me a PM i will look at adding it to the main code.

[kahn-hubitat]

sent pm but i dont see how to do a push request as for v2 .. the only think i find on github is the entire zip..

[mavrrick58]

I should probably create a beta of the Govee integration V2 breaks everything out. That would allow for code contributions. I will review your PM though and see about adding it to the larger base code.

[mavrrick58]

The Govee MMwave Presence sensor is back in stock if anyone is interested.

I just ordered one so i can get the integration of it setup with HE. Hopefully it will work nicely.

[mavrrick58]

So in prep for the mmWave presence sensor i took another look at the event based updates on Govee's new API. Govee did make progress and it is working now. So i have spent a littlw bit of time preping some code to help ingest those pushed updates via MQTT and it should be functional.

If anyone wants to try these updates before i fully publish the code go ahead and do a repaire through HPM for the integration. Once it is repaired you would need to open the App and then click on done to create the Govee MQTT listener device. At that point the new functionality should be working for you and devices like humidifiers and aroma diffusers should get their event messages posted to their devices.

This will be fully released in a few days after i get the mmWave sensor and can test out everything with it.

[mavrrick58]

Govee Integration v2 2.0.21 has been released for everyone to use.

The new features are as follows:

1. Descriptive logging was added to the Manual LAN API Driver by @kahn-hubitat.
2. Added proper support for Govee MQTT events to reach devices. This includes:
   a. A new Driver called "Govee MQTT Listener." As the name suggest this is a device that will connect to the new Govee API MQTT server and listen for events to be sent.
   b. Updates to drivers that support MQTT Events. These include the Aroma diffusers, Humdifiers, Dehumidifiers, Ice Makers, and Presence sensors.
   c. A new driver was created for the Govee Presence Sensor.

Once the update is installed you will need to do a few things to enable the MQTT Events.

1. Open the app and click on the button
   .
   The reason for this is it was found that this may help initialize MQTT functions in the govee cloud on devices if they didn't get setup earlier.
2. Click on next done a few times in the Govee Integration app until it closes and you are back to to the APPS page in Hubitat.

What will these events tell you?
Humidifiers/Aroma Diffusers/Icemakers - It will let you know when the device is out of water.
Dehumidifiers - It will let you know when the device is full and needs to be emptied.
Presence Sensor (mmWave) - Motion Active/Inactive, or Present/Not Present.

The lackWaterevent for Humidifers, Diffuers, Icemakers, and Dehumidifiers, don't reset. So they simply populate a value with the last time it was triggered. If you want to create a rule in RM based on it you should just look for the "Custom Attribute" to change as the trigger.

Enjoy everyone.

[mavrrick58]

One last thing for those that are developers. Per some of the conversation above with @kahn-hubitat I have reorganized some of the repo and created a section for the individual code items. This should allow for a user to create pull requests if you want to contribute.

[KurtSanders]

This post was removed by @KurtSanders since @mavrrick58 will be enhancing the V2 Kettle driver.

[mavrrick58]

You are not the only as I know of a few. I have looked through the code and approved it and am testing as much as I can now. I am looking at adding code so that basically if the needed new values aren't present to just populate some default values to ensure the driver keeps working. I think i have something that will work now.

That said one thing that just came to mind in the last few mins though is this may be to limiting. It only provides one time window to set the interval. I just updated the current driver to simply have a command to adjust the polling interval to whatever a user wants. This would allow someone to use RM to create rules around how they would adjust their polling intervals and it could be dynamic based on daily activities, day of the week, time of day, ect.

One example in my case would be something like when I run my wakeup routine to wake the house set the interval to something for a hour or so until i go to work and then turn it back to 0. This could even be applied across the entire Govee integration possibly as a way to minimize api calls based on home conditions if they can be predicted. I am going to think about that.

I have done allot of cleanup today on the drivers. Tried to improve their structure and make sure debug logging is working right as I have found a few bugs on some of the drivers. I have also moved some stuff that that should be standard across many drivers into the library code instead of the drivers themselves.

It could be very helpful if some folks added some input on this subject. Basically the question is what would be the thoughts behind being able to adjust polling based on criteria, and would you prefer it stay completely in the driver or be managed by lets say RM.

Govee really should move most of these notifications to MQTT as that would help reduced the need for polling as well. Since the MQTT functionality is fully working now it wouldn't be hard to add more devices to it.

[KurtSanders]

@mavrrick58

I think your recommendation of adding driver command methods of 'stop' and 'start/resume' in the polling drivers is be a much better and cleaner option. There would be no need for my version of your V2 kettle driver which only has start/stop times and stop polling.

Your recommendation would easily address a users' desire, if they so choose, to use Hubitat's WebCore or Rules to limit the polling to a variety of logic circumstances and not exceed Govee's daily polling max limit if they wanted a more frequent polling rate.

You can unmerge/rollback my latest github version and I look forward to your next release with the suggestions you made above!

Again, thank you for all your work on this application!

[mavrrick58]

I just posted Govee Integration V2.0.22. Here are the changes.

1. The MQTT Listener driver that was introduced in the previous release has been removed. All MQTT functions are now handled by the driver that receives the MQTT events.
2. Many functions were moved from individual drivers into the library objects. This should reduce the chance for coding errors not getting applied to all the devices.
3. Added command to Kettle driver to allow the Interval to be changed by RM ect. per work with @KurtSanders
4. Reviewed each drivers Lifecycle driver components. ie Update, Initialize, Configuration, and Refresh to ensure that that proper handling of functions and to ensure Debug logging turns off
5. Added Descriptive logging to the rest of the drivers per work with @kahn-hubitat

I am sure there are other changes that have slipped my mind at the moment. This has allot of changes though so keep that in mind.

If you installed the previous release. Please remove the Govee_MQTT_Listener devices from your hub as leaving it will cause application errors on the hub. It won't cuase a problem, but will generate errors. This was removed as it was looking as though the process I was using to listen to the Govee MQTT and then route it to the device was not very performant. On average each MQTT message was taking about 1.2-1.3 seconds to complete. The new process will reduce that time to around 100ms, or 12 to 13 times faster.

Because of the number of changes I will be checking back here allot for a while. Enjoy folks. Sorry about the unneeded Govee MQTT Listener driver in the previous release.

[jimhim]

@jimhim

That helped, thank you. Got it working in Rule Machine - One using V1, and the other using V2,

@mavrrick58 on a side note, from either your integration updates, or Govee back-end updates, all my devices are functioning now with V2 and I can now remove the V1 Govee drivers - just FYI.

[wiegout]

I have two LED lights of the H61731 sort. I am using the V1 drivers but figured this would be a good time to migrate these two last devices from the v1 to v2 API. Currently these are using the "Govee Lights, Plugs, and Switches Driver." I don't see a direct analog in the V2 drivers.

Is it Govee Color Lights Driver or 2/3/4? Looked in the thread and didn't see an obvious answer, so sorry if I'm being dense.

Thanks!

[KurtSanders]

@mavrrick58 Thanks for the updates. Your Govee integration work is very much appreciated.

Here are some observations with the latest Kettle driver and the associated library.

1. There is a log error from the Kettle driver when using the command 'Working Mode' and only sending a string parameter 'Tea' for mode, say from WebCore or Rules. This command method expects two parameters but will not validate a missing 'gear' number.

dev:1782024-03-26 06:10:37.238 AMerrorgroovy.lang.MissingMethodException: No signature of method: user_driver_Mavrrick_Govee_v2_Kettle_Driver_720.workingMode() is applicable for argument types: (java.lang.String) values: [Tea] Possible solutions: workingMode(java.lang.Object, java.lang.Object) (method workingMode)

I would like to recommend the following changes to the workingMode method for the gear variable if not provided to eliminate this error:

• Device: Govee V2 Kettle Driver:
• change to → def workingMode(mode, gear=0)
• delete line → if (gear == null) { gear = 0 }

2. The Govee V2 Kettle Driver attribute 'mode' is defined as numeric but the event value is not numeric. One cannot use RM to get the value of mode to determine current workingMode of the Kettle.

• Library: Govee_Cloud_API: def getDeviceState()
• change to → if (instance == "workMode") sendEvent(name: "mode", value: it.state.value.workMode);

3. Feature Request:

   • It would be great to have a new attribute added in Govee V2 Kettle Driver that would track the polling rate so that this numeric value can be used in RM or WebCore. I plan to use it when the Kettle's polling rate changes based upon other associated rules/pistons that change polling rate based on time, location mode, other hub events.

4. It would also be nice to have a new 'human readable' string attribute of the workingModeNames of the Kettle in a new Kettle device string attribute. This attribute would eliminate one having to create multiple 'If Then Else If' statements in WebCore or Rules to determine the workingModeName of the mode numeric value. Here is one example of how it could be added to the driver on the next update and added/called after each getDeviceState().

void setModeDescription() {
    def kettleWorkModeName = state.workMode.options[0].find{it.value==device.currentValue('mode')}?.name
    if (debugLog) {log.debug "setModeDescription(): kettleWorkModeName=${kettleWorkModeName}"}
    sendEvent(name: "modeDescription", value: kettleWorkModeName )
}

Again thank you so much for your contribution to this wonderful application.

[mavrrick58]

@wiegout

Is it Govee Color Lights Driver or 2/3/4? Looked in the thread and didn't see an obvious answer, so sorry if I'm being dense.

One of the differences between V1 and V2 is that V2 has as you pointed out more drivers that target the device features better then the V1. The V1 just had everything in one driver which ment that users had the ability to use commands that just wouldn't work for their stuff in some cases. When you setup the device in the Govee integration app it will select the correct driver. Then you will just need to go into the V1 device and select each integrated rule or app to point to the new one. If you are trying to just change the driver though it may work for the moment you may have issues as Hubitat keeps track of parent/child relationships. That device will continue to be related to the old version of the integration.

@KurtSanders

There is a log error from the Kettle driver when using the command 'Working Mode' and only sending a string parameter 'Tea' for mode, say from WebCore or Rules.

I will take a look at this later today when I get home.

@KurtSanders

def workingMode(mode, gear=0)

I will make this change for the next release.

@KurtSanders

It would also be nice to have a new 'human readable' string attribute of the workingModeNames of the Kettle in a new Kettle device string attribute.

I will look at add this as well for the next release.

[wiegout]

@mavrrick58

One of the differences between V1 and V2 is that V2 has as you pointed out more drivers that target the device features better then the V1. The V1 just had everything in one driver which ment that users had the ability to use commands that just wouldn't work for their stuff in some cases. When you setup the device in the Govee integration app it will select the correct driver. Then you will just need to go into the V1 device and select each integrated rule or app to point to the new one. If you are trying to just change the driver though it may work for the moment you may have issues as Hubitat keeps track of parent/child relationships. That device will continue to be related to the old version of the integration.

So I should delete and re-add these two lights?

[mavrrick58]

First integrate them from the V2 version. The apps are designed so they can run side by side. At this point you may want to check the devices page for the V2 devices to ensure that all of the expected controls are there and functional. There were a few devices that just simply didn't get all of their features moved to the new API used in V2. Now with the devices created for both V1 and V2 along with the functionality confirmed move all of your HE Rules and such from the V1 devices to the new v2 devices. Once that is completed simply open the device page for the V1 versions and use the remove option on the bottom of the page. If these are the last devices on the V1 instance you could also simply remove the Govee integration v1 and that will remove the devices as well.

[wiegout]

Got it. I forgot that you add these through the "App." Thanks.

[wiegout]

So one issue that has cropped up after moving all my devices to the V2 API: The space heater throws Java errors when trying to switch modes. Before I used to be able to switch the fan speed with mode 1, mode 2, mode 3. These now don't work. The device looks like this:

I suspect that the fan speed setting is more complex now, but can't figure out the right way to set it in a rule.
Actions in the rule:

Now throw Java errors:

Any suggestions?

Thanks!

[mavrrick58]

I do actually. You need to go into your rule do the following.

1. Change the rule to actuate workingMode now instead of Mode. This is the valid command
2. update the first variable to be "gearMode"
3. Add a second variable for the level of heating you want. It can be either "Low", "Medium", "High"

It should look something like this.

With the new API govee introduced the workingMode command which is used by pretty much every Govee Life product in some way.

The temp reading on the device will be fixed in the next release by the way.