環境制御自動化~

AoTのenv_coordinator(画面上は統合環境制御)は、1つの施設のすべてのアクチュエーター — 換気窓、排気・吸気ファン、ヒーター、冷房機、噴霧器、遮光スクリーン、保温カーテン、 補光照明、CO₂インジェクター — を1つにまとめて協調させる3層制御システムです。

異なる2つの場所で決まる、2つのことがあります。この2つを混同するのが、もっとも よくある混乱の原因です。

• 何を目指すか — VPD・CO₂・DLIなど — は、その施設で育っている区画の ものです。区画に付いた栽培プログラムを通じて決まります。
• どう到達するか — どんな設備があるか、越えてはいけない線はどこか、 目標をどれだけ強く追うか — はこの関数のものです。

目標はどこで決まるか~

区画は選んだプログラムを内在化します。区画画面でステージの目標値を編集すると、 その区画のその項目だけが上書きされ、プログラム本体や同じプログラムを使う他の区画には 影響しません。欄を空にすると、その項目はプログラムの値に戻ります — そのため 「元に戻す」ボタンを別に用意していません。

意図した制約が2つあります。

• 区画は新しい目標項目を作れません。語彙はプログラムのもの(target_defs) なので、未知のキーは黙って無視されるのではなく拒否されます。
• カーブが設定されている項目は、数値で上書きできません。カーブが優先され、 区画画面ではその項目が読み取り専用として表示されます。

コーディネーターが毎サイクル読み込むもの~

目標項目と制御軸は、項目のキー名ではなく測定値の種類と形で結び付きます — 利用者が「室内CO₂」と名付けた項目でも、測定値がCO₂であればCO₂制御に届きます。 測定値を選んでいない項目はどの軸にも届かず、画面には参考のみと表示されます。

区画がないとき~

コーディネーターは止まりません。 区画がない、プログラムがない、まだ確認されて いないAI下書きしかない、プログラムの種類が区画の種類と合っていない、あるいは今日に 該当するステージがない場合は、単に目標がないだけです — 制御は自分自身の推奨範囲の 中で動き続けます。これはすでに定義された挙動であり、栽培中の作物がない温室でも暖房は 必要だからです。

昼夜の温度と湿度が推奨範囲を決めます~

第一目標は引き続きVPDです。ステージの昼温度・夜温度・湿度は目標ではなく、 VPDを暑すぎて湿った組み合わせや寒すぎて乾いた組み合わせで達成することを防ぐガイドです。 コーディネーターは毎サイクル、自分の推奨範囲を次のものに置き換えます。

• 幅は固定で、プログラムの設定ではありません — 栽培技術資料の多くは平均値だけを示し、 昼夜の幅は書いていないためです。
• ステージにその値がない、または施設の位置が分からず日の出・日没が求められない場合、 その項目は機能自身の推奨範囲を使います。
• ハード上下限（Min/Max Temperature、Min/Max Humidity）が最後に適用されます。
• 推奨範囲を読むところはすべて追従します: VPDを分けた温度・湿度、VPD目標がないときの 中央値、予報補正、換気の温度上限。
• 実際に使った範囲は機能設定の区画の下に ガイド範囲 として表示されます。

コーディネーターには自分自身の終了日オプションはありません。 栽培を続けるかどうかは区画が決めます。Functionに日付を持たせると、新しい作物を 植えたあともその日付のせいで施設が止まったままになることがあるためです。

制御の基準 — VPD直接 / 温度優先~

既定はVPD直接です — 上のとおりVPDの目標を追い、温度・湿度はガイドです。高度な設定の 制御の基準を温度優先に変えると、コーディネーターごとに次のように動きます。

• 温度が第一の目標です。 ステージの昼間・夜間温度(施設位置の日の出・日の入り基準)を 追います。
• 湿度の目標はVPDの目標から作ります — その温度でVPDの目標になる湿度です(例: 24°Cで VPD 1.0なら約66%)。誘導範囲の外なら範囲の端で切ります。
• VPDは境界です。 目標より0.4 kPa低くなるか0.8 kPa高くなったときだけ戻す方向に押します。
• ステージに温度がなければ、温度は追わず、誘導範囲内に保つだけです。

VPDを直接追うと、同じ許容誤差が8°Cでは湿度±9%、35°Cでは±1.8%になり、低温では届かない 湿度を求めることもあります。温度優先にはこの差がありません。

