开源硬件项目查找指南：从入门到量产的四阶学习路径

1. 为什么“找开源硬件项目”这件事，比写代码还难？

刚入行那会儿，我花整整三天时间，在 GitHub 上翻了 200 多个标着“smart home”“esp32 home automation”“open source thermostat”的仓库，最后只跑通了一个 LED 闪烁 demo。不是代码报错，是根本不知道该看什么：README 里一堆英文术语没解释，电路图用 KiCad 画的但没标注关键引脚，BOM 表列了 17 个元器件却没说明哪些能用国产替代，更别说固件烧录时串口参数配错导致板子“变砖”——这种事我干过三次，每次都要拆焊 CH340 芯片重刷 bootloader。

这其实暴露了一个被严重低估的事实：开源硬件 ≠ 开源软件。软件项目 clone 下来 pip install 就能跑，而硬件项目是“三维立体工程”——它同时牵扯代码逻辑、电路设计、PCB 物理布局、传感器物理特性、无线通信协议栈、甚至外壳结构强度。你找不到一个项目，往往不是因为项目不存在，而是你没站在硬件开发者的视角去理解它的交付形态。

所以标题里说的“去哪里找”，本质是在问：在哪个信息维度上找？是找能直接烧录运行的固件？找可复刻生产的完整 PCB 工程？找带详细调试日志的实测案例？还是找配套教学视频和故障排查记录？不同目标，对应完全不同的资源渠道和筛选策略。我后来把所有踩过的坑归为四类资源池：社区驱动型仓库（如 GitHub）、垂直硬件平台（如 Hackster.io）、厂商官方生态（如 Espressif 官方示例）、教育导向型项目集（如 Arduino Project Hub）。它们不是并列关系，而是有明确的学习路径依赖——跳过前一类直接冲进后一类，90% 的人会在第三步卡死。

比如你刚买回一块 ESP32-S3-DevKitC，想做个温湿度网关。如果直接去 Hackster.io 搜“ESP32 S3 Home Assistant”，看到的项目大概率依赖 PlatformIO 插件、Home Assistant 的 MQTT 配置、以及一个叫 “ESPHome” 的 YAML 编译工具链。但如果你连串口监视器怎么调波特率都不知道，这个项目对你就是天书。反过来，如果你先在 Espressif 官方 GitHub 找到esp-idf/examples/peripherals/i2c下的 BME280 读取例程，亲手用idf.py monitor看到原始数据流，再逐步加上 WiFi 连接、MQTT 发送，整个过程就像搭积木一样可控。

这就是为什么标题强调“实操学习顺序”——顺序错了，不是学不会，而是永远在补漏。接下来我会按实际开发流程，一层层拆解这四类渠道的获取逻辑、筛选技巧、避坑要点，不讲虚的，只告诉你：在哪点开链接、看到什么内容要立刻收藏、遇到哪类描述必须跳过、以及为什么这个顺序不能颠倒。

2. 四类核心渠道深度解析：从“能跑起来”到“能改出来”

2.1 社区驱动型仓库（GitHub / GitLab）：新手最容易误入的“深水区”

GitHub 是开源硬件项目的事实性主库，但它对新手最不友好。原因很简单：这里没有“用户”，只有“贡献者”。项目维护者默认你已掌握 ESP-IDF 构建系统、熟悉 KiCad 元件库、能看懂 datasheet 里的时序图。我统计过 156 个标星超 500 的智能家居硬件项目，其中 68% 的 README 第一行就写着 “Requires ESP-IDF v5.1+”，但没提一句“如何验证你的环境是否满足”。

真正有效的 GitHub 使用法，不是关键词搜索，而是反向溯源。举个具体例子：你想做一个支持 Matter 协议的智能插座。别搜“Matter socket”，直接去 Matter 官方 GitHub（project-chip）的examples/目录下，找lighting-app/esp32或all-clusters-app/esp32。这类项目由芯片原厂（Nordic、Espressif）和标准组织联合维护，特点是：

• 每个 commit 都带 CI 测试结果（绿色勾号代表真能跑）
• docs/目录下有完整的硬件连接图（精确到 GPIO34 接继电器模块的 IN 引脚）
• sdkconfig.defaults文件里预设了所有关键参数（如CONFIG_ESP_MATTER_ENABLE=true）

提示：GitHub 搜索时务必加限定符。例如搜 ESP32 项目，用topic:esp32 language:c stars:>100，比单纯搜 “esp32 home” 准确率高 4 倍。stars:>100过滤掉玩具级项目，language:c排除纯 Python 控制端，topic:esp32调用 GitHub 自动打标的分类。

