jumpwire.ioを試してみる jumpwire.ioの備忘録2 #jumpwire #IoT #IoTやりてぃー

jumpwire.ioは日本発のIoTデバイス向けサービスです。多分
http://ja.jumpwire.io

さて、問題が無い訳でも無い訳でもない！
いまのところ判っているのは2件

１．接続が切れる
LED.inoでもそうですがシリアルモニターを見ていると時折接続が切れています。
なにが起きているのか判らん時はそうです、パケットモニターで見てみましょう。


接続が切れている手前辺りを調べると、サーバー側から切断する前に特長的なパケットが送られて来ています。
この内容はWebsocketのプロトコルで、送られて来たパケットの内容に不備が有るので切断するよん！って意味です。

ではその不備なパケットは？


「Line-based 云々」をハイライトすると、、、出鱈目なデータが見えてきました。どうやらこれが問題の様です。
この出鱈目を送っているのはESP8266側です。ライブラリではJWIO_ESP8266_ArduinoIDE.cppの
WebSocketSendTextの中のclient.printの様です。正しくbinaryデータを処理できていないのか？それともエンコード中にデータに0が発生しているのか？

そもそも元はキャラクタデータだったとしても、エンコードしてバイナリーデータに変換しているので、本来はbyte型で扱うべきでしょう。
String型で処理する事を止めてbyte型配列に入れてclient.printではなくclient.writeで送信すれば切断される事は無くなりました。少なくとも半日くらい確認。それ以上は判らん、、、


２．接続に時間が掛かる
ちょっと致命的な気もします。ESP8266ではすんなり接続できるのに、XBee wifiだとなっかなか接続できません。
パケットモニターで見てみましょう。


この画面はXBee wifiで接続中の話です。XBee wifiからのSYNにまったく反応していません。XBee wifiはこの後SYNを何度か再送します。この再送を諦めるまではおよそ75秒程度掛かっているようです。その後新しいポート番号を設定して再び接続を試みます。この前やったら接続まで16分掛かりました(笑)。



この画面はESP8266の場合です。しかしESP8266もあっさり無視されています(笑)。
※ESP8266でもATモードで動かす場合はポート番号が固定化されない様である。

XBee wifiとESP8266との違いは再送間隔の違いです。XBee wifiは失敗すると再送までの時間を延長して行きます。3秒、6秒、12秒、、、って感じで。しかしESP8266は再送間隔が約500ms固定です。
どちらの動作が正しいかと言えばXBee wifiですね。ESP8266は再送処理が雑過ぎます。
しかしこのESP8266の雑さのお蔭で見かけ上すんなり接続出来ている様に見えています。
多分ですが、ESP8266を使ったアプリケーションの開発中にこの接続性の良さはだんだん悪くなる方向だと思います。

では何故SYNを無視するのか？うんサーバー側の話なので判りません。

上記2件はjumpwire.ioに連絡済みです。
当分接続はESP8266で行うか、それとも接続されるまでしばらく待ちましょう。