汝の名はBlueZ - (10) : gatttoolをいじる

GLibのイベントループのことを調べたけど、gatttoolで状態を持ってるのは接続のことだけで、primaryとかの非同期コマンドの実行状態などは管理していない。
なので、これが終わったらこれしたい、というようなことをやりたいのであれば、実行状態を持つように書き換えがいる。
追加するのは、コマンドの開始時と、完了コールバックのところになるだろう。

それを全部に対してやるくらいだったら、コールバック関数のところに自分の関数を呼ぶように作り替えてしまえば、わざわざ何も無いときにポーリングするような作りにしなくても済みそうだ。
だが、処理は1箇所にまとめたいので、ポーリングするようにしようかとも思っている。

---

まずはサンプルとして、TIのSensorTag向けに作ってみよう。
SensorTagはいろいろとセンサーが付いているので、題材として使いやすい。

Characteristicを読んだり書いたりするだけだったら、別にコードを作り込まずともコマンドを入力すれば良い。
今回の目指すところは、こんなところにしよう。

• ボタンを押したらNotifyを受け取り、押されたのがS2かS3かをコンソールに出力する
• インタラクティブモードで起動し、開始コマンド(自作)を打ち込んだら、後は勝手にやってくれる

たったこれだけ？と思われそうだが、準備運動せずに海に飛び込んではだめなのだ。

---

connectやCharacteristicへの操作はコマンドを打ち込むが、Notificationはどうなってるのか知らなかった。
調べたところ、受けとったらコンソールに出力されるようだ。
SensorTagで試してみた。0x6CはボタンのNotificationを許可設定するCCCDで、01:00で許可になる。

[34:B1:F7:D4:FA:33][LE]> char-write-req 6c 0100
Characteristic value was written successfully
Notification handle = 0x006b value: 01
Notification handle = 0x006b value: 00

この辺を受け付けられるところがGLibを使った強みか。
受けとっているのは、interactive.cのevents_handler()。
コンソール出力からソースをgrepできるのがありがたい。

events_handler()は、connectが完了したコールバックで登録されている。
なので、connectの動作をgatttoolのルートでやってしまうなら、そのまま流用できる。
ただ、Characteristic操作と違って開始-終了がCentral側ではわからず通知だけになるので、ここはコールバック時に処理をした方がよいだろう。