New integration with Climate component of Home assistant about feature-requests

[OttoWinter]

@puuu First off, thanks for writing this up! I have some notes on the proposal:

As you said, there are several kinds of climate devices this would need to support. The "dumb" ones that just relay commands via IR/etc and the ones where the logic is on the ESP itself (bang bang controller for example). We don't need to support both from the start, but the architecture should be made in a way that will support both.

Re current temperature: I don't think the climate device should use a Sensor object internally. It should just be a float attribute. I've tried this inter-component arch stuff before (with switch), but that didn't work too well and was removed.

I also think we should bring in the notion of "traits" for climate devices. The implementation can tell the abstraction what stuff the climate device supports. This helps clean up the logic (examples are in light and fan). Traits describe what a climate device supports and can do.

Re modes:

• Personally I'd hold off with adding all modes, so for example dry and fan_only we should only add if we add support for an integration that has those modes.
• climate.template.publish should have multiple properties, one of which is mode (no state option)
• climate.auto etc actions. I'd prefer if all actions were merged into a single action, like climate.control which has properties starting from target_temperature to mode. This ensures atomic writes (if multiple properties are changed at once) and I find it cleaner (for example I like light.turn_on - except maybe the effects property in there).

Re target temperature:
These config options should be merged into a target_temperature key, that makes clear all of these options affect the temperature display. (an option called min_temp is not very descriptive). Either that or we split up the docs into multiple sections, like Mode Options, Advanced Options, MQTT Options, Visual Options (the last one containing min/max_value)

Re config options: Personally I hate HA's way of creating massive unstructured configs with tons of different options at the top platform level, I think we can structure the whole config more by using nested keys or with the documentation section split as described above.

For the future (but not necessary yet): We will support target_temperature_min and target_temperature_max too (for bang bang controllers).

Re MQTT topic options: I don't see a particular reason why we need to add config options for all topics yet - we can still add them later and this keeps the config cleaner.

Re Fan: Unless an integration needs this yet, I'd say we leave it out for now.

Re public API:

• publish_state - "state" means the entire state of the climate device. I think we can do things differently with this integration: Each climate device writes directly to the properties of the class and at the end calls publish_state() (with no params) to make the climate device publish its state.
• Other methods: I like the way it is done with lights better, and I think it would fit well here. auto call = id(climate).make_call(); call.set_mode(THE_MODE); call.set_target_temperature(42.0); call.perform();

// pseudo-code!
struct ClimateDeviceTraits {
 public:
  bool supports_auto_mode;
  bool supports_cool_mode;
  bool supports_heat_mode;
};

enum ClimateDeviceMode {
  // disable all operations - all devices must support this
  CLIMATE_MODE_OFF,
  // climate logic decides itself
  CLIMATE_MODE_AUTO,
  // Manually set to cool - at least one of cool/heat is required to be supported
  CLIMATE_MODE_COOL,
  // Manually set to heat
  CLIMATE_MODE_HEAT,
  // CLIMATE_DRY, - unless something needs these, I say we don't add them yet.
  // CLIMATE_FAN_ONLY
};

class ClimateDeviceCall {
 public:
  void set_target_temperature(float target_temperature);
  void set_mode(ClimateDeviceMode mode);
  void perform();
 protected:
  optional<float> target_temperature_;
  optional<ClimateDeviceMode> mode_;
};

class ClimateDevice : public Nameable {
  public:
    // attributes of the climate device, encodes entire state of the device.
    // read-only for users; integrations write directly to this.
    float current_temperature;
    float target_temperature;
    ClimateDeviceMode mode;

    ClimateDeviceCall make_call();

    // subclasses override these
    virtual ClimateDeviceTraits get_traits() = 0;
    virtual void perform_call_(ClimateDeviceCall call) = 0;
};

IMHO, additionally we should provide a controller components, too. Here a simple two-point controller is implemented as script. Another controller would be a PID controller.

Yes, definitely. I'm already doing this with custom components on the HA side, but having it directly on the ESP with simple config would be awesome.

Ok, so I think the way forward will be:

• Some more architectural discussion, though the proposal you said is already almost ready.
• Implement the component base (affected files: climate/climate.h/cpp, application.h/cpp, controller.h/cpp)
• Add a template climate platform - most of this is boilerplate and can be copied from other template platforms
• Add a MQTT climate class, Also mostly boilerplate, the fan example is closest to this one.

Then I think it is ready for now. If you want, I can take care of the native API side of things then (that part is not too well documented).

Future work:

• Adding more platforms for bang-bang/PID controllers
• Adding more operation modes/properties as needed.

