[AWS IoT Events] アクションで起動したLambdaに送られる、デフォルトのPayloadについて確認してみました

「変数の設定」をうまく活用すると、ディテクターごとに、如何なる情報も保持することが可能です。アラートに有用な付加情報の検討もできそうです。
2020.10.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

1 はじめに

CX事業本部の平内(SIN)です。

今回は、AWS IoT Events(以下、IoT Events)のアクションでLamdaを起動した場合に送られる、デフォルトのPayloadについて確認してみました。

今回、サンプルとしてイメージした探知機は、温度管理です。規定の温度を超えた場合に、アラートを発生させたいと考えています。

2 入力の作成

IoT Eventsの探知機では、入力を操作するために、予め、その型を定義しておく必要があります。

下記のようなjsonファイルをローカルに作成しておき、入力の作成を行います。

SampleDetectorModelInput.json

{
    "deviceName": "",
    "temp" : ""
}

入力名は、SampleDetectorModelInputとしました。

3 探知機モデルの作成

探知機モデルを作成します。

モデルは、2つの状態(Normal及び、Abnormal)とその間の相互の移行を定義しました。

4 移行イベント

相互のイベントトリガーロジックは、それぞれ下記のようになっており、tempの値が、50を超えるかどうかで、2つの状態を遷移するようになっています。

$input.SampleDetectorModelInput.temp > 50
$input.SampleDetectorModelInput.temp <= 50

5 Lambda

SampleDetectorModelFunctionという名前で、発火させるLambdaを作成します。

コードは、送られてきたペイロードを出力するだけの簡単なものです。

import json

def lambda_handler(event, context):
    print(json.dumps(event))

6 遷移後のイベント

状態(Abnormal)OnEnterにイベントを追加して、上記のLambdaを起動するように設定しました。

Lambdaに送られるPayloadは、デフォルトを選択しています。

7 発行

SampleDetectorModelという名前で、探知機を発行しています。

探知機生成メソッドは、一意のキー値ごとに探知機を生成するとし、deviceNameごとに探知機が生成されるようにしています。

8 サンプルデータの送信

通常、探知機へのメッセージは、IoT Coreのエンドポイントに到着したMQTTメッセージをルールでトリガーして、IoT Eventに送りますが、ここでは、テストとして、サンプルデータの送信を使用して、探知機を動作させて見ます。

設定した内容は以下のとおりです。

  • 入力名:SampleDetectorModelInput
  • ペイロード:
    • deviceName: device001 文字列
    • temp 40 番号

プレビュー画面からデータを送信するを押すと、探知機にメッセージが送られます。

ディテクターの一覧を見ると、temp:40としたので、device001 が、Normal状態のとなっていることが確認できます。

9 アラート発生

同じく「サンプルデータを送信」から、temp:60を送信してみると、device001 が、Abnormal状態に変化したことを確認できます。

また、Abnormalに遷移したので、OnEventからLambdaが発火して、ログが出力されていることを確認できます。

Lambdaに送られたペイロードを確認すると、payload.detector.detectorModelName及び、payload.state.stateNameで、どの探知機の何状態からの発火なのかが分かります。

また、payload.detector.keyValueに、deviceNameが入りますので、デバイス名も分かります。

しかし、異常となった原因、温度(temp)は、分かりません。

{
    "eventTime": 1601680342294,
    "payload": {
        "actionExecutionId": "8287b53e-6b65-3f3c-81d2-c1d85565a6a6",
        "detector": {
            "detectorModelName": "SampleDetectorModel",
            "keyValue": "device001",
            "detectorModelVersion": "1"
        },
        "eventTriggerDetails": {
            "inputName": "SampleDetectorModelInput",
            "messageId": "aab4fcbe-3d1c-40d2-822c-975a70c0e9b4",
            "triggerType": "Message"
        },
        "state": {
            "stateName": "Abnormal",
            "variables": {},
            "timers": {}
        }
    },
    "eventName": "Alert"
}

10 変数の設定

現在の移行イベント(toAbnormal)は、イベントトリガーのロジックしか設定されていませんが、ここに「変数の設定」アクションを追加し、tempの値を保存することにします。

前回と同じ要領で、Abnormalへの遷移を発生させ、Lambdaのログを確認すると、今度は、payload.statevariablesが増えており、保存した変数の値が入っていることが分かります。

11 最後に

今回は、IoT EventsでLambdaを発火させた場合の、デフォルトのPayloadについて確認してみました。

「変数の設定」を使用すると、ディテクターごとに、メッセージで送られて来た如何なる情報も保持することが可能です。

今回のような温度の探知機であれば、異常アラートに、「直近10回分の計測結果」とかを追加することも可能でしょう。

殆どコーディングなしで、ここまで出来てしまうマネージドサービスは、ホント凄いと思います。