どちらを選んでも、もう一方の「その基準だったら送ったはずの指令」を毎サイクル計算して記録します (制御には使いません)。同じ施設で2つの方式を比べるためです。

スコープ内に区画が2つ以上あるとき~

間作・混作は普通に起こることなので、コーディネーターは推測しません。施設・ベイの スコープ内に区画が2つ以上あるときは、そのことを伝えてこれに従うボタンを 出します。同じ選択は、詳細設定の基準区画にも保存されます。指定した区画が 終了したりスコープの外に出たりしても、値は消えません — 画面が「指定した区画は もうここにありません」と伝え、選択ルールをあらためて適用します。

区画に記録されるプログラムのバージョンは、バージョン番号を固定するだけで 内容までは固定しません。プログラムを編集すると、進行中の区画の解釈も 変わります。

VPD(飽差)~

VPDは、植物の蒸散と吸水を左右するもっとも重要な指標です。

VPD = SVP × (1 - RH/100)
SVP = 0.6108 × exp(17.27T / (T + 237.3))  [kPa]

env_coordinatorの制御レイヤー~

L1 — EnvTarget(設定値)~

上で説明した目標を、このサイクルの設定値へと解決します。Methodに従う目標項目は、 区画の経過週数と施設のローカルタイムゾーンで評価されます。

L2 — SituationReport(評価)~

現在の偏差、制限要因、傾向を評価します。

室内の温度・湿度・VPDは、まずノイズを除きます。 センサーの表示刻み(温度0.1°C、 湿度1%)が上下するだけで窓が動かないようにするためです。指数平滑を使いますが、元の値が 温度0.5°C・湿度3%以上離れたら実際の変化とみなし、すぐに元の値に追従します。VPDを 温度・湿度から計算する施設では、除去後の温度・湿度で計算し直します。安全ゲートと ハード上下限は除去前の元の値で判定します — 保護をフィルターの分だけ遅らせません。

VPD目標があり、VPDを測定できるとき、温度と湿度は制約に格下げされます — VPDを 分解して得られる範囲であり、越えてはいけない線です。この関数はサーモスタットでは ありません。

L3 — Coordinator(アクチュエーター指令)~

装置ごとに位置形PIで0〜100%の指令を出します。教科書どおりのPIとは3つの点で 異なります。

• 積分は累積誤差ではなく、その装置の「記憶された平衡開度(%)」で、常に0〜100に 収まります。偏差が小さいときは積分がそのまま残り、直前の開度を保ちます。
• 1つの装置が複数の軸に効くときは、偏差を1つにまとめます。 たとえば開口部は 温度・湿度・CO₂のすべてに影響します。軸ごとの偏差を比例帯(許容誤差 × 6)で割って 同じ尺度にそろえ、優先度 × その装置がその軸に与える効果の大きさで重み付き平均 します。
• 許容誤差の半分以内は休む区間(デッドゾーン)です。その外ではデッドゾーンの分を 差し引いた値を使うため、境界で指令が階段状に跳ねません。

e      = Σ(優先度 × 効果 × 偏差/比例帯) / Σ(優先度 × 効果)
e_eff  = e からデッドゾーン(許容誤差 × 0.5)を差し引いた値
I      = clamp(I + 0.2 × e_eff, 0, 100)          # 記憶された平衡開度
指令   = clamp(1.0 × e_eff × 100 + I, 0, 100)

