HATをobnizにつなげるライブラリを作成しました。デモムービーはこちら。ムービーにはありませんが、タッチイベントにも対応しています。Sensorですかね?追伸;このデバイスは3.3v駆動のため、obnizで使うにはちょっと面倒です。5vで使える姉妹商品がいいかも。こんな面白い部品があったんですね!知らなかったです。動きいいですね、素晴らしいです。Sensorになります。プルリクエストいただければ導入致します(持っていないので、弊社でも購入して動かしてみたいと思います!)なるほど、3.3vだと電源の問題がありますね。ライブラリには他にも3.3vの部品がありますし、それ自体は問題ありません。さんPRには少し時間をください。タッチイベントとタップイベントの違いなど、反応の違いが判らない点があるので、もう少し動作検証してAPIに反映したいと思います。パーツ購入されるなら、事前に現時点でのjsをお渡しすることもできます。個別にご連絡ください。Largeがいいと思います。さんかしこまりました。購入して、届きましたらご連絡させていただきます!よろしくおねがいします。さん完成しましたので、PRさせていただきました。PRコメントを参照してください。ありがとうございます!!確認させていただきます。こんにちは!プルリクエストをmergeして確認していたのですが、ジェスチャー検出がなかなかうまくいきません。なにか原因考えられますでしょうか。Largeのvccに外部から3.3vを供給して動かしています。それ以外は直接接続している状態です。入れていただいたdemoの実行画面はこのようになっています。#/seqはカウントアップされているので問題なくi2cで通信はできてそうです。ここからなにか分かりますでしょうか。versionに文字列が出ているので、デバイスから情報を読み取っているのは確かです。;DSP:ID9000r2963;i:B;f:22500;nMsg;s:Rel_1_3_prer1784:NM;と出力されるはずですが、途中から文字化けしているので、受信データが途中から0xFFになっていると思われます。mmと2組の数字が出るはずですが、seqに当たるところの数字が空なので、polling()が受信データが無く空回りしているか、または受信データを無効と判断している可能性があります。こちらもデータが0xFFになっていると思われます。PRするときのコメントにも書きましたが、なぜか受信データが途中から/先頭から0xFFとなる現象が出ています。そのため、0xFFのデータを無効とするロジックを入れてあります。具体的には、FlickHat.jsの下記の箇所です。{先頭データである受信データ長が0xFFはあり得ないため、それをチェックしています。このif文の直前にconsole.log(size)を追加してもらえば切り分けできると思います。)また、4バイトのジェスチャー情報が0xFFもあり得ないため、それをチェックしています。true;のコメントを外してもらえれば、FlickHat.jsの154-156行目で受信データをコンソール出力しますので、これで切り分けできると思います。こちらから逆にAPIの確認ですが、i2c.readWait()に指定するlengthは最大受信サイズのつもりで使用しています。最大サイズであり「そのサイズ以下で受信する場合もある」想定ですが、必ずlength分だけ受信しようとする仕様であれば、実装を変える必要があります。(上述の通り現在は最大サイズ132を指定しているため)以上、ご確認お願いします。ありがとうございます。何度実行しても同じで、i2cエラーは出るときと出ないときがあります。(比較的出ることが多いです)こちらから逆にAPIの確認ですが、i2c.readWait()に指定するlengthは最大受信サイズのつもりで使用しています。最大サイズであり「そのサイズ以下で受信する場合もある」想定ですが、必ずlength分だけ受信しようとする仕様であれば、実装を変える必要があります。(上述の通り現在は最大サイズ132を指定しているため)以上、ご確認お願いします。こちら、必ずlength分だけ取得します。ドキュメントが分かりづらくてすいません。obnizはi2cで相手に対してlength分のデータを共有し、受け取って送ります。length分にならない場合はエラーとなります。相手がi2cにおけるNAKという「それはうまくいきません」という主張をするとエラーとなります。さん、そうであれば、実装を変えて再PRする必要がありますね。コードのイメージだと以下のように。以上、ご確認お願いします。