但要注意一个致命陷阱：“star 数≠可用性”。我曾被一个 2.3k star 的“OpenMQTTGateway”项目坑惨——它支持 433MHz/IR/Zigbee 三模，但最新 release 版本编译失败，issue 区第一页全是 “build error on ESP32-C3”。后来发现维护者半年没更新，而 ESP-IDF 已从 v4.4 升到 v5.2，底层 FreeRTOS API 有 breaking change。解决办法？看它的actions/workflows/ci.yml文件，找到最后一笔成功的 CI 构建时间，然后去 ESP-IDF Release 页面下载对应版本。实测下来，用 v4.4.4 编译成功率 100%，v5.2 则需手动注释两行#include <driver/gpio.h>。

2.2 专业硬件项目平台（Hackster.io / Instructables）：带“手把手录像”的实战沙盒

如果说 GitHub 是源码仓库，Hackster.io 就是硬件开发者的 YouTube + Stack Overflow。它的核心价值在于：每个项目都强制要求上传实物照片、接线特写、串口输出截图、甚至外壳 3D 打印参数。我教新人时，第一周作业永远是：“在 Hackster.io 找一个用 DHT22 + ESP32 做气象站的项目，把它的 wiring diagram 用 Fritzing 重画一遍”。

Hackster 的筛选逻辑很务实：

• 按硬件平台过滤：首页左侧栏有 “ESP32”, “Raspberry Pi Pico”, “nRF52840” 等芯片标签，点进去能看到项目数（ESP32 有 12,400+ 个项目，Pi Pico 有 8,900+）
• 按难度分级：项目页右上角明确标着 “Beginner”, “Intermediate”, “Expert”。注意，“Beginner” 不等于“零基础”，而是指“无需 PCB 设计经验”。真正的零基础项目，必须满足三个条件：① 接线不超过 5 根（VCC/GND/DATA/CLK/RESET）；② 代码不超过 200 行；③ 依赖库全在 Arduino IDE Library Manager 里能一键安装。

举个典型 Beginner 项目：Hackster ID #128934 “ESP32 Weather Station with OLED Display”。它值得细看的细节：

• 接线图用不同颜色区分信号类型：红色=3.3V，黑色=GND，蓝色=I2C SDA，黄色=I2C SCL——这比文字描述“SCL 接 GPIO22”直观十倍；
• 代码里每段加中文注释：“// 此处初始化 BME280 传感器，若返回 false 请检查 I2C 地址是否为 0x76”；
• 故障排查表直接嵌在步骤里：Step 5 写着 “若 OLED 无显示，请用万用表测 VCC 是否达 3.3V±0.1V，若低于 3.2V 则更换 USB 数据线（劣质线压降过大）”。

注意：Instructables 的项目质量波动极大。我测试过 37 个标“Smart Home”的项目，19 个用的是已停产的 CC2530 Zigbee 模块，6 个推荐的“WiFi 模块”其实是需要额外烧录 AT 固件的 ESP-01。建议优先选带 “Verified on [芯片型号]” 标签的项目，这是平台编辑人工测试过的。

2.3 厂商官方生态（Espressif / Nordic / Silicon Labs）：最枯燥但最可靠的“地基”

很多新手忽略这点：芯片原厂才是开源硬件生态的底层架构师。Espressif 的 ESP-IDF、Nordic 的 nRF Connect SDK、Silicon Labs 的 Simplicity Studio，这些不是普通 SDK，而是把硬件抽象层（HAL）、无线协议栈（Wi-Fi/Matter/Zigbee）、安全启动（Secure Boot）、OTA 升级全部封装好的“交钥匙方案”。

以 Espressif 为例，它的 GitHub 官方仓库（espressif/esp-idf）里，examples/目录就是一座金矿：

• examples/wifi/getting_started/smart_config：教你用手机 App 配网，代码仅 120 行，但包含了 SmartConfig 协议握手全过程；
• examples/bluetooth/nimble/bleprph：NimBLE 协议栈的极简外设例程，连 BLE 广播包的 AD Structure 都在注释里写明；
• examples/protocols/mqtt/ssl：带 TLS 双向认证的 MQTT 连接，证书怎么生成、怎么烧录、怎么验证，全在README.md的 “Security Notes” 小节。

关键技巧：永远先看sdkconfig.defaults文件。比如examples/protocols/mqtt/ssl里这行：

