Armadilloフォーラム

AWS Dynamodbへのデータ送信方法について

new_bee

2024年6月17日 14時52分

いつもお世話になっております。

ゲートウェイコンテナを使用して、ロガーから取得したデータをDynamoDBに送信できないかと考えております。
armadilloとAWSで接続確認をするために取説にある 6.9.3. 接続先の クラウド 環境を構築 (AWS) を試してみたところ
ROLLBACK_COMPLETEエラーが発生してしまいました。

MyTopicRule  にてCREATE_FAILED が発生し Resource handler returned message: "Access denied for operation 'CreateTopicRule'." HandlerErrorCode: AccessDenied) 失敗しているようです。

IAMルールをコピペして作成しているはずなのですが、ほかに考えられる原因はございますでしょうか?

またゲートウェイコンテナを改造しdynamoDBにデータを送信することはできますでしょうか?
他に良い方法がございましたらご教授いただけると助かります。

よろしくお願いいたします。

コメント

at_reika.yamazaki

2024年6月17日 17時43分

お世話になっております。
山崎です。

「MyTopicRule  にてCREATE_FAILED が発生した」ということなので、
「6.9.3.5. AWS IoT Core と Amazon CloudWatch の設定を行う」の CloudFormation でのスタックの作成時にエラーしたという認識です。

使用しているユーザとポリシーについて確認してください。
ログイン画面の右上に "IAM ユーザー" 名が表示されていると思います。
使用しているユーザ名にアタッチしているポリシーが、作成したポリシー名であることをご確認ください。
作成したポリシーが正しくアタッチされている場合は、ポリシーを選択すると「このポリシーで定義されている許可」のサービス名 "IoT" の一覧に、"CreateTopicRule" が含まれています。
含まれていない場合はポリシーを再作成して、ユーザにアタッチしてください。

>またゲートウェイコンテナを改造しdynamoDBにデータを送信することはできますでしょうか?
>他に良い方法がございましたらご教授いただけると助かります。

こちらについてですが、IoT Core ルールを変更して DynamoDB にデータを渡すようにするのが良いと思います。
ゲートウェイコンテナは A6E に搭載されているセキュアエレメントを用いて、IoT Core にデバイス認証しています。
そのため許可されたデバイスのみが IoT Core に接続・データ送信が可能です。
セキュリティの観点から IoT Core を使うことをお勧めします。

CloudFomation のスタック作成に成功した場合、指定したデバイスに対して IoT Core ルールを作成します。
作成した IoT Core ルール名は "AWS IoT Core" のページの 「管理」→「メッセージのルーティング」→「ルール」に
"armadillo_iot_a6e_<シリアル番号>_cloudwatch_metrics"
という名前で登録されます。
デフォルトでは CloudWatch にデータを送信しますので、データが送信されているか「6.9.6.2. AWS 上でのデータ確認」でご確認ください。

無事にデータ送信が確認出来たら、ルールのアクションを DynamoDB 用に設定することで DynamoDB に送信が可能です。
ルールは10個しか登録できないため、適宜更新、もしくは削除してお使いください。
詳細は公式のドキュメントをご確認ください。
https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/iot-ddb-rul…

以上、どうぞよろしくお願い致します。

new_bee

2024年6月18日 11時22分

山崎様
お世話になっております。

一度削除して作成し直したところ、cloudwatchのダッシュボードにarmadilloのものが作成されました。
しかしデータが上がってきていないようで、エラーログなどはどこを確認すればよろしいでしょうか
cloud_agent.confを修正し、取説を参考に修正いたしました。
リージョンは東京です
[CLOUD]
SERVICE = AWS;
を選択し、
作成したアカウントのアクセスキー等を割り当てているはずです。

解決方法をご教授いただけると助かります。

> そのため許可されたデバイスのみが IoT Core に接続・データ送信が可能です。
> セキュリティの観点から IoT Core を使うことをお勧めします。
回答ありがとうございます。IoTCoreで進めていきたいと思います。

> 無事にデータ送信が確認出来たら、ルールのアクションを DynamoDB 用に設定することで DynamoDB に送信が可能です。
追加の質問なのですが、gwコンテナの通信設定ファイルには接点や、RS485のみなのですが、pythonで取得しているTCP/IPデータも送信することはできますでしょうか?

よろしくお願い致します。

> お世話になっております。
> 山崎です。
>
>
> 「MyTopicRule  にてCREATE_FAILED が発生した」ということなので、
> 「6.9.3.5. AWS IoT Core と Amazon CloudWatch の設定を行う」の CloudFormation でのスタックの作成時にエラーしたという認識です。
>
> 使用しているユーザとポリシーについて確認してください。
> ログイン画面の右上に "IAM ユーザー" 名が表示されていると思います。
> 使用しているユーザ名にアタッチしているポリシーが、作成したポリシー名であることをご確認ください。
> 作成したポリシーが正しくアタッチされている場合は、ポリシーを選択すると「このポリシーで定義されている許可」のサービス名 "IoT" の一覧に、"CreateTopicRule" が含まれています。
> 含まれていない場合はポリシーを再作成して、ユーザにアタッチしてください。
>
> >またゲートウェイコンテナを改造しdynamoDBにデータを送信することはできますでしょうか?
> >他に良い方法がございましたらご教授いただけると助かります。
>
> こちらについてですが、IoT Core ルールを変更して DynamoDB にデータを渡すようにするのが良いと思います。
> ゲートウェイコンテナは A6E に搭載されているセキュアエレメントを用いて、IoT Core にデバイス認証しています。
> そのため許可されたデバイスのみが IoT Core に接続・データ送信が可能です。
> セキュリティの観点から IoT Core を使うことをお勧めします。
>
> CloudFomation のスタック作成に成功した場合、指定したデバイスに対して IoT Core ルールを作成します。
> 作成した IoT Core ルール名は "AWS IoT Core" のページの 「管理」→「メッセージのルーティング」→「ルール」に
> "armadillo_iot_a6e_<シリアル番号>_cloudwatch_metrics"
> という名前で登録されます。
> デフォルトでは CloudWatch にデータを送信しますので、データが送信されているか「6.9.6.2. AWS 上でのデータ確認」でご確認ください。
>
> 無事にデータ送信が確認出来たら、ルールのアクションを DynamoDB 用に設定することで DynamoDB に送信が可能です。
> ルールは10個しか登録できないため、適宜更新、もしくは削除してお使いください。
> 詳細は公式のドキュメントをご確認ください。
> https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/iot-ddb-rul…
>
>
> 以上、どうぞよろしくお願い致します。

at_reika.yamazaki

2024年6月18日 13時14分

お世話になっております。
山崎です。

>しかしデータが上がってきていないようで、エラーログなどはどこを確認すればよろしいでしょうか
ゲートウェイコンテナのログをご確認ください。ログについてはマニュアルの以下をご確認ください。
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…

また、以下ですが、SERVICE に指定するのは AWS もしくは AZURE です。そのため `;` は不要です。
>[CLOUD]
>SERVICE = AWS;
マニュアルの「設定値」をご確認ください。
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…

>追加の質問なのですが、gwコンテナの通信設定ファイルには接点や、RS485のみなのですが、pythonで取得しているTCP/IPデータも送信することはできますでしょうか?
対応していないため、ゲートウェイコンテナのアプリケーションをカスタマイズする必要があります。
ゲートウェイコンテナのカスタマイズについては以下の Howto が参考になると思います。
https://armadillo.atmark-techno.com/node/13708

以上、どうぞよろしくお願い致します。

new_bee

2024年6月18日 15時23分

山崎様
お世話になっております。

cd /var/app/volumes/gw_container/device/log
にあるログを確認したところ以下エラーが発生していましたがそれ以降は1分ごとにCPU温度を出力しているようです。
2024-06-18 14:10:12,538 : CPU_temp read error.
2024-06-18 14:10:12,541 : ("can't concat NoneType to bytes",)
また使用していない要素のwarning が発生しているのみでエラーはそれ以降発生していないようです。

cloud_agent.conf がうまく設定できていないのかと思われるのですが
[CLOUD]
SERVICE = AWS

[LOG]
FILE_LOG = true
STREAM_LOG = true

[AWS]
AWS_IOT_HOST = iot.ap-northeast-1.amazonaws.com
AWS_IOT_REGION = ap-northeast-1
AWS_IOT_ENDPOINT = https://iot.ap-northeast-1.amazonaws.com
AWS_IOT_CERT_FILE = /cert/device/device_cert.pem
AWS_IOT_POLICY_FILE = /config/aws_iot_policy.json
AWS_IOT_CA_FILE = /cert/ca/AmazonRootCA1.pem
AWS_IOT_PKCS11_PATH = /usr/lib/plug-and-trust/libsss_pkcs11.so
AWS_IOT_KEY_LABEL = sss:100100F0
AWS_IOT_PORT = 443
AWS_IOT_PIN =
以下でおかしい部分はございますでしょうか?
アクセスキー等はコピぺのため間違ってないかと思います。

もしかしたらシリアルで取得しようとしたときに作成した
GWプロジェクトが影響していることはございますでしょうか?