• 確定の順序はコスト指数の順です(安い装置から)。同じドメインの中では、後の装置は 前の装置が生む効果を差し引いた残りの偏差だけを見ます — これが負荷分担です。
• 動かしても効かない装置は休みます。 100%で動かしても比例帯の2.5%未満しか 動かせない場合(たとえば室内外の差がほとんどない換気)や、パーキング対象の場合は、 サイクルごとに安全位置までの距離を60%に縮めながら、ゆっくり安全位置へ向かいます。 保温カーテンは例外でその場に留めます — 安全位置(開)へ戻すと、夜に室内外の差が 小さくなった途端に保温が外れてしまいます。判定にはヒステリシスがあります — 一度 効くと判定した装置は、しきい値(2.5%)の半分を下回るまで「休み」に切り替わらないため、 しきい値付近で揺れる効果によって窓が開閉を繰り返すことはありません(根拠「主作用」↔「勾配なし」)。
• 日中は保温カーテンを開けておきます。 効果モデルはカーテンの熱交換しか知らず、光を 遮ることは知らないため、施設位置の日の出から日の入りまでは開けておき、夜だけ判断します。 寒波などの安全ゲートはこの規則より優先します。
• カーテン・遮光スクリーンは全閉か全開のどちらかです。 いまの側から反対側へ動くには 指令が60%(開ける)または40%(閉じる)を越える必要があり、50%付近で端から端へ 往復しません。記録と画面にも実際に送った0/100が残ります。
• 押す向きが反転したら、続くかを見てから従います。 換気窓のVPD効果は冷却と乾いた 外気が競り合った合計なので、両者が近いと外気湿度の数%で向きがサイクルごとに変わります。 新しい向きが10分以上(かつ2サイクル以上)続いたときだけ従い、それまではその場に留めます。 室温が誘導上限に届いたときに加わる温度項も、超えた分に応じて徐々に重みを得ます — 線の付近を上下しても換気窓が階段状に上下しないようにします。
• 側窓は風を受ける側を広く開けます。 風を背にした側窓は指令の最小20%まで絞ります。 風速0.5 m/s未満では適用せず、3 m/sまで風圧(風速²)に比例して徐々に強まります — 弱く不安定な風向で側窓がサイクルごとに絞られたり戻ったりしないようにします。
• 目標を越えたまま固まりません。 デッドゾーンの中でも「減らすべき」側の偏差が3サイクル 続くと、その装置は指令をサイクルごとに60%に縮めながら退きます。保温カーテン・遮光 スクリーンも同じです — 効果が開度に比例するので、減らす側がそのまま効果を減らす側です。
• 積分の暴走防止。 100%で頭打ちになると、はみ出した分を積分から戻し、0%で 頭打ちになるとそのサイクルの積分を止めます。一方の端に張り付いたままなら、積分を 実際の開度のほうへ寄せていきます。
• 変化速度の制限。 1サイクルあたり最大20ポイントまで動きます。Actionに全ストローク 時間があり、その装置が実際に動ける量のほうが小さいときはその値を使います。カーテン・ 遮光スクリーンは一動作で開閉するため対象外です。5%未満の指令は0として送ります。

VPDモードの温度上限。 VPDを直接制御しているとき、温度は制御目標ではありません。 そのままでは暑くなっても換気窓を開ける力が働きません。そこで、次の判断時点の予想温度 (現在値 + 上昇率 × 周期)が推奨上限の1°C手前に届くと、換気装置に温度の項を加え、 超えた分だけ重みを大きくします。一度入った項は、予想温度がその線よりさらに0.5°C 下がるまで切れません — 線の上に留まる温度のせいで換気窓が「冷やす」と「休む」の間を 行き来しないようにするためです。最高温度のハード上限に届くと冷房機にもかけ、冷やす 方向と逆らう他の軸の項を外します。それでも偏差に比例するPIのままで、何も100%に 強制しません — 外気のほうが暑ければ、換気窓はむしろ閉じる方向へ動きます。

アクチュエーターのドメイン~

負荷の分担はドメインの中で起こり、ドメインの区切りは装置の見た目が似ているか ではなく、エネルギーの行き先が同じかで決まります。設定画面もおおむね同じ 区切りですが、補光照明だけは例外で、スクリーンと同じ「光と遮光」で設定します。

ドメイン同士は互いの仕事を見ないため、ドメイン間の調整は効果の暗黙の積み上げでは なく、明示的なインターロック(換気参照)で行います。

屋根換気口と側面換気口は挙動が違う~

どちらもopeningアクチュエーターですが、施設図面は棟(屋根)窓と側窓を区別し、 効果モデルもそれを使います。

図面に形状の指定がない場合は、天窓・側窓を区別せず同じモデルで動作します(補正なし)。

Function設定~

AoT UIでFunction → 統合環境制御に移動します。アクチュエーター自体は別途 登録するか(アクチュエーターの登録参照)、連携施設から自動的に 検出されます。

設定画面の読み方~

以下の表を読む前に知っておくとよいことが5つあります。

