최근 Home Assistant를 2025.12.1에서 2026.10.4로 업데이트했다.
업데이트 자체는 정상적으로 끝났지만, 이후 설정을 확인하던 중 문제 해결(Repairs) 메뉴에서 새로운 오류가 발견됐다.
지원되지 않는 YAML 구성 template
sensor: 키 아래에 platform: template를 추가하여 template 통합 구성 요소를 설정하는 방식은 지원되지 않는다. 대신 template 통합 구성 요소를 자체 template: 키 아래에 설정해야 한다.
처음에는 단순히 오래된 YAML 문법에 대한 경고인 줄 알았다. 그런데 확인해 보니 기존에 만들어 두었던 에어컨 작동 감지 자동화에도 문제가 생겨 있었다.
이 자동화는 개인적으로 꽤 유용하게 사용하던 기능이다. IoT를 지원하지 않는 오래된 에어컨의 작동 상태를 알아내기 위해 직접 구성한 것이기 때문이다.
1. IoT를 지원하지 않는 에어컨의 작동 상태 알아내기
집에서 사용하는 에어컨은 오래된 모델이라 IoT 기능을 지원하지 않는다.
일반적인 IoT 에어컨이라면 스마트폰이나 Home Assistant에서 전원 상태를 조회할 수 있겠지만, 이 에어컨은 그런 기능이 없다.
적외선 리모컨으로 조작할 수는 있어도 현재 에어컨이 실제로 켜져 있는지, 꺼져 있는지를 외부에서 확인하기는 어렵다.
특히 집 밖에 있을 때가 문제였다. 에어컨을 끄고 나왔는지 기억나지 않더라도 확인할 방법이 없었다.
그래서 에어컨 자체의 상태를 읽을 수 없다면, 에어컨이 작동할 때 주변 환경에 나타나는 변화를 이용하면 되지 않을까? 하는 생각이 들었다.
여기서 떠올린 것이 온도 차이를 이용하는 방법이었다.
송풍구 온도와 실내 온도를 비교하면 어떨까?
에어컨이 냉방을 시작하면 송풍구에서 차가운 바람이 나온다.
당연히 송풍구 바로 앞의 온도는 방 전체의 온도보다 훨씬 낮아진다. 반대로 에어컨이 꺼지면 송풍구 주변 온도는 점차 실내 온도와 비슷해진다.
이 차이를 이용하면 에어컨의 작동 여부를 간접적으로 알아낼 수 있을 것 같았다.
실제로 온도 센서 두 개를 다음과 같이 배치했다.
- 실내 온도 센서: 방의 일반적인 실내 온도를 측정한다.
- 송풍구 온도 센서: 에어컨 송풍구 바로 앞에 설치해 나오는 바람의 온도를 측정한다.
두 센서의 온도 차이는 다음과 같이 계산한다.
온도 차이 = 실내 온도 - 송풍구 온도
예를 들어 실내 온도가 27°C이고 송풍구 온도가 20°C라면 온도 차이는 7°C가 된다.
반대로 에어컨이 꺼져 두 센서가 비슷한 온도를 측정한다면 온도 차이는 1°C 안팎으로 줄어들 수 있다.
이 수치들은 원리를 설명하기 위한 예시지만, 실제로도 냉방이 시작되면 송풍구 앞 센서의 온도가 빠르게 내려가면서 두 센서 사이에 뚜렷한 차이가 나타났다.
적절한 온도 차이를 찾기 위한 실험
처음부터 몇 도 차이가 나면 에어컨이 켜진 것으로 판단할지 알 수 있었던 것은 아니다.
실내 온도는 계절이나 시간에 따라 달라지고, 에어컨의 설정 온도나 풍량에 따라서도 송풍구 온도가 달라질 수 있기 때문이다.
그래서 에어컨을 직접 켜고 끄면서 두 센서의 온도가 어떻게 변하는지 관찰했다.
냉방이 시작되었을 때 온도 차이가 얼마나 벌어지는지, 에어컨을 끄면 어느 정도까지 줄어드는지 확인하면서 적절한 기준값을 찾았다.
이 과정에서 단순히 하나의 임계값만 사용하는 것보다 켜짐과 꺼짐의 기준을 다르게 설정하는 편이 안정적이라는 점도 고려했다.
이를 히스테리시스(Hysteresis)라고 한다.
예를 들어 다음과 같은 기준을 사용할 수 있다.
온도 차이에어컨 상태 판단
| 3.5°C 이상 | 켜짐 |
| 3.0°C 이하 | 꺼짐 |
| 3.0°C 초과 ~ 3.5°C 미만 | 이전 상태 유지 |
위 수치는 설명을 위해 변경한 예시다. 실제 임계값은 설치 위치와 에어컨의 냉방 특성에 맞춰 실험으로 조정했다.
켜짐과 꺼짐의 기준을 다르게 설정하면 온도 차이가 경계값 근처에서 조금씩 변하더라도 상태가 불필요하게 반복 전환되는 것을 줄일 수 있다.
이렇게 온도 센서 두 개와 Home Assistant의 템플릿 기능을 이용해, IoT를 지원하지 않는 에어컨의 작동 여부를 간접적으로 판단하는 센서를 만들었다.
물론 에어컨에서 직접 제공하는 전원 상태와 완전히 동일한 정보는 아니다. 정확히는 송풍구에서 차가운 바람이 나오고 있는지를 기준으로 냉방 작동 여부를 추론하는 방식이다.
에어컨이 송풍만 하거나 냉방을 일시적으로 멈춘 경우에는 실제 전원 상태와 다르게 판단할 수 있다. 그래도 내가 필요로 하는 냉방 상태 확인에는 꽤 실용적인 방법이었다.
2. Home Assistant 업데이트 이후 자동화에서 발생한 문제
이 기능을 구현하기 위해 Home Assistant에 두 개의 템플릿 센서를 만들어 사용했다.
첫 번째 센서는 실내 온도와 송풍구 온도의 차이를 계산하고, 두 번째 센서는 계산된 온도 차이를 바탕으로 에어컨의 작동 상태를 판단한다.
이후 바이너리 센서가 on 상태로 바뀌면 알림을 보내도록 자동화를 구성했다.
그런데 Home Assistant 업데이트 이후 자동화 편집 화면에 다음과 같은 경고가 나타났다.
알 수 없는 엔티티
binary_sensor.example_ac_status
기존에 사용하던 에어컨 상태 센서를 찾지 못하는 것이다.
Home Assistant의 개발자 도구 → 상태(States) 메뉴에서 관련 엔티티를 직접 검색했다.
sensor.example_temperature_difference
binary_sensor.example_ac_status
두 엔티티 모두 검색되지 않았다.
자동화 설정이 잘못된 것이 아니라, 자동화에서 참조하는 센서 자체가 Home Assistant에 생성되지 않고 있었다.
앞서 문제 해결 메뉴에서 표시된 YAML 오류와 관련이 있을 것으로 생각해 configuration.yaml 파일을 확인했다.
3. 원인은 Legacy Template Sensor 지원 종료
문제가 된 기존 YAML 설정은 다음과 같은 형태였다.
아래 코드는 실제 기기 식별자를 제거하고 센서 이름과 임계값을 예시로 변경한 것이다.
sensor:
- platform: template
sensors:
example_temperature_difference:
friendly_name: "Temperature Difference"
unit_of_measurement: "°C"
value_template: >-
{{
(
states('sensor.example_room_temperature') | float
- states('sensor.example_ac_temperature') | float
) | round(2)
}}
binary_sensor:
- platform: template
sensors:
example_ac_status:
friendly_name: "AC Status"
value_template: >-
{% set previous = states('binary_sensor.example_ac_status') %}
{% set diff = states('sensor.example_temperature_difference') | float %}
{% if diff >= 3.5 %}
true
{% elif diff <= 3.0 %}
false
{% else %}
{{ previous }}
{% endif %}기존에는 sensor:와 binary_sensor: 아래에 platform: template을 선언해 템플릿 센서를 만들 수 있었다.
하지만 Home Assistant는 2025.12부터 해당 방식의 지원 중단을 예고했고, 2026.6에서 구형 템플릿 엔티티 구현을 제거했다.
따라서 2026.10.4에서는 기존 YAML이 남아 있더라도 템플릿 센서가 정상적으로 생성되지 않는다.
여기서 한 가지 구분해야 할 부분이 있다.
triggers:
- trigger: template
value_template: "{{ ... }}"자동화에서 사용하는 템플릿 트리거는 이번에 제거된 구형 템플릿 센서 플랫폼과 다르다.
자동화의 template 트리거까지 모두 수정해야 하는 것은 아니다.
이번 문제는 센서를 정의하는 방식이 변경되면서 기존 센서가 사라진 것이 핵심이었다.
4. 새로운 Template Integration 형식으로 마이그레이션
현재 Home Assistant에서는 템플릿 센서를 최상위 template: 키 아래에 정의해야 한다.
주요 변경 사항은 다음과 같다.
기존 설정새로운 설정
| sensor: - platform: template | template: - sensor: |
| binary_sensor: - platform: template | template: - binary_sensor: |
| sensors: 센서명: | - name: 센서명 |
| friendly_name | name |
| value_template | state |
이번 마이그레이션에서는 기존 기능을 유지하면서 센서 상태 처리도 일부 개선했다.
최종적으로 변경한 설정은 다음과 같다.
template:
- sensor:
- name: "Example Temperature Difference"
unique_id: example_temperature_difference
default_entity_id: sensor.example_temperature_difference
unit_of_measurement: "°C"
availability: >-
{{
is_number(states('sensor.example_room_temperature'))
and is_number(states('sensor.example_ac_temperature'))
}}
state: >-
{% set room = states('sensor.example_room_temperature') | float(0) %}
{% set ac = states('sensor.example_ac_temperature') | float(0) %}
{{ (room - ac) | round(2) }}
- binary_sensor:
- name: "Example AC Status"
unique_id: example_ac_status
default_entity_id: binary_sensor.example_ac_status
availability: >-
{{
is_number(states('sensor.example_temperature_difference'))
}}
state: >-
{% set diff = states('sensor.example_temperature_difference') | float(0) %}
{% if diff >= 3.5 %}
true
{% elif diff <= 3.0 %}
false
{% else %}
{{ this.state == 'on' }}
{% endif %}기존 엔티티 ID 유지
기존 자동화가 특정 엔티티 ID를 참조하고 있기 때문에 마이그레이션하면서 엔티티 ID가 달라지지 않도록 하는 것이 중요했다.
이를 위해 unique_id와 default_entity_id를 지정했다.
unique_id: example_temperature_difference
default_entity_id: sensor.example_temperature_differenceunique_id는 Home Assistant가 엔티티를 고유하게 식별하기 위한 값이다.
default_entity_id는 새로운 엔티티가 생성될 때 기본으로 사용할 ID를 지정한다.
다만 기존 엔티티 레지스트리에 등록된 정보가 있다면 해당 정보가 우선할 수 있으므로, 마이그레이션 이후 실제 생성된 엔티티 ID를 확인해야 한다.
센서 값이 없을 때의 예외 처리
기존 설정에서는 센서 값을 바로 float로 변환했다.
하지만 온도 센서가 일시적으로 연결되지 않거나 Home Assistant가 시작되는 과정에서는 unknown이나 unavailable 같은 상태가 발생할 수 있다.
이를 처리하기 위해 availability를 추가했다.
availability: >-
{{
is_number(states('sensor.example_room_temperature'))
and is_number(states('sensor.example_ac_temperature'))
}}두 센서의 값이 모두 정상적인 숫자일 때만 온도 차이를 계산하도록 했다.
한쪽 센서에서 유효하지 않은 값이 반환된다면, 잘못된 온도 차이로 에어컨 상태를 판단하지 않도록 해당 템플릿 센서를 사용할 수 없는 상태로 처리한다.
이전 상태를 유지하는 히스테리시스 로직
기존 에어컨 상태 판단 로직도 유지했다.
온도 차이가 켜짐 기준 이상이면 true, 꺼짐 기준 이하이면 false를 반환하고, 두 기준 사이에서는 이전 상태를 유지한다.
기존에는 바이너리 센서가 자기 자신의 상태를 조회하는 방식이었다.
{{ states('binary_sensor.example_ac_status') }}새로운 설정에서는 this.state를 사용했다.
{{ this.state == 'on' }}this는 템플릿 엔티티가 렌더링되기 전 상태를 참조할 수 있도록 제공하는 변수다.
이를 이용해 기존처럼 온도 차이가 중간 구간에 있을 때 이전 상태를 유지할 수 있도록 했다.
다만 재시작 시 이전 상태가 항상 복원되는 것은 아니다. 재시작 직후 온도 차이가 중간 구간에 있으면 이전 작동 상태를 알 수 없다는 한계는 남아 있다.
이 부분까지 정확하게 처리하려면 상태 복원 방식에 대한 추가적인 설계가 필요하다.
5. Code Server에서 발생한 YAML 경고
설정을 수정하는 과정에서 또 다른 경고가 나타났다.
Studio Code Server에서 default_entity_id에 빨간 밑줄이 표시되면서 다음 메시지가 출력됐다.
처음에는 새로운 템플릿 설정에서 해당 속성을 지원하지 않는 줄 알았다.
하지만 Home Assistant의 개발자 도구 → YAML → 구성 확인을 실행하면 다음 메시지가 표시됐다.
공식 Template Integration 문서를 확인해 보니 default_entity_id는 실제로 지원되는 설정 항목이었다.
이번 경고는 Code Server에서 사용하는 YAML 스키마가 Home Assistant의 현재 설정 형식을 제대로 반영하지 못한 것으로 보인다.
설정 파일을 편집하는 도구와 실제 설정을 실행하는 Home Assistant가 서로 다른 검증 방식을 사용하기 때문에 이런 차이가 발생할 수 있다.
이럴 때는 편집기의 경고만 보고 설정을 제거하기보다 공식 문서와 Home Assistant 자체의 구성 검사 결과를 함께 확인하는 것이 좋다.
6. 설정 적용 및 확인
YAML을 수정한 후 Home Assistant에서 구성 확인을 실행했다.
개발자 도구 → YAML → 구성 확인
구성 검사에서는 문제가 발견되지 않았다.
다만 구성 검사를 통과했다고 해서 센서가 실제로 정상 동작한다는 의미는 아니다.
변경한 템플릿 센서가 제대로 생성되는지 확인하려면 Home Assistant를 재시작한 뒤 개발자 도구의 상태 메뉴에서 다음 엔티티를 확인해야 한다.
sensor.example_temperature_difference
binary_sensor.example_ac_status
온도 차이 센서는 실내 온도와 송풍구 온도 사이의 차이를 숫자로 표시해야 한다.
에어컨 상태를 판단하는 바이너리 센서는 계산된 온도 차이를 바탕으로 on 또는 off를 반환해야 한다.
마지막으로 실제 에어컨을 켜고 끄면서 상태가 예상대로 전환되는지 확인하고, 연결된 자동화까지 정상적으로 실행되는지 검증하면 된다.
마무리
IoT를 지원하지 않는 오래된 에어컨이라고 해서 Home Assistant에서 활용할 방법이 전혀 없는 것은 아니다.
에어컨 자체의 상태 정보를 직접 조회할 수는 없지만, 에어컨이 작동하면서 주변 환경에 만들어 내는 변화를 측정하면 어느 정도 상태를 추론할 수 있다.
내 경우에는 송풍구 바로 앞에 온도 센서를 설치하고, 실내 온도와 비교하는 방법을 선택했다.
처음에는 단순한 아이디어였지만 실제로 에어컨을 켜고 끄며 온도 변화를 관찰하고 적절한 임계값을 찾으면서 사용할 만한 자동화를 만들 수 있었다.
이번 Home Assistant 업데이트에서는 이 기능을 구현하던 구형 템플릿 센서 설정이 더 이상 지원되지 않으면서 문제가 발생했다.
다행히 센서의 기능 자체가 제거된 것은 아니었다. 기존 platform: template 설정을 새로운 template: 형식으로 마이그레이션하면 같은 방식으로 센서를 구성할 수 있다.
이번 작업을 하면서 다시 느낀 점은 Home Assistant의 장점이 단순히 IoT 기기를 한곳에 모아 관리하는 것에만 있지는 않다는 것이다.
기기가 제공하지 않는 정보라도 다른 센서의 데이터를 조합하고 적절한 로직을 설계하면 새로운 상태 정보로 만들어 낼 수 있다.
이런 방식으로 오래된 기기까지 자동화에 활용할 수 있다는 점이 Home Assistant를 사용하는 재미 중 하나인 것 같다.
참고 자료
'IOT > Home Assistant' 카테고리의 다른 글
| Home Assistant 2026.8 HTTP 설정 마이그레이션: YAML에서 UI로 변경된 이유와 대응 방법 (0) | 2026.10.31 |
|---|---|
| Home Assistant 외부 접속 중 untrusted proxy 오류 해결하기 (1) | 2025.11.16 |
| ESP32-CAM을 Home Assistant에 연동하기: ip 카메라 구축 (0) | 2025.10.27 |
| Home Assistant에 Ulanzi Desktop Clock 연동하기 (0) | 2025.10.22 |
| Home Assistant로 구형 에어컨 자동화하기 (2) | 2025.08.17 |