Discussions

Ask a Question

Different APIs Confusion

Hello, I started playing around with the Govee API but so far I have come across two (maybe even three) different APIs with different capabilities. Can someone tell me which one to use and link me the right documentation? <br /> Also, I use the Glide Hexa Pro Lights (H6066), do they have support for controlling singular “cubes” or even the three panels of one cube separately? I have read in other threads that it is indeed possible with the segmentedRGB Command but my lights don’t seem to accept the command. If you know how it’s done, can you provide a short code snippet? (Language doesn’t matter) <br /> Thanks for your help!

Support for Smart Ground lights 2

Any chance we can get support for the new Ground lights. I believe their model numbers are H7052 and H7053. I have a few users asking about it.

How can I get temperature readings via API call?

Hi, I would like to make API calls to get temperature readings for data science purposes. But, I didn't see the GET method in the API documentation. Can someone verify if this is possible and if so, how? Thanks.

Govee Lights - Get Device State returns incorrect info.

If I call /router/api/v1/device/state the returned JSON always indicates that the light is in RGB mode rather than a DIY scene. Steps to reproduce: - Set your Govee lights to a DIY scene in Govee Home - Call <https://openapi.api.govee.com/router/api/v1/device/state> with the appropriate headers and body type = devices.capabilities.color_setting, instance = colorRgb always has a value while type = devices.capabilities.dynamic_scene, instance = diyScene is always an empty string even though you just set the lights to be a specific scene in the mobile application.

Govee Lights - API to get current scene

Please create a GET method for /router/api/v1/device/control to allow us to query the current scene for the SKU/device. This would allow us to determine if a) the current scene is a light scene or a DIY scene and b) what the scene parameters are so that we can change the scene temporarily and then restore it to the current scene after we are done. Something like this would allow us to connect our Govee lights to Twitch events so that we can, for example, flash the lights green when we get a new subscriber. Sample JSON body: { "requestId": "uuid", "payload": { "sku": "xxx", "device": "xxx" } } Sample JSON response: { "requestId": "uuid", "payload": { "sku": "xxx", "device": "yyy", "capability": { "type": "devices.capabilities.dynamic_scene", "instance": "diyScene", "value": 1234567 } } }

What is the rate limit for calling requests?

I want to know waht the rate limit for calling request is? And what exactly is the different to this (<https://govee.readme.io/reference/govee-developer-api>) Govee API?

Is there a way to trigger Tap-To-Run?

Hello! I've been playing with the device controls and I had a question about scene controls... Is there a way to trigger Tap-To-Run scenes? Is there a way to control Rooms or Groups? Or do I have to essentially have to create the scene from scratch by creating API calls to each individual device's scene? Thanks!

Support for H607C (Floor Lamp 2)

Hello, Is there any plan to support the Floor Lamp 2 (H607C) in the API? Right now, it appears in the list of devices but there's no way to interact with it. Thanks for your help.

Smart plug H5086 add energy usage info to state in API

Right now can only get the on/off state of the smart switch through the API, would be awesome if we could also get the energy monitoring information too. Give the power, current, and voltage

Inconsistancy with Work_mode on different devices

As I have been working through devices to support i have run into allot of inconsistent usage of the Work_Mode capability between devices. Here are a few examples The H7126 uses gearMode(workMode =1) with a option value of 1 for Sleep while a H7122 and the H7120 sleep mode(workMode = 5) with a option value of 0. It doesn't stop with that kind of different though. Then I also have a H7106 Tower fan that uses sleep modea as (workMode=3) with a option value 0f (1 through 8) I would hope that these values would be standardized across device types if possible so while integrators are creating their programs the responses are consistent across devices. I see this making it much harder to implement a integration then it should be. I am not sure how you would fix this now, but I think every effort should be made to reuse the same values when the naming and such is identical