Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

Share your Projects!
1154

I have the following script, and a number of similar:

front_room_heating_boost_1hour:
  sequence:
    - service: evohome_cc.set_zone_mode
      data:
        entity_id: climate.front_room
        setpoint: 24
        duration: {minutes: 60}

It takes around 1 minute to update the UI with the new set point, after executing the script. Video below shows executing the script, then another to reset/remove the override, takes around 2 minutes. I do have a scan interval of 60 seconds, in case it is related:

Changes happen on the controller screen instantly.

1155

@iMiMx Thanks for your very useful post.

I would say the update at 0:41, and the second 1 minute later, correspond to the scan intervalā€¦ if your scan interval was 300 seconds (which I recommend), then your UX would be worse.

Iā€™ve got two options for addressing this: I will push the easier solution first, and could you test it again?

1156

Sure, no problem.

1157

@iMiMx I just pushed an update to evohome_cc could you kindly test it as before?

1158

Looks good to me - I gave the system 5 minutes after a restart, just in case, then tested as before. Immediate changes in the UI.

I guess I can probably up my scan interval - suspect I probably dropped it so the UI updated faster.

However, if for arguments sake, I accept/set the default 5 minute scan interval, someone then makes a change via the controller (or a change not via HA), is it potentially a maximum of 5 minutes before evohome_cc will pick this up?

1159

Yes, changes from the evohome UI may take as long as scan interval to show up in HA (i.e. evohome_cc, although they show up immediately in evohome_rf) changes from the HA UI should show up in evohome immediately, and in HA in about a second (or less).

There will be some work done at a future point where such changes will show up in a chair immediately, But I should make it clear my recommendation for a 300 second scan interval remains otherwise HA will get flooded with micro data.

1 Like
1160

Ok - I wondered if it was more due to the amount of RF data going back and forth. As I no longer have the Internet Gateway plugged in, I seem to recall that it was rather ā€˜chattyā€™, I thought 60 seconds might be acceptable.

But Iā€™ll certainly have a play with the default, 5 minutes, 99% of all of our changes are via HA only these days anyway.

1161

The scan_interval does not affect the amount of RF traffic (between evohome_rf and an evohome controller)ā€¦ it changes how often evohome_cc asks evohome_rf for state changes.

evohome_cc then passes those changes up to HA, which logs themā€¦

Without going into details, a scan interval < 300 seconds is unnecessary and causes issuesā€¦

ā€¦the only exception is that the data in HA, and thus in the Lovelace UI may be a few minutes old (I have plans to solve this).

1 Like
1162

Okey dokey - have hashed out the scan_interval line and reloaded :slight_smile:

1164

Coming soonā€¦

create_sensor:
  name: Create a Zone sensor
  description: >-
    Create an emulated temperature sensor for a zone. Once created, it will 
    immediately enter bind mode and respond appropriately to any controller. 
    The controller must be listening for a sensor before calling this service 
    (as per the normal bind process).

set_zone_temp:
  name: Set a Zone's temperature
  description: >-
    Announce the current temperature of a Zone's temperature sensor. The zone 
    must have an emulated sensor (see the `create_zone_sensor` service call).
  fields:
    entity_id:
      description: The entity_id of the Zone.
      example: climate.main_room
    temperature:
      description: The current temperature in degrees Celsius.
      example: 21.3
1165

Great :smiley:
Thanks for the update on this feature and for your hard work on this integration.
Iā€™ll definitelly test this feature once it is available :slight_smile:

1166

This is a great feature. Thank you for the update!

1167

I switched to HACS install a little while ago and just updated things, I now see the following in the logs, Iā€™m unsure how to address this now Iā€™ve use HACS to install?

Logger: custom_components.evohome_cc
Source: custom_components/evohome_cc/__init__.py:80
Integration: RAMSES RF (documentation, issues)
First occurred: 4:13:51 PM (1 occurrences)
Last logged: 4:13:51 PM

evohome_cc v0.8.4, using evohome_rf v0.8.3 - versions don't match (this is bad)
1168

I am sorry - this one time, this isnā€™t bad.

2 Likes
1169

Is there perhaps a way for us/me to switch to this behaviour by changing a specific line(s) of code (locally)?

Iā€™m aware this will have to be done everytime I upgrade to a new version and might break in future versions, but at the moment the current behaviour means I canā€™t use this integration with any (semi-)standard climate UI component.

Thanks again for your amazing work!

1170

Create your own github fork (click fork), edit the code, import your fork. Then, merge changes from the master as/when :slight_smile:

Iā€™ve done this below:

I had a few days of someone nudging the climate UI to change the temperature and setting a permanent override, which was not how weā€™d been used to using evohome before this integration.

1171

Ah, thanks :+1: I was looking for the specific required code change and I think I found it here: Update climate.py Ā· iMiMx/evohome_cc@218e5f5 Ā· GitHub

1172

i changed this line 248 in custom_components/evohome_cc/climate.py because the default permanent override is not the wanted situation, i mainly set the temp of a zone with google home and than i want it to the end of the default program, and with google home i cannot choose permanent or tempoary, can this made configurable maybe?

self.svc_set_zone_mode(setpoint=kwargs.get(ATTR_TEMPERATURE))
to
self.svc_set_zone_mode(setpoint=kwargs.get(ATTR_TEMPERATURE), mode=ZoneMode.ADVANCED)

also tried the scripts found here (but these are only for the gui):

with this script i get the error:
cannot call script/evohome_simple_thermostat extra keys are not allowed @ data[ā€œsetpointā€]

1173

Faked Zone Sensors

I am shortly about to release a new feature - faked zone sensors.

Be aware, zones can only have 1 (or 0) active sensors.

The faked sensor behaves like a round thermostat, and the current (measured) temperature can be set via a HA service call. Note that there is no value in emulating other TR87RF functionality, such as changing the zone setpoint (target temperature), so do not expect this to happen.

The emulated (faked) zone sensor works with an evofw3-compatible interface, but not yet with a HGI80 - there are deep design features of evohome_rf that make this difficult (in essence, because a HGI80 is a HGI80 & not a TR87RF and evohome_rf is very strict about these things)ā€¦

ā€¦ nonetheless, I am committed to making a HGI80 function as a faked zone sensor at some future point.

Another advantage with an evofw3-compatible interface is that you can have sensors for multiple zones, and not just the one zone, as would be the case with a HGI80ā€¦

In future, relays will also be fakeable (able to be emulated)ā€¦ even more reason to buy one of these USB dongles

So if anyone is interested in testing, you need a evofw3-compatible dongle, and a HA thermostat, such as, for example:

The idea is that you use an automation to pass data from the thermostat to the faked sensor.

To set up the faked sensor:

  • get the controller listening for a sensor to bind for the zone of your choice
  • call the evohome_cc.create_sensor service call

To update the zone (measured) temperature

Use something like the following service service call:

service: evohome_cc.set_zone_temp
data:
  entity_id: climate.main_room
  temperature: 21.3

Do let me know how you get on with it.

1 Like
1174

Does this mean profiles are not ready to test with Hometronic yet?