aioble drops notifications
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 45/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- python
- 領域
- embedded-iot
調査の方向性
まず aioble の characteristic *.notified() パスと通知処理を追跡し、次に issue に記載されている血糖測定器の RACP 転送を再現します。rapid glucose measurement と context の通知が上書きされるか、未読のまま残るかを確認します。アプリケーションレベルのインターセプトキューを必要とせずに、転送ですべての通知が配信されれば完了です。
索引モデルが issue の本文から書いたものです。
説明
A glucose meter following the BT-SIG profile only stores measurements which must be retrieved by a Record Access Control Point (RACP) transaction. With aioble one is faced with the challenge of invoking the RACP transaction to transfer the data which causes the device to notify its stored data records. When all have been notified an indication is sent on the RACP characteristic.
One can see the challenge here - there are two nested await operations. Clearly impossible without placing one of these in a task.
Thus the RACP action to transfer is placed in a task.
Then one can write the command on the RACP characteristic.
Follow with a while loop that runs until the task completes (indication received)
The while loop has two consecutive await actions, one on the Glucose Measurement characteristic notification followed by the await on the Glucose Context Measurement characteristic notification. Fortunately the response of the Glucose Measurement Notification has a flag indicating if there is a following context measurement.
The issue is that these notifications are sent basically as fast as the device can dump them. So a log looks like this for a case with 3 stored measurements from a Roche Accu-chek Guide:
2024-11-05 00:16:30 DEBUG bt_sig_glucose: LNI: Number of stored measurements b'\x05\x00\x03\x00'
// the 05, 00 indicates success and the 03, 00 is the number of msmts (little endian)
2024-11-05 00:16:30 DEBUG bt_sig_glucose: LNI: Task to wait for RACP indication started
2024-11-05 00:16:30 DEBUG bt_sig_glucose: LNI: Send RACP command to transfer all records
LNI: AIOBLE: Notify received
LNI: AIOBLE: Notify received
LNI: AIOBLE: Notify received
LNI: AIOBLE: Notify received
LNI: AIOBLE: Notify received
LNI: AIOBLE: Notify received
LNI: AIOBLE: Indication received
2024-11-05 00:16:30 DEBUG bt_sig_glucose: LNI: Waiting for msmts
2024-11-05 00:16:30 DEBUG bt_sig_glucose: LNI: RACP indication: b'\x06\x00\x01\x01'. // Indicates successful RACP transfer all
2024-11-05 00:16:30 DEBUG bt_sig_glucose: LNI: 1b 3b 00 e6 07 08 05 14 08 19 28 1b 2f b0 f8 00 08
2024-11-05 00:16:30 DEBUG bt_sig_glucose: LNI: 02 3b 00 01
2024-11-05 00:16:31 DEBUG bt_sig_glucose: LNI: Waiting for msmts
2024-11-05 00:16:31 DEBUG bt_sig_glucose: LNI: Exiting RACP task.
All the notifications are lost or overwritten by the aioble library except the last two (a single stored measurement contains both a measurement notification and measurement context notification.
Why is aioble losing all these notifications? Is the only way to rescue this problem to write code that intercepts the notification and puts them into an application queue? The aioble queue is clearly overwritten or at least they are not dumped by the *.notified() method as expected: msmt: bytes = await asyncio.wait_for(msmt_char.notified(), 1.0)
I tried the reverse as well - placing the notification handler in a task and invoking the racp commands 'outside'. I also added prints of the received notification bytes at the aioble level. I get the same result:
2024-11-05 11:36:12 DEBUG bt_sig_glucose: LNI: Number of stored measurements b'\x05\x00\x03\x00'
2024-11-05 11:36:12 DEBUG bt_sig_glucose: LNI: Waiting for msmts
2024-11-05 11:36:12 DEBUG bt_sig_glucose: LNI: Send RACP command to transfer all records
LNI: AIOBLE: Notify received 1b 39 00 e4 07 07 1f 0b 2e 09 00 00 8d b0 f8 00 00
LNI: AIOBLE: Notify received 02 39 00 02
LNI: AIOBLE: Notify received 1b 3a 00 e4 07 0b 04 0f 25 02 00 00 93 b1 f8 00 00
LNI: AIOBLE: Notify received 02 3a 00 01
LNI: AIOBLE: Notify received 1b 3b 00 e6 07 08 05 14 08 19 28 1b 2f b0 f8 00 08
LNI: AIOBLE: Notify received 02 3b 00 01
LNI: AIOBLE: Indication received
2024-11-05 11:36:12 DEBUG bt_sig_glucose: LNI: 1b 3a 00 e4 07 0b 04 0f 25 02 00 00 93 b1 f8 00 00
2024-11-05 11:36:12 DEBUG bt_sig_glucose: LNI: RACP indication: b'\x06\x00\x01\x01'.
2024-11-05 11:36:12 DEBUG bt_sig_glucose: LNI: RACP transfer-all task completed. Disconnecting.
LNI: Setting to disconnected
LNI: AIOBLE: Peripheral disconnect. Handle 64
2024-11-05 11:36:12 DEBUG bt_sig_glucose: LNI: 02 3b 00 01
But now it is clearer to see that the first 4 notifications are dropped.
- 主要言語
- Python
- スター
- 2.9k
- フォーク
- 1.1k
- 平均マージ
- 7日 6時間
- マージ済み PR(30日)
- 3
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
micropython/micropython-lib のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
micropython/micropython-lib#1074 ·
-
needs-info
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
micropython/micropython-lib#943 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
micropython/micropython-lib#931 · コメント 1 件 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 62/100
micropython/micropython-lib#795 · コメント 2 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
micropython/micropython-lib#762 ·
micropython/micropython-lib の issue をすべて見る
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
zostera/django-bootstrap4#894 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
use-agent-os/agent-os#3276 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
zephyrproject-rtos/zephyr#119726 ·
-
area/auth bug comp/agent P3 platform/discord type/security
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
NousResearch/hermes-agent#117848 ·