On-Off Blueprint: sunrise/sunset plus scene activation

[alexdelprete]

Details*

• Blueprint name: On-Off

Description*

I love the state persistance concept of the blueprint, but I can't dismiss several automations because they're not based on a specific time but on events like sunset/sunrise (plus offsets).

The standard automation allows this, for example:

Another thing I would ask, if possible, is a scene activation option, like in the standard automation:

Automation YAML config

If the suggested feature or improvement requires to apply changes to the blueprint inputs section, please provide the sample yaml configuration for an automation using the updated blueprint.

Implementation

If you've an idea on how this could be implemented, post here an informal description of the steps necessary for reaching the wanted goal.

Additional Details*

• [ ] I'd like to help developing this feature/improvement.
• [ ] I've found a blueprint/automation not included in this project which achieves the same/similar goal
  • Link to the resources you've found: Resource name here

Additional context

Add any other context about the new blueprint here (corner cases which should be handled, different approaches which can be considered, etc.).

[EPMatt]

Hi @alexdelprete, thank you for reporting.

I love the state persistance concept of the blueprint, but I can't dismiss several automations because they're not based on a specific time but on events like sunset/sunrise (plus offsets)

Another user on the HA Forum suggested to add input_datetime entities for the on_time and off_time inputs.

I think this is the more viable solution, since the sunrise-sunset option can be achieved by updating the two input_datetime entities accordingly, with an external automation. This way we don't overcomplicate the blueprint by adding also the sunset-sunrise trigger.

Another thing I would ask, if possible, is a scene activation option, like in the standard automation

I agree on this, but I think this might be implemented with a totally different blueprint, which runs a certain action at a specific time, checking if it was executed when it should have to (with the same triggers defined in the On-Off schedule blueprint: Home Assistant startup or a custom event).

Let me know what you think about it. :)

[alexdelprete]

I think this is the more viable solution, since the sunrise-sunset option can be achieved by updating the two input_datetime entities accordingly, with an external automation. This way we don't overcomplicate the blueprint by adding also the sunset-sunrise trigger.

Yesterday I installed the sun2 HACS component, which provides exact timestamps for sun related events (dusk, dawn, sunset, sunrise, etc.). So I could feed the input_datetime entities with the sensor values sun2 provides. Looks like a good compromise. :) Flexibility is always a nice thing for an automation.

I think this might be implemented with a totally different blueprint, which runs a certain action at a specific time, checking if it was executed when it should have to (with the same triggers defined in the On-Off schedule blueprint: Home Assistant startup or a custom event).

I'm confused: the on-off blueprint does run an action based on a schedule. But it also checks the state when triggered. Hope I understood correctly its scope. I'm proposing that the scheduling/actions should be more flexible. Activating a scene, for example, is actually an action.

Sincerely, I think that different blueprints that offer the same "core" functionality but in different styles would only create confusion. But that is just my personal opinion obviously. :)

[EPMatt]

Hi @alexdelprete,

Yesterday I installed the sun2 HACS component, which provides exact timestamps for sun related events (dusk, dawn, sunset, sunrise, etc.). So I could feed the input_datetime entities with the sensor values sun2 provides. Looks like a good compromise. :) Flexibility is always a nice thing for an automation

Exactly. I'll move to add input datetimes to this blueprint, to increase its flexibility.

I'm confused: the on-off blueprint does run an action based on a schedule. But it also checks the state when triggered. Hope I understood correctly its scope. I'm proposing that the scheduling/actions should be more flexible. Activating a scene, for example, is actually an action.

The issue is that the blueprint, due to its current definition, only accept entities which can be turned on and off. Unfortunately scenes don't have the ability to be turned off:

Scenes can be activated using the service scene.turn_on (there is no ‘scene.turn_off’ service). https://www.home-assistant.io/integrations/scene/

Hence we need to write a more generic blueprint, which in my opinion might be much more flexible than this one.

Given an action A and an input_datetime I, the blueprint would execute A when current time = I's state. Similarly to the current blueprint, it would check whether the action was executed at the expected time.

Hope this better explains which would be the scope of this new blueprint. :)

[alexdelprete]

Hence we need to write a more generic blueprint, which in my opinion might be much more flexible than this one.

Given an action A and an input_datetime I, the blueprint would execute A when current time = I's state. Similarly to the current blueprint, it would check whether the action was executed at the expected time.

Basically, we need a nice and smart "Matt-style" scheduler. Flexible, easy to configure, that allows to schedule events, scenarios, etc. not only on/off of a single entity/device. :)