Not something i normally use was just trying to get it to work at the time so tested to see if it was needed.
Too many events alert.
I keep getting alerts stating that Govee v2 device manager is having too many events. I've searched around this topic and cannot find any info regarding it. Poking around under events I see that something called avgTIME comes back with a value of zero every second. Any thoughts on how to fix this? My hub performance hasn't been great since I've added more Govee devices.
The avgTime event is intended to show a performance metric fow how well the Govee device Manager is processing incoming lan api responses and MQTT messages fron the Govee Cloud. Basically a way of keeping an eye on how well the hus is handeling the load. The number is in miliseconds. The more devices you have the more frequently it would be updated.
- What version of the hub do you have c7, c8, or c8 pro?
- How many govee devices are we talking about and are they Lan API or Cloud API?
- What are your polling values if mostly lan Api
- What is the device scan value set to on the Govee device Manager.
Is that a exaggeration for effect or the real number. It may be something is set to aggressively. It seems hard to believe there is a valid reason for that frequency. That means the hub is getting data back constantly feom devices and passing it to the Govee Device Manager.
First of all, great work on this integration. Works very well.
Question on whether something is possible. When initiating a Govee scene with "Set Effect", is it possible to change the color palette used? For example, the scene effect "Fire" has 10 different color palettes you can choose from in the app. However when triggering the effect from the integration, it always uses the default palette (#1). Is there any way to change this or is it a limitation of the API?
- Using a C7
- Currently down to two (a kettle and ice maker), I have over 10 that I would like to add back.
- Currently no Lan devices
- I do not know where to find the device scan value.
That was no exaggeration. Something is hammering my hub.
Are you using the LAN API, or Cloud API for the device?
The cloud API as far as i am aware does not have a color pallet parameter.
The LAN API just submits a command directly to the device. If you can set the color pallet and perform a scene extraction you could potentially save that scene command and call that instead of the normal effect number.
Do you have the Hubinfo driver on your hub by chance. How is your memory on the hub?
That shouldn't be a problem. I have over 40 devices connected. You should be able to add them all back with no problems.
This makes it even stranger. If you have no LAN API Devices then you shouldn't be getting beat up by messages coming into the parse routine.
Open up the "Govee Device Manager". Click on the preferences tab. You should see something l ike what is below
Here you have a option to set the scan rate. It is in minutes though so that kind of kills my concern already.
Please turn on debug logging on that page and click save and Close. Go to the Live Logging page and capture just the logs for the "Govee Device Manager" and either post it here or DM me.
I was using the cloud but switched to LAN and did a scene load as you suggested but still used the default parameter. Guess I'm out of luck.
Follow up question - in the current state of the device in the scenes section there's an entry "9054":{"name":"Fire","paramId":15141}. What does that paramld:15141 part mean?
Thanks for the responses.
Go into the Govee Integration app and then go into the "LAN API Scene management menu". From there click on the button shown below.
Lastly go into the device and turn on the Local LAN Control switch.
You when you save that it should initialize the scenes from the scene file created on the hub in the first step above. That allows LAN API control. Then you will want to fallow the steps to perform scene extractions using tap-to-run method for the different color pallets.
@mavrrick58 HPM keeps saying there is a update but every time I update or repair it still says there is a update?
I spent a couple of hours reading your documentation and following the procedure as best I can (the Govee app seems to have changed for creating tap-to-run since the documentation was last updated) and named it "Hubitat Scene". After doing "Extract to scene from tap to run" here are the resulting:
Single entry in the DIYscenes file
[
{
"H7075": {
"1001": {
"name": "Fire",
"cmd": "[\"owABBwIEGiAAAAECAUElA4AUFHw=\", \"owEC4woBtQb/BwDtAwD5ABogAC4=\", \"owIAAQIBMhoBABQUAoAUAcMG/yc=\", \"owMVAOIAAIAAHTAAAAECAUQAALw=\", \"owTaCgoCABQCuwb/5Qb/AACAALc=\", \"owUAgAAaIwAAAQIBTRsDyRQUAoM=\", \"o/+AFAGSBv8VAPIAAIAAAAAAAMU=\", \"MwUETykCAAAAAAAAAAAAAAAAAFY=\"]"
}
}
}
]
There's a corresponding entry in the LanScenes_h7075 (for the device in question) as follows:
[
{
"h7075": {
"101": {
"name": "Forest",
"cmd": "[\"owABBwIDJgABAAoCAf8ZAbQKCtk=\",\"owECyBQF//8AAP//////AP//lBI=\",\"owL/ABQBlgAAAAAjAAIDAgIB/wE=\",\"owMUA8kBAQH3CgQE/wC0/wBH/44=\",\"owT/4/8AAAAAAAAAACMAAAAEAmE=\",\"owUBhRQDzAEBAuoUBAT/ALT/ALE=\",\"o/9H///j/wAAAAAAAAAAAAAAAAc=\",\"MwUETSkAAAAAAAAAAAAAAAAAAFY=\"]"
},
"102": {
"name": "Aurora",
"cmd": "[\"owABBQICIwAAAAMCAZw7AQAAACI=\",\"owED8jIECP+qCP8VAAD/2y/+Ayw=\",\"owIAgAAAAAAmAAAAAwIBrhkB+ks=\",\"owMAAALtFAVk/ggAAACLAP8AALg=\",\"o/8ACP8VAADMAAD/AAAAAAAAAI0=\",\"MwUETikAAAAAAAAAAAAAAAAAAFU=\"]"
},
"103": {
"name": "Fire",
"cmd": "[\"owABBwIEGiAAAAECAUElA4AUFHw=\",\"owEC4woB/zkHBwDtAwD5ABogAKM=\",\"owIAAQIBMhoBABQUAoAUAf9HB6I=\",\"owMVAOIAAIAAHTAAAAECAUQAALw=\",\"owTaCgoCABQC/0AH/2oHAACAAMM=\",\"owUAgAAaIwAAAQIBTRsDyRQUAoM=\",\"o/+AFAH/FwcVAPIAAIAAAAAAAEE=\",\"MwUETykAAAAAAAAAAAAAAAAAAFQ=\"]"
},
When I switch the device over to LAN and do the "Scene Load" from the device driver, nothing changes. I tried to change the name field in the DIYscenes file and redo the scene load (not that I know what I'm doing...) but no change. Any suggestions or is this just a limitation of the API?
I have been getting these lately but I have no idea where they are coming from.
The times are odd like 10:30 and 18:30. None of my automations run here except lighting pistons.
I do have 4 Govee bulbs that I have been using for the last month and it seems there are 4 null log lines each time. The bulbs have been working fine though.
I have this in the Govee app as well:
I will take a closer look at that soon.
Do you use something like Maker API, Google home, or Something that talks to the hub from a external system via the cloud.
That is very strange. Seems like your integration has 4 devices that are partially setup somehow. Something isn't right. I would suggest you remove the 4 devices and the integration and start over. I don't know how you you would get a device that is null on that page.
I only use Maker API for cloud access to my 3 locks.
So those 4 Rec Room devices shouldn't be in the dropdown if they are integrated properly?
I'll reinstall if this is the case.
Quick observation. My bulbs don't have the same name in the Android App as they do in HE as I renamed them to a better naming convention after the fact.
Could this be it?
I have these working fine:
That shouldn't make a difference. Does the device list stilll show null in the Govee Integration app.
Sorry i ment on the Govee Integration v2 app like you showed above. It showed 5 devices but then showed all of their names as null
Yes strange. they all have a proper name as devices but null in that one line.
I'm guessing the 5th device is the Lan integration (which I have no devices)?
I did the Manual "add a device" and nothing seemed to change.
Still have my null friends but devices are fine in Device tab.
I'll do a full delete in a few days as I'm going out for town in an hour.
PS:
I have Debug on and I get quite a few of these
I will perform some additional testing as well. I don't expect that should happen.
Ok i have spent some time on/off trying to dig into this. I don't really have a good answer but there is no doubt something is off with your setup. Here are the observations
- Your devices are showing "null" for all 5 devices in the Govee Integration app.
a. This shouldn't be possible first. That list is created by the system at run time. What it does is pull the child devices for the app and the "Govee Device Manager" and then displays the label there. That is pased during device creation process based on what is given by the Govee API.
b. Once the device is created you can change the label in the device preferences. Even if you just blanked out the label and then only updated the Device Name then it would just be blank and not null based on my testing. You can see the example below
- The "dev:null" in the log entries from your post 2012 are confusing as that should point to the device involved. The fact it says null indicates the device in question is corrupted in some way. Simply put it shouldn't be null ever. It would be interesting on those entries to place the mouce over the "warn" image and see what the URL is you are directed to.
- The errors you mentioned in your last message may not be a suprise considering the other issues. That could be expected, but not harmful, if the logic to that prevents already created devices from being submited to be created again failes for some reason. Considering the other strangeness you are seeing i wouldn't be suprised if that was the case.
By chance did you first install the built in Govee Integration and then just switch the devices to my drivers after they where already created? I am just trying to figure out what is unique about your setup becuase i can't seem to reproduce it. Also what hub version are you running?
