豆子ESP网关 on 豆子技术站

一步一步将ESP8266 WIFI 配网搞定并丝滑体验

Wed, 29 Apr 2026 22:22:34 +0000

准备入手ESP网关项目了，手头有一块esp8266的开发小板子，就先从esp8266开始入手。白天搞定了ESP8266 的UDP配网编码和小程序端的控制编码。就一个功能模块给ESP8266配置WIFI网络。这是必须的入门操作，因为WIFI 的SSID和密码不能真的写入到代码中。

网络配置有很多种方式，我选择了SoftAP配网，虽然配置有点繁琐，但这是一种很可靠的配网方案，兼容性极高，不依赖手机硬件的特殊协议。以前做过HTTP配网，这是2025年时做的，到现在已经忘的差不多了。现在捡起来再回忆一下。

准确来说，这不应该算是一个项目，但因为它具有通用性和实用性。我决定把它记录下来，可以方便地应用到我的其它项目中。

Soft配网原理

初始化模式：ESP8266 启动后进入 WIFI_AP_STA 模式。它会开启一个无密码（或已知密码）的热点（AP），并运行一个轻量级的 Web 服务器（HTTP Server）。
通道建立：手机通过小程序或系统设置连接到该热点。此时手机与 ESP8266 处于同一个局域网内。
数据交互：小程序通过 HTTP Post 请求将目标 WiFi 的 SSID 和 Password 发送给 ESP8266 的固定接口（如 /config）。
校验与切换：ESP8266 收到参数后，尝试作为客户端（STA）连接路由器。如果连接成功，则关闭 AP 热点，保存参数到 Flash；如果失败，则返回并重置到AP状态。

ESP8266端核心代码（Arduino IDE）和小程序端代码

在Arduino IDE打开项目后，需要安装ESP8266 WebServer库。这个库提供了Web服务，可以接收其它HTTP客户端的连接。

它的核心是实现了一个非常简单的Web服务，它监听/config接口并能够接收WIFI信息，以及接收之后可以本地存储，实现动态配置的功能。

下面是Arduino端的代码片段：

#include <ESP8266WiFi.h>
#include <ESP8266WebServer.h>
// 定义AP热点的名称
const char* ap_ssid = "ESP8266_Config_Device";
ESP8266WebServer server(80);
void handleConfig() {
// 处理SSID和密码逻辑
}
void setup() {
// 设置为AP+STA模式
WiFi.mode(WIFI_AP_STA);
WiFi.softAP(ap_ssid);
// 注册接口
server.on("/config", HTTP_POST, handleConfig);
server.begin();
}
void loop() {
server.handleClient();
if (WiFi.status() == WL_CONNECTED) {
// 如果连接成功，可以根据需要在这里处理业务逻辑
}
}

完整代码可以从https://91demo.top/tools/下载。小程序端则充当了HTTP客户端，它用来作为输入WIFI信息的终端。这个界面非常简单，一个WiFi信息提交表单，包含了SSID信息和密码信息，以及一个提交按钮。

在51单片机实现 Modbus RTU 协议过程中的踩坑和思考

Wed, 18 Mar 2026 08:05:33 +0000

在上篇原理文章介绍后，我开始实现代码，硬件使用现成的51开发板。原本以为只是简单的串口收发，结果却在 Modbus Poll 软件中疯狂循环 Checksum Error 和 Timeout。

下面是我在普中科技 51 开发板上，使用STC89C52芯片接入工业标准的 Modbus RTU 协议，从最基础的串口打印到实现动态温度采集，并成功通过 Modbus 协议回传的完整过程。

环境准备

硬件：普中 51-A2 开发板 (STC89C52RC)、DS18B20 温度传感器、USB 转串口线。
软件： Keil uVision5、STC-ISP、Modbus Poll (主机仿真器)、SSCOM 串口调试助手。

核心挑战：为什么 Modbus Poll 总是报 Checksum Error？

这是我耗时最长的地方，也是我头疼的地方。如果你也遇到数据看着对但校验不过，请检查以下三点：

查表法的陷阱

因为51单片机的性能问题，我使用了查表法，CRC表中的数据是采摘网上教程的。在解决了之后，发现是自己设置的表中的数值不对。要知道Modbus 的 CRC16 校验非常严苛。为了方便以后的开发者，我把正确的CRC表和获取函数都贴出来。

