装置が画面を渡す — ボード二枚がそれぞれ自分の定義を渡す

前の一編で窓が二つあると書いた。人が機械を直接扱う窓はMCPが狙った席ではなく、足りないのは画面だと書いた。

この一編は、その画面をどこから持ってくるかだ。

前提をひとつ変える

普通はホストが画面を知っている。どの装置がどの値を出すか、その値をどのウィジェットで描くか、どのボタンがどの命令を送るかをアプリが知っている。だから装置がひとつ増えるとアプリを直す。

変える前提はこれだ。画面をホストではなく装置が定義する。

装置はすでにMCPサーバーとして自分の機能を道具として出している。ここにひとつ足す — 自分の画面を宣言的に記述する。 クライアントはその記述を受けてネイティブに描く。ブラウザも組み込みウェブエンジンも要らない。

するとクライアントは何を描くかを あらかじめ知る必要がない。 初めて見る装置も、つないだ瞬間に扱える。

机の上の二枚

これは言葉にするともっともらしく聞こえる。だから実物で確認した。

ボード二枚だ。STM32H723 はUSBシリアルでつながり、ESP32 はWi-Fiでつながる。発見のしかたも違う — 一方はポートを開けて探し、他方はネットワークで探す。電気的にも伝送路的にも互いに他人である。

各ボードにブリッジが付いて自分の機能を道具として出し、自分の画面をリソースとして出す。そしてクライアントは 両方に対して同一だ。 ボードごとの分岐がない。

画面が出る。ボタンを押すと 机の上のLEDが実際に点く。

このサンプルには規則がひとつ掛かっている — ボードがなければ通さない。 シミュレーションで代えず、どのポートを探したかを明かして失敗で終わる。ハードウェアなしで「検証」されるハードウェアの話は、検証されたことにならないからだ。

つかまえたもの — ボードが正しかった

このサンプルをつくる途中で実ボードが即死したことがある。リソース一覧を読む瞬間に型エラーで落ちた。

原因はボードではなかった。クライアントライブラリが仕様に反していた。 リソースの説明フィールドはMCP仕様では任意なのに、ライブラリがそれを必ずある値として読んでいた。説明を付けなかったボードは規格どおりで、読む側が誤っていた。

同じライブラリを使う他のサンプル四つはその一覧を読まないので無事だった。実物をつないだときだけ現れる場所だ。

画面がそのままロジックだ

「画面を配る」と言うと絵だけを渡すように聞こえる。そうではない。

記述の中には三つが一緒に入る。

• バインディング — 装置の状態が画面の値へ流れ込む
• アクション — 状態変更、道具呼び出し、まとめ実行、そして 条件分岐
• 購読 — 装置の状態変化を受け続ける

この三つを編むと制御になる。温度ノードの値を購読し、それが画面へ流れ込み、条件分岐がしきい値を判定して、ファンノードの道具を呼ぶ。センサーとファンをそれぞれつなぐだけでよく、二つを結ぶコードは書かない。

制御のために別の言語を学ぶのではない。画面を宣言すれば制御がついてくる。

ここまでが一つの装置

一つの装置が自分の画面を渡し、その画面がそのまま操作面だというところまで来た。

現場に装置がひとつだけということは少ない。操舵室には発電機とバラストと燃料が一緒にあり、温室にはセンサーと弁が一緒にある。

複数の装置を一つの画面にまとめる話は二編あとだ。その前に、この構造に インストールという単位がないことを先に書く。