在智能家居和物联网逐渐普及的今天,动手从零打造一个实用且有趣的设备既能提升技能,也能解决真实生活中的小痛点。SplashFlag 的出发点非常简单:当家里有人在泳池里时,以一种低摩擦的方式邀请邻居过来一起玩。把这个社交信号变成物联网项目,不只是玩具,而是把软件工程、嵌入式开发和产品设计结合在一起的完整练习。 概念与目标首先要明确产品的核心体验:快速触达邻居且不打扰隐私。物理旗帜的做法在可视范围和反应速度上有局限,于是用设备来推送通知成为更可靠的方案。设备需要具备直观的视觉提示(如小旗子和字符屏)、简单的复位或隐私按钮、能被邻居轻松接入的 WiFi 配置流程、以及可在远端维护的固件更新能力。
实现这些目标的关键技术点包括 ESP32-S3 系列开发板、MQTT 消息总线、基于 DNS 的 captive portal、以及 OTA 固件更新。 硬件选型与实作建议硬件上我选择了 ESP32-S3 Nano,因为它体积小、支持 WiFi 与 WebSocket、并且支持 OTA 升级。显示采用了常见的 1602 LCD 加上 I2C 转接板,便于减少连线。用于可视化标记的机械部分是一个 9g 微型舵机,驱动一个小旗杆来做提示。为了让终端用户能够在不需要复杂设置的前提下完成 WiFi 配置,设备实现了 captive portal 功能。电源部分用 USB-C 适配器供电,并在舵机电源旁放置 0.1μF 去耦电容保证供电稳定。
如果你复刻或改进设计,注意几个物理细节:小型 LCD 与 I2C 适配板占据空间较多,会影响外壳设计。舵机在启动或高负载时可能会产生瞬间电流尖峰,建议把舵机供电分支做好布线并加入去耦电容。按键的安装宜采用小型快扣结构,既美观又易于装配。 固件架构与可靠性考量在代码层面,我尝试遵循一些基本的工程实践:把主循环保持精简、避免把敏感信息硬编码、将不同功能拆成类或模块来降低耦合度。设备在启动过程中优先尝试连接已保存的 WiFi,如果无法连接则进入 captive portal 模式以便用户通过手机完成配置。网络通信使用 MQTT 作为消息总线,设备以客户端身份订阅消息主题并在收到通知时驱动舵机与 LCD 更新显示内容。
为便于远程维护,固件支持 OTA 更新。设备定期检查 GitHub 的 release 页面是否有新版本,如果有则下载并执行升级。OTA 是强大的功能,但也有风险,建议在实现时保留回滚机制或在首次大规模部署前充分测试,以降低"刷机后变砖"的概率。 WiFi 配置体验的实现原理很多消费者都会遇到宾客网络的登录页面,那背后的原理其实与 DNS 重定向有关。移动设备在连接新网络后通常会尝试访问一些固定的 URL,路由器或接入点可以通过 DNS 拦截这些外部请求并返回本地的配置页面。ESP32 上有现成库可以实现一个小型的 DNS 服务器与 HTTP 服务器,用来搭建 captive portal,让邻居在首次配网时输入家庭 WiFi 名称与密码。
消息传递与 Web 应用设计我在家里运行了一个 mosquitto MQTT Broker,Web 应用通过 WebSocket 与 Broker 交互。这个单页 Web 应用提供简单的消息输入和持续时长选项,默认值覆盖最常用场景。Web 应用通过发布 MQTT 消息实现对所有设备的广播。为了安全性,我在对外访问时使用 Cloudflare Tunnel 并开启了 HTTP 基本认证,这对个人项目来说足够简便但并非最完美的方案。你可以根据需要替换为 OAuth 或其他更完整的认证方案。 开发与调试策略一个好的做法是在设备中识别"开发单元"与"生产单元"的差异。
ESP32-S3 每块板子带有唯一 MAC 地址,可以用于区分是否订阅仅供开发调试的专用主题。这样我无需为测试板写不同的固件,而是通过在运行时判断来拓展功能与日志级别。调试主题可以用来推送临时命令、查看日志或远程触发特定动作。 3D 打印外壳与装配经验外壳采用逐步迭代的方式设计,每完成一项零件就先单独试印与装配,避免一次性打印整件再发现尺寸不合。这样可以节省时间和材料。前面板为 LCD 预留开口,后盖安排舵机与 USB-C 插座的固定位。
注意在设计时预留螺栓孔与走线空间,最开始我忽略了螺栓而打算用卡扣固定,后来为了承重和布线整洁又加了螺丝,浪费了一次设计机会。 在按键的外观设计上,我实现了一个带有卡扣的按钮座,方便把面包板式的微动开关固定在壳体中,实际效果整洁并且易于更换。文字装饰可以通过多次打印不同颜色后粘合实现,虽然手工但相当有成就感。 电气连线与常见故障排查在焊接前务必尽量在面包板上完成功能验证。I2C 显示器通常接在 SDA 和 SCL 引脚,如果遇到字符乱码或不显示,先检查电源电压与接地,再确认 I2C 地址与库是否匹配。舵机异常抖动多半是供电不足或地线接触不良导致。
网络连接不稳定时,检查路由器设置和 captive portal 的 DNS 重定向是否生效。MQTT 消息没有到达设备时,排查 Broker 的端口、认证凭证、以及主题权限设置。 安全性与可改进方向在早期版本中我没有为设备端存储的 WiFi 密码和 MQTT 凭证做强加密,数据被保存在非易失性存储里。理论上可以使用 ESP32 的安全引导与 eFuses 来保护密钥,或者引入硬件安全模块来储存并做加解密。对于服务端 TLS 的漏洞与证书管理,也需要在未来投入精力来完善。若计划向邻居推广或规模化部署,这些安全环节尤其重要。
对于未来迭代,几个方向值得考虑:替换为更窄的 OLED 屏或自定义 PCB 以缩小体积,使用更可靠的认证机制替代基本认证,采用动态证书更新或 ACME 自动签发 TLS 证书以提升传输安全,另外将凭证加密存储并在硬件层面启用防篡改措施都能大幅提升产品的安全性。 总结与动手建议从零开始做一个像 SplashFlag 这样的项目,既能体验从概念到产品的完整过程,也能积累嵌入式、网络与机械设计的实战经验。对初学者的建议是先把最小可行原型做好:先实现 WiFi 连接、MQTT 收发和舵机动作,再逐步增加 captive portal、OTA 与外壳设计。保持模块化的代码和分阶段测试,会让整个工程更可控也更易维护。 代码与资料目前完整的示例代码、硬件清单与 3D 打印文件都托管在 SplashFlag 的 GitHub 仓库,使用 PlatformIO 可以方便地在本地构建并上传固件,后端与 Web 应用采用 Docker 容器化部署并配合 mosquitto MQTT Broker。自己动手实现一次从零到成品的流程,不仅能解决邻里社交的一个小问题,更能为未来更复杂的物联网产品打下扎实基础。
探索中常犯的错误是期待一步到位,实际工程上分步迭代、不断改进才是最可靠的路径。 。