// 高位表
unsigned char code aucCRCHi[] = {
 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40
};
// 低位表
unsigned char code aucCRCLo[] = {
 0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06, 0x07, 0xC7, 0x05, 0xC5, 0xC4, 0x04,
 0xCC, 0x0C, 0x0D, 0xCD, 0x0F, 0xCF, 0xCE, 0x0E, 0x0A, 0xCA, 0xCB, 0x0B, 0xC9, 0x09, 0x08, 0xC8,
 0xD8, 0x18, 0x19, 0xD9, 0x1B, 0xDB, 0xDA, 0x1A, 0x1E, 0xDE, 0xDF, 0x1F, 0xDD, 0x1D, 0x1C, 0xDC,
 0x14, 0xD4, 0xD5, 0x15, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3, 0x11, 0xD1, 0xD0, 0x10,
 0xF0, 0x30, 0x31, 0xF1, 0x33, 0xF3, 0xF2, 0x32, 0x36, 0xF6, 0xF7, 0x37, 0xF5, 0x35, 0x34, 0xF4,
 0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFA, 0x3A, 0x3B, 0xFB, 0x39, 0xF9, 0xF8, 0x38,
 0x28, 0xE8, 0xE9, 0x29, 0xEB, 0x2B, 0x2A, 0xEA, 0xEE, 0x2E, 0x2F, 0xEF, 0x2D, 0xED, 0xEC, 0x2C,
 0xE4, 0x24, 0x25, 0xE5, 0x27, 0xE7, 0xE6, 0x26, 0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0xE0,
 0xA0, 0x60, 0x61, 0xA1, 0x63, 0xA3, 0xA2, 0x62, 0x66, 0xA6, 0xA7, 0x67, 0xA5, 0x65, 0x64, 0xA4,
 0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F, 0x6E, 0xAE, 0xAA, 0x6A, 0x6B, 0xAB, 0x69, 0xA9, 0xA8, 0x68,
 0x78, 0xB8, 0xB9, 0x79, 0xBB, 0x7B, 0x7A, 0xBA, 0xBE, 0x7E, 0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C,
 0xB4, 0x74, 0x75, 0xB5, 0x77, 0xB7, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71, 0x70, 0xB0,
 0x50, 0x90, 0x91, 0x51, 0x93, 0x53, 0x52, 0x92, 0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54,
 0x9C, 0x5C, 0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x9B, 0x5B, 0x99, 0x59, 0x58, 0x98,
 0x88, 0x48, 0x49, 0x89, 0x4B, 0x8B, 0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C,
 0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42, 0x43, 0x83, 0x41, 0x81, 0x80, 0x40
};
// 获取CRC
unsigned int GetCRC16(unsigned char *pData, unsigned char len) {
 unsigned char uIndex;
 unsigned char crch = 0xFF;
 unsigned char crcl = 0xFF;

 while (len--) {
 uIndex = crcl ^ *pData++;
 crcl = crch ^ aucCRCHi[uIndex];
 crch = aucCRCLo[uIndex];
 }
 return (unsigned int)(crch << 8 | crcl);
}

字节序与 Quantity 的对齐

这里也是一个坑，自己概念不清，在设置quantity时设置错误，错把他们1比1进行换算。还有Modbus 规定低字节在前，高字节在后。

自制可使用 Modbus 采集的 RS485 温度传感器（原理验证版）

Fri, 06 Mar 2026 20:05:33 +0000

我将使用经典的 STC89C12 单片机作为核心，配合 DS18B20 数字温度传感器和 MAX485 通信芯片，构建一个支持标准 Modbus-RTU 协议的感知节点。

一、核心架构：传感器、大脑与传声筒

这个小模块的本质是一个“翻译官”。它把环境中的物理温度转化为数字信号，再按照工业标准协议通过长线传输给上位机（如 PLC 或电脑）。

感知单元 (DS18B20)：不同于传统的模拟热敏电阻，它是数字传感器，直接输出 12 位精度的二进制温度数据。
处理中心 (STC89C12)：负责按照时序“读”传感器，并把数据存入内存，同时监听串口指令。
通信接口 (MAX485)：单片机的 TTL 信号传不远，MAX485 将其转换为差分信号，实现抗干扰的长距离传输。

二、硬件链路设计

为了简化电路并验证可行性，我们将引脚定义如下：

