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

Share your Projects!
142

Hi Robert,

I suspected as much, because I found that installing Heaty installed the older AD version, overwriting the beta version. Which I quickly reversed again :wink:
I was rather hoping you have an updated version at the ready, but failing that you probably can quickly point me to a temporary fix I can carry out myself. A wild guess would be that it’s got to do with the (undocumented, or rather: wrongly documented) beta changes with regard to the get_state api call…
Anyway, thx a lot for an app that’s both flexible & powerful !

143

Unfortunately, I haven’t looked into appdaemon 3 yet, apart from a quick glance at the forum post announcing it. I plan to switch the requirement after appdaemon 3 is released as stable.

144

Hmmm, docs for appdaemon 3 seem not to be complete yet. But it seems there isn’t much effort involved in changing Heaty to work with both versions simultaniously.

Expect it to come later today.

145

That would be awesome (taking into account that Andrew plans to keep AD in beta till HA stops supporting Python 3.4). Thx beforehand !

146

Do you know when this is planned to happen?

147

Hi,

hass_apps 0.20180205.0 introduces support for AppDaemon 3.0.0b2 (at the time of writing) and is out now for upgrading with pip. Enjoy!

Feedback is heavily appreciated.

Best regards
Robert

148

Ah, forgot to mention that AppDaemon 2 will (or at least should :slight_smile: ) continue to work as before

149

Hi,

Has anyone had a problem with the master switch ? . When I try to switch off:

2018-02-05 19:30:21.332023 WARNING ------------------------------------------------------------
2018-02-05 19:30:21.332974 WARNING Unexpected error in worker for App heaty_full:
2018-02-05 19:30:21.333851 WARNING Worker Ags: {‘kwargs’: {}, ‘entity’: ‘input_boolean.set_heat_auto’, ‘type’: ‘attr’, ‘old_state’: ‘on’, ‘name’: ‘heaty_full’, ‘new_state’: ‘off’, ‘function’: <bound method modifies_state.._new_func of <hass_apps.heaty.app.HeatyApp object at 0x763998f0>>, ‘attribute’: ‘state’, ‘id’: UUID(‘05426acc-4eca-4688-90c7-2f5c525fb03d’)}
2018-02-05 19:30:21.334505 WARNING ------------------------------------------------------------
2018-02-05 19:30:21.336317 WARNING Traceback (most recent call last):
File “/usr/local/lib/python3.5/dist-packages/appdaemon/appdaemon.py”, line 512, in worker
utils.sanitize_state_kwargs(args[“kwargs”]))
File “/usr/local/lib/python3.5/dist-packages/hass_apps/heaty/app.py”, line 24, in _new_func
result = func(self, *args, **kwargs)
File “/usr/local/lib/python3.5/dist-packages/hass_apps/heaty/app.py”, line 175, in master_switch_cb
scheduled=False)
File “/usr/local/lib/python3.5/dist-packages/hass_apps/heaty/app.py”, line 24, in _new_func
result = func(self, *args, **kwargs)
File “/usr/local/lib/python3.5/dist-packages/hass_apps/heaty/app.py”, line 441, in set_temp
if target_temp.is_off():

Summary

This text will be hidden

AttributeError: ‘str’ object has no attribute ‘is_off’

150

@omen90 Please open an issue on Github and provide your configuration together with the complete log of Heaty with debug: true in your app configuration. Thanks.

151

I seem to remember that being planned for ‘January’. Didn’t happen, as we all know, but I suppose it is imminent nonetheless.
And kudo’s to you for the updated version - as always as speedy as the Duracell rabbit :+1:. Will test and report…

152

@pav There seems to be an issue with listen_state in appdaemon 3… please wait while I’m resolving it. Sorry for the inconvenience.

153

Upgraded & tested : all systems working… Or at least no more errors, and the target temps of every thermostat (generic & brand) are correctly retrieved. Not being home, I cannot test more than that, but it sure looks good. Much appreciated !
I just see your last post whilst typing the current reply : no problem and certainly no need for ‘sorries’…

154

Done. Thank you.

155

The problem is that it is going to re-send the temperature 10 times, no matter whether it has been received by the thermostat or not, which may cause battery drain on your thermostats.

156

@pav Alright, please upgrade again… It works flawless now at least for me.

157

@roschi While upgrading -> Could not find a version that satisfies the requirement appdaemon>=2.12.1

It’s a little mistake with required version, right? (2.1.12)

Thank you.

158

Oh damn! Yes, you’re right. I didn’t notice that because I switched between 3.0.0b2 and 2.1.12 manually. It’s fixed now.

159

After successful upgrade and restart. Still the same issue with the master switch. It could be something wrong with my configuration. And with my luck, they probably will be. If I find the problem I will let you know on github Thanks for your support.

160

@omen90 Please head over to the GitHub issue again, I’m pretty sure it’s fixed now. Thanks!

161

A question about the OFF special value : is it temp: OFF, or temp: “OFF” ?

Furthermore, I seem to have hit upon a problem : I could not understand why after switching a (generic) thermostat off, it’s operation mode kept showing ‘Heat’ iso ‘Off’. That is, until I found this in HA’s log :

Unrecognized operation mode: Off
2:12 PM components/climate/generic_thermostat.py (ERROR)

In contrast, using the service call ‘Off’ option from HA’s devtools page works flawlessly… ?

Edit : guess what, it looks like generic thermostat expects ‘off’ iso ‘Off’ (and ‘heat’ iso ‘Heat’), so I guess changing the corresponding opmodes in heaty’s yaml will solve this one. Testing now…

And a final question : what are log entries such as

2018-02-07 14:12:05.697942 INFO heaty: --- [living] Re-scheduling not before 14:12 (0:00:06).

supposed to tell us ?