search

olegtarasov / esphome-opentherm

Create your own smart modulating thermostat using the OpenTherm component for ESPHome
BSD 2-Clause "Simplified" License
37 stars 6 forks source link

[WARNING] Receive response timed out at a protocol level #13

Open clau-bucur opened 1 month ago

clau-bucur commented 1 month ago

Hi, and thanks for this component! I've just started using it with a thehognl OpenTherm shield + Wemos D1 Mini32 board (ESP32) + Viessmann Vitodens 100-W boiler.

When ESP starts things work alright and device responds to commands but after a while not sure what happens but I see the following warning in the logs: [W][opentherm:339]: Receive response timed out at a protocol level.

It appears every second and when that starts to happen my boiler starts heating all by itself. Visible here: image

The warnings stop after a while and boiler starts to work correctly. But only temporary.

I've attached the ESPHome logs, maybe you can see anything there suspicious? logs_opentherm_logs.zip

My config:

external_components:
  source: github://olegtarasov/esphome-opentherm@main

opentherm:
  in_pin: GPIO19
  out_pin: GPIO18

output:
  - platform: opentherm
    t_set:
      id: ch_setpoint
      min_value: 40
      max_value: 60
      zero_means_zero: true

# Values that can be set maually from HA interface
number:
  - platform: opentherm
    t_dhw_set:
      id: dhw_setpoint
      name: "Hot water target temperature"
      min_value: 10
      max_value: 60
      initial_value: 45
      restore_value: true

switch:
  - platform: opentherm

    ch_enable:
      id: ch_enable
      name: "Central Heating enabled"
      restore_mode: RESTORE_DEFAULT_OFF
    dhw_enable:
      id: dhw_enable
      name: "Hot Water enabled"
      restore_mode: RESTORE_DEFAULT_OFF

climate:
  - platform: pid
    name: "Central heating"
    heat_output: ch_setpoint
    default_target_temperature: 22
    sensor: ch_room_temperature
    visual:
      min_temperature: 15
      max_temperature: 30
      temperature_step:
        target_temperature: 0.5
        current_temperature: 0.1
    control_parameters:
      kp: 0.4
      ki: 0.004

sensor:
  - platform: opentherm
    rel_mod_level:
      name: "Relative modulation level"
    ch_pressure:
      name: "Water pressure"
    t_boiler:
      name: "Heating water temperature"
    t_dhw:
      name: "Hot water temperature"
    t_exhaust:
      name: "Exhaust temperature"
    t_ret:
      name: "Return water temperature"

  - platform: homeassistant
    id: ch_room_temperature
    entity_id: sensor.heating_opentherm_feed_temperature
    filters:
      # Push room temperature every second to update PID parameters
      - heartbeat: 1s

binary_sensor:
  - platform: opentherm
    ch_active:
      name: "Central Heating active"
    dhw_active:
      name: "Hot Water active"
    flame_on:
      name: "Flame on"
    fault_indication:
      name: "Fault indication"
      entity_category: diagnostic
    diagnostic_indication:
      name: "Diagnostic event"
      entity_category: diagnostic
clau-bucur commented 1 month ago

BTW, I used for a some hours an ESP8266 Wemos D1 Mini and this problem appeared too. So I thought I'll switch to an ESP32 as per your other suggestions. But the issue seems to persist.

olegtarasov commented 4 weeks ago

Hi @clau-bucur! Please try setting sync_mode: true in opentherm section.

clau-bucur commented 4 weeks ago

I remember I tried for the ESP8266 and it did not fix the issue, but I'll set it the same for the current ESP32 board and see if it works.

FreeBear-nc commented 4 weeks ago

Another Viessmann user here (an 050 combi). You might find that the boiler is automatically firing up to keep the system hot for when you want hot water (DHW). One of two ways to disable this:

clau-bucur commented 3 weeks ago

@FreeBear-nc thanks for the input! I'm using the boiler DHW only as a backup because I have solar panels which heat up my DHW so I have dhw_enable switch set exactly as your second suggestion.

What behaviour I find strange about my boiler is this: If the OpenTherm master is powered off or disconnected the boiler starts heating! Do you experience the same behaviour? Can we disable it somehow?

I find it very annoying and does not make sense to me. If my OT master somehow breaks or loses power the boiler just starts heating like crazy? What kind of silly fallback behavriour is this?

dmd79 commented 3 weeks ago

@FreeBear-nc thanks for the input! I'm using the boiler DHW only as a backup because I have solar panels which heat up my DHW so I have dhw_enable switch set exactly as your second suggestion.

What behaviour I find strange about my boiler is this: If the OpenTherm master is powered off or disconnected the boiler starts heating! Do you experience the same behaviour? Can we disable it somehow?

