mw-B commented 5 years ago

11と同様に、DeguはAWSに登録されているけれど、Shadowが更新されない状況です。

電源の入れ直しも何度も確認いたしましたが、シャドウが更新されず、原因絞り込みのデバッグ方法をお教えいただけないでしょうか？

8883ポートのアウトバウンドが拒否されている可能性を考えて、 GWからmosquitto_pubでGWのモノのShadow更新を試みたところ正常にJSONメッセージで更新されるため、8883ポートは問題なさそうです。

Degu-GW間のThread通信も#10を参照して確認したところ Pingは返ってきますし、Degu側のシリアルコンソールより open threadコマンドで見てもGWは見えているので Degu-GW間の物理的な接続はできているようです。

一点、ユーザマニュアルの手順と異なる点としては DFUでのDeguのアップデートが失敗するため、Degu技術情報にあるファクトリーイメージの利用を参照し、degu-v0.9.3.binとmcuboot-v1.3.0-degu1.bin を使用してファクトリーイメージを作成し、J-linkで書き込みましたがシリアルコンソールやmicroPythonコードは正常に動作してそうなので書き込み自体は問題なく行われていると考えられます。

DeguベースユニットからPostしたものがGWに届いているのか、 GWに届いていたとして、ブリッジされているかの確認をしたいのですが方法をアドバイスいただけないでしょうか？

naomitodori commented 5 years ago

ポートやThreadネットワークの接続状況など、既にご確認いただいたのですね。

DeguベースユニットからPostしたものがGWに届いているのか、 GWに届いていたとして、ブリッジされているかの確認をしたいのですが方法をアドバイスいただけないでしょうか？

