You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some features the boiler can indicate support through special messages, currently exposed as binary sensors:
dhw_present for Status(dhw_enable) and dhw related messages
cooling_supported for Status(cooling_enable) and cooling_control
ch2_present for Status(ch2_active) and ch2 related messages
dhw_setpoint_transfer_enabled for reading t_dhw_set
& dhw_setpoint_rw for writing t_dhw_set
max_ch_setpoint_transfer_enabled for reading max_t_set
& max_ch_setpoint_rw for writing max_t_set
If one of the messages is being sent that has a support indicator, we should query support at startup and automatically disable all unsupported messages. This information should probably be included in the schema, either in the binary sensors as an indicates_support_for or in the entity's with some support_indicated_by with a format similar to auto_min/max_value.
Clear logging is required, so useful to do this on startup as users are more likely to see the logs at that point.
The text was updated successfully, but these errors were encountered:
…at (ov1d1u#4)
has a min flow temp of 50C and a max of 70C set the pid output would be
clipped, a pid output of 100% would be 70C as you expect, but a pid
output of 70% is the same as 100% - 70C. The same goes for minimum flow
temp, 1% to 50% pid output produces a flow temp of 50C.
This is problematic for PID tuning, producing results which dont work.
It also causes bigger jumps in temperature when PID is modulating in the
50-70% range, a large drop in requested temperature will result in the
boiler shutting off instead of modulating down. Since I implemented the
change on my system I'm seeing more stable temperature regulation,
much less target temperature overshoot, and much less boiler cycling on
and off, which is how an opentherm system should work. Setting output
sample averaging also helps to smooth the boiler setpoint, I am
currently using 2.
My system is an Intergas 18kw system boiler with 14 radiators in a poorly
insulated Victorian home built in 1898 for reference. The outside
temperature while testing has been in the range -4 to 2C, inside room
setpoint 20.8C
FreeBear-nc
pushed a commit
to FreeBear-nc/esphome-opentherm
that referenced
this issue
Nov 16, 2024
For some features the boiler can indicate support through special messages, currently exposed as binary sensors:
dhw_present
for Status(dhw_enable) and dhw related messagescooling_supported
for Status(cooling_enable) and cooling_controlch2_present
for Status(ch2_active) and ch2 related messagesdhw_setpoint_transfer_enabled
for reading t_dhw_setdhw_setpoint_rw
for writing t_dhw_setmax_ch_setpoint_transfer_enabled
for reading max_t_setmax_ch_setpoint_rw
for writing max_t_setIf one of the messages is being sent that has a support indicator, we should query support at startup and automatically disable all unsupported messages. This information should probably be included in the schema, either in the binary sensors as an
indicates_support_for
or in the entity's with somesupport_indicated_by
with a format similar to auto_min/max_value.Clear logging is required, so useful to do this on startup as users are more likely to see the logs at that point.
The text was updated successfully, but these errors were encountered: