Proposal: Show Rain Delay status on the top-level card

[cmccambridge]

👋 Hi! New to OpenSprinkler, the HACS integration, and this Lovelace card...

At the moment I'm not yet comfortable with how the automatic weather handling algorithms might interact with new seeds in my garden, so I'm managing weather manually with the OpenSprinkler rain delay functionality.

I want to propose the idea of showing the rain delay status on the top-level card while active... similar to the brief banner across the top that you see on the OpenSprinkler home page or mobile app.

I've got a prototype that comes out looking like this... but before I pitch that as a PR, wanted to get your reaction as to whether that's a direction you would be interested in going or not:

Thoughts?

Basically looking to extend the high-level view of what's happening with my OpenSprinkler to also include "nothing... because there's a rain delay."

I'm interested in how to actually update the rain delay from Home Assistant as well, but need to dig into whether that's exposed by the API and integration or not. If so, perhaps it can be exposed through the card similar to the manual station time with the input_number support.

[rianadon]

👋 Hi! New to OpenSprinkler, the HACS integration, and this Lovelace card...

Welcome! I hope it hasn't been a frustrating experience so far.

At the moment I'm not yet comfortable with how the automatic weather handling algorithms might interact with new seeds in my garden, so I'm managing weather manually with the OpenSprinkler rain delay functionality.

I want to propose the idea of showing the rain delay status on the top-level card while active... similar to the brief banner across the top that you see on the OpenSprinkler home page or mobile app.

That's a great idea! Not quite the same, but you could show the rain delay with extra_entities:

type: custom:opensprinkler-card extra_entities: - binary_sensor.opensprinkler_rain_delay_active - sensor.opensprinkler_rain_delay_stop_time

I've got a prototype that comes out looking like this... but before I pitch that as a PR, wanted to get your reaction as to whether that's a direction you would be interested in going or not:

Thoughts?

Basically looking to extend the high-level view of what's happening with my OpenSprinkler to also include "nothing... because there's a rain delay."

This looks amazing! My only nitpick would be to change the date to a relative time (e.g. 70hr, or 30min, or 5s). That will take a lot more code to implement though, so I'm good with just date + time as a first pass.

I'm interested in how to actually update the rain delay from Home Assistant as well, but need to dig into whether that's exposed by the API and integration or not. If so, perhaps it can be exposed through the card similar to the manual station time with the input_number support.

You should be able to find the rain delay through the Rain Delay Stop Time entity. The card collects a list of entities belonging to the OpenSprinkler device, so if you assume the entity id still has "rain_delay_stop_time" (hopefully the user didn't change it), then you can filter for it.

[cmccambridge]

Alrighty, I've got everything working to dynamically filter for the ...rain_delay_active and ...rain_delay_stop_time sensors, check the state of the former and then display time based on the latter. 👍

if you assume the entity id still has "rain_delay_stop_time" (hopefully the user didn't change it), then you can filter for it.

Yes, good point here... I'll add it to the README note about requirements for named entities in the PR.

My only nitpick would be to change the date to a relative time (e.g. 70hr, or 30min, or 5s).

I like that! So, further questions for you, with apologies that I'm a dangerous newbie at best in JavaScript 😄:

I looked briefly at implementing this, and think there are a few possible paths depending on your philosophy about dependencies... what would you recommend/prefer as an approach?

In general I will need to:

• Get the relative time between "now" and the timestamp from the rain_delay_stop_time sensor.
• Select an appropriate relative unit based on the scale... 5 minutes, 15 hours, 2 days, etc.
• Format to a text string

A few options:

1. Follow Home Assistant frontend's lead, and use @formatjs/intl-utils plus Intl.RelativeTimeFormat/Intl.NumberFormat.
   • intl-utils offers selectUnit which does timestamp diffing plus relative unit selection, which are then passed to one of the two formatting options depending on whether we prefer to say "Rain delay ends in 14 hours" or "Rain delay ends tomorrow" versus "Rain delay for 14 hours". (The former does localized handling of relative time in future or past tense... the latter just does the number plus plural (or not) unit).
   • BUT: @formatjs/intl-utils is deprecated. Not sure your stance on taking a new dependency on it, whether or not HA itself does.
2. Use a current datetime library like luxon to do the work. luxon offers DateTime.toRelative which combines the diff and relative formatting.
   • Only formatting option there would be "Rain delay ends in 14 hours" style - I don't see a trivial path to the number-only format ("Rain delay for 14 hours"), though Duration.toHuman is similar with caveats.
3. Write something custom to avoid any new dependencies, at the cost of rewriting some kind of unit selection code. Formatting would still be easiest to do by consuming the localization of Intl.NumberFormat.

Any preferences or recommendations there? Left to my own devices I would probably try (2) with luxon, and create a string like "Rain delay ends in 14 hours".

My other question on any of the above is whether it's safe to rely on browser support for Intl.xxFormat (which all three would likely be using), or if we need to do any of the polyfill work to handle older browsers. What's normal for a custom-card?

Thanks for your thoughts & time! 😁

[cmccambridge]

Quick update: In further testing, I found a bug in the underlying python library that powers the HACS integration. The Rain Delay Stop Time is not actually corrected for OpenSprinkler's time zone settings, resulting in a local timestamp being incorrectly labeled as UTC in home assistant, and badness ensuing when computing a relative time. I missed this when doing simple date formatting since I wasn't pretty printing the timezone...

Working on fixing it quick, then will circle back to this PR since the relative time math really depends on valid underlying timestamps 😄

[cmccambridge]

OK, got the changes to the upstream python library used in the integration merged, so correct timestamp data will be flowing for the rain delay stop time.

I researched the relative time a bit more, and found that custom-card-helpers actually already did the legwork, and exposes relativeTime exactly mirroring the HA frontend implementation.

Let's use that. Details in the PR #17:

• Need to update custom-card-helpers to 1.9.0 to get the latest functional version
• Need to update home-assistant-js-websocket to ^6.0.1 to be compatible with custom-card-helpers in order to share Connection, UnsubscribeFunc, etc.