企业官网建设流程全解析

做人体存在检测，最让人头疼的从来不是“检测到人”，而是“人还在，它却以为人走了”。用 PIR 红外的场景大家都熟：人一坐下改代码，灯灭了；人稍微动一下，灯又亮，来回折腾。我前后换过四五套方案，最后落到 LD2410 这颗 24GHz 毫米波雷达传感器上，现在家里三个房间、办公室两个会议室都在用，最长的一台连续跑了十四个月没重启过。这篇就把从接线、读协议、调参到长期踩坑的全过程摊开写一遍。

LD2410 是一颗基于 FMCW 调频连续波原理的 24GHz 人体存在雷达传感器模块，串口直接输出目标状态、距离和能量，同时还能给一路 GPIO 高低电平做最简单的开关量输出。它最核心的价值是能认出“静止不动但还活着的人”——靠的是呼吸时胸腔起伏带来的毫米级位移，这一点 PIR 和超声波都做不到。这篇文章适合三类人看：刚买回来不知道怎么接线的硬件新手、想把它接进自己系统里的开发者、以及已经能读出数据但被误报折磨到想扔掉的倒霉蛋。全文按原理、硬件、协议、代码、调参、排障六条线走，代码都能直接抄。

1. 先把 LD2410 到底在测什么搞清楚

很多人拿到模块第一件事就是插上电看串口有没有数据，看到一堆十六进制就懵了，其实问题出在没理解它在测什么。LD2410 输出的不是一个“有人/没人”的布尔值，而是“每个距离区间里的运动能量和微动能量”，人只是这些能量的一种常见来源。理解这一层，后面所有的误报、漏检、调参问题都会变得有逻辑可循，而不是玄学。

1.1 它和红外、超声波的根本差别在哪

PIR 红外的工作原理是检测视场内红外辐射的变化，注意关键词是“变化”。人只要静止，辐射不变化，它就认为没人，这是物理原理决定的，不是产品做得差。所以 PIR 天生适合“走廊过道”，不适合“书房工位”。超声波测距靠声波反射，软性材料比如衣物、窗帘、地毯吸声严重，回波弱，而且超声波对气流极其敏感，空调一吹就飘，测距范围也短。

毫米波雷达走的是另一条路。它发射一个频率随时间线性变化的连续波，遇到物体反射回来，接收信号和发射信号之间会产生一个频率差，这个频差和距离成正比，于是能算出目标在多远。更关键的是相位：目标只要发生哪怕零点几毫米的位移，回波相位就会变化，雷达能把这种变化提取出来。人坐着不动，胸口随着呼吸起伏大约 3~8 毫米，这个量级对 24GHz 的毫米波来说完全够用。这就是 LD2410 能测“静止人体存在”的物理基础，也是它区别于前两者的根本原因。

它也有明显的软肋。风扇叶片、摆动的窗帘、鱼缸里的水流、空调出风口的飘带，这些都在“动”，雷达分不清是人还是物。所以实际部署时，误报的大头往往不是雷达本身不行，而是安装位置选错了。另外毫米波穿透力有限得很具体：塑料、亚克力、玻璃、木板、石膏板能穿，金属和大面积水体穿不过去。这几个特性后面会反复用到。

1.2 距离门、能量值这些数字的真实含义

LD2410 把探测空间按距离切成若干“门”，每个门宽 0.75 米，编号 0 到 8，一共九档。这个 0.75 米不是随便定的，它和雷达的调频带宽直接相关，带宽决定了距离分辨率，也就是“两个目标靠多近还能分开”。九档乘以 0.75 米，覆盖到 6.75 米左右，这就是为什么规格书里静止检测距离标 6 米上下——再远就没有对应的门了。

规格书里运动目标标称能到 8 米，这个 8 米说的是雷达的作用距离，不是距离门的编号上限。超过 6.75 米的目标，模块能告诉你“有人”，但给不出可靠的门号，这个区别在实际写代码时很重要——如果你拿距离做逻辑判断，超出范围的值不能直接信。

能量值范围是 0 到 100，可以理解成“这个门里的回波有多强”。运动中的人能量通常很高，六七十属于常见；静止坐着的人能量低得多，十几到三十几都正常；没人时基线一般在个位数。能量不是固定的，它跟人的体型、朝向、衣着、甚至衣服厚薄都有关系——穿羽绒服坐着和穿短袖坐着，回波强度能差一截。这一点后面调参时必须考虑进去。

