本文へスキップ
ysk-hack-log
戻る

Raspberry PiでBlazor(C#)を動かす|構成とBlazor Server/WASMの選び方【連載①】

「Raspberry PiでBlazor(C#)を動かす|構成とBlazor Server/WASMの選び方【連載①】」の記事アイキャッチ

「C# だけで、Raspberry Pi にセンサーの値を表示する Web ダッシュボードを作りたい」——本連載は、その完成形まで1つのアプリを通しで育てるシリーズです。第1回は全体像として、なぜ Pi × Blazor なのか/どの構成を選ぶか/何が必要かを整理します。

Table of contents

Open Table of contents

この連載で作るもの

作るのは 温度モニタリング・ダッシュボード 1つです。空のプロジェクトから始め、同じアプリに機能を積み上げます。

Raspberry Pi本体とブレッドボードを接続し、LED・ボタン・MCP3208を使った温度モニタリングを構成している実機

連載で使うRaspberry Pi実機。ブレッドボード上のLED・ボタン・MCP3208を接続して、センサー値の取得と操作を試します。

ブラウザで温度データをリアルタイムの折れ線グラフとして表示しているBlazorダッシュボード

取得した温度は、Blazorのダッシュボードでライブグラフとして確認します。第5回でSignalRを使ったリアルタイム更新を実装します。

なぜ Raspberry Pi × Blazor(C#)なのか

Blazor Server か WASM か(Piでは Server)

Blazor には主に Server と WebAssembly(WASM) の実行モデルがあります。本連載は Blazor Server(Blazor Web App の Interactive Server)を選びます。

Blazor ServerBlazor WASM
実行場所サーバー(=Pi本体)各利用者のブラウザ
ハードへのアクセスできる(サーバー側でGPIO/センサー)できない(ブラウザ内で隔離)
Piでの向き◎△

ポイントは、GPIOやセンサーを触れるのはサーバー側のコードだけということ。Piがサーバーになる Blazor Server なら、System.Device.Gpio でハードを操作し、その結果を画面へリアルタイムに流せます。WASM はブラウザ内で動くため、Piのハードには直接触れません。「ハードを扱うIoTダッシュボード」では Server が自然な選択です。

必要なもの

本体・環境

部品(この連載で使うもの)

部品役割登場回
LED + 抵抗Lチカ・警告灯第3回・第7回
押しボタン + 抵抗入力(プルダウン)第3回
MCP3208(12bit SPI ADC)アナログ→デジタル変換第4回
LM35DZ(アナログ温度センサー)温度取得(MCP3208経由)第4回

Raspberry Pi にはアナログ入力がありません。そのため、アナログ出力の LM35DZ を読むには MCP3208 のような ADC(アナログ-デジタル変換IC)が必須です。この「なぜADCが要るのか」は第4回で詳しく扱います。

全10回のロードマップ

  1. 全体像・Server/WASMの選び方(本記事)
  2. .NET導入+最初のBlazorアプリ(Pi OS・dotnet new blazor・LAN内アクセス)
  3. GPIO入門:LチカとボタンをWebから操作
  4. MCP3208+LM35DZでアナログ温度を読む
  5. SignalRで温度をライブグラフ表示
  6. SQLite+EF Coreで温度ログを蓄積→時系列グラフ
  7. MQTT連携でIoTダッシュボード
  8. systemdで常駐化(24時間稼働)
  9. GitHub Actions → Piへ自動デプロイ
  10. 安全に外部公開&運用(HTTPS・Cloudflare Tunnel)

各回はこの記事を起点にリンクしていきます(公開ごとに追記)。

まとめ

次回(第2回)は、Raspberry Pi に .NET を入れて、最初の Blazor アプリを起動し、同じLAN内の別PCから表示するところまで進めます。


この記事をシェア:

前の記事
C#でDPAPIを使い機密情報を安全に保存する|ProtectedDataでAPIキーを暗号化
次の記事
Raspberry Piに.NETを入れて最初のBlazorアプリを動かす【連載②】