[puuu]

I made a pull request with my suggested climate device implementation for esphome-core: esphome/esphome-core#569

There is not yet any python part and it implements only a template and a thermostat platform.

[rarroyo6]

I have a thermostat I made several years ago using a 4D Systems display. Recently the display started giving problems, so I decided to build a new one using ESP and a Nextion display, and interfacing it with HA, which I recently started using. I have a prototype already set up and working using the Venstar climate component which has a published API (here).
Then I ran into this post, and I'm very interested in testing or helping out in any way I can.
For what it's worth, here's my two cents.

• This node should have the option of being self contained, and not depend on HA for any of it's operations, so if HA or the network goes down, it can still function as a thermostat, and keep the room comfortable.

• It should be able to directly read the temperature with an attached sensor, and drive control relays with the GPIO pins or IR signals.

• It should have some basic logic built in so that the "heat" and "cool" pins are not switches on at the same time, and the "fan" pin is turned ON whenever the heat or cool is turned on.

I've already installed the ESPhome (dev) and would like to start playing with it. Any information on what has been done, or what "platforms" are being worked on, or where can I look for this information is appreciated.

Thanks to everybody who has worked on ESPHome.

[erazor666]

I'm researching adding some brains to my Mitsubishi heatpump also. It is very possible to add an esp8266 directly to a header inside the heatpump and control it directly. I've read some about the IR commands it sends and its not always straight forward, it doesn't always send a single command. It will send the all the settings on the remote in a command, so from what i read it can be kinda unreliable to command it via some other IR sender (not impossible by any means).

You also face the same issue as with 433mhz operated lightswitches/relays etc. There's is no sure way to know your command was accepted or executed. Also there is no feedback so you cant really see if the result in HA.