初歩的質問で大変申し訳ありませんがよろしくお願いいたします。

> お世話になっております。
> 山崎です。
>
> >しかしデータが上がってきていないようで、エラーログなどはどこを確認すればよろしいでしょうか
> ゲートウェイコンテナのログをご確認ください。ログについてはマニュアルの以下をご確認ください。
> https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
>
> また、以下ですが、SERVICE に指定するのは AWS もしくは AZURE です。そのため `;` は不要です。
> >[CLOUD]
> >SERVICE = AWS;
> マニュアルの「設定値」をご確認ください。
> https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
>
> >追加の質問なのですが、gwコンテナの通信設定ファイルには接点や、RS485のみなのですが、pythonで取得しているTCP/IPデータも送信することはできますでしょうか?
> 対応していないため、ゲートウェイコンテナのアプリケーションをカスタマイズする必要があります。
> ゲートウェイコンテナのカスタマイズについては以下の Howto が参考になると思います。
> https://armadillo.atmark-techno.com/node/13708
>
> 以上、どうぞよろしくお願い致します。

at_reika.yamazaki

2024年6月18日 16時20分

お世話になっております。
山崎です。

AWS への接続ログは出力されているでしょうか?
cloud_agent.log に `AWS connect start` が表示されている場合は AWS 接続処理をしています。
もし出力がない場合、クラウド接続が有効になっていない可能性があります。
マニュアルの「3.13.4.3. インターフェース設定」より `send_cloud=true` になっているか確認してください。
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…

>cd /var/app/volumes/gw_container/device/log
>にあるログを確認したところ以下エラーが発生していましたがそれ以降は1分ごとにCPU温度を出力しているようです。
デフォルトでは CPU温度を1秒間隔で取得して、10秒毎にクラウドに送信する動きになっています。
ゲートウェイコンテナを動かして1分経過しても CPU 温度が送られてこない場合、設定内容でエラーしている可能性が高いです。

貼っていただいた cloud_agent.conf は見た範囲では問題なさそうです。
設定内容に誤りがある場合は AWS 接続処理時に エラーが出力されるはずですので、ログをご確認ください。

>もしかしたらシリアルで取得しようとしたときに作成した
>GWプロジェクトが影響していることはございますでしょうか?
開発したゲートウェイコンテナアプリケーションについても問題ないと思いますが、
もし心配でしたら `/var/app/rollback/volumes/gw_container/src/customize` ディレクトリに main.py がある場合に main.py を削除してください。
こちらは ABOSDE のゲートウェイコンテナアプリケーションで作成した swu イメージによって配置された main ファイルになります。

以上、どうぞよろしくお願い致します。

new_bee

2024年6月18日 17時21分

山崎さま
お世話になっております。
早急の対応ありがとうございます。

cloud送信設定をオンにしたところ以下エラーが発生していました。
2024-06-18 16:51:13,666 : Provisioning error.
2024-06-18 16:51:13,682 : Device provisioning error
2024-06-18 16:51:13,685 : AWS connect error
証明書を別途AWS側にも保存しないといけないのでしょうか?

> もし心配でしたら `/var/app/rollback/volumes/gw_container/src/customize` ディレクトリに main.py がある場合に main.py を削除してください。
念のため削除いたしました。

すみませんがよろしくお願いいたします

2024-06-18 16:51:20,482 : network is False, update_publish_shadow() is not send
> お世話になっております。
> 山崎です。
>
> AWS への接続ログは出力されているでしょうか?
> cloud_agent.log に `AWS connect start` が表示されている場合は AWS 接続処理をしています。
> もし出力がない場合、クラウド接続が有効になっていない可能性があります。
> マニュアルの「3.13.4.3. インターフェース設定」より `send_cloud=true` になっているか確認してください。
> https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e_p…
>
> >cd /var/app/volumes/gw_container/device/log
> >にあるログを確認したところ以下エラーが発生していましたがそれ以降は1分ごとにCPU温度を出力しているようです。
> デフォルトでは CPU温度を1秒間隔で取得して、10秒毎にクラウドに送信する動きになっています。
> ゲートウェイコンテナを動かして1分経過しても CPU 温度が送られてこない場合、設定内容でエラーしている可能性が高いです。
>
> 貼っていただいた cloud_agent.conf は見た範囲では問題なさそうです。
> 設定内容に誤りがある場合は AWS 接続処理時に エラーが出力されるはずですので、ログをご確認ください。
>
> >もしかしたらシリアルで取得しようとしたときに作成した
> >GWプロジェクトが影響していることはございますでしょうか?
> 開発したゲートウェイコンテナアプリケーションについても問題ないと思いますが、
> もし心配でしたら `/var/app/rollback/volumes/gw_container/src/customize` ディレクトリに main.py がある場合に main.py を削除してください。
> こちらは ABOSDE のゲートウェイコンテナアプリケーションで作成した swu イメージによって配置された main ファイルになります。
>
> 以上、どうぞよろしくお願い致します。

at_reika.yamazaki

2024年6月18日 18時23分

お世話になっております。
山崎です。

プロビジョニング時に失敗しているエラーが出てますね。
先ほど、cloud_agent.conf に問題はないといったのですが、確認できない範囲の設定に誤りがある可能性があります。
申し訳ありませんが、以下の設定内容を再度ご確認くださると助かります。
・AWS_IOT_ACCOUNTID
・AWS_IOT_SHADOW_ENDPOINT
・AWS_ACCESS_KEY
・AWS_SECRET_KEY
また、以下の項目はセキュリティの観点よりプロビジョニング処理に使用した後削除されるため、まだ IoT Core のモノに登録されていない場合は記載をお願いします。
・AWS_IOT_ACCOUNTID
・AWS_ACCESS_KEY
・AWS_SECRET_KEY
登録後は空白のままで問題ありません。

>証明書を別途AWS側にも保存しないといけないのでしょうか?
こちらは不要です。
設定ファイルに記載している以下のファイルが確認出来れば問題ありません。
・/var/app/volumes/gw_container/device/cert/device_cert.pem
・/var/app/rollback/volumes/gw_container/config/aws_iot_policy.json
・/var/app/rollback/volumes/gw_container/cert/AmazonRootCA1.pem
・/usr/lib/plug-and-trust/libsss_pkcs11.so

お手数をおかけして申し訳ありません。
以上、どうぞよろしくお願い致します。

new_bee

2024年6月18日 19時15分

山崎様
お世話になっております。

以下で再度記入し直したのですが
・AWS_IOT_ACCOUNTID
 IAMで作成したpolicy_for_A6Eのポリシーが追加されているアカウントのID
・AWS_IOT_SHADOW_ENDPOINT
 Iot Core の設定にあるデバイスデータエンドポイントのエンドポイントをコピー
・AWS_ACCESS_KEY・AWS_SECRET_KEY
 ポリシーを追加したアカウントのキー

を記入していますが同様のエラーが発生いたします。
2024-06-18 19:00:07,631 : network is False, update_publish_shadow() is not send
2024-06-18 19:00:16,482 : AWS connect start
2024-06-18 19:00:16,486 : Request URL = https://iot.ap-northeast-1.amazonaws.com/things/
2024-06-18 19:05:19,969 : AWS_IOT_PIN is not found.
2024-06-18 19:05:20,160 : AWS connect start
2024-06-18 19:05:20,179 : Request URL = https://iot.ap-northeast-1.amazonaws.com/things/
2024-06-18 19:11:57,863 : Provisioning error.
2024-06-18 19:11:57,866 : Device provisioning error
2024-06-18 19:11:57,869 : AWS connect error
2024-06-18 19:11:57,876 : network is False, update_publish_shadow() is not send
2024-06-18 19:11:57,910 : AWS connect start
2024-06-18 19:11:57,917 : Request URL = https://iot.ap-northeast-1.amazonaws.com/things/

また、以下の項目はセキュリティの観点よりプロビジョニング処理に使用した後削除されるため、まだ IoT Core のモノに登録されていない場合は記載をお願いします。
こちらはAWSのコンソールで登録する必要があるのでしょうか?

またほかに考えられる原因はございますでしょうか?

大変申し訳ありませんがよろしくお願いいたします。

> お世話になっております。
> 山崎です。
>
> プロビジョニング時に失敗しているエラーが出てますね。
> 先ほど、cloud_agent.conf に問題はないといったのですが、確認できない範囲の設定に誤りがある可能性があります。
> 申し訳ありませんが、以下の設定内容を再度ご確認くださると助かります。
> ・AWS_IOT_ACCOUNTID
> ・AWS_IOT_SHADOW_ENDPOINT
> ・AWS_ACCESS_KEY
> ・AWS_SECRET_KEY
> また、以下の項目はセキュリティの観点よりプロビジョニング処理に使用した後削除されるため、まだ IoT Core のモノに登録されていない場合は記載をお願いします。
> ・AWS_IOT_ACCOUNTID
> ・AWS_ACCESS_KEY
> ・AWS_SECRET_KEY
> 登録後は空白のままで問題ありません。
>
> >証明書を別途AWS側にも保存しないといけないのでしょうか?
> こちらは不要です。
> 設定ファイルに記載している以下のファイルが確認出来れば問題ありません。
> ・/var/app/volumes/gw_container/device/cert/device_cert.pem
> ・/var/app/rollback/volumes/gw_container/config/aws_iot_policy.json
> ・/var/app/rollback/volumes/gw_container/cert/AmazonRootCA1.pem
> ・/usr/lib/plug-and-trust/libsss_pkcs11.so
>
> お手数をおかけして申し訳ありません。
> 以上、どうぞよろしくお願い致します。

