Heaty - a flexible heating control, facilitating schedules and manual intervention

roschi · July 27, 2018, 7:45am

hass-apps can’t be installed without AppDaemon, it’s a dependency.

roschi · July 27, 2018, 7:46am

I’m currently extending the installer to create a sensible configuration directory structure.

roschi · July 27, 2018, 9:14am

Ok, the installer does now also create a sample configuration directory structure and files to make things even simpler.

dzerovibe · August 28, 2018, 5:33am

I just tried running Heaty, but got the following error. I’m running hass.io (HA v0.76.2) on a Raspberry Pi 3+.

Appdaemon seems to work, as I can see the dashboard with the Hello World tile. But heaty fails to start:

2018-08-28 15:21:30.993548 INFO AppDaemon: Initializing app heaty_minimal using class HeatyApp from module hass_apps_loader
2018-08-28 15:21:31.012070 WARNING AppDaemon: ------------------------------------------------------------
2018-08-28 15:21:31.013050 WARNING AppDaemon: Unexpected error initializing app: heaty_minimal:
2018-08-28 15:21:31.013962 WARNING AppDaemon: ------------------------------------------------------------
2018-08-28 15:21:31.018554 WARNING AppDaemon: Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 2040, in check_app_updates
    self.init_object(app)
  File "/usr/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 1565, in init_object
    self, name, self.logger, self.error, app_args, self.config, self.app_config, self.global_vars
  File "/config/appdaemon/apps/hass_apps/loader.py", line 28, in _proxy_loader
    app_mod = _import_app_module(app_package)
  File "/config/appdaemon/apps/hass_apps/loader.py", line 24, in _import_app_module
    return importlib.import_module(mod_name)
  File "/usr/lib/python3.6/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/config/appdaemon/apps/hass_apps/heaty/app.py", line 18, in <module>
    from . import __version__, config, expr, util
  File "/config/appdaemon/apps/hass_apps/heaty/config.py", line 10, in <module>
    from .room import Room
  File "/config/appdaemon/apps/hass_apps/heaty/room.py", line 16, in <module>
    from .window_sensor import WindowSensor
  File "/config/appdaemon/apps/hass_apps/heaty/window_sensor.py", line 10, in <module>
    import observable
ModuleNotFoundError: No module named 'observable'
2018-08-28 15:21:31.019565 WARNING AppDaemon: ------------------------------------------------------------

roschi · August 28, 2018, 6:28am

! ! ! Please, don’t report bugs in here ! ! !

I’m writing this one more time. From now on, I’ll silently ignore any bug reported in this thread. Sorry guys, but it’s simply not feasible to discuss a hundred different things that should all be properly filed and archived in one long thread. A week later, everything related is lost in a wall of posts and virtually gone for future reference.

So once more, here is the link to the GitHub issues:

Create one, provide your information and we’ll see what we can do.

Thanks for using Heaty!
Robert

EDIT: I marked this as solution for the thread so that it shows up right at the top.

qrioniclabs · September 5, 2018, 9:03am

Hi! Finally got around to get Heaty working with my manual Home Assistant installation. Liking it so far, !

During configuration of the schedules and testing, one question coming up: What’s the best way to trigger Home assistant notifications from Heaty, for example when It sets target temperatures according to schedules. Any way to trigger it directly or do I need to watch the thermostat for changes?

Will get back with further review and comments.

Thanks!

roschi · September 5, 2018, 9:35am

Hi,

Nice to hear you liking it.

There is no sort of callback-like concept to do something different than setting thermostats when a temperature changes. However, you could try to configure a dummy thermostat with opmode_service_attr, target_temp_service_attr etc. that somehow calls a script in HA which then sends the notification… would be a bit clumsy of course. I recommend simply watching the thermostat for now. There will be a sensor named heaty_<heaty_id>_room_<room_name>_scheduled_temp which’s state will be set whenever the scheduled temperature for a room changes. This is currently in development and will be included in next release, probably mid of the month.

Another question: How did you get through the installation process, did you use the AIA or manual installation? How did this work for you?

Best regards
Robert

roschi · September 5, 2018, 10:18am

You may use the state in master branch if you’d like to try the new sensors holding the scheduled temperature.

qrioniclabs · September 5, 2018, 12:29pm

Greetings, @roschi!

Re: Automation trigger:
You’re right, using a dummy thermostat would be going a bit too far. I will use the thermostat’s set temperature as trigger for the time being - it’s just for testing purposes during the transition from the vendor’s schedule to heaty.

