なにがでるか

電話番号登録しているものとは別のdアカウントでスマートフォンのdアニメストアにログインする手順

2022-10-29T12:36:00.001+09:00

はじめに

dアニメストアを使い始めて2年ほどになりますが、表題のケースでログインする手順を毎回忘れてしまって困っていたのでまとめます。

前提条件とやりたいことの整理

この記事で紹介する手順が必要になる前提条件とやりたいことを整理します。

利用する端末はスマートフォン（Android）
そのスマートフォンの電話番号はdアカウントAと紐付いている
電話番号と紐付いていないdアカウントBでdアニメストアにログインしたい

dアニメストアを使わずにしばらく放置しておくと、自動的にログイン状態が解除されてしまいます。この状態から復旧するのが目的です。なお、電話番号に紐付いたdアカウントでログインする場合は、何も考えず自動ログインできるので、この記事の手順は不要です。

手順

1. dアニメストアアプリ設定のリセット

はじめに、dアニメストアアプリの画面右上のメニューから「アプリ設定 > ユーザーデータリセット」を選択して設定をリセットします。ここでdアニメストアアプリが自動的に終了します。

2. dアニメストアを起動

次に、dアニメストアアプリを起動して「規約に同意して利用を開始」を選択します。

このタイミングで、電話番号と紐付いているdアカウントAで自動的にログインされてしまいます。最初はここでうろたえますが、大丈夫です。

3. ログアウト

そのまま同じ画面で一番下までスクロールして「dアカウントログアウト」を選択します。ここが第一関門です。ログアウトのメニューを見つける難易度が高い。

ログアウトが完了したら画面に表示される「dアニメストア TOP」を選択してdアニメストアアプリのホーム画面が表示されることを確認します。

4. 別のアカウントでログインしなおす

dアカウントBでログインするため、dアニメストアアプリホーム右上にある「ご利用可能ポイント」を選択します。ここが第二関門です。「dアカウントログイン/発行する」を選択してはいけません。そちらを選択すると自動ログインが発動してしまい、最初からやり直しです。

次に「dアカウントアカウントA」の部分を選択します。ここが第三関門で、すでにログアウトしているはずなのに古いログイン情報が残っており、自分が一体何をしていたのかわからなくなります。精神を落ち着けて状況を想像するに、dマーケット側はまだログアウトされていないようです（理解した風なことを書いていますが、dマーケット側ってなんだよ、とサービスの構造を知らない私の頭の中は疑問符だらけです）。

次の画面で「別のdアカウントでログイン」を選択します。

「dアカウントのID」を入力し、「次へ」を選択します。もうおわかりかと思いますが、「かんたんログイン」を選択してはいけません。自動ログインが発動してしまい、最初からやり直しです。

パスワードとSMSで送られてくるセキュリティコードを入力して「ログイン」を選択します。

無事アカウントBでログインできました。でも、まだ罠があるので要注意です。すぐ下の各サービス一覧から「dアニメストア」を選択します。

dアニメストアアプリのホーム画面が表示されたら「dアカウントログイン/発行する」を選択します。ここが第四関門です。すでにdアカウントBでログインしなおしたはずなのにdアニメストアには反映されていません。実は先ほど「dアカウントログイン/発行する」を選択すると自動ログインが発動すると説明しましたが、dマーケット側がログイン状態であれば「dアカウントログイン/発行する」を選択しても自動ログインは発動しません。ユーザーが知り得ない状態によって同じメニューの動作が異なるため混乱します。

無事、dアニメストアアプリにアカウントBでログインできました。

問題の原因

罠がたくさんありましたが、整理してみます。

自動ログインが発動する状況がユーザから判別がつかない
dアニメストアとdマーケットのログイン状態が分離している
画面の構成がわかりにくい
画面の表記が不親切で、やりたいことがガイドできていない

さいごに

この記事で紹介した手順にたどり着くのにまる2日かかりました。それまでは、なんとなく画面をたどって復旧させていましたが、手順が複雑すぎて毎回忘れてしまっていました。

電話番号と紐付いたdアカウントを利用する場合は、こんな苦労をする必要がないので、特殊なケースかと思いますが、もう少しなんとかしてほしいものです。この記事を書いていてダメなUI実装を集めたこのサイトを思い出しました。

Batchノードを使う（その2）

2022-05-26T12:54:00.000+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はBatchノードの第2回目です。

確認するサンプルは、「読み込み > サンプル > flows > node-red > sequence > batch > 02 - Time based group mode」です。時間ベースでメッセージをグループ化できるみたいです。

時間ベースでメッセージをグループ化する

ざっくりとした流れは以下のとおりです。

Functionノードがバラバラのメッセージを送信する
Delayノードが流量制限を行い、1秒1メッセージ流すようにする
Batchノードが指定した時間間隔ごとにグループ化（partsプロパティに自動生成した値を設定）する
Joinノードが同じpartsプロパティの値ごとに1つのメッセージにまとめる

上流から順にノードの設定を見ていきます。入力データを生成するFunctionノードでは、0〜29の値をPayloadに持つメッセージを送信しています。ここは前回の記事と同じです。

続いて、Delayノードで流量制限を行います。

続いて、Batchノードで指定した時間間隔ごとにグループ化します。

続いて、Joinノードで複数メッセージをまとめます。動作が自動なので、partsプロパティの値ごとにまとめます。ここも前回の記事と同じです。

実行すると、以下のログが出力されます。画面キャプチャからは読み取れませんが、ログは約5秒毎に出力されます。流量制限したメッセージがグループ化されるのに時間がかかるんでしょうね。

まとめ

まとめます。

複数メッセージを時間ベースでグループ化できます

Batchノードシリーズはもう少し続きます。

Batchノードを使う（その1）

2022-05-23T13:03:00.002+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はBatchノードの第一回目です。

確認するサンプルは、「読み込み > サンプル > flows > node-red > sequence > batch > 01 - Number based group mode」です。サンプルを見る限りBatchノードを利用すると指定した条件ごとにメッセージをグループ化できるようです。「グループ化」って言葉だけを見ても何をするのか想像がつきませんが、「メッセージにpartsプロパティを付加する」のがより詳細な挙動の説明になると理解しました。複数のメッセージをまとめるのはJoinノードが実施しますが、そのJoinノードが動くために、複数のメッセージに同じpartsプロパティを付与するのがBatchノードの役割です。

バラバラのメッセージを指定した数ずつまとめる

最初に確認するのは1段目です。ざっくりとした流れは以下のとおりです。

Functionノードがバラバラのメッセージを送信する
Batchノードが指定した数ごとにグループ化（partsプロパティに自動生成した値を設定）する
Joinノードが同じpartsプロパティの値ごとに1つのメッセージにまとめる

上流から順にノードの設定を見ていきます。入力データを生成するFunctionノードでは、0〜29の値をPayloadに持つメッセージを送信しています。

続いて、Batchノードで指定したメッセージ数ごとにグループ化します。

続いて、Joinノードで複数メッセージをまとめます。動作が自動なので、partsプロパティの値ごとにまとめます。

実行すると、以下のログが出力されます。5ずつまとめられていますね。なお、Batchノードの出力にDebugノードをつなげて出力メッセージ全体を確認するとpartsプロパティに自動生成した値が設定されているのが確認できるはずです。

要素をオーバーラップする

Batchノードでは、グループ化する要素を一部オーバーラップさせることができます。この説明だけで伝わると思えないので詳しく説明します。確認するサンプルは2段目です。基本的な流れは一つ前のサンプルと同じで、違うのはBatchノードのオーバーラップ設定のみです。

これを実行すると以下の出力になります。最初と最後の要素がオーバーラップしていますね。何に使うかはわかりませんが、こういうこともできると覚えておきます。

まとめ

まとめます。

Batchノードを利用することでメッセージをグループ化できます
Batchノードは単にmsg.partsプロパティに値を付与するだけです

メッセージをまとめるのはJoinノードがやります

要素をオーバーラップさせることができます

Batchノードシリーズはもう少し続きます。