new_bee

2024年6月18日 19時17分

追記いたします。
またこちらのファイルはarmadillo内にあることを確認しております。
> ・/var/app/volumes/gw_container/device/cert/device_cert.pem
> ・/var/app/rollback/volumes/gw_container/config/aws_iot_policy.json
> ・/var/app/rollback/volumes/gw_container/cert/AmazonRootCA1.pem
> ・/usr/lib/plug-and-trust/libsss_pkcs11.so

よろしくお願いいたします。

new_bee

2024年6月19日 9時49分

ネットワーク設定が原因で同様のエラーが発生する場合もありますでしょうか?

現在armadilloに有線接続とSIMどちらもつないでいる状態です。
SIMは nmcli connection add type gsm ifname ttyCommModem ¥ apn [apn] user [user]password [pass]
を実行して接続確認しただけのものになっています。
有線接続はGUIのほうから設定したものでコンテナ内からパッケージをインストールできているので外には行けていると思います。
もし社内環境のせいで有線接続がはじかれて接続できない場合があったとしてmineoのSIMで接続する場合は有線接続を抜くだけで問題ないでしょうか?

小出しの情報が多くて申し訳ありませんがよろしくお願いいたします。

> 追記いたします。
> またこちらのファイルはarmadillo内にあることを確認しております。
> > ・/var/app/volumes/gw_container/device/cert/device_cert.pem
> > ・/var/app/rollback/volumes/gw_container/config/aws_iot_policy.json
> > ・/var/app/rollback/volumes/gw_container/cert/AmazonRootCA1.pem
> > ・/usr/lib/plug-and-trust/libsss_pkcs11.so
>
> よろしくお願いいたします。

at_shinya.koga

2024年6月19日 10時29分

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

new_beeさん:
>ネットワーク設定が原因で同様のエラーが発生する場合もありますでしょうか?

その可能性も、ゼロではないと思います。

>現在armadilloに有線接続とSIMどちらもつないでいる状態です。
>SIMは nmcli connection add type gsm ifname ttyCommModem ¥ apn [apn] user [user]password [pass]
>を実行して接続確認しただけのものになっています。
>有線接続はGUIのほうから設定したものでコンテナ内からパッケージをインストールできているので外には行けていると思います。

SIM の方は nmcli で設定して、有線 LAN の方は ABOS Web で設定された、ということのようですね。

>もし社内環境のせいで有線接続がはじかれて接続できない場合があったとしてmineoのSIMで接続する場合は有線接続を抜くだけで問題ないでしょうか?

はい。有線 LAN ケーブルを抜いた後、コンテナ内から、たとえば
 https://armadillo.atmark-techno.com/
を wget してエラーしなければ、それで問題ないはずです。

new_bee

2024年6月19日 13時45分

古賀様、山崎さま
お世話になっております。

SIMのみの接続にしwgetでindex.html を取得できることを確認いたしました。
何らかのアドレスがぶつかっていたのかもしれません。

SIMのみに変更しGWコンテナを再稼働させたところ、cloud_agent.conf から以下がきえておりました。
・AWS_IOT_ACCOUNTID
・AWS_ACCESS_KEY
・AWS_SECRET_KEY

IoTCoreのモノに追加されていることを確認いたしました。

2024-06-19 13:43:30,004 : AWS connect error
2024-06-19 13:43:31,885 : network is False, update_publish_shadow() is not send
2024-06-19 13:43:40,014 : AWS connect start
2024-06-19 13:43:40,017 : skip Device provisioning.
2024-06-19 13:43:40,020 : Device provisioning success
2024-06-19 13:43:40,034 : Connecting to a348cov4vnwoxt-ats.iot.ap-northeast-1.amazonaws.com with client ID ''...
2024-06-19 13:43:41,541 : AWS connect error
2024-06-19 13:43:41,912 : network is False, update_publish_shadow() is not send

のAWSとの接続エラーがまだ発生しておりまだ足りないことがあるのでしょうか?

すみませんがよろしくお願いいたします。

> アットマークテクノの古賀です。
>
> new_beeさん:
> >ネットワーク設定が原因で同様のエラーが発生する場合もありますでしょうか?
>
> その可能性も、ゼロではないと思います。
>
> >現在armadilloに有線接続とSIMどちらもつないでいる状態です。
> >SIMは nmcli connection add type gsm ifname ttyCommModem ¥ apn [apn] user [user]password [pass]
> >を実行して接続確認しただけのものになっています。
> >有線接続はGUIのほうから設定したものでコンテナ内からパッケージをインストールできているので外には行けていると思います。
>
> SIM の方は nmcli で設定して、有線 LAN の方は ABOS Web で設定された、ということのようですね。
>
> >もし社内環境のせいで有線接続がはじかれて接続できない場合があったとしてmineoのSIMで接続する場合は有線接続を抜くだけで問題ないでしょうか?
>
> はい。有線 LAN ケーブルを抜いた後、コンテナ内から、たとえば
>  https://armadillo.atmark-techno.com/
> を wget してエラーしなければ、それで問題ないはずです。

new_bee

2024年6月19日 17時57分

古賀様、山崎様

基本的にはデフォルトのままになっているはずなのですがsensing_mgr.conf を添付いたします。

お手数をおかけして申し訳ありませんがよろしくお願いいたします

> 古賀様、山崎さま
> お世話になっております。
>
> SIMのみの接続にしwgetでindex.html を取得できることを確認いたしました。
> 何らかのアドレスがぶつかっていたのかもしれません。
>
> SIMのみに変更しGWコンテナを再稼働させたところ、cloud_agent.conf から以下がきえておりました。
> ・AWS_IOT_ACCOUNTID
> ・AWS_ACCESS_KEY
> ・AWS_SECRET_KEY
>
> IoTCoreのモノに追加されていることを確認いたしました。
>
> 2024-06-19 13:43:30,004 : AWS connect error
> 2024-06-19 13:43:31,885 : network is False, update_publish_shadow() is not send
> 2024-06-19 13:43:40,014 : AWS connect start
> 2024-06-19 13:43:40,017 : skip Device provisioning.
> 2024-06-19 13:43:40,020 : Device provisioning success
> 2024-06-19 13:43:40,034 : Connecting to a348cov4vnwoxt-ats.iot.ap-northeast-1.amazonaws.com with client ID ''...
> 2024-06-19 13:43:41,541 : AWS connect error
> 2024-06-19 13:43:41,912 : network is False, update_publish_shadow() is not send
>
> のAWSとの接続エラーがまだ発生しておりまだ足りないことがあるのでしょうか?
>
> すみませんがよろしくお願いいたします。
>
> > アットマークテクノの古賀です。
> >
> > new_beeさん:
> > >ネットワーク設定が原因で同様のエラーが発生する場合もありますでしょうか?
> >
> > その可能性も、ゼロではないと思います。
> >
> > >現在armadilloに有線接続とSIMどちらもつないでいる状態です。
> > >SIMは nmcli connection add type gsm ifname ttyCommModem ¥ apn [apn] user [user]password [pass]
> > >を実行して接続確認しただけのものになっています。
> > >有線接続はGUIのほうから設定したものでコンテナ内からパッケージをインストールできているので外には行けていると思います。
> >
> > SIM の方は nmcli で設定して、有線 LAN の方は ABOS Web で設定された、ということのようですね。
> >
> > >もし社内環境のせいで有線接続がはじかれて接続できない場合があったとしてmineoのSIMで接続する場合は有線接続を抜くだけで問題ないでしょうか?
> >
> > はい。有線 LAN ケーブルを抜いた後、コンテナ内から、たとえば
> >  https://armadillo.atmark-techno.com/
> > を wget してエラーしなければ、それで問題ないはずです。

ファイル ファイルの説明
sensing_mgr.conf sensing_mgr

at_shinya.koga

2024年6月19日 18時52分

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

new_beeさん:
>基本的にはデフォルトのままになっているはずなのですがsensing_mgr.conf を添付いたします。

内容は問題なさそうですね。

>>SIMのみの接続にしwgetでindex.html を取得できることを確認いたしました。
>>何らかのアドレスがぶつかっていたのかもしれません。
>>
>>SIMのみに変更しGWコンテナを再稼働させたところ、cloud_agent.conf から以下がきえておりました。
>>・AWS_IOT_ACCOUNTID
>>・AWS_ACCESS_KEY
>>・AWS_SECRET_KEY
>>
>>IoTCoreのモノに追加されていることを確認いたしました。
>>
>>2024-06-19 13:43:30,004 : AWS connect error
>>2024-06-19 13:43:31,885 : network is False, update_publish_shadow() is not send
>>2024-06-19 13:43:40,014 : AWS connect start
>>2024-06-19 13:43:40,017 : skip Device provisioning.
>>2024-06-19 13:43:40,020 : Device provisioning success
>>2024-06-19 13:43:40,034 : Connecting to a348cov4vnwoxt-ats.iot.ap-northeast-1.amazonaws.com with client ID ''...
>>2024-06-19 13:43:41,541 : AWS connect error
>>2024-06-19 13:43:41,912 : network is False, update_publish_shadow() is not send
>>
>>のAWSとの接続エラーがまだ発生しておりまだ足りないことがあるのでしょうか?

