はじめに
先日、電池で数年もつ LoRaWAN センサーでブレーカーを見張る話を書きました。今回はその続編です。同じブレーカーを、通信方式だけ入れ替えて、当社で開発中の LTE-M v2 基板で見張ってみました。
写真の中央、透明なケースの中にあるのが当社の LTE-M v2 基板です。上に載っている薄い黄色のボード（ユニバーサル基板）に、今回のブレーカー監視に必要な拡張回路を組みました。この構成が、そのまま今回の 2 つの推しポイントに直結しています。
前回のおさらい（30 秒版）
- 困りごと：無人拠点のブレーカーが落ちても、誰も気づかない
- やりたいこと：「落ちた」を、手動 OFF / 過電流トリップ / 電源(PSU)喪失 まで撃ち分けて通知する
- 前回の答え：ブレーカーの補助接点・警報接点と PSU 出力の 3 点を、Dragino の LoRaWAN センサーで読んで通知
- 前回の推し：監視系（電池＋無線）が電力系と完全に切り離されているので、監視対象が死んでも監視は生き続ける
同じ課題を、同じ判別ロジックのまま、通信を丸ごと LoRaWAN → LTE-M に差し替えたのが今回です。
推し① ゲートウェイが要らない ― 通知経路の可用性を、キャリアに預ける
LoRaWAN 版は「センサー ⇄ 自前の LoRaWAN ゲートウェイ ⇄ クラウド」でした。ゲートウェイは電源も要りますし、置く場所も要ります。屋外に置くならケースも要ります。
LTE-M 版は、センサーが直接、携帯電話の基地局につながります。 つまり、ゲートウェイを一切立てなくても、通知経路が成立します。
自前ゲートウェイは、自分で電源を切らさないよう守る必要があります。バッテリー、停電対策、予備回線、死活監視 ―― 全部自分の責任です。
一方、携帯電話の基地局は、通信キャリアが 24 時間 365 日、専門部隊で守っているインフラです。バックアップ電源も冗長経路も、キャリア側の設計に含まれます。「見張り自体の稼働率を、キャリアの設備稼働率まで底上げする」という言い方もできます。
もちろん LoRaWAN 版にも、ゲートウェイをきちんと守れば十分な信頼性はあります。ただ「その手間を自分で持たない」という選択肢が LTE-M にはあり、拠点あたりの機材が減ることと合わせて、運用側の負担が小さくなるのが大きな価値だと考えています。
推し② 自社基板 × ユニバーサル基板 ― 拡張回路を、当日組める
今回主役の LTE-M v2 は、当社で開発中のオリジナル基板です（以前の記事で紹介したものと同じ基板です）。特徴を 1 つだけ挙げるなら、ケース内にユニバーサル基板を積める設計になっていることです。
冒頭の写真、透明ケースの上段に見える薄い黄色のボードがそれです。今回はここに「ブレーカーの 3 接点を読み、異常時に基板を叩き起こす」ための拡張回路を、はんだ付けで組みました。
これが何にうれしいかというと、「まだ試したい形が固まっていない段階でも、その場で実物を作れる」ということです。専用基板を起こすには最低ロットも起こし料金もあります。1 個 / 数個の試作段階に、専用基板は割に合いません。ユニバーサル基板ではんだ付けなら、思いついたその日に組めて、動かして、要件が変わったら線を張り替えられます。
今回のブレーカー拡張基板そのものが、この特性の実例です。
- 補助接点 / 警報接点 / PSU 出力の 3 系統を読む
- ESP32 の deep sleep 復帰要件に合わせて、3 信号すべてを「異常時 HIGH」にレベルを揃える
この要件を、LTE-M v2 マザーボードの IO × ユニバーサル基板で実装したので、すぐに実験ができました。「まず 1 個作って、現場で試す」を回せる構成 ―― 用途ごとに専用ハードを起こす前段の、ちょうどよい試作環境になっています。
動いているところ
動画をご覧いただくと分かるとおり、通知が届くまでに少し間があります。 LTE-M は 1 回の送信のたびに、通信モジュールの起動と網への接続を挟むため、どうしても 1 分弱かかります。LoRaWAN 版が数秒だったのに比べると、体感はまったく違います。「ゲートウェイなし」の対価が、この 1 分、というのが正直なところです。
ただ、ブレーカー監視の実務で「1 分遅れて困る」使い方はそれほど多くありません。「落ちたことに、その日のうちに気づけるかどうか」が本当の論点なので、実用上の問題にはなりませんでした。
スマホでどう見えるか
「通常運転」を大きく緑で言い切って、細かい接点の状態はその下に小さく置いています。業務の言葉を主、技術の言葉を従という設計です。異常時には赤色で「遮断」「発報」「喪失」と言い切ります。現場が画面を見た瞬間に「大丈夫」か「対応が要る」かが分かるように、という考え方です。
接点の生値（io=0x05 など）はデバッグ用に小さく残していますが、業務では見なくても済むようにしています。
LoRaWAN 版と LTE-M 版、どう使い分けるか
同じ問題に、2 つの答えを持てるようになりました。それぞれに得意分野があります。
| 観点 | LoRaWAN 版 | LTE-M 版（今回） |
|---|---|---|
| ゲートウェイ | 自前で必要 | 不要（基地局に直接） |
| 通知の速さ | 数秒 | 約 1 分 |
| 経路の可用性 | 自前ゲートウェイの守り方に依存 | キャリア設備に相乗り |
| 通信ランニング | なし（自前ゲートウェイの回線費のみ） | 1 回線ごとに月額 |
| 向いている場面 | 1 拠点にセンサー複数、または敷地内で完結 | 拠点あたり 1 〜数個、点在した設置 |
要は 「拠点ごとにゲートウェイを立てる固定費」と「1 台ごとの SIM 回線費」の比較にほぼ集約されます。設置場所が数拠点なら LTE-M、1 拠点で多点なら LoRaWAN、というのが素直な使い分けです。
まとめ
同じ「ブレーカーの落ちた」を見張る仕組みを、通信方式だけ入れ替えて仕立て直しました。
- LTE-M 版はゲートウェイが要らない。通知経路の可用性を通信キャリアに預けられる
- 自社 LTE-M v2 基板 × ユニバーサル基板で、専用基板を起こさずに拡張回路を組める。実験・少量に強い
- 通知の速さは約 1 分という代償はあるが、ブレーカー監視の実務では十分実用的
前回の LoRaWAN 版と合わせて、「ゲートウェイあり / なし」「速い / ゆっくり」を状況で選べるようになりました。同じ課題に対して 2 つの答えを持てるようになったこと、それ自体が今回の一番の収穫かもしれません。
- ブレーカー・電源・接点信号の遠隔監視のご相談（LoRaWAN / LTE-M どちらでも）
- 用途に合わせた拡張基板の試作（当社 LTE-M v2 基板 + ユニバーサル基板でスピード試作可能）
- 通信キャリア（Soracom 等）からダッシュボード・スマホ通知までのシステム構築支援
参考情報
- 前回の LoRaWAN 版：監視対象が死んでも、監視は生きている ― 電源にも LAN にも頼らないブレーカー見張り
- 「こんなものを試したい」というご相談は、お問い合わせフォームよりお気軽にご連絡ください