[feature request] Add possibility to group action on multiples schedules

[dj4ngo]

Hi,

TL;DR : I need a way to activate/deactivate easily all schedules managing the same entity without knowing how many schedule rules I have been defined.

Context

Scheduler-card is a really powerful card, allowing non-technical people to create/modify easily some schedules. Thanks a lot for this tool. This allow me to let my family creating / deleting some schedule. This is really cool, that was my target when I decided to use it.

I am using it to manage all my heaters. I've created one input_select per heater with 4 modes : unfreeze, eco, comfort, off.

I would like to implement several things on top of these standard schedules. I would like to change heater mode when the window is open; or setting some away or vacation mode, changing the heater modes to unfreeze or eco.

To perform that I need to be able to find all schedules related to a specific heater and deactivate all switches to ensure the scheduler won't change the mode; then I need to change my input_select to the desired mode. Once back or the window closed; I'll need to do the opposite to reactive scheduler to a standard mode, letting scheduler changing my select to the right mode; it is doing it very well.

To perform that I need to be able to discover automatically all switches generated for a single entity and change their status.

Proposal

1. One solution could be to propose a way to define, per card, the default name pattern. This could be for example in my context an automatic move from "Scheduler #xxxx" to "scheduler_heater_room1_xxxx". This is going with a way to filter (surrely with templates) only entities matching the right patter to perform actions. I am currently blocking on this point, maybe due to a lack of knowledge of hass. I am currently changing all schedule name when someone create one to gives it a human understandable name and adding it into my differents automations.

2. An alternative could be to use the entity name into the generated name. This could create some easily parsable names and more human understandable. This solution leads to the same issue than the previous one, this is not easy to use after, even with templates.(This is not documented, but if you have the solution I'll make a PR on hass documentation to improve it on that.)

3. My prefered choice : Scheduler could create a group with all switches managed by a single card. With this solution my wish can be accomplished through this way : https://www.home-assistant.io/docs/configuration/templating/#working-with-groups Group is an official entity of homeassistant so many examples exists about how to use it, I find it better than performing some regex based rules. The group name could be the card name (or generated from it to have a canonical name), or an additional string.

4. Scheduler could create a group for all entities managing a single entity. The name can easily be generated to something like scheduler_entityname. This solution could fit my need but disallow to manage multiples entity with a single group; but on an other way allow to have a single card managing différent entities not in the same group.

[nielsfaber]

Thanks for spending time on this extensive introduction! Very good that you considered all the options..

I feel obliged to mention this one:

then I need to change my input_select to the desired mode.

not mode, but option ... I made that mistake once 😉

My thoughts on this:

• Option 1+2: not a good solution. The friendly_name (at least, I assumed you meant this by 'name') is really only intended for visual purposes (not only in the card, in all of HA). Better not to abuse it for scripting purposes. I agree that a standard format would be helpful, but it will be difficult to guarantee uniqueness. There are plans for allowing schedules with multiple entities and/or actions.

• Option 3: good idea, I like it! I think it's quite easy to set up. There is a group.set service which seems to allow making changes to the entities inside quite easily. The entity ID for this group is a tough one... The card name is not very suitable IMO, since this is not guaranteed to be unique (you can even hide it if you want). It's important to make clear which parts of the functionality belongs in the scheduler-card and which part in the scheduler-component. I would prefer the component to manage this group as it is has nothing to do with the frontend, but it creates some (extra) dependencies (communicating a card identifier to the backend).

Do you have something in mind regarding displaying this group entity? Would it be visible to the user somewhere in the card?

• Option 4: maybe we can achieve a similar functionality by adding an extra service for scheduler, which allows you to turn_off or turn_on multiple schedules at once, based on the provided filter (like list of entity_IDs).

Maybe its good to realize that I'm planning to move the communication from the card to the component to Websocket API. It will take some effort to get here, but it allows MUCH more flexibility (such as bi-directional communication). Currently the entity_IDs are hardcoded to switch.schedule_xxxxx (as you know), which is basically the only way for the card to identify the schedules. With websocket API this requirement will be dropped.

[dj4ngo]

Ah ah, yes you're right about the Mode vs Option ! ;) Definitively !

I am really unfamiliar yet with home assistant code, and so about scheduler one. I am testing Home assistant since around a week now. I just can trust you about how to implement such kind of thing. Managing the group from the component makes totally sense IMHO. TBH I do not know yet who is creating the switches and event not where the schedules are stocked. This will be the next point I'll check, how to backup it, or automate rules creation... but that's another point.

Regarding where to display it, hum I have some lacks on the card, but it's hard to have all data and at the same time a small footprint... The filtering you made is pretty good. When I started with this card, one thing I was looking for on the card is the day of the automation. I am, until now (still building my domotic first step) using only schema and I am setting several schema for each entity managed due to days. I cannot find on the card the days ... It may could have been great to have a "few letter code" like "Mo Tu Th Fr" printed on the schedule entry on the card for example to know that this schedule is running on these days. (There is nothing to do with the current subject, I know, if it makes sense to you this may can be done in another Issue) Regarding the name of the group entity, I do not need to have it visible in the card, since like you said, only friendly name should be show (an by definition this one won't be so friendly), but this one should be show in the Edit page.