プロビジョニングには成功したものの、その後の接続でエラーしている、という状況のようですね。
原因が分からないのですが、何か手がかりになるかも知れませんので、以下のコマンドを実行した時の出力を教えていただけますか:

# cat /etc/atmark-release
# cat /etc/sw-versions

これらのコマンドの出力を見ると、お使いの ABOS のバージョンとゲートウェイコンテナのバージョンが分かりますので、調査の取っ掛かりにしてみたいと思います。

new_bee

2024年6月20日 8時44分

古賀様

お世話になっております

実行結果は以下になります。

armadillo:~# cat /etc/atmark-release
3.19.1-at.3.20240527

armadillo:~# cat /etc/sw-versions
base_os 3.19.1-at.3.20240527
boot 2020.4-at21
extra_os.initial_setup 4
extra_os.a6e-gw-container 2.5.2
extra_os.python_app 14
python_app 14
extra_os.rs485 4
rs485 4
extra_os.python_tcp 3
python_tcp 3

お手数をお掛けして申し訳ありませんがよろしくお願いいたします。

> アットマークテクノの古賀です。
>
> new_beeさん:
> >基本的にはデフォルトのままになっているはずなのですがsensing_mgr.conf を添付いたします。
>
> 内容は問題なさそうですね。
>
> >>SIMのみの接続にしwgetでindex.html を取得できることを確認いたしました。
> >>何らかのアドレスがぶつかっていたのかもしれません。
> >>
> >>SIMのみに変更しGWコンテナを再稼働させたところ、cloud_agent.conf から以下がきえておりました。
> >>・AWS_IOT_ACCOUNTID
> >>・AWS_ACCESS_KEY
> >>・AWS_SECRET_KEY
> >>
> >>IoTCoreのモノに追加されていることを確認いたしました。
> >>
> >>2024-06-19 13:43:30,004 : AWS connect error
> >>2024-06-19 13:43:31,885 : network is False, update_publish_shadow() is not send
> >>2024-06-19 13:43:40,014 : AWS connect start
> >>2024-06-19 13:43:40,017 : skip Device provisioning.
> >>2024-06-19 13:43:40,020 : Device provisioning success
> >>2024-06-19 13:43:40,034 : Connecting to a348cov4vnwoxt-ats.iot.ap-northeast-1.amazonaws.com with client ID ''...
> >>2024-06-19 13:43:41,541 : AWS connect error
> >>2024-06-19 13:43:41,912 : network is False, update_publish_shadow() is not send
> >>
> >>のAWSとの接続エラーがまだ発生しておりまだ足りないことがあるのでしょうか?
>
> プロビジョニングには成功したものの、その後の接続でエラーしている、という状況のようですね。
> 原因が分からないのですが、何か手がかりになるかも知れませんので、以下のコマンドを実行した時の出力を教えていただけますか:
>

> # cat /etc/atmark-release
> # cat /etc/sw-versions
> 

> これらのコマンドの出力を見ると、お使いの ABOS のバージョンとゲートウェイコンテナのバージョンが分かりますので、調査の取っ掛かりにしてみたいと思います。

at_reika.yamazaki

2024年6月20日 11時43分

お世話になっております。
山崎です。

バージョンについて連絡ありがとうございます。
こちらでも確認してみます。

また、複数コンテナを起動させているみたいなので、ゲートウェイコンテナのみを起動させた場合は接続できるかどうか試していただいてもよろしいでしょうか?
以下のコマンドを順に実行してください。

podman kill -a
podman_start a6e-gw-container

お手数をおかけして申し訳ありません。
接続できるかどうか、ご確認いただけますと助かります。

以上、どうぞよろしくお願い致します。

new_bee

2024年6月20日 14時13分

山崎様

お世話になっております

ゲートウェイコンテナのみを起動させ数分後に確認いたしました。
2024-06-20 13:58:45,077 : AWS connect start
2024-06-20 13:58:45,080 : skip Device provisioning.
2024-06-20 13:58:45,083 : Device provisioning success
2024-06-20 13:58:45,098 : Connecting to -ats.iot.ap-northeast-1.amazonaws.com with client ID ''...
2024-06-20 13:58:48,044 : AWS connect error
2024-06-20 13:58:51,340 : network is False, update_publish_shadow() is not send
2024-06-20 13:58:51,349 : network is False, update_publish_shadow() is not send
2024-06-20 13:58:58,052 : AWS connect start
2024-06-20 13:58:58,055 : skip Device provisioning.
2024-06-20 13:58:58,057 : Device provisioning success
2024-06-20 13:58:58,071 : Connecting to -ats.iot.ap-northeast-1.amazonaws.com with client ID ''...
2024-06-20 13:59:00,845 : AWS connect error
2024-06-20 13:59:01,376 : network is False, update_publish_shadow() is not send
2024-06-20 13:59:01,390 : network is False, update_publish_shadow() is not send
2024-06-20 13:59:10,862 : AWS connect start
2024-06-20 13:59:10,865 : skip Device provisioning.
2024-06-20 13:59:10,867 : Device provisioning success
2024-06-20 13:59:10,882 : Connecting to -ats.iot.ap-northeast-1.amazonaws.com with client ID ''...

やはり同様に接続がうまくいっていないようです。
上記は消していますがConnecting to の後ろに入る接続先は Iot Core の設定にあるデバイスデータエンドポイントで間違いないでしょうか?

またモノに登録されているのはarmadilloのIDと同じものが追加されていましたら問題ないでしょうか?

確認よろしくお願いいたします。

すみませんが宜しくお願い致します。

> お世話になっております。
> 山崎です。
>
> バージョンについて連絡ありがとうございます。
> こちらでも確認してみます。
>
> また、複数コンテナを起動させているみたいなので、ゲートウェイコンテナのみを起動させた場合は接続できるかどうか試していただいてもよろしいでしょうか?
> 以下のコマンドを順に実行してください。
>

> podman kill -a
> podman_start a6e-gw-container
> 

>
> お手数をおかけして申し訳ありません。
> 接続できるかどうか、ご確認いただけますと助かります。
>
> 以上、どうぞよろしくお願い致します。

new_bee

2024年6月20日 15時15分

追記いたします
アルマジロ本体から接続していたカメラ及びロガーを取り外して、SIM接続のみに変更し再度同様に確認いたしましたが、同様にエラーが発生いたしました。

SDブートにて起動しているためGWコンテナは後から導入しております。

何卒宜しくお願いいたします。

> 山崎様
>
> お世話になっております
>
> ゲートウェイコンテナのみを起動させ数分後に確認いたしました。
> 2024-06-20 13:58:45,077 : AWS connect start
> 2024-06-20 13:58:45,080 : skip Device provisioning.
> 2024-06-20 13:58:45,083 : Device provisioning success
> 2024-06-20 13:58:45,098 : Connecting to -ats.iot.ap-northeast-1.amazonaws.com with client ID ''...
> 2024-06-20 13:58:48,044 : AWS connect error
> 2024-06-20 13:58:51,340 : network is False, update_publish_shadow() is not send
> 2024-06-20 13:58:51,349 : network is False, update_publish_shadow() is not send
> 2024-06-20 13:58:58,052 : AWS connect start
> 2024-06-20 13:58:58,055 : skip Device provisioning.
> 2024-06-20 13:58:58,057 : Device provisioning success
> 2024-06-20 13:58:58,071 : Connecting to -ats.iot.ap-northeast-1.amazonaws.com with client ID ''...
> 2024-06-20 13:59:00,845 : AWS connect error
> 2024-06-20 13:59:01,376 : network is False, update_publish_shadow() is not send
> 2024-06-20 13:59:01,390 : network is False, update_publish_shadow() is not send
> 2024-06-20 13:59:10,862 : AWS connect start
> 2024-06-20 13:59:10,865 : skip Device provisioning.
> 2024-06-20 13:59:10,867 : Device provisioning success
> 2024-06-20 13:59:10,882 : Connecting to -ats.iot.ap-northeast-1.amazonaws.com with client ID ''...
>
> やはり同様に接続がうまくいっていないようです。
> 上記は消していますがConnecting to の後ろに入る接続先は Iot Core の設定にあるデバイスデータエンドポイントで間違いないでしょうか?
>
> またモノに登録されているのはarmadilloのIDと同じものが追加されていましたら問題ないでしょうか?
>
> 確認よろしくお願いいたします。
>
> すみませんが宜しくお願い致します。
>
> > お世話になっております。
> > 山崎です。
> >
> > バージョンについて連絡ありがとうございます。
> > こちらでも確認してみます。
> >
> > また、複数コンテナを起動させているみたいなので、ゲートウェイコンテナのみを起動させた場合は接続できるかどうか試していただいてもよろしいでしょうか?
> > 以下のコマンドを順に実行してください。
> >

