I found the root cause. It’s not the plugin. It was again the stupid eq3 max cube. I turned it off and on again, restarted appdaemon and everything works as expected.
Great! This would have been very strange if caused by Schedy.
I’d like to have
allow_manual_changesset according to an input_boolean.
I tried several options but failed every timeAny guidance please?
I’m afraid this isn’t possible… at least I don’t see a way to do this with Schedy only.
However, you could write an automation that reacts to changes of the temperature attribute of your thermostats and fires a schedy_reevaluate event in reset mode for the particular room.
@Reynald Or better let the automation watch the schedy_room.<app_name>_<room_name> entity which Schedy creates for each room and which is actor-independent. That entity’s state always reflects the value currently set for the room. But this only works if you don’t disable replicate_changes.
I am trying to unterstand how schedy works. I think i got nearly 80%. But I am stuck with dynamic expressions and in which order they will be evaluated. Mostly my english is of course not good enough for this.
Is it right that the rule which is furthest right will be first evaluated? What about rules which are on the same height? Are they evaluated from top to bottom?
At the moment my schedy.yaml looks like this:
watched_entities:
- "group.haus"
- "remote.eg_wohnzimmer_harmonyhub"
actor_type: thermostat
rooms:
wohn_und_esszimmer:
actors:
climate.egwohnzimmerheizung_links_mode_2:
climate.egesszimmerheizung_links_mode_3:
climate.egesszimmerheizung_rechts_mode_4:
climate.egwohnzimmerheizung_rechts_mode:
watched_entities:
- "group.haus"
- "remote.eg_wohnzimmer_harmonyhub"
schedule:
- v: 18
rules:
- weekdays: 1-5
rules:
- rules:
- { v: 21, start: "13:00", end: "22:00", weekdays: 1-4 }
- { v: 21, start: "11:30", end: "23:00", weekdays: 5 }
- rules:
- x: "Inherit() if is_off('remote.eg_wohnzimmer_harmonyhub') else Next()"
- v: 21
- weekdays: 6-7
rules:
- x: "Inherit() if is_off('group.haus') else Next()"
- { v: 21, start: "06:00", end: "22:00" }
I dont know how to integrate the holidays correctly. As i said above, I need to understand the order in which the rules will be evaluated.
I created a short flow chart for the first steps. May we can build the schedy.yaml together?
Hi @Se7enair
My English isn’t the best either 
Would you mind mailing me your phone number (click on author name under Meta section here)? I’ll call you back then and try to explain it in more detail in your mother tongue.
Best regards
Robert
I have just loaded a fresh version onto a clean HA installation, and copied the default config file from here https://hass-apps.readthedocs.io/en/stable/apps/schedy/configuration.html. I am getting this error
2020-01-13 21:49:13.494309 INFO AppDaemon: Reading config
2020-01-13 21:49:13.547611 WARNING AppDaemon: Error loading configuration
2020-01-13 21:49:13.547938 WARNING AppDaemon: parser says
2020-01-13 21:49:13.548307 WARNING AppDaemon: in "<unicode string>", line 174, column 5:
statistics:
^
2020-01-13 21:49:13.548547 WARNING AppDaemon: expected <block end>, but found '<block mapping start>' while parsing a block mapping
2020-01-13 21:49:13.548910 WARNING AppDaemon: File '/config/appdaemon/apps/schedy.yaml' invalid structure - ignoring
2020-01-13 21:49:13.552013 INFO AppDaemon: /config/appdaemon/apps/schedy.yaml added or modified
It seems the statistics needs to be indented one more level.
Hm, in fact, it was indented one level too much, but I’m unsure whether this was causing the issue. I now fixed the indentation in latest docs. Could you please try it out?
EDIT: The docs weren’t rebuilt after my update yet. Now they are.
1 Like
Yes the default config loads successfully. Thanks.
Just loaded this into AppDaemon 4 and there is an error relating to ha_url
2020-01-14 22:41:54.690391 INFO schedy: --- Actor type is: 'switch'
2020-01-14 22:41:54.720591 WARNING schedy: schedy: Entity schedy_room.schedy_schedule not found in namespace default
2020-01-14 22:41:54.721819 INFO AppDaemon: schedy: Entity schedy_room.schedy_schedule created in namespace: default
2020-01-14 22:41:54.724055 WARNING schedy: ------------------------------------------------------------
2020-01-14 22:41:54.724770 WARNING schedy: Unexpected error running initialize() for schedy
2020-01-14 22:41:54.725338 WARNING schedy: ------------------------------------------------------------
2020-01-14 22:41:54.730201 WARNING schedy: Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/appdaemon/app_management.py", line 145, in initialize_app
await utils.run_in_executor(self, init)
File "/usr/lib/python3.8/site-packages/appdaemon/utils.py", line 276, in run_in_executor
response = future.result()
File "/usr/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/lib/python3.8/site-packages/hass_apps/common.py", line 103, in initialize
self.initialize_inner()
File "/usr/lib/python3.8/site-packages/hass_apps/schedy/app.py", line 184, in initialize_inner
room.initialize(reset=self.cfg["reset_at_startup"])
File "/usr/lib/python3.8/site-packages/hass_apps/schedy/room.py", line 52, in wrapper
room._update_state()
File "/usr/lib/python3.8/site-packages/hass_apps/schedy/room.py", line 287, in _update_state
self.app.set_state(entity_id, state=state, attributes=attrs)
File "/usr/lib/python3.8/site-packages/appdaemon/utils.py", line 191, in inner_sync_wrapper
f = run_coroutine_threadsafe(self, coro(self, *args, **kwargs))
File "/usr/lib/python3.8/site-packages/appdaemon/utils.py", line 285, in run_coroutine_threadsafe
result = future.result(self.AD.internal_function_timeout)
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 439, in result
return self.__get_result()
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 388, in __get_result
raise self._exception
File "/usr/lib/python3.8/site-packages/appdaemon/adapi.py", line 1360, in set_state
return await self.AD.state.set_state(self.name, namespace, entity_id, **kwargs)
File "/usr/lib/python3.8/site-packages/appdaemon/state.py", line 431, in set_state
result = await plugin.set_plugin_state(namespace, entity_id, **kwargs)
File "/usr/lib/python3.8/site-packages/appdaemon/plugins/hass/hassplugin.py", line 369, in set_plugin_state
api_url = "{}/api/states/{}".format(config["ha_url"], entity_id)
KeyError: 'ha_url'
2020-01-14 22:41:54.730934 WARNING schedy: -----------------------------------------------------------
i think that is a problem with the addon.
on discord another user reprted that, and frenck is looking at it.
1 Like
i think that is a problem with the addon.
Yes, definitely. I upgraded to AD 4 and run Schedy without issues so far.
Fixed with 0.1.1
i hope you mean appdaemon 4, and i hope you made all neccesary changes as shown in the addon docs and or appdaemon docs
but its not related to shedy, so let us please discuss that somewhere elese 
I think this would work good for scheduling multiple thermostats but I think my logic may become too complex. For example I want away state to come into play but I also want to schedule my fans to run at the same time for say 5 minutes but not when something else is calling for heat or cold or it’s already at the desired state.
Thank you, I follow.
I will see how, but your ideas seems a good start point.
In my case, this is for lights.
1 Like
Hi @roschi ,
would you consider adding the climate actors’ preset modes to the possible target values?
For example, my Eurotronic Spirit thermostats have an attribute in the climate entity:
"preset_modes: Manufacturer Specific,Heat Eco,boost,none"
Those values can be sent via climate.set_preset_mode. Those presets have different meanings and probably differ from device to device. In my case, preset “none” puts the thermostat back in normal operating mode after having activated one of the other presets.
Those values could be treated similar to “Off”. So, if a string value is given as target value that is not “Off” it could be handled as preset name and trigger the climate.set_preset_mode service call.
The “Heat Eco” preset, for example, would allow you to set a eco/night/away temperature for each thermostat right in the HA UI and in Schedy you could just create a schedule_append or snippet valid for all thermostats that activates the “Heat Eco” preset at a certain time without caring what the actual “eco”-temperature for each thermostat is.
What do you think?
Hi @jo-me
would you consider adding the climate actors’ preset modes to the possible target values?
That’s an interesting idea… unfortunately I haven’t got much time for working on Schedy at the moment, but I’ll definitely keep it in mind, thanks!
Best regards
Robert
Ive set the ‘rescheduling_delay’ which all works fine but is there away of getting the time left in the delay to display in HA Lovelace so I can display a count down timer showing when the heating will return to the current schedule?
The schedy_room.xxx_xxx entity corresponding to the room has a rescheduling_time attribute which holds the timestamp at which rescheduling will take place or null, if no timer is running at the moment. You could take this value and subtract the current timestamp to get the number of seconds left, if that helps.
Ahrr, didn’t see that, Thank you.