画面の最上部にステータスヘッダーがあります。 施設選択欄の下に、制御が今 何をしているかが表示されます — 追従している軸ごとの現在値と目標(VPD・温度・湿度・ CO₂・光量)、デバイスの種類ごとの状態(開口部、冷暖房、加湿、遮光…)、最後に判断して からどれくらい経ったか。次の行は、この施設が軸ごとに実際に何を調整できるかを伝えます — 両方向、上げるだけ、下げるだけ、見るだけ、センサーなし。その下の2行の要約は、 追従している区画・ステージと、現在適用中の目標を伝えます。動かせない状態はそれぞれ 別の文で示されます — この施設に連携された環境制御がない、制御がオフ(代わりにこの 施設を動かしている制御があればその名前まで)、このコーディネーター自身の基準時間を 超えて判断がない、まだ1サイクルも回っていない。施設を選ぶ前はヘッダーは空のままです — 選択欄がすぐ上にあるからです。区画が2週間以内に終了する場合は、その旨の1行が 追加されます。

設定はオプションの種類ではなく、4つの層に並んでいます。

中心となる設定は、その詳細を引き連れて動きます。 誰も答えられない数値 (「緊急判定の倍率は3.0にすべきか4.0にすべきか?」)を尋ねる代わりに、答えられる 質問をして複数の値を一度に動かします — ロボット掃除機の静音/標準/強のような やり方です。そうした操作は3つあります: 制御の性格、換気・冷暖房の連携、噴霧の 頻度です。段階の名前そのものは保存されません — 保存されるのは実際の値だけで、 今どの段階かはその値から逆算されます。どの段階とも一致しない場合はカスタムと 表示されます。

範囲はハンドルが2つの帯として尋ねられます。 温度と湿度には質問が1つだけ あります — どの範囲で育てるか。ハンドルをドラッグすると、越えてはいけない線が固定の 余裕(±5°C、±5%RH)でいっしょに動きます。ドラッグしなければ、ハード上下限は出荷時の値 (5〜35°C、30〜90%)のままです。帯ではハード上下限を推奨範囲より狭くできないため、 「12~32°Cで育てるが30°Cは絶対に超えない」という表現はできません — この組み合わせが、 ヒーターと冷房機を互いに逆らわせる設定です。[詳細]で数値を直接入力してそうなった 場合、保存したその場で知らせます — どの軸か、2つの範囲は何か、実際にはどの範囲の 内側でしか目標を立てないかまで。その軸の4つの値のいずれかを今回いっしょに保存した ときに表示されます。そのうえでコーディネーターは推奨範囲をハード上下限の内側に 狭めて使い、そのことをログに残します。

[詳細]スイッチ1つで、すべての数値欄が開きます。 段階スケールごとにその 数値入力欄が併記され、詳細専用の行がすべて現れ、折りたたまれたグループも一度に 展開されます。このスイッチはブラウザ内だけのもので、保存される設定の一部ではない ため、同じFunctionを2人が別の見え方で見ることはありません。親トグルがオフの 設定は無効化されるのではなく非表示になります。 そのため保存済みの値は そのまま送信され続け、トグルをオフ/オンしても消えません。

一部の設定は特定の条件下でのみ読まれます — カスタム駆動周期はプロファイルが カスタムのときだけ、夜間の時刻欄は夜間を固定時刻で判定しているときだけ 使われます。入力されているのに使われていない値がある場合、画面はそれを 知らせます。そうしないと、黙って何も起きないだけになってしまうからです。

コマンド~

上の2つのコマンドのあとは、次のサイクルを1回だけ緊急として扱います — 換気窓が 駆動プロファイルの間隔を待たずに動くことがあります。

施設設定~

稼働時間~

トグルをオンにするまでは、それ以外の項目は表示されません。これは時間帯別の 制御ではなくスイッチです。時間帯の外では、目標追従(L1〜L3)が完全に止まります — 暖房・冷房も含みます。それでも保護は続きます。

• 事前安全ゲート(降雨・強風・高温緊急・低温緊急など)は 毎サイクル評価され、作動すればその強制指令を送ります。強風時に風上側の窓だけを閉じる 部分ゲートも同じです。
• 温度/湿度のハード上下限の防ぐ側もそのまま働きます。たとえば室内が最低温度を 下回ると、開口部と保温カーテンを閉じ、冷房を止めます。ハード上下限はもともと装置を 駆動しないため(暖房機を入れることはしません)、時間帯の外でも「停止」とぶつかりません。 光量の上下限は補光灯を点ける駆動なので、時間帯の外では使いません。
• 上の保護指令を受けなかった装置には、それぞれの終了時の動作を送ります。時刻は施設のローカルタイムで判定し、施設のタイムゾーンが 分からない場合はサーバーの時刻を使います。

