본문으로 건너뛰기
CoderRed Blog

Article

Tapo P110M 재부팅 의심 - 49.7일 경계에서 두 번 끊긴 Matter 로그

게시 읽기6분 분량1252자 작성CoderRed Tapo P110M스마트플러그MatterHome AssistantDebian홈서버재부팅49.7일+2Tapo P110M스마트플러그MatterHome Assistant+6
목차

10월 30일 오전 6시 22분경, 집에서 돌리는 Debian PC가 갑자기 재부팅됐습니다.

PC에는 Tapo P110M 스마트플러그를 달아뒀습니다. 평소 전력량을 측정하고, 비상시에 PC를 재부팅하려고 쓰던 장치입니다.

플러그 기록을 확인했더니 9월에 겪었던 장애와 같은 패턴이 남아 있었습니다. 두 번 모두 약 49.7일에 해당하는 시간 카운터 경계 직전에 계측 보고가 끊겼습니다.

Tapo P110M 에너지 모니터링 스마트플러그 공식 제품 이미지
PC 전원에 연결해 사용 중인 Tapo P110M
이미지 출처: Tapo 공식 제품 페이지. 아래 내용은 제가 사용하는 두 장치의 장애 기록입니다.

9월에도 같은 일을 겪었습니다

처음 비슷한 일이 생긴 건 9월 10일이었습니다. P110M 두 대가 통신을 멈춘 뒤 재부팅됐고, 각각에 연결한 PC도 다시 부팅됐습니다.

당시에는 Matter 로그와 플러그의 가동 시간, PC 부팅 기록을 모아뒀습니다. Tapo 웹사이트의 문의 페이지에도 내용을 남겼지만 피드백은 받지 못했습니다.

이번에 같은 장치에서 다시 장애가 발생하니, 보관해둔 기록부터 비교하게 됐습니다.

두 번 모두 49.7일 경계에서 기록이 끊겼습니다

Matter로 받은 에너지 계측 기록에는 측정 구간이 끝난 시점을 나타내는 시간 값이 있습니다. 9월과 이번 기록 모두 마지막 값이 2^32밀리초 바로 앞에 있었습니다. 시간으로 바꾸면 약 49.7일입니다.

32비트 밀리초 타이머를 쓴다면 이 시점에 값이 한 바퀴 돕니다. 그래서 시간 카운터가 순환하는 순간을 제대로 처리하지 못한 건지 의심하고 있습니다. 실제 P110M 펌웨어가 어떤 자료형과 코드를 쓰는지는 제조사 확인이 필요합니다.

장치마다 보고가 끊긴 시각은 달랐습니다. 마지막 시간 값은 모두 같은 숫자 경계 직전에 있었습니다.

이후 두 플러그가 응답하지 않다가 다시 연결됐습니다. 시작 이벤트가 들어왔고, 직접 읽은 가동 시간인 UpTime도 한 시간 미만이었습니다. 이 기록으로 플러그 자체가 최근 재부팅됐음을 확인했습니다.

현재 가장 유력하게 보는 가설은 다음과 같습니다.

[INFERENCE] Tapo P110M의 시간 카운터 경계 처리에 문제가 있어 장시간 가동 후 통신이 멈추고, 이후 플러그가 재부팅되면서 PC 전원도 잠깐 끊겼을 가능성.

다만 플러그 내부의 크래시 기록이나 릴레이 출력 전압을 측정한 자료는 없습니다. Home Assistant도 이 Debian PC 안에서 돌아가므로, PC가 멈춘 동안에는 플러그 상태를 기록할 수 없습니다. 플러그의 재부팅은 확인했지만, 그 과정에서 PC 전원이 실제로 끊겼는지는 별도 계측이 필요합니다.

자동 업데이트를 꺼둔 데도 이유가 있었습니다

저는 자동 펌웨어 업데이트를 꺼두고 1.4.3을 유지하고 있었습니다. 제 환경에서는 펌웨어를 업데이트할 때 플러그가 재부팅되면서 연결된 서버 전원도 끊겼습니다.

이번에 확인해보니 1.4.4가 나와 있었습니다. 한국 공식 다운로드 페이지에 올라온 P110M(KR) V1용 1.4.4 Build 260723의 게시일은 2026년 9월 30일입니다. 변경 내용은 다음과 같습니다.

  • 기기 페이지에 실시간 전류·전압 표시 기능 추가
  • 특정 사용 환경에서 전력 소비량이 비정상적으로 높게 나타나는 문제 수정
  • 기기 안정성과 보안 강화