> > podman kill -a
> > podman_start a6e-gw-container
> > 

> >
> > お手数をおかけして申し訳ありません。
> > 接続できるかどうか、ご確認いただけますと助かります。
> >
> > 以上、どうぞよろしくお願い致します。

at_reika.yamazaki

2024年6月20日 16時32分

お世話になっております。
山崎です。

>上記は消していますがConnecting to
>の後ろに入る接続先は Iot Core
>の設定にあるデバイスデータエンドポイントで間違いないでしょうか?
はい。合っています。
AWS_IOT_SHADOW_ENDPOINT に指定いただいた xxxxxxxxx-ats.iot.apnortheast-1.amazonaws.com になります。

>またモノに登録されているのはarmadilloのIDと同じものが追加されていましたら問題ないでしょうか?
はい。Armadillo のシリアルナンバーになります。
以下のログが出力されているハズです。

Connecting to <デバイスデータエンドポイント> with client ID <シリアルナンバー>...

追加で確認をお願いしたいのですが、
このデバイスデータエンドポイントにゲートウェイコンテナ内から ping が通るか確認していただけますか?

ping <デバイスデータエンドポイント>

以上、どうぞよろしくお願い致します。

new_bee

2024年6月20日 17時27分

山崎様
お世話になっております。

ログについて問題なく出力されていました。

shが動いているため podman attch でコンテナ内に入るとコマンドが打てないため、
a6e-gw-container.confにてsh をとめたところ起動後に終了してしまいます。

confファイルをどう修正したらよろしいでしょうか?
初歩的質問で申し訳ありませんがよろしくお願いいたします

at_reika.yamazaki

2024年6月20日 17時36分

お世話になっております。
山崎です。

コンテナの conf ファイルはデフォルトのままで大丈夫です。
以下のコマンドでコンテナに入らなくても指定のコマンドが実行できます。

podman exec -it a6e-gw-container ping -c 3 <デバイスデータエンドポイント>

こちらを実行してみてください。

以上、どうぞよろしくお願い致します。

new_bee

2024年6月20日 17時54分

山崎様 
お世話になっております

ping: bad address エンドポイント

でpinが通らないようです

宜しくお願いいたします

at_reika.yamazaki

2024年6月20日 18時22分

お世話になっております。
山崎です。

2点追加で確認したいです。

1. コンテナ外では以下に ping は通るのでしょうか?

ping -c 3 <デバイスデータエンドポイント>
ping -c 3 atmark-techno.com

上記、順に実行していただけると助かります。

2. ゲートウェイコンテナの conf ファイルを、デフォルトから変更を加えて使っていますか?
もし変更している場合は conf ファイルを貼っていただけると助かります。

以上、どうぞよろしくお願い致します。

new_bee

2024年6月21日 9時21分

山崎様
お世話になっております。

申し訳ありません
armadilloに接続していたUSBLANを取り外したところコンテナ内から
いったんUSBLANの設定を削除いたしました。

ping -c 3 <デバイスデータエンドポイント>
を実行したらpinが通りました。

またコンテナ外から以下を実行したところpinが通りました
ping -c 3 <デバイスデータエンドポイント>
ping -c 3 atmark-techno.com

念のためGWコンテナのconfファイルを添付いたします。

またこの状態でも前に添付した設定ファイルのまま
コンテナを再起動させ実行したところ
同様にAWS上でデータは表示されませんでした。

宜しくお願いいたします。

> お世話になっております。
> 山崎です。
>
> 2点追加で確認したいです。
>
> 1. コンテナ外では以下に ping は通るのでしょうか?
>

> ping -c 3 <デバイスデータエンドポイント>
> ping -c 3 atmark-techno.com
> 

> 上記、順に実行していただけると助かります。
>
> 2. ゲートウェイコンテナの conf ファイルを、デフォルトから変更を加えて使っていますか?
> もし変更している場合は conf ファイルを貼っていただけると助かります。
>
> 以上、どうぞよろしくお願い致します。

ファイル ファイルの説明
a6e-gw-container.conf

at_reika.yamazaki

2024年6月21日 11時45分

お世話になっております。
山崎です。

conf ファイルありがとうございます。
内容確認しましたが、ネットワーク周りの設定は特にないため、コンテナの設定に問題があるわけではなさそうです。

念のため以下確認です。

1. コンテナ内から ping が通ったということですが、以下のコマンドも問題ないという認識で合っていますか?

podman exec -it a6e-gw-container ping -c 3 <デバイスデータエンドポイント>

2. "同様にAWS上でデータは表示されませんでした。" とのことですが、
CloudWatch のダッシュボード画面で armadillo_iot_a6e_<シリアルナンバー> を選択しても、
データが表示されないということで合っているでしょうか?
1分ほど経過後にダッシュボードを更新しても、データが表示されないままということで合っていますか?

3. ゲートウェイコンテナのログには依然として "network is False" が出力されているという認識で良いでしょうか?

以上確認です。
どうぞよろしくお願い致します。

new_bee

2024年6月21日 13時07分

山崎様
お世話になっております。

podman exec -it a6e-gw-container ping -c 3 <デバイスデータエンドポイント>の実行結果が以下になっています。

64 bytes from 18.180.111.85: seq=0 ttl=42 time=6.549 ms
64 bytes from 18.180.111.85: seq=1 ttl=42 time=6.001 ms
64 bytes from 18.180.111.85: seq=2 ttl=42 time=5.579 ms

2. "同様にAWS上でデータは表示されませんでした。" とのことですが、
CloudWatch のダッシュボード画面で armadillo_iot_a6e_<シリアルナンバー> を選択しても、
データが表示されないということで合っているでしょうか?

ダッシュボード画面でCPU_temp等の項目がある中でCPU_temp には -- が表示されていてカーソルを合わせるとデータなしと表示されます。

3. ゲートウェイコンテナのログには依然として "network is False" が出力されているという認識で良いでしょうか?
以下のエラーが表示され続けています
2024-06-21 13:05:43,902 : AWS connect error
2024-06-21 13:05:50,681 : network is False, update_publish_shadow() is not send

以上になります。
何卒宜しくお願いいたします。

new_bee

2024年6月21日 13時57分

山崎様
お世話になっております

・AWS_IOT_ACCOUNTID
・AWS_ACCESS_KEY
・AWS_SECRET_KEY

をアカウントを作成し直して再度登録してみようと考えているのですが
AWSでアカウント作成後、鍵を発行し直し設定ファイルに再度追加すれば問題ないでしょうか?

また他に削除したりする必要があるのでしょうか?

宜しくお願いいたします

at_reika.yamazaki

2024年6月21日 14時54分

お世話になっております。
山崎です。

以下の状況了解です。
・podman exec -it a6e-gw-container ping -c 3 <データエンドポイント> は ping ok
・ダッシュボード画面での確認ができていない
・ゲートウェイコンテナのログには依然として "network is False" の状態

provisioning に成功している場合は以下の項目が合っていれば "AWS onnect complete" になると思います。
・AWS_IOT_CERT_FILE
・AWS_IOT_SHADOW_ENDPOINT
・AWS_IOT_CA_FILE
こちらの証明書のパスは設定ファイルに記載済、また A6E に自動で配置されるため、特に変更する必要はない項目です。
そのため注意すべきは AWS_IOT_SHADOW_ENDPOINT なのですが、ping が通るということなのでこちらも問題ないハズです。
provisioning されている region はすべて同じという認識ですが、そちらは問題ないでしょうか?

>・AWS_IOT_ACCOUNTID
>・AWS_ACCESS_KEY
>・AWS_SECRET_KEY
>
>をアカウントを作成し直して再度登録してみようと考えているのですが
>AWSでアカウント作成後、鍵を発行し直し設定ファイルに再度追加すれば問題ないでしょうか?

こちらが影響するのは provisioning 時なので、現在のネットワークで状況で provisioning が成功するか、
確認してもらった方が良いかもしれません。
IoT Core のモノから使用している A6E のシリアルナンバーで検索して、一覧から削除してください。
削除されたことを確認して、cloud_agent.conf を埋めてゲートウェイコンテナを再起動すると、再度 provisioning 処理が動きます。
cloud_agent.conf を新しく取得した設定内容にすればそちらが使用されます。
もし、provisioning が成功しなくなった場合はネットワークに問題が起きている可能性が高いです。
成功した場合は、モノの一覧に再登録した A6E のシリアルナンバーが表示されます。

以上、どうぞよろしくお願い致します。

new_bee

2024年6月21日 15時58分

山崎様
お世話になっております。

リージョンを確認いたしましたが、すべて作成されている場所及び、設定ファイルのリージョン東京になっていました。

一度IotCoreでものを削除しIAMのキーも作り直し再度登録し直しました。
その後GWコンテナを再起動いたしました。
そのをSNのコンテンツがIotのモノに追加されていることを確認いたしました。

