Skip to content

全体アーキテクチャ

対応 Issue: #1 全体アーキテクチャ・技術選定

構成図

┌─────────────────────────────────────────────┐
│ Unit CamS3-5MP / ESP32-S3                     │
│  工場 OSS ファーム (UnitCamS3-UserDemo) を拡張 │
│   ├─ HTTP REST API                            │
│   │    capture / stream / control / config    │  ← Phase 1 でそのまま流用
│   │    start_poster (EzData)                   │
│   ├─ WiFi AP "UnitCAMS3-WiFi" (192.168.4.1)   │
│   │    / STA (既設 WiFi 接続)                  │
│   └─ [追加] BLE GATT 制御                      │  ← Phase 2 / 独自実装
│        WiFi 再接続ウォッチドッグ                │
│        独自インターバラ・ファイル列挙 API       │
└───────────────┬───────────────────────────────┘
        BLE(制御) │ WiFi(画像転送)

┌─────────────────────────────────────────────┐
│ スマホ PWA (モバイル Web)                      │
│  ライブ / 設定 / ギャラリー /                  │
│  タイムラプス生成(ffmpeg.wasm) / 投稿           │
└───────┬──────────────────────┬────────────────┘
        │ HTTPS                │ (任意)
        ▼                      ▼
┌──────────────────┐   ┌──────────────────┐
│ Cloudflare       │   │ EzData クラウド    │
│ Workers          │   │ インターバル画像の │
│ (SNS 中継・鍵秘匿) │   │ 共有プレビュー     │
└───┬──────────────┘   └──────────────────┘

  X / Instagram

設計の要: 「作る」のではなく「拡張する」

工場ファームが REST API・ストリーム・クラウドアップを既に備えるため、デバイス側はフォーク拡張スマホ側は PWA クライアントとして実装する。これにより Phase 1 を最短で立ち上げられる。

主要な技術制約と決定

制約内容決定
工場ファームは WiFi 専用BLE 非搭載BLE は Phase 2 でファームに追加実装
Web Bluetooth は iOS 非対応iOS Safari が Web Bluetooth をサポートしないiOS は WiFi-REST 制御に縮退(機能パリティ維持)
mixed-contentHTTPS な PWA から HTTP の ESP32 への直接 fetch はブロックされる配信方式をフェーズで切替(下記)
WiFi 切断復帰不能ESP32 が長期運用で切断したまま復帰しない事例再接続ウォッチドッグを必須化

配信方式(mixed-content への対処)

フェーズ配信元API アクセストレードオフ
Phase 1カメラ AP 直結(http://192.168.4.1、HTTP 同一オリジン)API 直叩き可PWA インストール / Service Worker に制限
Phase 2Cloudflare Pages(HTTPS)直接 fetch 不可 → BLE 制御 + AP 直結サブページで転送インストール / オフライン対応可

責務分担

レイヤ責務フェーズ
ファーム (REST)撮影・ストリーム・設定・保存Phase 1 流用
ファーム (BLE/独自)省電力制御・インターバラ・ファイル列挙・再接続 WDPhase 2 / 独自
PWAUI・接続抽象・タイムラプス生成・投稿導線全般
Cloudflare WorkersX API 中継・鍵秘匿横断
EzDataインターバル画像の共有プレビュー(任意)任意

関連する機能設計