Energy Dashboard: Add configurable sampling interval for energy sources to reduce recorder writes

[satscan1]

Describe your core improvement

Add a configurable sampling interval for Energy Dashboard sources so users can control how often statistics and cost calculations are updated (e.g., native / 1 min / 5 min / 15 min). This would allow trading temporal granularity for significantly lower recorder write rates while keeping the Energy Dashboard fully functional at the hourly level.

Current limitations

Today, Energy Dashboard sources are effectively event-driven at the native update rate of the underlying sensors (e.g., DSMR/P1 ~10s, PV power updates). Even when users create trigger-based “slow mirrors”, the statistics and cost pipelines still react to every state change, resulting in very high recorder write rates (tens of thousands per day). There is no supported way to tell Home Assistant to sample an energy source at a fixed interval, so database I/O cannot be bounded without giving up Energy Dashboard functionality.

Technical benefits

Dramatically reduced recorder write rates for high-frequency energy sources

Better scalability for installations with fast meters, PV inverters, EV chargers, and batteries

Lower database I/O and storage wear without losing Energy Dashboard features

Clear, explicit trade-off between time resolution and system load (opt-in per source)

Backward compatible: default behavior can remain unchanged

Additional context

In real-world setups with DSMR/P1 and PV inverters, Energy Dashboard commonly produces 25k–35k+ writes per day, of which a large portion is inherent to the event-driven statistics and cost sensors. Since the UI already uses hourly statistics, allowing a configurable sampling interval (e.g., 5 or 15 minutes) would keep user-visible results effectively the same while reducing writes by an order of magnitude. This would make Home Assistant’s energy stack much more database-friendly for long-running and high-frequency installations.

[MindFreeze]

The energy dashboard uses the generic statistics data from core right now. There is no special recording and I don't think there should be. So this would require statistics to be configurable for all entities.