その後再度以下のエラーが発生するようになりました。
2024-06-21 15:50:56,379 : Provisioning error.
2024-06-21 15:50:56,384 : Device provisioning error
2024-06-21 15:50:56,389 : AWS connect error
2024-06-21 15:50:57,247 : network is False, update_publish_shadow() is not send

またcloudwatchは依然と更新されないままです。

ポリシーの作成が良くなかったのでしょうか?

何卒よろしくお願いいたします。

> お世話になっております。
> 山崎です。
>
> 以下の状況了解です。
> ・podman exec -it a6e-gw-container ping -c 3 <データエンドポイント> は ping ok
> ・ダッシュボード画面での確認ができていない
> ・ゲートウェイコンテナのログには依然として "network is False" の状態
>
> provisioning に成功している場合は以下の項目が合っていれば "AWS onnect complete" になると思います。
> ・AWS_IOT_CERT_FILE
> ・AWS_IOT_SHADOW_ENDPOINT
> ・AWS_IOT_CA_FILE
> こちらの証明書のパスは設定ファイルに記載済、また A6E に自動で配置されるため、特に変更する必要はない項目です。
> そのため注意すべきは AWS_IOT_SHADOW_ENDPOINT なのですが、ping が通るということなのでこちらも問題ないハズです。
> provisioning されている region はすべて同じという認識ですが、そちらは問題ないでしょうか?
>
> >・AWS_IOT_ACCOUNTID
> >・AWS_ACCESS_KEY
> >・AWS_SECRET_KEY
> >
> >をアカウントを作成し直して再度登録してみようと考えているのですが
> >AWSでアカウント作成後、鍵を発行し直し設定ファイルに再度追加すれば問題ないでしょうか?
>
> こちらが影響するのは provisioning 時なので、現在のネットワークで状況で provisioning が成功するか、
> 確認してもらった方が良いかもしれません。
> IoT Core のモノから使用している A6E のシリアルナンバーで検索して、一覧から削除してください。
> 削除されたことを確認して、cloud_agent.conf を埋めてゲートウェイコンテナを再起動すると、再度 provisioning 処理が動きます。
> cloud_agent.conf を新しく取得した設定内容にすればそちらが使用されます。
> もし、provisioning が成功しなくなった場合はネットワークに問題が起きている可能性が高いです。
> 成功した場合は、モノの一覧に再登録した A6E のシリアルナンバーが表示されます。
>
> 以上、どうぞよろしくお願い致します。

new_bee

2024年6月21日 16時11分

山崎さま ポリシーを確認したところ
アタッチされたエンティティには登録したIAMユーザ
許可にはcloudwatchへのフルアクセス等が与えられていました。

以下がjsonになります。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:Get*",
"iam:PutRolePolicy",
"iam:DeleteRolePolicy",
"iam:DeletePolicy",
"iam:DeleteRole",
"iam:AttachRolePolicy",
"iam:List*",
"iam:Pass*",
"iot:Connect",
"iot:Publish",
"iot:Subscribe",
"iot:Receive",
"iot:AcceptCertificateTransfer",
"iot:AddThingToThingGroup",
"iot:AssociateTargetsWithJob",
"iot:Attach*",
"iot:Cancel*",
"iot:ClearDefaultAuthorizer",
"iot:Create*",
"iot:Delete*",
"iot:DeprecateThingType",
"iot:Describe*",
"iot:Detach*",
"iot:DisableTopicRule",
"iot:EnableTopicRule",
"iot:Get*",
"iot:List*",
"iot:Register*",
"iot:RejectCertificateTransfer",
"iot:RemoveThingFromThingGroup",
"iot:ReplaceTopicRule",
"iot:SearchIndex",
"iot:Set*",
"iot:StartThingRegistrationTask",
"iot:StopThingRegistrationTask",
"iot:TransferCertificate",
"iot:Update*",
"autoscaling:Describe*",
"cloudwatch:*",
"logs:*",
"s3:PutObject",
"s3:ListBucket",
"s3:GetObject",
"s3:CreateBucket",
"cloudformation:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/events.amazonaws.com/AWSServiceRoleForCloudWatchEvents*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "events.amazonaws.com"
}
}
}
]
}
宜しくお願いいたします

new_bee

2024年6月21日 16時20分

山崎様
お世話になっております

先ほどからデータが上がってくるようになりました。
アカウントを登録し直し、再起動をしたところ追加されるようになりました。
特にそれ以外で変更したことはありません。

原因調査等で大変お手数をおかけいたしました。
誠にありがとうございました。

new_bee

2024年6月21日 17時29分

山崎様
お世話になっております。

LANにカメラを接続するため、カメラを接続したらAWS上に送信できなくなってしまいました。

おそらくLANのほうでAWSにアクセスしようとしているため接続できていないと思われるのですが、SIMを優先的に使用して接続するように設定することはできますでしょうか?

度重なる質問で申し訳ありませんがよろしくお願いいたします。

> 山崎様
> お世話になっております
>
> 先ほどからデータが上がってくるようになりました。
> アカウントを登録し直し、再起動をしたところ追加されるようになりました。
> 特にそれ以外で変更したことはありません。
>
> 原因調査等で大変お手数をおかけいたしました。
> 誠にありがとうございました。
>

koga

2024年6月23日 10時21分

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

new_beeさん:
>LANにカメラを接続するため、カメラを接続したらAWS上に送信できなくなってしまいました。
>
>おそらくLANのほうでAWSにアクセスしようとしているため接続できていないと思われるのですが、SIMを優先的に使用して接続するように設定することはできますでしょうか?

AWS IoT Core のエンドポイントの IP アドレス(※複数割り当てられています)に対して、LTE モジュールのネットワークデバイス(ppp0)を割り当てるルーティング設定を行う、というのが解になるかと思います。
ABOS で、ip route add [宛先アドレス] dev ppp0 のようにして、エンドポイントの各 IP アドレスに対するルーティング設定を追加してみてください:
 https://infra-exp.com/linux_static_route/

エンドポイントの IP アドレスを確認するには、nslookup コマンドを使ってみてください:
 https://nxmnpg.lemoda.net/ja/1/nslookup

new_bee

2024年6月24日 13時22分

古賀様
いつもお世話になっております
休日の対応ありがとうございます。

IoTCore のエンドポイントに対して 
割り振られているIPアドレスが動的に変わってしまっているようなのですが一度設定してしまえば問題ないのでしょうか
Non-authoritative answer: の以下にあるIPv4のアドレスをip route add [宛先アドレス] dev ppp0で追加して
ip r でppp0にエンドポイントのIPが割り振られていることを確認しています。
設定後GWコンテナを再起動させましたが AWS上にデータが上がってきませんでした。
方法やルーティング設定方法が間違っていますでしょうか?

お手数をおかけして申し訳ありませんがよろしくお願いいたします。

at_shinya.koga

2024年6月24日 13時38分

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

new_beeさん:
>IoTCore のエンドポイントに対して 
>割り振られているIPアドレスが動的に変わってしまっているようなのですが一度設定してしまえば問題ないのでしょうか
>Non-authoritative answer: の以下にあるIPv4のアドレスをip route add [宛先アドレス] dev ppp0で追加して
>ip r でppp0にエンドポイントのIPが割り振られていることを確認しています。

設定した IP アドレスは一つだけでしょうか?

古賀(2024年6月23日 10時21分):
>AWS IoT Core のエンドポイントの IP アドレス(※複数割り当てられています)に対して

と書いたように、エンドポイントに対しては、ラウンドロビン DNS で複数の IP アドレスを割り当て得られているようですから、それら全てに対するルーティング設定をち追加する必要があると思います。

>設定後GWコンテナを再起動させましたが AWS上にデータが上がってきませんでした。
>方法やルーティング設定方法が間違っていますでしょうか?

もし、設定された IP アドレスが一つだけなのであれば、nslookup が出力した IP アドレスを全てリストアップして、それらに対して全て設定してみてください。

new_bee

2024年6月24日 14時11分

古賀様
お世話になっております。

> 設定した IP アドレスは一つだけでしょうか?

いったん再起動しルーティング設定を初期化し
再度IPアドレスを取得しすべてのIPv4のアドレスはすべて追加いたしました。

やはり同様にカメラを接続した場合に
gwのlogにnetwork is False,が表示され接続できなくなりました。

LANカメラを抜くとAWSに接続可能になります。

宜しくお願いいたします。

> アットマークテクノの古賀です。
>
> new_beeさん:
> >IoTCore のエンドポイントに対して 
> >割り振られているIPアドレスが動的に変わってしまっているようなのですが一度設定してしまえば問題ないのでしょうか
> >Non-authoritative answer: の以下にあるIPv4のアドレスをip route add [宛先アドレス] dev ppp0で追加して
> >ip r でppp0にエンドポイントのIPが割り振られていることを確認しています。
>
> 設定した IP アドレスは一つだけでしょうか?
>
> 古賀(2024年6月23日 10時21分):
> >AWS IoT Core のエンドポイントの IP アドレス(※複数割り当てられています)に対して
>
> と書いたように、エンドポイントに対しては、ラウンドロビン DNS で複数の IP アドレスを割り当て得られているようですから、それら全てに対するルーティング設定をち追加する必要があると思います。
>
> >設定後GWコンテナを再起動させましたが AWS上にデータが上がってきませんでした。
> >方法やルーティング設定方法が間違っていますでしょうか?
>
> もし、設定された IP アドレスが一つだけなのであれば、nslookup が出力した IP アドレスを全てリストアップして、それらに対して全て設定してみてください。