Re: Heaty / my setup:
I am using Homematic thermostats, which are quite common in Germany. They’re programmed using a central unit accessible via web interface. The thing I like about the system is that multiple radiator thermostats can be controlled using a common wall thermostat, reading the current temperature away from the radiators, for example on the other side of the room. This way, I achieve a much more consistent heating curve while the radiator valves are not opening and closing repeatedly in a short amount of time (I mentioned this in a previous post when I first touched Heaty - wrongly thinking it might enable me to mix different radiator / wall thermostat products and still keeping this benefit: Heaty - a flexible heating control, facilitating schedules and manual intervention).

As I said, I will now transition from using Homematic central control unit (“CCU”) for the scheduling towards Heaty. From what I gathered, the thermostats will be running in ‘auto’ operation mode with Heaty changing the set temperatures. I merged the thermostats into rooms in CCU which provide virtual thermostats, which I then configure in Heaty. I’ve already run across that it may be needed to address the rooms wall thermostats rather than those virtual thermostats for it to work more reliable. But that would be a problem with the Homematic component, not with Heaty.

Homematic thermostats provide additional operation modes “comfort” and “lowering”, which then use pre-defined temperatures as the set values. Although I’d rather use these modes because the current state would be shown on the thermostats displays (sun / moon icons), I think that this is not compatible to Heaty and also would not allow me to use different “comfort” set temperatures within a schedule. So I am sticking to auto, having set

opmode_heat: auto
opmode_off: manual

in apps.yaml.

So that’s where I’m at at the moment.

Re: Installation
I am not a dev and not overly firm in working with python applications and python venvs. I am using Home Assistant since before Hass.io and have not given it a shot, sticking to my old manual way of installing it in a python venv and using a systemctl service to run it. That’s the way I installed AppDaemon now, also.

The part which I think is most important during the setup process is to get the grips around AppDaemon, it’s rank / position within a Home Assistant installation and Heaty as an AppDaemon app. Once I understood that, the installation was quite straight-forward. But coming back to the installation docs, I think it is quite well pointed out. Sure, a combined installation tutorials, starting with AppDaemon and it’s configuration specificalyl for using Heaty (skipping the “plugins”, “filters”, “Test-App”) would be helpful to newcomers.

Re: Heaty Scheduled Temp Sensor
This sounds very nice, especially for troubleshooting and testing purposes!! As mentioned, I am glad I got the venv installation working, so I have not yet decided if I will switch to the GitHub installation (If I understand correctly, you were referring to the master branch) to try out and test this new feature soon. Firstly, I’m going to concentrate on getting the schedules and rooms to work.

This has developed in to quite a long reply / review . @roschi, keep doing this great work! Thank you very much for this nice addition to Home Assistant heating environments and you supporting it actively in this thread!

roschi · September 5, 2018, 3:21pm

Hi,

Thanks for this thorough review!

You can switch back and forth between an installation from GitHub (dev) and one from PyPi (stable). There is a section about it in the Upgrading docs. It’s really just two commands…

The Auto-Install Assistant of Heaty just does what you did: install AppDaemon + Heaty into a virtualenv and allows for easy upgrading, so nothing related to hass.io. Actually, installing hass-apps under hass.io is still a bit painful at this time.

Are you sure that opmode_off should be manual? This needs to be the mode turning a thermostat off.

You may also want to set debug: true in your Heaty configuration during the migration phase to be able to do troubleshooting later.

Best regards
Robert

qrioniclabs · September 6, 2018, 9:17am

Hi Robert!

Okay, after some poking in my venv I switched from PyPi to GitHub in my 1st try. Everything seems to work, I now have 6 new sensors “…_scheduled_temp” in Home Assistant, all showing the correct state. Heaty log did output some warnings though:

WARNING AppDaemon: heaty: Entity sensor.heaty_default_room_[roomname]_scheduled_temp not found in AppDaemon

Maybe these disappear after rebooting HA? But as I said, it seems to work just fine. I had set debug: true since the first installation.

Regarding the operation modes, you are most probably correct! Homematic differentiates between “comfort” and “lowering” modes. The associated set temperature is to be configured in the Homematic CCU. I think “lowering” is the correct opmode_off in case of Homematic thermostats, too. The default “lowering” temperature is 17°C, but it can be set down to 5°C. I have changed it accordingly in my installation.

