귀가 자동화가 늦게 반응하던 이유
집에 도착하면 조명을 켜고 맥미니에서 인사를 들려주는 자동화를 만들어봤습니다. 조명과 음성을 각각 실행하는 것보다 까다로웠던 부분은 귀가 시점을 Home Assistant에 전달하는 일이었습니다. 휴대전화는 이미 집 Wi-Fi에 연결됐는데 자동화가 몇 분 뒤에 실행되는 경우가 있었습니다.
이 글에서는 Home Assistant와 맥미니를 연결한 구성부터, 위치 보고가 들어오지 않거나 늦게 도착하던 문제를 정리합니다.
Home Assistant VM과 맥미니 음성 연결
Home Assistant OS는 맥미니의 VirtualBox VM에 설치했습니다. 맥미니에서 다른 작업도 실행하고 있어 VM의 자원과 실행 상태를 따로 관리하는 구성으로 시작했습니다. 필요한 커뮤니티 통합은 HACS로 추가했습니다.
Home Assistant는 센서와 조명을 다루고, 맥미니는 AI 호출과 음성 재생을 맡습니다. VM에서 호스트 스피커를 직접 사용하는 대신, SSH로 맥미니의 명령을 실행하도록 연결했습니다.
SSH 키 파일 권한과 접속 주소도 이 구성의 일부입니다. 호스트 주소가 바뀌면 연결 설정을 맞춰야 하고, AI 응답에서 실행 로그를 제외한 문장만 음성에 전달해야 합니다. AI 호출 형식을 바꾸며 음성 연결까지 수정한 내용은 출력과 로그 분리 글에 정리했습니다.
집 밖에서의 위치 보고 문제
처음에는 외출해도 Home Assistant가 계속 집에 있는 것으로 판단했습니다. 서버를 집 안에서만 접속할 수 있게 열어 두었기 때문에, 밖에 있는 휴대전화가 바뀐 상태를 서버로 보낼 수 없었습니다.
외부 접속 경로와 프록시 설정을 구성한 뒤 휴대전화의 위치 보고를 다시 확인했습니다. 당시 만든 외부 접속 방식은 이후 서비스가 늘면서 바뀌었습니다. 그 변경 과정은 홈서버 외부 접속 글에서 따로 다룹니다.
귀가 조건에는 GPS 외에 집 Wi-Fi 연결도 추가했습니다. 하지만 Wi-Fi를 조건에 넣었다고 자동화가 바로 실행되지는 않았습니다.
Wi-Fi 연결과 센서 보고 사이의 지연
휴대전화가 집 Wi-Fi에 연결되는 시각과 Home Assistant가 그 상태를 전달받는 시각은 다를 수 있습니다. 제 환경에서는 앱이 백그라운드에서 센서 상태를 보내는 것이 늦어 자동화도 뒤늦게 실행됐습니다.
iPhone 단축어에서 집 Wi-Fi 연결을 조건으로 잡고, Home Assistant의 센서 업데이트를 호출하도록 바꿨습니다. Companion 앱은 단축어에서 센서 정보를 서버로 보내는 Update sensors 동작을 제공합니다.
설정은 다음 순서로 구성했습니다. 메뉴 이름은 iOS와 Companion 앱 버전에 따라 다를 수 있습니다.
- 단축어의 개인용 자동화에서 집 Wi-Fi 연결을 실행 조건으로 지정합니다.
- Home Assistant의 센서 업데이트 동작을 추가합니다.
- 확인 질문 없이 실행하도록 설정합니다.
- 집 Wi-Fi에 연결한 뒤 Home Assistant에서 상태 갱신과 조명·음성 실행을 확인합니다.
이렇게 바꾼 뒤 제 환경에서는 귀가 자동화의 반응이 빨라졌습니다. 휴대전화의 상태 감지, 서버로 상태를 보내는 과정, 서버에서 자동화를 실행하는 과정을 나눠 확인한 것이 도움이 됐습니다. 조명 실행이 늦더라도 조명 제어 전에 센서 보고부터 확인할 필요가 있었습니다.
지연이 발생한 구간 찾기
귀가 자동화가 늦으면 처음에는 조명이나 음성 실행 시간을 의심하기 쉽습니다. 하지만 서버가 아직 귀가 상태를 받지 못했다면 뒤쪽 작업을 바꿔도 빨라지지 않습니다. 확인할 시각을 다음처럼 나누면 어느 구간을 볼지 정할 수 있습니다.
| 시각 | 확인 위치 | 알 수 있는 것 |
|---|---|---|
| 휴대전화의 Wi-Fi 연결 | iPhone·단축어 | 로컬 연결 감지 |
| 센서 상태 갱신 | HA 개발자 도구의 상태 | 서버가 받은 값 |
| 자동화 실행 | 자동화 Trace·로그북 | 조건을 통과한 실행 |
| SSH 실행 | 맥미니의 작업 로그 | 호스트에 도착한 명령 |
| 음성 재생 | 실제 스피커 | 최종 동작 |
예를 들어 센서 값은 제때 바뀌었는데 Trace가 없다면 실행 조건을 확인합니다. Trace는 있는데 SSH 로그가 없다면 연결과 키·명령 경로를 봅니다. SSH 실행이 끝났는데 음성이 없다면 응답의 text 추출과 재생 장치 쪽을 확인합니다. 이 순서는 원인을 좁히는 절차이며 각 구간의 지연 시간을 측정한 수치를 뜻하지 않습니다.
음성 자동화와 무관하게 SSH 연결만 먼저 확인할 때는 음성을 재생하지 않는 명령을 사용할 수 있습니다. 아래는 주소와 계정을 바꿔 사용하는 연결 확인 예시입니다.
ssh -o BatchMode=yes -o ConnectTimeout=5 \
-i /path/to/ha_ssh_key \
USERNAME@MAC_HOST 'printf "ssh-ready\n"'이 결과가 정상이어도 실제 AI 호출과 음성까지 확인된 것은 아닙니다. 다음에는 자동화가 사용하는 동일한 실행 경로와 계정으로 호출하고, 최종 문장이 재생되는지 봅니다. 대화형 터미널에서만 준비한 PATH나 권한이 필요한 명령이면 SSH 경로에서 다르게 동작할 수 있습니다.
Wi-Fi 재연결과 중복 실행
Wi-Fi 연결은 귀가의 단서이지만, 집 안에서 공유기 연결이 잠깐 끊겼다가 돌아오는 경우도 있습니다. 센서 업데이트를 호출하는 단축어와 실제 인사를 실행하는 자동화를 분리해 두면, 업데이트 자체를 귀가 메시지로 취급하지 않고 HA의 현재 상태와 조건을 보고 결정할 수 있습니다.
예를 들어 조명에는 해가 진 뒤라는 조건을 적용하면서 인사는 다른 조건을 사용할 수 있습니다. 모든 동작을 긴 명령 하나로 연결하면 어느 조건에서 무엇이 생략됐는지 보기 어렵습니다. 실제로 자동화가 호출한 서비스는 Trace에서 확인하고, 서비스 이름에 예전 모델명이 남아 있다고 현재도 그 모델을 쓰는 것으로 판단하지 않았습니다.
휴대전화 센서 갱신은 Companion의 단축어 동작 을 이용했습니다. 당시 해결한 것은 제 환경에서 상태 보고가 늦던 문제입니다. 다만 휴대전화의 절전 설정이나 백그라운드 실행 상태에 따라 반응 시간은 달라질 수 있습니다.