Guru Suggestions on my Yaml Code

The yaml code below is what I use to activate the air conditioner inside my home lab. The code has been running pretty much the same for quite some time now, and is mostly ok from what I can tell.

On several occasions when the ESP32 gets out of sync with home assistant the AC unit wont start, even though the room is above the trigger temperature of 24 degrees Celsius. Also, I am not sure my code to start and stop the AC unit is a really sound approach?

I’ve tried a number of code ideas to ensure the esp5-studio-ac is as independent as possible i.e. so it runs the AC unit independent of most other HA functions. But I am unsure if I’ve really achieved the goal?

I am wondering if some of the esphome yaml gurus here could give me five minutes of your valuable time, to perhaps critically review my code, and possibly give me some tips on changes I should make or any suggestions.

Any time you can give is greatly appreciated, and feel free to be brutal :stuck_out_tongue:

  name: esp5-studio-ac
  platform: ESP32
  board: esp32doit-devkit-v1
  - wait_until:
      condition: api.connected
  - delay: 2s
  - script.stop: ac_timer
  - climate.control:
      id: ac_climate_id
      mode: 'off'
  - mqtt.publish:
      topic: HomeAssistant/Studio/Aircon/Status
      payload: "OFF"

# Enable logging
#  level: VERBOSE

# Enable Home Assistant API
  reboot_timeout: 0s

  password: !secret esp5-studio-ac-ota

  ssid: !secret wifi_ssid
  password: !secret wifi_password
  # Enable fallback hotspot (captive portal) in case wifi connection fails
    ssid: "Esp32-Ir-Test Fallback Hotspot"
    password: "<redacted>"


  pin: GPIO2

#Temperature Sensor Pin
  - pin: 23
    update_interval: 30s

#  broker: !secret mqtt_broker
  broker: !secret mqtt_broker_new
  username: !secret mqtt_login
  password: !secret mqtt_passwd
  port: 1883
  reboot_timeout: 0s
  keepalive: 60s
  discovery: false

# IR TRansmitter entry
  pin: GPIO5
  id: ir_transmit
  carrier_duty_percent: 50%

  - platform: daikin
    name: "Aircon Studio"
    id: ac_climate_id
    supports_heat: false
    transmitter_id: ir_transmit

  - id: ac_timer
      - binary_sensor.template.publish:
          id: timer_status
          state: ON
      - logger.log: "AC Timer is ON"
      - delay: 20min
      - binary_sensor.template.publish:
          id: timer_status
          state: OFF
      - logger.log: "AC Timer is OFF"

  - platform: template
    id: ac_climate_mgmt
    name: "Studio AC Climate"
          - climate.control:
              id: ac_climate_id
              mode: COOL
              fan_mode: AUTO
              target_temperature: 23°C
          - mqtt.publish:
              topic: HomeAssistant/Studio/Aircon/Status
              payload: "ON"
          - logger.log: "AC is ON"
          - climate.control:
              id: ac_climate_id
              mode: 'off'
          - mqtt.publish:
              topic: HomeAssistant/Studio/Aircon/Status
              payload: "OFF"
          - logger.log: "AC is OFF"
  - platform: template
    id: out_ac_temp_status
  - platform: template
    id: timer_status

# Studio Inside temperature sensor
  - platform: dallas
    id: in_ac_dallas
    resolution: 12
    address: <redacted>
    name: "Studio AC Inside Temperature"
      - if:
              # Is the inside temp higher than 24
              - lambda: 'return id(in_ac_dallas).state > 24;'
              # Start the AC Unit
              - binary_sensor.template.publish:
                  id: ac_climate_mgmt
                  state: on
              - script.execute: ac_timer
              - logger.log: "Telling Climate to START"
      - if:
              # Is the Outside temp under 18
              - lambda: 'return id(out_temp_studio).state < 18;'
              # Is the inside temp lower than 23
              - lambda: 'return id(in_ac_dallas).state < 23;'
              - binary_sensor.is_off: timer_status
              - binary_sensor.template.publish:
                  id: ac_climate_mgmt
                  state: off
              - script.stop: ac_timer
              - logger.log: "Telling Climate to STOP"

# Studio Outside Temperature from HA  
  - platform: homeassistant
    id: out_temp_studio
    name: "Studio Outside Temperature"
    entity_id: sensor.studio_temp_out

I don’t really get why you need so much code to manually manage things.

Can’t you just have a thermostat type set-up that once configured manages itself?


Same question here. Why not a climate component together with the native api? Maximum autonomy and integration at the same time!

Hi There… you make absolutely good sense. I started originally with a thermostat type, but found it was suffering from several issues. Let me explain…

My home lab has a number of servers running, so needs to be kept cool. I use two types of cooling… ‘free air’ and AC cooling.

Free air cooling draws outside cool air through a home made heat exchanger and keeps the room cool when the outside temp is below 18 degrees celcius. Above 18 degrees, the room automatically ‘seals’ and the free air cooling shuts down, and the AC cooling starts - you will see references to that in the yaml code.

The original code design I had was a thermostat… however the ‘exchange’ between the free air and AC cooling was problematic. And at times the free air was running and the AC running… which was an issue.

So why dont I have both functions on a single esp32… I wanted to keep them separate, so if all else fails the AC runs keeping the room cool. Whether or not this is the best approach… who knows?

I have been through a number of iterations, and happy to admit I am not the best yaml coder. But am always open to ideas.

So if there’s coding examples you feel might suit my use case then let point me in that direction. I find it easier to look at examples and work my way from there.

Now I better understand and notice the context that your “AC off” condition is more complex than typical and needs to look at both internal and external temperatures due to the dependancies on a second cooling system.

I think your approach in this case is reasonable.

As your AC device is the more critical one to be operating (?) I think your main reliability risk is when out_temp_studio can’t be imported?

You may want to think about desired behaviour when it is unavailable/down and double check it works/handles as expected.

My other question would be the same as @indeeed - is MQTT necessary. Consider just using the native API. I don’t have a detailed understanding of the pros and cons of each but tend to use the native api unless I can’t.

I don’t have any specific code examples.