For what its worth here is some of the pages i've come across from doing some research on this:
(https://community.home-assistant.io/t/mitsubishi-air-conditioner-remote-control/20753)
(posts 7 & 14 of special interest)
(https://nicegear.nz/obj/blog/heat-pump-hacking-4.jpg)
(here is a picture of where you need to 'attack', the mod on the heatpump isn't really bad (subjective). You need to connect to a pin header. It supplies power so all you need is to lower the voltage to power the esp module)
(https://nicegear.nz/blog/hacking-a-mitsubishi-heat-pump-air-conditioner/)

This mod as far as i understand it will function pretty much as the manufacturer's wifi module you can purchase. I personally like to make things and found it too costly. (and potentially not able to work with HA still). Haven't concluded fully on this topic yet so consider it my 2cents

[glmnet]

I'd like to work on this. Can somebody give more information of how this would work? I am new to both Home Assistant and ESPHome, I'm liking it a lot.
I guess I could make that configuration to work. I have some experience with AC remotes already and Arduino, not much python yet.

[OttoWinter]

@glmnet See #87. ESPHome mostly follows HA's model for entities, however the climate entity model in HA is quite broken IMO. There are tons of properties that are inproperly documented as to what they represent/do and things were just added with no thought about the architecture.

ESPHome would need to support a subset of HA's climate entity features, leaving out all the bloat.

So the steps would be:

1. Discuss the architecture of the climate component. Data properties (for example target_temperature), service calls (for example climate.set_target_temperature) - and document clearly what these do/represent.

2. Implement the abstraction in esphome-core (like other base classes switch/light etc).

3. Implement connection layer on core side - MQTT and native API

4. Add a template platform so that the base class can be used (like cover.template)

5. Implement python code gen side in esphome.

6. Update aioesphomeapi +HA + esphome-docs for changes.

It's a lot of work, and definitely not something that you should attempt when getting started with these projects. That's also why I have not tried to do this yet.

[glmnet]

I'm sorry to hear that about the climate component in home assistant.
A long term goal should be that they work seamlessly, I see your recommendation on going with "custom" switches / sensors, I'm going to try to add a climate component anyway, will work with mqtt only and see what happens. (Native api is awesome but yet more work)
I hope I could do a push and may be you can take a look later.

[erazor666]

@glmnet
IR components in their nature don't give any kind of feedback or state control, and there lies much of the problem. Of course its easier to make a general component that can control many brands and types of units, you just grab the IR codes and substitute. You wouldn't be able to get accurate info in Home Assistant on what the actual settings/states are with it being IR and its "fire and forget" nature. So it ends up being a one way system of sorts.

[glmnet]

@erazor666 exactly as you say. It’s called “optimistic” in ha ecosystem. If it is reliable then for sure it will be useful for many cases. At least for me, I have 5 ac systems I’d like to remotely/automatically control and this seems a good approach. It doesn’t mean it’s the only one. More “smart” ac are becoming available and I’m pretty sure it will be all WiFi in the end with no IR in the middle and that will make future easy.

[puuu]

Yes, a climate component is really missing in ESPHome.

There are a lot of possibilities you can implement with this:

• control your air con via IR (probably only optimistic mode)
• implement a thermostat heater with a relay and a temperature sensor
• implement a controlled cooler/heater with a peltier cooler/heater and an temperature sensor

@OttoWinter Let's concentrate on the climate.mqtt component of HA. Yes, it has tons of properties that are inproperly documented, but let it break down into some smaller topics. If you would hold a remote control of an air con in your hand, you probably find all these parameters.

Here is the Thermostat Card of HA:

The provided parameter examples are for a possible climate template component implementation. Everything is open for discussion.

Parameter

Current temperature

May be not on the remote control but required for controlling purposes. The current temperature is shown in the middle of the Thermostat Card. We can provide a configuration parameter sensor_id. The climate component can then register to its on_value actions.

Configuration variables:

• sensor_id (Optional, ID): The ID of the temperature sensor.

MQTT Options:

• current_temperature_topic (Optional, string): The topic to publish current temperature updates to. Defaults to <TOPIC_PREFIX>/climate/<COMPONENT_NAME>/current_temperature/state.

Modes

These are the small icons on the bottom of the Thermostat Card. Possible modes can be controlled by the modes configuration.

As usual, for all ESPHome template components, we should provide a lambda parameter to optionally calculate the current mode and actions that should be performed on mode changes.

Modes are:

• auto automatic mode of the air con or idle mode for a thermostat
• off power off the air con or thermostat
• cool cooling mode (air con) or active cooling (cooler)
• heat heating mode (air con) or active heating (heater)
• dry dry mode
• fan_only fan only mode

Configuration variables:

• <MODE>_action (Optional, Action): The action that should be performed when the remote (like Home Assistant’s frontend) requests a new mode.
• mode_lambda (Optional, lambda): Lambda to be evaluated repeatedly to get the current mode.

MQTT Options:

• modes (Required, list): A list of supported modes.
• mode_command_topic (Optional, string): The topic to subscribe to for mode commands from the remote. Defaults to <TOPIC_PREFIX>/climate/<COMPONENT_NAME>/mode/command
• mode_state_topic (Optional, string): The topic to publish current mode updates to. Defaults to <TOPIC_PREFIX>/climate/<COMPONENT_NAME>/mode/state

Actions:

• climate.template.publish (with parameter id and state): set mode
• climate.auto: set auto mode
• climate.turn_off: switch off
• climate.cool: set cool mode
• climate.heat: set heat mode
• climate.dry: set dry mode
• climate.fan_only: set fan only mode

Target temperature

The requested target temperature. The one that is controlled by the slider in the Thermostat Card.

Configuration variables:

• target_temperature_action (Optional, Action): The action that should be performed when the
  remote (like Home Assistant’s frontend) requests a new target temperature.
• target_temperature_lambda (Optional, lambda): Lambda to be evaluated repeatedly to get the new target temperature.
• initial (Optional, float): Set the initial target temperature. Defaults 21.
• min_temp (Optional, float): Minimum target temperature available. Defaults to 10.
• max_temp (Optional, float): Maximum target temperature available. Defaults to 30.
• temp_step (Optional, float): Step size for target temperature. Defaults to 1.

MQTT Options:

• temperature_state_topic (Optional, string): The topic to subscribe to for target temperature commands from the remote. Defaults to <TOPIC_PREFIX>/climate/<COMPONENT_NAME>/temperature/state
• temperature_command_topic (Optional, string): The topic to publish current target temperature updates to. Defaults to <TOPIC_PREFIX>/climate/<COMPONENT_NAME>/temperature/command

Actions:

• climate.set_target_temperature (with parameter id and temperature): set target temperature.

Fan

Similar to the fan component. fan_modes for ON/OFF or speed (low, medium, high) and swing_modes for oscillation.

Power

I do not recommend to use it. Power state can be controlled via mode. If you use the power configuration of HA, you will end up in two messages, on to power_command_topic and one to mode_command_topic.

Other options

There are other modes with topics that may can be implemented later on request: away_mode, hold mode, auxiliary heat.

Configuration variables:

• optimistic (Optional, boolean): Whether to operate in optimistic mode - when in this mode, any command sent to the template will immediately update the reported state. Defaults to false.
• name (Required, string): The name of the climate component.
• update_interval (Optional, Time): The interval to call the lambda functions. Defaults to 60s.
• id (Optional, ID): Manually specify the ID used for code generation.

public API

• enum climate::ClimateMode {MODE_HEAT, MODE_OFF, MODE_COOL, MODE_HEAT, MODE_DRY, MODE_FAN_ONLY }: modes
• void climate::publish_state(ClimateMode mode): set mode
• void climate::mode_auto(): set auto mode
• void climate::turn_off(): switch off
• void climate::mode_cool(): set cool mode
• void climate::mode_heat(): set heat mode
• void climate::mode_dry(): set dry mode
• void climate::mode_fan_only(): set fan only mode
• void climate::set_target_temperature(float temp): set target temperature
• ClimateMode climate::state: get mode
• float climate::target_temperature: get target temperature

Examples

Controlling an air con via IR. Unfortunately, there is not yet any way in remote_transmitter to calculate the remote code depending on some values (e.g. target temperature, fan_mode, ...)

climate:
  - platform: template
    name: "IR HVAC"
    modes:
      - auto
      - off
      - cool
      - heat
      - dry
      - fan_only
    auto_action:
      - switch.on_turn_on: ir_hvac_auto
    off_action:
      - switch.on_turn_on: ir_hvac_off
    cool_action:
      - switch.on_turn_on: ir_hvac_cool
    heat_action:
      - switch.on_turn_on: ir_hvac_heat
    dry_action:
      - switch.on_turn_on: ir_hvac_dry
    fan_only_action:
      - switch.on_turn_on: ir_hvac_fan_only
    optimistic: true

Simple thermostat heater with temperature sensor and relay.

climate:
  - platform: template
    id: climate_heater
    name: "Heater relay"
    sensor_id: my_temperature
    modes:
      - auto
      - heat
    target_temperature_action:
      - script.execute: control_heater
    mode_lambda: |-
      if (id(relay).state) {
        return climate::MODE_HEAT;
      }
      else {
        return climate::MODE_AUTO;
      }

sensor:
  - platform: dallas
    address: 0x1c0000031edd2a28
    id: my_temperature
    on_value:
      then:
        - script.execute: control_heater

output:
- platform: gpio
  pin: D1
  id: relay

script:
  - id: control_heater
    # Simple two-point controller. Better to implement as esphome component.
    then:
      - delay: 20ms
      - lambda: |-
          float hysteresis = 1.0;
          float target_temperature = id(climate_heater).target_temperature;
          if (isnan(target_temperature)) {
            ESP_LOGW("main", "Controller target_temperature is not defined!");
            id(relay).turn_off();
            return;
          }
          if (!id(my_temperature).has_state()) {
            ESP_LOGW("main", "Sensor my_temperature has no state!");
            id(relay).turn_off();
            return;
          }
          float target_temperature = id(my_temperature).state;
          if (temperature <= (target_temperature - hysteresis)) {
            id(relay).turn_on();
          }
          if (temperature >= (target_temperature + hysteresis)) {
            id(relay).turn_off();
          }

IMHO, additionally we should provide a controller components, too. Here a simple two-point controller is implemented as script. Another controller would be a PID controller.

[puuu]

We don't need to support both from the start, but the architecture should be made in a way that will support both.

Ok, then start with the bang-bang controller first. For the IR ones (as original requested in this feature request) we may need some architectural changes of ESPHome, because air con remote controller usually manage the whole status on the remote control and send it as a whole to the air con. This require to construct the IR messages form the actual state (target temperature, mode, fan, ...). As far as I see, this not yet supported by ESPHome.

Re current temperature: I don't think the climate device should use a Sensor object internally. It should just be a float attribute. I've tried this inter-component arch stuff before (with switch), but that didn't work too well and was removed.

The idea of the sensor id was inspired by the "Total Daily Energy Sensor". We need a way to get the temperature and publish it to a mqtt topic. Possible solutions are:

• take the sensor id and hook into the on_value action (configuration parameter: sensor_id)
• manage a float and let it update by an an service call (no configuration parameter)
• do not manage it at all and only tell HA about the mqtt topic of the sensor component (configuration parameter sensor_id or sensor_state_topic)

Note, we may need more configuration parameter, like accuracy_decimals.

I also think we should bring in the notion of "traits" for climate devices.

Yes sure!

Re modes:

Ok, lets begin with off, auto, cool and heat mode.
Actions are:

• climate.template.publish (mode, current_temperature, target_temperature)
• climate.control (mode, target_temperature)

Re target temperature:
Re config options:

Nested keys sounds good.

Re public API:

I don't like to make the thinks different here. The method wit the call object like in lights sounds good.

IMHO, additionally we should provide a controller components, too

Ideally, the controller base should not depend on the climate class. There are much more thinks, that can be controlled, e.g. humidity humidifier or light intensity. So we need to discuss the architecture of these components too.

We need:

• Input (process variable): can be an action/service call
• Setpoint: can be the state?
• Controller parameter (hysteresis; P, I, D value): can be configuration parameter
• Output (control variable): can be an output component or an action call

I already started to create some files if you like, I can make a WIP pull request.

[OttoWinter]

As far as I see, this not yet supported by ESPHome.

That is true, yes. Though most of the groundwork for it already exists here :) Even has the whole auto call = id(transmitter).transmit(); call.perform(); paradigm :)

I can make some remote_transmitter.transmit_... actions for all protocols for the next release, because the core exists already it will be bunch of boilerplate anyway.

Only thing that would need to be implemented it the IR protocols. Anybody here know which one would be a good place to start? Probably all manufacturers have their own one so I'd like to start out with one that is common.

Config for such an IR platform would then be like this (I also think we should call it ir_controller or so because this component will house a lot of templaty platforms):

- platform: ir_controller
  # Note: single action that controls everything; useful for IR climate devices
  # called any time something is changed, sends entire state
  # variables passed in directly as 'target_temperature' etc (like with api.services)
  control_action:
    remote_transmitter.transmit_...:
     target_temperature: !lambda 'return target_temperature;'
     mode: !lambda |-
       // convert climate mode to int with some logic
       return my_conversion(mode);

I guess we should name the publish action just climate.publish then too.

The idea of the sensor id was inspired by the "Total Daily Energy Sensor". We need a way to get the temperature and publish it to a mqtt topic. Possible solutions are:

So I don't have anything against having it be passed a sensor ID in the YAML config for the integration. What I'm proposing is only to have the core climate device architecture not care it's a sensor or not. The individual integrations can still manage it through sensors.

Note, we may need more configuration parameter, like accuracy_decimals.

Hmm, that is a good point. But, HA expects the accuracy in a different format anyway: precision (chosen from three fixed values 0.1, 0.5, 1.0). Don't ask me why it was done that way, but it is ¯_(ツ)_/¯

Ideally, the controller base should not depend on the climate class. There are much more thinks, that can be controlled, e.g. humidity humidifier or light intensity.

Why not? I think most of those are already handled by the HA climate component?

Input (process variable): can be an action/service call

We can either make this a lambda or directly hook it up to a sensor. I think 99% of people would hook it up to a sensor so let's make that a sensor directly passed in. If the user wants to customize things they can use template sensor.

Setpoint: can be the state?

Yes, target_temperature

Controller parameter (hysteresis; P, I, D value): can be configuration parameter

Yes (we probably will need to add a short guide to the docs of how to obtain these values/tune them).

Output (control variable): can be an output component or an action call

I say let's make it control a floatoutput directly, if the user wants to customize it they can still create a custom output.

[jjcrimmins]

Only thing that would need to be implemented it the IR protocols. Anybody here know which one would be a good place to start? Probably all manufacturers have their own one so I'd like to start out with one that is common.

Yes, you are correct most manufacturers have their own sometimes even multiple. The IRremoteESP8266 library already has a few AC protocols defined. I believe Daikin and Mitsubishi are two of the most popular.

[glmnet]

Only thing that would need to be implemented it the IR protocols. Anybody here know which one would be a good place to start? Probably all manufacturers have their own one so I'd like to start out with one that is common.
There are lots of models, another library is HeatpumpIr although both implement more or less the same models. Midea is very popular too. There's much component sharing / cloning so there are many more manufacturers than protocols itself. I even have an AC branded as Hyundai which is compatible with "Fuego" in HeatpumpIR, and there is a "Hyundai" protocol in that library that doesn't work.
The common denominator among all are Mode (Off, Cold, Heat, Dry, Fan), Target Temp and Fan Speed please include initial support for fan speed
I more or less understand all you're talking about here as I was spending some time looking at the code base, mostly Cover and Fan, so Traits idea is very important here, many AC are cool only.
Some AC models transmit more data, like current time, remote control sensed temperature, off timer, on timer, etc. Some send more than 100 bytes!
Then many remotes have toggle commands, in addition to all this static data, works like a regular remote, e.g. Toggle Led display, Toggle fan swing mode, even Toggle On / Off in some models.
The data transmitted to the AC via IR should be calculated somewhere: some send code repeated, others have a CRC, for me it makes most sense to be calculated by the esphome somewhere, I mean, please don't expect code to be calculated in HA or other controller and then be sent this raw by esphome.
I'll definitely be looking at this and try to implement my own ACs (3 different models, 5 units total) and provide feedback.

[puuu]

Ideally, the controller base should not depend on the climate class. There are much more thinks, that can be controlled, e.g. humidity humidifier or light intensity.

Why not? I think most of those are already handled by the HA climate component?

Simple, because a controller component is useful on its own. The climate component is only used for temperature control. For example, if you want to control humidity, you can use a humidity sensor and a relay with attached humidifier and pair them with the bang-bang controller.

Therefore, the implementations of the control components should not depend on the climate component. However, some climate component implementations may depend on control components.

Re: IR Climate component
First we can start to implement a simple controller and template platform with only cool and heat mode. In parallel the IR remote_transmitter component can be finalized. As soon as we start with a ir_controller platform for air cons, we need to add all modes and fan support.

[OttoWinter]

Simple, because a controller component is useful on its own.

I agree that is very useful. However, I think such a component without UI support won't be used much, or let's say one with UI support would be much more used :)

At least in my home automation setup, every time things are automated there needs to be some way to override it as the user.

I know climate is meant for temperature, but in the HA community I've seen many people (including myself :P ) use it for other values too. For me it is humidity as you said, it has the wrong unit in the frontend but other than that it's great.

Also, the climate model fits the controller model quite well. Controller would need its own abstraction which would only mean more work.

Anyway, I don't want to put any restrictions here. If you want to make a generic controller type too, that's ok also. Just wanting to give some input :)

