There is no polling. The device broadcast updates.
1 Like
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.
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
1 Like
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.
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.
1 Like
That sounds perfect. Can you show me an example how it looks in the config yaml?
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.
1 Like
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.
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.
1 Like
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? 
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.
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
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
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) -}}
1 Like
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?
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.
Indeed it is.
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.
1 Like
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.
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.
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.
1 Like
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.
1 Like
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.
done
Thank you for the clarification.
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?
What happens in case I install the Passive BLE in parallel? Do I see the sonsors twice?
Possibly or one will not work. The last time I tried this, only one worked at a time due to active polling, which if I remember, correctly takes control over the bluetooth adapter where passive subscribes to events. I believe Passive BLE Monitor changed libraries where Govee devices are seen with a passive connection. There may have have been library updates that allow both to work in tandem. You can try and see what happens, the data shouldn’t conflict.
Do you have any suggestions how to access the sqlite DB in a comfortable way
If by “access”, you mean strictly accessing the data, you can interact with sqlite database directly.
If you mean view large amounts of data in the dashboard, unfortunately no. This is a problem I have run into a few times where I lose a year’s worth of data do to corruption but haven’t dedicated enough time for a solution. The SQLite data base is primarily meant to be a short term data store. Overtime, the overhead will become too much, especially if writing to a sd card as it is only a single file database. I also tried a MySQL database recorder but had issues with migrating data. My last attempt was to use SQLite as a short term record, may be a week, then purge the data while recording the information into a time series database like InfluxDB so I could explore the data independent of Home Assistant but I didn’t get too far with this. As I never found a solution for myself, I am not sure what to suggest.
1 Like
A little late response, but you can try Bluetooth + Govee integration and the BLE monitor integration at the same time. But, make sure both the Bluetooth integration and the BLE monitor integration work at the same scanning mode. So, either choose passive scanning in both integrations, or choose active scanning.
If one is using active scanning and the other passive scanning, it often doesn’t work, as the Bluetooth dongle gets confused and tries to keep switching between the two modes, resulting in missing most data.
More background on the difference between the Bluetooth integration and BLE monitor, the first is using bleak as pypi package for BLE scanning and BLE monitor is using aioblescan.
1 Like