요금 잔액 Home Assistant 연동하다 3006 미신뢰 기기 오류

전기요금 고지서를 Home Assistant에 연동한 뒤, 제가 자연스럽게 다음으로 나아간 단계는 온 가족 휴대폰의 요금 잔액과 일반 데이터를 가정 개요 대형 화면에도 올려놓는 것이었습니다.

커뮤니티 플러그인을 찾아 휴대폰 번호와 통신 서비스 비밀번호를 입력하고 제출을 눌렀습니다. 저를 기다린 것은 깔끔한 잔액 차트가 아니라, 차가운 한 줄의 오류 메시지였습니다. resultCode 3006, 기기 미신뢰.

커뮤니티 논의를 찾아보니 어떤 이는 게이트웨이 무비밀번호 방식을 쓰라고 권했고, 어떤 이는 심지어 휴대폰 번호와 서비스 비밀번호, SMS 인증 코드를 제3자의 정체불명 역프록시 호스팅 사이트에 제출하라고 추천하기까지 했습니다. 통신 업무의 핵심 통제권을 쥔 서비스 비밀번호를 낯선 서버에 중계시키라고요? 가정 프라이버시와 기반 보안을 중시하는 사람이라면 결코 건드려서는 안 되는 선입니다.

그래서 오늘 저는 로컬 AI Agent에게 중국전신 공식 로그인 프로토콜 체인을 철저히 분해하게 했습니다. 패킷 캡처로 가정용 광대역 무비밀번호 방식이 왜 실패하는지 검증하는 것부터, 오직 로컬 메모리에서만 실행되고 외부 클라우드 의존이 전혀 없는 LAN 인증 도구를 직접 만드는 것까지, 오프스크린 Canvas 픽셀 스캔으로 슬라이더 퍼즐의 기하학적 드리프트 함정을 공략하는 것부터, Home Assistant 통합의 생명주기를 재구성해 최초 갱신 시의 크래시와 동시성 경쟁 상태를 해결하는 것까지 말입니다.

이것은 꼬박 하루가 걸린 소프트웨어·하드웨어와 프로토콜의 공방 실록입니다.

그림 1: 본문 창작 삽화. 통신사 3006 차단 분석, 로컬 제로 클라우드 인증 아키텍처, 그리고 Home Assistant에 두 장의 휴대폰 SIM을 우아하게 연동하는 전 과정을 아우른다.

一. 요구 배경: 가정 디지털 자산의 마지막 조각

현대 가정에서 전기요금, 수도요금, 가스요금, 통신요금은 함께 가정 운영의 기초 소비 장부를 구성합니다. 지난번 온라인 국가전망(网上国网) 전기요금을 Home Assistant에 연동하는 데 성공한 데 이어, 가정 대형 화면은 이제 매일의 전력 소비와 전기요금 잔액을 직관적으로 표시할 수 있게 되었습니다.

그러나 매달 휴대폰 요금제의 지출 역시 무시할 수 없는 비용입니다. 특히 광대역 결합 주부카 온 가족 묶음 요금제를 개설했다면, 주카드는 매달 고정 요금제 비용이 차감되고 부카드는 일반 고속 데이터를 공유합니다. 어떤 달에 데이터가 초과되어 요금이 발생하거나, 계정 잔액이 부족해 연체 정지가 되면, 광대역 네트워크와 가정 네트워크가 모두 직접적인 타격을 받습니다.

제가 달성하고자 하는 목표는 매우 명확합니다:

- Home Assistant의 내 집 개요 패널에 휴대폰 요금제 전용 구역을 따로 마련한다.

- 각 번호의 통신 계정 잔액, 당월 실제 소비, 남은 일반 데이터, 사용한 데이터, 남은 통화 분 수를 실시간으로 표시한다.

- 데이터 사용이 90%를 초과하거나 잔액이 경고값 미만일 때, 가정 자동화 음성 안내와 푸시 알림을 발동한다.

우리는 커뮤니티에서 주류로 쓰이는 통신 통합 컴포넌트를 선택했습니다. 통합 설정 화면에 휴대폰 번호와 6자리 서비스 비밀번호만 입력하면 끝날 줄 알았지만, 현실은 대개 첫 단계에서부터 정통으로 머리를 한 대 때립니다.

二. 문제 양상: 3006 기기 미신뢰와 흔적도 없이 사라진 엔티티

