一个开源项目把工业水位监测的成本砍到脚踝价。捷克开发者Martin Chlebovec的Watmonitor，用HTML5+PHP+Bootstrap搭了个轻量网页，却能接ESP32、树莓派Pico W甚至老式Arduino，超声波或激光测距的数据直接进MySQL，还能画成实时图表。
这套系统的核心逻辑很产品经理：硬件端只管测距和发数据，所有复杂计算扔给服务器。传感器从盖子往下打，测的是" lid到水面"的差值，但也能反过来从底部往上测真实水位。体积计算、历史曲线、报警阈值——全在网页端搞定。
1张卡片解锁：NFC/RFID的隐藏玩法
最新版本加了NFC/RFID触发。不是身份认证那种老套路，是物理场景里的"一键拉数据"。巡检人员拿卡片往读卡器上一贴，系统立即调取最近24小时的水位波动，不用摸手机、不用输密码。
这个设计踩中了工业现场的痛点：化工厂、污水处理站、粮仓这些地方，手套是厚的、屏幕是湿的、指纹是识别不了的。卡片是实体按键的替代品，却比按键便宜、比二维码耐造。
技术实现上，读卡器通过回调接口向PHP后端发请求，带token鉴权。同一张卡片可以绑定不同功能——短触查实时数据，长触导出周报，组合刷还能切换传感器组。Chlebovec在文档里埋了个细节：读卡器的UID白名单存在单独的数据表，和主业务数据物理隔离，就算前端被渗透，卡片权限也动不了。
硬件兼容清单：从2美元芯片到工业PLC
Watmonitor的硬件支持列表长得像供应链白皮书。WiFi阵营有ESP32（带RMII以太网的版本也认）、ESP8266、树莓派Pico W；有线阵营覆盖Wiznet W5100/W5500硬件协议栈、ENC28J60软件协议栈。最狠的是还支持"反向接入"——工业PLC或液位计只要能把数据HTTP POST过来，带个鉴权token就能写进数据库。
这种开放性在同类项目里少见。多数水位监测系统要么绑死自家硬件，要么收年费开API。Watmonitor的MIT许可证允许商业使用，代码仓库里甚至有个Node-RED流模板，专门给不懂PHP的工程师接Home Assistant。
数据可视化用了三件套：JustGage做仪表盘、Raphaël画矢量图、ApexCharts跑时间序列。Chlebovec没选更时髦的D3.js，理由是"Bootstrap 5.3.8的工程师看得懂"。技术选型服务于维护者，而不是演示效果。
第三方平台的" Trojan Horse "策略
系统预留了Ubidots、ThingSpeak、ThingsBoard的直连接口，也支持MQTT进Loxone、Home Assistant。但有意思的是，这些集成都是"拉模式"优先——Watmonitor主动从第三方取数据，而不是把自己的数据推出去。
这个设计选择暴露了Chlebovec的野心：他想让Watmonitor成为数据中枢，而不是边缘节点。第三方平台在这里是数据源，主控权在本地服务器。对于担心云服务商锁定的工厂IT部门，这个架构比"全上云"的方案好卖得多。
实际部署案例里，有个捷克酿酒厂用Watmonitor接了12个发酵罐的液位计，数据存在本地MariaDB，同时推一份只读副本到ThingSpeak给远程顾问看。NFC卡片发给夜班操作工，刷卡就能看到哪个罐该补料了。
开源硬件的"样板间"困境
项目文档 completeness 很高，但有个裂缝：示例代码全是Arduino IDE风格的setup()/loop()，对用PlatformIO或ESP-IDF的开发者不够友好。GitHub Issues里有条2024年3月的反馈，说ESP32-S3的RMII以太网初始化代码在特定PHY芯片上会挂，Chlebovec回复说"需要社区贡献测试"。
这大概是开源工业软件的通病——作者能覆盖80%的场景，剩下20%的边角案例需要用户自己填坑。好处是代码结构够简单，PHP端核心就4个文件：接收数据、查询历史、管理传感器、处理NFC回调。有LAMP栈经验的工程师半天能读透。
版本迭代节奏也很有意思。2023年主要补可视化图表，2024年上半年重点做第三方平台对接，NFC功能是2024年Q3才加进来的。Chlebovec在Release Note里写得很直白："有人愿意付咨询费做这个功能，做完就开源了。"
现在仓库里有个讨论串在吵要不要加LoRaWAN支持。反对方的理由是"会显著增加代码复杂度"，支持方甩了个非洲农村水井监测的用例。Chlebovec的最后回复是："等有人付咨询费，或者有人提交能过Code Review的PR。"
这个开源项目的生存模式，大概比它的技术架构更值得同行琢磨。
热门跟贴