I must admit that I’m struggling to get my head around the best way to decode and display the schedule. I wondered if you would have more success with flex_table_card?
Good luck!
I already tried that without success. I think the difficulty is the schedule attribute output is a “list within a list” so there isn’t a standard way to create the table, i.e. time_of_day is listed within day_of_week list.
Yes. I can pull the individual elements out in dev tools, but can’t see a sensible way to do this easily within a lovelace card
Nice. Look forward to seeing the code.
Our heating is still off, but soon we will need it and if this will work I will scream like a child.
I think the first thing to do is to check / check your system configuration - there is some evidence that your system is mis-configured.
In this sense, the schema is only there to calculate zone heat demands - but it’s no use having a ‘correct’ schema, if the system configuration is otherwise.
FWIW, my instinct is - as going ‘off-grid’ with ramses_cc mostly involves talking to the controller (rather than the boiler relay) - that you will have most functionality as-is.
In short - I expect that if your system is configured correctly, you can basically ignore any errors.
… although I would always be planning to remove such problems.
Is there any specific functionality that you need/want?
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.
4 Likes
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 have a Wireless relay box (BDR91) (13:132944) connected to the combi boiler.
- I have a Thermostat with setpoint schedule control (EHE0200361 , I believe) (12:236016).
- I have a “Honeywell Gateway Interface” (DIY CC1101-based, as shown in evofw3) (18:262143).
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 entity -
evohome_cc: is the ramses_rf integration (the older name is an unfortunate anachronism) -
01_145038: controller01: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.
1 Like
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 