Gatewayify

[wanno-drijfhout]

• Add "gateway" operation mode for existing thermostat
• Introduce "actual temperature" sensor (pin on OpenTherm adapter)
• Fix spaces, names and typos
• Improve ESPHome configuration (icons!)
• Replace -1 values by NaN
• Fix deprecated:

  In file included from src/main.cpp:40:0:
  src/opentherm_climate.h: In member function 'virtual esphome::climate::ClimateTraits OpenthermClimate::traits()':
  src/opentherm_climate.h:47:49: warning: 'void esphome::climate::ClimateTraits::set_supports_heat_cool_mode(bool)' is deprecated (declared at src/esphome/components/climate/climate_traits.h:60): This method is deprecated, use set_supported_modes() instead [-Wdeprecated-declarations]
           traits.set_supports_heat_cool_mode(false);
                                                   ^
  src/opentherm_climate.h:48:44: warning: 'void esphome::climate::ClimateTraits::set_supports_cool_mode(bool)' is deprecated (declared at src/esphome/components/climate/climate_traits.h:56): This method is deprecated, use set_supported_modes() instead [-Wdeprecated-declarations]
           traits.set_supports_cool_mode(false);
                                              ^
  src/opentherm_climate.h:49:43: warning: 'void esphome::climate::ClimateTraits::set_supports_heat_mode(bool)' is deprecated (declared at src/esphome/components/climate/climate_traits.h:58): This method is deprecated, use set_supported_modes() instead [-Wdeprecated-declarations]
           traits.set_supports_heat_mode(true);
                                             ^
  src/opentherm_climate.h:51:39: warning: 'void esphome::climate::ClimateTraits::set_supports_away(bool)' is deprecated (declared at src/esphome/components/climate/climate_traits.h:119): This method is deprecated, use set_supported_presets() instead [-Wdeprecated-declarations]
           traits.set_supports_away(false);
                                         ^
  

[wanno-drijfhout]

Note to self: somewhere between a000f01 and 903cb65, I introduced a regression that seems to cause the boiler to restart the flame constantly. Probably something to do with the half-finished migration of OpenTherm connection. To be continued...

[wanno-drijfhout]

I'm having a hard time focusing and combining forked code, new inspirations from https://github.com/wichers/esphome-opentherm, my own code, experimental code, half-done refactorings etc.

Here's the difficulties:

• My physical thermostat (Honeywell Modulating Thermostat) already does a lot of back-and-forth traffic.
  • It seems pointless (and possibly counterproductive) to poll for information that the physical thermostat already provides. Instead, we could piggyback on existing requests/responses and poll only if we really need information.
  • There's actual traffic with my physical thermostat that the OpenTherm library deems "invalid"!
• The OpenTherm library we use has some limitations w.r.t. hooks and callback; https://github.com/wichers/esphome-opentherm seems to have copied and changed the library for better C++ handling.
• Modulation is a big black box for me. I cannot determine how to integrate the PID algorithm conceptually with the gateway and external thermostats (which may already modulate). It requires experimentation, but it's a decision that strongly affects the architecture of the system, which makes it hard to keep focus on developing stuff. OpenTherm defines a RelModLevel attribute; is that the same as the PidOutput of the forked code?
• I don't yet know for sure if communication is always request by thermostat and response by boiler. (I.e., is it true that the boiler cannot send "requests"?)
• There's a lot of "interconnected concepts" and I found their separation and relation hard to design. Through various refactorings, I seem to more-or-less end up with the following conceptual demarcation:
  • Boiler is the physical device with the flame. It provides Central Heating and Domestic Hot Water (terminology from OpenTherm standard)
  • Room should be the climate the human sets
  • Hot water could also be a climate the human sets (for pre-heating warm water, I suppose?)
  • PID controller should be an internal component at best and not a climate set directly by a human

Here's the things I did learn that could improve the original code:

