OK, a bug from the rewrite - will fix & let you know. Until then use_schedules: false works, but until is 1 hour from now.
Yep, see the same behaviour, thanks.
Would be a useful feature to allow users to configure the default override time via .conf file, so could choose to make ‘until’ 2 hours from now, for instance.
Thanks for looking into these issues so promptly.
Seems reasonable - Would you consider adding a request via git: Issues · zxdavb/ramses_rf · GitHub
Fix just pushed for use_schedules
David - not sure how easy this would be or even if it’s a valid suggestion, but if there is a rate limit on the initial OAuth, could the OAuth tokens be cached locally so they aren’t re-requested every time HA starts?
OAuth is handled by the underlying API, so is beyond my control. Maybe I could do something with a hack, but it would be a real hack.
Sorry, too hard for now.
Is anyone interested in creating a custom card for evohome? The plan would be for it to look - as much as possible - the same as the evohome controller UI.
I would plan to include it with the custom component.
Thanks. Looking good.
After last update (evohome_cc) i have a lot of:
supported_features(2967739) = 1152
In the log…
Do you know why?
Seeing some strange behaviour at the moment that I don’t think is anything to do with this component - anyone else seeing similar?
When I set my controller to Away from HASS my iPhone app updates to say it’s in Away mode, as do my zones, but temperatures are not set to the away temp. And in fact, nothing actually changes on the ground.
My current presence detection stuff, which has been working for ages, uses IFTTT to trigger home/away and this is doing exactly the same. See screenshot of my iPhone app after triggering Away (away temp should be 10):-
At some significant risk to myself and my marriage - it is -1C here), I can tell you: it works for me.
Specifically, I set Away mode via HA, and the controller, Android App, and HR92s/TR87Fs all said Away mode/10C.
[ and fortunately, it also went back to a Auto ]
TL;DR Yes.
Long answer: There is an excessive amount of logging within this component. In addition, I use WARNING when I should use DEBUG (a lot), sinceI use colorlog & they show up nicely in a different color.
All this logging is because: a) the code has recently been extensively re-written, and b) I cannot test in all use-case (e.g. I have only TRVs).
You can turn the logging off in configuration.yaml, but I may not be able to help you without that data…
Eventually (say v1.0.0), the logging will be reduce to a more reasonable level, and mostly DEBUG rather than WARNING.
BTW, 1152 = 1024 + 128 (this snippet is for the controller):
self._supported_features = SUPPORT_OPERATION_MODE | SUPPORT_AWAY_MODE
I have switched back to the master branch.
For those who want, there is now support for custom updater
2 Likes
Super thanks for all your great work.
I can’t seem to get the component connected to the custom updater.
Am I missing something?
Other components are working.
In case it’s useful, here’s what’s in my configuration:
custom_updater:
component_urls:
- https://raw.githubusercontent.com/zxdavb/evohome/master/custom_components.json
1 Like
Thanks. That might help. I will test right away.
May I ask how your custom components folder is organized? I wanted to put the evohome component (all files like climate, heater, evohome_cc_py, custom_components.json,…) in a subfolder but that doesn’t seem to work.
Or do I only need the one evohome_cc.py?
The component works great but I never was sure about this. Thanks a lot!
No, I wondered about that too, but I think they do have to be in the correct directory structure within custom_components. Mine looks like this:
custom_components/
├── binary_sensor
│ └── hue.py
├── climate
│ └── evohome_cc.py
├── custom_updater.py
├── device_tracker
│ └── hue.py
├── evohome_cc.py
├── sensor
│ └── hue.py
└── water_heater
└── evohome_cc.py
This means, by the way, that I think David’s suggestion in the docs about installing it by doing a git clone is probably a bad idea now. That will create a .git subdirectory and lots of other files in here, which will be scanned by HA on startup and will get in the way if you wanted to use git for any other components. Much better to keep this clean. (You can see I have a custom Hue component in here too.)
Hence my suggestion of using the custom_updater (thanks, David!), since it provides a way to make updates easy without using git, and keeps things reasonably tidy without using subdirectories.
1 Like
@quentinsf Thanks for contributing to the thread/component/community - sometimes I’m a bit overloaded, so I don’t have time to respond as quick as I’d like.
I plan to release a new version of evohome_cc this weekend, with reduced logging, and also: https://github.com/zxdavb/evohome/issues/29
I will update the install instructions to drop git clone in favour of custom_updater
1 Like
Thanks for all your work! And thanks for pointing out the issue - I’ll plan to reorganise my folders…
A quick question on a different topic:
Am I right that if I want a temporary override to run until the next switchpoint, I should set use_schedules: true? And is the comment that this is only for the adventurous still appropriate? 
OK, we’re in for a wild ride - see: Integrations need to be in their own folder.
The latest code on github has the latest directory structure, see the warning at: README.md
It addresses a bunch of breaking HA PRs, see:
- PR #20677 - Embed all platforms into components
- PR #21023 - Update file header
- PR #20945 - Climate const.py move (and also, elsewhere, Water Heater const.py) - this will be in HA 0.89
This will likely cause an issue sometime soon. For now, it is safe to keep up with the latest master branch, on HA v0.87.