Imagine you have a button on the UI and every time you press it, you want to do a few calculations:
Record the time that the button was pushed.
Calculate and store the time since the last time it was pushed.
Estimate based upon the time between each button press how many time the button might be pressed within a given week/month/year, then use that estimate as the value of an input_select to control an automation that serves as a reminder that the button needs to be pressed soon.
Here’s an example of why we would want this:
We want to predictively determine within a day or two when our air filter actually needs to be replaced based upon a history of replacing it. At first, we will need to monitor the filter daily until we determine when it needs to be changed. Then, when we change it, we would tap the button to log that the filter has been changed. As a result, we would then calculate the most likely next time we would need to change it, then trigger an automation based upon that time-frame. Every time we tap the task completed, the frequency needed (input_number) would be updated, much like the tempo is updated on a tap tempo when following along to the beat of a song.
With that data, we’ll know things like how often we need to buy air filters so they can automatically be added to our shopping list, how much it costs monthly to supply the house with filters, etc.
This would apply to other tasks too, like cleaning the ceiling fans, checking the salt in the soft water system, etc.
It may seem excessive, but I think this community understands that the goal of home automation is not only to be fancy with technology, but to be practical with information that helps us live our lives more efficiently.
You might want take a look at the Grocy add-on and custom integration… it has a chore tracker with options for adaptive due dates based on past average execution frequency.
Grocy is functional but far too busy for such simple tasks. We want a simple button on the UI, not an entire task management add-on with its own interface. It doesn’t translate well to a tablet or mobile device, and we can’t use RFID tags to complete tasks (another feature we use for our little ones.)
I get what you’re saying about the Grocy UI being busy, but I think you may be underestimating the “simple-ness” of the task…
With the Grocy integration you can do all the day-to-day services from HA (including automating chore completion with NFC/RFID tags) without having to use the Grocy UI. I use the chore tracker every day and today was the first time in months I actually opened Grocy, and that was to double-check that there was an option for adaptive due dates so I could respond to your post accurately.
This is the field of Preventive Maintenance or Predictive Maintenance.
You somehow want to apply Predictive Maintenance (PdM) based on when the Preventive Maintenance (PM) is performed. That’s because PM is calender or delay based, while PdM observes (the evolution of) real properties.
IHMO, there should be a known recommended schedule for the air filter, which can then be added to a calender or similar to emit the reminder on that preset basis rather than trying to have the machine learn it.
If you want to make some kind of estimate of the delay you could do the following on each button press.
You need two stored values out of:
LastEvent: last time the button was pressed;
EstimatedPeriod: estimated delay between events.
NextEvent is LastEvent+EstimatedPeriod.
On the 1st click, you will set LastEvent, and leave EstimatedPeriod set to 0, null or None, indicating this is not set.
On the 2nd click, you will the EstimatedPeriod to Now-LastEvent, and LastEvent to Now. Then NextEvent
On the 3rd ans subsequent clicks, you compute someting more complex.
You need to choose alpha as a floating number between 0 and 1. alpha is the fraction you will keep fromt the old EstimatedPeriod.
Then `EstimatedPeriod=alphaEstimatedPeriod+(1-alpha)(Now-LastEvent)’, LastEvent becomes Now and NextEvent is LastEvent+EstimatedPeriod.
The smaller alpha, the more the last observed delay is important towords the new estimated period.
When alpha is 0, the last observed delay is fully taken into account! When alpha is 1, the estimated period will never change.
Here is my quick and dirty brainstorm on how I might handle it…
record the initial time and date of the first button press in an input_datetime (call it current) using now(). This will be initializing the system for the next operations to come.
then in an automation when you hit the button the next time in the actions set another datetime (call it previous) to the old current datetime value and then update the current datetime with now().
then you can create a sensor that gives you the number of seconds between previous and current. this is the periodicity.
then you can use a calendar integration to set the predicted next button press time based on how many seconds in the future from the periodicity.
OR if you don’t want a separate calendar entry…
you could just set a third input datetime (call it future) based on how many seconds from now() and the periodicity.
then set a trigger for how long before the future datetime you want to get a reminder.
pseudo-code:
push the button the first time:
"current" = now()
in 3 months push the button again:
set "previous" = "current"
set "current" = now()
set "periodicity" = "current" - "previous" timestamps
set "future" = "periodicity" + now()
trigger notification automation:
trigger = "future" - now() < some number of seconds before "future"