• Rather than -1, we should use NaN -- it causes states to show up in Home Assistant as "Unknown" (rather than "-1 %", for example).
• The modulation logic of forked code
• Solving the "deprecation warnings" is easy: 0bbc5c2
• There's a Dallas temperature sensor on the adapter that can be easily enabled (fe58560). I suppose it could be used as a room temperature sensor in some cases, but I reckon the hardware is often physically too close to the boiler for that to be effective. Still, the sensor might be useful in the future to measure "Return water" temperature somehow?
• I don't understand the two-point target temperature for the PID controller, which modulates between a low set-point and high set-point. I would think modulation occurs between current Room temperature and target temperature, rather than two target temperatures. Some user-documentation would be useful.

Here are things I'd like to investigate in the future:

• It should be easy to reorganize the GitHub repo a bit so that the whole OpenTherm integration can be included as external component without having to copy files manually to a certain folder. It also makes it easier to automatically provide updates for people, I reckon.
• Home Assistant's "Climate" component supports modes and presets; I'm interested in exploiting those
• There is "Remote Set-Point Override" functionality in the OpenTherm protocol. It seems relevant in the whole business of integrating and automating thermostats using a gateway, but I'm not sure how. A lot of conceptual questions to resolve about the role of a physical thermostat, the gateway and virtual thermostats.
• It seems possible for the gateway to also provide extra sensors to the boiler via OpenTherm (e.g., Room temperature, Outside temperature, Return water temperature, date/time). It'd be very interesting to import live (weather/clock) information from Home Assistant back into the Boiler, no?

I'm strongly considering starting the project from scratch in the near future, so that I can retain focus and scope. I'm a bit busy now, but I expect there'll be some free evening/weekend in the near future again. It's been fun experimenting so far already!

[AndreyShpilevoy]

Hi @wanno-drijfhout, I would like to ask:
Is it possible with the current version of the application to connect the ESPHome-OpenTherm gateway with limited functionality?

I am interested in very basic functions:

• read boiler status
• change boiler heater target temperature from HA
• send room temperature from HA server
• keep current thermostat fully functional

[wanno-drijfhout]

Hi @AndreyShpilevoy ,

Hi @wanno-drijfhout, I would like to ask: Is it possible with the current version of the application to connect the ESPHome-OpenTherm gateway with limited functionality?

Sort of. I have the gateway installed (with this software branch); it mostly just forwards all the communications from the physical thermostat to the boiler and back.

Note: when you upload the software to your gateway device, the boiler will probably enable at maximum temperature. So, you may want to (1) disable the Central Heating Unit, (2) upload the software, (3) enable the Central Heating Unit again. If the Central Heating stays idle, the software is probably uploaded correctly.

I am interested in very basic functions:

• read boiler status

Yes. Certain flags (like "flame") are bugged: I should only update those values for Message-ID/Data-ID 0 ("Status" responses). The code currently determines those values from any response I get, which is plain wrong. I needed to refactoring the whole "message handling", which made things so complex to oversee I want to start again.

• change boiler heater target temperature from HA

Nope. It's easy to send a "boiler temperature setpoint", but you don't want that. You want to set a "room temperature setpoint". Setting a "room temperature setpoint" directly is possible and easy with a single command. However, I don't know how to integrate "modulation" or the "room temperature override setpoint" functionality yet. With current gas prices I don't want to experiment too much.

• send room temperature from HA server

Nope. If you have a physical thermostat, it may already have a built-in sensor. I do know it's desirable to send our own sensor values to the boiler (e.g., room temperature, outside temperature, date-time, ...) but that's not possible yet.

• keep current thermostat fully functional

Yes. Keeping the physical thermostat working was my prime concern.

[ananyevgv]

Hi wanno-drijfhout, I found another interesting project
https://modkam.ru/2017/12/14/shljuz-opentherm/
https://modkam.ru/2018/09/13/shljuz-opentherm-versija-2/