For every BDR device (starting with 13:), you will have two entities you can delete:
13:xxxxxx (enabled) - a binary sensor13:xxxxxx (modulation_level) - a sensor… and there will be a new entity, 13:xxxxxx (active).
For every OTB device (starting with 10:), you will have one entity you can delete:
10:xxxxxx (enabled) - a binary sensorBTW, I should say - if you’re desperate - there is a way to re-attach the old enabled data to the new active entity…
And my fake sensor is now unavailable and the rest of the zone entities where the fake sensor is in.
I see from your screen grab - relay_demand has a red exclamation mark next to it - this would be OK, if you are not restoring state. If so, it will appear soon enough.
Show me your configuration.yaml and the schema from the 01:xxxxxx (schema) entity.
Configuration.yaml:
evohome_cc:
# scan_interval: 300
restore_state: true
serial_port:
port_name: /dev/ttyUSB1
config:
enforce_known_list: true
max_zones: 6
packet_log: /home/homeassistant/packet.log
# advanced_override: true
schema:
controller: 01:155341
known_list:
- 01:155341
- 04:008512
- 04:070150
- 04:070154
- 04:070160
- 04:073460
- 04:108167
- 04:108169
- 04:108171
- 04:108173
- 13:189740
- 18:203293
- 03:256005: {faked: true}
Schema from entity:
schema:
controller: '01:155341'
system:
heating_control: '13:189740'
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
'00':
_name: Woonkamer
heating_type: radiator_valve
sensor: null
devices:
- '04:070160'
- '04:108169'
- '04:108173'
- '04:108171'
'01':
_name: Bijkeuken
heating_type: radiator_valve
sensor: '04:070154'
devices:
- '04:070154'
'02':
_name: Hal
heating_type: radiator_valve
sensor: '04:108167'
devices:
- '04:108167'
'03':
_name: Badkamer
heating_type: radiator_valve
sensor: '04:073460'
devices:
- '04:073460'
'04':
_name: Kantoor
heating_type: radiator_valve
sensor: '03:256005'
devices:
- '03:256005'
- '04:008512'
'05':
_name: Garage
heating_type: radiator_valve
sensor: '04:070150'
devices:
- '04:070150'
friendly_name: 01:155341 (schema)
I have added Usefull Sensor Template (Wiki) and 10:040239 (heat_demand) have a heat_demand there is a difference the templates return 8% the sensor (10:040239) returns 81%. How can I know what is the real demand?.
I would like to have an idea if the heating is running and what is the demand, could you help me with the best approach?
Can you use the latest templates (I’ve just updated them seconds ago). You can include the FC heat demand, but I believe it is a duplicate of another sensor, ``01:000000 (heat_demand)`.
I will be adding these sensors in due course, so that these templates will no longer be required.
Please note that modulation level (OTB) is different from heat demand (BDR).
There is a linear relationship between heat demand of a boiler an it’s on/off intervals (this is TPI) - during this time, evohome expects the boiler either to be at 100%, or not (the boiler’s opinion of 100% is a discussion in itself).
For systems where the boiler control, FC, is a BDR relay, this would be 01:054173 (heat_demand) (TPI) and 13:000000 (active) (you have to look at the schema for the device id of the BDR).
For systems where the boiler control is an OTB, the modulation level of OTB is the % of its maximum power output. There is no linear relationship between modulation level and heat demand.
I updated yesterday to 0.14.16 which solved the problem, yust updated to 0.14.17 will report back if there is something wrong.
In actuator_state, you have dhw_active and ch_active:
result = {
"modulation_level": percent(payload[2:4]),
"_unknown_0": payload[4:6],
}
if msg.len > 3:
result.update(
{
"_unknown_3": flag8(payload[6:8]),
"ch_enabled": bool(int(payload[6:8], 0x10) & 1 << 1),
"dhw_active": bool(int(payload[6:8], 0x10) & 1 << 2),
"flame_active": bool(int(payload[6:8], 0x10) & 1 << 3),
"_unknown_4": payload[8:10],
"_unknown_5": payload[10:12],
}
)
if msg.len > 6:
result.update(
{
"_unknown_6": flag8(payload[12:14]),
"ch_active": bool(int(payload[12:14], 0x10) & 1 << 0),
"ch_setpoint": int(payload[14:16], 0x10),
"max_rel_modulation": int(payload[16:18], 0x10),
}
)
Sorry, I do not have an OTB to test against.
@phdelodder So, a good starting point would be something like:
- platform: template
binary_sensors:
dhw_state:
friendly_name: "DHW active"
value_template: >-
{{ state_attr('sensor.10_00000_modulation_level', 'actuator_state').dhw_state }}
Actually, I’ve just realised: I need to add some state attrs on for you first…
Keep me posted when this is available, I would prefer for heating and dhw
@phdelodder and any of you with an OTB - who has a sense of adventure?
There is a lot of OTB data that is not yet exposed via HA… Some data is there, where I have no idea what it represents (little of this is documented, really). Another issue is that some data isn’t what it appears to be…
The way forward is for this state data to be exposed to HA as device_state_attributes (one set for OpenTherm, the other will be pure RAMSES).
Then, you will need to create a number of sensor templates, like:
sensor:
- platform: template
binary_sensors:
otb_flame_state:
friendly_name: "Opentherm Flame State"
value_template: >-
{{ state_attr('13:049798_modulation_level', 'status').flame_on }}
Then, graph them against each other in Lovelace so to interpret the results/confirm expected behaviour, etc…
Sadly, I have no OTB, so cannot QA that code at all… Someone will just have to run the code I give you, to see what eventuates… Bugs, probably…
Anyway, 0.14.18 released now.
This is not critical and low priority - just a possible feature request please? Is there any way to make the climate.* entities work with new long term statistics feature in Home Assistant? I can select the actual sensor.* devices in the Statistic Graph Lovelace Card, but I’m guessing that the climate entities aren’t configured for that. I tend to use the climate entities rather than the sensors because of reliability - I think the data for the climate entities comes from my touch controller rather than direct from the various devices around the house.
Back in my old Domoticz days, by default it allowed me to view graphs of historical temperatures plotted against the set point, which were quite useful for figuring out various heating issues and quirks. It would be great if I could do that in Home Assistant again using the climate entities somehow. I am thinking though that even if you could make the climate entities work with long term stats, you might just have to pick one value it exposes (i.e., current temperature OR setpoint…). current temperature would be preferable for me I guess but both would be ideal! As I say, it’s nothing critical, just a nice to have feature.
What part of the Lovelace UI is it where you see the long-terms stats?
In any case, AFAIK, it is only for sensor entities.
The way the evohome_rf data works is thus:
Another way of saying this - the thermostat ‘knows’ the temperature in a room & announces that data. Hopefully the controller heard that announcement. If it missed the announcement, then it behaves on teh basis of the data it has, and sends messages to actuators, etc. on that basis - so it may call for heat for a room that it believes to be below the setpoint, although the reality is that this isn’t the case.
Finally, you can turn any entity attribute into a sensor - example are above for (e.g.) f9_relay_demand. This shoudl give you the functionality you need?
Or you can use the graph card?
type: history-graph
entities:
- entity: climate.controller
hours_to_show: 72
refresh_interval: 0
It’s the Statistics Graph Card (Statistics Graph Card - Home Assistant) which I was hoping to use. It looks much prettier than the history graph, but I guess the history graph might be the simplest way to achieve it - I’m not sure if it will utilise the new historical statistics but I can test! I know I could fudge things by manually creating sensors to pull in the required values from the climate entities, but that’s not as tidy as if the climate entities just supported it direct. Perhaps you’re right and only sensor.* entities will ever work with the statistics graph card, but I thought I’d ask just in case!
@sOckhamSter I would simply use the sensors you got - all you need to know is what sensor entity is the temperature sensor for a zone - the schema will tell you that (with the main exception being when the controller is used as a zone sensor (or 00:xxxxxx TRVs).
I doubt if any differences between the zone temps and the zone’s sensor’s temps would be significant.
@zxdavb With these more recent builds I definitely think I’m seeing sensor updates being missed, that previously worked perfectly. It’s not happening consistently but it appears to be effecting the Stored HW entity, and BDR relays, temperature sensors I think are OK. Would a packet and HA log be useful to help debug?
As an example, the hot water sensor updates correctly, but the reported temperature within the stored HW entity lags and reports an older temperature or misses updates. Very certain that the controller is showing the correct temperature on screen.
Another example, the BDR that directly controls our boiler, the relay demand (FC) is missing updates that are shown on the heat demand (FF) entity. I believe that these should report the same values.
When not restoring the state, I’m also seeing the role attribute for my heating relay being correctly identified, but within a few hours it reverts to thinking its a hot water valve. The reported schema is correct.
Please plot these on top of each other - create a history graph card like so:
type: history-graph
entities:
- entity: water_heater.stored_hw
- entity: sensor.07_045960_temperature
hours_to_show: 24
refresh_interval: 0
And you’ll get (this is mine):
So mine are not exact, but they are the same, within the boundaries of rounding, etc.
This is because of several factors, but primarily:
In addition, one is rounded to the nearest 0.01C, the other is rounded towards the setpoint to the nearest 0.1C.
I could make the whole thing more accurate (more cohesive) by reducing the 900 seconds (say to 30 seconds), or asking the controller for the stored HW temp every time it sees the sensor send an update…
… but isn’t that overkill? There is a responsibility to not exceed the RF duty cycle.
I’ll have a think about the pros & cons, but people can let me know their thought on the above.