Sortノードを使う（その3）

2022-05-09T12:51:00.001+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はSortノードシリーズの3回目です。

確認するサンプルは、前回に引き続き「読み込み > サンプル > flows > node-red > sequence > sort > 02 - Sort message sequence」です。前回紹介したサンプルとの違いは、Payloadを直接ソートするのではなく、複数メッセージをソート対象にしている点です。ソート対象の入力メッセージとソート後の出力ともに複数のメッセージのまま取り扱っているのがポイントです（前回紹介したサンプルは単一のメッセージ内でのソートでした）。それを再現するため、Sortノードの前にSplitノードを経由してメッセージをバラバラにしています。実運用ではわざわざSplitノードを利用することはなく、元々独立したメッセージをソートできることを示したいのだと思います。たぶん。

バラバラのメッセージをソートする

確認するのは1段目です。

入力データを生成するTemplateノードでは、単純な文字列配列を指定しています。

こいつをSplitノードでバラバラにしています。入力が配列なので固定長1でバラしてます。

Sortノードはmsg.payloadで昇順ソートするよう指定してあります。いたってシンプル。

実行すると、以下のログが出力されます。一度バラされた複数メッセージのmsg.payloadの値で昇順ソートされています。

ちなみに、2段目のサンプルは降順ソートです。3段目、4段目も文字列ソートに関するものです。これらは説明不要だと思うのでスキップします。

バラバラのメッセージに指定されたJSONオブジェクトのプロパティ値でソートする

続いて確認するサンプルは5段目です。フローの見た目は最初に確認したものと同じに見えますが、バラバラに飛んでくるJSONオブジェクトのプロパティ値でソートします。

入力データを生成しているTemplateノードでは、JSONオブジェクト配列を生成しています。

これをSplitノードで配列要素ごとにPayloadを分割します。Splitノードの内容は一つ前のサンプルと同じなので省略します。さらにSortノードではキー「payload.price」でソートしています。

結果は以下の通り、priceの値でソートされました。出力もバラバラのメッセージです。

複数のプロパティを条件に組み込んでバラバラのメッセージに指定されたJSONオブジェクトのプロパティ値でソートする

最後に確認するサンプルは6段目です。基本的に前回の記事の「複数のプロパティを条件に組み込んでソートする」と同じですが、入出力ともにバラバラのメッセージを対象にしているのがポイントです。ってことで、細かいことは全部省略します。

まとめ

まとめます。

バラバラのメッセージを対象にしてソートできる

以上、Sortノードシリーズ完了です。

Sortノードを使う（その2）

2022-03-22T22:47:00.004+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はSortノードシリーズの2回目です。

確認するサンプルは、前回に引き続き「読み込み > サンプル > flows > node-red > sequence > sort > 01 - Sort array payload」です。

シンプルなJSONata式でJSON配列をソートする

確認するのは5段目です。

　入力データを生成するTemplateノードでは、name（文字列）とprice（数値）をプロパティに持つJSON配列を指定しています。

SortノードではJSONata式でキー「price」で昇順ソートするよう指定してあります。

実行すると、以下のログが出力されます。msg.payload.priceの値で昇順ソートされていますね。特に説明の必要はないと思います。

複数のプロパティを条件に組み込んでソートする

最後は6段目です。先ほどより少し複雑なJSONata式を利用して複数プロパティの値を条件に組み込んでソートします。

入力データを生成しているTemplateノードでは、先程と同様JSON配列を指定していますが、今度は複数の要素で同じ値のpriceを持っています。このサンプルではnameの値も考慮に入れてソートを行っています。

Sortノードを開くと、キーに何やら長ったらしいJSONata式が設定されています。このままだと見づらいので、右側の「...」ボタンを選択します。

SONata式の全体像が確認できます。この内容を言葉で表現すると以下のようになります。

priceの値を4桁のゼロ埋めした文字列を生成して、nameの値と文字列結合する

「テスト」タブを選択して、「メッセージ例」にnameとpriceプロパティを持つJSONオブジェクトを指定すると、「結果」欄でこの式の動作を確認できます。この文字列でソートを実行します。

結果は以下の通り、priceの値が同じ場合、nameの値でソートされました。

まとめ

まとめます。

ソート条件にJSONata式を利用すると複雑な動作を実現できる

Sortノードシリーズはまだまだ続きます。

Sortノードを使う（その1）

2022-03-14T22:13:00.003+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回からSortノードを見ていきます。

確認するサンプルは、「読み込み > サンプル > flows > node-red > sequence > sort > 01 - Sort array payload」です。配列をソートするってことですかね。内容はシンプルなのでサクサク見ていきます。

文字列配列を昇順にソートする

内容は見出しの通りです。

Templateノードでmsg.payloadに文字列配列を設定する
要素の値をキーにして昇順でソート

結果は以下の通り、文字列配列の要素が昇順でソートされました。予想通りかと思います。

文字列配列を降順にソートする

続いて2段目は降順ソートです。先ほどとの違いはSortノードの順序設定のみ。

結果は以下の通り、先ほどとは逆順になりました。

文字列配列を昇順ソートする再び

続いて3段目は1段目と同じく昇順ソートのサンプルですが、入力するデータが数値っぽい文字列です。

文字列として昇順ソートされましたね。特に説明は必要ないかと思います。

文字列配列を数値として昇順ソートする

4段目は3段目と入力データは同じですが、数値として昇順ソートします。

文字列なのに数値として昇順ソートできました。いちいち数値に変換しなくていいので、これは意外と便利かもしれない。

まとめ

いったんここらでまとめます。

基本的に配列は文字列としてソートします
入力が文字列であっても、数値としてソートすることもできます
順序は昇順と降順から選択できます

Sortノードシリーズは続きます。

Joinノードを使う（その4）

2022-03-05T08:28:00.004+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はJoinノードの4回目です。終わらねぇ。

確認するサンプルは、前回に引き続き「読み込み > サンプル > flows > node-red > sequence > join > 02 - Manual join mode」です。

メッセージを結合してkey/valueオブジェクトにする

5段目のフローから見ていきます。ざっくりとした流れは以下のとおりです。

DataノードでCSVデータを送信する
CsvノードでCSVデータをJSONオブジェクトに変換する

msg.payloadには以下のような値が指定されたメッセージ4つに分解される

{ name: "Apple", price: 100 }

Changeノードでmsg.payload内の値を以下のプロパティに設定する

msg.topic = "Apple"（msg.payload.nameの値）
msg.payload = 100（msg.payload.priceの値）

Joinノードで、2個の受信メッセージごとにmsg.topicの値をキーとしてkey/valueオブジェクトに結合して送信する

これを実行すると、以下のようにmsg.payloadにJSONオブジェクトが指定されていることを確認できます。

メッセージを結合して結合オブジェクトにする

先ほどは結合した値がkey/valueオブジェクトでしたが、6段目のフローでは単純にオブジェクト結合します。ざっくりとした流れは以下のとおりです。

DataノードでJSON配列を送信する

nameをキーに持つオブジェクトとpriceをキーに持つオブジェクトを交互に含んでいます（実際、こんなに都合の良いデータが生成されることはあるんだろうか）

Splitノードで配列データを個別のメッセージに分割します
Joinノードで、2個の受信メッセージごとにオブジェクトに結合して送信する

これを実行すると、以下のようにmsg.payloadに2個ずつのオブジェクトがJSONオブジェクトに結合されたものが指定されていることを確認できます。ちなみに、Joinノードで結合するオブジェクトのキーが被っていると結合対象のメッセージは破棄されるようです（Templateノードで指定している配列要素の2個めのキーをpriceからnameに変更すると確認できます）。このサンプルではTemplateノードで指定したデータのkeyが結合後に被らないようにしてあるので、こんな感じで単純結合できるんですね。

指定した数に達するまでに受信したメッセージを保持して、後続のメッセージを差し替えて結合オブジェクトにする

7段目のフローも結合オブジェクトにしますが、文章にするととてもややこしい動きをします。ざっくりとした流れは以下のとおりです。

