I had the same issue.
I sort of solved it by turning off recorder for the battery and temperature sensors.
recorder:
exclude:
entities:
- sensor.pool_thermometer_battery
- sensor.pool_temperature
and instead made some time-based sensors that record the sensor values every minute.
- trigger:
- platform: time_pattern
minutes: "/1"
sensor:
- name: "pool temp time-based"
unit_of_measurement: °C
device_class: temperature
state_class: measurement
state: >
{{ states('sensor.pool_temperature') | float }}
While that has solved the amount of data being recorded due to slight fluctuations in sensor values issue, it has caused another where sometimes it records a 0 instead.
I then get around that by using max in the long term statistics.
I wouldn’t call that a solve, but it’s where I got to with it
As for battery life, I am polling the base station rather than direct to the battery powered sensor so I assume polling rate should have no impact on battery.
I did also find this feature of localtuya but have not used it yet.
https://github.com/rospogrigio/localtuya#energy-monitoring-values
Setting the scan interval is optional, only needed if energy/power values are not updating frequently enough by default. Values less than 10 seconds may cause stability issues.
I also noticed there was a big update to localtuya only 2 days ago.
Big release!
Introduced a mechanism to force the update of power consumption data, with an optional scan_interval parameter.
See https://github.com/rospogrigio/localtuya/releases/tag/v3.3.0
I might give this example a try, however currently my localtuya is configured via gui instead and I’m not sure it’s worth my time to try yet.
localtuya:
- host: 192.168.1.x
device_id: xxxxx
local_key: xxxxx
friendly_name: Tuya Device
protocol_version: "3.3"
scan_interval: # optional, only needed if energy monitoring values are not updating
seconds: 60 # Values less than 10 seconds may cause stability issues