Armadilloフォーラム

電力センサーの取得データをAWS連携する際のNoサンプルソースについて

hiroki.nakatani

2024年6月20日 17時54分

以下のNode-REDフロー例のフロー書き出しjsonファイルをいただけないでしょうか。

Armadillo-IoT A6E: Node-RED™でAWSへ接続するシステムを構築する
https://armadillo.atmark-techno.com/howto/iotg_a6e-node-red-demo-aws

電力センサー値を取得し、AWS S3アップロードする仕組みの構築を行いたいのですが、その参考にしたい為です。

コメント

アットマークテクノの古賀です。

hiroki.nakataniさん:
>以下のNode-REDフロー例のフロー書き出しjsonファイルをいただけないでしょうか。
>
>Armadillo-IoT A6E: Node-RED™でAWSへ接続するシステムを構築する
>https://armadillo.atmark-techno.com/howto/iotg_a6e-node-red-demo-aws
>
>
>電力センサー値を取得し、AWS S3アップロードする仕組みの構築を行いたいのですが、その参考にしたい為です。

この Howto の Node-RED フローは単体で提供していませんので、提供している SWU イメージを、お使いの Armadillo にインストールして取り出してくださいませ。
SWU イメージは、Howto の「Armadillo のセットアップ」の節にあるリンク先からダウンロードできます:
 https://armadillo.atmark-techno.com/resources/software/armadillo-iot-a6…

SWU イメージのインストールにあたり、お使いの Armadillo-IoT A6E の eMMC の内容を変更したくない場合は、マニュアルの「SDブートの活用」に記載している手順でブートディスクイメージを microSD カードに書き込んでブートディスクを作り、SD ブートした状態でインストールすればよいです:
 https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…

手順について不明な点がありましたら、お知らせください。

hiroki.nakatani

2024年6月21日 9時33分

ご回答ありがとうございます。
確かにSDブートすればソース抽出できますね。
試してみます。

アットマークテクノの古賀です。

hiroki.nakataniさん:
>ご回答ありがとうございます。
>確かにSDブートすればソース抽出できますね。
>試してみます。

Howto で使っている Node-RED フローの内容と同様のことを、Armadillo-IoT A6E の「技術情報・ダウンロード」のページからリンクを張っている「Armadillo-IoT ゲートウェイ A6E Node-RED™ 開発ガイド」で説明していますので、こちらもご覧になってみてください:
 https://armadillo.atmark-techno.com/resources/documents/armadillo-iot-a…

この開発ガイドの「AWS へデバイス情報を送信するフローを作成する」を見て頂くのがよいかと思います:
 https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_n…

ここで説明しているフローおよび Howto のフローでは、AWS IoT Core の Device Shadow に対する REST API を使用しており、MQTT は使っていません。
REST API の呼び出しには、curl を実行するスクリプト片を書いた exec ノードを使用しています。

「電力センサー値を取得し、AWS S3アップロードする仕組みの構築を行いたい」とのことでしたので、Device Shadow の更新をトリガとする Lambda を AWS 側に作り、その Lambda で、Armadillo による Device Shadow の更新内容を受け取って S3 にアップロードする、という方策になろうかと思います。

一点注意です:
お使いの Armadillo-IoT A6E で armadillo-twin-agentd サービスが有効になっている場合、Howto のコンテナの .conf ファイルで行っているように、アプリケーションを実行するコンテナが、ホストの /dev/shm をコンテナの同じパスにマウントするようにしてください。
これは、AWS との接続の認証処理に、Armadillo-IoT A6E 搭載のセキュアエレメント(SE050)を使用する場合に必要な設定です。armadill-twin-agentd も SE050 を使用しており、コンテナのアプリケーションでも SE050 を使用する場合、両者間での排他制御が必要となります。その排他制御のための設定です。

hiroki.nakatani

2024年6月21日 12時14分

いただいた内容でソース抽出はできました。ありがとうございます。

