Thanks for the quick reply :). The auxiliary contacts are indeed quite useful in with multiple distributors. Your solution with a zwave plug sounds good, thanks for the tip. Probably the best solution short-term. It would be great if the HCE80 could be persuaded to open an actuator without heat demand in the future, though (would like to work on the development once I have familiarized myself more with the protocol).
Iām sure @zxdavb would be happy to have someone with programming skills willing to help on the underfloor heating side because this is one of the system he cannot test easily. Being able to have the heat demand per HCE80 zones would be great. Being able to force an actuator to open would be nice too but I am not sure the evohome system has this capability.
At the moment I have some MT4 actuators which I also control artificially via a plug (instead of the HCE80) for my bathroom where I have a radiator and UFH. Evohome cannot control both types on a single zone and I did not want to create two zones for it so I start the actuator via control of a plug (230V actuator) to open this UFH zone at the time programmed for the radiator in the bathroom.
What is really nice is that when you have all the data from evohome in HA, you can start doing plenty of small automation like this easily. David has really done an amazing job with this integration 
I donāt know - I have never had an HCE80 to play with, so theyāre poorly understood.
If youāre keen, you could fiddle with the ramses_rf client, starting with something like:
python client.py /dev/TTYACM0 execute scan_full 02:123456
I will aim to do something about that when winter comes & I can get some packet logs.
FWIW, I am calling a UFH āzoneā a circuit, to avoid confusion with the evohome zones.
What does an MT4 do - it is an actuator for on/off flow valve? If so, are they NO (normally open) or NC (normally closed) for UFH? Or with a HCE80, you can choose?
So, itās (a number of) HCE80 switch ā MT4 on/off valve (opens the valve) ā pump (moves the water)?
- and somewhere in that, there is a call to heat from the boiler to make the CV hot
I guess with evohome, everyone is binding everything to evohome, right? (you can bind relays / 'stats to the HCE80 instead).
In most cases, the relationship between the HCE80 and the evohome controller is like that between a controller and a boiler relay - the HCE80 makes a call for heat to the controller.
WE could fool the HCE80 into calling fro heat (thus starting the pump), but it would send a call for heat to the controller (which would pass it onto the boiler relay)ā¦
However, I wonder what would happen if the controller was in away/heat_off modeā¦
- set controller to away mode for 10 mins
- fool HCE80 into asking for heat fro 5 mins by impersonating the controller?
First: What I need, gentlemen, it packet logs with heat demand!
Youāre welcome to have a good look around - and ask any questions to have.
The HCE80 (UFC) is only known to support these command class/verb pairs:
DEV_TYPE.UFC: { # e.g. HCE80/HCC80: Underfloor Heating Controller
Code._0001: {RP: {}, W_: {}}, # TODO: Ix RP
Code._0005: {RP: {}},
Code._0008: {I_: {}},
Code._000A: {RP: {}},
Code._000C: {RP: {}},
Code._1FC9: {I_: {}},
Code._10E0: {I_: {}, RP: {}},
Code._22C9: {I_: {}}, # NOTE: No RP
Code._22D0: {I_: {}, RP: {}},
Code._2309: {RP: {}},
Code._3150: {I_: {}},
},
ā¦ I have no idea what 22D0 does.
ā¦ It may well support other command classes / verbs.
Itās all here:
2022-10-05T13:55:16.318086 || UFC:222222 | CTL:111111 | I | heat_demand | 02 || {'zone_idx': '02', 'heat_demand': 0.0}
...
2022-10-05T14:00:06.987494 || CTL:081046 | | I | temperature | [..] || [{'zone_idx': '00', 'temperature': 16.34}, {'zone_idx': '01', 'temperature': 17.22}, {'zone_idx': '02', 'temperature': 17.87}...
...
2022-10-05T14:01:17.163086 || HGI:666666 | CTL:111111 | W | setpoint | 02 || {'zone_idx': '02', 'setpoint': 18.5}
2022-10-05T14:01:17.182930 || CTL:111111 | | I | zone_mode | 02 || {'zone_idx': '02', 'mode': 'temporary_override', 'setpoint': 18.5, 'until': '2022-10-05T18:00:00'}
2022-10-05T14:01:17.193918 || CTL:111111 | | I | setpoint | 02 || {'zone_idx': '02', 'setpoint': 18.5}
2022-10-05T14:01:17.205925 || CTL:111111 | HGI:666666 | I | setpoint | 02 || {'zone_idx': '02', 'setpoint': 18.5}
2022-10-05T14:01:17.950334 || UFC:222222 | CTL:111111 | I | heat_demand | 02 || {'zone_idx': '02', 'heat_demand': 0.88}
2022-10-05T14:01:18.113398 || UFC:222222 | CTL:111111 | I | heat_demand | 04 || {'zone_idx': '04', 'heat_demand': 0.81}
2022-10-05T14:01:18.269327 || UFC:222222 | | I | heat_demand | [..] || [{'ufx_idx': '00', 'heat_demand': 0.88}, {'ufx_idx': '01', 'heat_demand': 0.81}]
2022-10-05T14:01:19.258488 || UFC:222222 | | I | ufh_setpoint | [..] || [{'ufh_idx': '00', 'temp_low': 18.5, 'temp_high': 26.0, '_unknown_0': '01'}]
2022-10-05T14:01:19.655524 || CTL:111111 | | I | relay_demand | FC || {'domain_id': 'FC', 'relay_demand': 0.56}
2022-10-05T14:01:19.667297 || CTL:111111 | | I | heat_demand | FC || {'domain_id': 'FC', 'heat_demand': 0.56}
2022-10-05T14:01:19.686364 || OTB:999999 | CTL:111111 | I | heat_demand | FC || {'domain_id': 'FC', 'heat_demand': 0.99}
HVAC folks, I am considering purchasing a Nuaire Drimaster PIV unit to improve ventilation. Naturally I am looking for RAMSES-II RF/CC support but I am finding there are a myriad of options and itās not entirely clear which models support it. I have done some research and have come to the conclusion that only the following models support RF controls;
- DRI-ECO-LINK-HC
- DRI-ECO-HEAT-HC
- DRI-ECO3S-HEAT-HC
Is my understanding correct? Anyone with experience with integrating these units is very much appreciated.
I have (had) two - a DRI-ECO-LINK-HC & a DRI-ECO-HEAT-HC.
They both support RF - tip: look for the devices they interface with:
- DRI-ECO-4S (I have) or DRI-ECO-2S switches
- DRI-ECO-CO2 & DRI-ECO-RH sensor
The answer to the next question is:
- yes, I believe the switches / sensors can be faked, but - for the sensors - the equivalent of heat demand (31E0) is not well understood
Actually, I was using the temp sensor in the RH sensor to fake an evohome zone sensor.
BTW, a Heat HC is just a link HC with a small heater that you can buy / add-on separately.
1 Like
Yes. The MT4 is an actuator which opens or closes a circuit on the UFH distributor. The HCE80 sends power or not to the MT4 to control this opening / closing. When you buy a MT4 actuator you have the choice of NC or NO actuators. The HCE80 can be configured to use one or the other (but all actuators on a single HCE80 needs to be of the same type i.e. all NC or all NO).
Yes. From what I can see on my system it seems that evohome sends a signal to the HCE80 to open a cirtcuit of UFH when there is a need for heat in the corresponding zone a bit in the same way evohome would control a TRV to open or close a radiator valve (but the HCE80 is 0 or 100% open contrary to a TRV which can be partially open).
I guess so too. At least, based on the manual, this is the way it is supposed to be used with evohome.
Thanks for the helpful insight. I mainly want to put the unit into standby mode and turn off the heater when itās not needed which seems to be supported through the remote faking feature. Thank you for confirming my assumptions 
Has anyone had entity failure since upgrading the HASS OS to 9.2? Iām pointing my finger at that, but not 100% sure that it is responsible simply because that is the only element I can see has changed other that moving to 2022.10.
In essence Iām not getting any error messages from the Integration that I can see, but the sensors are all reporting as āUnavailableā. Iām on version 0.21.5 of the integration.
Home Assistant 2022.10.3
Supervisor 2022.10.0
Operating System 9.2
Frontend 20221010.0 - latest
I have the exact same problem. But Iāve had it for over 6 months.
FYI I did work with David to try and get this resolved but unfortunately we did not arrive to any resolution.
The entities will be set to Unknown. They will usually restore themselves (sometimes after a few hours, sometimes after a few days but also after a restart of HASS)
The funny thing is that the temperature is still being reported even though the state is set to Unknown. You can clearly see that in the below image.
Since Iāve had this issue for so long the integration has become a bit unreliable for me. I kind of gave up on it. Though to be fair thatās also because of the current gas prices and Iāve resorted to using my A/C units to heat the house instead.
For what itās worth, I have seen the following warning;
I am also using both evohome and ramses_rf and definition in yaml is as follows;
# Evohome home heating Integration
evohome:
username: !secret evohome_username
password: !secret evohome_password
scan_interval: 180
# Evohome local integration
ramses_cc:
restore_cache: false
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 3
01:076914: {} # CH/DHW system (evohome)
ramses_rf:
enforce_known_list: true
known_list:
01:076914: # {"alias": "--controller ZoneID 1659177 --"}
04:103285: # {"alias": "--zone 01 Bedroom 4 ZoneID 1659197 --"}
04:103287: # {"alias": "--zone 02 Laundry ZoneID 2941264 --"}
04:103289: # {"alias": "--zone 03 Bedroom 3 ZoneID 1659196 --"}
04:103291: # {"alias": "--zone 04 Bedroom 2 ZoneID 1659194 --"}
04:108651: # {"alias": "--zone 05 Lounge ZoneID 1659176 --"}
04:108653: # {"alias": "--zone 06 Lounge ZoneID 1659176 --"}
04:108655: # {"alias": "--zone 06 Office ZoneID 1659191 --"}
04:108657: # {"alias": "--zone 10 Kitchen ZoneID 1659192 --"}
04:116383: # {"alias": "--zone 07 Master Bedroom ZoneID 1659193 --"}
04:116385: # {"alias": "--zone 08 Cinema ZoneID 1780699 --"}
04:116387: # {"alias": "--zone 09 Landing ZoneID 1659198 --"}
04:116389: # {"alias": "--zone 10 Hallway ZoneID 1659195 --"}
04:181945: # {"alias": "--zone 11 Cinema ZoneID 1780699 --"}
04:181969: # {"alias": "--zone 12 Gym ZoneID 1659199 --"}
07:017642: # {"alias": "--hw ZoneID 1659230 --"}
13:019427: # {"alias": "--ch relay ZoneID 1659230 --"}
13:110263: # {"alias": "--hw relay ZoneID 1659230 --"}
I donāt see your HGI/nanoCUL in the known_list? Usually an 18:xxxxx I think? 
Iāll be honest I donāt understand why that record in the known_list is required (hasnāt been up to now), but I added it anyway and bobās your uncle all entities are now reporting.
This must have something to do with changes introduced either for 0.21.5 ramses_rf or for version 2022.10 of HA since nothing else has changed since it last worked. Either way thank you for suggesting, hopefully useful for others too.
The advice from @iMiMx is correct (I have removed the equivocation).
This warning is there no handle several scenarios, including:
- there is a second gateway in the area (rare I guess) - they all start
18: - there is a device with and id starting
18:that is not a gateway (common for HVAC)
It is a recommendation that you can ignore - it was put in because I was getting reports of errors from people with HVAC (i.e. non-evohome systems).
It is only a warning message - it does not change the behaviour of ramses_rf at all.
Any issue you have/had will be caused by something else, albeit in ramses_cc / ramses_rf / or something else.
@zxdavb Hi David, is the Set Zone Schedule service working in the latest release? I recall somewhere on the release notes that it was currently broken? Could you share same JSON schedule examples for reference?
set_zone_schedule:
name: Set the Weekly schedule of a Zone
description: >-
Upload the zone's weekly schedule from a portable format.
fields:
entity_id: *entity_id_zone
schedule:
name: Schedule
description: The weekly schedule of the zone in JSON format.
required: true
selector:
text:
multiline: true
IMO, this is currently broken. If is due to a difficulty deep in the RF protocol stack of ramses_rf that wasnāt apparent until now:
- the packets are very large (as large as is possible)
- they generate a lot of CPU time on the controller, so it doesnāt respond as quickly as for any other packet
The result is errors with timeouts & retransmissions, etcā¦
It may work as is, YMWV.
( hang on for an example )
All, if anyone is having persistent unavailable issues, please let me know. Tell me:
- sensors / binary_sensors, or
- (CH/DHW) climate / water_heater, or
- (HVAC) climate / remote
ā¦ and provide me the:
- packet log taken the time when the entity became unavailable
-
ramses_rf:section of configuration.yaml
@maesenator IIRC, the reception of the gateway (the USB dongle) wasnāt great for youā¦ And so data packets would timeout if they were not replaced with newer packets (because those packets are not being received).
Thatās my theory, anyway.
But your state card is of climate entities? And the graph is of a sensor? (i.e. two different entities)?
If it is the climate entities that are becoming unavailable, thatās a bit odd - they should never become unavailable at all!! If they are climate entities, then something else is going on. Please let me know.
This is the code for a sensor / binary sensor:
class RamsesDeviceBase(RamsesEntity): # for: binary_sensor & sensor
def available(self) -> bool:
"""Return True if sensor is available."""
return getattr(self._device, self._state_attr) is not None
This is the code for (edited for readability) of all other entities (fan/remote would be the same):
class EvohomeZoneBase(RamsesEntity): # for: climate & water_heater
_attr_available: bool = True
def available(self) -> bool:
"""Return True if entity is available."""
return self._attr_available # should always return True
Both screenshots were of the same climate entity.
I can provide logs again this weekend if required.