공개 설명에는 49.7일이나 2^32ms 경계, 예기치 않은 재부팅을 수정했다는 언급이 없습니다. 안정성 개선에 이번 문제가 포함됐는지는 아직 알 수 없습니다.

정리하면

비상시에 PC를 재부팅하려고 달아둔 장치인데, 이제는 플러그 자체가 전원 안정성에 영향을 주는 건 아닌지 걱정하게 됐습니다. 두 번 비슷한 장애를 겪으니 스마트플러그를 계속 쓸지, 다른 제품으로 바꿀지도 고민하고 있습니다.

우선은 1.4.3에서 1.4.4로 직접 업데이트한 뒤 같은 오류가 다시 발생하는지 지켜보려고 합니다. 이 글은 업데이트 전의 장애 기록입니다. 새 펌웨어를 적용한 결과는 앞으로 확인할 계획입니다.

상세 기록

아래에는 비교에 쓴 수치와 조회 방법을 모았습니다. 시각은 모두 한국시간(KST)입니다.

어떤 환경에서 확인했나요?

공식 제품 설명에 따르면 P110M은 Matter 연결, 에너지 모니터링, 원격 전원 제어를 지원합니다. 현재 Home Assistant 장치 레지스트리에서 확인한 연결은 다음과 같습니다.

  • Matter node 1: Debian PC 전원을 공급하는 P110M
  • Matter node 2: BC250 전원에 연결한 P110M

Home Assistant OS는 Debian PC 안의 libvirt VM에서 실행됩니다. 이번에는 Matter 서버 로그, recorder DB에 저장된 상태 이력, 플러그에서 직접 읽은 진단 속성을 대조했습니다.

9월 10일 자료에 남은 Matter 하드웨어 버전은 1.0입니다. 당시 SmartThings 장치 레지스트리의 펌웨어 표시는 1.4.3 Build 260526 Rel.224153, Matter Basic Information의 소프트웨어 표시는 66304 / 1.3.0이었습니다. 같은 시점에도 표시 경로에 따라 값이 달랐습니다. 이번 장애 때도 저는 펌웨어를 1.4.3으로 유지하고 있었습니다.

TP-Link 직원의 공식 공지에는 P110M/P110MA V1.0의 1.4.4 Build 260723 Rel.025417이 나와 있습니다. 이 공지도 전류·전압 표시 기능을 설명하며, 이번 재부팅 문제의 수정 여부는 밝히지 않습니다.

마지막 계측 값은 어디에서 멈췄나요?

에너지 계측 이벤트의 endSystime은 측정 구간이 끝난 시점을 나타내는 값입니다. Electrical Energy Measurement 데이터 모델은 이 필드를 systime-ms 타입으로 정의합니다.

2^32 ms = 4,294,967,296 ms
        ≈ 49.71027일
        ≈ 49일 17시간 2분 47초
사건장치마지막 계측 수신 시각마지막 endSystime2^32ms까지 남은 시간
9월 10일플러그 A13:05:14.4954,294,956,967ms10.329초
9월 10일플러그 B13:01:36.8174,294,946,986ms20.310초
10월 30일Debian PC 플러그06:12:04.5934,294,956,807ms10.489초
10월 30일BC250 플러그06:13:45.6364,294,960,832ms6.464초

9월 자료의 수신 시각은 표에서 밀리초 자리까지만 표시했습니다. 남은 시간은 4,294,967,296 - endSystime으로 계산한 값입니다. 실제로 경계를 통과하는 순간의 로그는 확보하지 못했습니다.

9월 기록에서는 추정한 경계와 플러그 재부팅 사이에 장치별로 약 4분, 약 8분 50초의 간격이 있었습니다. 10월에도 마지막 계측 보고와 PC 장애 사이에 몇 분의 간격이 있습니다. 경계 직후 바로 리셋됐다고 볼 수는 없습니다.

10월 30일에는 어떤 순서로 기록됐나요?

시각(KST)확인한 내용
06:12:04.593Debian PC 플러그의 마지막 에너지 계측 보고
06:13:45.636BC250 플러그의 마지막 에너지 계측 보고
06:16:49Debian PC 플러그의 저장 상태가 ON → unavailable로 변경
06:18:28BC250 플러그의 저장 상태가 OFF → unavailable로 변경
약 06:22Debian PC 비정상 재부팅 발생 시각
06:24:20두 플러그의 basicInformation.startUp, bootReason=0, 작은 endSystime 값 수신
06:24:25저장 상태가 Debian PC 플러그 ON, BC250 플러그 OFF로 복귀
07:20:16두 장치의 General Diagnostics 속성을 직접 읽음

