Add an estimated ready time sensor for bodies of water

[jaltmayerpizzorno]

What

This adds an Estimated ready time timestamp sensor for each body of water. It shows when the controller predicts the water will reach its set point, which is the same prediction the Poolside app shows as "ready in …".

It's the same change as PoolsideStan/home-assistant-core#1, applied to the custom component. That PR has the details and the tests.

A note on syncing

I know this repo is synced from the core branch with scripts/sync-from-core.sh. I'm opening this PR purely as a convenience, in case you'd like to get the sensor to HACS users before the next sync. If you'd rather keep everything flowing from core and pick it up with your next sync, that makes complete sense. Feel free to just close this PR. Thanks for the integration!

Changes

• sensor.py: a new PoolsideBodyReadyTimeSensor, created alongside the temperature and water-state sensors for each body of water. It reads TargetEndDateTime from the body's TemperatureRiseInformation push. It's unknown while the controller is still sampling (the 0001-01-01… placeholder), once ActualEndDateTime is set, and when no heat-up is in progress.
• const.py: the field and key names, to be imported from aiopoolside.const once Add TemperatureRiseInformation field constants aiopoolside#3 is released.
• strings.json, translations/en.json, icons.json: the entity name and icon.

Testing

I ran it on my own Attendant controller as an installed custom component. The sensor stayed unknown while the app said "mixing water…". Then it showed the predicted time, matching the app's "ready in" to within a minute, and followed the controller's revisions as heating went on.

🤖 Generated with Claude Code

[PoolsideStan]

Thanks for this. The structure fits the integration well: it uses the group entity base, the same unique ID scheme, translation and icon keys, and the shared datetime parsing. A few things before merging:

Match when the official app shows a "ready in" time. Right now the sensor reports TargetEndDateTime whenever it's a real date. The official app only shows a ready time when TemperatureState == "SAMPLED" and HeatingEventType == "NORMAL", and the target is still in the future. Without that filter the sensor shows times the app hides:

• During SAMPLING, the controller already fills in a preliminary estimate before the water has been properly sampled. This also contradicts the docstring's "unknown while sampling".
• During MAINTAIN_TEMPERATURE and LEARNING, which don't represent a heat-up ETA.
• After the target time has passed, which Home Assistant would render as "x minutes ago".

Suggestion: gate on those two fields plus a future check, and keep the 0001-01-01 placeholder guard.

ActualEndDateTime check. The controller clears the live document when a heat-up ends, so this field is never set on the value we read. The check can be dropped, or kept with a comment saying it's defensive.

Parsing consistency. Other JSON-in-string fields accept either a native value or an encoded string, and log a warning when parsing fails. It would be good to do the same here, and to parse the document once per read instead of once per key.

Entity creation. This adds the sensor to every body of water, including ones without a heater, where it would never have a value. Consider creating it the first time TemperatureRiseInformation is reported, the way the chemistry sensors work.

Nit: please add the new sensor to the sensor list in the README.

[jaltmayerpizzorno]

Thanks for the careful review! All addressed in 3eea4e5 (and the same change in PoolsideStan/home-assistant-core#1, where it's tested):

• The ready time now only shows for TemperatureState == "SAMPLED" and HeatingEventType == "NORMAL" while the target is ahead, and it's cleared at the target time if no new prediction arrives, so it never shows "x minutes ago".
• Dropped the ActualEndDateTime check.
• The document is parsed once per update, accepting a native value or an encoded string, with a warning when it can't be parsed.
• The sensor is created the first time TemperatureRiseInformation is reported, like the chemistry sensors.
• Added it to the README's sensor list.