Skip to content
まことの手帳
Go back

ESP32 でセンサーデータを AWS に送る #7 通信方式検討編

前回でバッテリー+ソーラーの部材選定を終えました。発注前にもう一つ、確認しておきたいことがありました。屋外の設置予定地は、自宅の Wi-Fi が届きません。

これまでの記事はすべて Wi-Fi 前提で進めてきました。せっかく電源を独立させるなら、通信方式も見直すべきか。今回はその検討記録です。

目次

LoRaWAN は早々に除外した

低消費電力・長距離が売りの LoRaWAN から調べ始めました。自宅にゲートウェイを立てる案を試算したところ、SORACOM のゲートウェイサービスだけで登録料 ¥27,280 + 月額 ¥10,978 × 3ヶ月 = ¥60,214(最初の3ヶ月分だけでこの金額)でした。電源部材の総額(約¥7,080)を大きく超えます。

加えて、LoRaWAN のゲートウェイは「基地局クラス」の無線機として扱われ、総務省への無線局登録が必要という規制上のハードルもありました。近所に無料のコミュニティゲートウェイ(The Things Network)があれば話は別ですが、それは個別に確認するしかありません。この時点で見送りました。

Sigfox:エリアも電波も確認できたのに

次に調べたのは Sigfox です。1回あたり12バイト、1日140回までという制約がありますが、気圧・温度センサーのデータ量にはちょうど合います。 料金も SORACOM Air for Sigfox 経由で初年度¥3,960、2年目以降¥1,980/年と安く、有力候補でした。

KCCS のサービスエリアページで設置予定地を確認したところ、エリア内でした。念のため、その場所で実際にスマートフォンの電波が入ることも確認しました。ここまでは順調でした。

ところが、日本のホビー向けで定番だった「Sigfox Shield for Arduino」が、V1・V2S2 とも販売終了していました。代わりのモジュールも見つかりません。

さらに、Sigfox は独自プロトコルで TCP/IP を話しません。AWS に届けるには SORACOM Funnel という中継サービスを挟み、AWS 側で IAM ポリシー・ロールの設定も必要になります。前回確認した MQTT/TLS の知識がそのまま使えないわけです。

「エリアも電波も確認できたのに、肝心のモジュールが手に入らない」という、少し拍子抜けする結末でした。

セルラー:通信費は安いのに、繋ぐモジュールが無い

気を取り直してセルラー(LTE-M/NB-IoT)を調べました。ESP32 は1時間に1回、ディープスリープから起きて送信する想定なので、実際の通信量を試算してみます。

24回/日 × 30日 = 720回/月

1回あたりの通信量は、送るデータ本体よりも接続・TLSハンドシェイクのオーバーヘッドの方が支配的です。目安として1回5〜10KBとすると、月あたり約5MB程度になります。

SORACOM の確認できた料金体系(plan-D、バンドルなし)はこうでした。

基本料: ¥10/日 × 365日 = ¥3,650/年
データ料: 約63MB/年 × ¥0.2/MB = 約¥13/年
合計: 約¥3,700/年(月あたり約¥305)

基本料がほぼ全てで、データ量による差はごくわずかです。ここまでは想定どおりでした。

問題はハードウェア側でした。ESP32 に外付けできる単体のセルラーモジュールを探したところ、こちらも Sigfox と同じ壁にぶつかりました。

候補状況
SORACOM「LTE-M Shield for Arduino」(Quectel BG96搭載)販売終了
SORACOM Onyx(LTE USBドングル)¥13,750。ただし LTE Cat.4(低消費電力の LTE-M ではない)で、USB ドングルなので ESP32 側に USB ホスト機能が必要
Quectel BG95 等の裸のモジュール表面実装部品で、アンテナ整合を含む基板設計が必要。はんだ付け初心者には扱えない
Wio BG770A v1.0(Seeed製)現実的な唯一の選択肢。¥14,850

Wio BG770A は独自マイコンを搭載した開発ボードで、ESP32 そのものを置き換えることになります。BMP180 は I2C なのでコードの移植自体は難しくないはずですが、これまでの ESP32・PlatformIO という前提が崩れます。

通信費(年約¥3,700)自体は妥当でしたが、電源部材の総額(約¥7,080)にほぼ匹敵する初期投資が発生します。ここが最終的な見送りの決め手になりました。

結局、Wi-Fi のまま進めることにした

3つとも見送った結果、方針を変えました。通信方式ではなく、Wi-Fi の電波が届く環境を作る方向です。

Wi-Fi 中継機を自宅と設置場所の間に置く、というだけの話ですが、これならこれまで積み上げてきた ESP32・センサー・電源回路の設計を一切変更せずに済みます。 通信方式を変えることの本当のコストは、通信費そのものよりも「これまでの検証がどれだけ再利用できるか」にある、というのが今回の実感でした。

まとめ

方式判定主な理由
LoRaWAN(自前ゲートウェイ)早期に除外無線局登録が必要。ゲートウェイ自体も高額
Sigfox検討したが見送りエリア・電波は確認できたが、モジュールが販売終了
セルラー(LTE-M/NB-IoT)検討したが見送り通信費は妥当だが、代替ハードウェアが高額
Wi-Fi + 中継機採用既存の設計を変更せずに済む

追記: AWS連携を終えてから、もう一段調べ直した

AWS 側(API Gateway + Lambda + DynamoDB + CloudWatch ダッシュボード)まで作り終えたあと、「代替ハードウェアが高額」という理由で見送ったセルラーの状況が変わっていないか、もう一度調べ直しました。

結果、当時は見つけられなかった、ESP32 を置き換えずに追加できるセルラーモジュールが2つ見つかりました。

どちらもレベル変換済みの UART なので ESP32 に直結でき、TinyGSM ライブラリ経由で HTTPS/TLS 通信にも対応していることを公式ドキュメントで確認しました。技適についても、秋月の BG96 キットは FAQ ページでアンテナ型番(antenova Lucida SR4L002)まで明記されており、確実性が高いです。

当時唯一の候補だった Wio BG770A v1.0 も価格が¥14,850→¥13,200に下がっていましたが、独自マイコン(nRF52840)搭載のため依然として ESP32 の置き換えが必要です。公式のセルラーライブラリ(WioCellular)を確認したところ、平文 HTTP・MQTT の例しかなく HTTPS/TLS 対応が確認できなかった点も、上記2つの UART モジュールに分があります。

参考までに、Lilygo T-SIM7080G-S3(ESP32-S3系)、Leafony、STM32、Qualcomm Dragonwing 搭載の Arduino UNO Q、Wi-Fi⇔LTE の自作ゲートウェイ案なども検討しましたが、いずれも「ESP32 を置き換えずに追加する」上記2択より実装リスクやコストが高く、見送りました。

結論(Wi-Fi 継続)は変わりませんが、次にセルラー化を試すなら候補はこの2つに絞れた、というのが今回の収穫です。

次回

Wi-Fi 中継機の設置は、電子工作というより家庭内ネットワークの話なので、部材が届いてからの実地調整で対応する予定です。AWS 側のアーキテクチャは別記事で扱う予定です。次はセンサー側の検証を終えたうえで、上記のセルラーモジュール候補を実機で検証する予定です。

参考リンク


Share this post on:

Previous Post
ESP32 でセンサーデータを AWS に送る #6 電源設計編
Next Post
ESP32 でセンサーデータを AWS に送る #9 気象庁データ比較編