I find it very annoying and does not make sense to me. If my OT master somehow breaks or loses power the boiler just starts heating like crazy? What kind of silly fallback behavriour is this?

Hi, I have the same behaviour on my Daikin D2C, but I think you can check the electric schematic, maybe there's some configurable wiring to enable or disable this thing

FreeBear-nc commented 3 weeks ago

What behaviour I find strange about my boiler is this: If the OpenTherm master is powered off or disconnected the boiler starts heating! Do you experience the same behaviour? Can we disable it somehow?

With the 050, when the OT master goes offline, it has no affect on my boiler. When it comes back online, the boiler goes through a startup & purge cycle for a minute or so. But this doesn't help you... Looking at the most recent installation manual for the 100, I one possible answer - From the control panel on the front of the boiler, select the three vertical squiggly lines (heating circuit 1), press the down arrow until "OFF" appears, and then press OK. Do the same for heating circuit No.2. You could also try accessing menu option P1 and setting HC1 & HC2 to n1. The manual gives further information: https://viessmanndirect.co.uk/files//92bc109d-eb87-4231-9a05-adec818a1b7d/6167584VBA00008_1.pdf

There are a few other settings that can be changed only if you have the ViCare app. The installation manual documents some of them. I've not used the ViCare app, so can't comment on what it does.

clau-bucur commented 3 weeks ago

When my boiler is set in OpenTherm mode none of these options are available, it won't allow changing the heating circuit or DHW temperature values, by any means:

This makes sense because OpenTherm is in control. But that fallback behavior does not.

olegtarasov commented 3 weeks ago

