Notify when entity is below 95 for 14 days or more

Configuration
,
1

Hi,

what is the best way to make a notification - a notification that would send a message if the entity is below 95 for more than 14 days? I don’t think the automation is good for this because it loses the number of days below 95 on restart.

Can I write it to a virtual entity and check it every day? Is this a good way?

2

I believe the best is probably to trigger on below 95 and then as action set a datetime helper with now + 14 days and this can then be the trigger for the next automation.
Can it go above 95 again or will it just drop from there?

1 Like
3

I will describe what I would need. I’m talking about the battery level. If it has not been charged to 95% or more in the last 14 days, send a notification.

4

In that case set the automation to trigger above 95 and set the datetime helper with {{ now() + timedelta(days=14) }}
Then use this datetime as the trigger to the notification.

This will move the date forward each time the battery goes above 95.

But most batteries don’t like being 100% charged.

1 Like
5

That doesn’t fit what I need. These are PVA batteries and there is little sunlight in winter and it is recommended to charge them once in a while. I need information about the fact that they have not been charged to 100% for more than 14 days in order to switch the mode and thus charge the batteries.

The solution you offer assumes that they charge themselves, I need it the other way around.

So I need to find out the charge value for the last 14 days once a day and if the charge value was not 95% or more, then send a notification.

I can think of a solution where I would write down the maximum value for 14 days and then evaluate every day whether or not to send a notification. Is this a reasonable solution?

6

Yes it does: just think about the logic a bit more.

Automation 1 triggers whenever a new battery level is received. If that level is above 95, it updates the notification time (in a datetime helper you must first create) to 14 days from now — so when it drops below 95, that timestamp stops being updated and starts approaching.

triggers:
  - trigger: state
    entity_id: sensor.battery_level
conditions:
  - condition: numeric_state
    entity_id: sensor.battery_level
    above: 95
actions:
  - action: input_datetime.set_datetime
    target:
      entity_id: input_datetime.battery_warning
    data:
      timestamp: "{{ now().timestamp() + (14*86400) }}"

then, 14 days from the last battery level reading that was not below 95:

triggers:
  - trigger: time
    at: input_datetime.battery_warning
actions:
  - action: notify...
7

I made a statistic of the value of the entity for the last 14 days and every day I run a check if the value is lower than 95. This will ensure me the same or rather better. Because your solution makes the time stamp on the day and time of the launch, whereas my version with reading data from the history takes into account all the values ​​there, even if the value above 95 happened only for a moment.

- platform: statistics
  name: "FVE baterka max"  
  entity_id: sensor.wattsonic_battery_soc
  state_characteristic: value_max
  sampling_size: 20000
  max_age:
    hours:336

Or am I wrong?

8

So does mine (Hellis’s logic). If any battery reading comes in above 95, the timestamp is reset to 14 days from now.

Yours should also work, although I think you can remove the sampling_size because you have max_age. You don’t need to “every day I run a check if the value is lower than 95”: just trigger off the value dropping:

triggers:
  - trigger: numeric_state
    entity_id: sensor.wattsonic_battery_soc_statistics
    below: 95
actions:
  - action: notify...
9

Yes you are wrong about the logic of the solution me and Troon is saying.
But I’m not sure a statistics sensor survive a restart. Have you tried that?

10

Yes, it will stay. It’s a sensor. Personally, I don’t see a reason why it should disappear after a restart.

11

Most sensors don’t survive a restart so I’m more surprised it does work.

But go ahead and use that method, but keep in mind you need to change your recorder also to hold 14 days.

12

I have the sensor in configuration.yaml, so it will be loaded there at every start. I’ll test it, but I think it will always be up to date since it’s in configuration.yaml.

13

And how do you plan to notify yourself with that entity?

14

I now have an entity FVE battery max, which has a value from 0 to 100, and I put it in the planner so that every day at a certain hour it will find out what the value is and if it is below 95, then let it send a notification.

Is this what you are asking?

15

yep, what’s “the planner”?

16

I use this one

17

That information would have been helpful and it would have avoided the back and forth above.

18

I guess I don’t understand, it doesn’t matter if I start via “planner” or via classic automation at a given time. Will it do the same thing or not?

19

The automations above listed by @Hellis81 and @Troon solve your request, however they fire exactly 14 days to the second after the value goes below 95 for the first time.

Your solution checks at a specific time after 14 days, which may end up being 14 days plus the offset between the time the 95 event occurred and your configured specific time.

You asked if checking once a day was a great solution, they provided an exact solution that you’re arguing against. It would have saved everyone the trouble if you justed asked for the solution you wanted, not ask if it’s a good solution or not.

1 Like
20

image

1 Like