설정 저장을 누르자 Home Assistant 프런트엔드에 곧바로 빨간 느낌표가 튀어나왔습니다. 알 수 없는 오류. 백엔드 로그로 들어가 확인하니, 터미널에 통신 게이트웨이의 실제 차단 응답이 또렷하게 찍혀 있었습니다:

2026-10-26 15:42:11.890 ERROR (MainThread) [custom_components.china_telecom.api] Telecom login failed: resultCode=3006, resultMsg=设备未信任, deviceId=None

로그인이 거부된 것뿐만 아니라 더 이상한 점은, Home Assistant 엔티티 레지스트리를 열어보니 해당 통합에 관한 센서 개수가 무려 0이라는 것이었습니다.

그림 2: Home Assistant 핵심 로그 실제 스크린샷. 오류 코드 3006은 통신 서버 측이 기기 신뢰도 검증을 수행했음을 보여주며, 구버전 통합이 예외로 중단되어 엔티티가 완전히 등록을 완료하지 못했음을 나타낸다.

이는 이중 타격을 구성합니다. 첫째, 통신 서버 측이 미인증 기기가 서비스 비밀번호만으로 민감한 재무 데이터를 조회하는 것을 명확히 거부합니다. 둘째, 오픈소스 통합이 설계상 결함을 안고 있어, setup 초기화 단계에서 곧바로 블로킹 새로고침을 실행하고 새로고침이 실패하면 즉시 잡히지 않은 예외를 던져, 본래 생성되어야 할 18개의 센서 엔티티가 자리표시자 하나조차 남기지 못하게 됩니다.

오픈소스 커뮤니티 Issues를 살펴보면 많은 사용자들이 이에 속수무책이며, 어떤 이들은 정체불명의 개인이 만든 'DeviceId 번호 생성 인증 도구 사이트'로 안내받기까지 합니다.

三. 초등학생도 단번에 이해하는 비유: 은행 창구, 구두 비밀번호, 전용 출입 보안 칩 카드

컴퓨터 저층부에 익숙하지 않은 어린이를 포함해 모든 사람이 이면의 논리를 철저히 이해할 수 있도록, 아주 생생한 생활 비유를 하나 들어보겠습니다:

통신사의 서버가 삼엄하게 경비된 은행 금고라고 상상해 보세요. 금고 안에는 여러분 집 휴대폰 번호의 모든 청구 자산이 들어 있습니다.

- 서비스 비밀번호는 구두 암호와 같습니다. 그것은 6자리밖에 안 되는 단순한 숫자열입니다. 초등학생이라도 옆에서 누군가 엿듣거나 비밀번호를 추측하기만 하면 쉽게 여러분을 사칭할 수 있다는 것을 압니다. 구두 암호만으로 창구에서 청구서와 명세를 빼낼 수 있다면, 은행 창구 직원은 반드시 간담이 서늘할 것입니다.

- SMS 인증 코드는 현장 대기표와 같습니다. 은행 창구 직원이 여러분 앞에서 여러분의 휴대폰으로 6자리 난수가 찍힌 일회용 번호표를 보냅니다. 여러분은 휴대폰을 몸에 지니고 직접 번호표를 확인해 창구 직원에게 건네야 합니다. 이것은 여러분 본인이 지금 이 자리에 실제로 있음을 증명합니다. 그러나 문제는, 스마트홈이 매시간 잔액을 조회해야 하는데, 매시간 여러분 휴대폰으로 문자를 보내 잠을 깨울 수는 없다는 것입니다.

- 인증 기기 식별자 DeviceId는 은행이 발급하는 전용 출입 보안 칩 카드와 같습니다. 여러분이 직접 구두 암호와 대기표를 들고 창구에 한 번 다녀오고, 창구 직원이 본인임을 확인한 뒤, 하드웨어로 암호화된 전용 출입 보안 칩 카드를 여러분의 Home Assistant에 발급합니다. 이후 Home Assistant는 이 칩 카드를 대고 구두 암호를 덧붙이기만 하면, 창구 직원은 이것이 주인이 직접 승인한 가정 관리자 기기임을 알고 안전하게 통과시켜 줍니다!

- 오류 3006의 본질: Home Assistant가 막 설치되었을 때는, 마치 빈손의 낯선 사람이 은행 창구로 달려가 구두 암호 한마디만 외친 것과 같습니다. 창구 직원은 즉시 경보를 울리며 외칩니다. 기기 미신뢰! 당신의 전용 출입 보안 칩 카드는 어디에 있습니까?

