@mairas Unfortunately, you’ll have to list the actors explicitly. Groups don’t work and aren’t easy to implement the way Schedy parses its configuration at the moment.
However, dynamic start and end times are possible, have a look at the tips and tricks chapter of the docs.
The problem is that schedules aren’t re-evaluated when rules of schedule snippets start or end, only the native room’s rules are considered therefor
I’m not sure I have understood what that means.
Switch to Schedy and you’re done.
I’m trying right now but I have to admit that installing the latest version of hass-apps is not straightforward.
Even your open window detection will benefit, as that was a bit fragile in Heaty.
I have seen that it needs some edition of customize and automation files, I’ll look to that later.
Can you please tell me what I’m not getting right in my conf please:
rooms:
# Create such a block for every room you want to control.
kid2:
allow_manual_changes: true
rescheduling_delay: 60
climate.kid2:
template: default
schedule:
- x: IncludeSchedule(schedule_snippets["enfants"])
statistics:
The output error is voluptuous.error.MultipleInvalid: extra keys not allowed @ data['rooms']['kid2']['climate.kid2']
@radar And, what’s actually the problem with installing the latest version? You seem to have got it installed. Weren’t the docs at https://hass-apps.readthedocs.io/en/latest/getting-started.html helpful enough?
Sure, you didn’t put the climate into the
actorssection
Yes, I figured out that right after posting the message. And could not edit it because my trackpad stopped working and I could not hit the edit button 
And, what’s actually the problem with installing the latest version?
Yes, I got it installed but the doc do not really refer to installing the latest version if it is not the stable one. I had to go through the git install method. I just needed to know that I have to do it this way.
You seem to have got it installed.
Just for info, it is not clear (at least for me) when one should use t, v, or x in the schedule part. I was using v and had some issues about ERROR schedy: !!! [R:kid2] Invalid value 'IncludeSchedule(schedule_snippets["enfants"])' for actor type 'thermostat': 'IncludeSchedule(schedule_snippets["enfants"])' is no valid temperature. I spent some time before understanding that I had to use x.
But now, it seems ok 
@radar When you also use the latest docs, there is a clear differentiation between installing the stable and development versions. Using the one isn’t really more difficult than using the other.
In Schedy, there is no t, only value/v and expression/x. The first is described in the Writing Schedules chapter and the latter in the Expressions chapter. Your confusion probably arises from mixing your pre-knowledge from Heaty in.
Actually, I followed a link you posted earlier in this discussion for installation.
Concerning v and x, I’m probably mixing but I did not find the explanation enough clear. However, note that I’m not criticizing your work at all, just pointing to what I think should be enhanced. I’m already very grateful to what you’re doing and absolutely aware that I can contribute to the enhancement of the doc.
With the old (= stable) docs, it can indeed be more difficult to install the development version, depending on the installation method.
I do see this as constructive criticism and the project heavily depends on such, so thanks. There should have been an explicit note about the x right at the top of the Expressions chapter. I added it and will commit it tomorrow.
What is confusing, in my opinion, is that one of the apps mentioned in the latest doc is not available if you follow one of the documented installation methods, the pip one. One should just figure out that this method installs the stable version of hass-apps while Schedy is only available in the latest version that you can get through the git method only.
One more thing: the section about window sensor is not clear.
If you provide me some explanation, I can help edit this part. I don’t know what part will require less time to you: explain to me or write it directly 
.
For me it seems to be quite clear in fact.
I am still procrastinating myself to switch from Heaty but already read the docs.
Especially because of the window sensor I am waiting. It took me lot of time to configure heaty to not switch back to default schedule after window is closed if temperature was changed manually at the thermostat.
Maybe that’s due to some occupational hazard (if I translate it well) 
@TriStone Exactly this was reworked in Schedy and will always reset the previous value, no matter if that was the scheduled or a manually set one. The OVERLAY marker takes care of it.
@radar Just to prevent confusion, could you give me the exact link to the section that’s not clear to you?
I just finished re-reading the doc and I have to admit that it is clear. Here is the section I’m reading.
What was not clear is that in the example you mention, you are considering 2 windows in two different rooms that use 2 different thermostats while, I think, you should focus on one instance of thermostat. Then, in the automation part, you can tell the user to add all the window sensor entities in the same automation.
If I had to write it, I would give an example of one room with two windows (window_living1 and window_living2), give the entire example, then consider one or two additional rooms in the automation part.
Ah ok, the idea is that only one schedule rule and one automation is needed, no matter how many rooms or windows per room you have.
BTW, the schedule rule you’ve to add for open window detection will become simpler, as that Python code is going to be provided as a ready-to-use function by the thermostat actor soon. I just have to write the docs for that function.
Yes absolutely. Maybe you can say it in the automation part (even if it has been said before).
One more thing: in the automation part, you mention schedy_heating as the name of schedy instance while in the configuration part, you use schedy. I advise to be consistent and use one of them in both parts.
With configuration part, you mean the sample configuration of Schedy, right? That’s because the sample configuration isn’t specific to heating, but the open window detection is. You may actually have multiple instances of Schedy running for different things. I could add a comment to the open window automation code to state this.
Yes, I meant the sample configuration.
A comment in the open window part should be ok.
@radar I see, there’s already a comment: "“Replace schedy_heating with the name of your instance of Schedy.”