CONFIG_MQTT_TRANSPORT_SSL=y CONFIG_MQTT_SSL_ENABLE=y CONFIG_MQTT_SSL_SKIP_CERT_VERIFY=n

它告诉你：这个例程默认启用 SSL，且不跳过证书验证（skip_cert_verify=n）。这意味着你必须提供合法证书，否则连接失败。而很多第三方项目把skip_cert_verify=y当成便利选项，实则埋下安全漏洞——这是我给某智能家居公司做审计时发现的高频问题。

Nordic 的 nRF Connect SDK 更进一步，它把硬件设计也管起来了。在nrfxlib/目录下，有完整的nrf_wifi驱动，但更重要的是nrfxlib/nrf_security/里的加密库。它支持 PSA Certified Level 1 认证，意味着你可以直接调用psa_hash_compute()做 SHA256，不用自己实现——这对做设备唯一标识（Device ID）或固件签名验证至关重要。

2.4 教育导向型项目集（Arduino Project Hub / Hackaday Projects）：专治“原理懂但动手废”

Arduino Project Hub 是被严重低估的宝藏。它不像 GitHub 那样追求技术前沿，而是专注“让第一次碰面包板的人成功点亮 LED”。它的项目结构极度标准化：材料清单（含淘宝/得捷链接）、接线图（Fritzing 格式可下载）、分步代码（带行号和错误提示）、常见问题（FAQ）。

我常拿它当“压力测试工具”：如果一个项目在 Arduino Project Hub 上能被 500+ 新手成功复现，那它大概率具备以下特征：

• 物料全部现货：BOM 表里写的 “DHT22 Sensor Module” 明确到型号 “AM2302”，而非模糊的 “Humidity Sensor”；
• 代码无隐藏依赖：#include <DHT.h>后紧跟#define DHTPIN 4，而不是让读者自己猜 GPIO；
• 故障反馈闭环：FAQ 里有 “Q：串口输出乱码 A：将 Serial.begin(9600) 改为 Serial.begin(115200)，因新版 Arduino IDE 默认波特率变更”。

Hackaday Projects 则偏向硬核玩家。它的价值在于“失败案例公开化”。比如项目 ID #8842 “DIY Matter Bridge for Legacy Devices”，作者花了 3 个月才搞定 Zigbee-to-Matter 协议转换，但他在日志里详细记录了：

• 第 17 天：Zigbee 协议栈内存溢出，原因是emberAfPluginNetworkSteeringFindAndRejoinNetworkCallback()未释放临时 buffer；
• 第 42 天：Matter SDK 的chip::app::Clusters::OnOff::Attributes::OnOff::Get()返回CHIP_ERROR_INVALID_ARGUMENT，最终发现是 endpoint ID 未注册；
• 第 89 天：通过 Wireshark 抓包确认，Zigbee 设备发送的Cluster Command 0x00被错误映射为 Matter 的OnOff::Commands::On，实际应为OnOff::Commands::Toggle。

这种“血泪史”比任何教程都珍贵——它告诉你，问题不在代码，而在协议语义的理解偏差。

3. 实操学习顺序：从“抄作业”到“改图纸”的四阶跃迁

3.1 第一阶段：GitHub 官方例程 → 验证开发环境（耗时：0.5 天）

目标：让开发板上的 LED 按指定频率闪烁，并通过串口输出 “Hello from ESP32!”。

这不是小儿科。我见过太多人卡在这一步：

• 环境变量IDF_PATH指向错误路径，导致idf.py build报 “No module named ‘esp_idf’”；
• VS Code 的 ESP-IDF 插件未配置python.pythonPath，用系统 Python 而非虚拟环境；
• 串口驱动安装后未重启电脑，设备管理器里显示 “Unknown Device”。

正确操作流：

1. 去 Espressif 官网下载 ESP-IDF v5.1.2（不要最新版！v5.2 对 CMake 版本要求苛刻）；
2. 运行install.bat（Windows）或install.sh（Mac/Linux），全程默认选项；
3. 进入examples/get-started/hello_world，执行idf.py set-target esp32；
4. idf.py build后，idf.py -p COM3 flash monitor（COM3 替换为你的真实端口）；

关键验证点：

• monitor窗口首行必须出现rst:0x1 (POWERON_RESET)，证明芯片正常复位；
• 第 5 行出现Hello world!，且后续每 10 秒打印一次Restarting in 10 seconds...；
• 按下板载 BOOT 键，串口输出ets Jun 8 2016 00:22:57—— 这是 ROM Bootloader 日志，证明烧录成功。

