做HVAC和嵌入式温度监测这块，前期做得最多的并不是把传感器往板子上一焊、读个数那么简单——真正要命的是“本地”怎么跟“远程”拉开距离，以及现场布线、供电、协议、掉线这些破事怎么系统性收口。PJ85718DM 配上 PIC18F86J15，算是比较顺手的一套组合：前者是单总线高精度数字温度传感器，不用调零、不用做冷端补偿，天生就适合多节点挂接；后者是 PIC18F 系列里外设相对齐全的一颗片子，GPIO 做时序、UART 转 RS-485、定时器做节拍都够用。这篇就把这个项目从器件选型、电路计算、软件驱动到 HVAC 现场部署的完整路径拆开说清楚，适合正在做温控器、风机盘管控制器、冷链监测或者楼宇自控的嵌入式开发者参考。
1. 为什么是"本地+远程"双轨监测
1.1 本地与远程的边界到底划在哪
很多刚接触这个项目的人会把“本地温度”和“远程温度”理解成交替测量的两个过程，觉得无非就是多读几个数。实际工程里不是这样，本地和远程的划分核心是物理拓扑与实时性要求的差异。
本地温度指的是控制器所在柜体、箱体或同一个机组内部，传感器到 MCU 的距离通常在 2 米以内，走线简单、干扰可控，读取频率可以拉很高，甚至每 100ms 刷一次都无所谓。远程温度则是分布在几个区域甚至几个楼层、几十米线缆之外的传感器节点，它们要经受现场强电干扰、端子氧化、线缆压降和潮湿环境的多重考验，读取频率通常降到 1~2 秒一次，每个节点的故障还要能单独识别和隔离。
PJ85718DM 这类器件支持一根信号线上挂接几十个节点，每个节点有唯一的 64 位 ID 序列号，这正好贴合“本地几个点、远端十几个点”的场景。本地节点可以直接挂在 MCU 身边的总线上，远程节点通过双绞线拉到远端墙装或风管位置。一根总线到底，用同一个驱动和同一种协议，不区分本地和远程的软件接口，只是布线和供电策略不同——这是双轨监测最容易落地的实现方式。
1.2 HVAC 场景对温度监测的硬性要求
HVAC 系统不像实验室环境那么温柔。风柜的送风温度、回风温度、防冻保护温度、各区域室温，还有室外温湿度补偿，全都混在一个系统里。这些测点的共同特点是：分布散、数量多、更新节奏不需要特别快，但掉线不能误判成真实温度——否则冬天室外温度传感器断线，控制器可能直接按 -40℃ 判断防冻，把电动阀全开，后果不只是能耗浪费，还可能冻坏盘管。
这就决定了温度监测方案不能只是“把温度读上来”。它必须做到几件事：第一，每个节点有稳定唯一的身份标识，便于挂牌和故障定位；第二，数据要有 CRC 校验，保证总线上的数据错误不会被当成真值；第三，冷启动和掉线要有明确状态，而不是输出一个随机值或默认的 85℃ 复位值；第四，所有节点要能批量触发转换，减少轮询周期，给控制逻辑留出时间余量。
单总线体系的器件在满足这些要求上非常贴合。每个传感器出厂固化唯一序列号，天然就是即插即用的身份标签。定义好寄存器映射后，空调主机、触摸屏或者上位机拿到的不再是裸的传感器读数，而是一组带状态位的温度对象：有效读数、离线标记、故障代码、上次更新时间。这套对象模型比单纯读几个寄存器值要抗用得多。
2. 硬件架构与关键器件选型
2.1 PJ85718DM 这类单总线传感器的特性盘点
PJ85718DM 的基本工作方式是和 MCU 之间通过单根数据线通信，本身由 1-Wire 协议（单总线协议）驱动。它在出厂时固化了一个 64 位激光序列号，其中包含 8 位家族码、48 位序列号和 8 位 CRC 校验码。这串序列号在实际项目里就是每颗传感器的“身份证”，上位机建表、挂牌、巡检全靠它。
电气特性上，这类传感器的工作电压一般是 3.0V~5.5V，测量温度范围在 -55℃ 到 +125℃ 之间，HVAC 常用的 -20℃~85℃ 区段完全覆盖。分辨率最高可以配置到 12 位，对应 0.0625℃ 的量化步进。精度典型值在 ±0.5℃（-10℃~+85℃ 区间），对于空调温控、风管测温和室温采集来说足够用，毕竟室温控制本身还有 ±1℃ 的滞回区间。
它的供电模式有两种：外部供电和寄生供电。外部供电是三根线：VDD、GND、DQ，供电稳定，信号驱动强，适合远程节点。寄生供电只接 GND 和 DQ 两根线，靠信号线上的高电平给内部电容充电，好处是少拉一根线、少一个电源，坏处是转换电流大时容易跌落，多节点和长线场景下可靠性下降。HVAC 远程节点我强烈建议外部供电，不要为了省一根线给自己埋雷。转换时间方面，12 位分辨率下典型转换时间约为 750ms，这个特性直接决定了批量测温的最小周期，后面软件部分会讲到如何利用并发转换指令把总耗时压下来。
2.2 PIC18F86J15 的资源盘点与引脚规划
PIC18F86J15 是一颗高密度 Flash 的单芯片方案，内部资源在中等复杂度温控项目里相当够用。编写端到端驱动和协议时，最关心的几个外设是：通用 IO（位撞击单总线时序）、定时器（生成精确延时和采样节拍）、UART（接 RS-485 收发器）、以及足够的 RAM 来维护传感器表格和滤波缓冲区。
单总线时序没有专门的硬件控制器，用 GPIO 位撞击实现。好在 1-Wire 协议由一系列毫秒级、微秒级延时组成，用定时器中断或者忙等待都行。建议默认的时序参数严格查数据手册，不要靠猜。以标准的复位脉冲为例：主机拉低最少 480μs，然后释放，等 15~60μs，再读传感器应答脉冲。这个窗口很窄，忙等待模式下的延时函数必须配置好时钟源。
RS-485 部分推荐用 UART 加一个收发器芯片，半双工模式。远程节点和上位机之间走 Modbus-RTU 协议，协议层用 CRC16 校验。对于 PIC18F86J15 这颗芯片来说，UART 波特率可以用 9600 或 19200，HVAC 现场总线线缆一般不长，9600 更稳，特别是在老建筑里穿管走线的情况。
主控制器的引脚规划建议分四组：单总线 DQ 引脚独立接一个带中断的 GPIO，UART_TX/RX 接 RS-485 收发器，几个按键输入，一路 PWM 输出控制风机或电动阀。预留 1~2 个 GPIO 作为 LED 状态指示，方便现场调试时一眼看出系统是否在线。
2.3 网络拓扑：总线型优于星型
单总线天然支持总线型拓扑，一条主干线从控制器拉出去，各个传感器节点就近挂接，支线要短。HVAC 现场最常见的错误是做成星型拓扑：控制器在中间，每颗传感器单独拉一根线到控制器。这样做的始发阻抗和信号反射都不好控制，尤其在远程端 30 米以上的线缆段，波形畸变往往导致偶发读错。
总线型拓扑的好处是主干线可以贯穿整个楼层或机组，每个传感器是总线上的一个分支节点。分支线（也就是从主干到传感器的短引线）越短越好，工程上建议不超过 3~5 米。如果现场实在绕不开星型走线，可以在集线点附近加一个有源中继器或者把总线分段驱动，不要长时间让一根长线带太多分支。
布线材质方面，优先选双绞线或屏蔽双绞线。屏蔽层一端接地（通常是控制器端），不要两端同时接地，避免地环流。线径上，信号线至少 0.5mm²，远程供电线建议 0.75mm² 以上，特别是多节点远程总线在 24V 供电下还要考虑压降。
3. 核心电路设计与参数计算
3.1 上拉电阻不是随便选个 4.7k 就完事
单总线空闲状态是高电平，使用时外部上拉电阻把 DQ 线拉高。上拉电阻的大小直接影响总线波形上升时间和驱动能力。总线电容越大、节点数越多，上拉电阻就得越小，否则上升沿太缓，传感器在读写窗口内采不到正确电平；但上拉电阻太小又会加重主机和从机的灌电流负担，低电平拉不下去，同样会造成通信失败。
估算上拉电阻的通用思路是：根据总线上总的分布电容和信号要求的上升时间，配合公式计算时间常数。单总线标准时序里读时隙对上升沿的要求一般比较严格，以 1-Wire 系统的常见要求为例，上升时间尽量控制在 1μs 内比较稳。典型双绞线的分布电容按 50~100pF/m 估算，30 米线大约 1.5~3nF，再加上每个传感器节点引脚电容约 100pF，20 个节点就是 2nF，总线总电容按 5nF 估。要满足上升时间 tr ≈ 2.2 × R × C 不超过 1μs，R 就是 VCC×C 下的等效充电电阻，实际上还要加上驱动管的导通电阻，估算下来 R 在 1kΩ~2.2kΩ 级别。室内短总线、节点不多时，4.7kΩ 是可以的；远程总线和多节点必须降到 1kΩ~2.2kΩ。
更稳妥的做法是先按 1kΩ 起步，用示波器看 A 点波形，没有示波器就做极值测试：全部节点离线（最坏反射状态）时试读，错读率增大的话再微调上拉电阻或加总线端接。不过 1-Wire 不像 RS-485 那样讲究端接匹配，总线长度不极端时靠适度下拉的上拉电阻就能压住振铃。
注意：寄生供电模式下，上拉电阻同时还负责给传感器内部电容充电，阻值太大会导致转换期间供电跌落，传感器会返回错误读数或干脆不应答。线路一长，寄生供电基本不可靠，这也是我在 2.1 里强调必须外部供电的原因。
3.2 本地与远程节点的电源设计
本地节点直接由主控板上的 3.3V 或 5V 供电即可，PIC18F86J15 工作在 3.3V，PJ85718DM 接 3.3V 或 5V 都能接受。如果传感器和 MCU 电平不一致，注意 DQ 线电平转换问题——单总线协议没有标准电平转换器，最好让 VDD 和 MCU 的 I/O 电压一致，都放同一组电源上，避免半电平状态。
远程节点建议采用集中供电而非每个节点单独配电源。典型的做法是控制器端输出一组 12V 或 24V 直流电源，沿总线把电源和信号一起拉到远端，在每个传感器节点近处加一个 LDO 降到 3.3V/5V 供传感器使用。同时电源和信号共地，保证逻辑电平参考一致。这里要小心：电源线和信号线不要穿同一根管走几百米，HVAC 现场强电干扰会耦合进信号，就算有 CRC 校验能发现错误，出错重试也会拖慢周期。
老建筑和机电房里雷击浪涌问题不可忽略。控制器端的电源入口要加防反接、保险丝和 TVS 管；远端的信号线入口建议串一个 100Ω 电阻再进传感器 DQ 引脚，线缆屏蔽层在控制器端单点接地，远离大功率变频器和接触器的布线通道。很多项目一开始省了这几毛钱，后期季节性跳变和偶发误读会让你恨不得把整条线挖出来重铺。
3.3 远程数据回传：为什么选 RS-485 而非自带总线直拉
如果所有传感器都挂在同一条单总线上，理论上 MCU 可以直读，但 HVAC 项目里控制器和显示面板、上位机往往不在同一个位置，而且单总线抗共模干扰能力有限，不适合跨楼层长距离传输总线原始信号。折中方案就是用两条通道：传感器到控制器之间是短一些的单总线，控制器把汇总后的温度数据通过 RS-485 转成 Modbus-RTU 协议回传给中央监控。
选 RS-485 而不是 CAN 或以太网，主要看在 HVAC 场景里 RS-485 的成本、成熟度和实施便利性占优。RS-485 是差分信号，共模抑制能力强，1200 米内稳定跑 9600bps 没压力，足够楼宇自控用。Modbus-RTU 协议栈实现简单，上位机组态软件基本都原生支持。CAN 在抗干扰和实时性上更好，但 HVAC 里温度数据实时性要求没那么高，没必要引入更复杂的总线配置。以太网则需要换用带以太网口的控制器或者外加转换网关，成本翻倍，在老项目改造中不划算。
硬件上注意三点：RS-485 收发器的 A/B 端要加 120Ω 终端电阻，且只在总线两端各加一个；A/B 线要分别加上拉和下拉偏置电阻（典型 680Ω~1kΩ），保证总线空闲时处于确定电平；收发器芯片的 RO/DI 引脚最好加光电隔离，避免现场地电位差烧坏主控板——HVAC 现场不同设备地电位差经常有好几伏，这个坑踩过的都懂。
4. 软件实现与调通
4.1 1-Wire 驱动层：时序就是一切
单总线驱动看起来代码不多，就是几个延时加电平翻转，但实现时最容易出事的就是时序精度。驱动层包含四部分：初始化（复位和在线检测）、写 0、写 1、读数据。
以写 1 时隙为例：主机先拉低总线至少 1μs，然后释放总线，让上拉电阻把电平拉高，整个时隙持续 60~120μs；而写 0 时隙是主机拉低总线并保持约 60μs，即使传感器在读窗口内采样到低电平。读时隙则是主机拉低 1μs 后释放，在 15μs 内采样总线电平，读到 1 就是高、读到 0 就是低。
这里有个容易被忽略的细节：主机释放总线后的上升沿需要时间，如果上拉电阻太大、总线电容又高，写 1 时序里传感器在读窗口采到的电平可能还没升到逻辑高，就会把 1 误读成 0。所以驱动代码的逻辑要和上拉电阻联调，不能光对着 datasheet 抄延时就算完。
典型驱动的伪代码如下：
uint8_t ow_reset(void) { uint8_t presence = 0; DQ_LOW(); delay_us(480); // 复位脉冲，拉低至少 480us DQ_HIGH(); delay_us(70); // 释放并等待传感器应答窗口 presence = DQ_READ(); // 0 表示有器件在线，1 表示总线上没有器件 delay_us(410); // 补齐整个复位时隙 return presence; } void ow_write_bit(uint8_t bit) { DQ_LOW(); if (bit) { delay_us(6); // 写 1：短拉低后释放 DQ_HIGH(); delay_us(64); } else { delay_us(60); // 写 0：持续拉低 DQ_HIGH(); delay_us(10); } } uint8_t ow_read_bit(void) { uint8_t bit; DQ_LOW(); delay_us(6); DQ_HIGH(); delay_us(9); bit = DQ_READ(); delay_us(55); return bit; }写 0 和写 1 的时序差异不是简单的延时长短，而是传感器在时隙开始后的 15~60μs 这个采样窗口内对总线电平进行采样。写 1 必须要保证采样窗口内总线已经回到高电平，写 0 则要保持低电平。理解了采样窗口，就会发现网上不少“抄来就能用”的延时参数为什么在部分板子上不稳定——因为它们的时序边缘刚好卡在窗口边界上，欠压或负载一变化就翻车。
4.2 多点传感器搜索与 ROM 表管理
PJ85718DM 这类单总线器件支持总线搜索命令（搜 ROM），本质是一个二叉树遍历过程。主机发搜索命令后发送 64 位掩码，逐位比较每位上有无器件、多大数量的器件在这一位出现冲突，以此把所有器件的 64 位序列号全部枚举出来。这块逻辑不复杂，但第一次上电时跑一遍搜索，建一个 ROM 表，后续顺序读取时就按表来操作，不必每次重新搜索。
我建议的项目流程是：上电后先执行一次完整搜索，把所有在线器件的序列号存入 RAM 数组（掉电前如无必要不必重新搜索）。如果发现本次搜索结果和设备表不一致，就标记为“总线变动”事件，并重新初始化端口后再搜索一次，避免一次瞬间干扰导致设备表错乱。对 HVAC 现场来说，每台机组传感器数量一般不会超过 20 个，搜索保存一次也就百毫秒级操作，代价可以接受。
ROM 表结构最小化定义大概这样：
typedef struct { uint8_t rom[8]; // 64 位序列号 uint8_t present; // 在线标志 float last_temp; // 上次有效温度 float filtered_temp; // 滤波后温度 uint32_t last_update; // 最后更新时间戳 } sensor_node_t;设备表还有一个用途是便于现场挂牌。把每个 ROM 号和实际安装位置（比如“三楼回风”“地下室送风”）绑定到一个配置文件里，现场调测时直接按位置查温度，而不是看到一串序列号摸不着头脑。这个环节看着不起眼，后期维护时能省下大量时间。
4.3 温度转换与批量读取：把 750ms 压成一次等待
PJ85718DM 单次温度转换在 12 位分辨率下要 750ms，如果 20 个节点一个个发转换命令再等结果，就是 20×750ms=15 秒一轮，控制周期完全没法接受。好在这类器件支持广播命令（跳过 ROM 匹配，对所有节点同时发转换指令），一条总线上的所有节点收到指令后同时开始转换，等待 750ms 后，再按 ROM 表逐片读取温度值。整体耗时从 15 秒压缩到 0.75 秒加逐点读取时间（每个点约几毫秒），20 个节点一轮实际不到 1 秒，这个方案才是工程可用的。
void read_all_temperatures(void) { ow_reset(); ow_write_byte(0xCC); // 跳过 ROM，广播 ow_write_byte(0x44); // 发起温度转换 delay_ms(800); // 等待转换完成（按 12 位分辨率留余量） for (int i = 0; i < node_count; i++) { ow_reset(); ow_write_byte(0x55); // 匹配 ROM for (int j = 0; j < 8; j++) { ow_write_byte(sensor_table[i].rom[j]); } ow_write_byte(0xBE); // 读暂存器 uint8_t lsb = ow_read_byte(); uint8_t msb = ow_read_byte(); // 跳过 CRC 校验（实际项目必须做），合成温度值 int16_t raw = (msb << 8) | lsb; sensor_table[i].last_temp = raw * 0.0625f; } }这段代码里 800ms 的等待时间按 12 位分辨率预留了 50ms 余量。实际项目里可以进一步优化：温度数据本身是缓变量，第一轮达到设计周期后，后续轮次可以采用“上次读取到本次转换完成”的重叠流水——转换等待期间处理通信、按键、显示等任务，不要用阻塞式 delay 把 CPU 全占住。PIC18F86J15 的主频跑这些绰绰有余，省出来的指令周期可以做滤波和联动控制。
温度读取后的软件滤波也不能省。虽然这类传感器本身有良好的噪声表现，但 HVAC 现场空调电磁阀启停、变频器运行时，总线上仍可能耦合少量干扰，读出的个别点会出现跳变。建议对每个节点做一阶滞后滤波：filtered = filtered + alpha * (raw - filtered)，alpha 取 0.2 左右，每 2 秒更新一轮时对 0.5℃ 左右的毛刺有不错的抑制作用。另外加一个要害判断：如果当前读数与上次有效读数的差值超过 2℃ 且没有转换状态标记，先不要覆盖有效值，而是标记可疑并继续观察，这一步能有效对抗变频器谐波导致的偶发跳变。
4.4 主循环协议状态机与 HVAC 联动控制
完整主循环可以拆成几个状态：初始化（搜索 ROM、加载配置）、空闲等待、广播转换、读取温度、更新滤波、数据上报、联动控制。整个周期用定时器切分，推荐 2 秒为一个温度更新周期——室内温度变化不可能超过这个时间尺度，而且这个周期远低于 HVAC 执行机构的响应时间，作为控制输入不会造成振荡。
数据上报用 Modbus-RTU 从站模式实现，寄存器映射这样定义：保持寄存器区存放每路温度值，按 0.01℃ 定标，比如 24.35℃ 存成 2435；输入寄存器区存放每路状态字，Bit0 为在线标志、Bit1 为掉线标志、Bit2 为校验失败标志、Bit3 为 CRC 错误标志；线圈区放各路报警输出。这套映射不花哨，胜在稳定，上位机组态时一目了然。
联动控制方面，温度数据真正产生价值的时刻是参与控制逻辑。举例来说，变风量末端通常用回风温度作为主控量，送风温度作为补偿量。回风温度决定了风机转速的粗调，送风温度偏差再对风阀开度做细调。如果把回风传感器布置在一个不合理的回流区，读到的温度会受局部涡流影响，波动大、控制肉。一个有效的做法是布置两个回风测点取平均，并把室外温度作为前馈补偿，室温变化滞后能减少 30% 左右。
5. HVAC 现场部署的避坑经验
5.1 冷启动时的 85℃ 假温度
这几乎是PJ85718DM这类器件在HVAC项目上线初期最常遇到的问题。传感器上电复位的默认温度寄存器值是 0x0550，按 12 位分辨率换算正好是 85℃。如果主控程序在器件复位后第一次读取就直接使用这个值，相当于系统上电那一刻控制器会认为现场温度已经85℃，夏天可能触发高温报警或直接关停制冷，冬天更离谱——这个“85℃”可能让防冻逻辑认为一切正常，防风阀被错误关小。
解决办法有两个层次。第一层是逻辑判断：上电后标记“未有效转换”状态，直到收到传感器完成转换的应答并且读到合理的温度值（比如 -30℃~+80℃ 区间内）才允许覆盖有效值。第二层是硬件复位策略：每次主控复位后，对单总线执行复位脉冲和存在检测，重新发起一次温度转换，等待足够时间后再进入正常的读取周期。只要不把复位值和正常值混在一起，这个坑就踩不进去。
5.2 长线下的供电与信号冲突
远程 30 米以上时，如果采用寄生供电，你就会看到非常典型的症状：短距离测试一切正常，拉远之后要么读不到、要么读数跳变。原因我在 3.1 里分析过——单根信号线上的上拉电阻既要传数据又要给传感器内部电容充电，远距离时总线电容把充电电流分走，转换期间电压跌落，传感器无法正常工作。
正确姿势是改成外部供电三线制，供电源头从控制器端拉 12V 或 24V，在传感器节点旁用 LDO 转成 3.3V。信号线和电源线走同一条双绞线时注意线对分配，推荐信号 DQ 和 GND 一对，电源 V+ 和 GND 一对，这样信号有参考地，电源纹波也不容易直接耦合到信号上。另外每个节点的 DQ 引脚和总线主干之间串联一个 100Ω~220Ω 电阻，一旦该节点损坏短路不会直接拉死整条总线——这个防护在 HVAC 现场特别重要，因为端子进水氧化后 DQ 线对地短路是掉线故障的头号原因。
5.3 掉线节点的策略：不要一根筋
某节点掉线后的处理策略比掉线本身更容易暴露设计问题。最差的处理方式是直接把它当 -55℃ 或 +125℃ 送进控制逻辑——一台空调如果回风传感器掉线，系统被强制按停机或全速模式处理，后果要么是没人管要么是能耗爆炸。
推荐做法是三级策略：第一阶段掉线先保持上次有效读数并标记离线标志，持续 5 个周期（10 秒）仍然没有恢复，进入第二阶段的“替代温度”模式，用相邻节点的平均值或者根据季节的设定默认值来接管；第三阶段如果离线时间超过 60 秒，直接触发掉线报警并切换控制器为手动/安全模式，同时把离线寄存器位置位，上位机可以明确看到是哪一路测点失效。不要把掉线值和有效值混在同一个变量里，给每个温度对象单独配一个状态位，宁可逻辑复杂一点。
5.4 空调联动控制的实测对比
真实项目里，我对比过同一台风机盘管在两种控制策略下的效果。第一种只用回风温度做 PID 闭环，室外温度变化时，因为回风温度滞后，风机转速要等到室温明显变化才调整，房间温度波动在 ±2℃ 左右；第二种加上室外温度前馈补偿，根据室外温度和回风温度的差值预先修正风机转速，稳态波动能压到 ±0.5℃，而且压机启停频率明显下降。硬件几乎没动，只是把温度数据从“测量显示”升级成了“前馈控制输入”。
增量式 PID 是 HVAC 联动里最常用也最稳妥的控制法，输出是每一步的增量变化，天然不会误动作。温度环路的采样周期一般取 2~5 秒，如果不加滤波直接使用原始温度，微分项会把噪声放大，所以至少要做一次平滑滤波再进 PID。还有一条经验：执行机构（电动阀、风机变频器）的输出增量一定要做限幅，防止一次干扰导致阀门全开或全关，这个限幅值根据实际系统的时间常数来定，空调系统一般取满量程的 5%~10%/周期。
6. 常见问题排查速查表
| 现象 | 可能原因 | 排查方法 | 解决措施 |
|---|---|---|---|
| 上电后读取全为 85℃ | 复位默认值未处理；未等转换完成 | 查看上电日志，确认是否在转换完成前读取 | 增加转换等待；做有效温度区间判断 |
| 某节点偶发读数错误 | 支线过长；端子氧化；CRC 错误 | 用示波器看节点处波形，测 CRC 出错率 | 缩短支线；加 100Ω 防护电阻；更换端子 |
| 远程节点全部离线 | 总线短路；供电中断；终端电阻短路 | 依次断开节点二分定位；万用表测 DQ 对地电阻 | 修复短路；重新供电；串入限流电阻 |
| 读数跳变、毛刺大 | 变频器干扰；上拉电阻过大；屏蔽层未接地 | 查看波形上升沿，对比大功率设备启停时间点 | 降上拉电阻；加强滤波；屏蔽层单端接地 |
| 总线无法搜索到任何器件 | 上拉电阻丢失；DQ 短路；复位脉冲宽度不足 | 万用表量 DQ 电压（空闲应为高）；核对复位时序 | 补上拉电阻；重查 DQ 走线；调复位延时 |
| 单节点掉线后整条总线卡顿 | 节点损坏拉低总线 | 逐步摘除节点二分定位 | 为每个节点增加隔离电阻，保证故障隔离 |
排查这类问题最忌瞎猜。我自己的习惯是先在控制器端用一个临时延长线挂一颗已知完好的传感器，跑一圈驱动自检，确认驱动层没坏，再沿总线向远端逐段排查。这样能把“主控问题”和“现场问题”快速切分开。
技巧：调试时给每个节点贴一个带 ROM 尾号的标签，记录安装位置和线缆长度。现场出问题时，不用抱着笔记本跑上跑下，看上位机报的序列号，对照标签直接找到对应节点。
最后再分享一个经验
做这个项目最大的体会是：温度监测真正的难点不在“读温度”，而在“可靠地读、多路地读、现场不怕折腾地读”。选择 PJ85718DM 这类 1-Wire 器件，选型时可能看上去不如 SPI/I2C 传感器“高级”，但在多节点、远距离、低成本这三重约束下，单总线体系实在是最省心的一套方案。而 PIC18F86J15 的真正价值在于把单总线驱动、Modbus 协议栈、滤波和控制逻辑全部集成到一颗芯片里，硬件简单、维护成本低，后续升级也方便。
如果再往后扩展，我会考虑在这套系统上面叠一层日志功能——把每个测点的温度曲线存到 SD 卡或通过串口导出，每周拉一次数据分析温控策略的效果；或者加一个以太网接口的网关，把 Modbus-RTU 转成 Modbus-TCP，这样远程运维时就能直接在网页上看到每个节点的实时温度和状态。硬件平台不用大改，主要工作量在协议转换和上位机界面。想把这套方案吃得透，关键是把总线时序、电源规划和状态机管理这三点打扎实，现场跑起来就会省心很多。
