IoT、MQTT、カメラ

ほとんどのデータツールはあなたのデータベースで止まります。Tablize は物理世界も読みます — 「なぜ注文が間違ったか」が Postgres ではなく倉庫のカメラに存在することもあるからです。

このページは、センサー、産業設備、カメラ、または MQTT を話す任意のデバイスを運用している人向けです。ハードウェアフィードがなければ、このページはスキップしてください。

モデル: Space → Asset → Point

Tablize はセンサーをフラットなリストとして扱いません。物理世界をマップする 3 階層のツリーに住んでいます:

階層	例	含むもの
Space	倉庫 A、冷蔵室 2	Asset。ネスト可能（建物 → フロア → 部屋）。
Asset	冷凍庫 7、コンベヤベルト B、カメラ 3	Point。種類を持つ（センサー / カメラ / メーター / 車両 / …）。
Point	温度、電圧、ドア開閉	時系列読み取り。

この構造により、「sensor-0042-port-B の温度は？」ではなく「昨夜どの冷凍庫がスパイクした？」と聞けます — Agent はどの Asset が冷凍庫で、どの部屋にあり、正常がどう見えるかを知っています。

MQTT 経由の接続

Tablize はあなた専用に EMQX ブローカーを動かしています。デバイスをオンラインにするのは 3 ステップ:

1. ブローカー認証情報を作成。 ワークスペース → Devices → + New device。クライアント ID、ユーザー名、パスワードを取得。
2. デバイスをブローカーに向ける。 Tablize Cloud: mqtts://mqtt.tablize.com:8883。セルフホスト: ブローカーを走らせているホストで、ポート 1883 プレーン / 8883 TLS。
3. トピックにパブリッシュ。 デフォルトトピックスキーマ: {space}/{asset}/{point}。JSON をパブリッシュ: {"value": 42.1, "ts": 1710000000}（ts は任意。デフォルトはサーバー時刻）。

メッセージは即座に TimescaleDB に着地します。パブリッシュから数秒以内に、Agent が point をクエリできます。

対応トピックパターン

• Tablize 慣例 — {space}/{asset}/{point} — 初回メッセージで Asset と Point が自動作成。
• カスタムトピック — デバイスがすでに使っているスキームを貼り、一度限りのマッピングを提供: 「第 2 セグメントは asset_id、第 3 は point_name」。Agent がマッピングルールを書きます。
• 生バイト — JSON を話さないデバイス向けに、デコーダ（Python 関数）をアップロードすると、Tablize が各メッセージで実行します。CBOR、Protobuf、バイナリパックフォーマット、MQTT にラップされたカスタム産業プロトコルでも動作。

Retained メッセージと QoS

• QoS 0 / 1 / 2 すべて対応。デフォルトは QoS 1 — 少なくとも一度の配信、サーバー側でメッセージ ID で重複排除。
• Retained メッセージを尊重。再接続後の「最終既知状態」クエリに便利。
• Will メッセージは別の device_events テーブルに着地 — Tablize はそれらをデータ点ではなくライフサイクル信号として扱います。

Spatial UI

ワークスペース → Spaces → スペースを選択。表示されるもの:

• 左に Asset ツリー。
• 現在選択中の Asset のライブデータカード（Point ごとの最新値、スパークライン付き）。
• 下にタイムスライダー — 直近 30 日（Max なら 1 年）の任意の瞬間にドラッグして、その時の状態を見る。

タイムスライダーがデバッグを楽にする部品です。「コンベヤが正確にいつ止まったか？」 — 分単位でドラッグ、すべての Point の状態を見て、変化が伝播するのを見る。

カメラ

カメラフィードは特殊な種類の Asset（kind = camera）です。2 つのエントリーポイント:

• IP カメラ (RTSP)。 Asset 設定で RTSP URL を貼り付け。Tablize は N 秒（設定可能）ごとにフレームを取得し、Media として保存。Spatial UI でライブプレビュー。
• アップロード動画または画像ストリーム。 HTTP でフレームをプッシュするデバイス向けには Webhook を使用（Webhook と APIを参照）。各アップロードがタイムスタンプ付きフレームになります。

フレームはファーストクラスのデータです。Agent に聞く: 「行方不明の注文が出荷された時刻のローディングドックのカメラを見せて」。Postgres の注文行のタイムスタンプと一致するフレームを見つけて見せてくれます。

連続動画では、ストレージが爆発するためフレームはサンプリングされ、フル動画としては保存されません。カメラごとにサンプルレートを制御します。

フレームに対する AI

Media として保存された任意のフレームを、Agent に抽出のために渡せます:

• 「この写真に見えるすべての SQU を列挙して」 — Agent がビジョン + 商品テーブルで棚の上のものを識別。
• 「この作業員は安全ヘルメットを着用していますか？」 — バイナリ yes/no。Watch に有用。
• 「各時間枠フレームのフォークリフトを数えて」 — 画像から時系列テーブルを生成する Script。

これらの呼び出しは通常の SQL クエリよりトークンを多く使います。Agent は長いバッチの前に警告します。

デバイス上の Watch

最も一般的な IoT ユースケース: Point が閾値を越えたら通知して。

> 深夜に冷凍庫が −15°C を 5 分超えたら通知して。

Agent は適切な Asset のサブセットに対して毎分実行する Watch を作成（Watches を参照）。ルールが発火したときだけ通知が届きます。

Agent は Asset グラフを知っているので、「任意の冷凍庫」を Space 階層内の assets WHERE kind='sensor' AND name ILIKE '%freezer%' として正しく解釈します。デバイス ID を列挙する必要はありません。

ストレージと保持

プラン	デバイスストレージ	履歴保持
Plus	—	IoT 利用不可
Pro	ホット 50 GB、コールド 500 GB	1 年
Max	ホット 500 GB、コールド 5 TB	5 年

「ホット」 = 100ms 未満でクエリ可能。「コールド」 = 解凍に 1〜2 秒、Agent には透過的。カメラフレームと生動画は別 — Media ストレージ枠を共有します。

よくある落とし穴

• メッセージが届かない。 認証情報、TLS、トピック形式を確認。Devices ページに各デバイスの last-seen-at が表示されます。「never」なら MQTT ハンドシェイクが完了していません。
• メッセージは届くがクエリ不可。 通常 JSON パースエラー。Devices ページの Recent messages タブが各ペイロードとパース可否を表示。デバイスのフォーマットを修正するか、デコーダをアップロード。
• カメラフレームが遅延。 デフォルト RTSP サンプルは 5 秒ごと。必要なら 1 秒に上げられますが、ストレージは急速に増えます。
• Watch が発火しない。 Watch のスコープが Asset ツリーに一致するか確認。Agent はチャットでルールに一致する Asset を伝えます — 沈黙を信用する前にそのリストをスポットチェック。

次のステップ

• Watches — デバイスデータの最も一般的な住処。
• Dashboards — 物理世界の運用ビューを構築。