[josh929800]

I have 4 NodeMCU BRUH multi-sensors that I have integrated with the IRMQTTServer Currently I have NodeRed receiving the Climate Commands from Home Assistant and then NodeRed generates the appropriate IR command. NodeRed keeps track of each part of the IR command e.g. power, fan speed, set temp, mode, etc. NodeRed also has to calculate the CheckSum of the IR command for the AC Unit. I am then passing the IR code to the NodeMCU to send to the AC.

A possible option would be to allow sending the IR command directly to the esphome.

[glmnet]

So where is the branch?

[nickrout]

Climate is a suggestion I came here to make, glad I read the issues list first!

I have a couple of Mitsubishi heatpumps and I am about to implement this https://github.com/SwiCago/HeatPump which consists of a library and an mqtt implementation for home assistant. This library is based on the work that @erazor666 referred to in post 2 of this thread. Unlike many other heatpump implementations it does provide feedback (as it is not IR based). Although there is a working implementation in SwiCago's repo, I thought it would be nice to have it incorporated into esphome. Anyway, I'll leave that with you. Thanks as always.

[freddan-teamleader]

Would be great if this would be implemented. Today I have to use https://github.com/ToniA/arduino-heatpumpir to make it work and my own mqtt etc.

[glmnet]

@freddan-teamleader do you integrate ha climate card/device. Could you share esp/ha yaml