DataノードでJSON配列を送信する

配列の先頭2つの要素はそれぞれnameとpriceをキーに持つオブジェクトで、その後はorderをキーに持つオブジェクトです

Splitノードで配列データを個別のメッセージに分割します
Joinノードで、3個のメッセージを受信したらオブジェクトに結合して送信します

最初に受信した2つのメッセージの内容はそのまま保持して、その後受信した後続のメッセージを1つ受信したら3つ目のメッセージを受信したメッセージ差し替えて送信します

これを実行すると、以下のようにmsg.payloadに最初の3個のオブジェクトがJSONオブジェクトに結合されたものが指定されていることを確認できます。その後は、最初の2個のオブジェクトは固定で、4つ目以降のオブジェクトが差し替えられて指定されています。

結果を見るとなんとなく挙動は理解できますが、実際こんなサンプルを利用しなきゃいけない場面はあるのだろうか。

まとめ

ようやく全部見終えたのでまとめます。

特定のプロパティを指定してkey/valueオブジェクトに結合できます
単純にオブジェクトに結合できます

結合対象のキーが被るとそのデータは破棄されます

指定した数に達するまでに受信したオブジェクトを固定し、その後受信したメッセージを差し替えて結合できます

長く続いたJoinノードシリーズがようやく終焉を迎えました。

Hacktoberfest 2021に参加したらTシャツもらえました

2022-03-04T22:39:00.000+09:00

昨年10月、Hacktoberfest 2021に参加しました。具体的には、Node-REDの標準ノードの翻訳に参加して4つのコントリビュートがマージされました。タイミング的にギリギリだったので、ダメかなと諦めていたのですが、先日Tシャツが届きました。ステッカーもたくさん同梱されていました。なんか嬉しいです。

レビュアーの皆様、ありがとうございました。また何か機会があればよろしくお願いします。

Joinノードを使う（その3）

2022-02-25T22:39:00.001+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はJoinノードの3回目です。

確認するサンプルは、前回に引き続き「読み込み > サンプル > flows > node-red > sequence > join > 02 - Manual join mode」です。

msg.completeを使って結合する

3段目のフローから見ていきます。ざっくりとした流れは以下のとおりです。

Templateノードで「msg.payload」に改行区切りの文字列を指定する
Splitノードでmsg.payloadの文字列を改行で区切って複数のメッセージに分離する
Functionノードでは、受信したメッセージが特定の条件を満たしていた場合に「msg.complete」に「true」を指定する

条件：msg.payloadにBananaまたはKiwiが指定されていたら

Joinノードでは、受信したメッセージのmsg.completeプロパティが設定されていたらメッセージを送信する（それまでに受信したメッセージはカンマで区切って文字列結合する）

Templateノード

Splitノード

Joinノード

実行すると、msg.completeプロパティが指定されるまでに受信したメッセージが結合されたログが出力されます。

メッセージを結合して配列にする

ここまでは結合した値が文字列でしたが、4段目のフローでは配列にします。TemplateノードとSplitノードは上述のサンプルと同じなので省略します。ポイントはJoinノードの出力が「配列」に設定されている点です。

これを実行すると、以下のようにmsg.payloadに文字列配列が指定されていることを確認できます。

まとめ

このへんで一旦まとめておきます。

手動モードでは「msg.complete」プロパティを指定するとメッセージの結合を区切ることができます
「msg.complete」を指定するまでに入力されたメッセージが結合されます
結合後のデータ型は文字列の他に配列が指定できます

たぶん、この後のサンプルで紹介することになると思いますが、データ型は他にも選択肢があります

Joinノードシリーズはもう少し続きます。

痩せてみた

2022-02-24T22:00:00.002+09:00

はじめに

ここ10ヶ月ほど、体重のコントロールに取り組み、安定的に運用できるようになりました。しかしながら、何かのきっかけでリバウンドしてしまう可能性はあります。いつの日か、リバウンドしてしまった際に再度コントロールを取り戻せるようここにメモを残しておきます。

成果

ダイエットを本格的に開始したのは2021年4月1日です。当時と今を比較してみます。

Before：2021年4月1日

体重：70.8kg
胴囲：85.7cm

After：2022年1月18日

体重：58.5kg
胴囲：70.5cm

ちなみに身長と標準体重は以下のとおりです。

身長：176.3cm
標準体重：68.4kg

これ以降は、この状態に至るまでに経験したことを記録します。

きっかけ

ちょっと前から、なんとなくお腹が出てきていたことが気になっていました。特に椅子に座った姿勢が顕著でしたが、気のせいだろうと思いこむことにしていました。そんな中、久々に会った方に開口一番「お腹出ましたね」と言われ、それが気のせいではないことをはっきり自覚しました。

やったこと

翌日から生活習慣を改めることにしました。やったことは極めてありがちなことばかりで、以下のような内容です。問題はこれらを継続できるかどうかでした。

毎日体重を測る
夕食のご飯は茶碗1杯まで
間食は控えめに
歩く

毎日体重を測る

どこで仕入れた情報か忘れましたが、ダイエットをするならまずは体重を測れというのを思い出してなんとなく始めました。体重をこまめに測ると、その間にやった食事や運動、排泄などの行動がどの程度体重に影響を与えるか見えてきます。見えたらあとは効果のあることを継続するだけです。私は以下のルールで実施しました。

測定タイミングは少なくとも一日2回

夕食後寝る前
朝起きた後朝食前

測定前にトイレは済ませる
測定は全裸で

寝る前は一日の中で最も体重が大きく、朝食前は逆に最も小さいタイミングと考えました。測定タイミングを一定にすることで前日と比較ができるようになります。トイレと全裸のルールは体重のブレを生じさせる要素をなるべく減らして自分に言い訳させないのが目的です。

また、細かいことですが、体重計はGoogle Fit対応のものを利用しています。体重計に乗るだけで自動的にスマホ上に記録できるので便利です。

夕食のご飯は茶碗1杯まで

食事制限によるダイエットは過去に一度失敗していたこともあり、極力避けました。食事を変化させたのは夕食のご飯（ライス）の量のみです。足りない分は、肉なり野菜なりで満たすので、食事制限の辛い感覚はほぼありません。あるとしたら、焼き肉やすき焼きの際のご飯不足くらいでしょうか。全体的な量は1日3食満足する程度に食べます。

間食は控えめに

間食の制限もやりすぎるとモチベーションを下げるので、制限は最低限に抑えました。文字通り「控えめ」程度で、全く食べないわけではありません。気をつけているのは以下の点です。

間食でお腹を満たさない
食事までに空腹になるよう量を抑える
タイミングを逃したら食べられなくなるものは食べる（高級◯◯とか、今話題の◯◯とか）
炭酸飲料などの甘い飲み物は避け、味が強くて糖分の無いブラックコーヒーで口寂しさを紛らわせる

最初の2、3ヶ月はストイックに間食を避けていましたが、体重の変化を見つつ影響がない程度にルールを緩和していき、この運用に落ち着きました。

歩く

実は、本格的にダイエットを開始する前から、毎日5kmほど歩いていましたが、体重に変化がないことがわかっていたので、歩く距離を倍の10km〜12kmに増やしました。標高差は20m程度です。ペースは10分〜11分/kmと、ほんのり早足程度。この距離を歩くのに2時間程度かかりますが、生活リズム的に連続で時間を確保するのは難しいので、朝食後と夕食後の2回に分けて歩いています。天気が悪くない限り基本的に毎日歩きますが、なんだかんだ週に1日は天気の悪い日があるので、週6日程度でしょうか。比較的よく歩いた8月は300km程度でした。

ただ歩くだけだと退屈なので、ラジオを聞きながら歩くようにしました。これはモチベーションの維持に意外と効果的で最近ではラジオを聞くために歩きに行く状態（いい意味で本末転倒）になっています。

体重と同じく運動もGoogle Fitで記録します。スマホを持って歩くだけなのでとても便利です。

