Yes, temp override - but for how long? An hour? Until next setpoint? There are four options when setting a temp:
permanent _overrideadvanced_override (not all systems support this)temporary_override, for a set period of time (say 1 hour)I can’t recall what it does in the official evohome integration (which I wrote) - should maybe just do that, for consistency?
Thoughts?
The actual Honeywell Evohome app defaults to end at the next set point, this would be my preference.
Although I do have a number of ‘dummy’ set points in all my zones, so that if I set an override now, it will automatically default to the convenient end point based on the next dummy set point - i.e I know I tend to leave my office at around 16:00, so I have a dummy setpoint for 15 degrees at 16:00, if I add an override now at 13:30, it will automatically set a reasonable end point. If that makes sense.
Although recently, I tend do pretty much everything with a single button, to boost zone X for 1 or 2 hours. This at least stops people (cough, girlfriend) from setting stupidly long overrides for hours and hours.
That would be my preference as well, so " 4. same as above, but until next setpoint (I’d have to work out when that is)". Currently it’s already the case like that in the evohome_cc
The challenge is that other systems - Hometronics for example - do not support advanced_override.
I do not want to limit evohome_cc to evohome (that’s why it may end up being renamed, e.g. honeywell_rf).
Could you make a config field to state which system you are going to use? By adding a system_type field?
Example:
evohome_cc:
serial_port: /dev/ttyUSB0
scan_interval: 60
config:
packet_log: /config/evohome_cc_packet.log
enforce_allowlist: true
system_type: evohome
schema:
controller: 01:223036
allow_list:
- 01:223036
This project looks promising, just bought a nanocul so I can test this.
The evohome cloud service is unreliable lately so I hope a local solution works better.
I have already started on this - called profile:
def create_system(ctl, profile=None) -> SystemBase:
if ctl.id in self.system_by_id:
raise LookupError(f"Duplicated system id: {ctl.id}")
system = SYSTEM_CLASSES.get(profile, System)(self, ctl)
if not self.config[DISABLE_DISCOVERY]:
system._discover() # discover_flag=DISCOVER_ALL)
return system
and…
SYSTEM_CLASSES = {
"chronotherm": Chronotherm,
"evohome": Evohome,
"hometronics": Hometronics,
"programmer": Programmer,
"sundial": Sundial,
"generic": System,
}
I think we are at that stage now:
While I was thinking about how hard this would be to do - came up with a great (i.e. simple) idea!
Proof of concept is only about a dozen lines - and it works!
One thermostat goes constantly back to 20 degrees.when i put it back to 10 degrees a couple of minutes later it goes back to 20 degrees… i can’t find out what the problem is.
Yesterday i have used:
data:
entity_id: climate.slaapkamer_evi
setpoint: 18
duration: {minutes: 20}
after that i cant put it back to 10 degrees.
@zxdavb Hi. Getting this error appearing with the most recent builds.
2021-03-16T20:04:27.364676 056 RQ --- 01:210309 10:022270 --:------ 3220 005 00808C0000 < Validation error
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/evohome_rf/message.py", line 324, in is_valid
self._payload = payload_parser(self.raw_payload, self)
File "/usr/local/lib/python3.8/site-packages/evohome_rf/parsers.py", line 327, in wrapper
result.update(func(*args, **kwargs))
File "/usr/local/lib/python3.8/site-packages/evohome_rf/parsers.py", line 1626, in parser_3220
assert (
AssertionError: Unknown OpenTherm msg id: 140 (0x8C)
2021-03-16T20:04:27.380675 053 RP --- 10:022270 01:210309 --:------ 3220 005 00B08C0000 < Validation error
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/evohome_rf/message.py", line 324, in is_valid
self._payload = payload_parser(self.raw_payload, self)
File "/usr/local/lib/python3.8/site-packages/evohome_rf/parsers.py", line 292, in wrapper
result = func(*args, **kwargs)
File "/usr/local/lib/python3.8/site-packages/evohome_rf/parsers.py", line 1626, in parser_3220
assert (
AssertionError: Unknown OpenTherm msg id: 140 (0x8C)
Do you get many of these? Is the RP ever anything other than 00B08C0000? What is the make/model of your OpenTherm boiler?
Please send me a 24h packet log & I will take a look.
The reason why you’re getting errors now & not before is that - over time - evohome_rf is getting more strict about what packet are considered invalid.
Packet log please - the HA log too if you can.
The issue is that evohome_cc is stressing evhome_rf to a degree that has never happened before - the root cause could be anywhere in the system - the packet parser, for example.
I imagine it is a bug we can fix soon enough.
I think it was a problem with the batteries of the thermostat. I replace them and i have now test it multiple times and there is no error…
I’m having this issue now and then, I can manually fix (change the state) it or reboot:
Looks like it’s happening every 5-10 minutes. I’ll send the packet log over the weekend. Yes I’m seeing other responses include
2021-03-18T17:51:27.821360 052 RP --- 10:022270 01:210309 --:------ 3220 005 00708C0000 < Validation error
Something to be aware of is I have an Opentherm Gateway sitting between the boiler and the Opentherm Bridge. Boiler is an Ideal System 24.
Daft question.
I finally got every running with HA core and evohome_cc. Real pain that there is no package yet for python3.8 on raspbian, messed up my install by doing it manually and took me a day to sort it out.
For some reason my nanoCUL does not like 115200 baud and spits out gibberish, but works fine at 57600. I’ve managed to force evohome_cc to use 57600 through the config file and everything comes in nicely in HA, I see the entities getting populated etc.
The system is a full 12 zone evohome, with a ‘13th’ zone setup as a 2nd location using a round thermostat & RFG100. I can see the raw packets through the packet log, but would like to dig deeper using evohome_rf through the listen & monitor modes.
I can’t find a reliable way to get client.py to use 57600 baud, it defaults to 115200 - I’m probably missing something here on the CLI. The ‘workaround’ I use is to immediately force the tty device back to 57600 using stty, but it creates some funky messages in evohome_rf and messes up the initial probing through the RQ requests, and eventually the controller says ‘no’ and my schema is incomplete.
Any hints would be welcome on how to force evohome_rf to use 57600!
This is probably because of the configuration with the Arduino IDE - look at tools, host menu.
Having said that, there is no need fro 115200; 57600 may even be more reliable - I would be running at 57600 if I could (the reasons I can’t is I’m flipping between a nanoCUL and a HGI80 all the time, and the HGI80 is only 115200).
Use this configuration.yaml for HA:
evohome_cc:
serial_port: /dev/ttyUSB0
serial_config:
baudrate: 57600
scan_interval: 300
and for python client.py -c config.json monitor /dev/ttyUSB0, use this config.json:
{
"config": {
"serial_config": {
"baudrate": 57600
}
}
...
I have just added experimental support for ser2net, which offers some opportunities.
There is a new version of evohome_rf coming, 0.7.x:
Most of the above is experimental.
There will be a new version of evohome_cc too:
allowlist & blocklist are now allow_list and block_list
The above will likely cause teething issues - sorry.
Please aim to use the native operation modes (service_calls, device_state_attrs) when you can.
i am happy to test it 