1.3 型号怎么挑，带蓝牙和不带蓝牙的区别

市面上常见的几个版本：基础版只有串口和 GPIO；带 B 的版本多了一路蓝牙，可以用手机端配置工具直接改参数，不用接电脑；带 C 的版本体积更小、引脚定义略有调整，适合空间紧的场合。功能核心是一样的，区别主要在调试便利性和尺寸。

我的建议很直接：第一次玩就买带蓝牙的版本。不是因为它性能更好，而是因为调参这件事你必须反复试，插着 USB 转串口线拖一根线到电脑上，来回改一次参数要拔插一次，效率低到让人暴躁。有蓝牙，你坐在房间里人肉测试“我坐这里能检测到吗”，手机上改完立刻看效果，调参时间能省掉一大半。

供电方面要留意：模块标称 5V 供电，但串口 IO 是 3.3V 电平。这两件事不矛盾，很多新手在这里翻车，以为 5V 供电就得配 5V 串口，结果把 RX 打坏了。天线那一面是陶瓷天线或者板载天线，正面必须裸露，贴着金属板装上去等于给雷达戴了个铁帽子，探测距离会掉得莫名其妙。买回来先看丝印和配套资料确认版本，别凭记忆接线。

2. 硬件落地：供电、走线、安装的三个死穴

我见过太多“雷达不准”的案例，最后查下来根本不是雷达的问题，而是供电脏、地没共、装错位置。这一章讲的都是看起来最没技术含量、但最容易翻车的地方。硬件基础没打好，后面代码写得再漂亮也是白搭。

2.1 供电不稳是误报的头号元凶

LD2410 工作电流不大，典型几十毫安，但它是射频器件，对电源纹波非常敏感。如果你把它和 LED 灯带、继电器、电机共用一个 5V 电源，那些负载开关瞬间产生的尖峰会直接耦合进雷达的供电轨，表现出来就是“灯一亮，雷达就报有人”。这个现象特别迷惑人，因为逻辑上完全说不通。

三个处理办法，按成本从低到高。第一，单独走一路电源，至少不要和开关类负载共用同一组线，从电源出口就开始分叉。第二，在模块供电脚旁边并一颗 100μF 电解电容加一颗 0.1μF 陶瓷电容，前者应付低频波动，后者滤高频噪声，两颗一起上才有意义，只焊一颗效果有限。第三，如果条件允许，用一颗低压差线性稳压器单独给雷达供电，把开关电源的纹波彻底隔开。

注意：模块的地和主控的地必须共地，这不是可选项。我遇到过用两路独立电源分别供主控和雷达、结果忘了共地的情况，串口收到的全是乱码，查了两个小时。

还有一点容易被忽略：电源线长度。线拉得太长、太细，压降和天线效应都会出来。超过 30 厘米就考虑加粗线径或者就近加电容，别图省事拿杜邦线拉一米。

2.2 串口连线与电平匹配

默认通信参数是 256000 波特率、8 数据位、1 停止位、无校验。这个波特率比常见的 9600、115200 高不少，有几个坑要提前说。

第一，USB 转串口模块要支持这个速率。FT232、CP2102、CH340 这些主流芯片一般都支持，但市面上有些极便宜的模块标称支持、实测丢包。如果你接上电脑打开串口工具只看到零星乱码，先换一个转换器试试，别怀疑模块坏了。

第二，主控和雷达的 TX/RX 要交叉接：主控 TX 接雷达 RX，主控 RX 接雷达 TX。这个基础错误每次都能坑到人。雷达的 TX 是 3.3V 电平，接 ESP32 的 RX 可以直接连；雷达的 RX 也是 3.3V 电平，所以 ESP32 的 3.3V TX 直接接没问题。但如果你的主控是 5V 逻辑，比如某些老式开发板，TX 输出 5V 直接怼进雷达 RX 会超规格，加个电阻分压或者用双向电平转换芯片，两个电阻分压的成本最低。

第三，能不用软件串口就不用。256000 这个速率对软件模拟串口来说压力很大，容易丢字节，丢一个字节整帧就废了。ESP32 有多个硬件串口，随便挑一个用。

2.3 安装位置决定了一大半的成败

雷达的视场角大约正负 60 度，也就是说它像一个手电筒的光锥，不是全向的。装的时候脑子里要有一个锥形，把要检测的区域罩进去。

