Govee BLE Thermometer/Hygrometer sensor

[Zoriontsu]

In case anyone else has the same issue: Older firmware not being discovered

Govee 5185 Meat Thermometer Not Recognized · Issue #76352 · home-assistant/core (github.com)

Fix will be on 2022.8.3

[kruste]

Hi everyone,
I have two Govee H5105 and one H5074. My problem is, that the polling is done too often. Especially the H5074 refreshes every few seconds.

I found a closed ticket in GitHub that an automation shall be used. So I disabled “Enable polling for updates” and created an automation for “update_entity”. But nothing changed. Even without any automation set and polling disabled, the three thermometers are updating a lot. The H5074 every few seconds (each poll it seems to be a different interval). The other two between every 30 seconds and a few minutes. Feels more like push from the Govees than a pull from HA/Govee BLE.

Has anybody an idea what I could change to update the measures only every x minutes?

[bdraco (J. Nick Koston)]

There is no polling. The device broadcast updates.

[kruste]

Thanks for the answer. Is there any possibility to let the Govee BLE integration not updating the data on every broadcast but only add data every x minutes? There will be million entries in a short time. I even disabled the Govee devices currently but would really like to see them in my HA.

[Zoriontsu]

I don’t believe there is such a feature. If you are concerned about the number of entries in the database, simply exclude them from the recorder.
Below is my configuration.yaml, to exclude particularly chatty sensors for which I do not need any history:

recorder:
  auto_purge: true
  purge_keep_days: 30
  exclude:
    domains:
      - sun
      - media_player
      - uptime
      - time_date
      - remote
    entities:
      - sensor.front_load_washer_remaining_time
      - sensor.server_cpuload
      - sensor.server_gpuload
      - sensor.server_ramusage
      - sensor.server_memoryusage
      - sensor.server_lastactive
    entity_globs:
      - sensor.weather_station_wind_*
      - sensor.govee*
      - sensor.*_last_seen
      - sensor.*_last_changed

[kruste]

Hi @Zoriontsu
thank you for the help. I’m pretty new to home assistant. Until a few days ago I wasn’t aware that a short term and a long term statistics exists. As far as I understood, the Govee data older than 10 days will we flattened to 4 entries per hour and still be available long term. I want to keep the Govee data long term. So excluding them from recorder is not working for me.

I was in fear, to have millions of temperature entries per year in the database. But as long as the huge amount of data is only kept for 10 days I’m kind of fine with it.

Nevertheless I’m still searching for a solution which doesn’t update the data every 2 seconds. I found the “Passive BLE Integration” (Passive BLE Monitor integration) which does exactly how I would like to have it: collect all the data but only stores the medium every 60 seconds.

Unfortunately this passive way seems not to work with Govee at present. But this is no topic for this thread.

It still would be great if the Govee BLE integration could add such a functionality too.

[teskanoo]

@kruste

I was in fear, to have millions of temperature entries per year in the database

I use template sensors for all of my Govee thermometer hydrometers. I take the raw value and round it to half a degree for the temperature because that’s all I’m interested in. I have prevented the raw data from being recorded and just record the value from the template sensor which probably only changes about 20 times a day.

In truth, the greatest benefit to this strategy is that it cuts down on communications to my raspberry Pi and also massively reduces the size of the database and the number of writes to it.

After I had done this for all 12 sensors, the performance overall of my home assistant massively improved.

I have since adopted the same strategy for power sockets, and anything that has GPS attributes such as person and device trackers, which also bloat the database and produce way more i o than suits me.

A candidate that I added just recently was media players, which when playing store the position of playback in the attributes, generating thousands of database entries.

[kruste]

@teskanoo

I use template sensors for all of my Govee thermometer hydrometers. I take the raw value and round it to half a degree for the temperature because that’s all I’m interested in. I have prevented the raw data from being recorded and just record the value from the template sensor which probably only changes about 20 times a day.

That sounds perfect. Can you show me an example how it looks in the config yaml?

