Addition of a schedule configure service

[mreditor97]

Adding in the ability to use a service call to be able to add / clear / change a schedule (so it can be done via automations etc).

I have one problem with the current configuration, it seems to work as expected - except it doesn't seem to last after restarts (it goes back to the previous configuration). I have checked the .storage/schedule file and it doesn't get updated after a update despite every other service example doing it in the same way that I have used.

When calling the service, it will tell you that you are overlapping previously set times if you press the call service button twice - which is correct. So I know that the Home Assistant state machine is getting it - the states are updated in the user interface too. If a time window is covering the current time it the state of the schedule turns to on as expected. The problem seems to be when I click on the schedule itself to edit it, it does not show the adjusted values - even though the state has changed to match what is happening behind the scenes.

If I could have some help on figuring out the reason for this would be greatly appreciated.

Proposed change

The addition of a schedule service to allow the adapting of a schedule via automations.
I am using it to block out a day within a schedule of mine just by the press of a button (for user friendliness and ease).

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hey there @home-assistant/core, mind taking a look at this pull request as it has been labeled with an integration (schedule) you are listed as a code owner for? Thanks!

[frenck]

I really do think we should not add a service like this.

It will be complicated and is actually simulating an API. In such cases, templates or a calendar service would be much more fitting.

This PR doesn't actually change the schedule, additionally, how would this work for YAML users?

Looking at other helpers (like the input_* helpers), they have services to change the state. Lookint at any otherintegration, we do not have services to change integration configuration. This service introduced in this PR is not about changing the state, it is changing the configuration; which we general don't have anywhere.

../Frenck

[mreditor97]

It will be complicated and is actually simulating an API. In such cases, templates or a calendar service would be much more fitting.

The addition of a calendar service would be useful. Are you thinking the ability to add and remove items on a calendar via automations?

Looking at other helpers (like the input_* helpers), they have services to change the state. Lookint at any otherintegration, we do not have services to change integration configuration. This service introduced in this PR is not about changing the state, it is changing the configuration; which we general don't have anywhere.

Instead of this, do you think the addition of schedule attributes (attributes for each time schedule that can be configurable within a schedule) would be more useful?

This PR doesn't actually change the schedule, additionally, how would this work for YAML users?

I now understand that it is only changing the state, due to it requiring a configuration change instead of a state change for the schedule sensor.

I believe the ability to change the schedule at a push of a button would be beneficial to end users. What is your thoughts on this?

[frenck]

The addition of a calendar service would be useful. Are you thinking the ability to add and remove items on a calendar via automation?

There is an architectural issue and development progress on this. However, not directly related to this PR.

Instead of this, do you think the addition of schedule attributes (attributes for each time schedule that can be configurable within a schedule) would be more useful?

I don't understand the question. My initial response would therefore be: No.

I now understand that it is only changing the state, due to it requiring a configuration change instead of a state change for the schedule sensor.

I believe the ability to change the schedule at a push of a button would be beneficial to end users. What is your thoughts on this?

See my previous response.

[balloob]

I agree that this adds complexity we shouldn't want. If you know a time it should fire, you could set an input boolean state or keep an automation running.