Hmmm. OK, I think I am convinced. I will download heaty and start trying to construct a basic (and then not-so-basic) schedule.
I’ve been thinking anyway of implementing a non-binary presence state (like on this link) so that if I/wife go out for a short period then the heating doesn’t go off, but if I go away and forget to turn the heating off then eventually an “extended away” state kicks in and does it. Maybe I will leave the not-so-basic stuff until I’ve looked in to that.
Can I just check one basic thing? I have an entity climate.upstairs_heating which has an operation_list of “auto”, “heat” and “off”. If I specify that as a thermostat, will heaty just use these, notwithstanding the capitalisation differences suggested in apps.yaml.example?
It would be very helpful to see a few actual, working apps.yaml if anyone was willing to share, please? Even though the docs are good, there’s nothing like a working example or two to look at.
You’ll need to tell Heaty the capitalization difference, but you can do it in thermostat_defaults and it will apply to all thermostats. It should only be two lines:
opmode_heat: heat
opmode_off: off
Hmm, maybe I’ll find the time to sanitize my own working configuration and post it as an example. There are probably no config snippets out in the wild yet because Heaty is only two months young.
Step 1 - Get yourself a nice cup of coffee or tea. You’ll surely need it. - check
Step 2 - Copy the file hass_apps_loader.py to your AppDaemon’s apps directory. - FAIL
Tried find / -name hass_apps_loader.py
can’t find it.
@PianSom Ah, I see… The file isn’t included in the python package, just fetch it from the github repo, it’s just a one-liner.
This is because the loader doesn’t belong to the package. This is just a stub needed by appdaemon to load the apps. I’m going to include it into the package in future releases. Thanks for noting.
EDIT: I now mentioned the new location of hass_apps_loader.py in the README. Thanks again.
OK, the pip install put the packages into ~/.local This seems to be the wrong place for appdaemon to find them, since I am getting an appdaemon error ending
ImportError: No module named 'hass_apps'
Nearly there - I just need to work out where they need to go
@PianSom What system are you running? Or, better, how did you install appdaemon?
If you installed appdaemon inside a virtualenv, you also need to install all python modules inside that virtualenv.
If you just installed appdaemon with pip, you probably ran it as root and the appdaemon module ended up in /usr/local/lib/python*. Then you need to install hass_heaty as root as well.
Just by the way, I implemented the schedule inclusion feature and released a new version 0.20180201.0 a couple of minutes ago. Maybe you want to use this new feature and split up schedules as originally proposed by you.
OK, so after a bit of playing around I’ve managed to get heaty working ok.
A few observations:
As you suggested, I had to use the opmode options (note that quote marks are missing from heat in the example yaml file)
it would be useful to have a “kill switch” option, which would turn on/off heaty in its entirety (especially while I’m getting used to it). Or, alternatively or additionally, a “test” option which prevents heaty from carrying out actions but still logs
On my heating system (Hive) there are three modes - schedule, manual or off. I found that heaty changed the target thermostat temperature but did not change the operating mode to manual; it was left at auto so the thermostat schedule was still active. I need to investigate this further. (This may be designed behaviour; or maybe I am using the incorrect climate command, I am not sure.)
The docs say that having no schedule is perfectly valid. I found this not to be true. But it’s a good temporary kill switch!
By a bizarre coincidence I have had a major valve failure on my central heating today, so my full adoption of heaty will need to be a bit delayed while I find a plumber. In the mean time, manual operation really does mean manual operation …
Sorry for what happened to your valve, must be frustrating to open and close it manually now.
There need to be no quotes around Heat, because Heat has no special meaning in YAML. The only reason “Off” is enclosed by quotes is that YAML would have converted it to False otherwise.
Hmmm, there is the master switch functionality, but when turning it off, Heaty will also turn all thermostats off. So that is basically not what you want while testing. However, you could comment out the thermostats defined in your config. Then Heaty should still log what it does but without sending anything.
Don’t know what happened there. For me, it always changes operation mode as desired.
Operation without schedules actually does work, but due to a bug in the voluptuous library used by Heaty you need to keep the schedule: headline in your config and just comment out the rules. I already filed a report against the bug and will see what happens. But this has no more consequences than a bit of inconvenience.
And you can also configure and test Heaty without adding thermostats at all. You will still be able to see what temperature it sets for the different rooms in the log.
The plumber is due this afternoon - not much you can do when there’s a hardware issue
Thanks for the tip on commenting the thermostat, that seems to work nicely.
But I get the error below in my appdaemon error log if I have a schedule: with nothing after it (and no error with a minimal schedule).
I will probably leave further testing/configuration until I have a working heating system again - I guess that’ll likely be next week now.
Ian
2018-02-02 08:22:04.258777 WARNING Unexpected error:
2018-02-02 08:22:04.259314 WARNING ------------------------------------------------------------
2018-02-02 08:22:04.260873 WARNING Traceback (most recent call last):
File "/home/pi/.local/lib/python3.5/site-packages/appdaemon/appdaemon.py", line 837, in check_config
new_config[name]["module"], new_config[name]
File "/home/pi/.local/lib/python3.5/site-packages/appdaemon/appdaemon.py", line 583, in init_object
conf.objects[name]["object"].initialize()
File "/home/pi/.local/lib/python3.5/site-packages/hass_apps/common.py", line 44, in initialize
self.cfg = self.Meta.config_schema(self.args)
File "/home/pi/.local/lib/python3.5/site-packages/voluptuous/schema_builder.py", line 221, in __call__
return self._compiled([], data)
File "/home/pi/.local/lib/python3.5/site-packages/voluptuous/schema_builder.py", line 716, in validate_callable
return schema(data)
File "/home/pi/.local/lib/python3.5/site-packages/voluptuous/validators.py", line 264, in __call__
raise e if self.msg is None else AllInvalid(self.msg)
File "/home/pi/.local/lib/python3.5/site-packages/voluptuous/validators.py", line 262, in __call__
v = schema(v)
File "/home/pi/.local/lib/python3.5/site-packages/voluptuous/schema_builder.py", line 221, in __call__
return self._compiled([], data)
File "/home/pi/.local/lib/python3.5/site-packages/voluptuous/schema_builder.py", line 716, in validate_callable
return schema(data)
File "/home/pi/.local/lib/python3.5/site-packages/voluptuous/schema_builder.py", line 221, in __call__
return self._compiled([], data)
File "/home/pi/.local/lib/python3.5/site-packages/voluptuous/schema_builder.py", line 538, in validate_dict
return base_validate(path, iteritems(data), out)
File "/home/pi/.local/lib/python3.5/site-packages/voluptuous/schema_builder.py", line 370, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: expected a list for dictionary value @ data['rooms']['downstairs']['schedule']
2018-02-02 08:22:04.261648 WARNING ------------------------------------------------------------
This is interesting. I suppose that there is anything else in your apps.yaml right after the schedule: directive that makes YAML interpret it as a dictionary instead of None. I have such a setup working in one room now for more than a month with no problems.
Here are the closing lines of my apps.yaml, which generate that error -
# Schedule for this room.
# The explanation of schedules has been removed from this file,
# because it is simply to detailled.
#
# Please see README.rst.
#
#schedule:
# ...
schedule:
# - { temp: 23, start: "07:00", end: "22:00" }
# - { temp: 16, start: "00:00", end: "00:00", end_plus_days: 1 }
I will download heaty and start trying to construct a basic (and then not-so-basic) schedule.