DS18B20 接口：连接至 P1.0。由于 1-Wire 总线需要上拉电阻，我们在硬件上需确保 P1.0 与 VCC 之间有一个 4.7kΩ 的电阻，以维持空闲时的高电平。
MAX485 控制：
- UART 接口： RXD(P3.0) 接 RO，TXD(P3.1) 接 DI。
- 收发切换 (RE/DE)：连接至 P3.2。RS485 是半双工的，平时 P3.2 置低电平处于“听”模式；当需要回传数据时，将其置高切换为“说”模式。
烧录接口：仅预留 VCC、GND、TXD、RXD 四线接口，用于程序的迭代验证。

三、技术实现思路

A. 如何采集 DS18B20？

STC89C12 通过单总线 (1-Wire) 时序与传感器对话。由于 STC89C12 速度较慢且不支持硬件单总线，我们需要通过精准的软件延时来模拟时序：

从“半夜巡栏”到“智能换气”：我把黑盒搬进了猪舍

Fri, 27 Feb 2026 18:00:00 +0800

一、那件披在身上的大衣

老家人养猪，冬天的半夜，都要披上厚重的大衣，去猪舍看产床温度。猪舍的墙上挂了一个水银温度计。温度低了猪仔会冻死，温度高了会脱水。氨气重了会生病，感觉味道重了，需要手动打开抽风机。这种“靠人巡、靠鼻闻、靠经验”的原始模式，不仅累，而且风险极高。

供暖烧煤炉，煤炉需要半夜起来加煤，人困得不行；母猪还得使用电热板，电热板是那种电阻丝加热的，没有温控计，只能隔几个小时去关掉，等温度降下去再打开。说到底，还是得靠人去“看着”。

我想，能不能用技术，把家人从这种重复、枯燥且充满风险的体力劳动中解放出来一点点？不用花太多钱，因为他们会心疼。

二、攻坚方案：黑盒的温控逻辑

可以看到面临的主要是“环境失控风险”。

温度控制的极端性：依靠烧煤和简易电热板，温度分布不均。半夜人工起夜不仅辛苦，且这种“大跨度”的温差变化会导致猪仔腹泻甚至死亡。
空气质量的隐形威胁：氨气超标是诱发呼吸道疾病的主因。仅靠“鼻闻”时，空气质量往往已经恶化到危及健康的程度。
利润被风险蚕食：养猪大头是料钱和药钱，但成活率才是利润的底线。一次深夜的失误，可能让数月的辛苦付诸东流。

能马上想到的临时解决方案：

恒温自动化（解决“半夜加煤”与“手动插拔”）
温控传感器方案：购买带有探头的温控开关，将电热板连接到温控插座上。
效果：设定好区间（如32-35度），温度低了自动通电，够了自动断电。不仅省去了人工看管，还能通过减少无效耗电抵消设备成本。
环境预警系统（解决“鼻闻”与“风险”）
智能监控终端：安装一个集成了温湿度监控与氨气检测的智能传感器，通过 Wi-Fi 或 4G 信号连接手机。
效果：当温度异常或氨气浓度过高时，手机会自动发出警报铃声提醒，避免了老人家整晚不敢闭眼的焦虑。
联动抽风（解决“呼吸道疾病”）
自动排风系统：将原有的抽风机改装为智能联动。
效果：当氨气传感器感应到超标，自动开启抽风机，达标后关闭。这能精准减少热量流失，同时保证猪舍空气清新。

核心硬件选择：务实与成本的平衡

因为猪舍现场环境非常恶劣，湿度，氨气，粉尘等因素，温控开关坏的频率非常高，如果接到料房，又采集不了温度。购买氨气专业设备成本又非常高。现场可以根据温度和通风进行解决，但在冬季，保暖是另一个问题。实际考量后，还是自己动手做比较划算。零部件能够直接买并满足现场需求的，直接购买，满足不了，自己动手制作，需要防腐蚀处理：焊接完成后，用酒精清洗焊渣，然后必须喷涂“三防漆”。外壳选用 IP65 防水接线盒，进线口使用电缆防水密封接头 (PG7)，否则氨气会从缝隙钻进去。线路外层加PVC管，防鼠咬，腐蚀，机械损伤。

