ESP32自作温湿度センサー → SWPF連携（初心者向け）

自作温湿度センサーを SWPF に連携する

「ESP32 →（HTTP or MQTT）→ SWPF →（Template / Profile）→ 自動処理」の全体像と手順

ゴール ESP32が送った温度・湿度がSWPFに入り、ルール判定や式計算（EXPRESSION）で自動通知・記録できるようにする

1. まず全体像（いちばん重要） 2. HTTP と MQTT どっちで送る？ 3. ESP32側でやること（最小セット） 4. 送信データ(JSON)の決め方（超重要） 5. SWPF側でやること（Profile / Template） 6. 例：HTTPで送る（サンプル） 7. 例：MQTTで送る（サンプル） 8. ノーコード処理例（不快指数→通知） 9. よくあるトラブルと確認ポイント

このページの前提

ESP32で温湿度（例：DHT22 / SHT3x など）を読める
SWPF側は「HTTP受信」または「MQTT受信」を用意できる（どちらかでOK）
SWPFは受信後、Template/Profileの設定でノーコード処理する

結論： 連携で一番大事なのは 送信JSONのキー名をSWPFで統一すること です。
ここが揃うと、rule_json と expr が一気に書きやすくなります。

1. まず全体像（いちばん重要）

flowchart LR
  A[自作 温湿度センサー] -->|HTTP or MQTT|C[SWPF 受信]
  C --> D[Paramsで正規化]
  D --> E[Ruleを評価
コマンド決定]
  E --> F[Pluginでコマンド実行]
  F --> G[結果保存・通知・可視化]

SWPFは「入口（HTTP/MQTT）」が違っても、受信後は同じ形式のContext に揃えます。
その後は Profile と Template の設定で処理が動くので、ESP32側は「正しいJSONを送る」ことに集中できます。

2. HTTP と MQTT どっちで送る？

方式	初心者向けの特徴	おすすめ用途
HTTP	ESP32 → SWPFへ「1回のPOST」で送れる。構成がシンプル。失敗時に再送（リトライ）を書きやすい。	まず動かしたい／サーバー1台で完結したい
MQTT	センサーが増えても拡張しやすい。リアルタイムや常時接続に向く。ブローカー（Mosquitto等）を挟むので構成は少し増える。	将来デバイス数が増える／他システム連携もしたい

初心者は HTTPから始める のが最短です。あとからMQTTに移行しても、JSONのキー名が同じならSWPF側のTemplateは流用できます。

3. ESP32側でやること（最小セット）

Wi‑Fiに接続

SSID/PASSで接続してIPが取れる状態にします。

温度・湿度を取得

TEMP（℃）, HUMID（%）を数値で用意します。

JSONを作って送る

SWPFが理解できるキー名で送ります（次章が重要）。

注意： ESP32側で「複雑な判定」や「式計算」を頑張る必要はありません。
それは SWPF の rule_json / EXPRESSION に任せた方が、後で仕様変更が楽です。

4. 送信データ(JSON)の決め方（超重要）

ESP32→SWPFで、最低限そろえると良いキーはこの4つです。

キー	例	意味
device_code	"dev-001"	SWPFが「どのデバイスか」を判別するためのID（MAC直は避け、疑似IDが安全）
at	"2026-01-03T06:00:00+09:00"	計測時刻（無ければSWPF受信時刻でもOK）
TEMP	28.4	温度（℃）。数値で送る（"28.4" ではなく 28.4）
HUMID	62	湿度（%）。数値で送る

最小JSON（おすすめ）

{
  "device_code": "dev-001",
  "at": "2026-01-03T06:00:00+09:00",
  "TEMP": 28.4,
  "HUMID": 62
}

この形にしておくと、SWPF側の rule_json / expr は TEMP と HUMID をそのまま参照でき、初心者でも迷いません。

5. SWPF側でやること（Profile / Template）

5-1. Profile：このデバイスはどのテンプレを使う？

SWPFは受信した device_code を手がかりに、対応する Profile を選びます。
Profileには「使うテンプレ（1つ or 複数）」や「有効/無効」などの運用設定を持たせます。

5-2. Template：処理内容（ノーコード）

rule_json：条件分岐（例：TEMP>=30ならHOT）
template_json：実行内容（例：EXPRESSIONで不快指数→mail_send）

もし「Template ID は必ず1件のみ」という運用なら、Profileが選んだTemplateだけを実行する形にできます。
（複数テンプレの順次実行は、後で慣れてから拡張でOK）

