홈어시스턴트 자동화, 트리거는 됐는데 조명이 안 켜진다면

조건에서 막히는 경우#

조건 항목 왼쪽 상태 표시기에 마우스를 올리면 지금 이 조건이 통과하는지 바로 보이고, 우측 점 세 개 메뉴의 Test로 그 순간 조건을 다시 평가해 볼 수 있습니다. 문제는 트리거가 발생한 순간과 조건이 평가되는 순간이 늘 같지는 않다는 점입니다. 어떤 센서 값이 막 바뀌는 도중에 트리거가 잡히면, 조건은 그 값이 완전히 반영되기 전 상태를 보고 판단할 수 있습니다. 커뮤니티에는 문자열 'true'와 불리언 true를 헷갈려 조건이 항상 거짓으로 평가되는 사례도 자주 올라옵니다. 트레이스에서 조건 단계가 빈 체크로 남아 있다면, Test를 다시 눌러보기 전에 트레이스 안에 저장된 그 실행 당시의 변수값부터 보는 게 순서입니다. 지금 값과 트리거 당시 값이 다를 수 있어서입니다.

모드(mode) 때문에 새 트리거가 버려지는 경우#

자동화에 mode를 따로 적지 않았다면 기본값은 single입니다. 공식 문서는 이 상태에서 이미 실행 중인 자동화가 다시 트리거되면 "새 실행을 시작하지 않고 경고만 남긴다"고 설명합니다(Automation modes). 로그북에는 트리거 이벤트가 그대로 남는데, 자동화 자체는 그 트리거를 무시하고 아무것도 실행하지 않는다는 뜻입니다. 실행 시간이 긴 자동화(조명 페이드, 알림 시퀀스 등)일수록 이 경고를 놓치기 쉽습니다.

restart는 진행 중이던 실행을 끊고 새로 시작하고, queued는 순서대로 쌓아 뒀다가 하나씩 실행하며, parallel은 여러 실행을 동시에 돌립니다. queued와 parallel에는 max 옵션이 있고 기본값은 10인데, 이 한도를 넘기면 로그에 경고가 남되 심각도는 기본이 warning이라, 콘솔을 계속 보고 있지 않은 이상 그냥 지나가 버립니다.

흔히 막히는 지점#

재부팅하고 나서 보니 자동화 목록에 트레이스가 하나도 없다. YAML로 작성한 자동화 여러 개에서 id가 한꺼번에 빠져 있던 사례가 커뮤니티에 올라온 적이 있습니다. id 하나가 없으면 그 자동화만이 아니라 다른 자동화들의 트레이스 저장까지 같이 안 되더라는 보고였습니다. automations.yaml을 열어 id 필드가 전부 들어 있는지부터 봐야 합니다.

자동화를 껐다 켜면 잠깐 되다가 다시 안 된다. mode가 queued나 parallel인 자동화에서 그 안의 특정 액션(예: 미디어 처리, 외부 API 호출)이 느려지며 실행이 계속 쌓이다가, 토글로 자동화를 끄고 켜는 순간 쌓여 있던 큐가 통째로 비워지면서 잠깐 정상으로 돌아온 것처럼 보이는 사례가 있습니다(Automation triggered but not running). 근본 원인은 큐 자체가 아니라 그 안에서 시간이 오래 걸리는 액션 쪽에 있었고, 트레이스 안에 남는 current/max 값으로 큐가 실제로 포화 상태인지를 확인할 수 있었습니다. 토글로 잠깐 낫는다고 문제가 없어진 게 아니라는 뜻입니다.

조건 Test에서는 통과하는데 실제 실행에서는 막힌다. Test 버튼은 누른 순간의 상태로 조건을 다시 평가합니다. 트리거가 발생한 시점과 Test를 누른 시점 사이에 센서 값이 이미 바뀌었다면 결과가 다르게 나올 수 있습니다. 이럴 때는 Test 결과보다 그 실행의 트레이스에 저장된 변수값을 봐야 실제로 무슨 일이 있었는지 알 수 있습니다.

정리#

트레이스 목록이 비어 있으면 id부터, 조건 단계가 빈 체크면 그 조건의 값부터, 실행 자체가 뜸하면 mode부터 봅니다. 자동화가 복잡해질수록 mode는 기본값인 single로 그냥 두기 쉽습니다. 액션이 오래 걸리는 자동화라면 지금 mode부터 한 번 열어 보는 게 순서입니다.