Yes. The rest service I posted yesterday works for me. Have you try it on postman for exemple ?
On and off are working for me (thanks for this thread).
I noticed in their docs they have a āstateā API as well. Has anyone got this working? (Itād be nice to be able to check the current state)
My command:
curl --request GET -G -d "device:XXXXX" -d "model:H7130" --header 'Govee-API-Key: XXXXXX' --url https://developer-api.govee.com/v1/devices/state
Is returning:
{āmessageā:ādevice, model are required paramsā,āstatusā:400}
For the state you have to use the new api.
@Idaho947 thatās working for me now, thanks kindly.
One thing thatās kind of weird to me, let me know if others are seeing this, as well?
Hereās my state of the world:
- H7130 that is āonā
- Thermostat Mode is ON
- Target temperature is 68
- Current temperature is 67.8
- The heater itself is physically āoffā (not currently heating)
- Auto Stop is ON
When I query the state API, hereās what I get. The weird thing to me is that the value of 0 indicates the heater is off, which is sort of true in that itās not currently heating, but the heater is powered on and set to Auto, meaning itāll start heating when the temp drops.
Is there any way for me to discern whether the heater is actually fully off vs. just currently off because the temperature isnāt low enough?
Hopefully that made some sense. Appreciate any insight.
{
"requestId": "abc",
"msg": "success",
"code": 200,
"payload": {
"sku": "H7130",
"device": "redacted",
"capabilities": [{
"type": "devices.capabilities.online",
"instance": "online",
"state": {
"value": true
}
}, {
"type": "devices.capabilities.on_off",
"instance": "powerSwitch",
"state": {
"value": 0
}
}, {
"type": "devices.capabilities.toggle",
"instance": "oscillationToggle",
"state": {
"value": 1
}
}, {
"type": "devices.capabilities.toggle",
"instance": "thermostatToggle",
"state": {
"value": ""
}
}, {
"type": "devices.capabilities.temperature_setting",
"instance": "targetTemperature",
"state": {
"value": {
"unit": "Celsius",
"targetTemperature": 20
}
}
}, {
"type": "devices.capabilities.property",
"instance": "sensorTemperature",
"state": {
"value": 67
}
}, {
"type": "devices.capabilities.work_mode",
"instance": "workMode",
"state": {
"value": {
"workMode": 2,
"modeValue": 0
}
}
}]
}
}
Wellā¦ if you have it fully off and try to query it what is the result?
Look at my full recipe to support Govee Smart Space Heater H7131 GitHub - wiltodelta/homeassistant-govee-smart-heater-h7131: Govee Smart Heater H7131 Integration for Home Assistant
Why you don t use the new gover api ?
Are you asking me?
everybody should check out the MQTT implementation by wez furlong ā¦ wez/govee2mqtt: Govee2MQTT: Connect Govee lights and devices to Home Assistant (github.com)
yes. They have a new api .
Will check and update my recipe
Here ya go!
Note: (For those of you wanting the stuff for the H7130, it should all be very similar!)
This is in my rest.yaml file.
heater_nightlight_onoff:
url: https://openapi.api.govee.com/router/api/v1/device/control
method: POST
headers:
Content-Type: application/json
Govee-API-Key: abc-123-api-key
content_type: "application/json; charset=utf-8"
payload: >-
{
"requestId": "uuid",
"payload": {
"sku": "H7131",
"device": "DE:VI:CE:ID:HE:RE",
"capability": {
"type": "devices.capabilities.toggle",
"instance": "nightlightToggle",
"value": {{ onoff }}
}
}
}
heater_oscillate_onoff:
url: https://openapi.api.govee.com/router/api/v1/device/control
method: POST
headers:
Content-Type: application/json
Govee-API-Key: abc-123-api-key
content_type: "application/json; charset=utf-8"
payload: >-
{
"requestId": "uuid",
"payload": {
"sku": "H7131",
"device": "DE:VI:CE:ID:HE:RE",
"capability": {
"type": "devices.capabilities.toggle",
"instance": "oscillationToggle",
"value": {{ onoff }}
}
}
}
govee_on_off:
url: https://openapi.api.govee.com/router/api/v1/device/control
method: POST
headers:
Content-Type: application/json
Govee-API-Key: abc-123-api-key
content_type: "application/json; charset=utf-8"
payload: >-
{
"requestId": "uuid",
"payload": {
"sku": "{{ sku }}",
"device": "{{ device }}",
"capability": {
"type": "devices.capabilities.on_off",
"instance": "powerSwitch",
"value": {{ onoff }}
}
}
}
govee_working_mode:
url: https://openapi.api.govee.com/router/api/v1/device/control
method: POST
headers:
Content-Type: application/json
Govee-API-Key: abc-123-api-key
content_type: "application/json; charset=utf-8"
payload: >-
{
"requestId": "1",
"payload": {
"sku": "{{ sku }}",
"device": "{{ device }}",
"capability": {
"type": "devices.capabilities.work_mode",
"instance": "workMode",
"value": {
"workMode":{{ mode }},
"modeValue":{{ modevalue }}
}
}
}
}
If you donāt have a split config, youāll have to make some tweaks.
Then, I made an automation with 6 triggers, all from when an input select is switched to OFF, FAN, LOW, MED, HIGH, and AUTO. In the actions, I have this:
choose:
- conditions:
- condition: trigger
id:
- "OFF"
sequence:
- service: rest_command.govee_on_off
data:
onoff: 0
device: DE:VI:CE:ID:HE:RE
sku: H7131
- conditions:
- condition: trigger
id:
- FAN
sequence:
- service: rest_command.govee_working_mode
data:
mode: 9
modevalue: 0
device: DE:VI:CE:ID:HE:RE
sku: H7131
- conditions:
- condition: trigger
id:
- LOW
sequence:
- service: rest_command.govee_working_mode
data:
mode: 1
modevalue: 1
device:DE:VI:CE:ID:HE:RE
sku: H7131
- conditions:
- condition: trigger
id:
- MED
sequence:
- service: rest_command.govee_working_mode
data:
mode: 1
modevalue: 2
device: DE:VI:CE:ID:HE:RE
sku: H7131
- conditions:
- condition: trigger
id:
- HIGH
sequence:
- service: rest_command.govee_working_mode
data:
mode: 1
modevalue: 3
device: DE:VI:CE:ID:HE:RE
sku: H7131
- conditions:
- condition: trigger
id:
- AUTO
sequence:
- service: rest_command.govee_working_mode
data:
mode: 3
modevalue: 0
device: DE:VI:CE:ID:HE:RE
sku: H7131
The above automation didnāt include anything about the nightlight or oscillation functionality, but those work similarly. Let me know if you have any questions or if I didnāt provide enough detail. Iām writing this kinda quickly so sorry if thereās any typos.
I am having a H713C.
Requesting the more general ālist all connected devices topicā ( https://developer-api.govee.com/v1/user/devices
) instead of the individual device state ( https://developer-api.govee.com/v1/devices/state
) I can see that my heater supports different āworking modesā
{
"type": "devices.capabilities.work_mode",
"instance": "workMode",
"parameters": {
"dataType": "STRUCT",
"fields": [
{
"fieldName": "workMode",
"dataType": "ENUM",
"options": [
{
"name": "gearMode",
"value": 1
},
{
"name": "Fan",
"value": 9
},
{
"name": "Auto",
"value": 3
}
],
"required": true
},
{
"fieldName": "modeValue",
"dataType": "ENUM",
"options": [
{
"name": "gearMode",
"options": [
{
"name": "Low",
"value": 1
},
{
"name": "Medium",
"value": 2
},
{
"name": "High",
"value": 3
}
]
},
{
"defaultValue": 0,
"name": "Fan"
},
{
"defaultValue": 22,
"name": "Auto"
}
],
"required": true
}
]
}
}
I am pretty sure your heater shows there something like:
{
"name": "Auto",
"value": 2
}
as your āworkModeā value for what showed is ā2ā and the āmodeValueā is ā0ā (which as of my modeValues would be something like āoffā
Hmmā¦ modeValue for me seems to always be 0, no matter what I do in the app.
workMode seems to map to:
1: Low
2: Medium
3: High
So far, I donāt notice any data differences in the app when I toggle:
āAuto Stopā on or off
āThermostat Modeā on or off
Does anyone else have similar (or different) results?
In the /users/devices API I did see the JSON key for autoStop, but Iām not getting that back when querying the deviceās state via https://openapi.api.govee.com/router/api/v1/device/state
I have tried this. I can now āseeā my humidifier in HA but cannot control it unfortunately. I see the toggles for light and humidifier but no dice. I have looked and looked for the LAN controls in settings on my app in case that needs to be turned on for the humidifier and itās not an option. It just isnāt there, neither in the humidifierās device settings, or the apps settings. This is also the only govee product I have so I cannot even see what itās supposed to look like.
For reference I have the Smart Humidifier Lite model H7140.
I really hope we can one day just get a full integration using the new api that just natively sees and controls these devices or some support for direct integration.
Or, heck, custom firmware for it so that we can do it ourselves.
Hi, can you please help me with how did you integrate the Homebridge addons to Home Assistant? Thank you
Use homeassistant homekit controller integration and you can enter the 9 digit code from homebridge into that. Then anything connected to homebridge will show up in homeassistant.
Note if your homebridge instance is already connected to HomeKit using the above mentioned code, you will have to remove it from there to get it to homeassistant. But then you can push all the devices from homeassistant into Homekit.
Hi,
I tried and learn many of these helpful tips. I am not programmer and just basic yml user. It was almost impossible for me to use api to do anything. I figured out the quickest way for me to integrate was google. I have govee connected to google home and used voice command to send our on off with or without delay. I have input boolean to show status. Its not perfect by any means but it is at least usable.
I will come back to api stuff later when I have more time. It was fun learning all about api, script and front end setup. Thanks!
soā¦ - its not clean, not nice, not very well written (and maybe with some devices still buggy as I only have a single govee device and the example values from the API page to test) but it is a first point to start
I really hope some of you here can contribute and get something out of my quick & dirty thing here
** LINK & REPOSITORY REMOVED ** - I highly recommend using govee2mqtt instead: wez/govee2mqtt: Govee2MQTT: Connect Govee lights and devices to Home Assistant (github.com)
This has worked for me, and is providing the functionality I wanted. Thank you for putting this together.
I do plan on purchasing a 2nd heater