[puuu]

@OttoWinter , thank you for implementing the climate device and the bang-bang controller! I have some comments to this. Basically I like the two-point-target-temperature option, it is really useful for a combined heating and cooling unit, but unfortunately there is no hysteresis for this configuration (combined heating and cooling support). Also, the need to handle two temperatures for a heating (or cooling) only device is a little too complicated.

The hysteresis of a bang-bang controller is very essential and depends on other components in the control loop, especially the noise of the sensor and the endurance of the relay. Without hysteresis means that the output (e.g., relay) under certain condition will cycle every time a new sensor signal arrives. A relay with 100000 ops endurance (e.g. sonoff basic) and a sensor update interval of 60 s may cause the relay to die after 2.5 months.
IMHO, hysteresis (HA call it tolerance) needs to be a config parameter of the bang-bang controller (not part of the user frontend).

[OttoWinter]

@puuu So about the hysteresis: I think the way it works currently is actually a hysteresis factor - it will correctly keep the temperature within the set region over time.

If I understand correctly you'd like the climate device to always be heating/cooling with no idle phase between? Wouldn't that be terribly inefficient with always heating/cooling when the temperature is already within the target range?

I guess this depends on the device in use - if there's a longish delay between relay actuating and temperature changing, the current model works well (temperature will keep increasing/decreasing for a while even after idling). For other applications that could indeed be a problem.

