You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Propose extending the recorder.get_statistics API to expose timestamps of extreme values by adding:
Add max_time and min_time outputs to recorder.get_statistics to show EXACTLY WHEN extreme values occurred.
Current limitations
Currently only get numerical max/min values
No way to know if temperature peaked at 14:00 or 20:00
Forces users to write complex database queries
Missing critical timing data for automations
Technical benefits
✅ Zero breaking changes - Only adds new fields
✅ No performance impact - Uses existing timestamps
✅ Standard implementation - Matches how other systems work
✅ Immediately useful - Solves real analysis problems
Additional context
Example use cases:
⏱️ See WHEN your solar production peaked today
🔥 Find out what TIME your house was hottest
💡 Track exactly WHEN lights turn on/off
Technical proof:
The data ALREADY EXISTS in the statistics table (timestamp column), we just need to expose it.
How others do it:
-- Standard SQL approachSELECTMAX(value) as max_value,
(SELECTtimestampFROM statistics WHERE value =MAX(s.value) LIMIT1) as max_time
FROM statistics s
Mock response:
{
"statistic_id": "sensor.temperature",
"max": 30.5,
"min": 18.2,
"max_time": "2025-06-28T14:30:00+02:00",
"min_time": "2025-06-28T05:15:00+02:00"
}
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Describe your core improvement
Propose extending the recorder.get_statistics API to expose timestamps of extreme values by adding:
Add
max_timeandmin_timeoutputs torecorder.get_statisticsto show EXACTLY WHEN extreme values occurred.Current limitations
Technical benefits
✅ Zero breaking changes - Only adds new fields
✅ No performance impact - Uses existing timestamps
✅ Standard implementation - Matches how other systems work
✅ Immediately useful - Solves real analysis problems
Additional context
Example use cases:
Technical proof:
The data ALREADY EXISTS in the
statisticstable (timestamp column), we just need to expose it.How others do it:
Beta Was this translation helpful? Give feedback.
All reactions