デバイスの登録
デバイスが接続するには、まずデバイス マネージャーに登録する必要があります。デバイス マネージャーを使用すると、デバイス レジストリとレジストリ内のデバイスを作成して構成できます。デバイス マネージャーは、Cloud Platform Console、gcloud コマンド、REST スタイルの API で使用できます。
デバイスレジストリ
デバイス レジストリは、デバイスのコンテナです。
- 各デバイス レジストリは特定のクラウド リージョンに作成され、クラウド プロジェクトに属します。
- cloudiot.googleapis.com サービスでは、レジストリが
projects/{project-id}/locations/{cloud-region}/registries/{registry-id}のように完全な名前で識別されます。 - デバイス レジストリは、そのレジストリ内のすべてのデバイス用にテレメトリー イベントが公開される 1 つ以上の Cloud Pub/Sub トピックで構成されます。1 つのトピックを使用して、すべてのリージョンでデータを収集できます。
- Stackdriver モニタリングは、レジストリごとに自動的に有効になります。
- Identity and Access Management（IAM）を使用すると、ユーザーにデバイスの表示、プロビジョニング、全面的な管理を行う権限を付与して、アクセス制御を行うことができます。Cloud IoT Core は、各プロジェクトの対応するサービス アカウントに、ロール
cloudiot.serviceAgentを自動的に付与し、Pub/Sub トピックへのパブリッシュを可能にします。 - デバイス レジストリ 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 は、デバイス メタデータの解釈やインデックス登録を行いません。理論上、デバイス メタデータはデバイスの状態やデバイス構成よりも安全です。これは、デバイス メタデータがデバイスとの間で送受信されないためです。つまり、デバイスが不正使用された場合、デバイスのメタデータを読み取ることはできません。
デバイスのメタデータは頻繁に変更しないようにしてください。最良の結果を得るには、1 日に 1 回を超える頻度では更新しないでください。
デバイスの追加または編集時に、最大 500 個の Key-Value ペアを定義できます。各キーは一意でなければなりません。
デバイス メタデータの Key-Value の命名とサイズの要件については、使用可能な文字とサイズの要件をご覧ください。
端末構成
Cloud IoT Core では、デバイス構成を送信することでデバイスを制御できます。デバイス構成とは、Cloud IoT Core からデバイスに送信されるデータの任意のユーザー定義 blob です。データは構造化または非構造化のいずれかのタイプに設定できます。また、任意のバイナリデータ、テキスト、JSON、シリアル化されたプロトコル バッファなど、任意の形式にできます。
デバイス構成は Cloud IoT Core によってストレージに保存されます。構成データの最大サイズは 64 KB です。その他の上限については、割り当てと上限をご覧ください。
最適な結果を得るには、デバイス構成で、一連のコマンドではなく、目的の値や結果に焦点を合わせる必要があります。コマンドを指定すると、中間構成バージョンで競合が発生する可能性があり、デバイスの状態を復元できなくなります（デバイスの状態を復元するには、デバイスが最初に初期化された時点以降のコマンドのすべてのシーケンスを実行する必要があります）。構成で値と結果を重視する場合は、デバイスの状態を簡単に復元できます。
構成のバージョン
MQTT ブリッジ
特定の MQTT 接続では、デバイスはバージョン番号の昇順でのみ構成を受信します。つまり、現在のバージョンより古い構成が送信されることはありません。ただし、デバイスが MQTT ブリッジに再接続すると、以前の接続で受信した構成よりも古い構成を受信する可能性があります（ただし、これはまれであり、デバイスは最終的に最新バージョンを受信します）。
デバイスがすべての構成の更新を受信する保証はありません。常に最新の更新を受信します。構成が急速に更新されている場合、デバイスは中間バージョンを受信しない場合があります。
デバイス構成を変更するときは、変更するバージョン番号を指定できます。これにより、構成を同時変更で上書きすることを防止できます。
HTTP ブリッジ
HTTP 経由で接続するデバイスでは、ローカル バージョン（デバイスの構成バージョン）を指定できます。HTTP ブリッジのセクションで説明されているように、Cloud IoT Core はより新しいバージョンのみを返します。
端末の状態
デバイスの状態に関する情報は、環境ではなく、デバイスの現在のステータスをキャプチャします。デバイスは、デバイスからクラウドに送信されるデータの任意のユーザー定義 blob を使用して状態を記述できます。データは構造化または非構造化のいずれかのタイプに設定できます。バイナリデータ、テキスト、JSON、シリアル化されたプロトコル バッファなど、任意の形式にすることもできます。
デバイスの状態の例には、デバイスの健全性やファームウェア バージョンなどがあります。通常、デバイスの状態情報は頻繁には更新されません。
デバイスのメタデータ、構成、状態の違い
構成と状態を併用すると、デバイスが現在行う必要があるとして「認識」している動作内容は何か、デバイスの最新の構成と比較してどのような状態であるのかという、構成と状態に関する基本的な質問に回答することをサポートできます。対照的に、メタデータは主にデバイスのラベルまたは識別子として機能します。
構成データは Cloud IoT Core からデバイスに送信されます。状態データはデバイスによって Cloud IoT Core に送信されます。構成は、デバイスに送信される外部命令として、およびデバイスの内部表現として状態と考えることができます。構成と状態データには、同じスキーマとエンコード、または異なるものを使用できます。
デバイス メタデータはクラウド内に維持されるため、デバイスとの間で送受信する必要がある情報は、デバイス メタデータとして保存しないでください。その情報は、デバイスに送信する必要がある場合はデバイス構成に、Cloud IoT Core に報告する必要がある場合はデバイスの状態データに保存する必要があります。
次の例は、建物内のデバイスのシナリオを使用して、メタデータ、構成、状態のさまざまな使用方法を示しています。
建物内の各フロアに複数のデバイスがあるとします。7 階のデバイスを識別するには、7 階のデバイスに
'floor': '7'メタデータの Key-Value ペアを追加します。このメタデータ情報を適用するとデバイスを識別できますが、メタデータは解釈またはインデックス登録されないため、メタデータは識別目的でのみ使用できます。建物内のデバイスの状態を変更する場合は、各デバイスにデバイス構成を送信できます。この構成は、デバイスの望ましい温度を含むデバイスの任意の blob と、デバイスのライトがオンまたはオフになっているかどうかで構成されます。
{ temperature: 50 lights: off }構成だけで、デバイスの温度が変わったり、照明がオンまたはオフにされたりすることはありません。構成を解釈し、独自のロジックを使用してコマンドを実行するかどうかは、デバイスによって異なります。数時間が経過しても（新しい構成を更新して送信しない限り）デバイス構成は変更されませんが、デバイスの状態は、温度が上昇または低下し、デバイスが自身のライトをオフにした場合に変化します。
構成が正しく適用され、デバイスが正しい状態であることを確認するために、各デバイスが自身の状態（オン / オフ、温度、温度が 50 度以下であること）を Cloud IoT Core に報告できます。
次の表に、デバイスのメタデータ、構成、状態の主な違いを示します。
| デバイス メタデータ | 端末構成 | 端末の状態 | |
|---|---|---|---|
| Description | デバイスの定義と分類 |
|
デバイスの現在の状態をキャプチャします |
| 内容 | Key-Value 文字列ペア | データの任意のユーザー定義の blob | データの任意のユーザー定義の blob |
| 制限事項 | 鍵:
すべてのデバイス メタデータ Key-Value ペアの最大合計サイズ: 256 KB |
|
|
| ユースケース | デバイスのシリアル番号とメーカー情報を Key-Value ペアとして保存します |
|
デバイスの正常性（クラッシュの頻度など）を取得する |
| メッセージの方向 | なし | Cloud IoT Core からデバイスへのみの接続 | デバイスから Cloud IoT Core のみ |
| 推奨頻度 | デバイス 1 台につき 1 日に 1 回以下 | 0.1 QPS 未満 | 0.1 QPS 未満 |
構成データを使用してデバイスの動作や状態を変更する
上の表に示すように、構成データの主な使用例は次のとおりです。
目的の状態を構成データとして送信する
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: ...
}
}
このモデルは、クライアントとデバイス間のコマンド / レスポンスの関係と考えることができます。有効期限が使用されている場合は、デバイスの時計が同期されていることを確認します。