洗濯機は、確かに洗濯が終わったことを知らせてくれていました。通知は届いたものの、スマートフォンには2件のメッセージとカレンダーのリマインダーに埋もれてしまい、濡れた洗濯物はさらに1時間そのまま。今回の構成が解決するのは、そんな些細で少しばかばかしい問題です。Divoom Pixoo-64があれば、本当に大切なスマートホームのイベントを、部屋の反対側からでも気づける形にできます。
まず、前提をひとつ。これはネイティブMQTT機能のガイドではありません。MQTTは受信箱であって、ディスプレイドライバーではなく、Pixoo-64もネイティブMQTTエンドポイントではありません。イベントを画面に表示する価値があるかどうかはNode-REDが判断し、そのメッセージをPixoo-64向けのHTTPリクエストに変換します。Node-REDを変換役、ディスプレイをドアに付いた明るい小さなサインだと考えてください。このひと手間の橋渡しこそが要であり、「通知をすべて表示する」よりもずっと賢くできる理由です。
この動画を見ると、スマートホームのエンドポイントとしてのPixoo-64の使い方がよくわかります。今回のやり方は少し異なります。ダッシュボード全体を作るのではなく、見る価値のあるイベントが起きるまで静かなままの、シンプルなアラートの流れを作ります。
3つのパートでつなぐ:受信箱、変換役、ピクセルサイン
すぐにキャンバスへノードをドラッグしたくなるかもしれません。まずは1分だけ待ってください。それぞれの役割を明確にすれば、6か月後もフローを理解できます。すべてのパーツに何でもさせると、最初のルーター再起動までは見事に動く、そんな自動化ができあがります。
| レイヤー | 唯一の役割 | すべきでないこと |
|---|---|---|
| MQTTブローカー | センサー、Home Assistant、またはほかのパブリッシャーからイベントを受信する | ピクセル、フォント、画面レイアウトを理解する |
| Node-RED | アラートをそれぞれ絞り込み、整形し、優先順位を付け、送信頻度を制限する | すべてのセンサー更新を判断せずに転送する |
| Pixoo-64 | 64×64のLED画面に、一目でわかる状態を表示する | ネイティブMQTTエンドポイントとして動作する、またはダッシュボード全体を置き換える |
この分離によって、すでに整っている環境を新しい構成が邪魔することもありません。Home Assistantのページやエンティティカード、HACSの設定を切り替えるのが本来の目的なら、まずPixoo-64 Home Assistantダッシュボードガイドをご覧ください。ここで扱うのは、もっとシンプルで明確な目的です。「このイベントが起きたら、実物の画面にこのメッセージを表示する」。
Node-REDで実用最小限のフローを作る
まずはトピックを1つ、アラートを1つだけ用意しましょう。私ならhome/laundry/stateにします。画面が役立つタイミングがはっきりしているからです。最小限のフローは次のようになります。
MQTT in
→ JSON
→ Switch(DONEのみ)
→ RBE(重複を無視)
→ Function(アラートを作成)
→ Delay(レート制限)
→ HTTP Request(Pixooコントロール層)
→ Debug / Catch
MQTT inノードがトピックを購読します。JSONノードは文字列のペイロードをオブジェクトに変換します。Switchノードは不要な状態を除外します。RBE(「report by exception」)ノードは、値が変化したときだけ通過させます。その後、Functionノードでディスプレイ用の小さく予測可能なメッセージを作成します。
msg.alert = {
title: "LAUNDRY",
value: "DONE",
color: "#55E6A5",
priority: 2,
ttl: 120
};
msg.method = "POST";
msg.headers = { "Content-Type": "application/json" };
msg.url = "http://PIXOO_IP/post";
msg.payload = {
Command: "Draw/SendHttpText",
TextId: 1,
x: 0,
y: 24,
dir: 0,
font: 2,
TextWidth: 64,
speed: 20,
TextString: msg.alert.title + " " + msg.alert.value,
color: msg.alert.color,
align: 1
};
return msg;
HTTP Requestノードでは、メッセージにすでに含まれているメソッドとURLを使い、解析済みのJSONオブジェクトを返します。Pixooへのリクエストが成功すると通常はerror_codeが返りますが、表示モードには重要な注意点があります。スクロールテキストはオーバーレイなので、既存の時計表示やギャラリー表示によっては表示されないことがあります。確実にアラートを表示するには、あらかじめ背景フレームを用意するか、Pixooヘルパーライブラリにバッファ処理と送信の順序を任せましょう。上記のコードはすっきりした橋渡しの形です。最終段階で送るペイロードとして捉え、すべてのファームウェアや現在のチャンネルで同じように動くと期待しないでください。
何かを描く前に、地味な明るさテストをする
{"Command":"Channel/SetBrightness","Brightness":50}をhttp://PIXOO_IP/postに送信します。明るさが変われば、Node-REDからデバイスに接続できており、JSONも届いています。変わらない場合は、まずIP、VLAN、ファイアウォールを修正してください。ネットワーク経路が壊れているのにフォントをデバッグするのは、夕方を無駄に過ごす絶好の方法です。
Node-REDのメッセージがまだつかみにくいなら、Functionノードのコードを増やす前に友人へ送るリンクはNode-RED公式のコンセプト解説ページです。メッセージオブジェクトと共有ブローカーの設定について、長大な講座に埋もれることなく説明しています。
4,096ピクセルを使う価値のある3つのアラート
64×64の画面は、求めるものを減らすほど使いやすくなります。ダッシュボード全体を載せようとすると、小さなタブレットになってしまいます。優れたアンビエント通知は、名詞ひとつ、状態ひとつ、そして色をひとつ添えるくらいです。この3つのパターンで、机やキッチンの壁に実際に表示したい情報のほとんどをカバーできます。
1. ドアの閉め忘れ:優先度高、状態ベース
開閉センサーのトピックを購読し、ドアがたとえば2分間開いたままの場合にだけドアが開いていますと表示します。優先度を3に設定し、赤または琥珀色の背景を使い、閉じた状態に戻るまで表示を続けます。ここではRBEが重要です。画面が変わるのは状態が変化したときであり、センサーが「開」と繰り返し送信するたびではありません。
2. 洗濯終了:優先度中、一度限りのイベント
これは継続的な状態ではなく、その場限りの通知です。洗濯終了を2分間表示してから、前の表示に戻します。フローで処理済みの記録も残さない限り、このアラートをブローカーに保持しないでください。そうしないと、Node-REDが翌日に再起動して、昨日の洗濯終了を誇らしげに知らせることになります。
3. もうすぐ雨:優先度低、期限付き情報
天気の変化は役立ちますが、緊急ではありません。20分後に雨のような内容を配信し、優先度を1に設定して、予報の有効時間に合ったTTLを指定します。ドアのアラートが届けば、雨の通知は後回しになります。ディスプレイが空く前に予報の期限が切れた場合は、Node-REDが古い情報を表示せずに破棄します。
Home Assistantを発信元のひとつにすることはできますが、ディスプレイを制御させる必要はありません。特に公式MQTTページは、状態トピック、一度限りの配信、保持メッセージのどれを使うか決めるときに役立ちます。実用上のルールはシンプルです。保持するのは現在の状態であり、過去のイベントではありません。
ディスプレイを通知の洪水にしない
自動化の最初のバージョンでわかるのは、何かを実行できるということです。2番目のバージョンでは、来週もそれを実行したいかどうかが決まります。4つの小さな工夫が違いを生みます。
- RBEで重複を除きましょう。気温が22°Cのままなら、画面にもう一度22°Cを表示する必要はありません。値が変わったときだけ通し、同じ値の繰り返しは破棄しましょう。
- レート制限を追加しましょう。HTTPリクエストの前にDelayノードを置き、ディスプレイが無理なく処理できるペースに更新を制限します。1秒ごとに届くセンサーの値で、Pixooをネットワークのメトロノームにしてはいけません。
- 優先度とTTLを組み合わせましょう。優先度はどれを先に表示するかを決め、TTLは待機中のメッセージをまだ表示する価値があるかを決めます。
- 失敗したときの行き先を用意しましょう。CatchノードとStatusノードを接続します。失敗したHTTPリクエストを一度だけ再試行し、エラーを記録してから、すでに信頼しているスマートフォン通知に切り替えましょう。無限再試行は回復力ではありません。自信満々にループしているだけです。
Node-REDホストとPixoo-64を、互いに通信できるネットワークセグメントに接続し、ルーターでディスプレイのIPアドレスを予約して、ローカルのHTTPエンドポイントをインターネットに直接公開しないでください。IoTデバイスをVLANで分離している場合は、必要なNode-REDからPixooへの通信だけを許可してください。
もっと凝ったアイコンや、用意済みの背景、実機の画面に触れる前に使えるシミュレーターをお探しなら、こちらのPixooライブラリを掘り下げてみるとよいでしょう。描画ヘルパーを見ると、運用上の大事な教訓もよくわかります。フレームを作ってから、無理のないペースで送信しましょう。
このセットアップが向いている人、避けたほうがいい人
このセットアップは、すでにブローカーやNode-REDのキャンバスを使っていて、便利なアイデアを保守しながら使う小さなシステムに仕立てるのが好きな人向けです。Pixoo-64なら、ダッシュボードのタブをもうひとつ増やすよりも、システムにずっと目を引く個性を加えられます。4,096個のLEDがあり、単語や数字、小さなアイコンを表示するのに十分なスペースがあり、デスクに置くことも壁に取り付けることもできます。
ワンタップで使える、公式サポート付きのMQTT機器をお求めなら、これは選ばないでください。通知に長文やカメラ画像、過去のグラフが必要なら、これは選ばないでください。IPアドレスの予約や、失敗したフローの確認が面倒な宿題に思えるなら、これも選ばないでください。スマートフォンや壁掛けタブレットのほうが見た目の魅力は控えめですが、手間も少なくて済みます。
試行錯誤も楽しみのうちなら、Pixoo-64 API初心者ガイドで生の制御方法をさらに詳しく解説しています。また、Divoomの公式製品マニュアルは1か所にまとまっています。まだ必要のないフローにコードをあと80行追加するより、次はこちらを読むのがおすすめです。
Divoom Pixoo-64Ⅱ
デスクや壁に置ける、64×64のWi-Fi対応ピクセルキャンバスです。Node-REDとローカル制御の連携を用意できるなら、スマートホームのアラート表示として活用できます。
Pixoo-64を見るまだ自動化する準備ができていませんか? まずはピクセルディスプレイコレクションでフォーマットを比較してから、開発プロジェクトに取り組むか決めるのがおすすめです。
よくある質問
Pixoo-64はMQTTにネイティブ対応していますか?
このガイドでは、Pixoo-64がMQTTのネイティブエンドポイントとして機能するとは想定していません。MQTTブローカーがイベントを受け取り、Node-REDがサブスクライブしてフィルタリングした後、PixooのローカルHTTP制御経路または互換性のあるヘルパーライブラリを通じてNode-REDが最終コマンドを送信します。
Home Assistantからアラートを送信できますか?
はい。Home Assistantから短いJSONペイロードをMQTTトピックに送信でき、Node-REDがそれをサブスクライブできます。ただし、Home Assistantは必須ではありません。ブローカーに公開するセンサー、スクリプト、サービスであれば、どれでも同じフローを開始できます。
Pixoo-64がオフラインの場合はどうなりますか?
HTTPリクエストが失敗した場合は、CatchまたはStatusの経路に進むようにします。アラートの性質に合うなら1回だけ再試行し、その後はスマートフォンへの通知などの代替手段を使いましょう。ディスプレイが復帰したときに期限切れのメッセージが表示されないよう、TTLも設定します。
すべてのアラートにGIFを使うべきですか?
いいえ。短いテキスト、シンプルなアイコン、背景色1色のほうがすばやく理解でき、更新処理への負荷も軽くなります。動きが本当に役立つまれなアラートにだけアニメーションを使い、すべてのプッシュにレート制限を設定しましょう。
画面にふさわしいアラートを1つ作る
先週見逃したイベントから始めましょう。システム上は公開できるイベントを20個並べるのではなく、見逃したそのイベントからです。明確なトピック、最優先事項、有効期限、代替手段をそれぞれ1つ設定します。そのアラートだけを7日間運用しましょう。目新しさが薄れたあともPixoo-64に目を向けるなら、2つ目のアラートを追加する価値があります。こうすれば、ピクセルディスプレイが見慣れて意識しなくなる別のダッシュボードではなく、部屋の一部になります。