endurance of the relay.

I guess we could add a minimum cycle length option to work against that. Once the climate device enters a mode, it will stay there at least for that amount of time irrespective of sensor input. That would double as a time-based hysteresis parameter.

IMHO, hysteresis (HA call it tolerance) needs to be a config parameter of the bang-bang controller (not part of the user frontend).

This is a separate point from the above right? Because the two-point mode actually is the exact same as a hysteresis, just with dynamic/user-adjustable hysteresis values.

And at least in my experience using this having the ability to change the hysteresis params via the frontend is invaluable if you're trying to tweak the system. Otherwise you'd need to go edit the config each time

[puuu]

If I understand correctly you'd like the climate device to always be heating/cooling with no idle phase between?

No, absolutely not. The idle phase is perfect! But for the combined heating/cooling controller, however, we need a hysteresis around the high and low temperature.

                low_temperature                            high_temperature
...----------|--------||--------|------------------------|--------||--------|----------...
    heating  |    hysteresis    |         idle           |    hysteresis    |  cooling

These are two independent controllers, one for heating and one for cooling. Both require their own hysteresis, especially when switched via relays.
In any case, the hysteresis parameter depends on the overall control system and there may be cases where no hysteresis is required. In this case, the hysteresis parameter can be set to 0.

As practical case: I have an 800 W heater controlled by a relay (sonoff basic). At certain outside temperatures and target temperatures, I can see the temperature of the sensor rising to the target temperature, then the relay switches off and within 60 s (sensor update interval) the temperature is again below the target temperature and the relay will turn back on. This can repeat for a very long time. The introduction of a hysteresis of ±0.3 °C increases the switching interval to 30 minutes and more.

