기기 등록
기기를 연결하려면 먼저 기기 관리자에 등록해야 합니다. 기기 관리자를 통해 기기 레지스트리와 레지스트리 내의 기기를 만들고 구성할 수 있습니다. 기기 관리자는 Cloud Platform Console, gcloud 명령어 또는 REST 스타일 API를 통해 사용할 수 있습니다.
기기 레지스트리
기기 레지스트리는 기기의 컨테이너입니다.
- 각 기기 레지스트리는 특정 클라우드 리전에서 생성되며 클라우드 프로젝트에 속합니다.
- 레지스트리는 cloudiot.googleapis.com 서비스에서
projects/{project-id}/locations/{cloud-region}/registries/{registry-id}와 같은 전체 이름으로 식별됩니다. - 기기 레지스트리는 레지스트리의 모든 기기에 대한 원격 분석 이벤트가 게시되는 하나 이상의 Cloud Pub/Sub 주제를 사용해 구성됩니다. 단일 주제를 사용하여 모든 리전의 데이터를 수집할 수 있습니다.
- Stackdriver Monitoring이 각 레지스트리에 자동으로 사용 설정됩니다.
- Identity and Access Management(IAM)를 액세스 제어에 사용하여 기기를 보거나 프로비저닝하거나 완전히 관리할 수 있는 권한을 사용자에게 부여할 수 있습니다. Pub/Sub 주제에 게시할 수 있도록 Cloud IoT Core에서 각 프로젝트의 해당 서비스 계정에
cloudiot.serviceAgent역할을 자동으로 부여합니다. - 기기 레지스트리 ID 이름 지정 및 크기 요구사항에 대한 자세한 내용은 허용되는 문자 및 크기 요구사항을 참조하세요.
자세한 내용은 DeviceRegistry 리소스 참조를 확인하세요.
기기
레지스트리 내에서 기기를 만들 때 기기를 Cloud IoT Core 리소스로 정의합니다. 그런 다음 기기 세부정보를 확인하고 일부 속성을 제어할 수 있습니다.
- 기기가 Cloud IoT Core와의 통신을 차단할 수 있습니다. 센서가 실패하거나 기기가 잘못 구성된 경우에 유용할 수 있습니다.
- 기기 타임스탬프에는 최근에 수신된 하트비트 및 원격 분석 이벤트가 표시됩니다.
- 각 기기는 전체 리소스 이름인
projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-id}또는projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-numeric-id}로 식별할 수 있습니다. 기기 ID 및 기기 숫자 ID에 대한 자세한 내용은 다음 섹션을 참조하세요.
자세한 내용은 기기 리소스 참조를 확인하세요.
기기를 사용할 때 Cloud IoT Core 할당량 및 한도를 준수해야 합니다.
기기 식별자
각 기기에는 다음과 같은 식별자가 있습니다.
- 사용자가 정의한 기기 ID: 기기 ID 이름 지정 및 크기 요구사항에 대한 자세한 내용은 허용되는 문자 및 크기 요구사항을 참조하세요.
- 서버에서 생성된 기기 숫자 ID: 기기 숫자 ID는 Cloud IoT Core에서 자동으로 생성됩니다. 전역적으로 고유하며 수정할 수 없습니다. 기기 숫자 ID를 확인하려면 기기 세부정보 페이지로 이동합니다.
- 이전 섹션에서 설명한 기기의 전체 경로
기기 메타데이터
하드웨어 지문, 일련번호, 제조업체 정보 또는 기타 속성 등의 기기 메타데이터를 정의할 수 있습니다. Cloud IoT Core에서는 기기 메타데이터를 해석하거나 색인을 생성하지 않습니다. 이론적으로는 기기 메타데이터는 기기에서 전송되거나 기기로 전송되지 않으므로 기기 메타데이터가 기기 상태 또는 기기 구성보다 안전합니다. 즉, 기기의 보안 침해가 발생한 경우 기기 메타데이터를 읽을 수 없습니다.
기기 메타데이터는 자주 변경하면 안 됩니다. 최상의 결과를 얻으려면 하루에 한 번 이상 업데이트하지 마세요.
기기를 추가 또는 수정할 때 최대 500개의 키-값 쌍을 정의할 수 있습니다. 각 키는 고유해야 합니다.
기기 메타데이터 키-값 이름 지정 및 크기 요구사항에 대한 자세한 내용은 허용되는 문자 및 크기 요구사항을 참조하세요.
기기 구성
Cloud IoT Core를 사용하면 기기 구성을 전송하여 기기를 제어할 수 있습니다. 기기 구성은 Cloud IoT Core에서 기기로 전송되는 데이터에 대한 임의의 사용자 정의 blob입니다. 데이터는 구조화되거나 구조화되지 않을 수 있습니다. 또한 임의 바이너리 데이터, 텍스트, JSON 또는 직렬화된 프로토콜 버퍼 등 모든 형식을 취할 수 있습니다.
기기 구성은 Cloud IoT Core에 의해 스토리지에서 유지됩니다. 구성 데이터의 최대 크기는 64KB입니다. 추가 한도는 할당량 및 한도를 참조하세요.
최상의 결과를 얻으려면 기기 구성에서 명령어 시퀀스가 아닌 원하는 값이나 결과에 초점을 맞춰야 합니다. 명령어를 지정하면 중간 구성 버전에서 충돌이 발생할 수 있으며, (기기가 처음 초기화된 이후 모든 명령어 시퀀스를 실행하지 않고는) 기기의 상태를 복원하지 못할 수 있습니다. 구성에서 값과 결과를 강조하면 기기 상태를 더 쉽게 복원할 수 있습니다.
구성 버전
MQTT 브리지
특정 MQTT 연결에서는 기기가 높은 버전 번호의 구성만 받습니다. 즉, 현재 버전보다 오래된 구성은 전송되지 않습니다. 하지만 기기를 MQTT 브리지에 다시 연결하면 이전 연결에서보다 더 오래된 구성을 수신할 수도 있지만, 이는 드물며 결국에는 최신 버전을 받게 됩니다.
기기가 모든 구성 업데이트를 받는다고 보장할 수는 없으며 대신 항상 최신 업데이트를 수신합니다. 구성을 빠르게 업데이트하는 경우 기기에 중간 버전이 수신되지 않을 수 있습니다.
기기 구성을 수정할 때 수정할 버전 번호를 지정할 수 있습니다. 이렇게 하면 동시 실행 변경사항이 구성을 덮어쓰는 상황을 막을 수 있습니다.
HTTP 브리지
HTTP를 통해 연결하는 기기는 로컬 버전(기기 구성 버전)을 지정할 수 있습니다. Cloud IoT Core에서는 HTTP 브리지의 섹션에 설명된 대로 최신 버전만 반환합니다.
기기 상태
기기 상태 정보는 환경이 아니라 기기의 현재 상태를 캡처합니다. 기기가 기기에서 클라우드로 전송되는 임의의 사용자 정의 blob 데이터를 사용하여 상태를 설명할 수 있습니다. 데이터는 구조화되거나 구조화되지 않을 수 있습니다. 바이너리 데이터, 텍스트, JSON 또는 직렬화된 프로토콜 버퍼 등 모든 형식을 취할 수 있습니다.
기기 상태의 예로는 기기 또는 펌웨어 버전의 상태가 있습니다. 일반적으로 기기 상태 정보는 자주 업데이트되지 않습니다.
기기 메타데이터, 구성, 상태의 차이점
구성과 상태를 함께 사용하면 '기기가 무엇을 해야 한다고 판단할까요?', 기기의 최신 구성과 비교하면 어떻게 다른가요?와 같은 질문에 답하는 데 도움이 됩니다. 반면에 메타데이터는 주로 기기의 라벨 또는 식별자 역할을 합니다.
구성 데이터는 Cloud IoT Core에서 기기로 전송됩니다. 상태 데이터는 기기에서 Cloud IoT Core로 전송됩니다. 구성은 기기로 전송되는 외부 명령, 상태는 기기의 내부 표현으로 생각할 수 있습니다. 구성 및 상태 데이터의 스키마와 인코딩은 동일하거나 다를 수 있습니다.
기기 메타데이터가 클라우드에 유지되므로 기기에서 전송해야 하는 정보가 기기 메타데이터로 저장되어서는 안 됩니다. 기기로 전송해야 하는 정보는 기기 구성에, Cloud IoT Core로 다시 보고해야 하는 정보는 기기 상태 데이터에 있어야 합니다.
다음 예시에서는 한 건물의 기기에 대한 시나리오를 사용하여 메타데이터, 구성, 상태의 다양한 용도를 설명합니다.
건물의 각 층에 여러 기기가 있다고 가정해 보겠습니다. 7층의 기기를 식별하려면 7층의 기기에
'floor': '7'메타데이터 키-값 쌍을 추가합니다. 이 메타데이터 정보를 적용하면 기기를 식별할 수 있지만 메타데이터가 해석되거나 색인이 생성되지 않으므로 메타데이터를 식별 목적으로만 사용할 수 있습니다.건물의 기기 상태를 변경하려면 각 기기로 기기 구성을 보내면 됩니다. 이 구성은 기기에 원하는 온도와 기기 조명이 켜져 있는지 여부를 포함하는 데이터의 임의 blob으로 구성됩니다.
{ temperature: 50 lights: off }구성만으로는 기기 온도를 변경하거나 조명을 켜거나 끌 수 없습니다. 구성을 해석하고 자체 로직을 사용하여 명령어를 수행하는 것은 기기의 몫입니다. 이후 몇 시간 동안 (구성을 업데이트하여 새 구성을 전송하지 않는 한) 기기 구성은 변경되지 않지만 온도가 증가 또는 감소하거나 기기 조명이 꺼지면 기기 상태가 변경되어야 합니다.
구성이 올바르게 적용되었고 기기가 올바른 상태인지 확인하기 위해 각 기기에서 상태(켜짐, 꺼짐, 온도, 50도 이하의 온도)를 Cloud IoT Core에 보고할 수 있습니다.
다음 표는 기기 메타데이터, 구성, 상태의 주요 차이점을 보여줍니다.
| 기기 메타데이터 | 기기 구성 | 기기 상태 | |
|---|---|---|---|
| 설명 | 기기를 정의하고 분류합니다. |
|
기기의 현재 상태를 캡처합니다. |
| 콘텐츠 | 키-값 문자열 쌍 | 사용자가 정의한 임의의 데이터 blob | 사용자가 정의한 임의의 데이터 blob |
| 제한사항 | 키:
모든 기기 메타데이터 키-값 쌍의 조합된 최대 총 크기: 256KB |
|
|
| 사용 사례 | 기기의 일련번호 및 제조업체 정보를 키-값 쌍으로 저장합니다. |
|
기기 상태(비정상 종료 빈도 등)를 가져옵니다. |
| 메시지 수신/발신 | 없음 | Cloud IoT Core-기기 전용 | 기기-Cloud IoT Core만 |
| 권장 빈도 | 기기당 하루 1회 이하 | 0.1QPS 미만 | 0.1QPS 미만 |
구성 데이터를 사용한 기기 동작 또는 상태 변경
위의 표에 나와 있듯이 구성 데이터의 기본 사용 사례는 다음과 같습니다.
원하는 상태를 구성 데이터로 전송
Cloud IoT Core에 저장된 기기 구성 데이터를 사용하면 기기의 상태를 변경할 수 있습니다. 예를 들어 기기 구성이 다음과 같이 표시된다고 가정해 보겠습니다.
DeviceConfig
{
firmwareVersionRequest: 1.11
}
MQTT 또는 HTTP 클라이언트에서 이 구성 데이터를 기기 상태를 변경하라는 명령으로 해석할 수 있습니다. 이 경우 기기가 펌웨어 1.11 버전인지 확인합니다. 그러면 기기에서 Cloud IoT Core로 기기 상태를 보내 사용 중인 펌웨어 버전을 표시할 수 있습니다.
DeviceState
{
firmwareVersion: 1.11
}
구성 및 상태 데이터를 사용한 명령어 모델링
Cloud IoT Core에 저장된 기기 구성 데이터를 사용하여 기기 명령어를 모델링할 수 있습니다. 예를 들어 기기 구성이 다음과 같이 표시된다고 가정해 보겠습니다.
DeviceConfig
{
rebootRequested: true
}
MQTT 또는 HTTP 클라이언트에서 이 구성 데이터를 작업 실행 명령으로 해석할 수 있습니다. 이 경우 재부팅 명령어를 전송합니다. 그러면 기기에서 기기 상태를 보고하고 마지막 재부팅 후 1초가 경과했음을 표시함으로써 결과를 표시할 수 있습니다.
DeviceState
{
last_reboot: 1
}
구성 데이터 구조화
구성 데이터를 더 구조화할 수 있으며 명령어 만료에 대한 세부정보를 포함할 수 있습니다.
DeviceConfig
{
commands: {
id1: {
type: REBOOT
requestedTimestamp: xxxx
expirationTimestamp: yyyy
}
id2: ...
}
}
클라이언트에서 이러한 명령어를 읽고 기기 상태를 적절히 업데이트하여 재부팅을 위한 타임스탬프와 오류 메시지를 제공할 수 있습니다.
DeviceState
{
commandResults: {
id1: {
type: REBOOT
completedTimestamp: zzzz
errorMessage: >empty<
}
id2: ...
}
}
이 모델은 클라이언트와 기기 간의 명령어-응답 관계로 간주할 수 있습니다. 만료 시간을 사용하는 경우 기기의 시계가 동기화되었는지 확인합니다.