그림 3: 창작 개념 도해. 구두 암호, 대기표, 전용 출입 보안 칩 카드로 통신 서비스 비밀번호, SMS 인증 코드, DeviceId의 신뢰 사슬을 알기 쉽게 풀어낸다.

다시 말해, Home Assistant가 지속적으로 데이터를 조회할 특권을 얻기 위한 핵심은 바로 합법적이고 규정에 맞게 공식 신뢰 바인딩을 한 차례 완료하여 여러분의 기기에 이 DeviceId 출입 카드를 획득해 주는 데 있습니다.

四. 함정 점검 一: 가정용 광대역의 무비밀번호 로그인 시도는 왜 반드시 실패하는가?

해결책을 찾을 때 우리가 가장 먼저 떠올린 지름길은 이것이었습니다. 통신 앱은 원클릭 무비밀번호 로그인을 지원하지 않던가? 통신 오픈 플랫폼에도 톈이(天翼) 무로그인 게이트웨이가 있다. 게이트웨이로 직접 번호를 취득해 문자를 보내지 않고도 자격 증명을 얻을 수 있지 않을까?

이런 구상을 가지고 Agent는 게이트웨이 탐지 스크립트를 작성해 중국텔레콤 모바일 클라이언트의 요청을 모방했다. 접속 대상은 open.e.189.cn의 autoLogin 인터페이스로, getPreMobileUrl.do를 호출한다. 식별을 피하기 위해 우리는 HTTP 요청 헤더에서 네트워크 방식을 셀룰러로 위장하기도 했다.

그러나 서버가 반환한 페이지는 찬물을 끼얹었다. “현재 환경에서는 비밀번호 없는 로그인을 지원하지 않습니다.”

그림 4: 실제 휴대폰 브라우저와 프로브 스크린샷. 네트워크 환경을 위장했음에도 가정용 광대역은 여전히 텔레콤의 비밀번호 없는 로그인 감지를 통과할 수 없었다.

근본 원인 분석: 비밀번호 없는 로그인의 본질은 통신사 기지국이 휴대폰 SIM 카드 하드웨어 칩에 대해 직접 수행하는 RADIUS/AAA 인증이다. 휴대폰이 4G 또는 5G 이동 셀룰러 네트워크에 있을 때는 기지국의 데이터 링크 계층이 SIM 카드의 IMSI와 물리 키를 직접 인지한다. 그러나 컴퓨터나 휴대폰이 집의 WiFi 광대역에 연결되면 데이터 패킷은 광모뎀, EPON/GPON 광섬유, 이더넷 프로토콜을 거쳐 간다. 통신사 접속망은 광대역의 PPPoE 계정만 인식하며, 물리적으로 SIM 카드 채널이 아예 존재하지 않는다! 서버가 하위 계층의 셀룰러 인증 헤더를 감지할 수 없으니 당연히 비밀번호 없는 자격 증명 발급을 거부하는 것이다.

결론: 가정용 광대역을 이용해 비밀번호 없이 번호를 얻겠다는 환상은 버리고, 표준 공식 인증 코드와 문자 메시지 챌린지 절차를 정면으로 마주해야 한다.

五, 함정排查 2: 제3자 클라우드 호스팅 대행 인증의 치명적 보안 함정

GitHub와 각종 스마트홈 포럼에서 일부 작성자들이 임시 제3자 Web 도구를 제공하며, 휴대폰 번호만 입력하면 원클릭으로 DeviceId를 얻을 수 있다고 홍보했다.

우리는 보안 감사 단계에서 이러한 경로를 단호히 배제했다.

그림 5: 자체 제작 보안 아키텍처 비교도. 왼쪽의 제3자 리버스 프록시는 심각한 프라이버시 유출과 크리덴셜 스터핑 위험이 존재하고, 오른쪽의 자체 개발 로컬 메모리 도구는 종단 간 안전 폐쇄 루프를 구현한다.

제3자 대행 인증 도구에 숨어 있는 거대한 위험을 살펴보자:

- 크리덴셜 스터핑과 권한 상승 위험: 일반 사용자의 텔레콤 서비스 비밀번호는 보통 6자리 순수 숫자이며, 많은 사람이 편의를 위해 가족의 각 부가 카드 심지어 은행 조회 비밀번호까지도 매우 유사하게 설정한다. 일단 제3자 서버가 당신의 휴대폰 번호와 서비스 비밀번호를 기록하면, 해커가 크리덴셜 스터핑 공격을 하기 매우 쉬워진다.

