Hi community, I am sharing my custom zone and schedule cards as shown below. If you’re interested, I have documented them on the Wiki, I hope someone finds them useful 
They are fairly simple in design so they are straightforward and quick to implement.
For anyone looking at displaying or handling schedules in any way, I’ve posted my simple card on the Wiki, which gives a way of breaking out the days for a room and iterating through the setpoints.
Hi all,
Sorry, I am a bit new with this Evohome/Ramses. I installed Evohome_cc last winter, but I could not make it work. I am hoping this year it is different.
I have a couple of questions which I hope someone here would be able to answer:
Is it possible to run this custom_integration if we do not have an Opentherm Bridge (10:123123) nor a controller (01:123123)?
Would we be able to view the temperature setpoint, when the boiler is on, and in a future time, control the boiler with this set-up?
My setup looks as follows:
I am sadly unable to change it as we are renting this flat, and smart control of the heating would really help with bills
If anyone could help us, we would be really grateful! Thank you community!
Yes - but you will have reduced functionality.
You have a BDR (a relay, 13:xxxxxx) - that is a TPI version of an OTB (which uses modulation rather than TPI).
Battery-operated controllers do not constantly listen for packets - so ramses_rf can do little with them, other than listen out for their transmissions.
At best, YMMV. I am not able to contribute any development time to improving support fro wireless programmers.
My suggestion to you is to get an old evohome controller - even the old black and white model - in Summer you could have picked these up from ebay for less than £50.
Turn off the programmer (just take the batteries out) - bind the BDR to your new controller and you’re fully supported.
Then, when you move out - put the batteries back in the programmer, rebind the BDR to it & take your evohome controller with you when you go.
All, I have lost track - if anyone is running 0.21.5 and would like to report any bugs, I’d be grateful if you could let me know.
I know that: you can’t set schedules
I don’t know if this is an underlying HA issue, but if you set a duration for a service using the gui, eg ramses_cc.set_dhw_mode, it interprets the value in seconds, rather than minutes:
- id: '1664999803808'
alias: '1'
description: ''
trigger: []
condition: []
action:
- service: ramses_cc.set_dhw_mode
data:
duration: 60
mode: single
should be
- id: '1664999803808'
alias: '1'
description: ''
trigger: []
condition: []
action:
- service: ramses_cc.set_dhw_mode
data:
duration:
minutes: 60
mode: single
I’ve finally upgraded both my ramses raspberry pi systems and everything is working perfectly for me.
Thanks for all the hard work you’ve put in over the years.
I am contemplating merging the 2 as there is now support for 2 controllers but to be honest, its working really well at the moment so I might just leave it as it is. It also gives me a chance to update 1 controller at a time so that’s a good point to not merge 
I have a question, rather than issue. I have re-installed my system and notice the climate entity_id naming convention is different.
Now
climate.ramses_cc_01_[controller id]_[zone_id]
where previously it was
climate.[zone name]
Was this a recent change?
That’s interesting, as mine are climate.evohome_cc_01_[controller id]_[zone number]
(I’m running 0.21.5)
This is the unique_id - no two HA entities (zones) on the planet will have the same ID:
climate.evohome_cc_01_145038_09
climate: is a climate entityevohome_cc: is the ramses_rf integration (the older name is an unfortunate anachronism)01_145038: controller 01:145038
09: zone index 9 (the zone occupying the 10th slot)I can’t use the zone name as a unique ID, because the name is an attribute, not an identifier.
You’ll see similar elsewhere:
binary_sensor.01_145038_09_window_open
Entities in HA have multiple identifiers / names - the unique_id is persistent. The name is the zone name, and the entity_id is configurable through the web UI - HA tries to pick a ‘friendly’ name if it can (this piece of code has changed recently, watch this space).
This is an entity_id:
climate.main_room
Anyway, the only ID guaranteed not to change is the unique_id.
You can use any id you like in automations, etc.
There is a bug in HA that is affecting anything with a duration - I will submit an issue soon enough, then address this when there is a fix.
Thanks for the detailed explanation. it would seem that I have observed this recent change in behaviour. I do like the new format, makes it easier to work with 
Just wondering if there’s a easier way to use the RAMSES RF: Set the ‘Mode of a Zone’ - ‘Temporary override’ option without having to specify the date, but just time (until midnight of the the day). For example if I use below, I can run it anytime and have it set the temp till 8PM but will not work tomorrow
service: ramses_cc.set_zone_mode
data:
entity_id: climate.hall
mode: temporary_override
setpoint: 17
until: 2022-10-06 20:00:00
Why not use advanced_override? It will run until the next schedule change and no need to put a timestamp in the call
Could you use the new scheduler helper to start and stop your automation?
I use that at the moment, but that means its limited by scheduler, hence exploring.
Thanks
Yes, One option is to use the Permannt override option and then use another automation/service call to revert back to schedule
Thanks
Hi @zxdavb, is it possible to provide the zone active_faults attribute like in the cloud version? I notice it’s missing for zones but the faults are listed in the controller log which is nice Previously I was using this active_faults attribute to show a fault icon on the associated zone card. Here is an example from Evohome cloud;
status:
active_faults:
- faultType: TempZoneActuatorCommunicationLost
since: '2022-10-05T21:16:31'
hi @zxdavb , I think It would be great feature if we could use Today and Tomorrow within the service calls that use Until, eg until: tomorrow 20:00:00
service: ramses_cc.set_zone_mode
data:
entity_id: climate.hall
mode: temporary_override
setpoint: 17
until: 2022-10-06 20:00:00