Node-REDでつまづいた記録

MC Protocolのデバイス指定方法

→デバイス, 個数で指定する。　X0から１０点ならば、X0,10　となる。

Joinノードに接続するノードの設定

Topicをキーとしてまとめることがよくある。
事前に、接続するフローには重複しないキーを設定しておく必要がある。

指定数のメッセージパーツを受信後　を接続個数に設定すると異なるフローのデータの待ち合わせを行うことができる

よくつかう書き方　let cnt = flow.get(“AAA”) || 0;　の||はなんですか

この || は、JavaScript における 「論理和（OR）」演算子 です。
ですが、Node-RED の Function ノードなどで使う場合、次のような意味で使われることが多いです。
➡ 「flow.get(“AAA”)
の値が null
または undefined
または false
または 0
または 空文字なら、
代わりに 0 を使う」 という意味です。

つまり：
「AAA」というフロー変数に値が入っていればその値を使う。
もし値がまだセットされていなければ（undefined）、初期値として 0 を使う。

|| の動作イメージ

flow.set("AAA", undefined);
let cnt = flow.get("AAA") || 0;  // cnt = 0

flow.set("AAA", 5);
let cnt = flow.get("AAA") || 0;  // cnt = 5

let result = 左側 || 右側;

という形の場合、

左側の値が「truthy（真っぽい値）」ならその値を返す。

左側の値が「falsy（偽っぽい値）」なら右側の値を返す。

falsy（偽っぽい値）とは？
JavaScript で false と見なされる値です。主なものは：

似たような書き方で　let cnt = flow.get(“AAA”) ?? 0;　 →0に意味がある場合に使用する

let cnt = flow.get("AAA") ?? 0;
➡ flow.get("AAA") が null または undefined のときだけ 0 を使う。

0 を有効値とするなら、|| よりも ??（Null 合体演算子）を使うのが最近の書き方です：
(前の|| では、0はfalsyな値として扱われてしまうため)

Function 内で、変数先頭文字が大文字小文字の変数でハイライトがことなるのはなぜですか？

Node-RED の Function ノードのエディタや多くのコードエディタ（Monaco、CodeMirror など）では、変数名の先頭文字の大文字・小文字でハイライトの色を変えることがよくあります。

その理由は：
1️⃣ 大文字始まりの識別子は「コンストラクタ・クラス的なもの」と推測
➡ JavaScript の慣例で、大文字始まりは「クラス名」や「コンストラクタ関数」に使われます。
（例：Date, String, AutoModeOffStartTime）

2️⃣ 小文字始まりは通常の変数・関数名と認識
➡ 小文字始まりは、一般的な変数や関数に使われます。
（例：prevIsAutoMode, msg）

Dashboard2.0　Template　に使用するVue.jsのライフサイクルについて教えて

Vue コンポーネントのライフサイクル

1️⃣ beforeCreate
2️⃣ created
3️⃣ beforeMount
4️⃣ mounted
5️⃣ beforeUpdate
6️⃣ updated
7️⃣ beforeUnmount / beforeDestroy (Vue 2)
8️⃣ unmounted / destroyed (Vue 2)

1️⃣ beforeCreate

✅ インスタンスが作られた直後。
✅ data や methods などはまだ使えない。

javascriptコピーする編集するbeforeCreate() {
  console.log("beforeCreate: data はまだ使えない");
}

👉 ほとんど使うことは少ない。

2️⃣ created

✅ data, methods, computed, watch が初期化された直後。
✅ まだ DOM（画面）は作られていない。

javascriptコピーする編集するcreated() {
  console.log("created: data や methods が使える");
  console.log(this.message); // data の値
}

👉 API データの取得や初期化処理に適しています。

3️⃣ beforeMount

✅ テンプレートが仮想 DOM として準備されたが、まだ画面には描画されていない。

javascriptコピーする編集するbeforeMount() {
  console.log("beforeMount: 仮想DOMが準備された状態");
}

👉 特に処理を入れる必要はあまりない。

4️⃣ mounted

✅ コンポーネントがブラウザの DOM に描画された直後。

javascriptコピーする編集するmounted() {
  console.log("mounted: DOM にアクセス可能");
  this.$refs.xxx.focus();  // DOM 操作
}

👉 DOM 操作、外部ライブラリ初期化、タイマー開始に最適。

5️⃣ beforeUpdate

✅ データが変更され、再描画が始まる直前。

javascriptコピーする編集するbeforeUpdate() {
  console.log("beforeUpdate: データが変わってこれから画面が再描画される直前");
}

👉 更新前の DOM の状態を記録したいときに便利。

6️⃣ updated

✅ データの変更による画面更新が完了した後。

javascriptコピーする編集するupdated() {
  console.log("updated: DOM が新しい状態に更新された後");
}

👉 データ更新後の DOM を確認・操作したいときに使います。

7️⃣ beforeUnmount (Vue 3) / beforeDestroy (Vue 2)

✅ コンポーネントが画面から消える直前。

javascriptコピーする編集するbeforeUnmount() {
  console.log("beforeUnmount: コンポーネントが消える前");
}

👉 タイマーの停止、イベントリスナの削除など後始末に最適。

8️⃣ unmounted (Vue 3) / destroyed (Vue 2)

✅ コンポーネントが完全に破棄された後。

javascriptコピーする編集するunmounted() {
  console.log("unmounted: 完全に消えた");
}

👉 リソースの完全なクリーンアップ。

Dashboard2.0　Template　ライフサイクルの中で、すでに予約されている主なオプションの一覧を教えてください。

beforeCreate → created → beforeMount → mounted → beforeUpdate → updated
→ beforeUnmount → unmounted