- 문자 메시지 차단과 부가 서비스 가입: 인증 과정에서 문자 인증 코드를 입력해야 한다. 문자 인증 코드는 텔레콤 체계 내에서 최고 권한을 가지며, 유료 요금제 개설, 실명 업무 변경 등에 사용될 수 있다. 실시간 문자 인증 코드를 제3자 서버에 넘겨 전달하게 하는 것은 자신의 통신 속내를 남에게 다 내주는 것과 같다.

- 자격 증명의 지속적 기록: 생성된 DeviceId는 장기 유효한 신뢰 기기 식별자다. 만약 제3자 플랫폼이 DeviceId를 몰래 디스크에 저장한다면, 상대방은 이후 언제든지 당신의 신뢰 기기 신분으로 로그인을 시작할 수 있다.

가정 자동화의 핵심 전제는 안전과 자기 통제다. 우리는 절대로 대시보드에서 요금 한 번 보겠다고 온 가족의 통신 보안을 낯선 서버의 인품에 걸어서는 안 된다.

유일하게 올바른 엔지니어링 경로: 완전히 본机에서 실행되고 오직 공식 189.cn과만 통신하는 순수 로컬 인증 도구를 직접 만들자!

六, 심층 트러블슈팅: 슬라이더 퍼즐 정렬 미스터리와 오프스크린 Canvas 픽셀 스캔

방향이 명확해진 후, Agent는 중국텔레콤 공식 클라이언트 로그인 프로토콜 체인을 재현하기 시작했다:

- 공식 도메인: appgologinsz.189.cn 및 appfuwu.189.cn

- 프로토콜 흐름: 먼저 getLoginRandomCode를 호출해 RSA 랜덤 솔트를 획득하고, 이어서 getSliderVerificationPicture를 호출해 동적 슬라이더 퍼즐을 요청하며, 슬라이더를 드래그해 검증을 통과하면 문자 메시지가 발송되고, 마지막으로 userLoginNormal을 통해 문자 인증을 완료하고 DeviceId를 추출한다.

그러나 로컬 Web 인터페이스를 개발하던 중, 매우 기이한 프런트엔드 현상이 나타났다. 사용자가 인터페이스에서 슬라이더를 직접 드래그해 육안으로 보기에 퍼즐이 배경의 홈에 조금도 어긋남 없이 들어간 것 같아도, 문자 발송을 클릭하면 공식 인터페이스는 빈번히 “인증 코드 오류 또는 슬라이더 위치 불일치!”를 반환했다.

그림 6: 자체 제작 기술 세부 분석. 텔레콤 퍼즐 이미지 가장자리에 투명 여백이 존재해 직관적 매핑은 심각한 좌표 드리프트를 초래한다. 오프스크린 Canvas로 비투명 픽셀을 스캔해 픽셀 단위 정렬을 성공적으로 구현했다.

Agent는 즉시 systematic-debugging을 실행해 심층排查에 들어갔고, 마침내 원인을 찾아냈다: 텔레콤 인터페이스가 내려주는 슬라이더 퍼즐(slider_piece) PNG 이미지는 촘촘하게 잘라낸 것이 아니다! 이미지 자체의 캔버스 너비는 150픽셀일 수 있지만, 실제로 색이 있는 퍼즐 조각은 중간의 44픽셀 범위에만 위치하며 주변은 전부 완전히 투명한 Alpha 여백 채널로 둘러싸여 있다!

만약 프런트엔드 개발자가 게을러서 슬라이더의 0에서 100을 곧바로 전체 이미지의 left 좌표로 매핑하면, 슬라이더가 계산한 좌표는 투명 캔버스 원점을 기준으로 하는 반면 육안으로 맞추는 것은 중간의 불투명 조각이다. 둘 사이에는 무려 18에서 30픽셀에 달하는 물리적 편차가 존재한다!

해결책: 우리는 프런트엔드에 지능형 오프스크린 Canvas 스캔 알고리즘(opaqueBounds)을 구현했다:

- 메모리에 보이지 않는 Canvas를 생성하고 퍼즐을 그린다.

- getImageData를 통해 모든 픽셀의 RGBA 원시 바이트 배열을 가져온다.

- 각 픽셀의 Alpha 투명도 채널을 순회하며, Alpha가 128보다 클 때만 유효한 실체 픽셀로 판정해 불투명 조각의 정확한 외접 사각형(bounds.left, bounds.top, bounds.width)을 동적으로 계산한다.