new_bee

2024年6月24日 17時22分

古賀様
お世話になっております。

定期的にnslookup を実行してエンドポイントIPアドレスを新規に増えたものを追加しつづけたら今のところ問題なく通信できるようになりました。

しばらく放置いたしまして 様子を見たいと思います。

永続化させるにはnmcli でSIMの設定に追加するのみで persist_file は必要ないでしょうか?

宜しくお願いいたします

at_shinya.koga

2024年6月26日 5時58分

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

new_beeさん(2024年6月24日 17時22分):
>定期的にnslookup を実行してエンドポイントIPアドレスを新規に増えたものを追加しつづけたら今のところ問題なく通信できるようになりました。

了解しました。ご確認有り難うございます。

>しばらく放置いたしまして 様子を見たいと思います。
>
>永続化させるにはnmcli でSIMの設定に追加するのみで persist_file は必要ないでしょうか?

ip route add コマンドによる設定は、ファイルに保存されません。
ゲートウェイコンテナの .conf ファイルに ip route add コマンドを記述して、コンテナの起動時に ABOS のルーティング設定を変更するという方策もありですね。

ただし、AWS のエンドポイントの複数アドレスに対してルーティング設定を追加するのだと煩雑ですから、LTE (ppp0) をデフォルトルートにして、「LAN カメラ」用のルーティング設定を eth0 に対して追加する、というのが簡単かも知れません。
確認ですが、LAN インタフェースで接続していらっしゃる LAN(御社の閉域 LAN?)経由で接続する機器のネットワークアドレスは、全て同じでしょうか?

もしそうであれば、そのネットワークアドレスに対するルーティング設定を、eth0 に対して ip route add で行い、ppp0 に対してデフォルトルート設定を追加する( ip route add default dev ppp0 )、というのが簡単ではないかと思います。

new_bee

2024年6月27日 9時49分

古賀様
いつもお世話になっております。

> 確認ですが、LAN インタフェースで接続していらっしゃる LAN(御社の閉域 LAN?)経由で接続する機器のネットワークアドレスは、全て同じでしょうか?
> もしそうであれば、そのネットワークアドレスに対するルーティング設定を、eth0 に対して ip route add で行い、ppp0 に対してデフォルトルート設定を追加する( ip route add default dev ppp0 )、というのが簡単ではないかと思います。

カメラの基本的に同じになると思います。
IPが違う場合でも、以下の方法で画像取得コンテナに同様にルーティング設定を追加すれば問題ないでしょうか?
>ゲートウェイコンテナの .conf ファイルに ip route add コマンドを記述して、コンテナの起動時に ABOS のルーティング設定を変更するという方策もありですね。

> ただし、AWS のエンドポイントの複数アドレスに対してルーティング設定を追加するのだと煩雑ですから、LTE (ppp0) をデフォルトルートにして、「LAN カメラ」用のルーティング設定を eth0 に対して追加する、というのが簡単かも知れません。
もしそうであれば、そのネットワークアドレスに対するルーティング設定を、eth0 に対して ip route add で行い、ppp0 に対してデフォルトルート設定を追加する( ip route add default dev ppp0 )、というのが簡単ではないかと思います。

こちらも同様にGWのconfファイルにに対し、ip route add default dev ppp0を追加しLTEをデフォルトルート設定に変更し、
接続するカメラにはルーティング設定を追加すれば問題ないでしょうか?

現在ゲートウェイコンテナのカスタマイズをしようとしてコンフィグエラーが発生しており確認できない状態なので復旧次第確認いたします。

また最悪ゲートウェイコンテナのみ削除して再度入れ直す方法はありますでしょうか?
全削除し直してから再度入れ直すしかないのでしょうか?

宜しくお願いいたします

at_shinya.koga

2024年6月27日 12時28分

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

new_beeさん:
>現在ゲートウェイコンテナのカスタマイズをしようとしてコンフィグエラーが発生しており確認できない状態なので復旧次第確認いたします。

了解しました。ということで、まずは、以下の質問にコメントしますね。

>また最悪ゲートウェイコンテナのみ削除して再度入れ直す方法はありますでしょうか?
>全削除し直してから再度入れ直すしかないのでしょうか?

現在の状況について確認ですが、「ゲートウェイコンテナのカスタマイズをしようとして」のカスタマイズでは、次のどれを行われたのでしょうか?

a.) /etc/atmark/containers/a6e-gw-container.conf の内容を変更して、persist_file で変更内容を永続化した。

b.) /var/app/rollback/volumes/gw_container/config/ にある、以下のファイルのどれかまたは全ての内容を変更した。
  aws_iot_policy.json
  cloud_agent.conf
  sensing_mgr.conf

c.) /var/app/volumes/gw_container/config/ にある、以下のディレクトリのどれかまたは全てにファイルを追加した。
  customize/
  src/

d.) (a)~(c) 以外にも変更を加えた。

上記の (a) と (b) の変更だけであれば、ゲートウェイコンテナのコンテナイメージ関連ファイルのダウンロードページから、「SWU イメージ作成アーカイブ」をダウンロードして、その中に入っているファイルを上書きコピーすればよいです。
 https://armadillo.atmark-techno.com/resources/software/armadillo-iot-a6…
コンテナイメージは書き換わっていないと思いますので、ABOS をリブートすれば、コンテナイメージからコンテナが作り直されて、最初の状態にもどるはずです。

いかがでしょうか?

new_bee

2024年6月27日 14時44分

古賀様
お世話になっております。

以前、ATDE上のvs code で作成した GW Project があり以下の4. ゲートウェイアプリケーションのソースコードをカスタマイズするの部分で
app/src/に配置するファイルをすべてコピーしSWUアップデートをかけました。
https://armadillo.atmark-techno.com/node/13708

GWProject自体は特になわってなくmain.py 等も特に触ってはいません

>ゲートウェイコンテナのコンテナイメージ関連ファイルのダウンロードページ
から取得したファイルに置き換えてみたところ、CPU温度は取得することはできていますがAWSへのデータ送信を使用とするとlogファイルにコンフィグエラーのみ書き込まれる形になります

宜しくお願いいたします。

at_reika.yamazaki

2024年6月27日 16時21分

お世話になっております。
山崎です。

現在の状況ですが、こちらの Howto「Armadillo-IoT A6E のゲートウェイコンテナをカスタマイズする(センサ追加編)」の、
「4. ゲートウェイアプリケーションのソースコードをカスタマイズする」を実行して、カスタマイズ用のコードを配置したものを SWU イメージにして適用したという認識です。

AWSへのデータ送信をしようとした場合にコンフィグエラーが出ているということですが、ABOSDE から作成した SWU イメージを適用したことで ABOSDE 上のコンフィグ内容(cloud_agent.conf, sensing_mgr.conf) に設定されたと思います。
変更した覚えがなければ初期状態に戻っていますので、使用しているコンフィグ内容について念のためご確認ください。

また、
Howto「Armadillo-IoT A6E のゲートウェイコンテナをカスタマイズする(センサ追加編)」のコードを動かす場合は、
「3. 設定ファイルをカスタマイズする」で説明している sensing_mgr.conf への追記が必要になります。

まずはコンフィグ内容をご確認ください。
以上、どうぞよろしくお願いいたします。

new_bee

2024年6月28日 9時33分

山崎様 
お世話になっております。

> 現在の状況ですが、こちらの Howto「Armadillo-IoT A6E のゲートウェイコンテナをカスタマイズする(センサ追加編)」の、
> 「4. ゲートウェイアプリケーションのソースコードをカスタマイズする」を実行して、カスタマイズ用のコードを配置したものを SWU イメージにして適用したという認識です。

以前VSCode 上のcreate new project 内のA6E GW New Project で作成したものに 
sensing_mgr.confにADCの設定を追加
app/src/以下にコマンドラインで一括でコピーしたはずです。

> AWSへのデータ送信をしようとした場合にコンフィグエラーが出ているということですが、ABOSDE から作成した SWU イメージを適用したことで ABOSDE 上のコンフィグ内容(cloud_agent.conf, sensing_mgr.conf) に設定されたと思います。
> 変更した覚えがなければ初期状態に戻っていますので、使用しているコンフィグ内容について念のためご確認ください。

コンフィグをarmadillo上で編集し、永続化し、 VScode上でも修正しswu アップデートしましたが同様にコンフィグエラーが発生していました。

取得したデータをどのようにAWS上に確認したかっただけでADCを使う予定はありません
またGWコンテナを動かしたときにCPUの温度のみのlogが出力されているだけなのでうまくコピーできてないと考えるのが妥当でしょうか?

今までのAWSとの、動作確認はarmadillo上で直接設定ファイルを書き換えていました。

