IDの取り扱い

IDレス通信の概念

Things Cloud の MQTT 実装は、特にデバイス通信用に設計されています。そのため、クライアント側から不要なロジックをできるだけ削除しようとします。

REST(またはSmartREST)プロトコルを使用するには、更新するすべてのオブジェクト、アラーム、およびオペレーションのIDを知っている必要があります。したがって、クライアントはこれらのIDの状態を保持する必要があります。例えば、アラームを作成する場合、あとでクリアできるように、アラームのIDを知る必要があります。

MQTT実装では、このようなアクションを実行し、ロジックをサーバーに移動するためにデバイスで必要なロジックを減らしたいと考えています。

例1: デバイスのID

RESTを経由してデバイスオブジェクトのデータを更新するには、デバイスオブジェクトのID(マネージドオブジェクトID)を知る必要があります。また、このIDはデバイスに関連付ける必要がある、他のすべてのデータ(メジャーメント、アラーム、イベントのソースなど)にも必要です。

IDをデバイスに保持する必要性をなくすために、Things Cloudは、 Identity APIを提供しており、External ID(例えばシリアル番号)をオブジェクトにリンクできるため、いつでもIDを照会することができます。

一般的なデバイスの起動は次のようになります。

REST受信デバイスID

MQTTでは、MQTT ClientIdで Identity APIを自動的に使用します。 これにより、デバイスにIDを通知する必要がなくなり、クライアントはこの接続で他のデータも送信するため、すべてのメジャーメント、アラーム、イベントなどを正しいデバイスに関連付けることができます。

MQTT自動的にIDを解決

例2: アラームのID

クライアントがREST APIを使用してアラームを作成する場合、Things Cloudによって生成されたアラームのIDを取得する必要があります。

クライアントは、後でアラームを更新するためにこのIDを必要とします。例えば、アラームがアクティブでなくなった場合、ステータスをCLEAREDに更新します。

RESTアラームの取り扱い

Things Cloudでは、デバイスはステータスがACTIVEのタイプごとに1つのアラームしか持つことができません。同じタイプで別のアラームを作成すると、重複除外されます。したがって、MQTT実装ではアラームのタイプを識別子として使用します。クライアントは解決されたアラームのタイプを送信するだけで、サーバーは正しいアラームオブジェクトを見つけることができます。

MQTTアラームの取り扱い