Govee Integration V2

Well, I was finally able to uninstall (I saw the "remove" button in the app--duh). I reinstalled and the integration found the devices and installed them. However, still no scenes. From the log:

Is it set to use LAn API or Cloud API

What is this value set to. If it is true/on. it means your are using LAN API

LAN API is turned on in the settings in the Govee app.
I

I installed everything with "light" in it:


The installed Table Lamp 2 device is using driver Govee v2 Color Lights 4.

I saw that the uninstall/reinstall had logged me out of the Govee account in the app, so I logged in and clicked on "retrieve all default Govee scenes for all installed devices to local files," but still nothing in the device page.

LAN API was the key. It was set to "on" in the Govee app, but not in the device page. Once I turned it on there, the next effect/previous effect commands work, and after hitting "scene load," the scene names showed up.

Thanks so much for your help!!

Any chance of adding the new H1270 ceiling light to this integration? I can add it using the Govee integration, but it will not pull down the scenes. I get the following error:

With this log entry:

Looking at the Govee LAN integration page, it appears to be a supported device:

I've successfully added other Govee lights, but this one doesn't seem to load the scenes. It's possible I'm doing something wrong though...

LAN Control is on in the Govee app. Successfully added in Hubitat, with the Type listed as "Govee v2 Color Lights 3 Driver". Light is controllable, but no scenes are available.

Any help would be appreciated.

Does the process to perform the extraction work when you use the tap to run option instead of the newer method to pull all scenes.

What i suspect is the cause of the failure is related to how Govee passes information along about their scenes. It isn't consistant between devices especially when they basic functionality chnges. Like your ligh vs a curtain light vs a led strip may require different handeling when parsing and converting their scene data for LAN Control. So you have a few options.

First and easiest is to simply go into the preferences for that device and change the preference setting to control scenes from the cloud instead of locally. This will make the device pull the scene list from the cloud api and call scene activations from the cloud. Though this may not be prefered it ensures scenes work.

The second is we/i need to collect information and review it so i can update the extraction process to parse and convert the scene data properly if possible. To do this you can provide me with some scenes extracted tap-to-run method and then provice me significant log data from the new process. Another option is you could give me access to your API key so i can extract the data on my dev hub and work on the conversion. I would still need you to setup some tap-to-runs so i can extract them for comparison. I totally understsand if you don't want to do the second option where i have access to your api key, and wouldn't blame you. It is just about making it easier for me to get the data needed to do the conversion, and perform testing.

Another thing to be aware of is there is a chance even if i can get the process to work on most scenes some may still not work. Govee uses two commands for scenes. For local LAN API scenes only one of them works so you could end up still needing to use the cloud for scenes.

I have the LAN control on for this device, but that makes no difference for scene extraction.

I've been unable to get the tap-to-run scenes to download either. The "Extract Scene from Tap to Run" shows nothing. When I try to do it manually, I have issues as well. I suspect I may be doing it wrong, but I'm unsure of the data needed for the extract.

I'm not sure what information is required for the last entry. Obviously, my tap-to-run scene is called "Fire", but I don't know what "String provided by other user" is that you're looking for...

I have no problem providing you with access to my API key if it will make it easier for you. Especially if it helps other people in the long run. I realize you can't test every new device. Since I have it and can provide the access for you, it would probably be the easiest way.

Let me know if you have any other ideas...

Would this integration work with Modern LED Torchiere Floor lamp - Govee | Govee UK? I'm looking to replace an old floor lamp that uses a zigbee dimmer socket that has just gone kaput. (I have a Hubitat C-8 Pro)

Try going into the device, open up the preference tab, leave the option for "Enable Local Lan Contrl" turned on and turn off "Enable Local Lan Scene Control" and click save and close. This should get you working with scenes. Until I get the process figured out for the extraction.

The screen shot is from the option to add manual scenes. That isn't the option to extract the tap-to-run. Try reading the documentation for the steps to perform the extract using the tap to run. The link is in app.

If you are cool with me having the API key just send it to me in a DM and I will start to work on it. I will only configure it while I am testing.

The integration will generally work with it. Nothing in the integration is really device specific. The above issue with LAN API scenes may be a issue though as I havent actually tested that specific device. That said, similar to the situation above it just means i need acces to a example device to help provide examples of scenes to decipher the extraction process.

Yes. The problem is, my Govee app doesn't look at all like the screenshots on the instruction page. Nor can I find the preference for local LAN scene control. I've made the requisite Tap-to-run scenes, but I get nothing when using the extract command on Hubitat.


The only LAN Control setting I can find

The Tap-to-Run scenes

Hubitat return after selecting "Extract scene from tap to run"

I'll DM you the API key

Thanks

I've been seeing ton of these errors. it's coming from the Govee v2 Device Manager:
groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Long#minus.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
[class java.lang.Character]
[class java.lang.Number] on line 296 (method parse)

I've done some searching and googlin' and AI'in but can't really find a rhyme or reason why i'm getting this error..

Anyone here have any ideas??

Ok i will see what I can figure out. What hub firmware are you on.

firmware: 2.5.1.167

and this is another error that is constant:
groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Long#minus

That is clearly a bug. Sorry about that.