目標と応答性~

[詳細]を開くと、各範囲帯の裏にある4つの数値(推奨最小/最大温度、 最小/最大温度、および湿度の対応する値)が表示され、制御の性格はそのメンバーを 表示します。

同じ場所にさらに2つのメンバーがありますが、これらは段階では設定されません — 同じ軸の上での微調整だからです。カスタム駆動周期(秒) — プロファイルが カスタムのときだけ使われます — と、緊急時の最小間隔(秒)(既定60)で、 緊急時であっても2回の換気窓指令の間に空ける最小の間隔です。

駆動プロファイルが左右するのは、側面/屋根の換気窓が動くことを許す頻度だけです。 センシングと計算は毎サイクル周期で常に実行され、カーテンや遮光スクリーンは 影響を受けません(一動作で開閉するため)。安全ゲートの強制指令(降雨・強風時の閉鎖など)は この設定に関係なくその装置にだけ即座に送られ、強制を受けていない他の換気窓はこの 間隔を守ります。この間隔をまるごと飛ばす緊急は、室内温度が急変したときと、偏差が緊急 判定しきい値を超えたうえでなお広がり続けているときだけです — 目標から離れたまま 留まっているだけでは緊急ではありません。

換気~

換気と冷暖房の連携は、3つのトグルを一度に動かします。

• 換気で目標に届かないときは開口部を閉じる — 換気は室内を室外の方向にしか 引っ張れません。目標が外気の反対側にあるとき、開口部を開けば開くほど目標から 遠ざかります。典型例は夜間の除湿で、外気が室内より湿っている場合です。これを オンにすると、開口部と排気・吸気ファンは、一晩中中途半端に開けておくのでは なく、閉じたままパーキングされます。
• 換気で目標に届くときは冷暖房を休ませる — 外気がすでに目標を超えている とき、換気だけで到達でき、そこで冷暖房を一緒に動かすのは外気がタダでやって くれることに料金を払うようなものです。3つの条件がすべて成り立つ必要があります — 外気の値が許容誤差を超えて目標を上回っている、制御対象の変数のすべてが そうなっている、そして開口部にまだ余裕がある(直近サイクルの最大開度が90% 未満)。外気が目標までの一部しか埋められないときは、冷暖房はその分を差し引いた 残りの偏差だけ働きます。15分経っても目標に届かない場合は、すべてが暖房・ 冷房へ戻されます — 予測が外れたということです。降雨・風速の値が途絶えて開口部を それ以上開けられない間は、この判定そのものがオフになります — それ以上開けられない 窓の助けを当てにして冷暖房が引き下がってはいけないからです。
• 冷暖房が動いている間は開口部を閉じたままにする — 稼働中の機器に逆らって 換気すると、その熱や冷気をそのまま外へ捨てることになります。外気が目標に 近づくのを助けてくれる季節であっても、この設定はその助けも一緒に捨てて しまいます。

稼働中の機器を検知するには根拠が必要で、その情報源は2つしかありません — このコーディネーター自身がその機器に指令を出しているか、稼働すると値が上がる 測定値を信号として指定しているかです。室内温度は意図的に使いません。 日射の強い 昼間は冷房機がなくても室内が室外より涼しくなることがあり、「室内が室外より涼しければ 冷房が動いている」という判定は、余裕を持たせてもしばしば外れます。

信号自身に鮮度の上限がない場合、その信号自身の測定周期(×2、下限300秒)で 判定されます。期限切れの信号は稼働していないとみなされ、その旨が記録されます。

夜間閉鎖があるのは、夜になると湿度が上がり結露するためです — 夕方には 役に立っていた開口部が、朝には作物を濡らしたままにしてしまうことがあります。 そのサブ設定は、トグルがオンのときだけ現れます。

閉じておくほうがかえって危険になると、自分で解除します。温度・湿度のハード上下限を 超えたとき、そして結露が迫っていて、換気がそれを和らげるときです。結露が迫るとは 室内温度と露点の差が2°C未満であること、和らげるとは外気を少し混ぜたときにその差が 広がることです。冷たく湿った外気は室内を冷やしてかえって結露を招くことがあるため、 外が乾いているというだけでは開けません。解除後は、差が3°Cまで回復するか換気が役に 立たなくなったときに再び閉じます。外気の値が分からなければ解除しません。

