search

esphome / feature-requests

ESPHome Feature Request Tracker
https://esphome.io/
412 stars 26 forks source link

New integration with Climate component of Home assistant #24

Closed david-yam closed 5 years ago

david-yam commented 5 years ago

What new integration would you wish to have?

Integration with the Climate component of Home assistant

If possible, provide a link to an existing library for the integration: N/A

Please describe your use case for this integration and alternatives you've tried:

Making use of the IR transmitter to control the heatpump including the operating mode, fan speed, target temperature. The IR codes of the common heatpump models (e.g. mitsubishi, panasonic, etc.) are readily available on the Internet. 

remote_transmitter:
  pin: GPIO2

climate:
  - platform: remote_transmitter
    name: "Mitsubishi Heatpump"
    model: mitsubishi

Additional context:

erazor666 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@glmnet See https://github.com/esphome/feature-requests/issues/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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

Yes, a climate component is really missing in ESPHome.

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

@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:

Thermostat Card

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:

MQTT Options:

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:

Configuration variables:

MQTT Options:

Actions:

Target temperature

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

Configuration variables:

MQTT Options:

Actions:

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:

public API

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.

OttoWinter commented 5 years ago

@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:

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:

// 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:

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:

puuu commented 5 years ago

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:

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:

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:

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

OttoWinter commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

So where is the branch?

nickrout commented 5 years ago

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.

puuu commented 5 years ago

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.

freddan-teamleader commented 5 years ago

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 commented 5 years ago

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

puuu commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

blademckain commented 5 years ago

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 commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

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.

rarroyo6 commented 5 years ago

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.

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.

glmnet commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago 
climate:
  - platform: bang_bang
    ...
    visual:
      min_temperature: 30.0
      max_temperature: 50.0
      temperature_step: 1.0
DutchDynamics commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

:clap: :clap: :clap: :clap:

r-jordan commented 5 years ago

Super!!

Bird55 commented 5 years ago

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 commented 5 years ago

@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.