SHWotever
More Govee woes - lights dropping in and out intermittently
Describe the bug Basically, connection is dropping or screen cap failing intermittently every 10-30 seconds, sometimes on one light, sometimes on another. It migrates around, but it's very distracting. I can see various errors in the logs, but have no idea how to interpret them. You may remember I was having issues with my five Govee lights and thought I'd solved it with improving the Wi-Fi connection, but it turns out either that was a fault on top of a bug or never the problem in the first place. I have used a mesh extender to ensure maximum signal strength and have exhausted all possible Wi-Fi fixes including QoS priority, static IP, changing band to least busy channel and so on. My router is a $600 ax11000 monster, the Govee lights have great signal strength and high priority on the network, and still it's happening all the time, so I'm now pretty convinced it's something else. Wondering if you could take a look. Thanks.
Simhub version Yes, latest.
Third party plugins Make sure to disable first any third party plugins (It's a critical step before reporting any freeze/performance/crash issues)
To Reproduce Just let the lights do their thing
Expected behavior A clear and concise description of what you expected to happen.
Screenshots If applicable, add screenshots to help explain your problem.
Log files SimHub.1.txt SimHub.2.txt SimHub.3.txt SimHub.4.txt SimHub.5.txt SimHub.6.txt
How to attach files : https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/attaching-files
Additional context Add any other context about the problem here.
Hi !
Seeing the logs it seems to run correctly, I spot capture errors but they are mostly expected (when a game goes in full screen, when monitor goes in sleep etc ... and seeing the timing it does not match your 30s or close recurrency
About prioritization at this level it should not be necessary and can make things worse.
Overall I can't seen any drops into the connection like the previous logs. I would feel like a conflicting instruction, the govee lights have no priority and will accept the commands from any software/phone which can lead to weird conflicts. I would check that the govee software is not running (both desktop or phone app).
Does it happens even on idle (out of the game ?) or when reducing the number of lights ? I wonder if it's not tied to a weird tining issue.
Yes, it happens in idle, and happens even if I reduce the number of lights to four, three, two or one, but it STARTED happening when I added lights four and five - that seems to have broken something. It happens with all Govee apps off or uninstalled, and only SimHub addressing the lights. If it were a timing issue, how might I go about looking into that?
Oh, and I've tried factory resetting the lights, removing them from the Govee app and reinstalling them, and power cycling them with a ten-minute off-time. Still the problem persists.
I've taken up the issue with Govee as I really have tried everything on the network side. As you said, there's no more connection dropping as far as SimHub can see, but the behaviour persists. If anything it's getting worse. If there's anything else you can think of that I could try, let me know. Otherwise thank you can feel free to close the thread.
Overall since the connection does not drop I was thinking just about an idle timer reaching on the light (UDP is a sneaky thing where packets can get lost, that said on a good network it should not). On the latest version I made each light update asynchronous so each one can continue to run even if one get stuck (the very first issue you had in the past) , not sure if it was caused by such delay.
I also reduced the forced delay when no changes is happening from 2000ms (2s) to 100ms (actually it never really stops feeding the light now) just saving a few packets in case it's static.
Overall that's all I can see except network dropping UDP packets for a reason (but it would also be visible in the logs as the light would also be lost and reconnect regularly which was not the case here.
I still feel "quantity" is one factor here (even not used they respond and gets scanned regularly)
Is there anything else you would try on my end? If not, we can close this and I'll wait to see what Govee says. It is weird that removing two or three of the lights from SimHub device list does not stop the behaviour, since it only started when I added lights four and five.
You can try the latest version all the little tuning I mentioned are inside: https://github.com/SHWotever/SimHub/releases/tag/9.4.14
That's fab. Will try when I'm back in my rig and let you know. Is there any way I can tip you? Not only do I love SimHub to bits, but you're just so helpful and such a pleasure to deal with.
https://github.com/user-attachments/assets/d9b072e1-0ed8-40d1-b6a3-23ea3cef131a
I have something to report! Okay, so the updated version you gave me still has the issue. However, I just tried the Govee desktop app for the first time, because it's the only other software that comes to mind that captures/reads the screen and outputs commands to the lights to match, and it works flawlessly, without the drop-out issue. It's terrible at it in terms of proper colour averaging and matching for the custome zones I set, and will only read the middle screen, so not a solution in and of itself. However, since the issue is not present within Govee desktop when it's doing the same thing, it must therefore be something to do with SimHub and how it's interacting with the lights, mustn't it?
I made a short video for you so you can see the behaviour yourself.
I noticed one other thing, too. When one light drops out (reverts to its default colour for 2-4 seconds) all the other lights are frozen. It's taken me a while to notice this behaviour as it's not immediately obvious. Not sure if that helps at all.
One final thing I've noticed when I'm using the Govee Desktop app instead of SimHub, the frame rate/polling rate is considerably lower than in SimHub. Maybe 2-3 samples per second? It's quite slow/lag, but way better than lights dropping out constantly. I wonder, if there were a slider or number entry field for the number of 'frames' or 'polls' (not sure the correct terminology here) per second SimHub is asking of the lights, I reckon tweaking that down a bit may fix it for cases like mine where a lot of lights are being driven. It's just a hunch based on the fact Govee's own app doesn't demand as much snappiness from its lights. What do you think?
Hi !
I checked the govee app, it must send at 30 FPS in the high performance settings, 2/3 samples per seconds are clearly showing something wrong. I will check if i can make all lights completely independent to see if it helps (currently status has to be retrieven for all lights at once and if somehow it locks it could be a cause of other lights freezing).
Alternatively have you tried to remove/bypass google mesh ? I've seen reports of very bad telemetry hangs on "consoles to pc" telemetry in the past, and I'm a little suspicious about it. Those 2/3 frames per seconds feels completely out of spec
Thanks. I don't use Google Mesh. I have a TP-Link AX11000 Archer, and one 'Onemesh' device added in the room with the lights to boost it up a bit – but I added the mesh booster only after experiencing this problem.
Okay, let me know then on the making them all independent thing. I'll test it to see if it helps if/when it's ready. Cheers!
I'VE CRACKED IT!!!
So, here is what was happening: The lights were switching between different networks (2.4/5G) as they pleased because both networks had the same password/SSID. I set up a guest network called 'Govee Eclusive' with a unique password, and changed the password on the existing ones so the lights can't access them (there's no 'forget network' function on these lights without a factory reset). I really didn't think it would work, but it did! Hilariously, I can still see the lights TRYING to switch back to the other networks occasionally. So will factory reset them when I get the chance. You've been a huge help here in narrowing down the problem. Without you, I would have been weeks on this, I'm sure of it. And Govee were no help at all. So thank you once again!
Amazing ! I'm truly happy to hear it, "unresolved cases" are always frustrating. So I guess now you are having a "normal" update speed through Govee and Simhub ?
Yeah multiple AP (access points) with same name can lead to unexpected behaviours. Mzsh network usually deals with that decently but as long as they are with a dedicated name.