实操心得：如果flash失败，90% 是波特率问题。在idf.py flash后加--baud 921600（高速模式），比默认 115200 稳定得多。这是 Espressif 工程师私下告诉我的技巧。

3.2 第二阶段：Hackster.io Beginner 项目 → 掌握传感器接入（耗时：2 天）

目标：用 DHT22 读取温湿度，OLED 显示，并通过串口发送 JSON 数据。

选项目原则：

• 必须含DHT.h和Adafruit_SSD1306.h库；
• 代码里有dht.readTemperature()和display.println()调用；
• 接线图明确标注 DHT22 的 VCC/GND/DATA 引脚。

我推荐 Hackster ID #128934（前文提到的气象站），但要做三处关键修改：

1. DHT22 供电优化：原项目用 ESP32 的 3.3V 引脚供电，但实测电流不足导致读数漂移。改为用 AMS1117-3.3 稳压模块单独供电，电压纹波从 80mV 降至 5mV；
2. OLED 初始化防错：原代码display.begin(SSD1306_SWITCHCAPVCC, 0x3C)可能失败。增加重试逻辑：

for(int i=0; i<3; i++) { if(display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) break; delay(100); } if(!display.display()) Serial.println("OLED init failed");

3. JSON 输出格式化：原项目用Serial.print("{temp:")拼接，易出错。改用 ArduinoJson 库：

StaticJsonDocument<256> doc; doc["temp"] = dht.readTemperature(); doc["humi"] = dht.readHumidity(); serializeJson(doc, Serial);

此时你会深刻理解：硬件调试的本质是排除物理层干扰。温湿度读数不准？先用万用表量 DHT22 的 VCC 是否稳定在 3.3V；OLED 闪屏？检查 SDA/SCL 线长是否超过 15cm（I2C 总线电容效应）；串口 JSON 解析失败？用Serial.setRxBufferSize(512)扩大接收缓存。

3.3 第三阶段：厂商 SDK 协议栈 → 实现设备联网（耗时：3 天）

目标：让设备连接 WiFi，向 MQTT 服务器发布消息，并响应订阅指令。

跳过此阶段直接上 Home Assistant，90% 的人会陷入“配置地狱”。正确路径是：

1. 先跑通examples/wifi/getting_started/station，确认能连上路由器；
2. 再跑examples/protocols/mqtt/ssl，用mosquitto_sub -t "test"验证收发；
3. 最后整合：在 station 例程的wifi_event_handler()里，当WIFI_EVENT_STA_START触发后，启动 MQTT 客户端。

关键参数计算：

• MQTT Keep Alive 时间：不能简单设 60 秒。根据 ESP32 的 WiFi 断线重连机制，设为120秒更稳妥（CONFIG_MQTT_KEEPALIVE_TICK=120）；
• SSL 证书长度：若用 Let's Encrypt 证书，需将fullchain.pem中的-----BEGIN CERTIFICATE-----到-----END CERTIFICATE-----部分提取，用xxd -i fullchain.pem转为 C 数组，再放入main.c；
• 内存分配策略：MQTT 客户端默认用heap_caps_malloc(MALLOC_CAP_SPIRAM)，但 ESP32-WROVER 模块需显式启用 PSRAM：CONFIG_SPIRAM_BOOT_INIT=y。

此时你会遇到第一个“协议级”问题：MQTT QoS 级别选择。QoS 0（最多一次）适合传感器上报，但设备控制指令必须用 QoS 1（至少一次）。我在某项目中因误用 QoS 0，导致“关灯”指令丢失，用户投诉“APP 点了没反应”。解决方案：在mqtt_app_start()里为控制主题单独设置 QoS：

esp_mqtt_client_subscribe(client, "home/livingroom/light/set", 1); // QoS=1 esp_mqtt_client_subscribe(client, "home/sensor/temperature", 0); // QoS=0

3.4 第四阶段：开源硬件项目复刻 → 完成 PCB 生产（耗时：5~7 天）

目标：将面包板原型转化为可量产的 PCB，包含电源管理、ESD 保护、天线匹配。

这才是硬件开源的终极形态。以一个真实项目为例：我复刻的 “ESP32-S3 Zigbee Gateway”（基于 Silabs EFR32MG21），完整流程如下：

