Home Assistant를 설치했다는 사실과 실제 자동화가 동작한다는 사실은 별도로 확인해야 합니다. 이 글은 Home Assistant Container의 공식 설치 구성을 설명하고, 운영 환경과 분리한 검증 환경에서 API 응답, 엔터티 상태, 자동화 실행, 관리 화면까지 확인한 범위를 기록합니다.
설치 명령과 검증 환경의 차이를 먼저 구분합니다
Home Assistant 공식 문서는 Linux의 Container 설치에 Docker Engine과 별도 /config 저장 경로, 8123 포트 접근을 안내합니다. Container 방식은 운영체제와 Docker 업데이트, 볼륨, 백업을 사용자가 관리하며 Home Assistant OS의 앱 기능은 제공하지 않습니다.
아래 명령은 공식 문서의 Container 구성을 단순화한 기존 예시입니다. HA_VERSION에는 확인한 안정 버전을 넣고, 설정 경로는 백업할 수 있는 실제 경로로 바꿉니다. 셸 문법은 bash -n으로 확인했지만 이번 격리 실행에는 --network=host를 사용하지 않았습니다. 운영 네트워크 검색이나 기기 접근을 일으키지 않기 위한 차이입니다.
export HA_VERSION=확인한_안정_버전
docker pull homeassistant/home-assistant:${HA_VERSION}
mkdir -p ~/homeassistant/config
docker run -d --name homeassistant --restart=unless-stopped -v ~/homeassistant/config:/config --network=host homeassistant/home-assistant:${HA_VERSION}
공식 예시는 통합 탐색을 위해 host network를 사용합니다. 적용 전에는 8123 포트 노출 범위, /config 백업, 필요한 장치 매핑을 별도로 결정해야 합니다. 컨테이너가 실행된 뒤에는 http://<host>:8123에서 온보딩을 진행하며, 구성 파일을 바꿨다면 재시작 전에 Home Assistant의 check_config로 문법을 확인합니다.
격리 환경에서 실행 상태를 확인했습니다
검증 환경은 운영 Home Assistant와 분리한 Compose 프로젝트, bridge 네트워크, 전용 볼륨을 사용했습니다. 포트는 127.0.0.1:18123에만 연결했고 host network, 실제 기기 검색, 운영 볼륨은 사용하지 않았습니다.
| 확인 항목 | 격리 환경 결과 | 판정 |
|---|---|---|
| Home Assistant 이미지 | 2026.9.2, 공식 이미지 digest 고정 기록 |
실행 이미지 식별 가능 |
| 컨테이너와 API | 컨테이너 실행, /api/ 응답 확인 |
기동 성공 |
| 구성 검사 | python -m homeassistant --script check_config --config /config 종료 코드 0 |
현재 검증 구성 정상 |
| 네트워크 | 별도 bridge, localhost 포트만 사용 | 운영 탐색 범위와 분리 |
이 결과는 Home Assistant OS나 가상 머신 설치를 실행해 비교한 결과가 아닙니다. Zigbee·Bluetooth 같은 실제 장치 통합, 외부 접속, 장기 안정성도 이번 검증 범위에 포함하지 않았습니다.
엔터티 상태와 자동화 실행을 따로 봅니다
자동화는 트리거가 실행 시점을 정하고, 조건이 실행 여부를 좁히며, 액션이 엔터티를 변경합니다. 아래 기존 예시는 person.example이 home일 때 light.entry를 켜는 구조입니다. 두 엔터티는 교체가 필요한 예시 ID이며, Home Assistant check_config로 YAML 구성을 확인했습니다.
alias: 현관 조명 켜기
triggers:
- trigger: time
at: '19:00:00'
conditions:
- condition: state
entity_id: person.example
state: home
actions:
- action: light.turn_on
target:
entity_id: light.entry
mode: single
실행 검증에는 실제 조명이나 사람 엔터티를 사용하지 않았습니다. 대신 전용 input_boolean.canary_flag를 off로 만든 뒤 최소 자동화를 수동 실행했습니다. API는 HTTP 200을 반환했고, 플래그는 off에서 on으로 바뀌었으며 자동화의 last_triggered 시각도 갱신됐습니다. 실제 기기 제어 없이 트리거 이후 액션과 상태 변경을 확인한 것입니다.
실제 관리 화면에서 상태 변화를 확인합니다
위 이미지는 격리 인스턴스의 Developer Tools 상태 화면입니다. 자동화 엔터티의 last_triggered와 input_boolean.canary_flag의 on 상태를 함께 보여줍니다.
대시보드는 자주 확인하는 엔터티부터 작은 카드로 구성합니다. 화면에 카드가 보인다는 사실만으로 자동화가 성공했다고 판단하지 않고, 엔터티 상태와 자동화 실행 기록을 함께 확인합니다. 실제 장치를 연결할 때는 Settings의 Devices & services에서 해당 통합의 지원 범위와 인증 방식을 먼저 확인합니다.
정상과 조사 필요 상태를 나눕니다
| 단계 | 정상 기준 | 조사할 항목 |
|---|---|---|
| 컨테이너 | running이며 8123 응답 가능 | 컨테이너 로그, 포트 바인딩, 방화벽 |
| 구성 | check_config 종료 코드 0 |
YAML 들여쓰기, 존재하지 않는 통합 설정 |
| 엔터티 | 기대한 상태와 최근 갱신 시각 | 통합 연결, 엔터티 ID, unavailable 상태 |
| 자동화 | last_triggered 갱신과 액션 결과 일치 |
트리거, 조건, 액션 trace를 순서대로 확인 |
컨테이너가 정상이어도 엔터티가 unavailable이면 통합이나 기기 연결 문제일 수 있습니다. 자동화의 last_triggered가 바뀌지 않으면 트리거부터 보고, 시각은 바뀌었지만 상태가 그대로라면 조건과 액션 trace를 확인합니다.
적용 범위를 확인한 뒤 운영 환경으로 옮깁니다
이번 검증은 Home Assistant Container의 기동과 최소 자동화 경로를 확인했습니다. 운영 적용에서는 볼륨 백업, 네트워크 노출, 실제 기기 통합, 업데이트 절차를 환경에 맞게 추가해야 합니다. 공식 설치 절차는 Home Assistant Linux 설치 문서, 구성 검사는 Container common tasks, 자동화 동작은 Automation actions와 automation.trigger에서 확인할 수 있습니다.
관련해서 컨테이너 상태를 먼저 진단하려면 Docker 컨테이너 헬스체크로 장애를 자동 감지하고 재시작하기를 함께 확인합니다.