波仔
🍓 第十三章 IoT 实验范例：温湿度监控与 Node-RED
📄 一句话概括

给 Node-RED 装上 Dashboard（仪表板），把温湿度数据画成指针仪表与历史曲线——数据留在家里、手机打开就能看；这是本章也是【IoT 基础线】的收官实验：从一根 GPIO 针脚到一块自己的监控面板。

📝 本节和前面几节的关系

13-3 把数据送去了云端（ThingSpeak），本节把展示权收回本地：13-4 的流式画布负责收数据，Dashboard 负责画出来。13-2 留下的问题（浏览器不刷新就看不到新状态）在这里正式解决——仪表板是服务器主动推送，数据一到页面自动动。

一、先认门：Dashboard 1 与 Dashboard 2

⚠️ 老教程哪几处已失效（本章防坑段 ④）
  1. 两代仪表板并存：老教程装的 node-red-dashboard（Dashboard 1）已进维护模式，靠的底层库不再更新；当下正路＝@flowfuse/node-red-dashboard（Dashboard 2）——两者界面不兼容、官方没有迁移工具，新项目直接上 2；
  2. 安装地址不同：Dashboard 1 的页面是 /ui，Dashboard 2 是 /dashboard——网上抄链接打不开时先查装的是哪代；
  3. 低内存机器安装会爆：palette 里安装 Dashboard 2 会现场编译、内存尖峰很高（Pi Zero 级别有当场崩掉的真实案例）；兜底办法＝命令行装：cd ~/.node-red && npm install @flowfuse/node-red-dashboard 后重启。

安装：编辑器右上菜单 → Manage palette → Install → 搜 @flowfuse/node-red-dashboard → Install，等左侧节点栏多出一排 dashboard 系列。

二、动手 Demo：温湿度仪表板（先假数据后真数据）

第一步：用假数据把仪表板立起来。

  1. 拖 inject 进画布，payload 改成 JSON：{"temperature": 24.6, "humidity": 58}，重复间隔 every 30 seconds；
  2. 拖两个 function 节点，分别写一行取值： javascript msg.payload = msg.payload.temperature; // 另一个写 humidity return msg;
  3. 从 dashboard 分组拖一个 gauge 和一个 chart，照下面连：
inject ──┬─ function(温度) ── gauge(温度)
         └─ function(湿度) ── chart(湿度历史)
  1. 双击 gauge：group 里点铅笔新建一个分组（page/tab/group 是三层收纳），label 写 温度 °C，范围 -10 到 40；chart 的 label 写 湿度 %；
  2. Deploy，浏览器开 http://<树莓派IP>:1880/dashboard。

看到什么算成功：温度指针立在 24.6 附近；等两三个注入周期，湿度曲线开始爬点。手动点几次 inject 的方块，指针立刻动——13-2 的【不刷新就不动】问题就此终结。

第二步：换真数据。 把 inject 换成 http in 节点（方法 POST、地址 /dht）→ 后接一个 json 节点 → 接回两个 function；再从 gauge/chart 各拉一根线到 http response（回应 200，客户端上传才算完成）。Python 端改自 13-3 的脚本：

# demo13_5_feed.py —— 把 DHT22 读数喂给本地仪表板
import time, json, urllib.request
import board, adafruit_dht

dht = adafruit_dht.DHT22(board.D4, use_pulseio=False)
URL = "http://127.0.0.1:1880/dht"

while True:
    try:
        data = json.dumps({"temperature": dht.temperature,
                           "humidity": dht.humidity}).encode()
        req = urllib.request.Request(URL, data=data,
              headers={"Content-Type": "application/json"})
        urllib.request.urlopen(req, timeout=10)
    except RuntimeError as e:
        print("read retry:", e)
    time.sleep(30)

读结果：数据链是【DHT22 → Python（读）→ HTTP POST → Node-RED（收）→ 仪表板（画）】——Python 只干硬件活、Node-RED 只干展示活，正是 13-4 说的分工正路；上传打 127.0.0.1 表示数据不出本机，这就是【数据留在家里】。同一份读数想同时上 ThingSpeak？在 Python 里多调一次 13-3 的 upload 函数即可——采集一次，分发多处，IoT 应用的标准形态。

三、30 秒实验：亲手算一笔【点数与时间】的账

chart 默认保留最近若干个点。你的 inject 是每 30 秒一个点，把 chart 的 x 轴范围（last）设成 last 10 minutes。

看到什么算成功：曲线上同时最多约 20 个点（10 分钟 × 每分钟 2 点）。把注入间隔改 5 秒再观察——点密了曲线看着"活"，但 10 分钟攒下 120 个点。这个【频率 × 窗口 = 内存】的小账，就是 IoT 展示层最基本的容量规划；温度这类慢变量，30 秒一个点绰绰有余。

四、常见误区

  1. 装的是 Dashboard 1 却照 Dashboard 2 的教程配——两代节点名、配置页、访问地址全不同（/ui vs /dashboard）；先看 palette 里装的是哪个，再对号入座。
  2. gauge/chart 不显示数据先怪网络——九成原因在流没部署、function 没连线或 payload 取值路径写错；先回编辑器看 debug 面板有没有数据，再查前端。
  3. http in 后忘了接 http response——上传端会一直等到超时（13-5 脚本里 timeout=10 那里报错），而仪表板其实已经收到数据；【页面有数、脚本报错】就是这个原因。
  4. 把仪表板端口暴露公网——Node-RED 编辑器加锁了、仪表板也要想清楚：它显示的是你家数据、也能反向触发控制流；要远程看，走 VPN 或隧道，别裸开 1880。
自测三问（点开对答案） 1. Dashboard 1 和 2 的两个肉眼可辨区别是什么？——npm 包名（node-red-dashboard vs @flowfuse/node-red-dashboard）与访问地址（/ui vs /dashboard）。 2. 本节数据链上各环节的分工是什么？——Python＋gpiozero 读硬件，HTTP POST 交接，Node-RED 收数据并画仪表板；采集一次可同时分发本地仪表板与 ThingSpeak。 3. http in 后不接 http response 会发生什么？——数据其实已到仪表板，但上传客户端会一直等响应直到超时报错。
📄 第十三章读完了，回头看这条线

13-1 认地图（IoT 四层，旧知识各就各位）→ 13-2 点灯（Flask 把 GPIO 搬上浏览器）→ 13-3 上云（DHT22＋ThingSpeak，四条死库一条正路）→ 13-4 学积木（Node-RED 流式编程与安全开门）→ 13-5 收官（本地仪表板，数据留在家里）。 全课至此贯通一条完整的链：GPIO/相机/Pico 采集 → Python 处理（AI 加持）→ HTTP/MQTT 分发 → 云端曲线与本地仪表板双出口。 带着走的一句话：IoT 的每一段路都有一条【老教程的死路】和一条【当下的正路】——学的是判据（协议怎么选、库为什么死、状态真相在谁手里），跑的是当下。 下一章按教材顺序，等波仔报标题。

相关笔记