Hi,
I’m actually very happy with my Home Assistant and have very few wishes, as you can control and configure a lot yourself.
However, one thing bothers me a lot because it now seems very arbitrary.
I followed the recommendations and now use long term statistics. I have also removed all the “tweaks” from the recorder settings so that the recorder now works with the default settings.
Instead, I now use the long term statistics.
However, these only seem to work with sensor entities at the moment.
But there are a lot of other entity types that would benefit from long term statistics. Some of these can even include the same state_classes and units_of_measurements and behave in the same way as sensors in the history - except that they cannot be included in the long term statistics.
I therefore argue in favor of including additional entity domains in the long term statistics.
Primarily, from my point of view, this would include the data from the following entity domains, because they act pretty similar to sensors:
climate (the temperatures)
water_heater (the temperatures)
number (the value, can have device_class and unit of measurement just like sensors)
input_number (the value, can have device_class and unit of measurement just like sensors)
If you’re asking how many people want to know what their water heater temperature was at 6am a year and a half ago, I’d say very few. Like, single digits few.
Remember you can still retain the data for these specific entities using the recorder settings should you wish to. Others, however, might not be amused at seeing their db size increase over time, especially if they don’t have too much disk space to begin with.
The measurements you suggest tend to not be very accurate, as most devices measure these in, or close, to the device that is influencing them. So using separate thermometer/hygrometer entities to gather historical data is way better.
You seem to want to record pretty much everything. I believe many people do not take the time to configure recorder, so they will have way more data stored than needed. If you want to store this much data, Influxdb and Grafana seem to be the way to go for you.
First, thank you for your oppinion! I found wrong installations with statistics over time (almost every time water heaters, no joke! ) and I want so see optimizations for energy usage over time. Long time statistics doesn’t increase the db size, that is why they are enabled for all sensors with state_class.
The measurements you suggest tend to not be very accurate, as most devices measure these in, or close, to the device that is influencing them. So using separate thermometer/hygrometer entities to gather historical data is way better.
My climate devices have an external sensor so the measurement is not less accurate than those from other sensors.
You seem to want to record pretty much everything. I believe many people do not take the time to configure recorder, so they will have way more data stored than needed. If you want to store this much data, Influxdb and Grafana seem to be the way to go for you.
I use the standard settings for the recorder, so I lose those statistics after some days. I don’t want to have all the data, long term statistics don’t record pretty much everything. So I don’t want to record pretty much everything. If I want to do that, I could use the recorder and set a long storage time. I just need the hourly value and mid, max, min… Long term statistics are every efficient in what they store and how they are stored. That is why they are stored forever.
So I still think it would be a good addition, especially for climate entities.
I’m with you. Twice now I’ve caught early failure of a air conditioning unit by being able to compare energy usage and humidity to temperature setpoint, run status and room temperature, and having this data to definitively show premature compressor degradation has gotten the company to cover the cost of a new compressor before it became a problem (it’s been as high as 118°F here this week, so having an A/C unit down would be…impactful).
So apparently it is wanted and by design that I have to create sensors from my climate’s temperature attributes to make them available as long-term information while my stand-alone thermometers get the long-term storage by default?
I also have to add, that most of my climate-sensors are using thermometers detached from the radiator. Nevertheless I would never do such a design decision based on the assumption that most measurements might be inaccurate…it’s both temperatures, so it’d just be great to have them both equally available as long-term data!
) and I want so see optimizations for energy usage over time. Long time statistics doesn’t increase the db size, that is why they are enabled for all sensors with state_class.