> ここで説明しているフローおよび Howto のフローでは、AWS IoT Core の Device Shadow に対する REST API を使用しており、MQTT は使っていません。
> REST API の呼び出しには、curl を実行するスクリプト片を書いた exec ノードを使用しています。
>「電力センサー値を取得し、AWS S3アップロードする仕組みの構築を行いたい」とのことでしたので、Device Shadow の更新をトリガとする Lambda を AWS 側に作り、その Lambda で、Armadillo による Device Shadow の更新内容を受け取って S3 にアップロードする、という方策になろうかと思います。
→なるべくセキュア&低価格&通信経路をシンプルにしたいと考えております。
 AWS IoT側の勉強不足ですみませんが、上記方策とMQTT通信しS3にアップロードする方法ではどちらが適切でしょうか。
 MQTT方式の方が適切であれば、そのサンプルが公開されているページはありますか。

アットマークテクノの古賀です。

hiroki.nakataniさん:
>>ここで説明しているフローおよび Howto のフローでは、AWS IoT Core の Device Shadow に対する REST API を使用しており、MQTT は使っていません。
>>REST API の呼び出しには、curl を実行するスクリプト片を書いた exec ノードを使用しています。
>>「電力センサー値を取得し、AWS S3アップロードする仕組みの構築を行いたい」とのことでしたので、Device Shadow の更新をトリガとする Lambda を AWS 側に作り、その Lambda で、Armadillo による Device Shadow の更新内容を受け取って S3 にアップロードする、という方策になろうかと思います。
>
>→なるべくセキュア&低価格&通信経路をシンプルにしたいと考えております。
> AWS IoT側の勉強不足ですみませんが、上記方策とMQTT通信しS3にアップロードする方法ではどちらが適切でしょうか。

ケースバイケースだと思います。
AWS IoT との通信に、デバイス側がどのプロトコルを使うべきかの判断材料が、AWS IoT Core のドキュメントに記載されています:

 Device communication protocols
 https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html

このページの "Choosing a protocol for your device communication" の表をご覧になってみてください:
 https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html#pr…

デバイス(Armadillo)から AWS へ計測データを送出するだけの一方向通信で、かつ、送出間隔が1分以上程度であれば、HTTPS (REST API) でも問題ないと思います。
AWS からデバイスへ通知を行なったり、常時ネットワーク接続しておくことによりクラウド側からデバイスの死活監視を行う、というようなユースケースであれば、MQTT の方が適しているでしょう。

ちなみに、先のコメントに書いた armadillo-twin-agentd は、弊社のクラウドサービスである Armadillo Twin との間で双方向通信を行い、クラウド側からのデバイスの死活監視も行うため、クラウドとの接続に MQTT を使用しています。

> MQTT方式の方が適切であれば、そのサンプルが公開されているページはありますか。

Node-RED については、セキュアエレメントを使用して MQTT 接続するサンプルを現状提供していません。ごめんなさい。

hiroki.nakatani

2024年6月23日 1時16分

参考情報ありがとうございます。いただいた情報を元にMQTTを利用したいです。
接続の為に、ノード:デバイス証明書作成時に証明書、秘密鍵、CA証明書を取得&ローカル保存し、それらを元にMQTT接続するようにしたいのですが
ノード:デバイス証明書登録のcurlをどのように変更すればよいかわかりませんでした。

どのようにすればよいか教えていただけないでしょうか。

【現状】
set -x

AWS_ACCESS="$1"
AWS_REGION=ap-northeast-1
ENDPOINT=iot.ap-northeast-1.amazonaws.com
URI=/certificate/register-no-ca
CERT=$(cat /root/pem_files/device_cert.pem | sed -z 's/\n/\\n/g')

curl \
-H "Content-type: application/json" \
--cacert /root/pem_files/AmazonRootCA1.pem \
--user "${AWS_ACCESS}" \
--aws-sigv4 "aws:amz:${AWS_REGION}:execute-api" \
-d "{\"certificatePem\":\"${CERT}\",\"status\":\"ACTIVE\"}" \
--request POST -v \
"https://${ENDPOINT}${URI}"