- 실제 슬라이딩 총 이동량을 계산한다: travel = background.naturalWidth - bounds.width.

- 최종 슬라이드 오프셋 환산 공식: nativeLeft = normalizedDistance * travel - bounds.x.

- 여기에 클라이언트의 현재 뷰포트 스케일 비율 scale = background.clientWidth / background.naturalWidth를 곱한다.

이 엄밀하고 정밀한 수학 변환을 거쳐, 슬라이더의 이동과 배경 홈은 물리적 수준으로 빈틈없이 일치했다. 슬라이더를 드래그하면 한 번에 공식 검증을 통과한다!

七, HA 아키텍처 재구성: 엔티티 유실과 다중 계정 동시성 크래시 해결

DeviceId를 얻기 전에, 우리는 돌아가서 Home Assistant 연동 코드의 두 가지 심각한 결함을 철저히 근본적으로 해결했다.

그림 7: Home Assistant 연동 패치 아키텍처도. 18개 엔티티를 사전 등록해 내결함성을 확보하고, 비동기 동시성 잠금을 추가해 다중 계정 프런트엔드 리소스 충돌을 차단한다.

결함 1: 첫 새로고침 실패로 엔티티가 등록되지 않음

구버전 통합 코드에서 async_setup_entry가 가장 먼저 하는 일은 바로 await coordinator.async_config_entry_first_refresh()입니다. DeviceId가 없는 상황에서 이 새로고침은 반드시 3006 예외를 던집니다. 예외는 로딩 함수 전체를 즉시 중단시켜, 뒤에 배치된 async_add_entities는 영영 실행될 기회를 얻지 못합니다! 이로 인해 사용자는 인터페이스에서 영원히 엔티티를 볼 수 없게 됩니다.

수정 로직: 생명주기를 뒤집었습니다. 먼저 조건 없이 18개의 센서 전부를 Home Assistant에 등록하고(이때 상태는 우아하게 unavailable로 표시됨), 이어서 hass.async_create_task를 통해 백그라운드 비차단 새로고침을 트리거합니다. 이렇게 하면 네트워크가 흔들리거나 자격 증명이 미설정 상태여도 모든 엔티티는 등록 테이블에 안정적으로 남아 있으며, DeviceId가 보완되는 즉시 데이터가 핫 로드되어 점등됩니다!

결함 2: 다중 번호 동시 등록 시 프런트엔드 카드로 인한 setup_error

가정에는 흔히 두 장, 심지어 그 이상의 카드가 있습니다. Home Assistant에서 전화번호 두 개를 구성하면 시스템은 재시작 시 두 항목을 동시에 로딩합니다. 구버전 통합은 항목 시작 시 모두 hass.http.register_static_path를 호출해 사용자 정의 카드 리소스를 등록합니다. 상호 배제 보호가 없기 때문에 두 번째 항목이 동일한 경로를 등록할 때 라우트가 이미 존재한다는 치명적 예외를 곧바로 던져, 보조 카드가 영원히 setup_error를 표시하게 됩니다.

수정 로직: Python 모듈 전역에 asyncio.Lock()을 도입하고, 전역 card_registered 플래그를 유지합니다. 첫 번째 계정이 락을 획득해 리소스 등록에 성공하면 플래그를 세우고, 이후 계정은 플래그를 감지하면 안전하게 건너뜁니다. 이제 가정 번호를 몇 개를 추가하든 시스템은 매끄럽게 동시 시작할 수 있습니다!

8. 산출물: 자체 개발 오픈소스 통신 설비 인증 도구

우리는 위의 완전한 프로토콜 체인, 보안 방어 메커니즘과 오프스크린 Canvas 알고리즘을 완전히 로컬에서 실행되는 표준화된 오픈소스 도구로 패키징했습니다: telecom-phone-device-id-tools. 이 프로젝트는 현재 GitHub에 전면 오픈소스로 공개되어 있으며, 즉시 사용 가능한 로컬 서비스 스크립트와 완비된 단위 테스트 세트를 제공합니다.

그림 8: 로컬 Web 인증 도구의 실제 스크린샷. LAN 기기에서 열람 가능하며, 메모리 단기 세션을 사용하고, 통신사 공식 발급의 규정 준수 DeviceId를 안전하게 출력합니다.

이 도구는 다음과 같은 핵심 보안 특성을 갖추고 있습니다:

- 공식 엔드투엔드 직접 연결: 모든 HTTP 요청은 appgologinsz.189.cn, appgologin.189.cn, appfuwu.189.cn으로만 발신이 허용되며, HTTPS 인증서 지문 검증을 강제로 활성화하고 모든 리다이렉트를 금지합니다.