传感器：水银温度计不行，无法采集。工业级的 RS485 温湿度传感器太贵（动辄上百元），购买不锈钢封装好的民用级的DS18B20数字温度传感器，焊接后要密封好，挂在猪舍合适的位置。它通过一根单总线连接，协议简单，成本极低。
主控：具备 NB-IoT 通信功能的物联网核心板或者采用分布式架构，先接一个STM32控制黑盒，然后再连接物联网黑盒，它集成了主控芯片和 NB-IoT 模块，可以直接连接运营商网络。它负责读取传感器、执行逻辑、控制输出，并具备联网能力。
通信：猪舍没有Wi-Fi，即使有WiFi，也推荐使用RS485线连接，考虑如下：稳定性以及长期收益。布线不方便的地方，可以使用4G或者NBIot模块，用一张物联网卡，可以直接走运营商的网络上传数据，无需在猪舍和住房之间拉网线，年流量费仅需十几元。这是实现“无线化”的关键，需要注意的是，如果在猪舍内加装铁盒，需要接外接天线，防止信号屏蔽。
报警：前期控制投入，不用手机流量卡和云平台。购买一个433MHz无线门铃，使用黑盒驱动，黑盒使用IP65 防水塑料接线盒，把发射模块接在主控板上。当需要报警时，主控板模拟按下门铃按钮，屋里就会“叮咚”响。这是最直接、最可靠的本地告警。

第一阶段：从“定时巡”到“听铃响”

目标：解决“夜间需要频繁固定间隔的去猪舍”的核心痛点，将人工巡检间隔时间拉长到“只在有异常时响应”。

系统架构与原理：

感知：主控板不断读取 DS18B20 的温度值。
决策：我在主控板的固件里写死一段简单的判断逻辑（例如：if (温度 < 18度或温度 > 28度)）。
执行：一旦条件满足，主控板立即驱动 GPIO 引脚，向 433MHz 发射模块发送一个高电平脉冲信号。
告警：433MHz 信号被屋里的门铃接收器捕获，触发响铃。屋里的人听到铃声，就知道猪舍温度异常，需要去查看。

可执行性与落地关键：

硬件连接：仅需将 DS18B20 的数据脚、电源、地线接到主控板对应引脚；将 433MHz 发射模块的信号脚接到另一个 GPIO 引脚。接线简单，无需复杂电路。

水表、电表、热表：一个“黑盒”如何撬动千亿级存量市场中的利旧改造细分蓝海

Thu, 26 Feb 2026 18:00:00 +0800

一、场景：从“插卡洗澡”到“手机充值”的断层

“洗澡洗一半，卡里没钱了，得湿着身子跑下楼去圈存机充钱。”——这是十年前大学宿舍的常态。

我参与过那个“刷卡时代”的项目。彼时，每个宿舍楼都有一个弱电井，里面几十个水表通过RS-485总线串联。学生用M1卡洗澡，钱存在卡里，水表是“单机版”。宿管中心不知道哪个宿舍快没水了，只能被动等待报修。

核心痛点：用户需要手机充值的便捷，但海量的老式水表（及电表、热表）是“数字孤岛”，只有RS-485接口，不具备任何联网能力。整体更换为物联网表成本极高，且施工影响巨大。

二、方案：一个“黑盒”，唤醒沉默的数据

我们的方案是添加一个 “黑盒”——一个协议转换网关。它的逻辑很简单：不换表，不改线，只做“翻译官”。

物理部署：在弱电井的485总线汇接处，并联接入“黑盒”。原有的刷卡系统完全保留，作为保底。

核心工作：

采集：黑盒内置高性能Modbus协议栈，主动轮询总线上所有水表，读取余额、用量。
转换：将不同品牌、不同协议的水表数据，统一“翻译”成标准的JSON格式。
上传：通过4G或网线，将数据通过MQTT协议上传至云平台。

手机充值闭环：

学生在小程序支付。
云端将“为XX房号充值XX元”的指令下发给对应黑盒。
关键一步：黑盒将指令“反向翻译”成目标水表能识别的、符合其私有协议的485报文，完成“写卡”操作。
系统确认后，充值到账。

三、定位：在巨头缝隙中，做“数字化的梯子”

我深知，国家级、城市级的智慧水务/能源项目，是头部玩家的“铁桶阵”，他们依靠专用网络、5G和强大的工程能力构建壁垒。

“黑盒”的目标，是那片被忽略的“长尾市场”：

还未改造的高校宿舍、企业公寓、公租房保留的水表。
城中村的个体房东，管理几栋到十几栋楼房。
中小工厂的宿舍楼。

对他们而言，动辄数十万的整体改造方案是不可承受之重。而一个单价数百元、即插即用、半天可部署、不动原有设施的“黑盒”，是他们迈入数字化管理的唯一可行阶梯。

四、挑战与壁垒：并非“即插即用”的童话

这个方案在逻辑上自洽，但真实的商业落地远非易事，存在多重壁垒：