【やりたいこと(AWS CLIの場合)】
以下の処理をcurlで実現し、${certificate.pem}、${private.key}、${public.key}をローカル保存するようにしたいです。
利用できるのであれば、/root/pem_files/device_cert.pemを使用したいです。

aws iot create-keys-and-certificate --set-as-active \
--certificate-pem-outfile ${certificate.pem} \
--private-key-outfile ${private.key} \
--public-key-outfile ${public.key}

hiroki.nakatani

2024年6月23日 8時35分

五月雨すみません。
デバイス登録後の結果取得に問題があるかもしれません。確認します。

アットマークテクノの古賀(休日モード)です。

hiroki.nakataniさん:
>参考情報ありがとうございます。いただいた情報を元にMQTTを利用したいです。

ということですと、Node-RED に関して、こちらから提供できる情報は、ありません。ごめんなさい。
Node-RED での AWS IoT Core 接続については、以下のブログが参考になりそうです:

 MQTT Explorer で AWS IoT Core につなぐときの設定メモ (2023年3月26日)
 https://www.1ft-seabass.jp/memo/2023/03/26/mqtt-explorer-aws-iot-core-s…
 https://mqtt-explorer.com/

 AWS IoT Core に Node-RED から標準の mqtt ノードでつなぐメモ (2023年4月27日)
 https://www.1ft-seabass.jp/memo/2023/04/27/aws-iot-core-node-red-build-…

2021年に書かれた以下のブログでは、node-red-contriib-aws-iot パッケージの aws-iot-{in,out} ノードを使っていますが、このパッケージは8年前から更新されておらず、リンク先の GitHub リポジトリは既に存在していませんので、上で紹介されている手順の方が良さそうです:

 Node-REDでAWS IoT Coreを使ってみた
 https://dev.classmethod.jp/articles/node-red-aws-iot-core/
 https://www.npmjs.com/package/node-red-contrib-aws-iot

>接続の為に、ノード:デバイス証明書作成時に証明書、秘密鍵、CA証明書を取得&ローカル保存し、それらを元にMQTT接続するようにしたいのですが
>ノード:デバイス証明書登録のcurlをどのように変更すればよいかわかりませんでした。

curl コマンドを使うのであれば、MQTT を採用する利点が無いと思います。MQTT の場合、TCP 接続のコネクションを張ったままにしておき、データ送信のたびに TCP 接続・切断を行わないことで、データ送信のたびに TCP 接続・切断するよりも通信オーバーヘッドを抑制できる、というのが利点だと思います。しかし、curl では MQTT の topic を取得・更新するたびに TCP 接続・切断するようですから、そうであれば REST API を使うのと変わりません。

さらに、curl のドキュメントを見ると、TLS をサポートしていないため、AWS IoT Core への MQTT 接続には利用できないと思われます:
 https://curl.se/docs/mqtt.html

hiroki.nakatani

2024年6月23日 13時18分

参考情報ありがとうございます。

aws IoT関連の初期セットアップ(もの、ポリシー、証明書の作成アタッチ)に対して、curlを使用して行い、MQTT通信は鍵情報取得後にmqttノードを使用して行う予定です。

curlで証明書作成時に鍵情報を取得&ローカル保存し、mqttノードでの接続設定にてローカル鍵を使用する予定です。

またcurlでREST API実行する際に参考にした技術情報URLがわかれば教えていただけないでしょうか。

アットマークテクノの古賀(休日モード)です。

hiroki.nakataniさん:
>またcurlでREST API実行する際に参考にした技術情報URLがわかれば教えていただけないでしょうか。

AWS IoT Core の Developer Guide に、IoT Core デバイスから REST API を呼び出す手順例があり、Python と curl のそれぞれの場合について説明されています:

 https://docs.aws.amazon.com/iot/latest/developerguide/http.html#codeexa…