However, I am still unsure about opmode_on… Setting it to “manual” certainly works. But maybe it would be best set to “comfort”. The thermostats displays would then show a “comfort” (sun) icon rather than the “manual” (hand) icon. But I’m unsure whether Homematic would accept Heatys set temperature instead of using it’s own “comfort” temp, again set in the CCU. I will try it out and report back.

Greetings
Jan

=================// EDIT //=================
Correction - “comfort” and “lowering” aren’t valid operation modes for Homematic thermostats as far as I can see. They may very well be sent towards a Homematic device, making it switch from the configured “lowering” temperature to the configured “comfort” temperature and vice versa. But the thermostats are still only sending their state as “auto” or “manual” with just the set temperature being changed.

What exactly this means for my configuration, especially regarding opmode_off, I am not sure as of yet. But using “comfort” as opmode_on will certainly not work, because the thermostat stays in “auto” or “manual”, resulting in Heaty ignoring it because of the unknown mode. This also means I will probably not get the thermostats to display the sun icon when the comfort temperature is scheduled and set via Heaty.

roschi · September 6, 2018, 6:00pm

Hi,

The warnings are generated by AppDaemon when setting the state of an entity which didn’t exist in HA before. I can’t do anything against them. Just ignore them, they are just meant to be informative, no real warnings.

When your thermostats are set to auto, they do accept set temperatures, right? If so, you could set the following:

supports_opmodes: false
min_temp: 5.0

This would cause a scheduled temperature of OFF to result in setting 5.0 degrees and Heaty won’t ever deal with operation modes. It’ll just set the scheduled temperature and never call climate/set_operation_mode.

Best regards
Robert

EDIT:
Or you can use off_temp instead of min_temp when you’re on the master branch anyway, but execute git pull first to fetch the latest changes.

snizzleorg · September 17, 2018, 11:33am

First thanks to the author of Heaty. It seems like a very helpful piece of software.
I have a question with regards to presence.

What I want to do is reduce the temperature when people leave the house. BUT the heating schedule should still be respected. This is because the time the flat heats up is rather long.

So if presence goes from on to off the temperature should be reduced but the thermostat should kick back to heating at e.g. 17:00 independent of the presence. Of course the temperature should also be raised if someone returns home before e.g. 17:00.

Any idea on how to achieve this?

roschi · September 17, 2018, 11:47am

Hi @snizzleorg

Have you read the documentation about temperature expressions? I recommend you read the whole parts about writing schedules and temperature expressions, including the examples. Then the way to go should become clear.

Feel free to ask if you have further questions after reading.

Best regards
Robert

snizzleorg · September 17, 2018, 12:00pm

Yeah I did read those. Still not obvious. I thought there might be a more elegant way. or someone already did achieve this.

roschi · September 17, 2018, 12:23pm

Hm, I use a similar configuration myself and don’t find it inelegant actually.

Define your schedule, however that may look like.

Add a rule like this above the other rules:

- temp: Add(-3) if ... else Skip()
  start: "09:00"
  end: "17:00"

Trigger a re-scheduling when the state of entities used in your if statement changes.

That’s it.

Best regards
Robert

roschi · September 17, 2018, 12:26pm

BTW… “more elegant” than what exactly?

roschi · September 17, 2018, 12:32pm

And that’s the source actually…

https://hass-apps.readthedocs.io/en/stable/apps/heaty/temperature-expressions.html#example-use-of-add-and-skip

snizzleorg · September 18, 2018, 12:08pm

Thanks. I have this working at the moment. The documentation is excellent.

Still this will not turn the heating to lets say [temp] °C in case nobody is at home at a certain time. The above rule will turn it to [temp - 3] °C.

I want heaty to set the set point to [temp - 3] whenever the last person leaves but regardless of presence turn the heat up at a certain point in time since it takes hours to heat up the house.

So far I have not come up with an elegant solution.

I can do this by manually (with an automation) reducing the set point (independent of heaty) when the last person leaves. Then at a certain time of the day heaty will turn the heat up again. But I thought somebody might have come up with a more elegant way of achieving what I want.

snizzleorg · September 18, 2018, 12:11pm

Hm maybe I now get this:

- temp: Add(-3) if ... else Skip()
  start: "09:00"
  end: "17:00"
- temp: 20
  start: "17:00"
  end: "00:00"
- temp: off

would this be working?