We can imagine some default name (like you generate with switches), or letting empty can mean no groups to create .... I have no advice on that.

Regarding your websocket API point, I'm too new in home assistant to understand what are the differences in term of functionalities. I know what is a websocket API (and my first try was to check where it was but I did not find it ^^)

Regarding the future of this project, more than websocket api, there is one other point. My feeling is that being able to schedule easily some tasks is a super basic functionality of a domotic engine, I'm just surprised that home assistant (which is a great great tool in term of functionalities but in term of code philosophy too) does not have it embedded. My feeling is that scheduler should evolve to be more and more proach from home assistant philosophy to be one day potentially included in it. One surprising point to me is that scheduler does not generate yaml definition of the schedule and is not able to read yaml definition to match the way we are configuring the rest. This cannot be used like the rest of the config otherwise it requires a restart of the whole server each changes in schedule, but I think there might be something in balance to do. If this point is relevant to you, once again, to keep this issue clear, we can open one other to discuss it.

[nielsfaber]

I am, until now (still building my domotic first step) using only schema and I am setting several schema for each entity managed due to days. I cannot find on the card the days ... It may could have been great to have a "few letter code" like "Mo Tu Th Fr" printed on the schedule entry on the card for example to know that this schedule is running on these days. (There is nothing to do with the current subject, I know, if it makes sense to you this may can be done in another Issue)

The (localized) names of the days of the week are taken from your browser (both the long and short version). Naming is all fixed by ISO standards. Its the same approach as HA uses.

I'm just surprised that home assistant (which is a great great tool in term of functionalities but in term of code philosophy too) does not have it embedded.

Well, AFAIK there are only like 10 people working on HA, the rest are hobbyists who grow something until its mature enough to merge with the core. This is pretty much how it usually works (community driven). Except that this integration is a frontend+backend combination, which you usually don't see. I already talked with Paulus about merging this component and he's open to it. But there are some hurdles to take still.

One surprising point to me is that scheduler does not generate yaml definition of the schedule and is not able to read yaml definition to match the way we are configuring the rest.

YAML is intended for configuration by user. There's no need for that with scheduler since it automatically generates entities. Made this choice together with the developers of HA as well.

I prefer if you stick to the topic of this issue from here on.

[SlavikS-PL]

@nielsfaber - GREAT work. This is the card and commponet I was looking for my heaters schedule. Thank's for sharing it. I was looking for this feature as well. For me displaying group entity in the card is not needed. Service also will be very good solution. @dj4ngo I thing I know what you mean about displaying days in row of scheduler card. I modified display_options in code editor to get it:

display_options:
  primary_info:
    - '{entity}: {days}'
  secondary_info: 'Closest action: {relative-time} - {action}'

At the moment, to avoid run scheduled action I use several HA boolean helpers and conditions in option part of the card. Disadvantage of this is to remember to set up all this conditions every time you create new schedule. I was looking a way to add this conditions automatically, but if we would have requested feature it will not be needed. Or maybe some new section possible to add in code editor to set up default conditions of the card. I use multiple cards - one per thermostat.

[dj4ngo]

@SlavikS-PL Thx for this information, didn't known it. Regarding my implementation to turn-off all schedule of an heater I am using a method based on the schedule friendly_name. I define a name : schedule_bed2_xxxx and disable all switches having a friendly_name starting by this pattern. Here is my automation

