Given a sensor representing a "stairway" (non-decreasing monotone integer function picewise constant), how to build another sensor returning the height of latest step?

I need to create a sensor to computing the latest change in value of another source sensor.
The source sensor may update once a day few minutes after 6:00 AM, but doesn’t update necessarly every day.

Basically I want the sensor return the height of the step in the following plot in the last 24 hours, if any, or zero otherwise.

I tried with a platform statistics sensor

    - platform: statistics
      name: <change sensor name>
      entity_id: <source sensor name>
      state_characteristic: change
        hours: 24

but doens’t work because source sensor sample value for today, or yesterday, or both can be missing.

Any other way?

use the derivative sensor. It will give you the rate of change, which I believe is the value you want.

No, I don’t want the rate of change.

So you don’t want the change in value, but the time it occurred at?

That’s what I gathered, which is the rate of change. :man_shrugging:

1 Like

Yes, I want the change in value, the height of the step in the plot in the last 24h, if any.
The issue come from the fact the source sensor maybe doesn’t change the value every day, so maybe there are not 2 sample in the past 24 hours.

Yes, then the derivative sensor is exactly what you want. Your other option is to built an automation that takes the state change so you can plop the number into a sensor.

For piecewise constant function like the one plotted, the derivative (or “rate of change”) is zero almost everywhere. At the steps you can’t even compute derivative (in classical way, without resorting to distributions and Dirac’s Delta).

no it’s not, you specify a time window. Just look at the derivative sensor and try it before you instantly shoot it down please.

  - platform: derivative
    source: <source sensor name>
    name: Xyz change per day
    round: 1
    unit_time: d
      days: 1

That will give you the result you want at any point in the day after 6 and it won’t include the previous 6.

I understand now you are not referring to a statistics platform sensor with change_second as state_characteristic and not even to a derivative in a mathematical meaning but to another derivative platform. I’ll have a look.

it is a derivative in a mathematical meaning, it’s just that the period is controllable by the user instead of it being every data point.

It’s definitely not a mathematical derivative and not even an approximation of a mathematical derivative if the “time window” is big.

It’s something we can maybe call the difference quotient. The derivative would be the limit of the this difference quotient when the increment goes to zero.

But a picewise constant function as in my plot, as a discontinuous function, is not differentiable in classical mode, and if it were (in the meaning of generalized function aka distributions), its derivative will be zero almost everywhere.

Anyway, thanks for pointing me in the direction of this “derivative” sensor.

And that’s what the default is with a time window of zero. :man_shrugging:

Nice try. :slight_smile:

By the way, the derivative sensor, even when used with a time_window as of your settings, does not compute what I’m looking for.

For example last samples of source sensor are:

9 960 425 ur
9 962 578 ur
9 965 472 ur

so the step height are

2 153 ur
2 894 ur

while the derivative sensor compute

2 158.1 ur/d
2 886.8 ur/d

that is not even the difference quotient across the last 24h

Change the unit of measurement. If you’re using d then it divides it by the number of hours minutes and seconds in the day. This is why I’ve been trying to get you to read the docs on this sensor. It has many config option, all spelled out to get the results in the units you want.

Edit, not unit of measurement, unit time iirc. I don’t have the docs in front of me atm

I read the documentation 4d ago when I understood you were referring to a derivative platform/sensor.

My understanding was that this sensor computed or estimated the derivative of source sensor, so useless for my needs, because the derivative is exactly zero a.e. or undefined, definitely not what I was looking for.

You pointed out that with a “big” time_window this derivative sensor can behave differently and I gave it a try.

After testing, I’m always convinced this platform try estimate the derivative with some interpolation of the actual data, using maybe more than two data point, that’s way I get a non integer result.

I don’t see any way of changing the settings to get what I need from this platform. Basically we come back to what I wrote 4d ago:

No, I don’t want the rate of change.

Ok, you can try a template sensor based on a state trigger. Subtract the difference between the to and from state. But the value won’t persist over restart. Or do the same thing in an automation that sets an input number that will persist over shutdown.

This will be my last advice here. Good luck.

The state trigger doesn’t add so much to current incomplete implementation. The idea of input_number and automation was my first idea but it’s not concise or elegant.

Really there is no other way to do and no one else has ever done something similar?