3つの保証が成り立ちます — 安全ゲートが優先します(真夏の夜の熱でも換気窓は 開きます)、ハードな温度/湿度の上下限がパーキングを解除します、そして太陽時刻を 計算できる座標がない場合は何もパーキングされません。これとは別に、夜間閉鎖に 限らない4つ目の規則があります — 外気の値そのものが分からないとき(キャッシュが 空で、外気=室内と仮定した合成値しかないとき)は、そもそも通気口を閉じず、今の 位置をそのまま保持します。このサイクルで他のどのルールがすでに下した閉鎖判定も、 この保持が上書きします(ただし降雨・強風などの非常用安全ゲートはこの保持よりも優先され、閉じることがあります)。作り物の外気=室内の値を根拠に閉じてしまうと、気象データ 源が止まった際に真夏の日中でも通気口が閉じたままになりかねないためです。時刻は 施設のローカル タイムゾーンで読み取られ、サーバーのものではありません。施設のポップアップでは、 このオプションでパーキングされたデバイスは夜間のため閉じ、冷暖房で管理して いますと表示され、このデバイスが今できることは何もありませんとは区別されます。

冷暖房・加湿~

噴霧バルブはほとんどの場合オン/オフしかできないため、流量を絞る手段はありません — 調整できるのは、1回の作動がどれだけ続くかと、次までどれだけ待つかだけです。 この段階スケールが設定するのはそれです。

日焼け保護は頻度とは別の判断です — 2つを分けておくことで、 「頻繁に噴霧しつつ強い日差しでは遮断する」という組み合わせを指定できます。

保護の有無にかかわらず、湿式噴霧器は連続変調ではなくパルス投与されます — 連続的な 変調では葉が乾く暇がないためです。1回の時間と間隔は噴霧の頻度スケールの値を使い (出荷時のひんぱんに: 1回最大20秒、乾燥間隔600秒)、値が空のときだけ30秒/180秒で 動きます。

湿式噴霧は最高湿度のハード上限より手前でも遮断されます。湿度がこのサイクルの湿度の 基準(VPD目標から分けた湿度、推奨範囲内)+ 5% を超えると遮断し、湿度が分からない ときも遮断します。すでに湿った空気の中で葉をさらに濡らさないためです。霧タイプ (高圧ミスト)は対象外です。

光と遮光~

どちらの端もオフにでき、オフの意味は両端で異なります — 下側のハンドルを0にすると 補光しない、上側のハンドルをオフにすると遮光しないです。施設に遮光スクリーンや 補光照明が登録されていない場合、画面は何もしないハンドルを出す代わりにその旨を 伝えます。

遮光側の基準線は、閉じたスクリーンの下の光量ではなくスクリーンを開けたらどれだけ 明るいかで判定します — そうしないと、閉じた瞬間に暗くなって判定が解け、次のサイクルで また開いてしまいます。屋外の光量が分からない場合(室内センサーのみの設置)は、現在の 値で判定します。遮光が効いている間は、補光と開放を同時に強制しません。2本の基準線を 同時に満たせないとき — スクリーンを閉じると補光の基準線より暗くなる設定 — は遮光を 優先し、その矛盾をログに一度だけ書き出して、人が直せるようにします。

裏にある実際の値は最小光量しきい値(補光)(既定0)と最大光量しきい値 (既定800)で、どちらも[詳細]の下に表示されます。

関連する3つの値はこの画面にはありません。

• 遮光生地の透過率は施設側の設定で、施設エディターの遮光カーテンの下に あります。室内の光センサーがないときにのみ使われ、そのときは屋外日射と 開度から室内の光量を推定します。未設定または範囲外の値は0.50にフォール バックし、施設が遮光カーテンを持たないと宣言している場合は1.0が使われます。 1画面だけ生地が異なる場合は、そのActionで個別に上書きできます。
• 被覆材の透過率は外皮の資材から自動的に決まります(ガラス0.85・二重フィルム0.78・ 不織布0.50など)。遮光スクリーンがなくても屋根は常に光を減らすため、 室内光量の推定にあわせて掛けています。そのため光量の上下限は室内基準です。同じ250でも、 ガラス温室と不織布ハウスでは作物が受ける光が2倍近く違います。
• 光飽和点は遮光しきい値ではなく、プログラムにある作物のK_Lから導かれます。 この2つを1つの値にすると、遮光しきい値を下げた途端に光合成モデルが「もう十分な 光がある」と判断し、強い日射の下でも光制限を検出できなくなります。K_Lがない場合は、 システムの既定値600 W/m²が使われます。

