Govee Integration V2

Are they all at the same time. There is nothing in the integration that would allow it to go across devices and trigger actions like on/off ect.

Have you checked the Govee Home to see if there is anything setup in Auto-Run's that would account for it.

I just don't see how this is related to the integration,

I don't think it's the integration myself. I set up the logs for "info", if that's wrong, let me know.

I uninstalled the Govee app and reinstalled it. There's no schedules set. There is absolutely no Alexa or Home integrations. I didn't even push the devices over to them. Strictly Hubitat and Govee App.

If it happens again, I should be able to see if it's the API calling or hubitat.

Would be weird because I used a new API key and it's still did it.

From the screen shot above It looks like you are using the Cloud API. So that means the devices are getting commands from the Govee Cloud. Even when you submit commands through hubitat, they get sent to the cloud and then come back to your device. Do you have any setup for Local Lan Control?

Pick one of the devices on hubitat and open up it's preferences page. Turn on Debug Logging and click on "Save and Close". If you have devices that have "Local LAN Control" turned on you may want to do the same for the "Govee Device Manager" device. If you set something to Info that was probably for the Govee Integragtion app. That probably won't give you anything. That logging would help for issues with Scene extraction or installing devices.

What you are looking for is basically a command submitted to change to that given state, or was a poll done to get the device status that had the new state without it being submitted from the Hub itself.

What i suspect is you will see a poll executed that recieves the new state and updates the device with a event to change it. At that point check for Auto-Runs in the Govee Home app and probably change your password.

They turned on again. Unfortunately didn't see this so didn't capture the logs.

Gonna change password as suggested.

Any chance the info logs might be in your past logs? Filtering them by the Govee device might provide you with what you’re looking for. Alternatively, you can check the devices’ events to get a clue to what triggered the « on » event.

1 Like

Here's some of those logs for one device. The ON event happened at 3:41. I turned it off myself when I noticed them on.





Also seeing driver errors on another device

Unfortunately that doesn't help.

I need to be able to see the event that put in the on status which isn't there. I do see that after you updated the preference to enable debug logging the driver performed a getDeviceState() which gets the device current state and it did show it was on at that time. It didn't submit an event though because it was already in that state.

Now that debug logging is on we can get that information the next time it occurs

Just updating. Not going to jinx it, but I have nothing to report.

1 Like

6 posts were split to a new topic: HPM Error Occurred During Installation

7 posts were merged into an existing topic: HPM Error Occurred During Installation

I am so sorry I got stuck at another stage.
I put in API and if found my device but when I click next it stuck (picture)

How long did you wait. Were there any errors generated in logging?

I waited like 30 mins.
I repair the govee integration app also
Also reboot hub.

From the log,there is an error

That looks like you are trying to load the device as a LAN API device using the manual method. Put in your API Key and click on the "Done" button. Once that is done the option to setup devices with the standard method will be enabled. Go back into the app and use that method. You may want to click on the icon in the upper right with the ? In a circle to view the documentation for the Govee Integration v2

2 Likes

Thank you very much. Finally worked.
It was little confusion as to what to click next.

Thank you again, this community never lets me down.

@mavrrick58 any advice on how best to get this to do what I need it too?


Just looking at the nested if.

I want to turn on the light call a scene and make sure it's not bright.

However every night the level from hubitat seems to not get there. I end up with the light on with scene but it's always at 50%.

I have to use the App to dim them.

What are the values for retry intervals and number of retries.

How is it getting 50% as i dont see that anywhere in your rule?

If i am understanding your rule it look like you are turning it on, then 1 second later setting dim level to 10, then 1.5 seconds later submitting it to a scene. Each of those commands also involves device status calls so it adds up. I would take the On command out. By nature of setting a level or Scene you will be turning the device on. So the first thing I would do is remove the "on" command. That may help a lot. Then change your time between commands to 2 seconds. In my general testing, 2 seconds is the best amount of time between commands if possible. Seems to do the best at preventing failures or the device api getting backed up.

I did find one thing in the retry logic i am going to tweak to see if it may help.

Hey I made a small change to one of the routines for the retry logic validation.

If you update HPM to 1.9.8 and then enable beta for the Govee Integration you can download this patch and see how it works for you. Simply put the guardrail put in place for the deviceStatusWait wasn't following the values for the Number of retries and timout interval. It should do a better job of that now. This should allow more time for the commands to complete or be retried before everything is reset.

1 Like

I was already on the beta but updated and currently every time I set the levels it's working! Thanks.

I had the same question as there was nowhere I was setting 50 from but it's in the events as coming from the driver in the morning which is odd.

What I did notice before the update was I set a level with a transition of 2 seconds but it seemed like it was doing it over a long period, it would randomly change as if they were all queued up but stuck.

I did get a load of errors in the logs saying to many commands so hopefully your fix worked.

The fade function should be used sparingly and probably over min instead of seconds. It isn't a built in function in the api so it has to be done programmatically. That means allot of commands and done very quickly.

It will work fine to do something like simulate a sunrise or sunset over several min. But will likely cause issues if the transition is less then a min or two.

1 Like