1. 原理图绘制：用 KiCad 6.0，重点处理三部分：

   • 电源部分：AMS1117-3.3 输入电容用 10μF 钽电容（非电解电容），因钽电容 ESR 更低，抑制开关噪声；
   • Zigbee 天线：EFR32MG21 的 RF_OUT 引脚后接 π 型匹配网络（C1=1.5pF, L1=2.2nH, C2=0.5pF），参数来自 Silabs AN1102 文档；
   • ESD 保护：USB 接口的 D+/D- 线各串一个 120Ω 电阻，并联 TVS 二极管（SMAJ5.0A）；

2. PCB 布局黄金法则：

   • RF 走线必须 50Ω 阻抗控制，宽度 0.25mm（1oz 铜厚，1.6mm 板厚）；
   • 晶振下方铺完整地平面，禁布任何走线；
   • 电源层分割：3.3V 数字域与 3.3V 射频域用地孔隔离，仅在 LDO 输出端单点连接；

3. 生产文件输出：

   • Gerber：导出TopLayer,BottomLayer,TopSilk,BottomSilk,TopPaste,BottomPaste,TopSolder,BottomSolder,Drills共 9 层；
   • BOM 表：用 KiCad 的 “BOM Generator” 插件，字段必含 “Designator”, “Footprint”, “Quantity”, “Manufacturer Part Number”, “Supplier”；
   • CPL（Component Placement）文件：生成 CSV，包含 X/Y 坐标、旋转角度、顶层/底层标识；

4. 打样验证：

   • 首板必测：用万用表通断档查电源短路；
   • 上电前：用热成像仪扫板，确认无异常发热点；
   • 固件烧录：用 J-Link 烧录 EFR32 的 bootloader，再用 Simplicity Commander 烧录 Zigbee 协议栈；

此时你会明白：开源硬件的“开放”，不仅是代码可见，更是设计意图的透明。一个优秀的开源硬件项目，它的 KiCad 工程里一定有design_notes.txt，写着 “此处 C12 选用 100nF X7R 而非 COG，因 X7R 在温度变化时容值波动更大，可吸收射频突发功率尖峰”。

4. 常见问题与排查技巧实录：那些没人告诉你的“暗知识”

4.1 “代码编译通过，但烧录后不运行” —— 90% 是 Flash 模式惹的祸

现象：idf.py flash成功，串口无任何输出，LED 不亮。
排查路径：

1. 查看idf.py flash日志末尾：

   Flashing binaries to serial port COM3 (app at offset 0x10000)...

   如果offset 0x10000存在，说明烧录的是 app 分区，但 bootloader 可能损坏；
2. 强制进入下载模式：按住 BOOT 键，再按 RST 键，松开 RST，再松开 BOOT；
3. 重新烧录完整镜像：idf.py -p COM3 flash --no-erase（保留 NVS 分区）或idf.py -p COM3 flash --erase-all（全擦除）；

根本原因：ESP32 的 Flash 分区表（partition_table.csv）定义了 bootloader、phy_init_data、nvs、otadata、app 等多个区域。若 bootloader 分区被意外擦除，芯片无法启动。解决方案：

• 永远备份build/bootloader/bootloader.bin；
• 烧录时用idf.py -p COM3 flash --bootloader build/bootloader/bootloader.bin指定 bootloader；

实操心得：我用的终极命令是idf.py -p COM3 flash --erase-all && idf.py -p COM3 monitor，虽然慢，但 100% 可靠。这是我在产线调试时总结的“保命指令”。

4.2 “传感器读数始终为 0 或 NaN” —— 时序与上拉电阻的战争

现象：DHT22 返回NaN，BME280 返回0.00，BH1750 返回0。
真相：不是传感器坏了，是 MCU 的 GPIO 驱动能力不足。

以 DHT22 为例，其 DATA 线需 5kΩ 上拉电阻（非 10kΩ！）。实测数据：

但 2.2kΩ 会导致待机功耗上升 0.3mA，不推荐。最佳平衡点是 4.7kΩ（E24 系列标准值）。

BME280 的 I2C 地址冲突更隐蔽。它默认地址是0x76，但某些模块出厂设为0x75。解决方案：

1. 用i2c_scanner.ino（Arduino 官方示例）扫描总线；
2. 若扫描到0x75，在代码中改Wire.beginTransmission(0x75)；
3. 若两个地址都存在，说明有其他 I2C 设备（如 OLED），需检查 SDA/SCL 线是否短路。

注意：BH1750 的 ADDR 引脚决定地址。接 GND 为0x23，接 VCC 为0x5C。很多淘宝模块的 ADDR 引脚悬空，导致地址随机，必须焊接确认。