A hysteresis/tolerance value is the typical parameter for such cases. A parameter for the minimum cycle length is also possible, but I like to think about the temperature (control parameter) rather than time by designing/optimizing the controller. Please note that HA Generic Thermostat has both, the parameter cold_tolerance/hot_tolerance (hysteresis) and min_cycle_duration.

Because the two-point mode actually is the exact same as a hysteresis, just with dynamic/user-adjustable hysteresis values.

From the point of view of the control system, the two-point mode (for a single heater/cooler) is exactly the same as a hysteresis, but from the usability view not. I don't want to talk about people in my household who I have to teach, how to set two temperatures, and what is the best distance between those two temperatures. Just think of automations if every time you want to change the target temperature, you need to calculate and set two temperatures. This is much more complicated than it has to be.
Two-point mode may be interesting and acceptable for tweaking the system, but unhandy for the daily usage and automation. IMHO, after optimizing the controller, it is not necessary to control the hysteresis from the frontend and I do not know any commercial thermostats where the hysteresis parameter is directly accessible.

[glmnet]

May be instead of target temperature high and low they should be target HEAT and COLD

[blademckain]

would it be possible to also integrate a scheduler? like this:
https://github.com/emoncms/development/tree/master/experimental/control/open_thermostat_scheduler
or another implementatio of thermostat with scheduler with esp8266
https://github.com/openenergymonitor/ESP8266_Relay_Board

[OttoWinter]

These are two independent controllers, one for heating and one for cooling. Both require their own hysteresis, especially when switched via relays.

Hmm I think you answered the question there :) You need two controllers in that case, one for the heater, one for the cooler. So... that means two climate devices, one for heating and one for cooling.

Adding a second layer of hysteresis as this change would mean would just over-complicate the system too much. For sure we can create a new platform that does solve this, but that should not be in the bang_bang controller.

Two-point mode may be interesting and acceptable for tweaking the system, but unhandy for the daily usage and automation. IMHO, after optimizing the controller, it is not necessary to control the hysteresis from the frontend and I do not know any commercial thermostats where the hysteresis parameter is directly accessible.

I agree, we should either:

• Make that a separate platform or
• Add a new single_point (or so) option with which static hysteresis parameters can be set - if so, a single target temperature point will be shown. Otherwise both are shown.

May be instead of target temperature high and low they should be target HEAT and COLD

@glmnet I don't understand how that would be any different from the current approach?

would it be possible to also integrate a scheduler?

@blademckain One step at a time please. However, all that would already be possible with the time component as far as I see.

[glmnet]

As I see it the two point temperature set point are e.g. when you have a device capable of both heat and cool. Otherwise as discussed above I don’t want to bother with hysteresis etc.
Now semantically it makes more sense to me to say heat to e.g 18 deg and cool to 24 deg.
So if ambient is cooler than 18 then it will start working the heater.
Now if it is warmer than 24 it will star working as cooler. It would work with “two hysteresis” as @puuu said but if it is cooling most likely the ambient is warm and the warm set point would never kick in (until winter). Unless you live somewhere you have big climates changes during day/night and your hvac will actually cool and heat in the same day.

[OttoWinter]

Now semantically it makes more sense to me to say heat to e.g 18 deg and cool to 24 deg. So if ambient is cooler than 18 then it will start working the heater.

