Put in a support ticket for it. Each device type needs to be coded for, the dev isn’t going to have every single Device type so we have to provide whatever info we can
Yeah I’ve worked with the developer to iron out issues with other stuff and I actually do have an open ticket for the double plugs.
But in the meantime I was looking at the addon docs for something else and I came across a pretty good holdover solution for the plugs I was talking about.
Turns out any Tap-to-Run automations you create in the govee app are exposed HA through the addon.
So I made separate automations to turn on and off each plug separately and then in HA I can link them to input booleans for each outlet.
Not exactly perfect but a totally fine work around 
1 Like
Update on this. It seems to see it when first set up then looses the humidifier. Unsure as to what is causing this. This is the issue on github that I have submitted.
Edit: Added the github issue link
I do all my automations in node-red, so I’m coming at this a little different.
I have my api calls in rest_cmd, which I can then call from a service, I use node red to put a virtual switch in HA that when i toggle, fires off the on or off service to my devices…
where I’m getting stuck is with rest calls to get the status
If i go to jasonpath.com and walk that path, it returns the value I want
i’m getting this error
homeassistant.exceptions.InvalidStateError: Invalid state with length 402. State max length is 255 characters.
i know the headers and payload are all correct, if i use them in api tester, I get valid api data returned…
any ideas?
- authentication: basic
scan_interval: 60
resource: https://openapi.api.govee.com/router/api/v1/device/state
payload: '{"requestId": "uuid","payload": {"sku": "H7172","device": "mac address redacted"}}'
method: POST
verify_ssl: false
headers:
Govee-API-Key: api key redacted
Content-Type: application/json
sensor:
- name: "device status"
json_attributes_path: "$.payload.capabilities[1].state"
json_attributes:
- "value"
I finally got it to work… PITA
sensor:
- name: "device online"
value_template: '{{ value_json.payload.capabilities[0].state.value }}'
- name: "device2 online"
value_template: '{{ value_json.payload.capabilities[1].state.value }}'
if i specified as above with the value as the attribute i was looking for it gave me a 255 limit. if did’n’t it gave me the value i wanted… 
So I believe I have it fixed.
MQTT’s auto start on boot didn’t seem to be sticking but now seems to be fixed and the humidifier reports data now.
For whomever it helps, I have Govee Smart Space Heater Pro (H7133) working like a champ through the MQTT integration.
I’ve set it up as a full blooded climate entity and am not using any of the auto created entities as they were (a) too disconnected and (b) too buggy.
Here it is, sitting in a mini-climate card. Configuration.yaml below.
The code can probably be optimized, but it works well.
- climate:
name: Porch SpaceHeater
modes:
- "off"
- "heat"
- "auto"
- "fan_only"
fan_modes:
- "high"
- "medium"
- "low"
- "auto"
optimistic: true
json_attributes_topic: "gv2mqtt/sensor/sensor-DB2A6074F445163C-gv2mqtt-status/attributes"
json_attributes_template: |-
{% set mqttValue = value_json.platform_state.capabilities[3].state.value %}
{% set scene = value_json.platform_state.capabilities[6].state.value %}
{% set scenes = value_json.platform_metadata.capabilities[5].parameters.options | list %}
{% set selected_scene = ((scenes | selectattr("value", '==', scene) | list or [{"value":scene, "name":"none"}]) | first).name %}
{% if mqttValue == 0 %}
{{ {"nightlight": "off", "nightlight_scene": scene, "nightlight_scenes": scenes, "selected_scene": selected_scene } | tojson }}
{% else %}
{{ {"nightlight": "on", "nightlight_scene": scene, "nightlight_scenes": scenes, "selected_scene": selected_scene } | tojson }}
{% endif %}
current_temperature_topic: "gv2mqtt/sensor/sensor-DB2A6074F445163C-gv2mqtt-status/attributes"
current_temperature_template: "{{ value_json.platform_state.capabilities[8].state.value }}"
temperature_state_topic: "gv2mqtt/sensor/sensor-DB2A6074F445163C-gv2mqtt-status/attributes"
temperature_state_template: "{{ value_json.platform_state.capabilities[7].state.value.targetTemperature }}"
swing_mode_state_topic: "gv2mqtt/sensor/sensor-DB2A6074F445163C-gv2mqtt-status/attributes"
swing_mode_state_template: |-
{% set mqttValue = value_json.platform_state.capabilities[2].state.value %}
{% if mqttValue == 0 %}
{{"off"}}
{% else %}
{{"on"}}
{% endif %}
# get hvac mode from workmode --- but we need hvac mode = "off" from powerState
mode_state_topic: "gv2mqtt/sensor/sensor-DB2A6074F445163C-gv2mqtt-status/attributes"
mode_state_template: |-
{% set mqttValue = value_json.platform_state.capabilities[9].state.value %}
{% set mqttOffValue = value_json.platform_state.capabilities[1].state.value %}
{% if mqttOffValue == 0 %}
{{"off"}}
{% elif mqttValue.workMode == 1 %}
{{"heat"}}
{% elif mqttValue.workMode == 3 %}
{{"auto"}}
{% elif mqttValue.workMode == 9 %}
{{"fan_only"}}
{% endif %}
fan_mode_state_topic: "gv2mqtt/sensor/sensor-DB2A6074F445163C-gv2mqtt-status/attributes"
fan_mode_state_template: |-
{% set mqttValue = value_json.platform_state.capabilities[9].state.value %}
{% if mqttValue.modeValue == 1 %}
{{"low"}}
{% elif mqttValue.modeValue == 2 %}
{{"medium"}}
{% elif mqttValue.modeValue == 3 %}
{{"high"}}
{% else %}
{{"auto"}}
{% endif %}
power_command_topic: "gv2mqtt/switch/DB2A6074F445163C/command/powerSwitch"
temperature_command_topic: "gv2mqtt/DB2A6074F445163C/set-temperature/targettemperature/°F"
# mode_command_topic: "gv2mqtt/DB2A6074F445163C/set-work-mode"
mode_command_topic: "gv2mqtt/DB2A6074F445163C/set-hvac-mode"
mode_command_template: |-
{% if value == "auto" %}
{{"Auto"}}
{% elif value == "heat" %}
{{"gearMode"}}
{% elif value == "fan_only" %}
{{"Fan"}}
{% elif value == "off" %}
{{"off"}}
{% else %}
{{"NONSENSE"}}
{% endif %}
fan_mode_command_topic: "gv2mqtt/number/DB2A6074F445163C/command/gearMode/1"
fan_mode_command_template: |-
{% if value == "high" %}
{{"3"}}
{% elif value == "medium" %}
{{"2"}}
{% elif value == "low" %}
{{"1"}}
{% else %}
{{"0"}}
{% endif %}
swing_mode_command_topic: "gv2mqtt/switch/DB2A6074F445163C/command/airDeflectorToggle"
swing_mode_command_template: |-
{% if value == "on" %}
{{"ON"}}
{% else %}
{{"OFF"}}
{% endif %}
The MQTT implementation has a few challenges that I could only solve by creating some small automations. (i.e. Off is not an HVAC mode, so I publish to a intermediate MQTT topic, and the automation kicks in, parses intent and publishes to the real topic).
Can you pass it to me privately?
Any chance to also share the automations ?
So we have a full set ?
can you elaborate on this please, I am in the same boat, and can’t figure out how to control my govee dual outlets.
When I go to the MQTT integration and choose the “govee 2 MQTT” device, all tap to run automations list there with buttons to activate:
So from there I built…I think toggles/input booleans and then I made automations where flipping the toggle on/off presses the appropriate button to activate the corresponding tap to run scene.
At least I think that’s what I did. I overhauled a bunch of stuff since then in my ha instance and my brain is mush.
And if you just created the tap to run automations in the govee app, you will probably need to restart the addon to get them to show.
1 Like
I have brought back the new GoveeLife integration from @mk-maddin located here. Having a native HA integration will work a whole lot better than using a bridge or MQTT.
So far I have ironed out some switch issues, added support for Govee Fans and Govee Air Purifiers.
I would love to add more, but that’s all I’ve got at home.
2 Likes
Interesting. Do you have humidifier support?
Not yet Because I don’t own one. I can give you on/off support immediately and if you want more, you’ll need to paste me your API response as an issue in the repo.
I put the URI in the readme.
1 Like
Awesome! I see it has fan support for the air purifier. I assume that’s just an on/off switch entity? Do you know if this new API would support reading the actual air quality values into HA? I’m happy to help contribute code. I was just looking into getting a smart air purifier where I could read the air quality values into HA.
I have an air purifier which is, at this time, fully operational using this integration. The air purifier supports on off as well as preset modes including fan speed.
The API does not offer air quality readings or filter lifetime readings just yet. Therefore these objects are not yet available. As soon as the API offers them I will implement.
1 Like
Ah, I just saw that the air purifier doesn’t have a built in air quality monitor anyway… they made that a little misleading in the product description… it apparently has to be paired with a separate air quality monitor.
Sorry,
but does anyone have the same problem as me? Turning on/ff works, but changing modes does not do anything:
I’m using a h713a space-heater.
After struggling with this integration for the past few days, I figured I should post about my experience with the Govee API, Homebridge, and Home Assistant.
When I started integrating this, I figured I would use the API method to control my H7130 and H7135 heaters. The first problem I encountered was finding the 23-character product ID. I don’t know if the Govee App changed, but I could not find it in the App, and posting an API request didn’t return anything (more on that. soon).
Since I couldn’t find the Device ID, I loaded Homebridge in a Docker container on my Synology to see if it could retrieve the IDs. It worked like a charm. As soon as I loaded the Govvee plugin and rebooted Home Bridge, the Device IDs popped up in the log files.
Armed with the Device IDs, I set up my rest command for the appliance, I set up my script, and I wrote an automation to turn on and off the H7130 heater. Then, I set up a button to trigger the automation, and everything worked perfectly. Hurray. Little did I know that was the last time I would see success for a while.
Next, I focused on controlling the Mode, Fan, and Temperature. I tried every variation of the API commands I could think of. I read the API documentation (it’s very sparse, btw), and nothing worked. So, I tried sending an API command to query the device’s state. No luck. I tried PUT commands and GET. Apparently (and as suggested in the above posts), you can’t query the state of the Govee devices as of July 10th, 2024. Hopefully, these changes will happen in the future, but by this time, I was fed up and decided to return to the Homebridge integration.
When I tried to get that to work on my Synology, I quickly realized that the Node.js version on Synology is 12.0, and Homebridge requires version 20. So, I decided to load Homebridge on my HA Yellow. That worked great, except that HA complained that this was a non-supported change to the system and I should remove Homebridge. So, I created a VM on my Synology with Ubuntu and loaded Homebridge on that. That was the answer. It worked great, and I now have a VM with a clean version of Linux on it, so I can also load other apps on it in the future. Yeah!
So here’s where I stand after three days of work. The Govee integration works great through Homebridge and appears in HA under Homekit. For the H7130 heater, I can query and control the temperature and on/off. For the H7135, I can query and control the on/off, temperature, and fan mode.
In summary. If all you want to control is the on/off, then I recommend using the API. You won’t be able to query the status of your heater (but you could plug it into a smart plug and query the state that way). If you want to control or query anything else, I suggest Homebridge. As an added benefit, Homebridge does not require any API keys. All you need is your username and password for the Govee app. The downside to Homebridge is you need a separate app running on a machine at all times.
I hope this helps.
Update: I found a way to make the query work using the following command: curl -X GET “https://openapi.api.govee.com/router/api/v1/user/devices” -H "Govee-API-Key: xxxx-xxxx-xxxx-xxxx-xxxx (where x represents your API key).
I will continue working on this to see if I can get the API method to work.
Second Update: I found this integration referenced above on Github: async_forward_entry_setup Warning for GoveeLife Integration · Issue #16 · disforw/goveelife · GitHub
It does everything I want it to so I am abandoning Homebridge in favor of the native integration.
1 Like
Hello, trying to make a template sensor in case the tank runs out of water for a Govee Humidifier H7143, seing some alarms coming in under attributes for the state entity but cant figure out how to use that as a reliable indicator, just wondering if anybody has gotten a way to get the sensor working
- alarmType: 51
eventState:
options: - message: Lack of Water
name: lackWater
value: 1
instance: lackWaterEven