上のリンク先で、"CURL" を選択してみてください。

hiroki.nakatani

2024年6月25日 9時50分

参考URLありがとうございます。
ただ、具体的にどのようなコマンドにすべきかわかりませんでした。

①デバイス証明書を登録するノード処理にて以下の記載があったのですが、どの情報を参考にされましたか。
URI=/certificate/register-ca

②Node-redに追加のカスタムノードをインストールする手順を教えていただけないでしょうか。

アットマークテクノの古賀です。

hiroki.nakataniさん:
>①デバイス証明書を登録するノード処理にて以下の記載があったのですが、どの情報を参考にされましたか。
>URI=/certificate/register-ca

確認ですが、'URI=/certificate/register-ca' は 'URI=/certificate/register-no-ca' の誤記でしょうか?
6/23 に頂いたコメントでは 'URI=/certificate/register-no-ca' と書いていらっしゃいました:
 https://armadillo.atmark-techno.com/forum/armadillo/20816#comment-16753
Armadillo-IoT ゲートウェイ A6E Node-RED™ 開発ガイド」の「デバイス証明書を登録するフローの作成」に記載している exec queue ノードのプロパティ内容でも、
 URI=/certificate/register-no-ca
となっています:
 https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_n…

/certificate/register-no-ca のことであれば、このリクエスト URI については、ASWS IoT の API リファレンスにある "RegisterCertificateWithoutCA" をご覧ください:
 https://docs.aws.amazon.com/iot/latest/apireference/API_RegisterCertifi…

>②Node-redに追加のカスタムノードをインストールする手順を教えていただけないでしょうか。

こちらについては、Armadillo に固有な話ではなく、Node-RED 一般の話ですから、Node-RED のドキュメントをご覧ください:
 https://nodered.org/docs/user-guide/runtime/adding-nodes

hiroki.nakatani

2024年6月25日 11時46分

>確認ですが、'URI=/certificate/register-ca' は 'URI=/certificate/register-no-ca' の誤記でしょうか?
失礼しました。
ご指摘の通りです。

>/certificate/register-no-ca のことであれば、このリクエスト URI については、ASWS IoT の API リファレンスにある "RegisterCertificateWithoutCA" をご覧ください:
ありがとうございます。参考にいたします。

>こちらについては、Armadillo に固有な話ではなく、Node-RED 一般の話ですから、Node-RED のドキュメントをご覧ください:
> https://nodered.org/docs/user-guide/runtime/adding-nodes
→ほかのIoTデバイスでは、通常npmでパッケージ導入後、Node-REDで利用しますが、armadilloだと-ash: npm: not foundとなりましたので質問させていただきました。

hiroki.nakatani

2024年6月25日 12時23分

EdgeLock SE050の証明書/リファレンスキーを利用してmqtt outノードを実行する方法がわからなかったので、CreateKeysAndCertificateを利用し、AWS上で生成した鍵を利用してmqtt outノードを実行することにしました。

アットマークテクノの古賀です。

hiroki.nakataniさん:
>>こちらについては、Armadillo に固有な話ではなく、Node-RED 一般の話ですから、Node-RED のドキュメントをご覧ください:
>> https://nodered.org/docs/user-guide/runtime/adding-nodes
>→ほかのIoTデバイスでは、通常npmでパッケージ導入後、Node-REDで利用しますが、armadilloだと-ash: npm: not foundとなりましたので質問させていただきました。

ABOS (Armadillo Base OS) では、npm や Node-RED などのアプリケーション用パッケージを OS に直接インストールする使い方を推奨していません。
コンテナをお使いください。

弊社から提供している Node-RED コンテナは、Debian ユーザーランドに Node-RED 用のパッケージを追加したものです。
従って、Node-RED コンテナをベースにして追加の npm パッケージをインストールして頂くのがよいでしょう。

hiroki.nakatani

2024年6月25日 15時10分

承知しました。いただいた回答を元に対応進めます。
ありがとうございます。