In this case it’s an ESP and I am responsible for the firmware, so not an issue. I am trying to get the change between each reading, and if I could get the device to read & report faster I would.
To be frank, the correct way to implement the behavior I want is to update the derivative integration so that it triggers on the state_reported event. I know for a fact that a PR for that improvement would be accepted; it just hasn’t been done by anyone yet. And I’m not smart enough to do it myself, so having a template sensor trigger off the last report is technically a workaround, but I’m unable to implement that either.
A 2-minute time pattern trigger is an even less optimal workaround. The trigger could be up to 2 minutes delayed from the report since they are not synchronized.
The workaround that works best is to use 2 triggers: one for state changes, and one for state changes using for: with 2 minutes and 1 second, so that it can update to 0 when no state change is detected for over 2 minutes. If I’m able to improve my device and get update rates e.g. every 1 minute, I’ll have to go back and remember to update my template sensor. So, it’s still a workaround, but admittedly not bad.
I agree with your point on not wanting to rely on random update intervals that a user may not control and could change at any point. But that isn’t what I’m doing here.
Most often, the ability to trigger off state_reported events is desirable as a “more optimal workaround” while waiting for an integration to get updated to enable that behavior.