[teskanoo]

template:
- trigger:
  - alias: to_valid
    id: to_valid
    for:
      seconds: 5
    entity_id: sensor.climate_bathroom_temperature
    platform: state
    not_to:
    - unknown
    - unavailable
  sensor:
  - name: t_climate_bathroom_temperature
    unique_id: t_climate_bathroom_temperature
    state: '{{ states(''sensor.climate_bathroom_temperature'') | float(0) | round(1,''half'') }}'

I found that making sure the state change persisted for five seconds prevented updating for small sensor reading fluctuations.

[kruste]

Thank you @teskanoo ! That will be my solution too. Super simple, super effective.

Can you explain, how it is made sure, that not every change of the raw sensor is written to your custom sensor? I understand the algorithm of the template statement and that you calculate to half-degree steps which will lead to less changes. But I do not understand why this prevents HA updating the recorder of the custom senor. I guess HA is taking care of only updating record in case the value is different?

Maybe a dumb question, But as I said: I’m pretty new to HA. Installed it a week ago.

[teskanoo]

@kruste

But I do not understand why this prevents HA updating the recorder of the custom senor. I guess HA is taking care of only updating record in case the value is different?

You may be new to HA, but you do understand. That’s exactly the reason. If the value of the sensor does not change, it does not get recorded.

I’m glad you found this useful.

[kruste]

@teskanoo

I’m glad you found this useful.

Just useful? I love your solution.

I changed all my thermometers to your trigger based approach. Instead of 50k and more records per day and sensor I just have a few hundreds for the really chatty ones. Just look at this 25 minutes frame (I let the thermometers run in parallel at present to figure out the best configuration):

I think there is even room for improvement for my setup, especially for the Govee H5074.

The H5074 is a thermometer which provides native two decimal places, which makes it changing the value almost every second. With the trigger approach I observe that the state is still flickering a bit. Most of the “needless” changes are within 8 to 15 seconds.

So I’m wondering whether it would help to change the for: section from 5 seconds to 20 seconds. Do you see any unwanted side effects or risks like missing changes completely?

Setting for: to 20 seconds does mean that value has to be the same for at least 20 seconds before is recorded? Or does it have to be different for 20 seconds before it is recorded?

[kruste]

P.S.
The humidity sensors are also still a bit too chatty for me. I already use round(0), but the humidity measurement of the Govee is so inaccurate that it jumps a lot.

I changed it to only calculate to the next full 3% (e.g. 27 = 27, 27.5 = 30, 29.9 = 30, 30.4 = 33). Maybe not very precise, especially as always rounding up. But the humidity sensor is inaccurate anyhow. So I think that is fine. Here is the template how to round to the next 3:

‘{{ (states(’‘sensor.h5074_humidity’‘) | float(0) / 3) | round(0, ‘‘ceil’’) * 3 }}’

If you like to have a different step width: just exchange the two 3’s by any other number.

[teskanoo]

@kruste

So I’m wondering whether it would help to change the for: section from 5 seconds to 20 seconds. Do you see any unwanted side effects or risks like missing changes completely?

Depending on your use-case I would say you can happily drop the time to one or even five minutes for the temperature sensors.

It all boils down to what you need to know. I mean a lot of your room could be engulfed in flames in 5 minutes, so if you’re using it as part of a safety-system, you might want a lower duration

@kruste

Setting for: to 20 seconds does mean that value has to be the same for at least 20 seconds before is recorded? Or does it have to be different for 20 seconds before it is recorded?

Answer: It has to both change, and remain at that value for at least 20 seconds before the triggered template gets calculated.

With the humidity sensors your calculation is good, personally, I find rounding to the nearest 2.5 covers the granularity I need for humidity.

I use the following jinja template macros throughout my system (count_decimal_places is a bit verbose/wordy but I like to make it more clear what is happening sometimes )

