IoT Hub には、デバイス アプリが機能をバックエンド アプリに公開するための 3 つのオプションが用意されています。
デバイスを特定の望ましい状態にすることを目的とした長時間実行コマンドの Twin の望ましいプロパティ。たとえば、テレメトリの送信間隔を 30 分に設定します。
結果の即時確認を必要とする通信のための直接的な方法。ダイレクト メソッドは、多くの場合、ファンをオンにするなどのデバイスの対話型制御に使用されます。
デバイス アプリへの一方向通知用のクラウドからデバイスへのメッセージ。
参照：
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-c2d-guidance

説明

Box1: はい
ボックス 2: はい
Fanspeed 73 は報告されたプロパティです。
ボックス 3: いいえ
deviceID プロパティは読み取り専用です。
参照：
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-device-twins

シナリオ: IoT ゲートウェイ デバイスと iothub1 の間の接続の問題を発見しました。これにより、IoT デバイスの接続とメッセージが失われます。
デバイスと IoT ハブの間で状態情報を同期するには、デバイス ツインを使用します。デバイス ツインは、特定のデバイスに関連付けられた JSON ドキュメントであり、クエリを実行できるクラウド内の IoT Hub によって格納されます。デバイス ツインには、必要なプロパティ、報告されるプロパティ、およびタグが含まれています。
参照：
https://docs.microsoft.com/en-us/azure/iot-hub/tutorial-device-twins
これは事例研究です。ケーススタディの時間は個別に設定されていません。各ケースを完了したいだけの試験時間を使用できます。ただし、この試験には追加のケース スタディやセクションがある場合があります。指定された時間内にこの試験に含まれるすべての問題を完了できるように、時間を管理する必要があります。
ケース スタディに含まれる質問に答えるには、ケース スタディで提供されている情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する資料やその他のリソースが含まれている場合があります。このケース スタディでは、各質問は他の質問とは独立しています。
このケース スタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認して変更を加えることができます。新しいセクションを開始すると、このセクションに戻ることはできません。
ケーススタディを開始するには
このケース スタディの最初の質問を表示するには、[次へ] ボタンをクリックします。質問に答える前に、左ペインのボタンを使用してケース スタディの内容を調べます。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題ステートメントなどの情報が表示されます。ケース スタディに [すべての情報] タブがある場合、表示される情報は、後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、[質問] ボタンをクリックして質問に戻ります。

1 - グループの主キーを取得する
2 - デバイスの SAS キーを生成します。
3 - 一意の資格情報をデバイスにフラッシュします。
4 - デバイスを IoT Central に接続する
5 - デバイスをテンプレートに関連付け、接続を承認します。
参照：
https://docs.microsoft.com/en-us/azure/iot-central/core/concepts-get-connected
トピック 1、ADatum
要件
変更予定
ADatum は、環境条件を監視するための Azure IoT ソリューションを開発しています。IoT ソリューションは、ハードウェア デバイスとクラウド サービスで構成されます。すべてのデバイスは、Azure IoT Hub と直接通信します。
ハードウェア デバイスはブランチ オフィスに展開され、温度、湿度、空気の質、騒音レベルなどのさまざまな環境条件に関するデータを収集します。デバイスは、Power over Ethernet (PoE) 接続を使用して配線されます。
ADatum は、価値証明 (POV)、パイロット、本番の 3 つのフェーズでソリューションを開発しています。
要件。POV要件
POV フェーズでは、技術的なソリューションが実行可能であることを実証します。このフェーズでは、100 台のデバイスが本社に展開され、Azure Stream Analytics が IoT ハブに接続されてリアルタイム アラートが生成されます。Stream Analytics は、次の処理を実行します。
中央値を 4 倍超えるデバイス全体のテレメトリの中央値を計算します。
現在のテレメトリを指定されたしきい値と比較し、テレメトリ値が範囲外の場合にアラートを発行します。
デバッグを簡素化するために、このフェーズ中のすべてのメッセージ コンテンツが人間が判読できることを確認してください。
要件。パイロットの要件
パイロット フェーズでは、デバイスが 10 のオフィスに展開されます。各オフィスには最大 1,000 台のデバイスがあります。
このフェーズでは、Azure Time Series Insights を Stream Analytics と並行して追加して、ダッシュボード Web アプリでリアルタイムのグラフとクエリをサポートします。
パイロット展開では、運用コストを最小限に抑える必要があります。
要件。生産要件
生産フェーズには、すべてのオフィスが含まれます。
運用環境のデプロイでは、各 Azure リージョンに 1 つの IoT ハブがあります。デバイスは、その地域の IoT ハブに接続する必要があります。
生産フェーズは、次の要件を満たす必要があります。
IoT ソリューションがパフォーマンスとスケールのターゲットをサポートできることを確認してください。
IoT ソリューションがオフィスごとに最大 1,000 台のデバイスをサポートしていることを確認してください。
IoT ソリューションの運用コストを最小限に抑えます。
要件。技術要件
Datum は、計画されている IoT ソリューションの次の要件を特定します。
ソリューションは、オフィスで火災状態が検出されたときにリアルタイム アラートを生成する必要があります。そのオフィス内のすべてのデバイスは、アラートから 10 秒以内に可聴アラーム サイレンをトリガーする必要があります。
ダッシュボード UI は、アラートとシステム ステータスをリアルタイムで表示し、デバイス オペレーターがシステムを調整できるようにする必要があります。
各デバイスは、1 時間ごとの更新を IoT Hub に送信します。状態アラートはすぐに送信されます。複数のタイプのデバイスが、異なるスキーマを持つテレメトリを収集します
。
IoT Hub は、メッセージ本文に基づいてメッセージ ルーティングを実行する必要があります。
クラウドからデバイスへの通信には、ダイレクト メソッドを使用する必要があります。
レポートは、毎月、四半期ごと、および毎年提供する必要があります。
格納されたデータのクエリは、可能な限り効率的でなければなりません。
デバイス メッセージのサイズは 4 KB 未満になります。
開発作業は最小限に抑える必要があります。
要件。スロットルとクォータ
次の表に、さまざまな IoT Hub 層に関連するスロットルとクォータを示します。

要件。IoT ハブ ルーティング
次の図に示すように、POV フェーズで IoT Hub ルーティングを実装する予定です。

説明
100 KB * 24 は約 2,400 バイトです。
100 KB のメッセージは 4 KB のブロックに分割され、25 メッセージに対して課金されます。25 かける 24 は 600 です。 注: デバイスからクラウドに送信されるメッセージの最大サイズは 256 KB です。これらのメッセージは、有料層では 4 KB ブロックで計測されるため、たとえば、デバイスが有料層を介して 16 KB のメッセージを送信すると、4 つのメッセージとして請求されます。
参照：
https://azure.microsoft.com/en-us/pricing/details/iot-hub/