高度上，1.2 到 1.5 米之间比较合适，大概是人坐着时胸口的高度。装太高，向下俯视，近处的地面会进视场，走动的人会频繁进出不同距离门；装太低，桌面和椅背会遮挡。角度上，如果装在墙角，建议斜 45 度朝向房间中心，这样能最大化覆盖；如果装在正对区域的墙面上，稍微向下压 10 到 15 度，能减少天花板方向的无效回波。

遮挡物这块必须讲清楚。模块正面能穿塑料外壳、亚克力面板、玻璃、木板、石膏板，所以你可以把它藏在吊顶里、装在塑料配电箱里、甚至贴在木质柜门后面，这属于它的优势。但金属绝对不行，铝扣板、铁皮箱、金属网都会把信号挡死。大面积的水也会吸收，鱼缸后面、水管密集的墙边都不是好位置。

提示：玻璃能穿透这件事是个双刃剑。装在窗户边，它能检测到窗外的行人、马路上的车，你会以为是自己房间在误报。装之前先想想视场锥里除了人还有什么。

另外提一个反直觉的点：不要贴着墙装。模块正后方如果有大面积反射面，会产生多径反射，回波绕一圈回来被当成目标，表现是“明明没人但一直报有人”，而且距离值飘忽不定。至少离墙面留出几厘米，或者干脆装在离墙的位置。

3. 串口协议拆解：从一串十六进制里读出人

协议本身不复杂，但要写得健壮，得理解帧的边界在哪、长度字段怎么算、粘包怎么处理。这一章把帧结构掰开讲，配合第 4 章的代码，基本能覆盖九成以上的应用场景。

3.1 帧结构逐字节说明

所有数据帧和命令帧都是同一个外壳：帧头四个字节FD FC FB FA，接着是两个字节的数据长度（小端序，低字节在前），然后是数据段，最后是固定的帧尾04 03 02 01。

[FD FC FB FA] [len_lo len_hi] [data...] [04 03 02 01]

关键在于长度字段的含义：它统计的是数据段的字节数，不含帧头六字节，也不含帧尾四字节。所以一整帧的总长度等于 6 加数据长度加 4。这个定义看起来简单，但它是解析代码的核心，算错一个字节后面全乱。

在字节流里找帧不能只看帧头就认为是一帧的开始，因为数据段内部完全可能出现FD FC FB FA这样的巧合字节。稳妥的写法是：只在缓冲区开头匹配帧头，匹配上就按长度字段等够整帧，帧尾校验通过才处理。这个思路比状态机好写也好调试，第 4 章的代码就是这么做的。

3.2 目标数据帧长什么样

目标数据帧的数据段第一个字节是帧类型，值为0x02。后面跟着目标状态和距离、能量字段：

状态字段的值 3 很常见，意思是模块同时检测到运动目标和静止目标，通常是同一个人的身体在动、但整体位置没大变化。写业务逻辑时不要只判 1 或 2，把 3 也算进“有人”。

探测距离这个字段值得单独说。它是模块综合判断后给出的“目标最远到哪”，比单独看运动距离或静止距离更接近真实情况。做灯光联动时，我一般用这个值做区域判断，而不是用运动距离，因为人静下来之后运动距离会归零，但探测距离还在。

工程模式下，数据段会在这七个字节之后追加内容，包括最大运动门、最大静止门，以及九个门的运动能量和九个门的静止能量。这部分的长度在不同固件版本上存在差异，我踩过一次坑：按网上找的固定长度去切，结果每个门的能量全错位。正确做法是第一次接上电先把原始十六进制整帧打印出来，数一遍字节，然后按自己手上的固件来写。第 5 章的调参方法完全依赖这部分数据，所以值得花十分钟确认清楚。

3.3 命令帧与参数读写

命令帧的数据段第一个字节是命令码，常用的几个：

改参数有个绕不开的规则：必须先发0x00进入配置模式，改完发0x01退出，否则改了不生效。这个规则文档里写了，但很多人扫一眼就跳过，然后对着“参数改了没反应”抓头发。我自己的习惯是在封装函数里把进出配置模式做进去，调用方只管传数值。

写参数命令0x03的数据段结构，按常见固件的排布是：两个保留字节，然后最大运动门、最大静止门、无人持续时间两个字节（小端，单位秒），接着九个字节的运动灵敏度，再九个字节的静止灵敏度。