{#- count_decimal_places: Counts the number of decimal places in a floating point number -#}
{%- macro count_decimal_places(num) -%}
    {%- set num_str = num | string -%}
    {%- set num_str = num_str.rstrip( '0' ) -%}
    {%- set num_str = num_str.rstrip( '.' ) -%}
    {%- set parts   = num_str.split( '.' ) -%}
    {%- set rv = 0 -%}
    {%- if 2 == ( parts | count ) -%}
        {%- set rv = parts[1] | length -%}
    {%- endif -%}
    {{ rv|int }}
{%- endmacro -%}

{#- round_closest: General function to round a number up/down to the closest step_size: -#}
{%- macro round_closest(num, step_size ) -%}
    {%- set rv = (num+step_size/2) // step_size * step_size -%}
    {%- set round_size = count_decimal_places(step_size) | int -%}
    {{ rv | round(round_size) }}
{%- endmacro -%}

They are stored in config/custom_templates/math.jinja file

I use them in my templates everywhere

@see Reusing templates

template:

- sensor:
  - unique_id: t_h5074_humidity
    name: t_h5074_humidity
    state: >
      {%- from "math.jinja" import round_closest-%}
      {{- round_closest(states(’‘sensor.h5074_humidity’‘) | float(0), 2.5) -}}

[kruste]

@kruste

Setting for: to 20 seconds does mean that value has to be the same for at least 20 seconds before is recorded? Or does it have to be different for 20 seconds before it is recorded?

@teskanoo

Answer: It has to both change, and remain at that value for at least 20 seconds before the triggered template gets calculated.

Is the check - whether the value remained for 20 seconds - done by comparing the raw values? I guess so, but the automation trigger documentation it is not clearly answering the question. In case it would be the raw value, my H5074 wouldn’t work with 20 seconds or longer as it changes too often. My trigger would never be calculated in case the raw value chnaged within this 20 seconds, right?

@teskanoo

I use the following jinja template macros throughout my system

And with this small sentence you just introduced me to to macro capabilities of HA.

I have seen jinja before in some other post but thought that something needs to be installed and shifted the read-up to later point in time. With your post I realized that nothing needs to be installed. I already changed all my calculation to a central macro this morning. Thank you again.

[teskanoo]

@kruste

Is the check - whether the value remained for 20 seconds - done by comparing the raw values?

Indeed it is.

@kruste

In case it would be the raw value, my H5074 wouldn’t work with 20 seconds or longer as it changes too often. My trigger would never be calculated in case the raw value changed within this 20 seconds, right?

Indeed you’re right, it may change that many times in 20 seconds that it would never trigger the template to recalculate.

I do not experience this issue and I have mine to trigger with a for: 10 seconds. However, I do not use the Govee integration for my Govee sensors, I am using the Passive BLE Monitor integration.

I think that Passive explicitly rounds to 1 decimal place before even announcing a change on temperature or humidity. That really cuts down on that chatter between the integration my listening template sensor.

I think when had the devices coming into home assistant through a different integration that they were reporting to 4 decimal places !!!

My recorder stores about 150-300 readings per sensor over the 7 day period over which I retain my data.

[kruste]

One last question @teskanoo then I stop bothering you.

I setup up the custom triggers for all of my Govees sensors. Now I want to make sure that the raw sensors are not recorded anymore. Neither in the long term statistics nor in the short term statistics (10 days in my case).

I excluded the sensors from recorder by adding e.g.:

recorder:
  exclude:
    entities:
      - sensor.h5074_humidity

That seems to work fine although it is a bit tough to find out for the short term statistics, because each time you click on the sensor it opens the history an starts tracking the current values. Feels like a kind of bug but might be a feature.

My question with the long term statistics:
I see the sensor still in the “statistics” section of he developer tools. It states “This entity is no longer being recorded” so everything is fine. But I would like to remove it completely from the statistics section.It just needs not to be shown there.

As the original sensor is not within the configuration.yaml, I have no clue how to remove the state_class attribute from the sensor to remove it from the statistics list. Do you have any idea how the sensors from integrations can be configured?

EDIT:
Ah, ok, it is still there because old long term data exists. That makes sense. But it would still be very interesting to know, where “3rd party” sensors can be configured, where their yaml is located.

@teskanoo

I do not experience this issue and I have mine to trigger with a for: 10 seconds. However, I do not use the Govee integration for my Govee sensors, I am using the Passive BLE Monitor integration.

I had a look at that integration too. But it’s documentation states that active polling is needed for Govee devices which leads to more power consumption.

[teskanoo]

@teskanoo

I am using the Passive BLE Monitor integration

@kruste

I had a look at that integration too. But it’s documentation states that active polling is needed for Govee devices which leads to more power consumption

Hmmm… I see that in the docs, it says Active scan must be enabled for the devices we both use, however I do not have that option checked, and my device readings are picked up just fine in Home Assistant - FWIW, the batteries (rechargeable AAAs) last about 6-8 months.

@kruste

My question with the long term statistics:
I see the sensor still in the “statistics” section of he developer tools. It states “This entity is no longer being recorded” so everything is fine. But I would like to remove it completely from the statistics section. It just needs not to be shown there.

Unfortunately this functionality has not yet been implemented. For the time being, the only way that existing long term statistics can be deleted seems to be direct database manipulation.

Fortunately one only has to remove the relevant row from the table named ‘statistics_meta’.

The row you need to remove is the one where you see your entity in the column named ‘statistic_id’

There are many discussion and polls in the forum regarding this lack of functionality.

[1] Long term statistics (how to remove from database)

[2] Remove statistics of disabled (not deleted!) entities from recorder

[3] Ability to clear (long term) statistics for excluded entitites

[4] WTH is it not possible to delete long term statistics for entities using services

Items 2, 3 and 4 are polls/votes for this feature request - please vote for them to encourage the developers to implement the ability for users to delete long term statistics for entities they have decided to exclude from recording.

[Thrilleratplay]

@kruste

I had a look at that integration too. But it’s documentation states that active polling is needed for Govee devices which leads to more power consumption.

My apologies for the confusion. There is no direct connection to the Govee devices and the data received is from the broadcast the device sends out roughly every second. “Active polling” is the dedicated scan mode of the receiver only and no bearing on the battery life of the thermometers. Both Passive BLE Monitor and this plugin work the same way. I would suggest using Passive BLE Monitor as it is actively maintained and works with more devices but it is up to personal preference.

[kruste]

@teskanoo

Fortunately one only has to remove the relevant row from the table named ‘statistics_meta’.

The row you need to remove is the one where you see your entity in the column named ‘statistic_id’

Great to know. I will clean it up. Do you have any suggestions how to access the sqlite DB in a comfortable way? I have my HA installed on a raspi using docker, so I cannot use addons. I installed sqlite3 on the raspi which is ok but really raw. I also installed sqlitebrowser which was dump by me, because I’m acessing my raspi via SSH, so I have no X.

BTW:
I just find out another advantage of using your approach of custom trigger-sensors per original sensor. Switching to a new device and keeping the old data is super easy (e.g. after buying a different thermometer for the same room). Just exchange the original sensor as source in the custom one. HA does not even recognize that the data comes from a completely different sensor. I have read a lot today about people having problems keeping old data.

@teskanoo

Items 2, 3 and 4 are polls/votes for this feature request - please vote for them

done

@Thrilleratplay

My apologies for the confusion. There is no direct connection to the Govee devices and the data received is from the broadcast the device sends out roughly every second.

Thank you for the clarification.

@Thrilleratplay

I would suggest using Passive BLE Monitor as it is actively maintained and works with more devices but it is up to personal preference.

I’m happy at present but I guess I will switch sometime now where I know it is not actively polling the device. The good thing: switching is super simple for me because of the cutom trigger-sensors.

The Passive BLE Integration can be configured to only change state for the sensors every e.g. 60 seconds, right? That would lead to even less data in HA than my current solution.

What happens in case I install the Passive BLE in parallel? Do I see the sonsors twice?