Why don’t you create an automation that’s triggered by state changes in any of the participating entities and emits a re-schedule event? That way you’d get a finer granularity.
BTW. I would have created an external module to hold the code currently placed in the YAML and then just call a function in that module to trigger the logic. The config gets a lot cleaner this way.
def get_temp(room_name, app, time, OFF, **kwargs):
if app.get_state("sensor.{}_first_period".format(room_name)) == "on" and time.hour == 12:
return app.get_state("input_number.{}_temp".format(room_name))
# do some more logic here
return OFF
@roschi Good idea with the external module to simplify the config, thanks.
Those reschedules every 10 minutes are there becuase no change which can be used as automation trigger happens at the time of change. All the values are just inputs, saying when to switch temperature. All of them are more or less constantly set from the UI and that’s it (but I do not want them hardocoded in config file).
Ah, I see. Then a granularity of 10 minutes seems feasible I think.
Currently, this breaks manual changes made at a thermostat, because they are overwritten at any re-scheduling. But I’m going to change the mechanism of the heaty_reschedule event in the next release so that one can decide whether an existing re-schedule timer (if one exists) should be cancelled or kept running.
Override detection I have already made - when a change target temperature is detected at thermostat, it is compared to both low and high temperature values and an boolean input is set if temperature differs. Then the automation every 10 mintues detects this and skip action.
Override is canceled when exact time of next change (start or end of interval) happens.
Ok, but this always reschedules at fixed times. Heaty’s re-scheduling mechanism re-schedules X minutes after a manual change, even if that’s going to be later than the next time the schedule would have been evaluated at.
Anyway, this is something to be incorporated into Heaty directly, and it actually has been in the master branch. It would be cool if you could use that for testing, because there have been lots of useful additions and rewrites. The changelog is quite long this time.
@DamianFlynn Are you proceeding with testing the new statistics feature? It’d be nice to hear what you think about it.
Currently, thermostats that are turned off are excluded from calculating the temp_delta I’m not yet sure whether that’s desirable or not. The alternative would be to count them with a delta of 0. The issue I see with excluding them is that the configured weights get out of balance when some thermostats are skipped eventually.
I implemented the alternative behaviour in the temp_delta_off_0 branch for testing. This seems better to me and I’ll probably merge it into master when you have no contradicting reasons.
@roschi Just home today after a couple of work trips, so apart from downloading the code, there has not been a lot of work done. I see errors on the Z-Wave network; so ill debug that first, and then take a look at this work of art.
No problem, I’ve still got some things to improve and clean up all around the code before next release, so don’t hurry too much.
The changelog is a little longer and there are backwards-incompatible changes in the configuration syntax, hence I want to get the things finally right before people need to change their configs twice.
Hi @roschi . I managed to get to a state that project can be shared
In fact I did not utiltize the discussion above as I decided after longer thinking that I will keep things as they are, at least for now.
The huge expressions in Heaty config are ugly but for me it is more readable then external module - I can read it immediately and do not need to think where I put the module.
What is interesting is the delayed re-scheduling. I plan to use this definitely for bathroom but first I need to solve some physical issues directly in the room. For all the other rooms it is more usefull for me to stick to the schedules instead of eg. 2 hours dynamic override.
One thing to think off:
I tried to put in place a safety interval to fully open the valve to prevent calcium deposits. This is usually done by better “dummy” TRV once a week. And I had to set max. target temperature which is 28° for my TRV. You can imagine that in summer it may not open the valve fully at all.
So maybe some improvement to allow somehow to choose the full open operation mode.
@TriStone There is no common mechanism among thermostats to fully open the walve. Some have a special operation mode (e.g. “Heat Boost”) for that purpose, some don’t. You’d be better-off with an automation that triggers whatever is needed in order to open the walve once a week and revert a minute later.
Thanks for sharing your work! I currently have no time for looking into it, maybe next weekend or the one after that, but I can’t promise. An external module definitely is more readable, at least when done right. You’d only have to insert a single rule e.g. in the schedule_prepend ruleset. I think that people might be scared of the long lines they have to repeat for every room, which also brings maintenance difficulties. Maybe you want to dive into it again in the future.
So far, we look pretty ok; The real issue i have is that we are experiencing weather i dont think we have ever seen in the west of ireland.
Currently the bedroom’s are reporting temperatures at a low of about 25C at night, and hitting 31C during the day. While fantastic, is making an real evaluation of Heaty triggering some real demand patterns a total disaster…
Go ahead with your release, and ill update my system to run the code; setting the trigger points in the high 20’s to monitor behaviour.
I know we are never going to be lucky enough to see this weather last a whole lot longer, but i will keep the fingers crossed that i am wrong
I have been delaying using your code since the though of disentangling my existing setup and installing in a virtualenv as you told me to do was just too painful! However, your new post has given me no excuse
I have my appdaemon setup in ~/appdaemon. I have a folder apps in ~/appdaemon which contains a number of folders (eg 01_general, 02_dash, 03_occusim, etc, and - until now - 04-heaty). I moved 04_heaty somewhere safe, and confirmed that AD removed the module.
I started your script. The first issue I faced was the first question - deciding where to install hass-apps. In spite of the suggestion I chose ~/appdaemon/apps. Your script then ran perfectly, installing (lots!) as it went. It ended with
[ INFO ] has-apps has successfully been installed!
[ INFO ]
[ INFO ] You can run AppDaemon with the following command:
[ INFO ]
[ INFO ] '/home/pi/~/appdaemon/apps/bin/appdaemon'
[ INFO ]
[ INFO ] Please read http://hass-apps.readthedocs.io/en/stable/getting-started.html#configuration for the next steps.
[ INFO ]
[ INFO ] Have fun!
I now have a new folder in my home directory called “~” - not quite what I was expecting! I am a little loathe to try “rm ~” - for obvious reasons. And a mv ~ tmp returns mv: cannot move '/home/pi' to a subdirectory of itself, 'tmp'
The os.path module doesn’t understand ~ as a shortcut for the home directory. This is something only shells understand. That’s why it created a directory named ~.
You can of course remove it when you escape the ~ like so:
rm -rf \~
Or just use the auto completion of your shell.
Check with realpath before deleting to be sure.
BTW, you shouldn’t install a second AppDaemon into your apps directory, what you tried to do actually. The One-step installer installs hass-apps, which pulls appdaemon as a dependency. It’s meant for people wanting to have a plug-and-play solution with no need to install appdaemon manually. But when you use the installer to install it to, let’s say ~/appdaemon, you would be fine. Just move your apps directory and anything else you care about out of the ~/appdaemon before running the installer.