はじめのうちは1日に2時間も歩くとぐったりと疲れてしまい、翌日まで引きずっていましたが、2週間もすると徐々に慣れてきました。また、体重が減るとともに上り坂での足の運びの軽さを感じられるようになりました。標高差20mを一気に登りきっても特に息が切れることもなく、足が軽く前に出る感覚が強くなります。

山手線一周

毎日10kmくらい歩いているとだんだん物足りなくなってくるもので、ふと山手線一周（約40km）を歩いてみました。9時間で完歩。そこそこ疲れましたが、良いモチベーションアップになりました。その後も、大江戸線全線制覇（約50km）、銀座線＋副都心線はしご（約40km）をやって、やるたびに身体に対するダメージが少なくなってきています。徐々に自分が強化されるのを感じ取れて楽しいです。

期待はずれだったトクホ

多少なりともダイエットの効率をあげようと思い、5月〜6月にかけて「からだすこやか茶W」を飲み続けました。しかしながら、グラフが示すとおり体重が減るペースに変化はありませんでした。公式ページによるとこのお茶の効果は「脂肪の吸収を抑える」「糖の吸収をおだやかにする」で、一言も体重を減らすとは書いてないんですよね。その表現どおりの効果なのだろうと思います。

一応補足情報を。公式情報によると1日3本飲むのが推奨とのことです。この商品には350mLサイズと1Lサイズのペットボトルがあり、公式情報からはどちらのサイズを3本飲むべきなのかは読み取れませんが、さすがに1日3L飲めって話はないと思うので、350mL×3に相当する量を飲み続けました。

酒を飲むと体重が増える

きわめて当たり前のことですが、飲み会が増えると体重が増えます。忘年会が連続した12月と帰省で運動ができなかった正月で2kgほど増えました。その後、生活リズムが元に戻ると体重も戻りました。これはペースを乱すといつでもリバウンドする可能性があることを意味します。

さいごに

継続できなければ元に戻るのは間違いありません。自分には食事制限や辛い運動を継続する精神力はないので、できる範囲で自分なりのルーティンを見つけることができたのが幸いだったと思います。それを見つけるための基礎情報がこまめな体重測定、といったところでしょうか。

今のところ毎日一定の距離を歩かないと物足りなく感じるので心配はありませんが、いつの日かリバウンドからカムバックしたくなったら自分でこの文章を見返して事象を再現させようと思います。

Joinノードを使う（その2）

2022-02-19T14:49:00.002+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はJoinノードの2回目です。

確認するサンプルは、「読み込み > サンプル > flows > node-red > sequence > join > 02 - Manual join mode」です。今度は「手動モード」だそうです。7つのフローから構成されています。ちょっと多すぎですが、それだけいろいろな使い方ができるのだと思います。

指定した個数のメッセージごとに結合する

一番上の段は、指定した個数のメッセージごと結合するサンプルです。左側のTemplateノードから設定を見ていきます。ここでは「msg.payload」に改行区切りの文字列を指定しています。

続いて、その右側にあるSplitノードです。msg.payloadには文字列が格納されているので、改行（\n）ごとに個別のmsgオブジェクトに分割します。今回の場合、4つのメッセージに分割されます。

続いて、Joinノードは以下のように設定されています。

たくさん設定が見えますが、以下の条件でメッセージを結合して送信するようです。

結合対象の入力メッセージのプロパティは「msg.playload」
出力はカンマ（,）区切りの文字列
msgオブジェクトを2つ受け取るか「msg.complete」プロパティが設定されたメッセージを受信したタイミングで送信

実行すると、4つに分割されていたであろうメッセージが以下のように2つに結合されています。

指定した時間内に受信したメッセージを結合する

2段目のフローでは、指定した時間内に届いたメッセージを結合します。例によって左から順に設定を見ていきます。TemplateノードとSplitノードは上述のサンプルと同じなので省略します。

続いて、Delayノードです。Splitノードで分割したメッセージの流量を1メッセージ/秒に制限します。

最後に、このフローのポイントとなるJoinノードです。最初のメッセージ受信から2秒経ったらメッセージを出力します。言い換えると、2秒以内に受信したメッセージを結合するってことでしょうね。

これを実行すると、最初に紹介したフロー同じようなログが出力されますが、2件出力されるログのタイムスタンプが2秒空いています。Joinノードから2秒毎に結合されたメッセージが出力されたことがわかります。

まとめ

まだまだ先は長そうなので、このへんで一旦まとめておきます。

Joinノードの手動モードは以下の条件でメッセージを結合して出力できます。

指定した個数のメッセージごと
指定した時間内に受信したメッセージごと

文字列結合する場合、区切り文字を指定できる
結合対象のプロパティを指定できる

Joinノードシリーズはもう少し続きます。

Joinノードを使う（その1）

2022-02-18T00:12:00.000+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はJoinノードを見ていきます。その名の通り、複数のメッセージを結合するのが役割です。前回ご紹介したSplitとは逆ですね。

確認するサンプルは、「読み込み > サンプル > flows > node-red > sequence > join > 01 - Automatic join mode」です。「自動モード」とやらがポイントのようです。3つのフローから構成されているので順に見ていきます。

Splitノードで分割したメッセージをJoinノードの自動モードで結合する

一番上の段は、Splitノードで分割したメッセージをJoinノードの自動モードで結合するサンプルです。左側のTemplateノードから設定を見ていきます。ここでは「msg.payload」に改行区切りの文字列を指定しています。

続いて、その右側にあるSplitノードです。msg.payloadには文字列が格納されているので、改行（\n）ごとに個別のmsgオブジェクトに分割します。

続いて、Joinノードは以下のように設定されています。

動作：自動

このモードでは、本ノードがSplitノードと組となるか、msg.partsプロパティが設定されたメッセージを受け取ることが前提となります。

このフローではmsg.partsプロパティは存在しないため、Splitノードと組となることが前提で動作します。実行すると以下のように4つに分割されたであろうメッセージが1つに結合されています。

これだけ見ると、分割した文字列をものをそのまま結合しただけなので、何が嬉しいのかサッパリ理解できませんが、ここでは基本的な動作はこういうものだと認識するのに留め、次のフローを確認していきます。

CSVデータをJSON配列に変換する

続いて2段目のフローでは、CSVデータをJSON配列に変換するサンプルです。結構使える場面が多いのではないでしょうか。例によって左から順に設定を見ていきます。Templateノードではmsg.payloadにCSVデータが指定されています。1列目が「name」で文字列データ、2列目が「price」で数値データ。各レコードは改行（\n）で区切られています。

続いて、csvノードです。CSVデータが入力されるので、以下の赤枠で囲った部分の設定が働きます。

CSVをオブジェクトに変換する
1行目に列名を含む
数値を変換する
行ごとにメッセージを分割

参考までに、Csvノードから出力されるmsgオブジェクト全体をログ出力すると、以下のような内容になっています。先ほどチラっと出てきたmsg.partsプロパティが見えます。どうやらこいつがこの後のJoinノードで利用されるようです（どのメッセージを結合対象とするか判断しているのではないかと思います）。

最後にJoinノードは最初にご紹介したフローと同じく自動モードになっています（画面キャプチャは省略）。

これを実行すると、Csvノードで分割されたメッセージがJSON配列に結合されて出力されます。なんかいい感じです。

CSVデータから条件を満たさないものを除外してJSON配列に変換する

3段目のフローでは、2段目のフローに条件を加えて、指定した条件を満たさないものをJSON配列から除外します。CsvノードとJoinノードの間に挟まっているSwitchノードがポイントです。「msg.payload.price」の値が100を以上のものをポートから出力します。

その他は2段目のフローと同じです。これを実行すると以下のようにpriceが100以上のオブジェクトのみ抽出されたログが出力されます。

まとめ

ここまで確認したことをまとめます。

Joinノードの自動モードはSplitノードとセットで利用する
他に、自動モードはmsg.partsを利用して結合動作を制御できる
CSVデータをJSON配列に変換できる

ついでにプロパティの値に応じてフィルタできる

Joinノードシリーズはもう少し続きます。

Splitノードを使う