I have posted a hotfix to the repo. Just go into HPM and do a repair to get the fix until i publish it more formally.

Simply put, it was related to the added ability to turn off stat collection. That was added just a couple of revisions back of the Govee Device Manager. It was part of my activity to try to reduce load of the Govee Integration. Unfortunately in doing so i messed up the variable scope and so it was generating that error. A HPM repair should fix it now though.

I have found another error i am chasing down as well. Strangely i am only seeing it on my dev hub though and not my prod hub.

UPDATE -- I figured out the second problem I was working. I posted a small change to fix the issue with @steelz1 identified and a issue with the Socket driver with multisocket/LED components. Enjoy

@mavrrick58 I think it's safe to say there is not a single person that uses your Govee integration that would question or chastise you for that small oops. It happens to the best of us. But regardless, I'm happy that I was able to at least see the error and provide my logs. Thank you for the very very quick hot fix. As always you are the master and we all greatly appreciate everything you do to keep your Govee integration working better than any other integration I've used to date.

Thank you again, and have a wonderful weekend.

@mavrrick58 I'm not sure if this is something you've been looking into, or if it's just something happening with my Govee integration on my hub, however, I wanted to share it nonetheless just in case others are seeing it. I think between habitat and their updates and Govee making changes to their system. Things are going a little wonky.

The plug model is:H5083, and here's the error code that I'm getting from one of my Govee plug-in modules. (side note about posting on this forum: I missed the option where you could have hidden text behind a title. I can't seem to find it anymore. It looks like it was replaced by a footnote option. Anybody know what the syntax is or remember what I'm talking about?)

Anyways, here's the log snippet:
UDP Response -> Error Type: LAN_TYPE_UDPCLIENT_ERROR Error Message: UnknownHostException: N: Name or service not known

dev:18432026-09-02 08:45:04.617

error

Got something to parseUDP

dev:18432026-09-02 08:45:02.628

error

UDP Response -> Error Type: LAN_TYPE_UDPCLIENT_ERROR Error Message: UnknownHostException: N

dev:18432026-09-02 08:45:02.612

error

Got something to parseUDP

dev:18432026-09-02 08:45:00.785

error

UDP Response -> Error Type: LAN_TYPE_UDPCLIENT_ERROR Error Message: UnknownHostException: N

dev:18432026-09-02 08:45:00.770

error

Got something to parseUDP

dev:18432026-09-02 08:44:58.721

error

UDP Response -> Error Type: LAN_TYPE_UDPCLIENT_ERROR Error Message: UnknownHostException: N

dev:18432026-09-02 08:44:58.707

error

Got something to parseUDP

dev:18432026-09-02 08:44:56.502

error

UDP Response -> Error Type: LAN_TYPE_UDPCLIENT_ERROR Error Message: UnknownHostException: N

dev:18432026-09-02 08:44:56.495

error

Got something to parseUDP

dev:18432026-09-02 08:44:54.498

error

UDP Response -> Error Type: LAN_TYPE_UDPCLIENT_ERROR Error Message: UnknownHostException: N

dev:18432026-09-02 08:44:54.491

error

Got something to parseUDP

dev:18432026-09-02 08:44:54.301

error

UDP Response -> Error Type: LAN_TYPE_UDPCLIENT_ERROR Error Message: UnknownHostException: N

dev:18432026-09-02 08:44:54.294

error

Got something to parseUDP

I did go into HPM and run a repair on the Govee integration suite. We'll see if that makes any difference in the meantime.

I am working with a new lightstrip (a H61F5).

A couple things:

  1. When I set the level to 0 (I was trying to dim to off) it fails. Nothing below 1 works in the level field. And 1 leaves them on, albeit barely. (I get a "command failed" error in the log).

  2. I wanted to delay the dimming (5, 10, 15 secs, whatever). It ignores that time completely and just does the dimming (up or down) immediately.

Thoughts?

Thanks,

What is the driver the device is using?

What was the state you were trying to dim to 0 from? Was it in a CT or RGB or a effect?

Were you doing this from the device page, or from a app.

Can you share with me the Live Logs for the device.

I tested a y light a few different ways and it worked fine using setLevel (dimming) to 0.

What do you mean by delay the dimming. Nothing in the code is intended to do that. It does have a fade over time ability. Is that what you mean? If so, that is a LAN API only function. Is the device using LAN API? What are the preference settings for "% change per interval" and what time interval are you trying to use? Fade over time isn't a native function and so the hub has to tell the device to dim on intervals and the Govee devices seem to have issues if those intervals are more frequent then every 2 seconds. You need to adjust the prefrence to work with the time interval you want to use to make sure that happens. So if you want to fade over 30 seconds from 100 to 0 it needs to at most submit 15 intervals and so the change per interval is 100/15 or 7

The driver is "Govee v2 Color Lights 3 Driver".

Using the "Device" page, "Commands" tab.

In CT mode,

If I enter "0" for the "Set Level" level, it does nothing.

If I enter a non-zero number there and a "Duration" > 0, the duration is ignored.

Same thing with the "Set Color Temperature" with the "Level" and "Transition Time" fields.

When I changed to RGB mode, it accepted and sorta-properly handled the "0" level (the lights went totally dark, but it left the switch state "ON") and it still ignored the duration times.

Thanks!