Add the time domain (time entities) to the list of standard configuration actions

[pdcastro]

Checklist

• I checked for similar existing requests (both open and closed) before posting.
• My request is generic, other users may benefit from it too.
• I will participate in further discussion about this feature and can test it (if requested) once it's done.

Proposal

Many Home Assistant integrations (components) provide entities in the ‘time’ domain (see Time Entity docs), e.g. time.start_time or time.duration, comparable to other perhaps more common domains such as switch, e.g. switch.garden_sprinkler (see Switch Entity docs).

The scheduler card’s standard configuration ignores those time entities though. Visually, this means that time entities are not included in the following list:

As per title, this issue requests that time entities be added to the standard configuration action list.

Whether or not time entities can currently be used through the scheduler card’s customize configuration, the point of this issue is to request that time entities be included in the standard configuration action list, so that they work “out of the box”.

Additional info

Why would anyone want to schedule the setting of a time? I.e. calling a time entity’s set_value() method at a chosen (scheduled) time.

There are Home Assistant integrations that control physical devices primarily through the setting of one or more of: start time, end time, target time, and duration. These integrations may not expose, say, switch entities that allow the physical device to be turned on/off directly through the Scheduler Component & Card at certain times. This may be because the physical device requires local on/off control by its algorithm, or centralized control by a cloud service. For example:

• Devices such as yogurt/cheese makers, fish tank CO2 diffusers, etc. that start operation when a duration is set through a time entity rather than an on/off switch, thus maintaining continuous operation even if the network connection to the Home Assistant instance is lost, or the Home Assistant instance goes down for maintenance.

• An electricity supplier’s API such as that of Intelligent Octopus Go (HA integration) that centrally controls the charging of electric cars around the country and does not allow the car charging to start or stop by a direct on/off switch command from its Home Assistant integration. Instead, it requires a directive such as “charge to 80% by 7am,” the latter set through a time entity.

Even though such devices or integrations allow the user to set the relevant start/end/target time or duration manually through the Home Assistant frontend or through automations or scripts, using the Scheduler Component & Card to set those times or durations would be most convenient in many cases, altogether avoiding the need to write custom automations or scripts. For example:

• A Home Assistant integration provides time entities to allow configuring start and end times, but it does not allow configuring different times for different days of the week. The Scheduler Component & Card could be used to schedule changes to the start and end time entities’ values on weekdays and weekends.

• A Home Assistant integration provides time entities to allow configuring start and end times, but only two “slots” a day (e.g. from 1am to 7am and from 8am to 2pm). But the user wanted to set a third slot. A solution is to configure a single slot, and use the Scheduler Component & Card to change the values of that slot’s time entities three times a day, thus covering the desired three slots.

• A Home Assistant integration provides a time entity to set a capped duration, e.g. a duration no greater than “9:59” (9 hours and 59 minutes) simply because the physical device’s front panel has a 3-digit 7-segment countdown display that displays the duration. To get around this limitation, the user would like to use the Scheduler Component & Card to schedule a change to the duration, for example scheduling two consecutive 6-hour sessions as an alternative to a single 12-hour session.

[pdcastro]

I have put together PR #808 that addresses this issue. Feedback is welcome!

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[pdcastro]

Not stale - awaiting codebase rewrite as per PR 808 comment.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[pdcastro]

Bump