Yes... and that's exactly what the two-point temperature currently does. When you enter 18 as low-point and 24 as high-point, then it will start heating when below 18 and start cooling when above 24.

Anyway, the documentation I have planned (but not written yet) will explain it exactly like that: heat/cool until a position is reached.

[glmnet]

Any information on what has been done, or what "platforms" are being worked on

currently there is the bang_bang platform, which needs a temperature sensor to trigger custom actions to .e.g relays.
I sent a PR with another platform 'coolix' which sends IR remote code.
This dev branch is working and handling the communication with HA 0.92 nicely.

More or less everything you want to do can be done with no problems, but looks like you are mixing too much stuff together.

[rarroyo6]

Thanks, bang_bang is what I'm after, since I'm doing it self-contained. I saw the 'coolix' option above but it doesn't meet my needs.
I'll try to make some time to try it this weekend.
Is there a link to the code or documentation? I could not find any.

[glmnet]

bang_bang is only on dev branch AFAIK
No docs there yet, this is really new in the dev branch. Since you are getting started with this it can be a bit hard to learn with no docs.
You might want to make sure you can run other stuff alone first, like temperature sensor, switches, lights, etc.
Then by reading the climate.py in the folder of bang_bang you can figure out which options it will accept in the yaml, but basically it will be something like this:

climate:
  - platform: bang_bang
    id: my_climate
    sensor: sensor_id # this id must match one sensor defined somewhere, e.g. a DHT22 sensor, when you declare the temperature element you give an id for it there
    default_target_temperature_log: 17
    default_target_temperature_high: 25
    idle_action: lambda |-
      some c action code here

those are required (mandatory) config element, then you have optional ones, check the py code and you should be on your way

[rarroyo6]

Thanks, that was a big help.
I had already installed the dev branch, I'll look at the code this week and give it a try.

[DutchDynamics]

Hi,
Trying to use this new component to control the water temperature of a Jacuzzi.
Are the configuration min_temp en max_temp implemented?

When I try to use it I get a validation error:
[min_temp] is an invalid option for [climate.bang_bang]. Please check the indentation.
min_temp: 30 [source /config/esphome/other_outside_jacuzzi.yaml:38]

Thanks for this nice compenent

[glmnet]

the following is a valid configuration

sensor:
  - platform: dht
    pin: D0
    temperature:
      id: dht_temp
    humidity:
      id: dht_hum

switch:
  - platform: gpio
    pin: D1
    id: heater

climate:
  - platform: bang_bang
    id: bang_bang_climate
    sensor: dht_temp
    idle_action:
      - switch.turn_off: heater
    default_target_temperature_low: 10
    default_target_temperature_high: 20
    heat_action:
      - switch.turn_on: heater

[DutchDynamics]

Hi,
Found that the functions that i need are not implemented on the Bang Bang climate control.
Functions op the generic_thermostat in HA. Are a perfect match for me.
So for now I will expose the sensor and switch with ESPHome and configure a generic_thermostat in HA

Thanks

[DutchDynamics]

Hi,
Trying the bang bang controller another change, but cannot select a temperature about 30C.
I configured in the

    default_target_temperature_low: 35
    default_target_temperature_high: 37

Because I want the heater to go on when the water is 35 and switch of when the water is 37
Initially this looks ok in HA, but when I click the arrow up on 37 it jumps down to 30

I try to get this working, because I want the D1 Mini to be able to operate standalone without HA

[glmnet]

climate:
  - platform: bang_bang
    ...
    visual:
      min_temperature: 30.0
      max_temperature: 50.0
      temperature_step: 1.0

[DutchDynamics]

Thanks, that is helps a lot. Now its working much better.
Google Home Assistant cannot handle it, but that is not a problem to discuss here ;-)

[OttoWinter]

I'm gonna close this because climate is in 1.13 - additional features like fan_only etc can be discussed here (though I would wait with those a bit until HA's climate architecture v2 has settled a bit)

[glmnet]

👏 👏 👏 👏

[r-jordan]

Super!!

[Bird55]

Hello,
I set up a bang_bang thermostat on the BlitzWulf BWSP-2, to which I connected DS18B20,
it works fine. But there is a problem. Thermostat publishes data to the MQTT broker with high frequency.
Is it possible to increase the publication interval of MQTT messages from the ESPHome?

[OttoWinter]

@Bird55 The bang_bang climate controller publishes as often as the base sensor - see update_interval and sensor filters on the base sensor.

Please don't use this issue for further discussions - the feature has been implemented and I will lock the conversation.