工程实施壁垒：“不换表”不等于“零施工”。将黑盒接入弱电井，需要开井、找线、破接、取电、固定，这本身就有一定的技术门槛和安全风险，并非普通用户能独立完成。
协议适配壁垒：水、电、热表协议各异，且大量是厂家私有加密协议。适配、测试每个新协议，都意味着高昂的研发和现场调试成本。这绝非一个“通用字典”就能轻松解决。
性能与稳定性壁垒：RS-485总线是半双工，挂载几十块表后，轮询周期会拉长，数据实时性下降。网络波动、设备干扰可能导致指令执行失败，需要设计复杂的重试、容错和事务一致性机制。
渠道与商务壁垒：如何触达并说服高校后勤、房东这些分散的客户？如何提供及时可靠的现场支持？这比技术开发更难。

五、思考：技术应俯身解决真问题

从弱电井里满是灰尘的RS-485总线，到云端的MQTT消息；从易丢失的实体卡，到手机里的数字账户。

“黑盒”的价值，不在于它用了多炫的技术，而在于它用极低的成本，为一个真实、广泛但被忽视的需求，提供了一个可行的解决方案。

它像一根“数字化的梯子”，让那些无力承担“电梯”费用的用户，也能攀上智能管理的台阶。

这背后，是对现场通信“脾气”（干扰、雷击、协议冲突）的深刻理解，更是对用户“简单、可靠、别添乱”这一终极诉求的敬畏。

当巨头们仰望星空，构建未来时，总需要一些人，愿意为角落里那些“老旧笨重”的设备，插上一双通往现代的翅膀。

这条路充满挑战，但正因如此，每一步才都踏在真实的需求之上。

后记与邀请

如果你正在寻找低成本的老旧设备数字化方案，欢迎交流。关于“黑盒”项目的固件核心进展、协议文档与配置字典，我将在爱发电https://afdian.com/a/modujson 持续同步与更新。

从粮仓 RS485 总线到云端 JSON：一个前实施工程师的数字化反思

Wed, 25 Feb 2026 18:00:00 +0800

“以前看粮仓，那是体力活，现在看粮仓，是技术活。”——一位在粮库工作三十年的老保管员

一、那些年，我在粮库“插钎子”

“我年轻时，最怕夏天查粮仓。”老保管员回忆道。三伏天，他得扛着十几斤重、6米长的铁杆，踩着晃晃悠悠的木板，深一脚浅一脚地爬上几米高的粮堆。杆子前端是温度传感器，杆子末端则是一个巴掌大的小型LED显示屏。每到一个检测点，他就得用力把这“铁签子”插进压得结实的粮堆底部，然后低头查看杆子末端的屏幕读数，再抄录到本子上。全部查完、记录完，要爬一整天。粉尘呛人、闷热缺氧，是家常便饭。

“那时靠的是腿，是眼，是经验。”老保管员说得对。他练就了“一看、二闻、三摸”的本事，但这套经验在几千吨的粮堆面前，总有盲区。一旦某个角落的粮食开始发热霉变，等人工发现时，往往损失已不可避免。

这不是故事，这是我的朋友——一位粮库测温系统的实施工程师——告诉我的：

他入行时，老保管员的手艺活已是过去式。他面对的是更“现代”的麻烦：部署一套有线测温系统。

这套系统的核心，是把带有固定传感器的“测温电缆”像神经一样埋入粮堆，取代人工巡检。而他的工作，就是把这套“神经”铺进去，再把“信号”引出来。

这活儿，一点不比爬粮堆轻松。

夏天，粮仓内像个蒸笼，地面温度超过40度。他要在入粮前，或趁着粮堆还不高时，拖着几十米长、拇指粗的测温电缆在仓内布线。电缆里包裹着钢丝，死沉。他得把它沿着预定路径铺好、固定，确保每个传感器都在设计位置。

这仅仅是开始。真正的考验是“拉线”。

粮堆深处的测温电缆，其线头最终要汇集到挂在仓库墙壁或柱子上的“测温分机”（采集器）。他需要扛着梯子，在满是灰尘的仓房里，将几十根从粮堆里引出的线，一根根对号入座，拧到分机箱内的接线端子上。接错一根，整个回路的数据都可能乱掉。

这还没完。仓库里几十台这样的分机，还需要用更粗的“通信总线”（RS-485线）手拉手串联起来，最后拉到机房，接入一台专用电脑。

这，才是他口中“从杆子末端拉出数据线，连接到远处的分线器上”的真实图景：那不是在粮堆上现插现拉的潇洒，而是在高温、高粉尘环境下，重复千百次的枯燥、负重且必须精准的体力与细心活。线要拉得横平竖直，接头要拧得牢靠，还要防鼠咬、防磨损。