DeguからGWにPostしたパケットが届き、ブリッジされているかについてはブリッジサーバーのログから確認できます。
# systemctl status coap-mqtt-bridge.service
下記の通り、 publish message ...　と出力されている場合、ブリッジされています。
● coap-mqtt-bridge.service - CoAP over DTLS - MQTT bridge server
Loaded: loaded (/lib/systemd/system/coap-mqtt-bridge.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2019-07-22 09:05:52 UTC; 18h ago
Main PID: 1668 (coap_mqtt_bridg)
CGroup: /system.slice/coap-mqtt-bridge.service
mq1668 /bin/coap_mqtt_bridge

Jul 23 03:57:51 armadillo coap_mqtt_bridge[1668]: publish message topic: $aws/things/xxxxxx/shadow/update message: {"state": {"reported": {"battery": 0.9376172, "pres" Jul 23 03:57:52 armadillo coap_mqtt_bridge[1668]: publish message topic: $aws/things/xxxxxx/shadow/update message: {"state": {"reported": {"battery": 0.9361406, "pres" Jul 23 03:57:53 armadillo coap_mqtt_bridge[1668]: publish message topic: $aws/things/xxxxxx/shadow/update message: {"state": {"reported": {"battery": 0.9258047, "pres"

mw-B commented 5 years ago

ご教授いただきありがとうございます！

確認したところ、DeguのmicroPython側のポートが5683に対して、 GW側では5684をListenしているコメント出力がありましたので Deguのmain.pyの5684に変更いたしました。

しかし、ClientHelloでつまづいてしまっているようです。。 Jul 25 03:45:54 armadillo coap_mqtt_bridge[1668]: clientError: SSL - Processing of the ClientHello handshake message failed

ohsawa commented 5 years ago

ポートは変えなくて良いです。

GW側では5684と5683の両方でlistenしていますが、 5684は、将来のアップデートのためにdtls向けに開いているポートです。現在のdeguのファームウェアでは使用できずclient helloに失敗します。

ポート5683でCOAPパケットがGWに届くのが正常な状態になります。

mw-B commented 5 years ago

5683に戻して、status確認しました。証明書情報の入力待ちでストップしています。。

Jul 25 04:19:09 armadillo coap_mqtt_bridge[1667]: writing new private key to '/tmp/coap-dtls/key.pem'
Jul 25 04:19:09 armadillo coap_mqtt_bridge[1667]: -----
Jul 25 04:19:09 armadillo coap_mqtt_bridge[1667]: You are about to be asked to enter information that will be incorporated
Jul 25 04:19:09 armadillo coap_mqtt_bridge[1667]: into your certificate request.
Jul 25 04:19:09 armadillo coap_mqtt_bridge[1667]: What you are about to enter is what is called a Distinguished Name or a DN.
Jul 25 04:19:09 armadillo coap_mqtt_bridge[1667]: There are quite a few fields but you can leave some blank
Jul 25 04:19:09 armadillo coap_mqtt_bridge[1667]: For some fields there will be a default value,
Jul 25 04:19:09 armadillo coap_mqtt_bridge[1667]: If you enter '.', the field will be left blank.
Jul 25 04:19:09 armadillo coap_mqtt_bridge[1667]: -----
Jul 25 04:20:45 armadillo coap_mqtt_bridge[1667]: Country Name (2 letter code) [AU]:State or Province Name (full name) [Some-State]:Locality Name (eg, city) []:Organization Name (eg, company) [Internet Widgits Pty Ltd]:Organizational Unit Name (eg, section) []:Common Name (e.g. server FQDN or YOUR name) []:Email Address []:dtls listening on :::5684

ohsawa commented 5 years ago

ストップしているのではなく、完了しているはずです。 (ここで作っているcertとkeyは現在は利用せず平文で通信しているので通信できていない事とは無関係です。)

この状態で、deguからcoapパケットが届くと次のようなログが残るのですが、下記のログが出力されず、且つdegu->gw間でpingが返るのであれば、main.pyが期待した動作をしていないものと思います。

Jul 23 03:57:51 armadillo coap_mqtt_bridge[1668]: publish message topic: $aws/things/xxxxxx/shadow/update message: {"state": {"reported": {"battery": 0.9376172, "pres"

mw-B commented 5 years ago

Degu側のmain.pyをdegu-micropython-samplesのbasec/batteryのコードに置き換え GW側でwpan0をtcpdumpで確認しました。受信したデータが正しいCoAPのフォーマットではないこと(Codeが0.00?)が coap-mqtt-bridge.serviceでJSONメッセージのログが出てこない理由ではないかと疑っています。

05:41:34.447388 IP6 fd02:7043:8d0c:0:f7d5:9822:513c:4341.43007 > fd02:7043:8d0c::1.5683: UDP, length 84
        0x0000:  6000 0000 005c 1140 fd02 7043 8d0c 0000  `....\.@..pC....
        0x0010:  f7d5 9822 513c 4341 fd02 7043 8d0c 0000  ..."Q<CA..pC....
        0x0020:  0000 0000 0000 0001 a7ff 1633 005c 1a34  ...........3.\.4
        0x0030:  4802 0002 1768 537e e35f 52bf bd09 7468  H....hS~._R...th
        0x0040:  696e 672f 3734 4537 4142 3834 4438 3436  ing/74E7AB84D846
        0x0050:  3334 3339 ff7b 2273 7461 7465 223a 207b  3439.{"state":.{
        0x0060:  2272 6570 6f72 7465 6422 3a20 7b22 6261  "reported":.{"ba
        0x0070:  7474 6572 7922 3a20 302e 3834 3435 3933  ttery":.0.844593
        0x0080:  387d 7d7d                                8}}}
05:41:34.549624 IP6 fd02:7043:8d0c::1.5683 > fd02:7043:8d0c:0:f7d5:9822:513c:4341.43007: UDP, length 12
        0x0000:  6006 6d20 0014 1140 fd02 7043 8d0c 0000  `.m....@..pC....
        0x0010:  0000 0000 0000 0001 fd02 7043 8d0c 0000  ..........pC....
        0x0020:  f7d5 9822 513c 4341 1633 a7ff 0014 1ecf  ..."Q<CA.3......
        0x0030:  68a0 0002 1768 537e e35f 52bf            h....hS~._R.

Deguのソースをビルドして、再度動作確認しようと考えておりますが急ぎでAWSにデータが上がることを確認する必要があり、動作確認済みのファクトリーイメージをいただけないでしょうか？

ohsawa commented 5 years ago

最新のソースから作ったファクトリーイメージです。 zipを展開して出てきたファイルをjlinkやjflashでオフセット0で書いてください。書き込むと接続情報は消えてしまうので、一旦AWSから当該のthingを削除して、改めてスマートフォンから登録してください。

degu-factory-20190726.zip

shadowは次のように更新されます。

shadow

mw-B commented 5 years ago

ファクトリーイメージを添付いただき、ありがとうございます。こちらの環境で作成したものと同一ファイルでした。。

また、さきほどのtcpdumpで受け取ったデータもIPv6のヘッダを失念しており UDP--> CoAPとしては、きちんと0.02のPOSTとなっており送りたいデータが正しく送られていることがわかりました。

そのため、GWまでデータは届いているけれど、 coap-mqtt-bridge.serviceでブリッジされていないという状況のようです。

GW側のcoap-mqtt-bridge部分をもう少し詳しく確認する手立てはございませんでしょうか？

naomitodori commented 5 years ago

ご確認いただきありがとうございます。

GW側のcoap-mqtt-bridge部分のデバッグについてですが、現状できることは出力されるログの確認までとなっております。

AWSに対してデータを送信する際、下記のログを出力します。

Jul 23 03:57:51 armadillo coap_mqtt_bridge[1668]: publish message topic: $aws/things/xxxxxx/shadow/update message: {"state": {"reported": {"battery": 0.9376172, "pres"

こちらのログが出力されていないのであれば、仰る通り、ブリッジが行われていないこととなります。

なお、現状エラーメッセージは出力していないのですが(本来出力すべきですので、後日修正いたします)、データ送信時にAWSの認証に失敗した場合、ブリッジは行われません。

もし可能であれば下記をお試しいただけますでしょうか。

・ AWS IoT Coreに登録されている Degu-GW のThingを削除　「Armadillo-xxxxxxxxxxxx」という名前で登録されています。　xxxxxxxxxxxxは Degu-GW のLAN MACアドレスです。

・ DeguのThingについても同様にAWSから削除

・ Deguに記録されている接続情報を消去　ファクトリーイメージを再度書き込むか、　https://open-degu.github.io/technical_specifications/flash_memory_map/#region_usb_mass_storage 　こちらの内容を参照し、消去を行ってください。　・ Degu-GWを再起動し、下記のマニュアルの「DeguをAWS IoT Coreに登録する」から再度実行　https://open-degu.github.io/user_manual/30_setup/

mw-B commented 5 years ago

ありがとうございます。無事にシャドウの更新が確認できました！

open-degu / USER_COMMUNITY

シャドウ更新しないときのデバッグ方法について #19

11と同様に、DeguはAWSに登録されているけれど、Shadowが更新されない状況です。