再度新規にGWコンテナアプリを作成し中身をすべてコピーすれば初期に戻すことはできますでしょうか?

こちらのミスでお手数をおかけして申し訳ありませんがよろしくお願いいたします。

at_reika.yamazaki

2024年6月28日 14時04分

お世話になっております。
山崎です。

>取得したデータをどのようにAWS上に確認したかっただけでADCを使う予定はありません
>またGWコンテナを動かしたときにCPUの温度のみのlogが出力されているだけなのでうまくコピーできてないと考えるのが妥当でしょうか?
ゲートウェイコンテナアプリケーションのクラウド接続の仕組みについては、
Armadillo-IoT ゲートウェイ A6E ゲートウェイコンテナアプリ ソースコードを見てもらうのが良いと思います。
https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-a6e/c…
AWS 接続に使用しているコードは以下にあります。
gw-app-v2.4.4/atgateway/app/cloud_agent/modules/aws_iot_agent/

また、Howto 上部には「[Howto] Armadillo-IoT A6E で ADC を使用する方法」を案内していますが、「使う予定はない」とあるためこちらは実行していないという認識です。
その場合は ADC にアクセスできずに失敗するログが出るはずです。
しかし、CPU温度のみが出力されるということなので、コピーができていない可能性が高いです。
配置したコンフィグファイルについても、AWS 送信しようとした場合にコンフィグエラーしているとの情報から、cloud_agent.conf の内容が怪しいです。
これまでやりとりしている中で、貼っていただいた内容で接続できたとあったため、問題ないと思っていたのですが、その時から cloud_agent.conf の内容が変わっていないでしょうか?

また、以下に念のためコンフィグファイルを初期状態に戻す方法を記載します。
>今までのAWSとの、動作確認はarmadillo上で直接設定ファイルを書き換えていました。
>再度新規にGWコンテナアプリを作成し中身をすべてコピーすれば初期に戻すことはできますでしょうか?
はい。こちらへの回答にもなりますが、ゲートウェイコンテナアプリケーションがコンフィグファイルを置きなおすので、
新規作成した場合は初期状態のコンフィグファイル、アプリケーションファイルを配置します。
アプリケーションファイルは初期状態だと通常のゲートウェイコンテナアプリケーションの動きをするので、この対応は使えます。

置き換え前に現在のコンフィグファイルをリネームして、置き換え後に diff を取るとコンフィグファイルエラーの原因がわかるかもしれません。
以下はリネーム実行用のコマンドです。

mv /var/app/rollback/volumes/gw_container/config/cloud_agent.conf /var/app/rollback/volumes/gw_container/config/cloud_agent.conf_bak
mv /var/app/rollback/volumes/gw_container/config/sensing_mgr.conf /var/app/rollback/volumes/gw_container/config/sensing_mgr.conf_bak

コンフィグファイルを置き換え後、ゲートウェイコンテナを再起動して、コンフィグエラーがなくなったことを確認してください
もし、正しく動くようになった場合は diff コマンドで差分が見れます。
出力された内容がコンフィグエラーの原因の可能性がありますので、ご確認ください。

diff /var/app/rollback/volumes/gw_container/config/cloud_agent.conf /var/app/rollback/volumes/gw_container/config/cloud_agent.conf_bak
diff /var/app/rollback/volumes/gw_container/config/sensing_mgr.conf /var/app/rollback/volumes/gw_container/config/sensing_mgr.conf_bak

もし、状況が変わらないようであればログファイルにコンフィグエラーの内容についてが出力されていないでしょうか?
ある場合はその内容を貼っていただけるとヒントになると思います。
以上、どうぞよろしくお願いします。

new_bee

2024年7月1日 14時02分

山崎様
お世話になっております。

> これまでやりとりしている中で、貼っていただいた内容で接続できたとあったため、問題ないと思っていたのですが、その時から cloud_agent.conf の内容が変わっていないでしょうか?
SWUアップデートしたときにRS485ように設定を変更しようとしていたもので上書きしてしまっているので、ほぼ初期状態のものに変更されてしまっています。
再度登録し直せばと思いAWS IotCore のモノを一度削除しており、コンフィグエラーのため?再登録できていない状態です。
IAMのキーファイルも作成し直しています。

また証明書ファイルを確認したところ以下がありませんでした。
・/var/app/rollback/volumes/gw_container/cert/AmazonRootCA1.pem

cloud_agent.conf の差分を確認したところ初期設定ファイルの違いは
send_cloud をtrue に変更していること、[CPU_temp]のpolling_interval=10に変更されていること
[RS485_Data1]はmethod=noneでボーレート等の設定値が残っているという違いがありました。

またsensing_mgr.confでは新規に作成したアクセスキーが追加されているのみでそれ以外の変更点はありませんでした。

またログファイルには以下が表示されています。
ssse-flw: EmbSe_Init(): Entry
2024-07-01 13:56:39,445 : DO1 output_state parameter is empty.
2024-07-01 13:56:39,452 : DO1 output_time parameter is empty.
2024-07-01 13:56:39,457 : DO1 output_delay_time parameter is empty.
2024-07-01 13:56:39,463 : DO2 output_state parameter is empty.
2024-07-01 13:56:39,469 : DO2 output_time parameter is empty.
2024-07-01 13:56:39,475 : DO2 output_delay_time parameter is empty.
2024-07-01 13:56:39,482 : Getting RS485_Data1 is disable.
2024-07-01 13:56:39,503 : AWS_IOT_CA_FILE /cert/ca/AmazonRootCA1.pem is not existed.
2024-07-01 13:56:39,508 : AWS_IOT_PIN is not found.
2024-07-01 13:56:39,547 : AWS connect start
2024-07-01 13:56:39,553 : Config error
2024-07-01 13:56:39,558 : send device information to cloud.
2024-07-01 13:56:39,562 : network is False, update_publish_shadow() is not send
2024-07-01 13:56:39,573 : {'data': {'CPU_temp': 35.236, 'timestamp': 1719466981}}
2024-07-01 13:56:39,594 : AWS connect start
2024-07-01 13:56:39,600 : Config error
2024-07-01 13:56:39,607 : network is False, update_publish_shadow() is not send

2024-07-01 13:56:39,503 : AWS_IOT_CA_FILE /cert/ca/AmazonRootCA1.pem is not existed.
で出ているようにファイル何等かで消してしまったのが原因でしょうか?

お手数をお掛けして申し訳ありませんがよろしくお願いいたします。

at_reika.yamazaki

2024年7月1日 15時33分

お世話になっております。山崎です。

そうですね。記載したパスに AmazonRootCA1.pem が存在しないというコンフィグエラーになります。
消えた理由は不明ですが、以下のコマンドを実行するとネットワーク経由で証明書をダウンロードして配置することができます。

curl -o /var/app/rollback/volumes/gw_container/cert/AmazonRootCA1.pem https://www.amazontrust.com/repository/AmazonRootCA1.pem

その後ゲートウェイコンテナを再起動してコンフィグエラーがなくなるかどうかご確認ください。

また、提案ですがゲートウェイコンテナをお使いいただくよりも Node-RED コンテナをお使いいただくほうが良いのではないかと思います。
Node-RED はいくつかのノードを組み合わせて、ローコードでアプリケーションを作成する開発ツールです。
Node-RED 開発ガイドに AWS にデータをあげるフローの作成方法について紹介しているので、一度目を通していただけますと幸いです。
https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-a6e/d…

以上、どうぞよろしくお願いいたします。

new_bee

2024年7月2日 14時31分

山崎様
お世話になっております。

証明書を再度ダウンロードし再接続することができました。
ありがとうございました。

> また、提案ですがゲートウェイコンテナをお使いいただくよりも Node-RED コンテナをお使いいただくほうが良いのではないかと思います。
一度clearswuでコンテナを削除し、Node-REDコンテナをswuでインストールしブラウザで起動確認いたしました。
こちらでAWSとの通信をしてみようと思います。

また、今までに作成した画像取得用のコンテナと、ロガーから取得していたコンテナは修正することなく、再度SWUファイルでインストールすればそのまま使用することはできますでしょうか?

宜しくお願いいたします。

at_reika.yamazaki

2024年7月2日 16時18分

お世話になっております。山崎です。

>証明書を再度ダウンロードし再接続することができました。
>ありがとうございました。
接続できたということで良かったです。

>一度clearswuでコンテナを削除し、Node-REDコンテナをswuでインストールしブラウザで起動確認いたしました。
>こちらでAWSとの通信をしてみようと思います。
Node-RED コンテナの起動確認ができたということで了解です。
まずは開発ガイドを参考に、AWS 接続を試してもらえればと思います。

>また、今までに作成した画像取得用のコンテナと、ロガーから取得していたコンテナは修正することなく、再度SWUファイルでインストールす>ればそのまま使用することはできますでしょうか?
はい。作成したコンテナは再インストールすれば一緒に利用できます。
Node-RED コンテナはデフォルトでポート番号 1880 をポートフォワードしているため、他のコンテナとポート番号が被っていない限りは問題ないと思います。

以上、どうぞよろしくお願いいたします。