Summary
Add future support for bucket-level or pump-session-level tracking/reporting, beyond the daily aggregate handle-stroke metrics planned in #6.
The motivation is that float-switch transitions are already a rough proxy for buckets or groups of buckets. Today boot_count / 2 is surprisingly useful as an approximate count of filled buckets/sessions, because the ESP32 wakes on float switch up/down events. With the new handle-stroke odometer, we can eventually make this much more informative: per-session dry strokes, flowing strokes, duration, and strokes-per-water-output behavior.
Why this matters
For predictive maintenance, daily totals are helpful but incomplete. We eventually want to know how handle effort relates to actual water production at a smaller granularity:
- How many strokes were needed before water started flowing from dry/rested state?
- How many strokes happened while water was flowing?
- How many seconds did each water-flow interval last?
- Were there repeated short stops between bucket changes where the pump was still primed?
- Are strokes-per-minute or strokes-per-flow-duration trends changing over time?
This could help distinguish normal heavy use from changing pump performance.
Important caveat
Bucket/session-level reporting may generate a lot of extra data, especially at busy pumps. This should not be part of the first Counter 2 Click implementation unless the storage/reporting pipeline is ready for it.
Near-term #6 reporting should stay aggregate-oriented. This issue is for designing the later richer data model.
Possible future session model
A future firmware model could track each water-flow interval as a session-like record:
- session start time
- session end time
- flow duration seconds
- handle strokes before flow start, if pump was considered dry
- handle strokes while water was flowing
- dry/primed classification
- maybe bucket/session sequence count for the report period
Short gaps between float-switch active periods should probably be merged or classified as the same primed pumping session if the water was off for less than a configurable drain interval.
Drain-time / priming rule
Add a configuration value such as:
WATERPAL_MIN_DRY_DRAIN_TIME_S
Default should be conservative, likely around 240 seconds until field testing says otherwise.
If water stops flowing for only a second or two while users swap buckets or workers, the pump is still partially primed. That short gap should not feed the dry-start metric. Only after the float switch has been inactive for at least WATERPAL_MIN_DRY_DRAIN_TIME_S should the next flow-start event be considered a true dry/rested start.
Acceptance criteria for a future implementation
- Firmware can distinguish dry-start sessions from primed continuation sessions using a configurable minimum drain time.
- Firmware can record per-session or per-bucket-ish metrics without losing daily aggregate metrics.
- Reporting/storage format is designed to avoid runaway SMS/HTTP payload size.
- Backend/app can display or summarize per-session data usefully.
- Field testing validates the chosen drain-time threshold and whether short gaps should be merged or tracked separately.
Related
Summary
Add future support for bucket-level or pump-session-level tracking/reporting, beyond the daily aggregate handle-stroke metrics planned in #6.
The motivation is that float-switch transitions are already a rough proxy for buckets or groups of buckets. Today
boot_count / 2is surprisingly useful as an approximate count of filled buckets/sessions, because the ESP32 wakes on float switch up/down events. With the new handle-stroke odometer, we can eventually make this much more informative: per-session dry strokes, flowing strokes, duration, and strokes-per-water-output behavior.Why this matters
For predictive maintenance, daily totals are helpful but incomplete. We eventually want to know how handle effort relates to actual water production at a smaller granularity:
This could help distinguish normal heavy use from changing pump performance.
Important caveat
Bucket/session-level reporting may generate a lot of extra data, especially at busy pumps. This should not be part of the first Counter 2 Click implementation unless the storage/reporting pipeline is ready for it.
Near-term #6 reporting should stay aggregate-oriented. This issue is for designing the later richer data model.
Possible future session model
A future firmware model could track each water-flow interval as a session-like record:
Short gaps between float-switch active periods should probably be merged or classified as the same primed pumping session if the water was off for less than a configurable drain interval.
Drain-time / priming rule
Add a configuration value such as:
WATERPAL_MIN_DRY_DRAIN_TIME_SDefault should be conservative, likely around 240 seconds until field testing says otherwise.
If water stops flowing for only a second or two while users swap buckets or workers, the pump is still partially primed. That short gap should not feed the dry-start metric. Only after the float switch has been inactive for at least
WATERPAL_MIN_DRY_DRAIN_TIME_Sshould the next flow-start event be considered a true dry/rested start.Acceptance criteria for a future implementation
Related