- 순수 메모리 세션 생명주기: 휴대폰 번호, 서비스 비밀번호, SMS 인증 코드, 생성된 DeviceId는 전부 Python 프로세스 메모리에 보관되며, 로그를 남기지 않고, 디스크에 저장하지 않으며, 어떤 서버로도 업로드하지 않습니다.

- LAN 접근 제어: LAN IP 바인딩(--host 0.0.0.0)을 지원하며, 시작 시 터미널에 고엔트로피 랜덤 접근 토큰(Token)을 단 한 번만 출력합니다. 토큰이 없거나 토큰이 잘못된 모든 요청은 일괄 401로 거부됩니다.

- 열람 후 소각 및 타임아웃 파기: 매 인증마다 독립 세션을 사용하며, 단일 인증 완료 후 접근 토큰은 즉시 폐기되고, 세션은 10분 후 강제 만료되어 메모리가 비워집니다.

그림 9: 로컬 자동화 테스트 콘솔 스크린샷. 공식 프로토콜 계약, 세션 만료, 접근 제어와 엔티티 생명주기를 커버하는 53개 단위 테스트가 모두 통과했습니다.

9. 전 플랫폼 원클릭 자동화 세트와 실행 이중 경로

모든 독자가 오늘의 성과를 그대로 재사용할 수 있도록, 전체 도구 체인을 바로 다운로드 가능한 통신 설비 인증 및 통합 영속화 세트로 정리했으며, 세 가지 주요 운영체제에 맞는 스크립트 진입점이 포함되어 있습니다.

이 세트는 전적으로 표준 Python과 각 운영체제 네이티브 Shell에 기반하며, Docker 설치가 필요 없고 어떤 서드파티 유료 또는 자동화 서비스에도 의존하지 않습니다.

방법 1: 수동 파라미터 구성과 스크립트 자동 실행

먼저 로컬에 Python 3.10 이상 환경이 설치되어 있는지 확인하고, 두 개의 공식 암호화 의존 라이브러리를 설치합니다:

pip install requests pycryptodome

터미널에서 비공개로 Home Assistant 접근 주소와 전용 장기 토큰을 내보냅니다(필수 아님, 자동화 검수용):

export HOME_ASSISTANT_URL= "http://<YOUR_HA_IP>:8123" export HOME_ASSISTANT_TOKEN= "<YOUR_LONG_LIVED_TOKEN>"

현재 운영체제에 따라 해당 스크립트를 선택해 실행합니다:

1. macOS 27 진입점

네트워크 연결성과 공식 게이트웨이 상태 점검 ./scripts/telecom_auth_toolkit_macos27.zsh check # 로컬 인증 서비스 시작(휴대폰 LAN 스캔/열람 지원) ./scripts/telecom_auth_toolkit_macos27.zsh serve # 브라우저에서 SMS 인증을 완료한 뒤, HA 엔티티 상태를 읽기 전용으로 확인 ./scripts/telecom_auth_toolkit_macos27.zsh verify

2. Ubuntu 26.04 진입점

실행 의존성과 환경 점검 bash scripts/telecom_auth_toolkit_ubuntu2604.sh check # 로컬 격리 인증 서비스 시작 bash scripts/telecom_auth_toolkit_ubuntu2604.sh serve # 엔티티와 실시간 요금·트래픽 데이터 검증 bash scripts/telecom_auth_toolkit_ubuntu2604.sh verify

3. Windows 11 PowerShell 진입점

시스템 연결성 점검 실행 .\scripts\telecom_auth_toolkit_windows11.ps1 check # 로컬 기기 인증 서비스 시작 .\scripts\telecom_auth_toolkit_windows11.ps1 serve # Home Assistant 엔티티 센서 온라인 상태 검수 .\scripts\telecom_auth_toolkit_windows11.ps1 verify

실행 흐름:

- serve 명령을 실행하면 터미널에 http://192.168.x.x:8765/?token=... 형태의 유일한 비공개 주소가 출력됩니다.

- 같은 WiFi에 연결된 휴대폰이나 컴퓨터 브라우저로 해당 주소를 열고, 휴대폰 번호를 입력한 뒤 슬라이더 가져오기를 클릭합니다.

- 슬라이더를 끌어 홈에 맞춘 뒤 문자 발송을 클릭하고, 수신된 6자리 문자 인증번호를 입력한 뒤 제출을 클릭합니다.

