· 2分で読了
ArduinoとESP32で作る空気質モニタリングアプリ(4)- WiFi編
この記事は中国語から自動翻訳されたものです。翻訳によりニュアンスが失われている場合があります。
この記事はシリーズ第4弾だ:
- センサー紹介編 - DHT11とMH-Z14A
- データ通信編 - UART(実装で使ったのはUARTなので、UARTの話だけ)
- Arduino 落とし穴編
- WiFi編:デバッグの時間を節約するため、元からWiFiとBluetooth機能を備えているESP32開発ボードを追加で購入した
- (未公開)MQTT編:データを他のデバイスに送信するため、軽量でコンパクトな通信プロトコルであるMQTTを使用した
- (未公開)Grafana / Web編:データベースに保存したデータは、もちろんイケてる見た目で可視化したい!ここではGrafana + Prometheus、そしてSvelteを使ってデータを表示した。
はじめに
通常、ArduinoでWiFi機能を実装するには拡張モジュールが必要であり、よく使われるチップとしてはESP8266が挙げられる。ただ、ESP8266単体で購入すると、ピンをすべて自分でハンダ付けしなければならず、データシートも自分で読み解く必要がある。WiFiの低レイヤーの仕組みを理解したいのであれば素晴らしい練習になるが、今回の僕たちの目的はアイデア全体を実現することなので、あらかじめWiFiとBluetooth機能が内蔵されているESP32開発ボードを購入した。
ESP32開発ボードにはWiFi機能だけでなく、GPIOピン、シリアルインターフェース、UARTなども備わっており、Arduino IDEと互換性があってコードの書き込みもでき、開発がとても手軽だ。そのため、実際にはArduinoを使わなくてもESP32だけで全機能を完成させることもできる。
WiFi接続
#include "WiFi.h"
WiFiClient client;
void setup()
{
WiFi.mode(WIFI_STA);
WiFi.begin(SSID, PASSWORD);
while (WiFi.status() != WL_CONNECTED)
{
delay(500);
Serial.println("Connecting to WiFi..");
}
Serial.println("Wifi is connected!");
}
void loop()
{
}
WiFiライブラリを使えば、WiFi接続を確立するのはかなり簡単で、setup内で直接WiFi.modeとWiFi.beginを呼び出すだけで済む。ここでは再接続の仕組みを設定していないので、失敗した場合はArduinoを再実行(リセット)する必要があるかもしれない。
WiFiに接続できれば、できることは一気に広がる!HTTPサーバーを動かしたり、サーバーへAPIリクエストを送ったり、センサーのデータをデータベースに送信したり、リアルタイム監視を行ったりと様々だ。
ここで僕たちがやりたいのは、MQTT経由でセンサーデータ(温湿度、CO2濃度)をサーバーへ送信し、残りのロジックはすべてサーバー側に任せて処理することだ。MQTTについては、次回の記事でまとめて紹介する!
関連記事
- 測定が目標になるとき:窓税からPull Request数まで かつて僕は小さなツールを自作し、四半期で自分がどれだけPRに貢献したか、レビューコメントをどれだけ残したか、チケットをどれだけ消化したかを集計して、上司にアウトプットを証明しようとしたことがある。上司は淡々と、評価はアウトプットだけで見るものではないと言った。数年後、僕はようやく理解した――測定が目標になるとき、それはもはや良い測定ではなくなるのだ。英国の窓税、ハノイのネズミ駆除の報奨金から、現代のPR数による開発者評価に至るまで、そのメカニズムはまったく同じだ。
- Cloudflare Images を画像ストレージ・変換ソリューションとして使う ウェブページに画像を1枚置くのはフロントエンドにとって最も簡単なことだが、リサイズや各種フォーマットの生成、さらにはトラフィックの負荷に耐えることまで完璧にやろうとすると、実際には一つの包括的なソリューションが必要になる。僕はその後、すべて Cloudflare Images に任せるようになり、オリジナル画像1枚だけを渡すようにしている。
- もう AWS Access Key を使うのはやめよう Access Key は AWS において見落とされがちなセキュリティリスクだ。OIDC と IAM Role を組み合わせることで、GitHub Actions にシークレットを一切保持させることなく、安全に AWS リソースを操作できるようにする。
- データベース主キー:AUTO_INCREMENT、UUID、そしてUUIDv7 バックエンド開発で度々直面する主キーの決定。auto incrementを使うべきか、それともUUIDか?衝突への懸念は?UUIDv7とcreated_at + インデックスの性能差はどれほどか?実際に2,000万件のデータで検証したベンチマークと設計上の意思決定を解説する。