2022-02-13T00:30:00.001+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はSplitノードを見ていきます。その名の通り、とにかくいろいろな値を分割するのが役割です。

確認するサンプルは、「読み込み > サンプル > flows > node-red > sequence > split > 01 - Split message payload」です。

4つのフローから構成されています。順に見ていきます。

特定の文字で文字列を分割する

一番上の段は入力「msg.payload」内の文字列を、指定した文字列（サンプルでは改行\n）で分割します。

msg.payloadには改行（\n）で区切られた文字列が指定されています。

実行すると、デバッグパネルに3件のログが出力されます。

一定の文字数ごとに文字列を分割する

続いて2段目のフローでは、入力「msg.payload」内の文字列を、指定した文字数ごとに分割します。

msg.payloadには先ほどと同じく改行（\n）で区切られた文字列が指定されています。これを実行すると、改行コード含め4文字ごとに分割されてログが出力されます。

配列を分割する

3段目のフローでは、入力「msg.payload」内の配列を、指定した要素数（サンプルでは1）ごとに分割します。

msg.payloadには文字列を要素に持つJSON配列が指定されています。

これを実行すると、配列の要素ごとにログが出力されます。

オブジェクトを分割する

最後の4段目のフローでは、入力「msg.payload」内のJSONオブジェクトをkey/valueの要素ごとに分割します。加えて、分割後のmsgオブジェクトの「msg.topic」にkeyに相当する文字列を格納します。

msg.payloadにはJSONオブジェクトが設定されています。

これを実行すると、要素ごとにログが出力されます。上述のSplitノードの設定通り「msg.topic」にkeyに相当する文字列が格納されていることと、「msg.payload」にvalueに相当する数値が格納されていることが確認できます。

まとめ

ここまで確認したことをまとめます。

msg.payloadに設定されている値の形式によって分割条件を指定できる
分割条件はいろいろある

文字列なら特定文字列や文字数
配列なら分割する要素数
JSONオブジェクトならオブジェクトの要素ごと

Udpノードを使う

2022-02-08T17:54:00.000+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はUdpノードを見ていきます。構成はほとんどTcpノードのサンプルと同じです。通信プロトコルがUDPを使っているだけで、表面上はTCPノードのサンプルと変わりません。ということで、これ以降全部省略してもいいのですが、サンプルを全部舐めることに意義があるので、儀式的に記事を書きます。

UDPクライアントからメッセージを送信する

確認するサンプルは、「読み込み > サンプル > flows > node-red > network > udp > 01 - Transfer data using UDP protocol」です。

上段のUdp outノードを確認すると、以下のように設定されています。

送信：UDPメッセージ
ポート：1881
アドレス：localhost, ipv4
ローカルポートをランダムに使用

localhostのポート番号1881番にipv4上でUDPメッセージを送信するようです。設定によってはブロードキャストメッセージやマルチキャストメッセージも送信できるようです。ipv6も選べます。

続いて、下段のUcp inノードを確認すると、以下のように設定されています。

待ち受け：UDPメッセージ
ポート：1881
種類：ipv4
出力：文字列

こちらは、UDPメッセージを待ち受けるようです。

Injectノードを実行すると、デバッグパネルに「Hello, World!」のログが出力されます。上段のフローで送信したUDPメッセージを下段のフローで受信してログ出力しています。

一応、動いてはいますが、これだけだとNode−RED内で完結してしまっているのでUDPサーバが動いている実感が湧きません。そこで、netcatコマンドを使ってUDPサーバにメッセージを送信してみます。

$ netcat -u localhost 1881
unko
unko

Node-REDのデバッグパネルを確認するとnetcatから送信した美しいメッセージが表示されています。以上で、UDPクライアントからメッセージを送信できました。

まとめ

ここまで確認したことをまとめます。

Udp outノードを利用してUDPメッセージが送信できる

ブロードキャストやマルチキャストメッセージも送信できるっぽい

Udp inノードを利用してUDPメッセージを受信できる

以上です。

あれ？Node-RED上にメッセージを送信するUDPサーバは構築できない？Udp outノードで待ち受けする設定がないので無理なのかな。

Tcpノードを使う（その3）

2022-02-01T22:24:00.010+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はTcpノードの最終回です。前々回の記事では、サーバからクライアントにメッセージを送信しました。前回の記事では、クライアントからサーバにメッセージを送信しました。今回は、クライアントからサーバにメッセージを送信し、そのコネクション上でサーバからクライアントにメッセージを返信します。普通のTCPクライアントとサーバのやり取りをまるっと実装します。

TCPクライアントとサーバ間でメッセージを送受信する

確認するサンプルは、「読み込み > サンプル > flows > node-red > network > tcp > 03 - Send reply to client of TCP connection」です。

上段はサーバに対してリクエストを送信後、サーバからのメッセージの返信を待ち受けるクライアントのフローです。グレーのTcp requestノードを確認すると、以下のように設定されています。

サーバ：localhost
ポート：1883
戻り値：指定文字の受信時　\n

Injectノードでは「Hello, World!\n」という文字列をpayloadに指定して送信しています。

一方、下段は接続を待ち受けるサーバサイドのフローです。Tcp inノードを確認すると、以下のように設定されています。

種類：待ち受け
ポート：1883
出力：ストリーム文字列のペイロード
区切り文字：\n

続いて、Changeノードを確認すると、msg.payloadの値を加工して、先頭に「Received: 」、末尾に改行コードを付加しています。

最後に、Tcp outノードは次のように設定されています。雰囲気的にmsg.payloadの内容をレスポンスとして返すんでしょうね。

種類：TCP応答

Injectノードを実行すると、デバッグパネルに「Received: Hello, World!\n」のログが出力されます。

上段のフローで「Hello, World!」のメッセージをサーバに送信する
下段のフローでサーバがメッセージを受信し、メッセージを加工してクライアントに返信する
上段のフローでサーバが返したメッセージをクライアントで受信してログ出力する

という流れです。

例によって、これでも一応動いてはいますが、Node−RED内で完結してしまっているのでTCPサーバが動いている実感が湧きません。そこで、TelnetクライアントでTCPサーバに接続してメッセージの送受信を行ってみます。

と、その前に、下段のTcp inノードの区切り文字設定を以下のように「\n」に変更しておきます。これはTelnetクライアントを動かすターミナルの改行コード設定と合わせるのが目的です。この設定が合っていないと、TelnetクライアントでEnterキーを押してもメッセージの送受信がうまく行われません。

この状態で、Telnetクライアントから「localhost 1883」に接続して適当な文字列（ここでは「fugo」）を入力してEnterキーを押下します。

$ telnet -a localhost 1883
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
fugo
Received: fugo

サーバから「Received: fugo」と返信が返ってきましたね。

まとめ

ここまで確認したことを一旦まとめます。

Tcp requestノードを利用するとメッセージの送信と返信の受信を行うTCPクライアントになります
Tcp inノードで「待ち受け」て、Tcp outノードで「TCP応答」を設定すると、クライアントの接続を待ち受けて、何らかの処理後にメッセージを返信するTCPサーバになります

この仕組を拡張すればWebサーバ、SMTPサーバ、FTPサーバなど、TCPベースのサーバは何でも作れそうです（誰もやらないと思いますが）。ということで、以上TCPノードシリーズでした。

Tcpノードを使う（その2）

2022-01-28T21:50:00.000+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はTcpノードの続きです。前回の記事と同様、TCPサーバとクライアントの間でメッセージを送受信しますが、今回はメッセージの流れる方向が逆で、TCPクライアントからサーバにメッセージを送信します。

TCPクライアントからサーバにメッセージを送信する

確認するサンプルは、「読み込み > サンプル > flows > node-red > network > tcp > 02 - Connect to tcp in server」です。

上段のTcp outノードを確認すると、以下のように設定されています。

種類：接続
ホスト：localhost
ポート：1882
メッセージを送信するたびに接続を切断：ON

localhostのポート番号1882番に接続してメッセージを送信するクライアントのフローです。メッセージを送信したら接続を切断します。