刚开始，他觉得这工作充满了技术仪式感。干久了，日复一日地扛电缆、爬高、接线、测通断，只剩下一个字的感受：累。一种被庞杂的物理线缆和复杂现场环境反复折磨的、沉甸甸的疲惫。

然而，正是这种疲惫，让他对“可靠”二字有了刻骨的理解。他见识过雷雨天后烧毁一片的电路板，处理过因一个接头松动导致整仓数据瘫痪的故障，也深知那台机房里孤零零的电脑，就是整个系统最脆弱的“大脑”。

二、技术跃迁：从“有线”到“无线”

我朋友后来参与实施的，正是那套用来取代人工的有线测温系统。它的核心是用预埋测温电缆取代了人工铁钎——技术人员在粮堆中预埋专用电缆，每根电缆上集成数十个温度传感器，像“神经末梢”一样分布。数据通过RS-485总线手拉手串联，即设备像糖葫芦一样串在一条总线上，一个接一个。最终汇总到仓外的监控主机。

除了传统的平房仓，现代化的粮库越来越多地采用立筒仓（圆仓）。这种仓体高大，粮食像瀑布一样从顶部灌入，依靠底部的锥形漏斗和出粮机实现自动化出粮。

在这里，测温电缆不再是“蛇形”铺在底部，而是像垂直的琴弦一样，从仓顶的采集器一直垂到仓底。采集器不再藏在灰尘满布的机房，而是直接安装在仓顶的防雨箱里，通过无线模块将数据发送到云端。

这种结构，让粮仓从“体力活”彻底变成了“自动化工厂”。

再回到我朋友的测温系统，这解决了人工爬仓的问题，但带来了新的、更复杂的麻烦。

当时觉得这套系统很先进，但现在回想，它太“重”了：

怕雷击：几百米纵横交错的485总线，成了感应雷的“引雷针”，雷雨季后，分线器经常烧坏一片。
维护难：专用的监控电脑不能死机，SQL数据库一旦损坏，几年的历史温度数据可能全丢。
数据孤岛：粮库主任想看一眼温度，必须跑到那个满是灰尘的专用监控室。
工程浩大：布线、穿管、调试，一个仓的改造就需要数周，成本高昂。

真正的变革，发生在物联网和无线通信普及之后。

新一代的“黑盒”采集器出现了。它只有巴掌大小，却集成了主控、4G模块和无线传输功能。它直接读取测温电缆的数据，通过MQTT协议将数据打包成JSON格式，一跳直达云平台。

粮库管理员在办公室，甚至用手机，就能看到整个粮堆的立体温度云图。系统自动分析、自动报警。

免布线：每个仓门口挂一个4G黑盒，直接对接原有的分线器。省掉了跨仓位、跨建筑的数千米复杂布线工程。
云端大脑：不再需要机房那台脆弱的专用电脑，数据直接上云，永不丢失，随时随地可查。

三、黑盒的定位：避开红海，寻找蓝海

在深入了解行业后，我发现粮储智能化其实是一个典型的“双轨制市场”。

大公司的“铁桶阵”：资质与工程的护城河

国家级粮储库、大型央企的智能化改造，是标准的“重工程”市场。它被几家头部企业垄断，依靠的是强大的工程化资质（如机电安装、系统集成）和专用设备（如光纤测温、工业级5G网关）。这些方案性能极高，但成本也极其昂贵（单仓改造费用动辄数十万），且施工周期长，需要专业工程队进场。

我的“黑盒”逻辑：低成本与快速响应

我开发的这个黑盒项目（基于ESP32等开源硬件），从一开始就没打算去冲击那个“铁桶阵”。我清醒地认识到，在需要军工级可靠性的战略储备库，我的方案无法与那些天价的专用设备竞争。

黑盒的核心价值在于“降维打击”与“普惠”：

目标市场：中小型粮库、地方储备点、合作社、个体储粮户。这些场景对成本极度敏感，无法承担大型工程的费用，也无需那么严苛的可靠性。

核心优势：极致低成本（硬件成本可能只有大公司方案的百分之一）和极速部署（即插即用，一个人半小时就能装好一个仓）。

价值主张：用“够用”的可靠性，解决“有没有”的问题。对于绝大多数只需要基本温湿度监控、异常报警功能的用户，黑盒是让他们迈入数字化门槛的唯一可行选择。