詳細設定~

このグループは既定で折りたたまれており、Functionを試験するエンジニア向けで、 生産者向けではありません。

効果キャリブレーション~

予報フィードフォワード~

デバッグログはもう独立したオプションではありません。 これはフレームワーク 自身のデバッグスイッチと重複しており、それが守っていたもののほとんどはDEBUG レベルで書き出されていたため、単独では何も出力していませんでした。Functionの 詳細設定にある1つのスイッチが、今では両方を兼ねています。重大なイベント — 安全ゲート、送信失敗、実行状態のエラー — は、この設定に関係なく常に記録 されます。

アクチュエーターの登録~

連携施設の図面に描かれたアクチュエーターは自動的に検出されます。それ以外は このFunctionに環境制御アクションを登録します — デバイス1台につき1回、この アクションを追加してください。手動登録は、施設から検出されたリストとマージ されます。

デバイス種類ごとの自動変換~

指令は常に0~100%として算出されます。アダプターはOutputモジュール自身の メタデータから選ばれ、追加設定は不要です。

湿式噴霧器は、さらにパルス投与でラップされます — 1回の噴霧は最大作動時間で 打ち切られ、乾燥間隔が経過するまでは一切噴霧しません。

かんがいの流量は施設図面から集計されます — あるレイヤー下のすべてのエミッターが そのアクチュエーターのflow_lpmに合算され、容積式アダプターがそれをそのまま 使います。フォールバックの順序は、アクチュエーターごとの流量、次に施設全体の 合計、それもなければ1.0 L/minです。

噴霧器の効果モデルは別の流量を使います — そのアクチュエーターのドリップ以外の 噴霧ノズルの流量だけを見て、フォールバックしません。投与量には根へ向かうドリップが 含まれますが、空気中へ蒸発する量には含まれないからです。そのため図面にノズル情報が ない噴霧器は、施設全体の合計を引き継ぐのではなく、冷却・加湿の効果がまったくない ものとして計算されます。

測定のない軸、装置のない軸~

施設ごとに備えている装置は違います。測定はできても動かす手段がない軸、逆に動かせても 測定する手段がない軸は、どちらも普通の構成です。コーディネーターはその組み合わせを 見て、自分で動き方を変えます。

関数設定のいちばん上にある調整可能の行が、この組み合わせを軸ごとに一語で示します (温度・湿度・VPD・CO₂・光量)。装置の構成と直近のサイクルで測った値からコーディネーターが 計算したもので、語にマウスを重ねると、その軸を動かす装置の名前が表示されます。

装置もセンサーもない軸は表示しません。開口部がCO₂を少し下げるような、副次的な効果 だけで動く軸も、センサーがなければ表示しません。VPDは温度と湿度の両方の装置を 合わせて見ます — 加湿の噴霧はVPDを下げ、換気は外気が乾いていればVPDを上げます。 この行は今のところ表示専用で、制御は上の表の規則どおりに動きます。

安全ゲートも同じ規則です。 室内の値が途絶えると、ゲートはその事実に名前を付けて 画面とログに残しますが、強制指令は作りません。 すべての装置を安全時デフォルト 位置へ動かすこと(開口部は閉じ、スクリーンは開く)は、根拠がないという理由で 設備を動かすことになるためです。外気の値が途絶えたときと同じ判断であり、制御を まるごと止めることもしません。CO₂や光量のように、まだ測定できる軸は制御を続けます。

降雨・強風のように外気だけで判断できる危険は、そのまま防ぎます。 逆に、高温緊急・ 低温緊急は室内温度が分からないときは判定しません — これらのゲートはすべての装置を 一方向へ動かすため、根拠が確かなときだけ作動するべきだからです。

食い違った組み合わせはヘルスチェックも知らせます:

python3 -m aot.scripts.check_env_coordinator_health

目標はあるのに測定がない場合、目標はあるのに装置がない場合、装置はあるのにその装置が 動かす軸を1つも測定できない場合を設定チェックに報告します。測定だけがあり、目標も 装置もない軸は報告しません — それこそが参考値だからです。

