thanks for the link! it didn't show up
...not one to give up easily lol
I used HTTP Toolkit to capture traffic between the Android app and Govee and see that it's using an older(?) API call to get this device
https://app2.govee.com/bff-app/v1/device/list
{
"status": 200,
"message": "Success",
"data": {
"devices": [
{
"deviceId": 34298501,
"sku": "H5109",
"deviceName": "Pool",
"deviceExt": {
...
"lastDeviceData": "{\"online\":false,\"tem\":2915,\"hum\":0,\"lastTime\":1754059800000,\"avgDayTem\":2915,\"avgDayHum\":0}",
"deviceSplice": "{}",
Anyway, @mavrrick58 sorry if this isn't related to this app/driver. I figured you'd know the most about anything Govee related. I did try installing the V1 app and it didn't see anything either. But, at least it seems like it might be possible to capture the temp..
So for the most part this integration works with the official Govee API's that either uses their Cloud or LAN API. That endpoint is not part off that.
I am familiar with the host involved with that call as I use 2 endpoints. They are used as part of the processes to extract scenes. I also believe those endpoints are part of the AWS infrastructure Govee uses which brings other complications with it.
That said I have never used that endpoint for devices. I am not sure it would be a good idea considering it likely provides allot of un-needed info if i remember right. There is also the fact that as this is not a published API it could change at any time if Govee wanted to.
It seems like the Lan Control Function only works with On/Off and set brightness... i try to do anything else related to scenes/snapshot/color etc, nothing works
I am using the V2 Govee Integration, Product Model H6076
anybody have any idea why?
The LAN API only supports on/off, set brightness, set color and set color temperature. Depending on what driver your are using it will either not have those options, or it will fall back to the cloud to use them.
Do you have any logs showing a error?
I just went through all of the LAN API functions on my test device and they all worked. Please let me know what driver the device is ussing?
I have the H6099 (Govee TV Backlight 3 Lite) and the H607C (Govee Floor Lamp 2) both using the Govee v2 Color Lights 4 Dreamview Sync driver. I have the Movie Watching DreamView setup in the Govee app, but I cannot turn it on via the Govee Intergration on either device. I'm not sure what I am missing as I simply tried toggle the DreamView command on/off and nothing happended.
Can you tell me where to turn on the DreamView sync so that when I'm watching a movie, the DreamView turns on or am I missing something else?
I think I figured it out. I have the H6099 (Govee TV Backlight 3 Lite) uses the Govee v2 Color Lights 3 Driver driver and the H607C (Govee Floor Lamp 2) uses the Govee v2 Color Lights 4 Dreamview Sync driver. The TV Backlight 3 Lite is the Sync Center and only it needs to be turned on, as the Floor Lamp 2 will follow.
I see that whatever is connected to the Sync Center cannot be controlled individually.
You are right in that the Dreamview toggle in Hubitat turns on and off the Dreamview feature at the Dreamview enabled device that is functioning as the Sync Center.
I am a little concerned about the mention of the driver and that it changed from the first post to the second. The Integration app selects the best driver for the device based on what commands the API reports it supports. You should never need to change the driver because of this. Did you change the driver?
Most likely both of them should have variations of drivers that support the Dreamview feature. The Govee TV Backlight 3 lite supports Move Dreamview while the Floor Lamp 2 probably supports Music Dreamview. That is why they would both have it.
Just remember when using the toggle it is always about what is controlling the Dreamview Sync
I was playing around with the drivers thinking I needed the Dreamview Sync driver so that I would have access to the Dreamview toggle command.
However, I deleted both devices and let the integration app reinstalled them with the approporiate driver for each. The second post is what the app installed.
H6099 (Govee TV Backlight 3 Lite) = Govee v2 Color Lights 3 Driver driver
H607C (Govee Floor Lamp 2) = Govee v2 Color Lights 4 Dreamview Sync driver
You are right that the driver would be tagged with Dreamview in the name if it supported that command.
Can you open the device, go to the Device Info tab, scroll down until you see the data fields, look for the data field "commands" and past all the values here for me. It shlould show support for Dreamview in that list of commands if it is supported. I can then review the list to see why it didn't select a driver with Dreamview. I may need to create a new driver for it if the combination of commands is new
H6099 (Govee TV Backlight 3 Lite) = Govee v2 Color Lights 3 Driver driver
H607C (Govee Floor Lamp 2) = Govee v2 Color Lights 4 Dreamview Sync driver
So based on those screenshots the H6099 doesn't support the Dreamview toggle and the driver it picked is the right one.
The Integration worked as expected.
Now if the H6099 does support Movie Dreamview as a sync center in the Govee app you would need to ask Govee support for why it isn't showing supported in the new API.
Looks like everything is working as expected. H6099 does support Movie Dreamview, however only it needs to be controlled. When it turns on/off, the other devices that are part of the sync will follow.
On/off just turns the device from a given state. So if a device is in Dreamview mode when turned off it would likely return it to that state when turned on.
The Dreamview toggle would allow you to activate the Movie/music Dreamview from any state. You could have the device in CT mode as general lighting with a CT of 3500. Then if you flipped the dreamview toggle it would activate the Move/Music dreamview. It doesn't depend on you leaving it in the Dreamview Mode.
It may be a good idea to reach out to support as to why that device is missing the Dreamview from the Supported Commands list from the API.
I have been offline due to family medical issues. I appreciate the responses, I probably won't dive into this again for a while.
What I can tell you is that using the cloud API, even simple on/off commands work randomly, why I prefer the LAN API control.
No worries I will be here when you get back to it.
That is a little bit surprising. Generally speaking, the Cloud is fairly reliable, just slow sometimes. It only starts to have issues when you exceed rate limits. The LAN API is more often than not reported as having reliability issues because the protocol used is fire and forget. Either way we will get to the bottom of this when you get back to it.
I am about to install 4 separate strips in a location that I won't be able to troubleshoot later. Was intending on using the LAN integration and getting appropriate strips and using Siri scene voice commands. But if the LAN integration is flaky, should I just stick with the cloud? Cloud isn't my preference. When you say fire and forget, does that mean it doesn't check if it actually did it? Would reissuing the voice command "simply" take care of the issue? Annoying, but the current solution?
While searching for LAN compatible strips, I can't find any that say WiFi compatible on the box. However, the listings seem to always associate Alexa compatible with WiFi capability. Is that correct?
Finally, two of the strips are to be installed on opposite sides of the room. Is it possible to "connect" two 16ft strips together to make 32 feet with 15 feet in between so that only one controller is needed and they work in one continuous pattern? Which models could support that?
In networking there are two main protocols which are TCP and UDP. TCP is used mostly for reliability as it has allot of checks and acknowledgements, but that also causes overhead. UDP is used for a variety of tasks that need to be super fast. UDP simply doesn't do all the checks and validations TCP does so it can be allot faster. For whatever reason Govee choose to run there LAN API over UDP. The transmit of the command is fire and forget from the standpoint the command gets sent and nothing ensures your device recieved the command on the network level. Until 2.4.1 and the last big update to my Gove Integration I had no way to validate the command actually happened. With 2.4.1 i do have a way to get the status Of Lan API devices and have thought a few times about adding a check and retry process in the driver.
UDP and LAN API reliability is a result of how well your wifi network works. I personally dont have issues with LAN API. I know a few have experienced problems though. My guess is it is related to network congestion or interference.
I will start to look at adding a command validation and retry to the driver.
Sending the command a second time is a viable way to ensure it makea the change l. I know a few users that have done it.
Yea. If you look at the specs of a strip it should list wifi as a communication method along with Bluetooth. LAN API isn't a guarantee though with wifi. That said pretty much any new device released in the last year or two will likely have LAN API if it has alexa.
As far as the last question goes i am not sure. I suspect you will likely need two devices and then use a scenic dreamview to link them together.
Great work on the govee integration... just sent a donation. Keep up the great work! I've used the outdoor lights and integrated them nicely with my hubitat. Just added some interior lights, they have no LAN option unfortunately. I am tinkering with them. I can get a group on the govee app and I can get that exposed in hubitat as a device. However, only three commands are available... on/off/Initialize. The on off work great, just wish could do everything else as a group.
I know I can set up commands to group them together but they go off one by one with a slight delay in between. Not a deal breaker but the group works better. Is there any way to get more commands for the group? I.e. - set level, colors, etc.
Thanks again for your work