At the moment I an refactoring for ventilation systems - they break the the rules I had previously thought I could rely upon - then we’ll implement FAN entities
I have an issue: some rooms are heating out of nothing until 20 degrees. Nobody gave a command to heating that room. Also when i control a valve manually, it reboots the valve. Verry strange… i will enclose a log file within an hour.
OK, new releases:
- 0.19.0 - lot of changes, will form the basis for HVAC integration
- 0.18.x - latest stable (for bug fixes only)
- 0.17.x - previous stable - no updates now
Please tell me which version you’re using, if you want to report any issues.
1 Like
Do you need log files also when there are no problems?
I’ve updated and no problems so far.
Generally, yes.
The reality is simple: the more information provided to me, the more likely I am to address the problem.
In addition, the issue need to be ‘interesting’. This is where the version comes in: I will no longer look at 0.17.x issues, I will jump on bugs for 0.18.x, and I will consider enhancement requests only for 0.19.x.
Of course, there are other reasons for things to be interesting… It is a little hard to predict what they might be, so best to hedge your bets & includes logs.
Can anyone with a HVAC system:
- MEV (extraction ventilation, e.g. Itho CVE-S), or
- MVHR unit (heat recovery ventilation, e.g. Itho HRU)
… please PM me a packet log captured whilst the RFT switch/controller is being (re-)bound to the system?
1 Like
Anyone help with this?
Probably missed something, but going from 0.17.x to 0.18.7 the heat_demand from each zone entity has disappeared. Was this intentional? Was tracking it on a graph against setpoint and current temperature.
No, zones should still have heat demand.
FYI, that piece of code is unchanged from 0.17.15 to 0.18.7 for almost all zone types:
@property
def heat_demand(self) -> Optional[float]: # 3150
"""Return the zone's heat demand, estimated from its devices' heat demand."""
demands = [
d.heat_demand
for d in self.devices
if hasattr(d, ATTR_HEAT_DEMAND) and d.heat_demand is not None
]
return _transform(max(demands + [0])) if demands else None
However, version 0.18.x introduced a more accurate heat demand for underfloor heating, from:
def heat_demand(self) -> Optional[float]: # 3150
"""Return the zone's heat demand, estimated from its devices' heat demand."""
return self._msg_value(_3150, key=ATTR_HEAT_DEMAND)
to
def heat_demand(self) -> Optional[float]: # 3150
"""Return the zone's heat demand, estimated from its devices' heat demand."""
if demand := self._msg_value(_3150, key=ATTR_HEAT_DEMAND):
return _transform(demand)
The above should be straightforward - it shouldn’t cause the issue you describe.
That is the best answer I can give with the information you have provided.
All radiator zones (no UFH). Here is a zone state with 0.18.7. Also tried a restore_cache:false, same behaviour. Logs are clean.
hvac_modes:
- auto
- heat
min_temp: 10
max_temp: 24
preset_modes:
- none
- temporary
- permanent
current_temperature: 19.1
temperature: 19
hvac_action: idle
preset_mode: temporary
zone_idx: '03'
heating_type: radiator_valve
mode:
mode: temporary_override
setpoint: 19
until: '2022-03-05T23:30:00'
config:
min_temp: 10
max_temp: 24
local_override: false
openwindow_function: true
multiroom_mode: false
controller_id: '01:201047'
schema:
_name: Offices
zone_type: radiator_valve
zone_sensor: '22:028749'
sensor_alt: '22:028749'
devices:
- '22:028749'
- '04:177711'
- '04:173146'
- '04:179866'
actuators: []
params:
config:
min_temp: 10
max_temp: 24
local_override: false
openwindow_function: true
multiroom_mode: false
mode:
mode: temporary_override
setpoint: 19
until: '2022-03-05T23:30:00'
name: Offices
friendly_name: Offices
supported_features: 17
And with 0.17.15
hvac_modes:
- auto
- heat
min_temp: 10
max_temp: 24
preset_modes:
- none
- temporary
- permanent
current_temperature: 19.1
temperature: 20
hvac_action: heating
preset_mode: temporary
controller_id: '01:201047'
zone_idx: '03'
config:
min_temp: 10
max_temp: 24
local_override: false
openwindow_function: true
multiroom_mode: false
heat_demand: 0.58
mode:
mode: temporary_override
setpoint: 20
until: '2022-03-05T23:30:00'
heating_type: radiator_valve
friendly_name: Offices
supported_features: 17
Heat demand is no longer a state attribute of the climate entity. It is now a sensor in its own right.
For example, if your zone is called climate.offices, then the sensor may be something like sensor.01_145038_03_heat_demand:
controller_id: '01:145038'
device_id: '01:145038_03'
domain_id: '03'
domain_name: Offices
unit_of_measurement: '%'
icon: mdi:radiator-off
friendly_name: Kitchen heat_demand
Note that the example above, zone 0x03 is called ‘Offices’.
I appreciate the entity ids of the climate (zone) entities and the (zone) sensor entities are not consistent.
Ah, missed that change! Thanks David, will change my dashboard config.
Actually, looking at the state attrs for a climate entity - they’re a bit of a mess - I will be removing the params & otherwise tidying it up - shouldn’t affect you, though.
… wont fix this in 0.18.x, but will rationalise it in 0.19.x.
Can anyone running the latest 0.18.x tell me if the heat demand for their UFH zones is correct?
I have one example, but I need more (especially systems with sequence numbers, if you know what they are).
Is this some you need from my PIV?
Hi,
I just noticed that you have a topic on ha forum. I can help you get a log inluding re-bound of multiple sensors. Tomorrow I will clear all bounded devices and re-couple (RFT remote, Co2 sensor and the ITHO spider thermostat). Is rebounding a single time enough?
FYI I have a system where can control my HRU, I have no spider gateway or any rf opentherm device to give heat setpoints to the thermostat.
It would would be a little instructive if I could see a packet log where you rebind your remote to your PIV (but your system doesn’t use sequence numbers).
Such a packet log would be very useful both now and in the longer term.