Matter 로그에도 두 장치의 offline 기록이 있습니다. 복구 후 받은 endSystime에는 약 53004ms, 54143ms처럼 작은 값이 있었습니다.

BC250 플러그의 출력 상태는 장애 전후 모두 OFF였습니다. 부하로 나가는 출력이 꺼져 있어도 플러그 전자회로는 동작하므로 계측과 통신 기록이 남습니다.

unavailable은 Home Assistant가 장치 상태를 확인할 수 없다는 뜻입니다. OFF 명령이 실행됐는지는 이 상태 이력만으로 알 수 없습니다. 복귀 전후의 ON/OFF 값만으로는 중간에 릴레이가 열렸는지, 아주 짧은 전원 차단이 있었는지 알 수 없습니다.

플러그 재부팅은 어떻게 확인했나요?

07:20:16 KST에 General Diagnostics를 직접 읽었습니다.

장치UpTimeRebootCountBootReason
Debian PC 플러그3,433초80 · Unspecified
BC250 플러그3,440초60 · Unspecified

UpTime은 가동 시간입니다. 조회 시각에서 이 값을 빼면 Debian PC 플러그의 부팅 시각은 약 06:23:03, BC250 플러그는 약 06:22:56으로 역산됩니다. 조회·통신 지연과 초 단위 값의 오차가 포함된 추정치입니다.

06:24:20은 Home Assistant가 시작 이벤트를 받은 시각입니다. Home Assistant를 실행하는 PC도 재부팅됐으므로 실제 플러그 부팅 시각과 차이가 있습니다. 호스트 장애 시각도 약 06:22로 파악한 상태라, 이 자료만으로 전원 변화를 초 단위로 맞추기는 어렵습니다.

RebootCount는 누적 카운터입니다. 이번 장애에서 각각 8번, 6번 재부팅됐다는 뜻으로 해석할 수는 없습니다.

BootReason=0은 Matter General Diagnostics 정의에서 Unspecified, 즉 원인을 특정하지 못했다는 값입니다. 전압 저하, 소프트웨어 워치독, 하드웨어 워치독에는 별도 값이 있습니다. 두 장치가 보고한 값은 모두 0이었습니다.

조회 과정에서 무엇을 했나요?

이번 조사에서는 저장된 기록과 읽기 전용 속성 조회만 사용했습니다.

  • HAOS의 이전 부팅과 현재 부팅에서 app_core_matter_server 로그 확인
  • Home Assistant recorder DB를 mode=ro로 열어 기존 상태 이력에 SELECT 수행
  • Matter 서버의 read_attribute로 General Diagnostics 조회

General Diagnostics의 경로는 endpoint 0, cluster 51 기준입니다. 0/51/1은 RebootCount, 0/51/2는 UpTime, 0/51/4는 BootReason입니다.

Supervisor proxy의 이력 조회가 401로 거부돼 기존 recorder DB를 읽었습니다. 인증 값은 출력하지 않았고, 조사를 마친 뒤 HAOS 진단 콘솔도 종료했습니다. 전원 제어, 펌웨어 업데이트, 자동화 변경은 하지 않았습니다.

주기적인 전원 차단으로 카운터를 초기화하면 문제를 피할 수 있는지, 소프트웨어 재부팅 중 부하 전원이 유지되는지는 확인하지 않았습니다. 운영 중인 PC의 전원에 연결된 장치라 그런 실험은 하지 않았습니다.

확보한 기록은 경계 직전의 계측 보고, offline·unavailable 상태, 복구 후 시작 이벤트와 짧은 가동 시간, 누적 재부팅 횟수입니다. 플러그 내부 크래시 기록, 리셋 원인 레지스터, 릴레이 출력 전압 파형은 없습니다. 외부 제어 경로 전체를 확인할 OFF 명령 감사 로그도 없어 다른 전원·제어 원인을 모두 배제할 수는 없습니다.

현재 자료만으로 Matter 표준 전체의 결함이라고 판단할 근거도 없습니다. 정확한 원인을 확인하려면 제조사가 카운터 경계 처리, 리셋 원인, 재부팅 중 부하 전원 유지 여부를 분석할 수 있는 자료가 필요합니다.

참고 자료

댓글