@clau-bucur Do you have another thermostat that was connected to your boiler before the OpenTherm bridge? If so, we may have some luck in sniffing its messages in the future (my component doesn't have this feature yet). Other than that, I can't really figure out why protocol errors are happening for you :( It would make sense if things didn't work completely, but I see in your logs that sometimes your boiler sends valid responses. I'm really out of ideas on how to diagnose this except for trying to sniff traffic from the "official" thermostat.

As for the fallback behavior — I think it's normal with some boilers, I have the same behavior with my boiler. I didn't look into it much, but I thing the boiler just tries to heat the water to a setpoint that is specified in its own settings. Maybe you can view and change these settings while any kind of OpenTherm thermostat is disconnected.

olegtarasov commented 3 weeks ago

@clau-bucur By the way, you can also try to flash this sketch and see whether it works better: https://github.com/diyless/esp32-wifi-thermostat. It uses a different protocol library, so if it works better, we will know that there is a problem in protocol handling.

clau-bucur commented 3 weeks ago

@clau-bucur Do you have another thermostat that was connected to your boiler before the OpenTherm bridge?

No other thermostat, I was using it previously in On/Off mode.

As for the fallback behavior — I think it's normal with some boilers, I have the same behavior with my boiler. I didn't look into it much, but I thing the boiler just tries to heat the water to a setpoint that is specified in its own settings. Maybe you can view and change these settings while any kind of OpenTherm thermostat is disconnected.

Nothing is possible to be changed as long as the boiler is in OpenTherm control mode. Nevermind, I'm implementing some failsafe checks and will switch off the boiler if it's heating when it's not supposed to.

@clau-bucur By the way, you can also try to flash this sketch and see whether it works better: https://github.com/diyless/esp32-wifi-thermostat. It uses a different protocol library, so if it works better, we will know that there is a problem in protocol handling.

So, I've stared for some days to use https://github.com/Alexwijn/SAT integration with your component. There they have a predefined ESPHome configuration that one's supposed to have in order for SAT to properly control your component. Since I've started using that configuration I have had 0 issues and no protocol timeouts. I've waited a few days until I could confirm that this is the case. I have even removed sync_mode: true and it works. I am really not sure what is the reason, but here is the current config that works:

esphome:
  name: opentherm
  friendly_name: OpenTherm

esp32:
  board: wemos_d1_mini32

# Enable logging
logger:
  level: INFO

ota:
  - platform: esphome

external_components:
  source: github://olegtarasov/esphome-opentherm@main
  refresh: 0s

opentherm:
  in_pin: GPIO19
  out_pin: GPIO18
  # sync_mode: true
  ch_enable: true
  dhw_enable: true

number:
  - platform: opentherm
    t_dhw_set:
      name: "dhw_setpoint_temperature"
      min_value: 10.0
      max_value: 60.0
      step: 1
      initial_value: 45.0
      restore_value: true
    t_set:
      name: "ch_setpoint_temperature"
      min_value: 0.0
      max_value: 80.0
      step: 0.1
      initial_value: 0.0
      restore_value: true
    max_t_set:
      name: "max_ch_setpoint_temperature"
      min_value: 20.0
      max_value: 80.0
      initial_value: 80.0
      step: 1
      restore_value: true
    max_rel_mod_level:
      name: "max_modulation_level"
      entity_category: config
      min_value: 0
      max_value: 100
      step: 1
      initial_value: 100
      restore_value: true

sensor:
  - platform: opentherm
    rel_mod_level:
      name: "modulation"
    device_id:
      name: "boiler_member_id"
    t_boiler:
      name: "boiler_temperature"
    t_ret:
      name: "return_temperature"
    t_dhw_set_lb:
      name: "dhw_min_temperature"
    t_dhw_set_ub:
      name: "dhw_max_temperature"
    t_dhw:
      name: "Hot Water Temperature"
    ch_pressure:
      name: "Heating Water Pressure"
      unit_of_measurement: hPa
    t_exhaust:
      name: "Exhaust temperature"
    max_capacity:
      name: "max_capacity"
    min_mod_level:
      name: "min_mod_level"

binary_sensor:
  - platform: opentherm
    flame_on:
      name: "flame_active"
    ch_active:
      name: "Central Heating active"
    dhw_active:
      name: "Hot Water active"
    fault_indication:
      name: "Boiler Fault indication"
      entity_category: diagnostic
    diagnostic_indication:
      name: "Boiler Diagnostic event"
      entity_category: diagnostic

switch:
  - platform: opentherm
    dhw_enable:
      name: "dhw_enabled"
      restore_mode: RESTORE_DEFAULT_OFF
      entity_category: config
    ch_enable:
      name: "ch_enabled"
      restore_mode: RESTORE_DEFAULT_OFF
      entity_category: config
olegtarasov commented 3 weeks ago

@clau-bucur That's unusual :) Can you please post full configs for both cases (excluding passwords of course)?

clau-bucur commented 3 weeks ago

@olegtarasov what you see are the full configs, I don't have anything else configured on the ESPHome device. And I've not made any hardware changes at all since the first post and the last.

olegtarasov commented 3 weeks ago

@clau-bucur Did you have the same board specified before? I don't see the board section in your first config. If board is the same, can you add the following section to your first config and see if it works better?

sensor
  - platform: opentherm
    device_id:
      name: "boiler_member_id"
clau-bucur commented 3 weeks ago

Yeah, sorry, I see now my first post was missing non OT-related config. But it was indeed the same as my last config. I'll add that sensor to my first config and report back.

ties-s commented 2 weeks ago

I have this same issue.

This set of logs keeps looping:

[15:24:36][D][opentherm:317]: Sending request with id 0 (STATUS) [15:24:36][D][opentherm:318]: 00000000 00000000 00000010 00000000 type: READ_DATA; id: 0; HB: 2; LB: 0; uint_16: 512; float: 2.000000 [15:24:37][W][opentherm:357]: Receive response timed out at a protocol level

config:

external_components:
  source: github://olegtarasov/esphome-opentherm

opentherm:
  in_pin: 13
  out_pin: 14

(i have tried switching pin numbers, as well as defining them as GPIOXX)

adapter: https://ihormelnyk.com/opentherm_adapter (measured 3.3V on power inputs, 32VDC on open therm bus) board: ESP32-S3

FreeBear-nc commented 2 weeks ago

@clau-bucur By the way, you can also try to flash this sketch and see whether it works better: https://github.com/diyless/esp32-wifi-thermostat. It uses a different protocol library, so if it works better, we will know that there is a problem in protocol handling.

I've updated my fork of Arthur Rump's external OpenTherm component - This uses the Ihor Melnyk's OT library. Tried to keep the sensor names the same so that minimal changes are needed to the yaml. Just the following lines need to be added:

esphome:
  platformio_options:
    lib_deps:
    - https://github.com/freebear-nc/opentherm_library.git

external_components:
  - source:
      type: git
      url: https://github.com/FreeBear-nc/esphome-opentherm.git
      ref: main
    components: [ opentherm ]
    refresh: 0s
olegtarasov commented 2 weeks ago

@ties-s Can you post full debug log collected over wired connection to esp (so that no messages are missed while establishing wireless connection)? Also please post you entire config (excluding secrets).

clau-bucur commented 1 week ago

@clau-bucur Did you have the same board specified before? I don't see the board section in your first config. If board is the same, can you add the following section to your first config and see if it works better?

sensor
  - platform: opentherm
    device_id:
      name: "boiler_member_id"

After I added this, the connection is stable. I did not experience any timeouts for half a day so we can consider that this fixed it. I wonder why...? Here's the full config I've used:

esphome:
  name: opentherm
  friendly_name: OpenTherm

esp32:
  board: wemos_d1_mini32

# Enable logging
logger:
  level: INFO

ota:
  - platform: esphome

external_components:
  source: github://olegtarasov/esphome-opentherm@main

opentherm:
  in_pin: GPIO19
  out_pin: GPIO18

output:
  - platform: opentherm
    t_set:
      id: ch_setpoint
      min_value: 40
      max_value: 60
      zero_means_zero: true

# Values that can be set maually from HA interface
number:
  - platform: opentherm
    t_dhw_set:
      id: dhw_setpoint
      name: "Hot water target temperature"
      min_value: 10
      max_value: 60
      initial_value: 45
      restore_value: true

switch:
  - platform: opentherm
    ch_enable:
      id: ch_enable
      name: "Central Heating enabled"
      restore_mode: RESTORE_DEFAULT_OFF
    dhw_enable:
      id: dhw_enable
      name: "Hot Water enabled"
      restore_mode: RESTORE_DEFAULT_OFF

sensor:
  - platform: opentherm
    rel_mod_level:
      name: "Relative modulation level"
    ch_pressure:
      name: "Water pressure"
    # dhw_flow_rate:
    #   name: "Hot water flow rate"
    t_boiler:
      name: "Heating water temperature"
    t_dhw:
      name: "Hot water temperature"
    t_exhaust:
      name: "Exhaust temperature"
    t_ret:
      name: "Return water temperature"
    device_id:
      name: "boiler_member_id"
    burner_starts:
      name: "Burner starts"
    ch_pump_starts:
      name: "Heating pump starts"
    dhw_pump_valve_starts:
      name: "Hot water pump valve starts"
    dhw_burner_starts:
      name: "Hot water burner starts"
    burner_operation_hours:
      name: "Burner operation hours"
    ch_pump_operation_hours:
      name: "Heating pump operation hours"
    dhw_pump_valve_operation_hours:
      name: "Hot water pump valve operation hours"
    dhw_burner_operation_hours:
      name: "Hot water burner operation hours"
    t_dhw_set_ub:
      name: "Upper bound for adjustment of DHW setpoint"
    t_dhw_set_lb:
      name: "Lower bound for adjustment of DHW setpoint"
    max_t_set_ub:
      name: "Upper bound for adjustment of max CH setpoint"
    max_t_set_lb:
      name: "Lower bound for adjustment of max CH setpoint"
    max_t_set:
      name: "Maximum allowable CH water setpoint"

binary_sensor:
  - platform: opentherm
    ch_active:
      name: "Central Heating active"
    dhw_active:
      name: "Hot Water active"
    flame_on:
      name: "Flame on"
    fault_indication:
      name: "Fault indication"
      entity_category: diagnostic
    diagnostic_indication:
      name: "Diagnostic event"
      entity_category: diagnostic
olegtarasov commented 1 week ago

@clau-bucur Thank you! I guess, your boiler expects some sort of standard OpenTherm song-and-dance which is not clearly described in v2.2 spec. Requesting device_id is clearly part of this startup sequence. I've seen some code somewhere that contains a version of this message sequence, and I will try to implement it in develop so you could test it out.

FreeBear-nc commented 1 week ago

What behaviour I find strange about my boiler is this: If the OpenTherm master is powered off or disconnected the boiler starts heating! Do you experience the same behaviour? Can we disable it somehow?

Was having a read of the OpenTherm V2.2 specification.

3.5 Special Installation Short-Circuit Feature

The boiler unit must support an important installation feature which allows the terminals at the boiler to be short-circuited to simulate a heat demand such as can be done with existing on/off boilers. The boiler unit should interpret the short-circuit as a heat demand within15 secs of the short-circuit being applied. This must be supported by both OT/+ and OT/- boilers. It is allowable that this can implemented by a software-detection method. The software short-circuit condition is defined as a low-voltage state (V low ) with no valid communications frame for at least 5 seconds.

So being baked in to the specification, I don't think this behaviour can be disabled.

clau-bucur commented 1 week ago

I saw too this requirement, but I interpreted the "short-circuit condition" as the + and - wires being tied (bridged) together so I thought "this can't be the same case as when the communication with the master is not present".

software short-circuit condition is defined as a low-voltage state (V low ) with no valid communications frame for at least 5 seconds.

Though this might mean exactly that... ? Absence of the master is considered as a "low-voltage state" ?

olegtarasov commented 1 week ago

@clau-bucur I'm not en expert in analog schematics (which I consider OpenTherm bridge to be :) ), but since OpenTherm protocol initialization includes bringing one of the pins up, I can surmise that the default state of both terminals is down, so boilers interpret it as a short-circuit. Seems like not much we can do here as @FreeBear-nc pointed out.

clau-bucur commented 1 week ago

@olegtarasov & @FreeBear-nc thanks for all the assistance and info! This issue can be closed as far as I'm concerned.