ステータス読み取りは、プリンターが「今どうなっているか」を知るために使います。オンラインか、用紙切れか、カバーが開いているか、過熱しているか、電池残量はいくらか、バージョンやシリアル番号は何か、といった情報です。これは印刷内容の書き込みとは別の経路です。書き込みは命令をデバイスへ送る役割を持ち、ステータス読み取りはデバイスから返るデータを受け取って解析します。

すべてのプリンターがすべてのステータスに対応しているわけではありません。同じ ESC、TSPL、CPCL を使っていても、ファームウェアによって一部のクエリだけに対応していたり、特定の異常が発生したときだけ能動通知したりする場合があります。

1 回のクエリの流れ

典型的なステータスクエリは、次の経路を通ります。

1. アプリがクエリ命令を書き込む、またはデバイスの能動 notify を待ちます。
2. プラットフォーム転送層がデータを受信し、receive source へ渡します。
3. receive source が生の bytes を query dispatcher へ渡します。
4. query dispatcher が現在の pending query の response matcher で、このデータが待っている応答かを判断します。
5. マッチしたら、raw bytes を対応する方言の parser へ渡します。
6. parser は typed response を返します。例: status、battery、version、model、serial number、MAC、unknown。

pending query がない場合、受信データは通常の通知イベントとして扱えます。pending query があるものの matcher が一致し続けない場合、クエリはタイムアウト後に失敗します。

受信ソース

NIB の receive source は、「デバイス応答を SDK に入れる」入口にすぎず、業務上の意味は解釈しません。

ソース	説明	よくあるシーン
callback / notify	プラットフォームが BLE notify、システム callback、プラグインイベントを受け取った後、SDK へ能動的に渡します。	BLE notify、モバイル Bluetooth プラグイン。
polling	SDK が read をループ呼び出しし、空でないデータを読めたら listener へ通知します。	ネットワーク、USB、クラシック Bluetooth、または read API だけを持つデバイス。
device receive source	デバイスオブジェクト自身が receive source を公開し、session が直接接続します。	プラットフォームラッパーが notify/read をすでに処理している場合。

どれを選ぶかは、プラットフォーム API とデバイス能力によって決まります。BLE では通常 notify を優先します。安定した notify がない場合に、polling または明示的な read を検討します。

pending query とタイムアウト

query dispatcher は一度に 1 つの pending query だけを追跡します。クエリを開始するときは matcher と timeout を渡します。

状況	結果
matcher が typed response を返す	クエリが完了し、業務側は解析後の結果を取得します。
matcher が空値を返す	このデータは現在のクエリ結果ではないため、待機を続けます。
matcher が例外を投げる	現在のクエリは失敗します。
receive source がエラーまたは close を報告する	現在のクエリは失敗します。
timeout を超える	現在のクエリは失敗し、後から遅れて届いた応答でこのクエリが自動完了することはありません。

タイムアウトは、必ずしもプリンターの故障を意味しません。デバイスがそのステータスに対応していない、notify の購読に失敗した、クエリ命令と方言が一致していない、または転送層が応答を receive source へ渡していない可能性があります。

方言解析の範囲

NIB は現在、ESC、TSPL、CPCL の一般的な応答解析をカバーしています。

方言	よく解析する内容
ESC	ステータス、電池残量、バージョン、型番、名称、シリアル番号、MAC、および一部の能動イベント。
TSPL	ステータス、電池残量、バージョン、型番、名称、シリアル番号、MAC。
CPCL	ステータスフレーム、通常ステータス、電池残量、バージョン、型番、名称、シリアル番号。認識できない MAC や特殊応答は unknown として保持します。

typed response の unknown は、「データは受信したが、現在の parser はこの形式を認識していない」ことを表します。これは transport failure とは異なります。transport failure は接続、read、notify、receive source 自体の失敗であり、通常は解析可能な raw response を得られません。

導入時のおすすめ

ステータス読み取りは print session または device service に置き、UI コンポーネントへ分散させないでください。導入時はまず次の 3 点を確認します。

1. このプリンターとファームウェアが、読み取りたいステータスに本当に対応しているか。
2. クエリ命令、response matcher、parser が同じ方言に属しているか。
3. receive source が起動済みで、notify/read のデータが dispatcher に入っているか。

ユーザーインターフェイスには「用紙切れ」「カバーオープン」「低電量」などの結果を表示できます。ただしログと調査では、生の段階を残してください。応答がなかったのか、応答は未知だったのか、それとも接続/読み取りが失敗したのかを区別できるようにします。