Just had a look at the new services in 0.21.0, and I don’t appear to have get_dhw_schedule or set_dhw_schedule. I do have the equivalent zone services, and I have the other 6 dhw services.
Whoops - I left some code commented-out - fix coming.
What is the difference between sensor.01_223036_heat_demand and sensor.fc_heat_demand like mentioned in the Wiki: 3. How to: Useful sensor templates
Is it possible for someone to share working example of service calls, such as set_zone_config, set_zone_mode as not knowing the correct data to add is the main reson I could not test these service calls.
Upgraded to 0.20.22g and got the missing Temp value in Multiroom zone and more importantly, it stays on, unlike before where it occationally showed up and soon disapeared
Many thanks
hallway_heating_boost_1hour:
sequence:
- service: ramses_cc.set_zone_mode
data:
entity_id: climate.hallway
setpoint: '{{ states.input_number.hallway_heating_boost_temperature.state | float }}'
duration: {minutes: 60}
Example script above for ‘ramses_cc.set_zone_mode’, I have various sliders in the UI so the boost temperature/setpoint temperature can be adjusted easily.
There is, however, example data/format in HA:
- Developer Tools
- Services
- Select the service you want to use
- Go to YAML mode
- Fill example data
2 Likes
Added to the Wiki
Many thanks, what I was looking for
Well that’s bizarre - I was pondering the very same question this morning, the only difference being I’m looking at sensor.f9_heat_demand.
What I do notice is that sensor.01_xxxx_heat_demand lags behind the other one.
Daft question, how do I actually get the data out? The service call in developer tools gives a green tick and nothing else. Does this need to be scripted/templated into some kind of structure?
I have pushed 0.21.1 to the Candidate Release track - it includes selectors (see screenshot) for the service calls. The selectors will make it a lot easier to test the service calls.
Please keep on testing / reporting!
Fixes:
Added back in get_dhw_schedule and set_dhw_schedule.
Known bugs:
For svc_set_zone_mode:
ValueError: Invalid args: For temporary_override, setpoint/active cant be None
Here is a screenshot of the selectors at work:
1 Like
You should be able to get it from:
`{{ state_attr('climate.main_room', 'schedule') }}`
… but I think there is a regression!
Hang on a sec!
It is fixed now with release 0.21.2, use this template:
{{ state_attr('climate.bathroom_dn', 'schedule') }}
The answer is a little complicated.
First, there are three (or more) relays that may have demand sent to them by the controller:
F9: heating valve (BDR relay)FA: HW valve (BDR relay)FCappliance control (BDR relay, or OTB)
Then (if you look at your schema):
- most systems have a
appliance_controlrelay (+/- a DHW relay) - others may instead have a heating relay (+/- a DHW relay)
Finally, there is a difference between what the controller is asking fro, and what the relay is doing (most often, they are the same).
sensor.01_223036_heat_demand is the maximum of the zone’s heat demands. In a ‘simple’ appliance-control only system it will match FC.
If you add DHW, but still only have a appliance control relay, then FC will depend upon why there is a call for heat - from the CH, or from the DHW.
… and so it goes.
And just like that, there is release 0.21.3 that fixes DHW service calls!
There is still a bug preventing the setting of zone/DHW schedules.
Hallo zxdavb. I upgraded from 0.11 (was a very stable version) to 0.21 and I am really impressed. Very nice job. Thank you for all your efforts.
I noticed a bug. Calling get_schedule doesn’t get the current preset - for instance I am on custom but I am getting the normal heating preset.
You will have to describe this bug in much greater detail. If I can reproduce it, I will fix it.
There are different schedules for different presets. However, the service gets the schedule of the normal
heating mode without taking into consideration the active preset.
In order to reproduce the problem:
- program a schedule for the custom preset, which is different than the normal mode
- activate the custom preset
- get the schedule
It will report the schedule of the normal heating mode.
This is expected behaviour.
The schedule is the schedule - it remains the schedule, regardless of what system mode you are in.
There is no known way to retrieve the custom mode schedule.
You can see the remaining duration of the current mode, though.
In Developer Tools, Services this works:
service: ramses_cc.set_zone_mode
data:
entity_id: climate.bedroom
mode: advanced_override
setpoint: 21