続いて、下段のTcp inノードを確認すると、以下のように設定されています。

種類：待ち受け
ポート：1882
出力：単一文字列のペイロード

こちらは、TCPクライアントからの接続を待ち受けるサーバサイドのフローです。

Injectノードを実行すると、デバッグパネルに「Hello World!」のログが出力されます。上段のフローで実装したクライアントから下段のフローで実装したTCPサーバにメッセージを送信します。サーバが受信したメッセージをログ出力しています。

一応、動いてはいますが、これだけだとNode−RED内で完結してしまっているのでTCPサーバが動いている実感が湧きません。そこで、TelnetクライアントでTCPサーバに接続してメッセージを送信してみます。

と、その前に、下段のTcp inノードの出力設定を以下のように「ストリーム」に変更しておきます。

この状態で、Telnetクライアントから「localhost 1882」に接続して適当な文字列（ここでは「hello tcp!」）を入力してEnterキーを押下します。

$ telnet -a localhost 1882
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hello tcp!

Node-REDのデバッグパネルを確認すると、Telnetで入力したメッセージがログ出力されることが確認できます。

以上で、Telnetクライアントから送信したメッセージをTCPサーバで受信できることが確認できました。

まとめ

ここまで確認したことを一旦まとめます。

Tcp outノードの種類を「接続」に設定すると、TCPサーバに接続してメッセージを送信するクライアントになります
Tcp inノードの種類を「待ち受け」に設定すると、クライアントからメッセージを受信するサーバになります

Tcpノードシリーズは次回が最終回です。

Tcpノードを使う（その1）

2022-01-24T22:26:00.001+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回からTcpノードを見ていきます。ざっと見た感じ、サンプルフローの構成はWebSocketノード似ており、TCPサーバとクライアント間でメッセージの送受信ができます。

TCPクライアントにメッセージを送信する

確認するサンプルは、「読み込み > サンプル > flows > node-red > network > tcp > 01 - Connect to tcp out server」です。Node-RED上で動作するTCPサーバからクライアントにメッセージを送信します。

上段のTcp outノードを確認すると、以下のように設定されています。

種類：待ち受け
ポート：1881
メッセージを送信するたびに接続を切断

ポート番号1881番で待ち受けるTCPサーバって感じでしょうか。メッセージを送信したら毎回接続を切断するようです。

続いて、下段のTcp inノードを確認すると、以下のように設定されています。

種類：接続
ポート：1881
ホスト：localhost
出力：単一文字列のペイロード

こちらは、TCPサーバに接続するクライアントサイドのフローでしょうか。

Injectノードを実行すると、デバッグパネルに「Hello World!」のログが出力されます。上段のフローでポート1881番で待ち受けるTCPサーバにメッセージを送信して、下段のフローで受信したメッセージをログ出力しています。イメージ的には、上下段のフローの間にTCPサーバがいて、Node-REDのフロー上でメッセージの送信と受信ができたということになります。

一応、動いてはいますが、これだけだとNode−RED内で完結してしまっているのでTCPサーバが動いている実感が湧きません。そこで、TelnetクライアントでTCPサーバが送信するメッセージを受信してみます。Telnetクライアントでlocalhost:1881に接続します。

$ telnet -a localhost 1881
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

この状態でさきほどと同様Injectノードを実行すると、以下のようにTelnetクライアント上に「Hello, World!」の文字列が出力され、接続が切断されます。

$ telnet -a localhost 1881
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Hello, World!Connection closed by foreign host.
$

以上で、TCPサーバが送信するメッセージをTelnetクライアントで受信できることが確認できました。

まとめ

ここまで確認したことを一旦まとめます。

Tcp outノードの種類を「待ち受け」に設定すると、TCPクライアントの接続を待ち受けるサーバになります
Tcp inノードの種類を「接続」に設定すると、サーバからメッセージを受信するクライアントになります

次回は、TCPクライアントからメッセージを送信してみます。

WebSocketノードを使う（その2）

2022-01-18T00:11:00.001+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。前回に続きWebSocketノードを見ていきます。

WebSocketサーバからメッセージを受信する

確認するサンプルは、「読み込み > サンプル > flows > node-red > network > websocket > 02 - Connect to websoket out server」です。Node-RED上のWebSocketサーバが送信するメッセージをクライアントで受信します。

上段のWebSocket outノードを確認すると、以下のように設定されています。

種類：待ち受け
URL：/ws2

WebSocketサーバ「/ws2」でクライアントからの接続を待ち受ける、いわゆるサーバサイドのフローです。

続いて、下段のWebSocket inノードを確認すると、以下のように設定されています。

種類：接続
パス：ws://localhost:1880/ws2

こちらは、「ws://localhost:1880/ws2」からメッセージを受信するWebSocketのクライアントサイドのフローです。

Injectノードを実行すると、デバッグパネルに「Goodbye, World!」のログが出力されます。上段のフローでクライアントからの接続を待ち受けるWebSocketサーバを起動して、クライアントに対してメッセージを送信します。下段のフローではWebSocketクライアントが接続したサーバが送信したメッセージをログ出力しています。こちらも前回の記事と同様、イメージ的には、上下段のフローの間にWebSocketサーバがいて、Node-REDのフロー上でメッセージの送信と受信ができたということになります。

これで一応、動いてはいますが、これだけだとNode−RED内で完結してしまっているのでWebSocketが動いている実感が湧きません。そこで、ブラウザからWebSocketサーバに接続してメッセージを受信してみます。ということで、さきほど確認したサンプルに以下のフローを加えます。

Templateノードは以下のように設定します。違いは接続するWebSocketサーバのURL（ws://localhost/ws2）のみです。

ブラウザから「http://localhost:1880/hello」にアクセスすると、ブラウザのコンソール上に「onopen」のログが出力されています。WebSocketサーバに接続ができているようです。ここで、Node-REDのフロー上でInjectノードを実行すると、WebSocketサーバ「/ws2」に接続しているすべてのクライアントに対して「Goodbye, World!」のメッセージを送信します。Node-REDのデバッグパネルを確認すると、「onmessage: Goodbye, World!」のメッセージが出力されるはずです。これで、Node-RED上のサーバが送信したメッセージをブラウザで受信できることを確認できました。

まとめ

ここまで確認したことをまとめます。

WebSocket outノードの種類を「待ち受け」に設定すると、WebSocketで接続を待ち受けるサーバになります
WebSocket inノードの種類を「接続」に設定すると、WebSocketサーバにメッセージを送信するクライアントになります

ちょうど前回ご紹介したWebSocket outノードとWebSocket inノードの設定を入れ替えることでメッセージの送信と受信の関係が入れ替わります。

WebSocketノードを使う（その1）

2022-01-12T22:03:00.008+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回からWebSocketノードを見ていきます。

WebSocketクライアントが送信するメッセージを待ち受ける

確認するサンプルは、「読み込み > サンプル > flows > node-red > network > websocket > 01 - Connect to websoket in server」です。WebSocketクライアントが送信するメッセージをNode-REDで待ち受けます。

上段のWebSocket outノードを確認すると、以下のように設定されています。

種類：接続
URL：ws://localhost:1880/ws1

メッセージをWebSocketサーバ「ws://localhost:1880/ws1」に送信する、いわゆるクライアントサイドのフローです。

続いて、下段のWebSocket inノードを確認すると、以下のように設定されています。

種類：待ち受け
パス：/ws1

こちらは、「/ws1」でメッセージを待ち受けるWebSocketのサーバサイドのフローです。

Injectノードを実行すると、デバッグパネルに「Hello World!」のログが出力されます。上段のフローでWebSocketサーバにメッセージを送信して、下段のフローでWebSocketサーバが受信したメッセージをログ出力しています。イメージ的には、上下段のフローの間にWebSocketサーバがいて、Node-REDのフロー上でメッセージの送信と受信ができたということになります。

一応、動いてはいますが、これだけだとNode−RED内で完結してしまっているのでWebSocketが動いている実感が湧きません。そこで、ブラウザからWebSocketサーバにメッセージを送信してみます。ということで、さきほど確認したサンプルに以下のフローを加えます。