- alias: Start/stop bed2 schedule
  trigger:
    platform: state
    entity_id: input_boolean.bed2_schedule
  action:
    data:
      entity_id: >-
        {%- for i in states.switch if i.name.startswith('schedule_bed2') -%}
        {{ i.entity_id }}
        {%- if not loop.last %},{%endif%}
        {%- endfor %}
    service: switch.turn_{{ trigger.to_state.state | lower }}

---

Now, let's stay focus on this feature ...

Just to resume here the target (please correct me if I'm wrong) :

Functionalities :

• Creating one homeassistant entities group per scheduler card. This group should contain same entities than scheduler internal group.set.
• Regarding the name of the group : This must be configurable in the card options. We have to status for the default value. Do we generate a random name (like schedule) or do we create the group only if the user specified a name ? (my preference is for generating a random name). We should define here the pattern to use.
• This group have to be updated each time the card is updated to keep the group in phase with all schedules.
• This feature as to be quite stupid (at least for a first version) and no mechanism to remove a specific schedule from the group is planned; all schedules manages by a card should remain in the group.

Implementation :

• The group creation and management have to be performed in the scheduler-component.
• The modification of the group name must be performed in the UI, so in the card.

---

I am quite blind on the implementation, since do not really know the code. I would like to help on it and can began to try somethings. I think I'll need you @nielsfaber to guide me during this, (if you don't already have implemented it since you're a super fast PR implementer ;-) ). Could you please leave here some additional specifications/guidance on how to implement it ?

[KTibow]

@dj4ngo usually GitHub comments are short and simple, unlike emails. Mind splitting up your comments, instead of using headers?

[nielsfaber]

@KTibow I'm happy with his structured comment! Don't be too strict on him 🙂

@dj4ngo I think it should roughly be done like this:

1. Find a way to assign/retrieve a unique ID for each scheduler-card. I would prefer if this is not set by the user, but I don't see a way how.
2. Have this card ID sent to the scheduler-component with every schedule modification (service calls).
3. The scheduler-component will keep track of all schedules having a certain ID, and generate / modify the group entities.
4. The scheduler-component will implement turn on and turn off functionality for these group entities.

Most work will be on the component/python side actually. I would like to keep this feature as optional, because I can imagine not every user wants the extra group entities.

Food for thought:

• There is currently a show-header-toggle option in the card, that gives you a 'master' switch to quickly enable/disable all schedules in a card. Maybe your functionality should be a replacement for it (the master switch would also toggle the group entity).
• Maybe some users would like to create groups with only couple of schedules of a card. So it would be best not to limit the grouping per card, but also other ways (like per entity / entity-domain / weekdays vs weekends)
• Maybe it would be useful to be able to visualize the grouping in the card in some way.

[dj4ngo]

@KTibow: I'm not really sharing this feeling about what should be a feat request comment, the projects I'm working with have some bigger templates on feature requests , here is some examples :

• https://docs.openstack.org/keystone/latest/contributor/proposing-features.html
• https://docs.openstack.org/rally/latest/feature_requests.html
• https://github.com/ansible/ansible/issues/new?template=feature_request.md
• https://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-pep

But it doesn't matter on my side, I heard you and will be more concise and split it into subject dedicated comments. By the way, is there any IRC channel, discord one or other way to reach you for side discussions dedicated to scheduler ?

[dj4ngo]

My understanding on how groups could be defined and schedules could be added to a specific group could be to generate a list of groups in the card options. Then we could have a select into each scheduler option to choose the group (or maybe a list of groups). We may could, I don't know choose a color while defining groups to print a small colored point into the UI to show in which group/groups the schedule is.

I think this approach is a bit more far than my original need which is to have "nothing to do" to automatically add a schedule to a group. The idea was to never forgot a schedule even if it has been created by non-technical person not aware of all automations behind.

An other approach could be to generates groups anyway, one 'all' group with all tasks of the card; another one per entities managed by scheduler, some others to groups entities having the same days and activate or not these automatics groups from the option panel. Since these groups will be manage by the component, shouldn't we define the group option into the scheduler-component options in configurations -> integrations ?

[nielsfaber]

I like the idea of assigning groups in the card, and give them a colored marker (as my email inbox). Unfortunately the word group is already in use for an entire different purpose. I wish now I chose something else, like 'entity categories'.

I would put the whole group management in the UI, so add it as a field where you also can provide a friendly_name. I picture a dropdown menu with your previously defined groups, together with the option to add a new one.

In my opinion it shouldn't be something that you configure in YAML (or the card editor). It would create quite some complications, because users can decide to throw away their YAML config, or rename/regroup stuff. It would become difficult to have the scheduler-component keep track of all these mutations.

Since these groups will be manage by the component, shouldn't we define the group option into the scheduler-component options in configurations -> integrations ?

This is really tough to do. I looked into this when starting this project, the functionality you can make here is quite limited. It's really only intended for providing login credentials and such. You cannot create a fancy form.

[KTibow]

Is there anything you have against a scheduler as a panel instead of card, @nielsfaber?

[nielsfaber]

@KTibow I made the scheduler as a way to quickly set timers for devices through my phone. On my phone I use the Kiosk mode, I don't use panels here. So for my personal use I don't want scheduler to be a panel, but users are free to add the card in a panel. The UI is not optimized for panels though. And I don't feel like supporting 2 different UI's.

[lmagyar]

My 2 cents: Configuring grouping in card config seems strange to me now (even if I suggested something similar in #237). If the scheduler yaml config only defines grouping as "views" (like database views), modifying the yaml seems to be a smaller problem: scheduler deletes all the groups previously created by itself and recreates (and maintains) the new groups based on the scheduler yaml config. This yaml config can have some nice UI.

Disclamer: I'm new to HA, I don't even feel, whether it is a good or bad idea.

[lmagyar]

I would put the whole group management in the UI, so add it as a field where you also can provide a friendly_name. I picture a dropdown menu with your previously defined groups, together with the option to add a new one.

If users can freely edit grouping, this will make it impossible to use groups in scripts/automation. It's like asking them to set friendly_name to something to make the system function properly. If the "use case" for grouping is to support the "developers", users shouldn't be able to mess with these values/settings!

[nielsfaber]

Configuring grouping in card config seems strange to me now

Currently groups are only intended as a means for categorizing the entities in your HA config. This only exists within the card and doesn't set any property to the created entities. So in this discussion they are not relevant.

If support is added for creating groups of schedules (created entities), I will probably rename this to categories or something, to avoid confusion.

If users can freely edit grouping, this will make it impossible to use groups in scripts/automation.

I have requests from users asking for grouping:

• per scheduler card
• per entity (e.g. thermostat programs)
• per weekday (workdays vs weekends)
• arbitrary (e.g. all vacation-mode schedules)

So by hard-coding the grouping it will never satisfy all use-cases. Users will have to be able to assign a schedule to an existing group, and create new ones. In my opinion this should become part of the UI.

It's like asking them to set friendly_name to something to make the system function properly. If the "use case" for grouping is to support the "developers", users shouldn't be able to mess with these values/settings!

I don't know what you mean with this at all. The groups would be only there for helping the user with their customizations/automations. The whole point is for them to be able to mess with it.

[dj4ngo]

My understanding from @lmagyar remark is that if users need to affect each new schedule to a group (defined in the UI), this become useless. It mean that everytime you create a schedule you have to think about changing its group and this is not "non-developers" compatible. You have to understand/know that some automations needs it. This is the actual solution I described below by using friendly_name to group my schedules. This definitively have to be automatic.

You already answered than @nielsfaber since the configuration in the UI is to create some automatic affectation rules and not to manually affect a specific schedule to a specific group (or it is partially right because of arbitrary mode).

[dj4ngo]

To summarize the UI specs :

I see two options; and still do not really understand which one you have in mind Niels :

Option 1 - most customizable

• Define a list of HA groups

For each groups :

• define a name
• define a friendly_name
• define some group members

Groups members would be a multiple selection of :

• already existing schedules managed by the current card (for arbitrary mode)
• a per entity option; then select the entity
• a per weekday option; then select the weekday
• a per schedule card option (then take the current card)

Option 2 - most "simple"

Here just selecting simple choices, like some checkbox for example with this list :

• per scheduler card
• per entity
• per weekday

And all groups are automatically generated with some predictives names.

Comportment in detail :

• "per schedule card" : All schedules created in this card
• "per entity" : a group per entity will be created. This can be a cross UI cards option, I think it should include only schedules defined for an entity managed by the current card.
• "per weekday" : 9 groups could be created: 1 for all schedules using weekday; 1 for all using wee-end; and One for each day of the week including all schedules running on this day. Same remark as previous; it could be a cross UI one; but it should be more intuitive to limit it to current card since the parameters are set into the card.
• arbitrary : I do not see any easy way to make this kind of groups with this option.

I can see a third option

Option 3 - Config placed in the scheduler config - Or no configuration at all

We can use the same principles than option 2 but making the configuration in the scheduler-component itself. I understood you cannot make some advanced config there; but this could be basically just some booleans to create the comportment described in Option 2.

My original thought was to have this group generation performed "by-default" and so there is no need of a config for this, neither in the card nor in the component. Just a creation of all groups described in option 2; letting the user using these or not.

[lmagyar]

I agree with @dj4ngo, though Option 1 is not clear to me. :)

Lets distinguish 2 types of users:

• average users wife, kid, who uses the UI, and will never ever set up any automation, and will forget to assign any arbitrary scheduler group
• develeopers: who set up automations, write scripts, and can't automate on arbitrary scheduler groups (created through the card UI)

Lets distinguish 3 types of grouping:

• predefined (developers will enable them in integration or scheduler component config yaml): per entity (e.g. thermostat programs), per weekday, etc.
• custom (developers will set them up in scheduler component config yaml): per scheduler card, per "something custom condition defined in the yaml" (see below)
• arbitrary (average users can define & assign them through card UI): this makes no sense for me, shouldn't exist, we can't set up automations on them

Are there requests, that can't be solved with predefined & custom groups?

• vacation-mode schedules: create a vacation mode scheduler card and a non-vacation mode card, when the system goes into vacation mode, scripts can turn off non-vacation schedules and even conditional cards can hide non-vacation scheduler cards

Brainstorming:

• Custom & per scheduler card groups: logically equal to #237. If we allow multiple "names" or "tags" per card, it is possible to assign schedules to multiple groups (groups per tag, tags defined in card).
• Custom & per "something custom condition defined in the yaml": nothing clear in my head, just some condition list, evaluated on each schedule's, or scheduled entity's state/attributes.

[nielsfaber]

I'm starting to think this functionality does not fit in scheduler. What you seem to be looking for is some sort of 'HA entity scanner', that looks for patterns in the friendly_name / entity_ID / entity attributes and creates/maintains groups with entities that match these rules. IMO this should/could become a standalone integration. It seems quite a simple thing to make, perhaps it already exists even.

I'm working on an update of the scheduler-component, which will allow more free choice in the entity_id and attributes of the generated switch entities.

After all, scheduler is just a variation to regular HA automations. I could also say I like to have all automations for my thermostat grouped together such that I could easily disable them all at once. Why should such organization need to be provided by scheduler?

[dj4ngo]

I think I disagree a bit with that. Scheduler is creating the scheduler switches; and offer the possibility to enable/disable them so it could be an improvement to offer a way to easily sort/class them.

The main need here is to perform some automations on a group of schedules. Since schedules can be created/deleted while during HA life this have to be automated; no way to know in advance how many schedule there are and which will be deleted/recreated.

One way to perform this is through templates like I described in https://github.com/nielsfaber/scheduler-card/issues/219#issuecomment-729169942 . The major problem here is that the generated names are all the same regardless the entity managed, the scheduler card or weekdays...

Regarding your next improvement to allow being more free on the "choice in the entity_id and attributes of the generated switch entities" I think we need to know a bit more to see if this will match this need.

If we are able to have an entity_id having the card id/slug; the entity managed, the work days; directly in the name; we may can be able to perform some filters on theses without requiring a group. I just find group easier to parse since it is an HA object, but I can deal without it. I think the best way to do this could be to have some user defined templating names for these switches that could allow us to define the most relevant name for our use-case.

TBH, I need to have a look closer on automations generated by scheduler to understand if there is some easier way to find all scheduler switch managing a specific entity for example; but my feeling is that it wont be easy to filter on weekday since this is THE goal of the component and all your development is for setting this...

[lmagyar]

Yes, deleting my comment will solve the problem...

@dj4ngo I created the schedule grouping Python scripts. These will recreate the groups on each entity registry change and restart. See https://github.com/lmagyar/nielsfaber_scheduler-card_issues_219

Add python_script: to your configuration.yaml, restart HA Core. Later you can reload the scripts without restart.

You will need only these automation actions for per entity schedule grouping (itt will not delete existing groups, I hope):

    - service: python_script.remove_all_groups
    - service: python_script.set_thermostat_schedules_group_per_all_thermostats

In scripts/automations you can use these groups like:

turn_on_XXX_thermostat_schedule:
  sequence:
    - service: switch.turn_on
      data:
        entity_id: group.XXX_thermostat_schedules

Disclaimer: This is my first Python script and I'm new to HA, I'm not aware of the unintended consequences.

Without scheduler component support, without card specific extra attributes in schedule entities: it is impossible to create per card groups, like "Vacation schedules".

[nielsfaber]

Without scheduler component support, without card specific extra attributes in schedule entities: it is impossible to create per card groups, like "Vacation schedules".

Please give me a week or so to settle some things I'm working on currently. Afterwards, we can discuss which attributes should be exposed to facilitate this functionality.

[nielsfaber]

With the new upcoming version of the scheduler component, the entity ID will be based on the name entered in the card: You can also update the name at a later point, the entity_id will be updated. Leaving the name field empty in the card, will fall back to the current random-generated codes.

The attributes are currently all removed, as the card no longer uses them. Ofcourse we can discuss practical attributes to add to be able to identify the schedules.

[nielsfaber]

I am closing this issue since there hasn't been any activity on this for a while (cleanup of issue list)

[lmagyar]

Hasn't been activity on this, because

Please give me a week or so to settle some things I'm working on currently. Afterwards, we can discuss which attributes should be exposed to facilitate this functionality.

In lack of any built in support, my workaround currently is: family members name schedules and add "attributes" to the name like [default] or [early] or [away], automation collects these, add it to an input_select, and the "global system state" can be changed by this input_select: automation turns on/off schedules based on this input_select value. It works, but family members can easily misspell something.

It would be a stable solution, if an admin could define these "attributes", scheduler cards could add these attributes to the schedules (without user intervention): automation won't get simpler, but accidental typo-s won't cause malfunction.

@dj4ngo asked for groups. Creating groups is more complex, I agree, it's beyond the scope of the scheduler, but adding attributes to the schedules isn't. It would add the necessary information to the schedule, everybody can work from this point on their preferred solution (groups and/or automation).

[sddgit]

In lack of any built in support, my workaround currently is: family members name schedules and add "attributes" to the name like [default] or [early] or [away], automation collects these, add it to an input_select, and the "global system state" can be changed by this input_select: automation turns on/off schedules based on this input_select value. It works, but family members can easily misspell something.

I know this is a bit old, but I'd like to do something similar, and I'm wondering whether you can enlighten me as to how you accomplish your workaround using automations (very new to HA). I'd like to set up schedules for pool equipment that cover different running times depending on the time of year. I can come up with some standardised naming for each individual equipment schedule. But how do you use automation to weed out all the ones that have, say, summer in their name, and turn those off, while turning on all the ones with, say, winter? I guess it may be possible to use the new tags facility instead of names, but I still don't know how to use automations to affect them. Hope you can help.

[lmagyar]

Wow! Gosh! This tag support seems to be fantastic! (I've only read the docs.) I suggest to use it with tags like "summer", "winter", and on the UI you can turn on/off all "winter" or "summer" schedules, though it seems to me it won't protect you from accidentally turning on both "winter" and "summer" tag "group". I think some automation is required to turn of the "other" schedules. And it requires to define and add these tags to the UI in advance.

I went down a different path, I group the schedules around the thermostats/rooms (this never changes), and the "tagging" is done through the name of the schedule, it is flexible, though requires black magic on automation side. I will copy-paste my config and delete out the irrelevant parts (90+ % of it), but if you new to HA, it is a complex solution. I will write some short readme for the repo. Here it is: https://github.com/lmagyar/GH_Comment_908308830