Formula based statistics graph

Configuration
1

Hi there!
I’m diving into the rabbit hole of long term statistics, and came across quite a specific problem:
I would like to see statistics on the dominant wind direction in a given time window. Since we are talking compass headings where 359° and 1° are separated by 2° and not 358°, I cannot use a simple average of the compass heading. The average for the above example is obviously 0° (North), but a normal average would give the opposite result, 180° (South)

The solution for this is to have template sensors that log the sine and cosine of the wind direction, averaging those over time, and performing an arctan of the averages to get the average wind direction. This is discussed in this thread in detail: Filter wind direction - #13 by Kimble8650

However, when using long term statistics, the solution would be similar - I log the statistics of the sine and cosine of the wind direction, but in order to display the average wind direction I would need to, at the time of rendering, calculate the arctan based on the sine and cosine statistics.

Is there a way for me to do this, to display a statistics graph based on a calculation of two separate statistics?

2

No, this is not possible without something custom or a template sensor that uses radians.

3

Hi!
Bummer. That makes me sad =(.
Maybe I’ll put out a feature request on that then =).

Thanks for the help!

4

I highly doubt that FR will go through as the whole point of template sensors is to apply complex math on your existing sensors.

template:
- sensor:
  - name: wind dir atan2
    state: >
      {% set angle = states('sensor.wind_dir') | float(0) %}
      {% set radians = angle * pi / 180.0 %}
      {% set x = cos(radians) %}
      {% set y = sin(radians) %}
      {{ atan2(y, x, none) }}
    availability: >
      {{ states('sensor.wind_dir') | is_number }}
5

Yes, and I have utilised a template sensor to get a (short term) average on the wind direction, but I cannot report long term statistics on that as the results would be skewed if any averaging is done when saving those statistics. Any change to the observed timeframe (e.g. daily vs. weekly average wind direction) will render the statistics useless.

Maybe this would require some custom frontend component to accomplish at the moment.

I still feel that the ability to use formulas in the long term statistics graphs would be a powerful tool also in the cases when you would want to see (calculated) trends on previously reported data, as at the moment creating a new template sensor would not calculate past values, but only values from the creation of the template sensor forward. But I do understand that this is def. not priority no. 1 in the development backlog :smiley:

6

I don’t see how this is the case. If you store the template sensor in long term stats, then you’d get the values you want, or am I missing something.

7

The thing is, the math in averaging compass headings differs from the math of averaging pretty much any other thing.
Let’s say, that I create a template sensor, that would display the hourly average of the wind direction and that it would log that (hourly) value in the long term statistics correctly (no additional averaging). Then If I would view the hourly long term statistics, everything would be fine and dandy. If I were however to change the timeframe, and view daily averages, the statistics would calculate a new average based on the logged long term statistics and break down.

Example: Lets say that the correct hourly averages for five logged hours are: 340°, 350°, 0°, 10° and 20°, If I were to view the average over a five hour period, the statistics engine would calculate the average as (340+350+0+10+20)/5 = 144°, the min as 0° the max as 350° and the median as 20°.
The correct values would however be: average 0°, min and max are essentially 340° and 20° respectively, and the median 0°.

The min, max and median are even more difficult to get right, but at least the average would be possible to calculate with said “formula graph”.

I’m really bad at explaining my thought process, but I hope I’m getting my message through. =) If not, please keep on pressing me =)

8

Think it like this. The wind blows from the N for 6 hours, then from the S for 6 hours. The average is either E or W, and both are completely misleading.

9

It’s not even that, it’s also that using atan2 the numbers in his example become.

-20, -10, 0, 10, and 20 respectively and thus give the values he’s expecting; avg of 0 a min of -20 (340) and a max of 20 (20). However, this does shift the issue to the 180º side (wind usually doesn’t travel that direction world wide anyways). His best option is to make a vector using i, j coordinates. Storing the LTS of i and j components separately.

Also, the stats for day vrs hour use the same data set. The daily stats do not use the hourly stats, so his results will still be different than what he expects.

Regardless of this, I highly doubt any a circular mean will be given as an option for LTS or any graph. This can be done in a template sensor though.