Has anyone looked at the transmitted radio packet that is generated by ramses_cc for the eco_boost function. I just thought that given the mode had the word boost rather than just eco, it had been coded to send the 1 hour time for the eco system mode.
I looked at the RF packets sent. If you use the climate.01_078710 and choose the preset Eco, Eco is set permanently, as expected.
However if you call the service, the preset is eco_boost. And for whatever reason it seems to be invoking this preset for 1 hour even without specifying any time constraint.
service: ramses_cc.set_system_mode
data:
mode: eco_boost
entity_id: climate.01_078710
So its either a bug with the service call. Or the preset eco is missing.
Hey Guys question,
Ive got the ssm and of looks like in loses connection occasionaly ,
Is there anything i could do except !Ft and !Fs! ?
Evohome controller is about 80cm away from the ssm
Answering my own question. Its definitely a bug with the service call. The services.yaml was updated about a month ago. Now the climate.py seems to be getting a duration value passed to the set_system_mode function
I hadn’t thought of trying it that way and it works for me too. I’ll raise it as a bug and David can either look at it or ignore it if it’s intended behaviour.
So this is a start - have a look and let me know what you think:
Ideally, the entity ids should be all lowercase - too late now.
The battery thing looks a bit messy - I’ll have a think & make a decision - it is not in the test yet.
@philchillbill (or @brucemiranda)
For sensor.${dhwRelayId}_relay_demand, where are you getting dhwRelayId from?
Be specific as you can, please.
- I assume it’s from the schema, but from which key?
- if for
appliance_control, what do you do if the value is null? Do you look elsewhere? - or are you using
${cid}heat demand with/withoutFC, orF9orFA
You should be using extra_state_attributes:
{'id': '07:046947', 'battery_level': None}
This is a bug - it should be: extra_state_attributes.battery_level - I will make that change in the next release.
In binary_sensor.01_xxxxxx_status the stored_hotwater 13:xxxxxx (i.e. hotwater_valve) value is what I use to determine the ${dhwRelayId} for sensor.${dhwRelayId}_relay_demand.
I do not need to use the value of appliance_control anywhere in the skill
The thing is, I have to support people who may be on different versions of ramses_cc as I don’t just tell people to update. So I guess I’ll have to support 3 different schemes for battery_level to cover all possible versions.
I would have expected a value like 13:xxxxxx for the hotwater_valve entry in the SCHEMA. Right now, the value is None.
The following premise is incorrect:
If people have DHW, they have any one of:
{
"system": {"appliance_control": "13:120242"},
"orphans": [],
"stored_hotwater": {
"sensor": "07:046947",
"hotwater_valve": None,
"heating_valve": None,
},
… (above is the most common, I feel) or:
{
"system": {"appliance_control": None},
"orphans": [],
"stored_hotwater": {
"sensor": "07:046947",
"hotwater_valve": "13:120242",
"heating_valve": ...,
},
or (if using an OTB rather than BDRs):
{
"system": {"appliance_control": "10:123456"},
"orphans": [],
"stored_hotwater": {
"sensor": "07:046947",
"hotwater_valve": None,
"heating_valve": None,
},
I am sorry - this is not fair on you - totally my fault - what ever goes into the test suite will not be changed without the tests failing - so that will help.
The unit test is much more extensive that the first version I posted - I want you to tell me what attrs you are using as well - e.g. current_temperature, for one.
I understood that 10: is OTB and 13: is BDR. Surely appliance_control is the device controlling the boiler (can be 10 or 13) while DHW always needs a separate BDR device to control it?
Yes.
More correctly, the ‘heat source’: it could be a community HW system (common in Europe, but I’ve seen in UK).
… and know if can be a source of cold as well as heat (a la BDR91T).
No.
Actually - now I think about it, I’m not so sure! I have an unusual setup here as a testbed, so maybe ignore me.
In addition, I use 01:123456_FA_heat_demand instead - so that confused me.
Does 01:123456_HW_heat_demand not give you what you want?
I discussed this yesterday with Bruce and he was not a fan of this sensor. Perhaps he can explain why.
The attrs I extract are
current_temperature,
mode.mode,
mode.setpoint,
mode.until,
status.temperature_status.is_available (which no longer seems present in the latest ramses_cc)
Regarding the possible System Modes, the mapping I expect between your mode names and those used in the TCC API is:
auto: ‘Auto’,
eco_boost: ‘AutoWithEco’,
away: ‘Away’,
day_off: ‘DayOff’,
custom: ‘Custom’,
heat_off: ‘HeatingOff’
Can’t recall why I removed this - but probably because it was unreliable? I works by paying attention to when a device was last heard from - the issue being that evofw3 wont hear exactly what the controller hears.
How important is it to evo_control? What entities do you want it one - just tcs / zone / dhw constructs, or actual devices like CTL, BDR, TRV?
I just use it because TCC also reports it. I’ve only ever seen it to be false when a zone is bound but not communicating, like e.g. a spare HR92 lying in a drawer without batteries but still bound. When I get this state I display a ? to draw the user’s attention to the zone. They can then hide it from their dashboard if they like but I don’t auto-hide. It’s not a big deal if it’s gone but if you want to put it back then I expect it in the climate.${cid}_${zid} entities so not in the actual devices.