安全時デフォルト位置~

各アクチュエーターには、安全ゲートが作動したとき、緊急停止時、または外部からの force_safe_state()呼び出し時に移動する安全な位置があります。この位置はデバイスの 種類に従います — 保温カーテンと遮光スクリーンは100%でパーキングし、それ以外は 0(オフ)です。施設図面から検出されたアクチュエーターでも、アクションで登録した ものでも同じです。

Method(設定値カーブ)~

Methodは、設定値が時間とともにどう変わるかを定義します。Methodはこの Functionではなく、プログラム側の目標項目に付けられます — カーブが設定された 項目は区画画面でカーブに従うと表示され、数値で上書きできません。

• Daily — 時刻(HH:MM)ごとの設定値
• Duration — 開始からの経過時間ごとの設定値
• Daily Bezier — なめらかな日周カーブ
• Repeating — 繰り返しパターン

生育週で進行するカーブは、区画の開始日から評価され、施設のローカルタイム ゾーンの深夜0時に読み取られ、区画画面や区画の日誌が使うのと同じ経過週数から 計算されます。

作物ステージスケジュールの例(トマト):

SEED:から始まるMethodはシードプリセットで、読み取り専用です。編集する前に プリセットを複製してください。

安全ゲート~

安全機構はL1~L3の協調アルゴリズムの外側で動きます — 毎サイクルL1~L3の前に 確認するPre-Gateと、L3の結果を送信前にサニティチェックするPost-Gateです。 一度作動すると、Pre-Gateは最後に作動してから最低300秒はアクティブなままです (急速なオン/オフの繰り返しを防ぐため)。ゲートが解除されると、ゲートが動かした装置は ゲートが置いた位置から平衡を探し直します。ゲート前の平衡開度へすぐ戻ることは しません — その間に条件が変わっている可能性があるためです。ゲートの強制指令は駆動周期を 待たずに直ちに送られ、ゲートが立っている間は毎サイクル送り直されます。ゲートが強制 しなかった装置は通常の駆動周期をそのまま守ります — 1つの装置にゲートが立っていても、 施設の残りが速くなることはありません。

Pre-Gate(L1~L3の前に確認)~

値の途絶は緊急事態ではなく制約です。 室内の値の途絶と屋外の雨・風の途絶は、 どちらも強制指令を作らず、300秒の保持もかけません。この2つだけが作動しているときは L1~L3が通常どおり実行されます。根拠がないという理由で設備を動かさないという規則で あり、動かすかどうかはコーディネーターが軸ごとに判断します。

降雨・高温・低温のしきい値はコードに固定されています — 強風だけが Functionのオプションとして公開されています。複数のゲートが同時に作動する こともあり(例: 降雨+強風)、その場合は方向にかかわらず開口部は無条件に 閉じます。

ゲートが作動したサイクルも、サイクルであることに変わりありません。 ゲートが サイクルを早期に終わらせると、簡略化されたサマリーが書き込まれ、サイクルには タイムスタンプが付きます — そのため施設ウィジェットは、コーディネーターが 応答不能になったと報告するのではなく、実際に何が起きたかを表示し続けます。この 簡略化されたサマリーにも、そのサイクルで実際に測った環境値はそのまま載ります — ゲートが作動していてもセンサーは測り続けているからです。省かれるのはL1~L3が 作り出したはずの値(目標や偏差など)だけです。デバイスもゲートが強制したものだけで なくすべて一覧に残ります — 触れていないデバイスには0%ではなく、指令自体が 記録されません。

Post-Gate(L3の後、送信前に確認)~

緊急停止と安全状態~

緊急停止のあと、次のサイクルは60秒遅延します。直後にアクチュエーターが 動かないのはこの遅延であり、故障ではありません。

トラブルシューティング~

AI連携~

AoTのAIチャットと、MCPで接続したAIは、次のツールでこのコーディネーターを扱います。 書き込みツールはすべて人の承認を経ます。

目標はこのFunctionではなく、区画のステージ計画にあります。1つの区画の目標だけを 変えるには、区画画面で編集します。AIはプログラムを編集するツール(modify_program)で ステージの目標を変えることもできますが、そのプログラムを使うすべての区画に適用されます。

関連ページ~

• AIの機能概要
• Functionガイド
• Methodガイド