What you used before was just the master branch of the repo, no release at all, not even a beta release.
I update the version number in each release commit, so it’ll stay 0.1.0 in the repository until 0.1.1 or 0.2.0 comes out. So if you’d now be using the master branch, you’d still see 0.1.0. That’s common practice afaik.
It could though have been 0.0.0 before the first release for consistency, in that point I agree and will consider it for the next project.
I have had a power failure today and after restart, some of my schedules using schedule_snippets do not evaluate correctly and I have this error message Invalid value "20 if is_on('input_boolean.kids') else 16" for actor type 'thermostat': "20 if is_on('input_boolean.kids') else 16" is no valid temperature
But the same type of rule worked properly this morning.
My schedule_snippet looks like
kids:
- { v: "20 if is_on('input_boolean.kids') else 16", start: "06:00", end: "07:30", weekdays: 1}
...
schedule:
- x: IncludeSchedule(schedule_snippets["kids"])
Is there something wrong with that?
@radar I think we already discussed this, didn’t we? You set an expression as the value parameter.
EDIT: And this couldn’t have worked this morning either, you probably just missed the error.
Yes we discussed that. I can’t explain how it worked today if it could not this way. I even checked my commits and I was running a version of the script similar to what I have. Anyway, I corrected my conf and it’s working well now.
Ok, in the next release an additional warning is logged when a plain value couldn’t be validated to suggest setting it as an expression instead.
Hi @roschi,
I much appreciate your work on this topic. I’m already using the Heaty and planning to upgrade to Schedy.
I like the flexibility of your solution but I’m not sure how can I simply enhance my setup in a user friendly way. As I see my heating program has usually 3 way: workday, weekend and away. For me the easiest way of using - to let my wife can handle it - is a simple button (or 3 radio button) on the UI where I can easily override the actual state between the 3 enlisted. In an ideal world I can define the day-type settings in advance - in some kind of calendar.
An easier challenge: I’d like to define the end of the away. Typical scenario: leave the house on Friday evening and get back around Sunday afternoon. So if I can define - via some UI element - when the thermostat should raise the target temperature to the usual value that would be awesome.
Please let me know if you have any solution for my challenges.
BR,
denx
@denxhun Schedy includes no UI components, and that isn’t planned either. But you can of course create your own input_number (or similar) entities and have the Schedules depend on them. Have a look at the tips and tricks chapter, there is an example for dynamic start and end times that you can start with.
Or you just implement a binary switch to enable/disable the away schedules independent of time.
@roschi Thanks for your prompt reply. I know that your program has no front end - this wasn’t a question.
I found a way to assemble a system which is suitable for my needs - from UX perspective. I defined an input_select with 3 options: weekday, weekend and away. I managed to operate this with a Google Calendar component and a minimal automation in HASS. My question is the any way to change from one schedule to another in Schedy? I mean I can assemble a “weekend” and a “weekday” schedule (and a predefined target temperature for “away”) in Schedy but is there any way to change between these run time from a HASS automation snippet?
Sure, create different schedule snippets and include them depending on the state of that input_select, and then trigger a reschedule event when its value changes.
Just the normal workflow to include entity state in Schedy schedules.
Hello. May I ask you how to install Schedy on Hassbian? I used hadashboard in the past and as I know Schedy is based on Appdaemon? But how to install it? Thank you.
None. Jist don’t know where to start.
Hello @roschi, is it normal that I have no history of statistics? It’s running since few days.
Thanks.
Another question: I have two schedule_snippets and I use either the one or the other in all my rooms schecules (all the rooms have only an inlcudeSchedule in their schedules).
But one of my rooms is misbehaving. Instead of having 16° like all the other rooms, it is set to 18.
I think that’s due to a manual change I made yesterday. But this room is configured as below:
allow_manual_changes: true
#replicate_changes: true
rescheduling_delay: 60
From my understanding, it should has applied the target temperature only for one hour yesterday, right?
Is that a bug or there is any explanation?
The logs show:
2018-12-14 10:08:59.072180 INFO schedy_heating: --> [R:kid] [A:climate.kid] Attribute 'operation_mode' is 'heat'.
2018-12-14 10:08:59.073486 INFO schedy_heating: --> [R:kid] [A:climate.kid] Attribute 'temperature' is 18.0.
2018-12-14 10:08:59.076150 INFO schedy_heating: --> [R:kid] [A:climate.kid] Attribute 'current_temperature' is 17.7.
2018-12-14 10:08:59.078744 INFO schedy_heating: --- [R:kid] Unchanged HA state: state='18.0', attributes={'actor_wanted_values': {'climate.kid': '18.0'}, 'scheduled_value': None, 'rescheduling_time': None, 'overlaid_wanted_value': None, 'overlaid_scheduled_value': None, 'overlaid_rescheduling_time': None}
Note that I have manually changed this thermostat to 18° at 5:39pm yesterday and that I have updated (and restarted) HA at 5:58pm after what, schedy set back the temperature to 16° right after restart (without considering the 60 minutes before rescheduling). But something (I don’t remember all what I have done) changed the target temperature to 13° around 9:30pm, after what it has been changed again to 18° at the same time.
@radar Since I’m blind I can’t spot what you’re showing on that image, but probably it’s just that HA doesn’t know how to represent the custom schedy_room and schedy_stats entities. State changes are logged to the database for sure.
Hmm, this log excerpt doesn’t show much except that the schedule doesn’t seem to evaluate to a value at all. You need to log a schedule evaluation, best would be to emit a schedy_reschedule event with this data from the HA developer tools manually:
{"room":"kid"}
And show me the log entries this produces.
I’m sorry for that, did not know that you are blind.
I thought that statistics history would be displayed in its history graph.
No problem at all.
Does the schedy_stats.something entity show up at all? It normally shouldn’t be visible except when searching via the developer tools.
Here is the output. Note that I have manually set the temperature at 16° between my question and your answer.
2018-12-14 15:13:22.809981 INFO schedy_heating: --> Re-schedule event received for: R:kid [mode='reevaluate', delay=3sec]
2018-12-14 15:13:25.003690 INFO schedy_heating: --- [R:kid] Applying room's schedule (reset=False, force_resend=False).
2018-12-14 15:13:25.006505 INFO schedy_heating: --- [R:kid] Assuming it to be 2018-12-14 15:13:25.
2018-12-14 15:13:25.008285 INFO schedy_heating: --- [R:kid] 3 / 3 rules of <Schedule 'kid'> are currently valid.
2018-12-14 15:13:25.009964 INFO schedy_heating: --- [R:kid] ������ <<Schedule 'kid'>/1:<Rule x='Abort() if is_off("input_boolean.schedy"'...>>
2018-12-14 15:13:25.011931 INFO schedy_heating: --- [R:kid] ������ => Abort()
2018-12-14 15:13:25.013977 INFO schedy_heating: --- [R:kid] Found no result.
2018-12-14 15:13:25.014884 INFO schedy_heating: --- [R:kid] No suitable value found in schedule.
2018-12-14 15:13:25.015925 INFO schedy_heating: --- [R:kid] Unchanged HA state: state='16.0', attributes={'actor_wanted_values': {'climate.kid': '16.0'}, 'scheduled_value': None, 'rescheduling_time': 1544799859.0, 'overlaid_wanted_value': None, 'overlaid_scheduled_value': None, 'overlaid_rescheduling_time': None}