为什么选 ESP32 做入门硬件

ESP32 把 Wi-Fi、蓝牙、几十个 GPIO 和一颗足够快的双核芯片塞进几块钱的开发板，用 Arduino 框架或 ESP-IDF 都能开发。对物联网入门者来说，它是「一块板子就能跑通联网采集」的最低成本路径：不用外挂网络模块，烧录即用。

物联网的第一课不是协议，而是「让一块小小的板子，把传感器读数送到互联网上」。
最小系统组成
  • 主控ESP32 开发板，双核、自带 Wi-Fi。
  • 传感器一只温湿度模块（如 I2C 接口）即可起步。
  • 供电USB 调试，或电池 + 稳压模块。
  • 链路Wi-Fi 连路由器，经 MQTT/HTTPS 上报云端。
ESP32 实战配图：中央芯片轮廓散发出无线波纹，右侧连接温湿度传感小圆块
采集、联网、上报，是任何一块智能硬件的三段式主线。

最小硬件：传感器与接线

以一只温湿度传感器为例，它通常走 I2C 接口：一根 SDA、一根 SCL，加上电源与地。接线的第一原则是「共地」——传感器的地必须和 ESP32 的地连在一起，否则读数全是噪声。其次，电源电压要匹配，3.3V 的传感器接到 5V 引脚上可能直接损坏。

#include <Wire.h>
#define SDA_PIN 21
#define SCL_PIN 22

void setup() {
  Wire.begin(SDA_PIN, SCL_PIN);
  Serial.begin(115200);
}

上电后先用串口扫描仪确认传感器的 I2C 地址，再在代码里用这个地址发起读取。很多「读不到数据」的问题，根源都是地址不对或接线松动，而不是代码逻辑错了。

采集与本地滤波

传感器读数天然带有毛刺——温度可能在 25.0 和 25.8 之间乱跳。直接上报会让云端图表充满噪声。简单有效的做法是连续采样多次取平均值，或者用一阶低通滤波给读数加一个平滑系数。

float smooth = 0.0f;
float readSmooth() {
  float raw = readSensor();        // 原始读数
  smooth = smooth * 0.8f + raw * 0.2f;
  return smooth;                  // 越旧权重越高，曲线更平
}

滤波系数要按场景调：系数大更平滑但响应慢，系数小更灵敏但抖动多。环境监测这种慢变量场景，平滑一些没问题；快速变化的量就别过度平滑，否则会把真实变化也滤掉。

WiFi 联网与断线重连

Wi-Fi 连接不是一劳永逸的：路由器重启、信号遮挡、信道干扰都会让连接断开。代码里不能假设「连上一次就一直在线」，而要在主循环里检测连接状态，掉了就重连，并给每次重连加上退避延时，避免疯狂重连反而更不稳定。

void ensureWifi() {
  if (WiFi.status() == WL_CONNECTED) return;
  Serial.print("reconnect");
  WiFi.begin(SSID, PASS);
  int tries = 0;
  while (WiFi.status() != WL_CONNECTED && tries < 20) {
    delay(500);
    tries++;
  }
}

实际项目里还应记录「本次已离线多久」，超过阈值就在本地缓存数据，等网络恢复后再补传，而不是直接丢弃读数——对无人值守的设备，数据连续性比实时性更重要。

数据上报与格式约定

设备端上报的报文格式要提前和云端约定好。一份最小报文通常包含设备编号、时间戳和若干指标字段。用 JSON 结构清晰，但报文较大；对带宽敏感的场景也可以用紧凑的二进制或键值串。下面以 JSON 经 HTTPS 上报为例。

String buildPayload(String devId, float t, float h) {
  return String("{\"dev\":\"") + devId +
         "\",\"t\":" + String(t, 1) +
         ",\"h\":" + String(h, 1) + "}";
}
// 上报：HTTPS POST 到网关接口，由网关转发到平台
上报约定要点
  • 设备号每块板子有唯一标识，云端据此识别。
  • 时间戳优先用云端校时后的网络时间，而非板子本地时钟。
  • 单位温度、湿度的单位在报文里写清，避免歧义。
  • 频率按指标变化快慢定上报间隔，不要盲目高频。