Templateノードは以下のように設定します。

ブラウザから「http://localhost:1880/hello」にアクセスすると、画面上には「送信」ボタンが表示されます。ブラウザのコンソールを確認すると「onopen」のログが出力されています。WebSocketサーバに接続ができているようです。ここで「送信」ボタンを選択すると、WebSocketサーバ「ws://localhost:1880/ws1」に「send message from browser」のメッセージを送信します。Node-REDのデバッグパネルを確認すると、同じメッセージが出力されるはずです。これで、ブラウザが送信したメッセージをNode-RED上のWebSocketサーバで受信できることを確認しました。

まとめ

ここまで確認したことを一旦まとめます。

WebSocket outノードの種類を「接続」に設定すると、WebSocketでメッセージを送信するクライアントになります
WebSocket inノードの種類を「待ち受け」に設定すると、メッセージを待ち受けるWebSocketサーバになります

次回は、WebSocketサーバからメッセージを送信してみます。

HTTPノードを使う（その4）

2022-01-07T22:39:00.001+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。年が明けましたが、新年の展望もご挨拶もなく、引き続きマシーンのようにサンプルフローを見ていきます。今回はHTTPノード最終回です。

Cookieを扱う

確認するサンプルは、「読み込み > サンプル > flows > node-red > network > http > 07 - Working with cookies」です。フローは3段階に別れており、それぞれ以下の動作をします。

/hello-cookie：cookieデータにアクセスしてHTMLに埋め込んで返却

上段は、cookieの中身をHTMLに埋め込んで返すフローです。説明文にある通りブラウザから「http://localhost:1880/hello-cookie」にアクセスすると以下のページが表示されます。

フローの中身を確認すると、Functionノードで「msg.req.cookies」の内容をJSON文字列化してmsg.payloadに代入しています。msg.payloadは、この後のTemplateノードでHTMLに埋め込まれます。

/hello-cookie/add：cookieにデータを追加

ブラウザ画面上に表示されている「Add a cookie」リンク（http://localhost:1880/hello-cookie/add）を選択すると中段のフローが開始され、cookieに適当なキーバリュー値が追加されます。

中段のFunctionノードを確認すると、「msg.cookie」にキーとしてランダム生成した文字列と、値として現在時刻を登録しています。

その後、ブラウザにリダイレクトを指示するため、「statusCode = 302」、「msg.headers.location = /hello-cookie」を設定して返却します。これにより最初のフローに戻ります。

/hello-cookie/clear：cookieをクリア

ブラウザ画面上で「Clear Cookies」リンク（http://localhost:1880/hello-cookie/clear）を選択すると下段のフローが開始されます。下段のFunctionノードで「msg.cookies」を空にしています。

まとめ

ここまで確認したことをまとめます。

クライアントからアクセスを受けた際のフローでは、「msg.req.cookies」でcookieデータにアクセスできます
クライアントにレスポンスを返すフローでは、「msg.cookies」にキーバリュー形式で値を設定してHTTP OUTノードに渡すことでcookieデータに変更を加えることができます

以上HTTPノードは終了です。

HTTPノードを使う（その3）

2021-12-27T00:13:00.000+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。前回に引き続き、機械的にHTTPノードのサンプルフローを見ていきます。

ファイルを送受信する

確認するサンプルは、「読み込み > サンプル > flows > node-red > network > http > 06 - Post file to a flow」です。フローは2段階に別れており、それぞれ以下の動作をします。

上部フロー：ファイルアップロード用フォーム生成

ファイルのアップロード用ページを表示するためのフローです。パス「/hello-upload」でGETメソッドによるアクセスを待ち受けています。ブラウザから「http://localhost:1880/hello-upload」にアクセスすると以下のページを表示します。

HTMLボディ部は上部フローのTemplateノードで生成しています。

ブラウザ画面上に表示されている「選択...」ボタンを選択するとファイル選択ダイアログが表示されるので、適当なファイルを選択して、ブラウザ画面上の「OK」ボタンを選択すると、上述のHTMLの通り、選択したファイルをパス「/hello-uplad」にPOSTします。

下部フロー：アップロードされたファイルを受信

上部フローにてアップロードされたファイルを受信するフローです。パス「/hello-upload」でPOSTメソッドによるアクセスを待ち受けています。ファイルがアップロードされるとブラウザ画面上に「Hello <ファイル名>」を表示します。

ページの内容は下部フローのTemplateノードで生成しています。「{{req.files.0.originalname}}」という表記を使ってPOSTデータ内の1つ目のファイル名にアクセスしています。

reqオブジェクトに他にどんなプロパティがあるのかはhttp inノードに載っています。

まとめ

ここまで確認したことをまとめます。

アップロードされたファイルには「{{req.files.<ファイルIndex>...}}」でアクセスできます
reqプロパティ配下のプロパティについて知りたいときはhttp inノードのヘルプを確認します

まだ次回に続きます。

HTTPノードを使う（その2）

2021-12-25T06:23:00.004+09:00

リクエストヘッダを扱う

確認するサンプルは、「読み込み > サンプル > flows > node-red > network > http > 04 - Access HTTP request headers」です。リクエストヘッダの扱い方を確認できます。フローは前回の記事で紹介したものとほぼ同じなので、細かい説明は省略します。ポイントはTemplateノードにある「{{req.headers.user-agent}}」です。これでHTTPリクエスト内のUser-Agentヘッダの値が取得できます。

ペイロードを扱う

ペイロード＝HTTPボディ部ですね。確認するサンプルは、「読み込み > サンプル > flows > node-red > network > http > 05 - Post data to a flow」です。これも前回紹介したフローとほぼ同じなので詳細は省略します。ポイントは「{{payload}}」でHTTPリクエストのボディ部（つまりペイロード）にアクセスできる点です。

まとめ

内容は薄めですが、ここまで確認したことをまとめます。

リクエストヘッダには「{{req.headers.<ヘッダ名>}}」でアクセスできます

headers配下に個別のヘッダに対応したプロパティがぶら下がります

ペイロードには「{{payload}}」でアクセスできます

まだまだ次回に続きます。

HTTPノードを使う（その1）

2021-12-23T00:29:00.007+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回から何回かにわけてHTTP関連ノードを使ってみます。実はだいぶ前の記事「Node-REDでWebサーバを作ってみる」でHTTPノードのサンプル01は確認済みなので、残りのサンプルを見ていきます。

クエリパラメーターを扱う

最初に確認するサンプルは、「読み込み > サンプル > flows > node-red > network > http > 02 - Handle query parameters」です。クエリパラメータの扱い方を確認できます。

まず、上半分のフローです。エンドポイント「http://localhost1880/hello-query」にてHTTPのGETリクエストを待ち受けます。Templateノードでは「{{req.query.name}}」の形式でクエリ内の「name」パラメータにアクセスして、値をHTMLに埋め込んでHTTP responseを返しています。

続いて下半分のフローでは、上半分のフローで待ち受けているエンドポイントに対してHTTPリクエストを送信しています。リクエストではクエリパラメーター「name」に値「Nick」を指定しています。そして、HTTPレスポンスをDebugノードで出力しています。

フローを実行すると、以下のログが出力されます。さきほどの「{{req.query.name}}」が値「Nick」に置き換わっていますね。

URLパラメータを扱う

続いて、URLパラメータを扱う方法を確認します。確認するサンプルは、「読み込み > サンプル > flows > node-red > network > http > 03 - Handle URL parameters」です。さっきと似ていますが、今度はクエリストリングではなく、URLの一部をパラメータ化して扱っています。

さきほどのサンプルと同じく、上半分のフローはHTTPのリクエスト待受とレスポンスの構築を行っています。http inノードでは「:name」という形式で、URLの一部をパラメータ化しています。Ruby on RailsなどのWebアプリケーションフレームワークのRouter系機能でよく見る形式です。これで、Node-REDがHTTPリクエストを受信すると、クエリパラメータ内の「name」の値（Nick）にアクセスできます。

