Scheduler component

[Gyran]

A scheduler component

• Component
• Time event
• Sun event

[balloob]

I am not a big fan of the name scheduler as it implies time-related functionality. If we add support for state changes this will not hold. If I look at other systems they use the word 'rules', which I like. What do you think of naming it 'rules'?

Rules (scheduler)
RuleGroup/RuleSet (schedule)
Rule (event)

[balloob]

Let's make sure we create an example schedule.json file in the config directory with an example of all the possibilities for easy initial setup.

[balloob]

Let's make sure the execute part is reused by all the different types (time, sun). Each type should then only have to implement the schedule method.

[Gyran]

I had one thought that all events (or maybe rules) has to have a service that will be called when executed is called. But I don't want to limit a event to so that it has to have an service. It might want to do something else.

[balloob]

Wouldn't it be great that if you add support for an extra action, that all other events get that functionality too? I don't see us getting into a situation where we want to allow a certain action to be done after a certain event takes place, but not another event.

[balloob]

I really like the structure you have decided for the components and I can see this being a great addition to Home Assistant.

Just seeing this code gives me great ideas for the future:

• migrate device_sun_light_trigger to just add schedules
• add it to the frontend: first just seeing which ones are active, then enable/disabling, and finally CRUD.

[balloob]

event_description is a confusing name as we have a variable name called description a few lines above it. Next to that event is already used within Home Assistant. Calling it rule_data would be less confusing

[balloob]

Knowing this is still very much a work in progress I tried to not be too picky with my comments. Hope you don't hate me 🐬 .

[Gyran]

The reason I like scheduler more than rules is that I want something to happen for each event. I would think that a rule group will do something if all the rules are satisfied and something else if not. Now we want something to happen based on some event:

• When the sun goes below the horizon: turn on window lamps
• When device x comes home: start coffeemaker.

If it were rules it could be

• If the sun is below the horizon: turn the lamps on, if not: turn the lamps off
• If device x is home AND sun is below horizon: turn bedroom lamp on, if not: turn bedroom lamp off

The rules could be checked in an interval and respond on the current state of hass but with a schedule we can schedule something to happen when that event occur.

I agree that both components are similar but the rules component is more powerful. But we also might implement the rules component so that it works as the scheduler component?

[balloob]

You are right that rules imply it is either on or off. And that's a valid point. I do see the component evolving that at a certain point it will add support for rules and would like the component name to still hold true. Maybe a name like Automation? But then I guess scheduler would still work too.

We cannot use the class name Event inside the scheduler but should use something that better represents what the class does, ie EventListener. So we get TimeEventListener, SunEventListener, StateEventListener etc.

I also agree with you on the RuleSet being a flawed name. I gave it some more thought and maybe we should use the word Group? That way we can have the schedule component also take over the task of defining groups, since, you know, it actually allows us to define groups. That way the information that is present in the JSON file for each group can be split up into:

• group information: name, description, entity ids
• common event tracking rules/data: days active
• event trackers

[balloob]

Another idea I just had is to have the scheduler component only support the events from Home Assistant core out of the box: TimeChanged, StateChanged.

A SunChanged listener would be defined in the sun component. Each component that supports this would have a method called setup_listener(config). You can then do something like this:

def setup(hass, config):
  for listener_config in listeners:
    if event['type'] in ('time', 'state'):
      # handle locally
    else:
      listener = get_component(event['type']).setup_listener(listener_config)

[Gyran]

Sorry for not doing something with this for a long time. I have been using this component for a couple of weeks now with a config that turns on my lights 45 minutes before the sun sets and turns them off at 22:30 and it works great.
I saw you had created a automation component. Is this component still interesting? I think it can be really powerful.

The config I'm using:

[
    {
        "id": "window_lamps",
        "name": "Window lamps",
        "description": "Turn on window lamps on sunset and turn off at 22:30",
        "days": [0, 1, 2, 3, 4],
        "entity_ids": [
            "group.window_lamps"
        ],
        "events": [
            {
                "type": "time",
                "service": "switch.turn_off",
                "time": "22:30:00"
            },
            {
                "type": "sun",
                "service": "switch.turn_on",
                "event": "sunset",
                "offset": "-00:45:00"
            }
        ]
    }
]

[coveralls]

Coverage decreased (-1.93%) to 56.16% when pulling 7066f25 on Gyran:scheduler into 253e3eb on balloob:dev.

[balloob]

Hi! I did make an alternative but that should be considered a lite version, I feel that this approach is the future. I'll merge it in and we'll see how things evolve over time :-)

[balloob]

Added you as a collaborator on the project. Trying out something I read.

[balloob]

What do you think of this idea?

[Gyran]

Thanks for the collaborator permissions! I'll try to be helpful

The idea is nice, but I see both advantages and disadvantages. I like that the scheduler component is separated from the other components so that it's not necessary to modify others components to add a new listener. But then again, if the listener is a part of the component, it's more likely that the listener will be updated if the component is updated.
I'm also guessing that we might have listeners that isn't part of a component? or can't really be tied to a component? Then I think the current solution is more neat than adding exceptions that won't look in the component. Maybe we could do a mix, so that if the type isn't defined in the scheduler component it can look in the types component?

[balloob]

The advantages would be:

• Keep code that works together, together (all sun related stuff in the sun component)
• Allow people with custom components to add listeners

Time and state would still be things that should be supported out of the box by the scheduler component.

[Gyran]

Refactored a bit in 6f3ef12. What do you think about that?

[balloob]

That's awesome!

Might want to add a check if the component exists / is loaded by calling
bootstrap.setup_component() and check if it returns True. To avoid
duplicate loads add this to the head to the start of the setup_component
method:

if domain in hass.components:
return True

On Wed, Jan 28, 2015 at 11:02 AM, Gustav Ahlberg notifications@github.com
wrote:

Refactored a bit in 6f3ef12
6f3ef12.
What do you think about that?

—
Reply to this email directly or view it on GitHub
#11 (comment).

+1 858 380 9709 ⋅ PaulusSchoutsen.nl
It's nice to be important but it's more important to be nice.