结语：让技术回归解决问题的本质

技术不应只是大公司的专利和豪华包装下的奢侈品。我的黑盒项目，源于“插钎子”的汗水，目标是证明一件事：在那些大公司不愿弯腰、传统方案贵得用不起的“边缘地带”，廉价的芯片和开源的智慧，同样能默默守护好每一粒粮食。

这不仅是技术实现，更是一种让技术回归普惠、解决真问题的尝试。

四、我的“黑盒”：从痛点里长出来的解决方案

“虽然已离开粮储行业多年，但那些亲自插下的钎子，让我深刻理解了RS485总线的‘脾气’、雷击的刁钻、还有现场对‘简单可靠’的极致渴望。”——这种浸入式的场景理解，是我开发这款“黑盒”固件最硬的底气。

它不是一个实验室里的玩具，而是为了解决 “老旧工业设备低成本上云” 这个具体痛点而生的 “数字化插件” 。它目前是一个稳定的Modbus/RS485转MQTT网关固件，未来可以扩展为支持多种协议、具备边缘计算能力的核心。

未来黑盒可以集成LoRa，LoRa 最大的优势在于极强的穿透能力和超长的传输距离，非常适合“密闭、大跨度”的粮仓环境。在粮仓这种密闭、充满金属设备和粮堆的环境下，LoRa 依然表现出色。相比于 4G/NB-IoT 在密闭环境信号较弱的特点，LoRa 的信号能够穿透厚厚的墙体，深入到粮堆内部。配合无线测温探杆，使用电池以及太阳能电池板，彻底免布线。

关于合作：

我个人专注于核心固件的研发、算法优化与开源社区建设。硬件生产与制造，我与专业的工业设计伙伴合作，以确保设备的出厂品质。我相信，专业的人做专业的事，才能把产品做到最好。

最终结语

从“汗滴禾下土”的插钎巡检，到“数据云中走”的智能值守，变的不仅仅是工具，更是守护粮食安全的思维与模式。

我朋友的故事，可能只是大时代里一个很小的注脚。但如果这个源于亲身痛苦、成于开源技术的“黑盒”项目，能帮助到某个正在为粮仓温控发愁的中小业主，或者给某个在工业物联网领域摸索的开发者一点启发，那么，那些年在粮堆上流过的汗，就算有了超越它本身的价值。

技术，理应如此踏实而有温度。

后记与邀请

如果你也有过类似的工业现场“血泪史”，或正在寻找低成本的老旧设备数字化方案，欢迎交流。关于“黑盒”项目的固件核心进展、协议文档与配置字典，我将在爱发电https://afdian.com/a/modujson 持续同步与更新。

Modbus转MQTT网关固件研发与共创计划

Tue, 24 Feb 2026 18:00:00 +0800

一、项目愿景：让设备上云，像接线一样简单

新的一年，新的计划，我们致力于为工程师、创客及小团队，打造一套开箱即用、稳定可靠的工业物联网数据采集方案。你无需深究复杂的协议栈，只需聚焦业务，即可让传统设备轻松上云。

本项目的核心价值在于：

协议翻译官：打造一个高性能的“中间件”，将底层的Modbus协议（支持RS485/TTL）无缝转换为上层的MQTT协议，打通设备与云端的“最后一公里”。
软硬解耦：不绑定特定硬件。无论是WiFi环境（ESP32）还是4G环境（Cat.1模组），只要具备基本通信能力，软件就能赋予其“智能”，提供极大的硬件选型自由度。
解决技术断层：解决有业务需求但没有研发实力的小团队（如硬件工程师、创客、小厂），本项目提供了一种低成本解决方案。它只需通用开发板，就能实现数据采集和上云，花小钱办大事。

二、技术架构：三位一体的全栈实现

为确保方案的极致稳定与高度可扩展，我们采用“固件 + 配置工具 + 演示端”的三位一体架构，确保方案的完整性与专业性。

核心固件（“翻译官” - 逻辑版）

固件架构：采用分层架构设计，硬件抽象层隔离具体芯片与通信接口（如RS485/TTL），实现核心逻辑与硬件的解耦；协议栈层实现完整的Modbus协议栈（主/从站，RTU/TCP），并进行高效、健壮的JSON封装；服务层内置MQTT客户端，负责可靠的数据上传、断线重连与本地缓存；配置管理层，通过Rust编写的PC工具下发设备配置，实现软件定义功能。

技术栈：采用C语言开发，优先实现裸机（No OS）逻辑版本，确保在资源受限的MCU上也能稳定运行，降低用户使用门槛。