这里我要分享一个真正省事的方法：不要凭记忆去拼这个字节串。先用0x02把当前参数读回来，你会拿到一串完整的、格式肯定正确的字节；然后在内存里改掉想改的那几个位置，把0x02改成0x03发回去。这样格式问题和固件差异问题一次性绕开，比对着文档一个字节一个字节对齐靠谱得多。这种“读回来改再写回去”的手法在很多串口设备调参上都通用，值得记下来。

读参数命令的返回帧，数据段第一个字节是0x02，后面跟着的就是上面那套参数的当前值。要注意返回帧和主动上报的目标数据帧都是类型0x02，靠数据长度区分——参数的返回帧长度和上报帧不一样。所以解析的时候不能只看类型字节，还得看长度。

4. 上手实操：三套代码直接抄

下面三套代码覆盖三种典型场景：想自己完全掌控逻辑的用 ESP32 手写解析，想快速接进智能家居系统的用现成组件，想在电脑上先摸清楚模块行为的用 Python 脚本。三套可以并行，不冲突。

4.1 ESP32 手写帧解析

这套代码的核心思路是环形缓冲加帧头扫描，重点处理了粘包和半帧等待。bufLen >= sizeof(buf)那个判断是兜底，防止缓冲区溢出之后一直在错误状态里打转。

#include <Arduino.h> HardwareSerial RadarSerial(1); static const int PIN_RX = 16; // 接雷达 TX static const int PIN_TX = 17; // 接雷达 RX uint8_t buf[128]; uint16_t bufLen = 0; struct Target { uint8_t state; uint8_t moveDist; uint8_t moveEnergy; uint8_t stillDist; uint8_t stillEnergy; uint8_t detectDist; } t = {0}; void handleFrame(const uint8_t *p, uint16_t len) { if (p[0] == 0x02 && len >= 7) { t.state = p[1]; t.moveDist = p[2]; t.moveEnergy = p[3]; t.stillDist = p[4]; t.stillEnergy = p[5]; t.detectDist = p[6]; } } void parseBuf() { while (bufLen >= 4) { // 只从缓冲区开头匹配帧头，不是就丢一个字节继续找 if (!(buf[0] == 0xFD && buf[1] == 0xFC && buf[2] == 0xFB && buf[3] == 0xFA)) { memmove(buf, buf + 1, --bufLen); continue; } if (bufLen < 6) return; // 长度字段还没收全 uint16_t plen = (uint16_t)buf[4] | ((uint16_t)buf[5] << 8); uint16_t total = 6 + plen + 4; if (bufLen < total) return; // 整帧还没收全 handleFrame(buf + 6, plen); memmove(buf, buf + total, bufLen - total); bufLen -= total; } } void setup() { Serial.begin(115200); RadarSerial.begin(256000, SERIAL_8N1, PIN_RX, PIN_TX); Serial.println("radar ready"); } void loop() { while (RadarSerial.available()) { if (bufLen >= sizeof(buf)) bufLen = 0; // 兜底清空 buf[bufLen++] = (uint8_t)RadarSerial.read(); } parseBuf(); static uint32_t last = 0; if (millis() - last > 500) { last = millis(); Serial.printf("state=%d move=%dcm/%d still=%dcm/%d detect=%dcm\n", t.state, t.moveDist * 75, t.moveEnergy, t.stillDist * 75, t.stillEnergy, t.detectDist * 75); } delay(5); }

几个值得解释的细节。距离换算成厘米是门号乘 75，因为一门 0.75 米。memmove而不是memcpy，因为源和目的内存区域重叠，用memcpy是未定义行为，虽然在小数据量下往往也能跑，但没必要赌。parseBuf里while循环是为了处理一次读到多帧的情况，串口一次给你塞三帧是正常的。最后的delay(5)给串口留出时间，避免主循环空转太快把 CPU 占满。

调试阶段建议把原始帧也打印出来，肉眼对着十六进制看，比盯着解析结果猜问题快得多。等确认字段都对了再关掉打印。

4.2 ESPHome 接智能家居系统

如果你的目标就是“人来自动开灯”，不想自己写业务逻辑，用现成的组件最省事。串口配置好之后，各类实体声明出来，剩下的交给自动化规则。