- 페이지가 즉시 중국전신(China Telecom) 공식 발급 전용 DeviceId를 반환합니다. 복사 버튼을 클릭합니다.

- Home Assistant를 열고, 이미 구성된 중국전신 통합 옵션에서 해당 DeviceId를 문자 인증 DeviceId 항목에 붙여넣고 저장합니다.

- 통합이 즉시 다시 로드되고, 18개 센서가 모두 켜집니다!

방법 2: 검수와 구성 작업을 로컬 Agent에 위임하기

로컬 AI 프로그래밍 어시스턴트(예: 명령줄 또는 IDE 기반 Agent)를 사용하는 데 익숙하다면, 아래 표준 작업 설명을 Agent에 그대로 전달할 수 있습니다:

목표: Home Assistant에서 중국전신 통합의 기기 인증과 패널 구축을 완료한다. 원칙: 휴대폰 번호, 비밀번호, 문자 인증번호, 자격 증명을 로그에 기록하거나 외부 네트워크로 업로드하는 것을 엄격히 금지한다. 모든 외부 요청은 HTTPS를 사용해야 하며 189.cn 공식 도메인으로만 한정한다. 단계: 1. 로컬 전신 인증 도구 모음의 check 모드를 실행하여 공식 게이트웨이와 HA API 도달 가능성을 검증한다. 2. serve 서비스를 시작하여 1회성 랜덤 토큰 URL을 출력하고, 사용자가 로컬 브라우저에서 슬라이더와 문자 검증을 직접 완료하기를 기다린다. 3. 생성된 공식 DeviceId를 캡처하여 해당 휴대폰 번호의 HA 통합 options 구성 항목에 안전하게 주입한다. 4. 통합 핫 리로드를 트리거하고, 18개 센서 상태가 unavailable에서 벗어날 때까지 /api/states를 지속적으로 폴링한다. 5. 잔여 트래픽, 요금 잔액, 당월 소비, 통화 시간 필드가 실제 비어 있지 않은 숫자인지 자동 점검한다. 6. Lovelace 개요 대시보드에 '휴대폰 요금제' 카드 구역을 구축하고, 전후 구성 비교 보고서를 생성한다.

이 방식은 자질구레한 API 상호작용, 구성 새로고침, 데이터 검증을 Agent에 맡기고, 자금 안전과 관련된 수동 문자 검증은 자신의 손에 확실히 쥐고 있습니다.

10. 최종 상태 검수: 숫자가 가정용 대형 화면에서 우아하게 흐르도록 하기

두 장의 휴대폰 카드가 각각 인증을 완료한 후, 데이터는 마치 맑은 샘물처럼 Home Assistant로 흘러들어왔습니다.

그림 10: Home Assistant '나의 집' 패널 실제 스크린샷. 요금 잔액, 잔여 범용 트래픽, 당월 소비와 통화 시간이 선명하게 표시된다.

그림 11: Home Assistant 개발자 도구 엔티티 상태 스크린샷. 범용 트래픽, 전용 트래픽, 사용률, 업데이트 시간 등을 아우르는 18개 완전한 센서가 포함된다.

우리는 대시보드 구역을 자동 생성하는 유지보수 스크립트 phone_section.py를 작성했습니다. 앞으로 부가 카드를 추가하든 번호를 교체하든, 스크립트를 한 번 다시 실행하면 china_telecom 엔티티에서 번호 레이블을 자동으로 추출하고 가정 개요에서 우아한 카드 배열을 재구성합니다.

전체 검수 과정을 되돌아보면, 우리는 다음 여섯 가지 완료 지표를 엄격히 준수했습니다:

- 공식 게이트웨이 직결성: 모든 인증은 TLS 인증서로 보증되며, 제3자 중계가 없음;

- 엔티티 완전성: 각 번호마다 18개의 표준 센서를 보존하며, 누락된 필드가 없음;

- 데이터 진실성: 잔액은 분 단위까지, 트래픽은 0.01 GB 단위까지 정확하며, 모의 가짜 데이터가 아님;

- 동시성 안전성: 다중 계정이 Core 재시작 시 직렬화되어 로드되며, setup_error 충돌이 없음;

- 재시작 자가 복구성: HA 재시작 후 구성 내 DeviceId를 자동으로 읽어, 다시 수동으로 문자를 보낼 필요가 없음;