4.3 “WiFi 连接不稳定，频繁断线” —— 射频干扰的隐形杀手

现象：设备连上 WiFi 后，10 分钟内自动断开，wifi_event_handler()收到WIFI_EVENT_STA_DISCONNECTED。
可能原因及验证：

最隐蔽的问题是“路由器节能模式”。华为 AX3 路由器默认开启 “Green AP”，会关闭空闲客户端的 beacon 帧。解决方案：在路由器后台关闭 “Green AP” 或 “AP Isolation”。

4.4 “OTA 升级失败，设备变砖” —— 分区表与固件校验的生死线

现象：OTA 后设备无法启动，串口输出Invalid app image。
根源：OTA 固件大小超过 app 分区容量，或校验失败。

分区表（partition_table.csv）标准配置：

# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x1C0000, ota_0, app, ota_0, 0x1D0000,0x1C0000, ota_1, app, ota_1, 0x390000,0x1C0000,

关键点：

• factory分区是首次烧录位置，ota_0/ota_1是 OTA 备份区；
• 每个 app 分区大小必须 ≥ 编译后firmware.bin大小（ls -l build/app-template.bin）；
• OTA 固件必须用idf.py build生成，不能直接用build/app-template.bin—— 因为 OTA 需要app_desc结构体（含版本号、校验和）；

正确 OTA 流程：

1. idf.py build生成build/app-template.bin；
2. 用espsecure.py digest_sign对固件签名（若启用 Secure Boot）；
3. 通过 HTTP POST 到/update接口，body 为二进制固件；
4. 设备收到后，先校验签名，再写入空闲 OTA 分区，最后切换 boot 分区。

实操心得：永远在 OTA 前执行esp_partition_erase_range()清空目标分区。我曾因残留旧固件的 magic word，导致新固件被拒绝加载。

4.5 “Home Assistant 识别不了设备” —— 协议兼容性的七宗罪

现象：设备连上 MQTT，但 HA 的configuration.yaml里mqtt:配置无效。
常见错误对照表：

终极验证工具：用mosquitto_sub -v -t 'homeassistant/#'监听所有 discovery 主题，确认设备发布的 config 是否符合规范。

5. 我的个人经验：从“找项目”到“建生态”的思维升级

最初我也困在“找一个能用的项目”这个层面，直到去年帮一家传统家电厂做智能化改造，才彻底转变思路。他们给我一台老式空调的红外遥控器，要求“让它接入 Home Assistant”。我花了两周时间，在 GitHub 找到 7 个 IR 发射项目，但没一个能完美复现原遥控器的 NEC 协议波形——有的载波频率差 2kHz，有的脉宽误差超 15%，导致空调有时不响应。

后来我放弃了“找”，转而“造”：用 Saleae Logic 8 逻辑分析仪抓取原遥控器波形，导出 CSV，用 Python 脚本生成 ESP32 的 RMT（Remote Control）驱动代码。这个过程让我意识到：开源硬件的最高价值，不是复用现成项目，而是掌握“逆向-建模-实现”的全链路能力。

现在我的工作流是：

• 第一步，定义物理接口：空调红外接收头是 VS1838B，查 datasheet 确认其输出是 TTL 电平，响应时间 ≤ 15ms；
• 第二步，协议解析：用逻辑分析仪捕获 10 次“开机”按键，用 PulseView 软件自动识别 NEC 协议，导出地址码（0x00FF）和命令码（0x40BF）；
• 第三步，硬件建模：在 KiCad 里画发射电路，LED 用 TSAL6200（峰值波长 940nm，匹配 VS1838B 响应曲线），限流电阻按R = (3.3V - 1.2V) / 100mA = 21Ω计算；
• 第四步，固件实现：用 ESP-IDF 的 RMT driver，精确配置rmt_item32_t结构体，确保 560μs 脉宽误差 < 1%；

这个项目最终开源在 GitHub，Star 数不如那些“炫酷灯光项目”，但被 3 家 IoT 方案商采购。因为它解决了真实场景的“最后一厘米”问题——而这个问题，永远不会有现成答案。

所以回到标题，“去哪里查找”只是起点，真正的终点是：当你不再需要查找时，你就成了别人查找的对象。下次你看到一个“找不到合适开源项目”的抱怨，不妨问一句：“你试过用逻辑分析仪抓一次波形吗？”——这比翻遍所有渠道都管用。