@roschi
This is a very good proposal. Indeed I do have a schedy switch running too.
This does solve my problem when missing the event by the switch. I now created an automation which runs every 10 minutes to check the state but it is getting far to complex to easily read. Will give this a try
Works perfectly, it now only goes wrong if I manually change my switch state, which is easily solved by removing it from the gui 
It does give the right state if the switch was offline at the moment the tress-hold is crossed
Not sure what happened but it does not work any mre. I enabled debig logging in the switch code and nothing happens when the tres-hold is crossed. This is the log:
2018-12-27 20:21:49.951774 INFO AppDaemon: App initialization complete 2018-12-27 20:21:50.007908 INFO schedy_switch: --> [R:Taste House] [A:switch.heat_house_ex_liv] Attribute 'state' is 'on'. 2018-12-27 20:21:50.009728 INFO schedy_switch: --- [R:Taste House] [A:switch.heat_house_ex_liv] Cancelled re-sending timer. 2018-12-27 20:21:50.011793 INFO schedy_switch: --> [R:Taste House] [A:switch.heat_house_ex_liv] Received value of 'on'. 2018-12-27 20:21:50.013574 INFO schedy_switch: --- [R:Taste House] Unchanged HA state: state='"on"', attributes={'actor_wanted_values': {'switch.heat_house_ex_liv': '"on"'}, 'scheduled_value': '"on"', 'rescheduling_time': None, 'overlaid_wanted_value': None, 'overlaid_scheduled_value': None, 'overlaid_rescheduling_time': None, 'friendly_name': 'Taste House'} 2018-12-27 20:22:27.194267 INFO schedy_heating: --> [R:Studeerkamer] [A:climate.study_wall_thermostat] Received value of 13.0��. 2018-12-27 20:22:27.202732 INFO schedy_heating: --- [R:Studeerkamer] Re-applying the schedule not before 21:52:27 (in 1:30:00).
As you can see I changed a thermostat so it would be below the tres-hold (it was on when I restarted). This was the last part of the log. I waited 2 minutes but nothing happens. Any thoughts?
Would you put the log in a code block please? All the line breaks are gone…
Do you fire a schedy_reschedule event for the boiler switch room when the stats entity changes?
For the next release, it is planned to have a list of entities in the config for each room that should be watched for state changes automatically. You then no longer need these reschedule automations in most cases.
Sorry I did put a preformatted text code around it but it looks like it had no line breaks when I copied it
Do you fire a schedy_reschedule event for the boiler switch room when the stats entity changes?
No, should I? It did work initially so I thought this was not necessary. How do I detect any change in the stat entity?
For the next release, it is planned to have a list of entities in the config for each room that should be watched for state changes automatically.
I think I will wait for that. Until then my automation works fine just a bit frustrating I need so many lines
You just need to change your existing automation to emit the schedy_reschedule event instead of turning the boiler on or off directly.
Look at the first of these examples: https://hass-apps.rtfd.io/en/latest/apps/schedy/expressions/examples.html
EDIT: Why it worked previously was probably because you either restarted Schedy or something else triggered a schedule reevaluation at the right moment, which happens from time to time.
@taste You are welcome to test the new feature, just switch over to the development version. It’s fully backwards compatible, so you won’t break anything.
Docs are updated as well: https://hass-apps.readthedocs.io/en/latest/apps/schedy/CHANGELOG.html
Feels really convenient to get rid of most of the re-scheduling automations.
Of course, everybody else is welcome to test it, too.
I am afraid I need some help. I added this to my schedy_heating configuration:
watched_entities:
- entity: "schedy_stats.schedy_heating_eqmax_temp_delta"
This does not give an error but I do get this warning:
You query the 'max' attribute of 'schedy_stats.schedy_heating_eqmax_temp_delta' in an expression, but the entity is not watched for state changes by Schedy. You should add it to the watched_entities configuration
I tried adding :numeric_state,other_attribute:‘max’ (or without the ’ ') and various other variants but all give me an error:
voluptuous.error.MultipleInvalid: does not match regular expression for dictionary value @ data['watched_entities'][0]['entity']
How do you get to
- entity: "schedy_stats.schedy_heating_eqmax_temp_delta"
You mixed several things here… Either use the single line string representation OR the mapping with entity, attribute and mode.
The warning just sais that you query the entity but didn’t configure a proper watch.
I don’t know how you named the statistical parameter instance, but assuming you named it temp_delta and the name of your schedy instance is schedy_heating, it should look like
- "schedy_stats.schedy_heating_temp_delta:max"
EDIT: I now tried to improve the description of the syntax of the short variant in the sample configuration again. Could you maybe read over it and confirm that it’s understandable now?
EDIT 2: Wait, you added the watcher to your schedy_heating configuration? It should be the instance controlling the switch that needs to be watching…
Got it yes this works. Indeed I mixed it up. Maybe it is better to only support the short format since the mapping with entity will get very long if you need to watch multiple entities. To avoid the confusion you could add an example for this one too. If I look at the code now it is clear but since I know my error it difficult to imagine if I would get it the next time.
btw: indeed I added it to schedy_switch not heating, my bad.
Cool that it’s working. I couldn’t do much testing myself yet 
Hmm, yes, maybe I’ll remove the long mapping format from the docs completely and only show the string variant, however it’s rewritten to the long format internally after all.
Can confirm it really works after a few switches this evening. Will change my other booleans too tomorrow.
Ok, reworked the format description again. The string format now is the only one mentioned.
This is working since last evening using the development branche:
schedy_switch:
module: hass_apps_loader
class: SchedyApp
actor_type: switch
# Enable debugging output
debug: false
watched_entities:
- "schedy_stats.schedy_heating_eqmax_temp_delta:max"
rooms:
house:
friendly_name: Taste House
schedule:
- x: "'on' if float(state('schedy_stats.schedy_heating_eqmax_temp_delta', attribute='max') or 0) > 0.4 else 'off'"
actors:
switch.heat_house_ex_liv:
1 Like
I have an other switch which switches the electric floor heating of the bathroom on/off but only if the outside temp is < 5 degrees C. I currently use an input_boolean as output of schedy_switch and have an automation to drive the actual switch with a condition outside_temp< 5.
I assume if I would do this directly inside schedy the schedule is retriggered at any change of the outside Temperatur so this is etter with respect to load. Or could I do this only when the start time is matched?
@taste You can control the floor heating switch with Schedy directly, procedure is identical to that used for the boiler: a room with the real switch as actor, a schedule that considers the outside temperature sensor and a watch for that sensor. Reevaluation doesn’t cause much load actually… unless your outside temperature changes 2x per second and you run on a raspi 2 or so.
EDIT: And yes, you can constrain the rule that sets the switch to on with normal start/end/weekdays/whatever constraints. It’s just a normal schedule rule after all.
- x: "'on' if float(state("outside_temp") or 0) < 5 else Skip()"
start: "07:00"
end: "09:00"
- v: "off"Thanks will give this a try. It is convenient to have everything together. Much easier to read and understand.
Yes, you’ll save 1 automation + 1 input_boolean. With the growing amount of smart stuff we’re probably going to have in the future, every bit counts. Tell us if it worked.