- 프라이버시 제로 유출: 로컬 인증 서비스 프로세스가 종료되면 메모리가 즉시 0으로 돌아가고, 디스크에 민감한 잔여물이 전혀 없음.

그림 12: 독자 제작 트러블슈팅 의사결정 트리 매트릭스. 3006 오류, 슬라이더 변위 편차, 동시성 충돌, 광대역 비밀번호 없는 실패의 진단 로직을 총정리했다.

Q&A: 여러분이 궁금해할 몇 가지 하드코어한 의문

질문: DeviceId를 한 번 획득한 후 유효 기간은 얼마나 되나요? 이후에도 계속 문자를 반복해서 보내야 하나요?

답변: 중국전신 공식 발급 DeviceId는 장기 유효한 신뢰 하드웨어 바인딩 자격 증명에 속합니다. 통신사에서 중대한 리스크 통제 정책 조정이 발생하지 않는 전제하에, 해당 자격 증명은 보통 장기간(수개월에서 수년) 유효합니다. 전신 영업점에서 기기를 주도적으로 해제하지 않는 한, 일상적인 매시간 폴링은 DeviceId와 서비스 비밀번호를 함께 사용하는 것만으로 조용한 인증을 완료할 수 있으며, 다시 수동으로 문자를 받을 필요가 없습니다.

질문: 이미 DeviceId가 있는데, 왜 전신 서비스 비밀번호도 필요한가요?

답변: 앞서 든 은행 비유로 돌아가 봅시다: DeviceId는 출입 카드 칩이고, 서비스 비밀번호는 구두 암호입니다. 전신 v1 조회 인터페이스는 둘을 동시에 제시하도록 요구하여, 하드웨어 식별자만 보유한 부정 결제 행위를 방지합니다. 두 층의 보호는 서로를 보완합니다.

질문: 이 로컬 도구는 중국이동(China Mobile)이나 중국연통(China Unicom)을 지원하나요?

답변: 본 프로젝트는 중국전신 통합 특유의 3006 기기 미신뢰와 슬라이더 문자 프로토콜 체인 문제 해결에 집중합니다. 중국연통의 경우, 커뮤니티 방안은 보통 위챗 미니프로그램의 OpenID 패킷 캡처에 의존합니다; 중국이동의 경우, 현재 우리는 순수 HTTP 패킷 캡처로 autoLogin 세션에 접속하는 방식을 구현했습니다. 세 통신사의 보안 인증 체계는 각기 다릅니다.

질문: 왜 도구는 반드시 --host 0.0.0.0으로 LAN을 개방해야 하나요? 127.0.0.1에서만 실행하면 안 되나요?

답변: 전혀 가능합니다. 컴퓨터 자체에 그래픽 인터페이스와 데스크톱 브라우저가 있다면 기본값인 127.0.0.1을 사용하는 것이 가장 안전합니다. LAN 개방을 지원하는 이유는, 많은 사용자의 Home Assistant와 보조 스크립트가 모니터 없는 소프트 라우터, NAS 또는 Linux 서버에서 실행되기 때문입니다. LAN을 개방하면 사용자가 소파에 편안히 누워 같은 LAN의 휴대폰 브라우저로 슬라이딩 퍼즐을 풀고 문자를 수신할 수 있습니다.

참고 자료 및 오픈소스 감사

- margrop/telecom-phone-device-id-tools : 본문에서 구현한 중국전신 DeviceId 로컬 제로 클라우드 기기 인증 도구의 공식 오픈소스 저장소.

- 전신 공식 로그인 게이트웨이 인터페이스 프로토콜 : 이번 리버싱과 프로토콜 계약 정렬의 공식 기반.

- hlhk2017/ChinaTelecomMonitor-Homeassistant-Integration : 본 프로젝트가 최적화한 기반 통합 프로토타입.

- yahooor/cn-carrier-monitor : 일부 통신사 v2 암호화 알고리즘 구현을 참고함.

- Home Assistant 공식 아키텍처 가이드: Config Entries : 엔티티 생명주기와 비동기 새로고침 설계 규범.

- W3C Canvas 2D Context 규격: 오프스크린 ImageData 픽셀 스캔 표준.

본문에 사용된 여섯 장의 실제 스크린샷은 모두 필자의 가정 내 운영 환경에서 수집한 것이며, 전체 IP와 내부 호스트명, 휴대전화번호는 가려 두었다. 여섯 장의 창작 아키텍처 다이어그램과 차트는 모두 벡터로 그렸다.

Margrop

87

글

9.0k

조회

1

팔로워