@bartaspoz ignore_updates was false by default, and this is now the only supported behaviour. If you didn’t enable it before, you won’t see any difference though it has been removed.
Ok, I’m after a few days of tests today. So…my thermostats started to work flawlessly, don’t know why (maybe hass upgrade has do to sth with that) 
Each temp set is beeing processed in 15 seconds by my thermostats so I’m unable to test your new feature. If I will see any retries in logs will post it here for sure. But I started to see logs entries which I didn’t noticed before, what can they mean?:
WARNING Scheduler clock skew detected - delta = 1.71
6540813446045 - resetting@bartaspoz Good to hear that your thermostats work flawlessly. In non-debug mode, retries aren’t logged, so you wouldn’t see them although they are made. The default retry interval is set to 10 seconds, hence if you say that it takes about 15 seconds for the thermostat to report the change back, there should have been one retry happening under the hood.
Regarding your issue with clock skew, I currently have no idea where this could come from. This is something reported by AppDaemon when a callback function in one of its apps takes more time to finish than it should. It would be interesting if this is caused by Heaty at all and, if so, which function actually causes the delay. Would you mind setting debug: true in your apps.yaml, capture the logs and upload them somewhere? Don’t be afraid, they can get quite comprehensive in debug mode.
Ah, have you any AppDaemon dashboard running? These can cause scheduler clock skew as well.
And please use the new v0.8.0 for capturing the logs, since there have been changes that affect logging.
No, I do not have any apps runnig. But I noticed that the skew can be related with another system app, which makes some of my services restart once during night.
About the resending - i’ve enabled debug mode and actually there are some resend attempts The 15 seconds is normal feedback time in my thermostats so I’ve set max 5 resend attempts every 60 seconds.
Additionally I can see on GitHub that you are implementing custom HADashboard widget. I just got mine working and would be more than happy to be a beta tester of new widget Happy new year!
@bartaspoz Nice to hear that it works! I’m probably going to increase the default re-send interval to 30 seconds.
Don’t expect the dashboard widget to be ready too soon. I’ve never dealt with dashboard widgets before and probably won’t have time for it before February.
Wish you a happy new year as well!
Best regards
Robert
I haven’t tried installing this yet, but I’m curious if it could do what I’m looking for my setup to do. I want rules for when I’m at home (temp between 68 and 72F) and rules for when I’m at work (temp between 55 and 65F) . I’d like to use it in conjunction with something like this and the Google Calendar component. Do you think that’s possible?
@MartiAbernathey Nice to hear that you’re thinking about using Heaty.
I suggest using Heaty together with some kind of device_trackers to create schedule rules that set temperatures depending on the state of these device trackers. But then you wouldn’t need to use Google Calendar at all.
Hi,
I just want to let you know that I moved Heaty into my new hass_apps package to make further development of more apps simpler.
Please uninstall as follows:
pip3 uninstall hass-heaty
And then re-install the new package:
pip3 install hass_apps
The new repository can be found here:
You’ll also need to remove heaty_app.py from your apps directory and copy hass_apps_loader.py from the new repository.
The settings for apps.yaml have to be changed to:
module: hass_apps_loader
class: HeatyApp
If you have any questions, feel free to ask.
I wish you a good new year.
Best regards
Robert
I get this error:
appdaemon_error.log
2018-01-12 12:11:23.040594 WARNING Unexpected error:
2018-01-12 12:11:23.042467 WARNING ------------------------------------------------------------
2018-01-12 12:11:23.045507 WARNING Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/appdaemon/appdaemon.py", line 816, in check_config
new_config = read_config()
File "/usr/local/lib/python3.4/dist-packages/appdaemon/appdaemon.py", line 805, in read_config
return new_config
UnboundLocalError: local variable 'new_config' referenced before assignment
Edit: after install finished and restating appdaemon it works. But in think I still need to finish configure as it claims for settings
OK I’m updating to latest appdaemon …will see if it fixes the error
Where is all of the RADME of old hass-heaty??
@bartaspoz It’s in hass_apps/heaty/doc/README.rst There is also a link in the main README.rst referencing to it.
@thundergreen Yes, please do so. If there is something not working, open an issue in the new repository and I’ll respond to it as soon as possible.
Hi
Sorry for the newbie questions, but I am thinking of using heaty and just want to be clear that what it does will actually meet my wants/needs.
I have a working HA system, with a three-heating-zone thermostat system (upstairs, downstairs, hot water - so I guess three rooms: in heaty) and a working appdaemon. I would love to have more control over my home heating system than my current set up allows. (I can run in auto, on or off, where auto is a fixed program.)
In particular, I’d like to change the time-based heating schedule for my zones (I guess in heaty terms a schedule: ?) depending on:
- the season (winter, spring, summer, Xmas, …)
- if someone is home (I already monitor presence), or if someone is likely to be home (I can add a manual switch for this), or if there’s a prolonged absence (vacation, etc)
- the weather (so turn up the thermostats if it’s cold or cold/windy out - I already monitor weather)
- and so on …
So what I would like there to be multiple heating schedules (if it’s winter and very chilly and someone is home then use schedule WinterBoost for my three zones; if it’s spring and no-one is home then schedule SpringEmpty; if it’s winter and my wife is not home then schedule WinterBasic though if she is home then use WinterWarm, and on and on). Ideally I’d like “friendly names” for a schedule, so that they are easy to manage and customise over time, and I can see in HA which one is in use.
I can see how a HA automation can trigger the adoption a given schedule (and can see that perhaps some/all of this re-scheduling could even take place within heaty). But it is not so clear to me from the heaty docs that multiple schedules in the way I envisage them is possible. Nor is it clear how human-readable a schedule can be.
Perhaps if there were a few examples of heaty scheduling that existing users could share here then I would better understand what is possible? And I’d be grateful for any thoughts on what I am trying to achieve.
Thanks!
Hi,
Heaty seems to fit perfectly for what you are aiming to achieve.
There is no way of defining multiple schedules that one is chosen of based on external conditions in Heaty. I think having such a setup would be difficult to maintain as well, because you’d end up with a lot of redundant rules common among different schedules.
I would suggest setting up a schedule that consists of multiple “layers”, each of wich adds the functionality related to one external condition.
Imagine something like the following (untested):
schedule_prepend:
# 1.5 degrees higher from Nov to Feb
- temp: Add(1.5)
months: 1-2, 11-12
# lower by 3 degrees if wife is not home
- temp: Add(-3) if app.get_state("device_tracker.wife") != "home" else Ignore()
Then, in the schedule for a particular room/zone:
- { temp: 21, start: "07:00", end: "23:00", weekdays: "1-5" }
- { temp: 21, start: "08:00", end: "23:30", weekdays: "6-7" }
- { temp: 15 }
Another approach which gives you even more control would be to write a custom python function which takes all your external conditions into account and returns the temperature Heaty should set. You can then call the function from inside a schedule like so:
temp_expression_modules:
my_module:
schedule_prepend:
- temp: my_module.my_function(app, room_name)
There is a section about writing schedules in the README, which also contains an example for writing custom functions for use within schedules.
https://github.com/efficiosoft/hass_apps/blob/master/hass_apps/heaty/doc/README.rst
If you have any further question, feel free to ask.
Best regards
Robert
Hi Robert, and many thanks for taking the time for such a detailed reply
I’m not 100% convinced that a simple “add n degress” overlay quite does what I was hoping for. Let me give an example. Here is my current downstairs heating schedule for right now (picked up from my thermostat provider’s web interface):
Now if my wife is at home during the day I’d like all those 20 degs in the middle of the day to become 22 degs.
And if we are away for a few days (as we are often) then I’d like a fixed 18 degs schedule to be adopted (so that the house doesn’t take too long to warm up when we’re back), but if we’re on vacation then it should have a fixed 10 degs (just to prevent freeze damage). Except that as we move in to spring then we probably won’t need the heat on for so long (yes, I know the thermostat should take care of that, but living in an old, drafty house can be a problem!). And so on …
So the ideal would be to have a menu of different schedules like the one above which I can pick between, and then I can construct rules (possibly, as you say, quite complex rules!) which change the active schedule to the one that is the best. (This changing is, essentially, what I do by hand right now.)
I would rather be thermostat-independent, but I am starting to wonder if I may be better going down the route of using the thermostat API to retrieve/save heating schedules. Though I would much prefer to use a provider independent platform like heaty
Thanks again for taking the time to respond. I will think further and revert with any questions
Hi,
I can’t comment on the screenshot you took because I’m blind and hence pictures don’t make sense to me at all, but I think I got the point you make.
If you don’t care about writing a little, really just a little, Python, then I’d suggest including temperature expressions in your schedule. I still think that different schedules would cause more headache than simplification.
Take this untested config I just wrote as a starting point.
schedule_prepend:
- temp: 10 if app.get_state('input_boolean.vacation') == 'on' else Ignore()
- temp: 10 if float(app.get_state("sensors.outside_temperature")) > 20 else Ignore()
- temp: Add(-2) if app.get_state('group.all_device_trackers') != 'home' else Ignore()
rooms:
downstairs:
schedule:
- { start: "07:00", end: "22:00", weekdays: 1-5,
temp: "Add(2) if app.get_state('device_tracker.wife') == 'home' else Ignore()" }
- { start: "07:00", end: "22:00", weekdays: 1-5,
temp: 20 }
- { temp: 18 }
However, I’m not entirely sure about the group.all_device_trackers I used to lower the temperature when nobody is home. Make sure that it really changes to “not_home” if and only if nobody is home.
Best regards
Robert
BTW, I’m thinking about implementing a way to let schedule rules insert sub-schedules dynamically, maybe based on constraints or the result of temperature expressions.
While this would not extend Heaty’s scheduling capabilities in any way, it might make some configurations more readable.
But having said that, this is just an idea and far from getting implemented.