Templateノードでは「{{req.params.name}}」の形式でURLパラメータにアクセスしています。

続いて下半分のフローでHTTPリクエストを送信しています。アクセス先URLは「http://localhost:1880/hello-param/Nick」です。もうおわかりかと思いますが、「{{req.params.name}}」の部分が「Nick」に置き換わります。

まとめ

ここまで確認したことをまとめます。

クエリパラメーターには「{{req.query.<パラメーター名>}}」でアクセスできます
URLパラメーターには「{{req.params.<パラメーター名>}}」でアクセスできます

次回に続きます。

MQTTノードを使う

2021-12-20T23:44:00.003+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はMQTTノードを使ってみます。私はMQTTについてはあまり詳しくなく、うっすらIoTの分野で使われていることを聞いたことがある程度です。まずはMQTTについて調べるところから開始しました。

MQTTの概要

Wikipediaによると、こんな感じの説明があります。

Message Queuing Telemetry Transportの略
TCP/IPによるPub/Sub型のデータ配信モデル
軽量な通信電文
メッセージブローカーが必要

Pub/Sub型と言えば、トポロジー的にはAWSで言うところのSNSみたいなもんですかね。軽量なのでスペックの低いIoT機器でも扱いやすいということなのでしょう。だいたい理解しました。

ブローカーのインストールと起動

Node-REDのドキュメントに使い方の説明があるので、実際にやってみます。ブローカーが必要なので、まずはmosquittoなるものをインストールおよび起動します。ちなみに、Mac上で作業しています。

$ brew install mosquitto
$ mosquitto
1640008513: mosquitto version 2.0.14 starting
1640008513: Using default config.
1640008513: Starting in local only mode. Connections will only be possible from clients running on this machine.
1640008513: Create a configuration file which defines a listener to allow remote access.
1640008513: For more details see https://mosquitto.org/documentation/authentication-methods/
1640008513: Opening ipv4 listen socket on port 1883.
1640008513: Opening ipv6 listen socket on port 1883.
1640008513: mosquitto version 2.0.14 running

動いたようです。これでlocalhostの1883ポートでブローカーが待ち受けを開始しました。

MQTTノードを使ったフローの作成

いよいよ、フローを作っていきます。「mqtt in」ノードと「mqtt out」ノードを含めて以下のように配置します。

上部のmqtt outノードでブローカーにメッセージを送信しています。一方、下部のmqtt inノードでブローカーが配信したメッセージを受信しています。イメージではノードのステータスが「接続済」となっていますが、現時点ではステータスの表示が違っていても気にしなくて大丈夫です。

mqtt outノードは以下のように設定します。この内、「サーバ」は右上の鉛筆アイコンを選択して編集します。トピックはとりあえず「hoge」の文字を指定しておきます。

続いて、サーバの編集を行います。「サーバ」と言っていますが、実際には「mqtt-brokerノード」の編集画面です。ポイントは以下のとおりです。

名前：ブローカーを識別するための適当な文字列を指定します
サーバ：今回はローカルのブローカーに接続するので「localhost」と入力します
ポート：デフォルトの「1883」のままにしておきます

さっき起動したmosquittoと合わせておきます

続いて、mqtt inノードは以下の通りに設定します。

サーバ：先程設定したmqtt brokerノードの設定を選択します。
トピック：mqtt outノードと同じく「hoge」と設定します

以上で設定は完了です。設定が正しければ、デプロイするとmqtt inノードとmqtt outノードのステータスに「接続済」と表示されるはずです。

フローを実行すると以下のようなログが出力されます。

payload：injectノードで設定した時刻が出力されています
topic：mqtt in/outノードで設定したトピック名「hoge」が出力されています

MQTTクライアントで送信したメッセージをmqtt inノードで受信する

続いて、3rdパーティ製のMQTTクライアントで送信したメッセージをmqtt inノードで受信します。今回利用したMQTTクライアントは「MQTT X」です。ポイントは以下の通りで、最初にインストールしたブローカーmosquittoの待受ポートに接続設定します。

Host：localhost
Port：1883

Connectした後、トピック「hoge」に対して以下のようなメッセージを送信します。

Node-REDではmqtt inノードで受信した以下のようなメッセージがログ出力されているはずです。

まとめ

ここまで確認したことをまとめます。

ブローカーをインストール＆起動しました
mqtt in/outノードからブローカーに接続して、メッセージの送受信を確認しました
3rdパーティ製MQTTクライアントが送信したメッセージをmqtt inノードで受信できることを確認しました

MQTTノードについてはこんなもんでしょうか。

Filterノードを使う

2021-12-15T23:41:00.000+09:00

ここのところずっとNode-REDのサンプルを見ながら各ノードの使い方を確認しています。頭出しの記事はこちらをご確認ください。今回はFilterノードを使ってみます。大量のメッセージを入力して、条件を満たした場合のみメッセージを出力するノードです。大量のデータを発生させる加速度センサーみたいなものを扱うのに使えそうです。

入力値が変化したら出力する

Filterノードには標準のサンプルが提供されていないのでやむを得ず自作します。最初に作ったのはこんな感じのフローです。

Filterノードのプロパティは次のとおりです。

動作は「値が変化したときのみメッセージを中継」
対象プロパティは「msg.payload」

ここに2つのInjectノードでメッセージを流し込みます。

1つ目は、msg.payloadに「aaa」という文字列を設定したメッセージを1秒に1回繰り返し流す
2つ目は、msg.payloadに「bbb」という文字列を設定したメッセージを単発で流す

デプロイすると、「aaa」のログが1回出力されます。msg.payloadの値が変化したのでメッセージが中継されたようです。その後、Injectノード「bbb」を実行すると、「bbb」のログと「aaa」のログが1件ずつ出力されます。Injectノード「bbb」を選択したことによりmsg.payloadの値が変化したのでメッセージが中継され、その後、Injectノード「aaa」の定期的な動作により再びmsg.payloadの値が変化したので中継されたようです。Filterノードのヘルプではこの設定のことを「RBEモード（Report by Exception）」と表現しているようです。

ちなみに、Filterノードの動作で「値が変化したときのみメッセージを中継（初期値を無視）」を選択すると、デプロイ時の「aaa」が出力されなくなります。フローリセット時に値が変化しないものとしてFilterノードの動作を抑制するのに利用できそうです。

入力値が指定した値を超えて変化したら出力する

続いて、入力値が指定した値を超えて変化したらメッセージを出力する動作を確認するために以下のようなフローを作成しました。

ポイントは以下の点です。

Filterノードの動作が「最後の出力値と比較して10%以上変化したらメッセージを中継する」
Injectノードはmsg.payloadに数値「100」を繰り返し流し、手動で数値「120」を流せるようにする（しきい値以上変化する）

実行すると、以下のようになログが出力されます。最後に入力した値と比較して10%以上変化していたらメッセージを転送します。ちなみにFilterノードのヘルプではこのモードのことを「不感帯モード」と表現しているようです。

入力値が指定した値を超えて変化したら無視する

最後にご紹介するのは、入力値が指定した値を超えて変化したら無視する動作です。Filterノードのヘルプでは「狭帯域モード」と呼んでいます。要は、指定した値を超えたら異常値とみなして無視します。

フローを実行すると以下の挙動になります。

デプロイして放置すると1秒毎に「100」のログが出力され続けます
Injectノード「120」を何度選択しても「120」のログは出力されません

これは設定した値10%を超えて変化したものは無視する設定になっているためです。これ以上の説明は不要かと思います。

まとめ

ここまで確認したことをまとめます。

RBEモードではFilterノードに対する入力値が変化したらメッセージを転送します

値が変化しなかったら無視（Filter）します

不感帯モードではFilterノードに対する入力値が指定した値を超えて変化したらメッセージを転送します

範囲内に収まっているものは無視（Filter）します

狭帯域モードではFilterノードに対する入力値が指定した値の範囲内ならメッセージを転送します

範囲を超えたものは無視（Filter）します

Filterノードについては以上です。