功能：负责实时采集Modbus寄存器数据（如电压、电流），并根据配置的倍率进行数据转换，最后通过MQTT协议将数据打包上传。

PC配置工具（“指挥官” - Rust版）

技术栈：使用Rust语言开发，利用其内存安全特性，确保配置过程绝对可靠，工具长期运行不崩溃。

功能：提供图形化界面，用户可轻松配置通信模式、寄存器地址、倍率等参数。支持通过串口（USB转TTL）进行固件刷新与参数下发，解决现场实施难题，无需复杂的网络配置。

数据演示端（“仪表盘”）

技术栈：微信小程序。

功能：扫码即可查看实时数据曲线与数值面板，直观验证数据上云效果，方便现场调试与演示。

三、当前状态：诚邀你，成为“共创者”

项目正处于核心研发阶段，当前全力攻克裸机版本，实现通信方式支持WiFi和4G的Modbus RTU（串口）协议的稳定性与性能。它适合简单应用，保证运行稳定。我们相信，最好的产品源于真实场景的千锤百炼。

未来会研发通信方式支持LoRa、以太网的Modbus TCP，以及FreeRTOS多任务版，用于解决需要同时处理多路数据采集，复杂业务逻辑的高端场景。

因此，我们发起此次共创计划：

你的支持，将直接转化为测试硬件（ESP32、各类Modbus传感器），用于极限环境下的兼容性验证。
你的设备，可以寄来成为我们的“适配样本”，共同完善设备库。
你的反馈，将直接塑造产品的下一个版本。

四、未来承诺

当固件通过大量真实场景验证，达到工业级稳定标准后，我们将正式申请软著，并启动授权售卖。所有共创阶段的支持者，都将依据历史贡献，获得丰厚的升级折扣与永久优先支持权。

我入驻了爱发电，更多详情内容请查看：https://afdian.com/a/modujson

豆子ESP网关 on 豆子技术站

一步一步将ESP8266 WIFI 配网搞定并丝滑体验

Soft配网原理

ESP8266端核心代码（Arduino IDE）和小程序端代码

在51单片机实现 Modbus RTU 协议过程中的踩坑和思考

环境准备

核心挑战：为什么 Modbus Poll 总是报 Checksum Error？

查表法的陷阱

字节序与 Quantity 的对齐

自制可使用 Modbus 采集的 RS485 温度传感器（原理验证版）

一、核心架构：传感器、大脑与传声筒

二、硬件链路设计

三、技术实现思路

A. 如何采集 DS18B20？

从“半夜巡栏”到“智能换气”：我把黑盒搬进了猪舍

一、 那件披在身上的大衣

二、 攻坚方案：黑盒的温控逻辑

核心硬件选择：务实与成本的平衡

第一阶段：从“定时巡”到“听铃响”

系统架构与原理：

可执行性与落地关键：

水表、电表、热表：一个“黑盒”如何撬动千亿级存量市场中的利旧改造细分蓝海

一、 场景：从“插卡洗澡”到“手机充值”的断层

二、 方案：一个“黑盒”，唤醒沉默的数据

核心工作：

手机充值闭环：

三、 定位：在巨头缝隙中，做“数字化的梯子”

四、 挑战与壁垒：并非“即插即用”的童话

五、 思考：技术应俯身解决真问题

后记与邀请

从粮仓 RS485 总线到云端 JSON：一个前实施工程师的数字化反思

一、那些年，我在粮库“插钎子”

二、技术跃迁：从“有线”到“无线”

三、黑盒的定位：避开红海，寻找蓝海

四、我的“黑盒”：从痛点里长出来的解决方案

关于合作：

最终结语

后记与邀请

Modbus转MQTT网关固件研发与共创计划

一、 项目愿景：让设备上云，像接线一样简单

二、 技术架构：三位一体的全栈实现

三、 当前状态：诚邀你，成为“共创者”

四、未来承诺

一、那件披在身上的大衣

二、攻坚方案：黑盒的温控逻辑

一、场景：从“插卡洗澡”到“手机充值”的断层

二、方案：一个“黑盒”，唤醒沉默的数据

三、定位：在巨头缝隙中，做“数字化的梯子”

四、挑战与壁垒：并非“即插即用”的童话

五、思考：技术应俯身解决真问题

一、项目愿景：让设备上云，像接线一样简单

二、技术架构：三位一体的全栈实现

三、当前状态：诚邀你，成为“共创者”