uart: id: uart_radar tx_pin: GPIO17 rx_pin: GPIO16 baud_rate: 256000 parity: NONE stop_bits: 1 ld2410: id: radar binary_sensor: - platform: ld2410 has_target: name: "有人" has_moving_target: name: "有运动目标" has_still_target: name: "有静止目标" sensor: - platform: ld2410 moving_distance: name: "运动距离" still_distance: name: "静止距离" detection_distance: name: "探测距离" moving_energy: name: "运动能量" still_energy: name: "静止能量" number: - platform: ld2410 max_move_distance_gate: name: "最远运动门" max_still_distance_gate: name: "最远静止门" timeout: name: "无人判定延时" button: - platform: ld2410 factory_reset: name: "恢复出厂参数"

这套配置最实用的地方是timeout这个数字实体，它能直接在界面上滑动改无人延时，不用重启也不用重新烧录，调灯光联动体验的时候非常方便。max_move_distance_gate和max_still_distance_gate也是同理，装在 3 米宽的房间里，把门号设到 4 就够，多余的远距离门关掉能明显减少窗外误触发。

提示：改这些参数后要等几秒让模块写入，改得太快会丢。我一般是改一项、等两秒、看一眼行为、再改下一项。

4.3 电脑端 Python 调试脚本

调参之前先在电脑上把数据流看明白，比直接上单片机省时间。下面这段可以直接跑，装了 pyserial 就行。

import serial HEAD = b'\xfd\xfc\xfb\xfa' TAIL = b'\x04\x03\x02\x01' def frames(ser): buf = b'' while True: buf += ser.read(64) while True: i = buf.find(HEAD) if i < 0: buf = buf[-3:] break buf = buf[i:] if len(buf) < 6: break plen = buf[4] | (buf[5] << 8) if len(buf) < 6 + plen + 4: break payload = buf[6:6 + plen] if buf[6 + plen:6 + plen + 4] == TAIL: yield payload buf = buf[6 + plen + 4:] else: buf = buf[1:] # 帧尾不对，丢一个字节重找 def build_frame(cmd, data=b''): payload = bytes([cmd]) + data return HEAD + len(payload).to_bytes(2, 'little') + payload + TAIL ser = serial.Serial('/dev/ttyUSB0', 256000, timeout=1) # 打开工程模式，开始输出逐门能量 ser.write(build_frame(0x00, b'\x01\x00')) import time; time.sleep(0.1) ser.write(build_frame(0xFE, b'\x01\x00')) time.sleep(0.1) for p in frames(ser): if p[0] == 0x02 and len(p) >= 7: state, md, me, sd, se, dd = p[1], p[2], p[3], p[4], p[5], p[6] print(f"state={state} move={md*0.75:.2f}m/{me} " f"still={sd*0.75:.2f}m/{se} detect={dd*0.75:.2f}m")

这个脚本跑起来之后，屏幕上会持续滚出目标状态。让它跑着，你做几个动作：站着不动十秒、走动、坐下、离开房间，观察状态字段和距离字段怎么变。这个过程大概五分钟，你对模块行为的直觉就建立起来了，比看任何文档都管用。Windows 上串口名改成COM3这种形式。

5. 调参：把误报压到接近零的方法

调参这件事没有万能参数，因为每个房间的反射环境都不一样。但有方法论：先看清能量分布，再逐门设灵敏度，最后调延时。乱设参数的结果往往是“误报少了但漏检变多”，来回横跳。

5.1 用工程模式看清每个门的能量分布

工程模式是调参的唯一正确入口。打开之后，每一帧都会带上九个门的运动能量和静止能量，你就有了完整的画面。

具体步骤我按实际操作顺序写。第一步，把房间清空，人离开，门窗关好，让风扇空调都停掉，然后观察每个门的能量数值。这时候看到的数字就是背景噪声基线，通常都在个位数，个别门可能到十几。如果某个门在完全没人的情况下常年二三十，那这个门对应的区域一定有干扰源——可能是窗帘、可能是鱼缸、可能是隔壁房间透过来的。先把干扰源找出来，或者把这个门关掉，而不是靠调数字去硬压。

第二步，人坐在预期位置上，保持正常坐姿不动，观察能量。这时候你关注的是这个人所在的门，能量应该明显高于基线，比如基线 5、人坐着 25。如果只有十几，说明距离偏了或者角度不对，可以考虑挪模块位置。

