Hehe no problem, I appreciate the effort you’re going to on this project 
So: try 0.16.5 (sorry, typo) 0.16.5:
- should fix zones losing state (e.g. mode) & params (e.g. name)
- you can leave
restore_state: true
1 Like
Sorry if this has been asked before (I couldn’t seem to find it).
Simplified I have 3 rooms, each one of them has a radiator that is always open and two of the rooms have two additional radiators that have HR92’s on them) and Evohome is controlling the central heating system through an OpenTherm bridge.
So there is this one room in the house that doesn’t have a TRV, but does have an old-fashioned radiator that is always open. What I would like to do is be able to heat up that room (room 3) without having to open up / heat up the other two rooms. So I want to make evohome send a signal to the boiler to turn on the heat, without it opening up any of the four real TRV’s.
I’m thinking this means faking a TRV? Are there any plans to add this fake-TRV functionality?
Or are there other options, without faking a TRV/zone? Can I just tell the R8810 to turn on the heating…?
Kinds regards, keep up the hugely impressive work!
I assume you have two zones, one for rooms 1 & 2.
You can create a 3rd zone, using (say) the zigbee temp sensor via a faked sensor. You can do without an actuator and see how you get on (just stop creating the zone after adding the sensor).
The sensor will cause the controller to send a call for heat if temp sufficiently lower than setpoint.
As you infer - any call for heat from any zone will cause all of the three ‘always open’ rads to warm up - those zones (rooms) may well go above their setpoints…
There are no current plans to fake a TRV, but there are plans to fake a BDR91, which will be just as good. You could - for example - use this to send an instruction to a bluetooth TRV to open much as a evohoem TRV would.
You could instruct the R8810 so, but the above will be easier/simpler (and neither option is currently implemented).
Thanks for the quick reply!
Yes, you are right, I currently have two zones and will try to add a third one with just the faked sensor.
Faking the BDR91 sounds interesting as well, as this may allow me to extend the system to a room currently outside of reach of the evohome system (but in range of wifi and zigbee).
config:
max_zones: 7
Is max_zones still under config: or now the renamed ramses_rf: ?
EDIT: Am assuming it is a documentation issue (?) and that it is now under ramses_rf? As this is a ramses_rf limitation/feature?
I’ve managed to create a zone with the fake sensor and Home Assistant is reporting the temperature from the zigbee sensor to the Evohome controller correctly, but the heat demand of the zone stays at 0%, even though the temperature is over 2 degrees below the setpoint.
I’m wondering if this is caused by the absence of a TRV/radiator in that zone.
When creating the zone I picked the option ‘Radiator Valve - Radiators controlled by HR92s or HR80s’. Should I perhaps select a different heating type?
The other options being:
- Underfloor heating - Underfloor heating controlled by an HCE80 or HCC80
- Mixing valve - Modulating valve controlled by an HM80
- Zone valve - Motorised valve controlled by a BDR91
- Electric heat - Small electric load controlled by a BDR91
And I found some comment from some dude on some forum stating that when you use Evohome with multiple zones then all zones will need an actuator. So it might sound like I’ll need to wait for BDR91-faking 
It should be:
ramses_rf:
max_zones: 7
Are you looking at demand in HA, or in the controller UI?
Heat demand in HA is fudged - the controller doesn’t provide this data, so it is constructed from the demand of individual actuators. This zone doesn’t have any actuators, so nothing to fudge with.
In your case, look at the demand in the controller UI, via a long-press of the settings button - the definitive answer will be there.
Yes/No, and BTW - the difference between ZoneValve and Electric zone is that - by definition - the electric zones do not cause a heat demand (they do not ask the boiler for heat).
If there is no demand in the controller UI - use a mix valve zone.
updating from 15.5 to 16.5 makes everything “not available” did i miss some braking changes ?
My config:
evohome_cc:
serial_port: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
restore_state: false
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
ramses_rf:
enable_eavesdrop: true
schema:
controller: 01:*******
I did see the same earlier when I upgraded from 0.14.x - just give it a few minutes and it seems to sort itself out.
Waited more then 1 hour, then downgraded back to 15.5 and all was working again…
I don’t see any immediate issues with the config - this is mine (I have a lower baud rate set on the nanoCUL)
evohome_cc:
restore_state: true
serial_port:
port_name: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
baudrate: 57600
packet_log:
file_name: /config/packet.log
rotate_backups: 3
ramses_rf:
enforce_known_list: true
max_zones: 8
schema:
controller: 01:xxxxxx
known_list:
- 01:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 04:xxxxxx
- 07:xxxxxx
- 13:xxxxxx
- 13:xxxxxx
- 22:xxxxxx
- 22:xxxxxx
- 22:xxxxxx
Don’t use eavesdropping unless you need to. Use restore state if you can.
evohome_cc:
serial_port: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
restore_state: true
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
ramses_rf:
enable_eavesdrop: false
schema:
controller: 01:*******
Based on your feedback i installed 16.5 again, now it works… very strang since waited almost 2 hours the first time.
But thanks ! I use the HGI80 that one has a higher baudrate.
@all. I think there is no need to obscure device_ids, but up to you…
I wasn’t sure… so just did it in case
Did you already recieve the BDR91T ?
I read some “rumoers” that it has 2 device ID’s ? (one for cooling and one for heating ?)
There’s no need.
It hasn’t arrived… I am not in a rush. I had it before, it only had one device ID then.
You genius! This did the trick
Though the zone demand in the controller UI remains at 0% I can now see the boiler demand going up in the controller UI and the heating actually turns on.
Updating python solved the problem. Thanks a lot.
I’ve sent you a PM with a link to the logs for the scan_hard.