6. 例：HTTPで送る（サンプル）

ESP32からSWPFのエンドポイントへPOSTします（URLや認証はあなたのSWPF設定に合わせてください）。

HTTP Request（イメージ）

POST /swpf/ingest HTTP/1.1
Host: your-domain.example
Content-Type: application/json

{
  "device_code": "dev-001",
  "at": "2026-01-03T06:00:00+09:00",
  "TEMP": 28.4,
  "HUMID": 62
}

まずは Postman / curl で同じJSONを送って、SWPFが受信できることを確認してからESP32実装に進むと失敗が減ります。

7. 例：MQTTで送る（サンプル）

ESP32がMQTTブローカーへ publish → SWPFがsubscribeして取り込みます。

トピック例

swpf/dev-001/telemetry

Payload（JSON）

{
  "device_code": "dev-001",
  "at": "2026-01-03T06:00:00+09:00",
  "TEMP": 28.4,
  "HUMID": 62
}

MQTTは「topicにMACアドレスをそのまま使う」のは避けるのがおすすめです（推測されやすい）。
device_code（疑似ID）で運用すると安全性が上がります。

8. ノーコード処理例（不快指数 → 通知）

8-1. EXPRESSIONで「不快指数」を作る

{
  "DISCOMFORT_INDEX": {
    "type": "EXPRESSION",
    "label": "Discomfort Index",
    "expr": "0.81 * TEMP + 0.01 * HUMID * (0.99 * TEMP - 14.3) + 46.3",
    "result_key": "discomfort_index"
  }
}

8-2. 不快指数で分岐する（rule_json例）

{
  "cases": [
    { "if": "discomfort_index >= 80", "then": "ALERT_MAIL" },
    { "if": "discomfort_index >= 75", "then": "WARN_MAIL" }
  ],
  "default": "OK_MAIL"
}

8-3. メール通知テンプレ（template_json例）

{
  "ALERT_MAIL": {
    "type": "COMMAND",
    "command": "mail_send",
    "mailinfo": {
      "to": "admin@sincerew.biz",
      "subject": "【警告】危険な暑さです"
    },
    "message": "不快指数が高いです。換気や冷却を検討してください。"
  },
  "WARN_MAIL": {
    "type": "COMMAND",
    "command": "mail_send",
    "mailinfo": {
      "to": "admin@sincerew.biz",
      "subject": "【注意】暑さ注意"
    },
    "message": "不快指数が上がっています。状況を確認してください。"
  },
  "OK_MAIL": {
    "type": "COMMAND",
    "command": "mail_send",
    "mailinfo": {
      "to": "admin@sincerew.biz",
      "subject": "みまもり通知"
    },
    "message": "受信しました（正常範囲）。"
  }
}

ここがSWPFの強み： 仕様変更（しきい値や文言）は Template のJSONを編集するだけ。
ESP32のファームを書き換えなくても、運用を変えられます。

9. よくあるトラブルと確認ポイント

✅ 1) SWPFが受信していない

HTTPなら：URL / Content-Type / 認証（Basic, Token等）
MQTTなら：topic / payload / TLS証明書 / user/pass

✅ 2) TEMP/HUMID が “文字列” になっていて式が動かない

"28.4" ではなく 28.4（数値）で送るのが基本。

✅ 3) キー名が一致せず、rule_json / expr が参照できない

ESP32が temp / humid で送っているのに、SWPFは TEMP / HUMID を期待している…など。どちらかに統一。

✅ 4) Profileが選ばれない（device_codeが紐づいていない）

SWPF側で「device_code→Profile」を解決する仕組みを確認。まずは固定で1つのProfileに紐づけてもOK。

最短デバッグ手順：
① curl/Postmanで同じJSONをSWPFに送る → ② SWPFログ/TRACEで受信・正規化を確認 → ③ TemplateのEXPRESSIONが動くか確認 → ④ 最後にESP32実装

次のおすすめ（発展）

電池残量 battery や電波強度 rssi も送って「故障予兆」をルール化
WireGuardやTLSで通信を保護（SWPFの方針に合わせて）
1時間ごと送信＋朝昼夕にAI解析（vibegrow.net構想）へ接続

当サイトまたはIoTカスタムモジュール、開発支援に関するお問い合わせはこちらのメールフォームからお気軽にお問い合わせください。

目次