第三步，人站在房间各个角落分别测，画一张粗糙的覆盖图。哪些位置能量够、哪些位置不行，一目了然。这一步花二十分钟，能省掉后面无数次“为什么这个角落检测不到”的返工。

5.2 逐门灵敏度应该怎么设

灵敏度的理解有个反直觉的地方：数值调高是更容易触发，不是更不容易。出厂默认九个门全部是 100，等于所有门全开、门槛最低，这就是很多人一装上去就疯狂误报的原因——把窗帘飘动、远处走廊的行人都算进来了。

合理的设法是逐门递减，近处低、远处高，因为近处干扰多、远处信号弱。

静止灵敏度整体要比运动灵敏度低一档，因为静止检测本来就靠微弱的呼吸信号，门槛设太高会把真人漏掉，设太低会把风扇的微动也算进来，这个平衡点只能靠实测找。表格里的数字是起点，不是终点，实际调试在这个基础上上下调十到二十都正常。

还有个实用技巧：先用最大距离门做粗调，再用逐门灵敏度做精调。比如房间只有 3.5 米深，把最大运动门和最大静止门都设到 5，超出的门直接不参与判断，这一步往往就能砍掉一半误报，比逐门调灵敏度省事得多。

5.3 无人延时和响应速度怎么权衡

无人延时指的是“目标消失之后，等多久才判定为无人”。这个参数在灯光联动里比灵敏度重要得多。

延时设太短，人只是屏住呼吸看手机，几秒钟后灯就灭了；设太长，人走了灯还亮着，浪费电也影响体验。我的经验值：书房、卧室这类人会长时间静坐的场景，设 30 到 60 秒；玄关、走廊这类人停留时间短的场景，设 10 到 20 秒；卫生间可以设到 60 到 120 秒，因为人在里面确实可能长时间不动。

响应速度这一端没有直接参数可调，靠的是灵敏度加上模块固件本身的行为。需要注意的是，不要用降低灵敏度来换取“不误报”，那是用漏检换的，最后会变成“人在那儿它死活不认”。正确顺序永远是：先清干扰源，再关多余距离门，再逐门降灵敏度，最后调延时。这个顺序反过来做，你会一直在原地打转。

6. 常见问题与排查技巧实录

下面这些坑我几乎全踩过一遍，有些是硬件问题，有些是理解偏差。整理成速查表，遇到问题先对号入座，能省不少时间。

6.1 收不到数据、乱码、只上报一次

关于乱码，有个细节：如果你看到的是“有周期性的、间隔规律的无意义字节”，十有八九是波特率错了；如果是“偶尔冒出来一个错字节”，那是丢包，查线路和地。这两种情况处理方式完全不同，先分清。

还有个小概率事件：主控刚上电时串口引脚电平不稳定，会在雷达的 RX 上产生一段噪声，极端情况下把模块的配置搞乱。稳妥的做法是主控上电后延时 500 毫秒再初始化串口，或者干脆先发一个退配置命令让模块回到默认状态。

6.2 频繁误触发和该检测不到

误触发是问得最多的。按出现频率从高到低排：第一是风扇和空调出风口，第二是窗帘和百叶窗，第三是窗外的行人车辆，第四是附近走动的宠物，第五是供电干扰。

风扇的判断方法很简单：把风扇关掉，观察十分钟，如果误报消失就确认了。解决方式是调整安装角度避开风扇所在的门，或者把那个门的灵敏度压低。风扇的旋转是周期性运动，能量稳定且有节奏，而人不是，所以在软件层面也能做一层过滤——比如要求能量持续超阈值超过两秒才认，这个简单的时间窗过滤能砍掉大量偶发误报。窗帘的处理更简单，把窗帘所在的距离门灵敏度降下来，或者装的时候让视场避开。

漏检的花样少一些。最常见是安装位置正对着床、沙发但角度太偏，人的轮廓没有正对天线；其次是灵敏度整体压得太低；再次是衣服太厚、人和模块之间隔着棉被之类的软材料，回波衰减严重。排查时打开工程模式，让人坐在实际位置，看那个门的能量到底是多少，数字会直接告诉你真相。

宠物误报是绕不开的。猫狗也在动、也在呼吸，雷达从物理上区分不了。如果你的场景必须排除宠物，只能从距离上做文章——把猫狗活动的高度对应的距离门关掉，或者把模块装高