export default {
  data() {},
  methods: {},
  computed: {},
  watch: {},
  props: {},
  mounted() {},
  beforeUpdate() {},
  updated() {},
  // ...他のライフサイクルやオプション
}

それぞれの書くべき処理の例を以下に示します。

1. data()

javascriptコピーする編集するdata() {
  return {
    count: 0,
    users: [],
    dialogOpen: false
  };
}

2. props

javascriptコピーする編集するprops: {
  title: { type: String, required: true },
  pageSize: { type: Number, default: 10 },
  user:   { type: Object, validator: v => !!v.id }
}

3. computed

javascriptコピーする編集するcomputed: {
  filteredUsers() {
    return this.users.filter(u => u.active);
  },
  fullName() {
    return `${this.first} ${this.last}`;
  }
}

4. methods

javascriptコピーする編集するmethods: {
  async fetchUsers() {
    this.loading = true;
    this.users = await api.getUsers();
    this.loading = false;
  },
  increment() {
    this.count++;
  }
}

5. watch

javascriptコピーする編集するwatch: {
  searchQuery: _.debounce(function (q) {
    this.fetchUsers(q);
  }, 300),
  "$route.params.id"(newId) {
    this.loadDetail(newId);
  },
  settings: {
    deep: true,
    handler(val) {
      localStorage.setItem("settings", JSON.stringify(val));
    }
  }
}

6. ライフサイクルフック

javascriptコピーする編集するcreated() {
  this.fetchUsers();
},
mounted() {
  this.chart = initChart(this.$refs.canvas);
},
beforeUnmount() {
  clearInterval(this.timer);
  this.chart.destroy();
}

7. components / directives / filters

javascriptコピーする編集するcomponents: { UserCard, Pagination },
directives: {
  focus: {
    mounted(el) { el.focus(); }
  }
},
// Vue 2 のみ
filters: {
  currency(v) { return v.toLocaleString() + " 円"; }
}

8. provide / inject

javascriptコピーする編集する// 祖先
provide() { return { theme: reactive({ dark: false }) }; }

// 子孫
inject: ["theme"],
mounted() { console.log(this.theme.dark); }

使い所：グローバルに近い小規模状態共有（i18n, テーマ, フォーム系など）。

9. mixins / extends

• mixins：複数ファイルへ横断する共通ロジック注入
• extends：単一ベースコンポーネントを継承し追加・上書き

javascriptコピーする編集するconst timeMixin = {
  created() { console.log("now:", Date.now()); }
};

export default {
  mixins: [timeMixin]
};

✅ “どこに何を書くべきか” 早見チャート

Node-REDの設定ファイルの在処を教えて下さい

設定ファイルの所在：/home/ユーザー名/.node-red/settings.js（デフォルト）

Node-RED起動時のログで所在を確認できます。

23 Jul 10:03:25 - [info] Settings file  : /home/pi/.node-red/settings.js　←これ
23 Jul 10:03:25 - [info] User directory : /home/pi/.node-red

もし「Settings file : none」と出る場合は、ユーザーディレクトリに settings.js がない状態でデフォルト設定が使われています。

NOTE!　sudo　nano /home/ユーザー名/.node-red/settings.js で編集すると、管理者権限のディレクトリになってしまうため　sudoはつけないで編集を行うこと

サービスで起動している場合は、一度止めないと再起動ができないため以下を実行

sudo systemctl stop nodered

Node-REDの設定ファイルで設定できる項目を教えて下さい

以下の方が非常にわかりやすくまとめておられます。

Qiita

Node-REDの設定 - Qiita Node-REDはsettings.jsで各種設定を行います。自分の環境で現在どのsettings.jsを見ているか確認するにはNode-RED起動時の以下のログを見ます。 Welcome to Node-RED =====...

httpStatic (自分がためしたこと)

フォルダを公開してファイル共有

Node-RED の httpStatic 機能（設定ファイルを編集）

/home/pi/.node-red/settings.js を開き、以下を追記 or 編集（コメントアウトされている箇所を復活させて追記するとよい)

httpStatic: [
  { path: '/home/yoshiki/Share',  root: '/share/' }
],

どう動くか
Node-RED の HTTP サーバは、受け取ったリクエストが
http://:1880/share/… で始まっているかをチェック。

マッチしたら /home/yoshiki/Share 直下の同名ファイルを探し、そのまま返却 します。

例）

実ファイル: /home/yoshiki/Share/Log.csv

アクセス URL: http://:1880/share/Log.csv

root を省略するとトップレベル（/）に公開されますが、今回のように別パスを指定すると
エディタ UI やフロー用エンドポイントと衝突しにくい のがメリットです。

Node-RED 3.x 以降は httpStatic を 配列 で書けるようになり、複数フォルダーを別々の URL にマウント できます

この設定にしておけば、/home/yoshiki/Share フォルダーを “/share/” という仮想パスで公開 できるというわけです。

日付型の変換メソッドの変換結果比較

日付型には沢山の文字列変換形式があります。

以下は Node-RED の Function ノード（= Node.js の Date オブジェクト）で使える主要な “to〇〇String” 系メソッド を横並びで比較した早見表です。
例として同じ日時 ― new Date('2025-07-01T07:45:31.781Z') ― を JST (+09:00) で実行した場合にどう見えるかを示しています。

※ 実際の文字列は実行環境のタイムゾーンとロケール設定（LANG, LC_TIME など）に依存します。特に toLocale* 系は OS の言語設定によって「2025/7/1 16:45:31」や「2025年7月1日 16:45:31」など細部が変わる点に注意してください。