植物生长灯和种植控制器App怎么做

做植物生长灯和种植帐篷控制器的品牌，很多产品主要卖海外，用户是室内种植爱好者和小型种植户。他们对 App 的要求很实际：光照能按时间自动调，温湿度和 VPD 一眼能看到，几盏灯能一起控，出了问题能马上知道。

我们给一个灯具和种植环境控制器品牌做过 App、管理平台和设备接入服务，下面按这个项目说说这类 App 开发时最容易卡住的几个地方。项目全貌可以看 灯具与种植环境控制器 IoT 平台案例，交付范围可以对照 植物生长灯 App 开发。

两类设备，一个 App

这个品牌下有两类设备：一类灯具直接走 MQTT；另一类环境控制器用的是私有二进制协议，通过 TCP 连接。很多品牌都是这样，老产品用老协议，新产品换了新方案，但用户希望在同一个 App 里管所有设备。

我们没有去改设备协议，而是用 Go 写了一个桥接服务：负责 TCP 连接管理、解析控制器的二进制协议、双向转发指令、检测传感器告警，还带了监控面板和黑名单。经过桥接以后，平台和 App 看到的都是统一的 MQTT 消息，不需要关心设备底层用的是什么协议。

如果你手上也有一批走私有协议的老设备，这种"桥接服务 + 统一消息"的做法基本是改动最小的方案。

蓝牙和 Wi-Fi 都要能控制

种植帐篷里 Wi-Fi 信号不一定好，有的用户也不想把设备连到网上。所以 App 要同时支持蓝牙近场控制和 Wi-Fi 远程控制。

难点不在连接本身，而在两种方式的控制逻辑要一致。我们在 uni-app 里自研了蓝牙通讯库，把蓝牙和 Wi-Fi 两条通道都映射到同一套指令模型上。调光、风扇档位、模式切换这些操作，界面只写一遍，底层按当前连接方式发出去。

蓝牙部分的通用做法，可以参考 蓝牙APP开发怎么做。

控制项要和固件逐条对齐

生长灯和控制器的 App 功能看起来不多，但每一项都要和固件对齐细节：

• 多通道调光：通道数量、调光范围、步进
• 风扇档位和手动 / 定时模式
• 过温保护：触发温度、保护动作、恢复条件
• 缓升缓降：开灯和关灯时亮度渐变的时长
• 分组控制：多台设备同时执行同一组设置

我们的经验是先把这些整理成一张指令表，每条写清楚参数、单位、取值范围和设备回执，App 和固件都按这张表开发。

定时和分组，以谁为准

这是种植类 App 最容易出问题的地方。定时开关灯，是设备自己按时执行，还是云端到点下发指令？

设备本地执行的好处是断网也照样运行，种植用户最怕的就是网络一断，灯不开了。云端执行的好处是改起来灵活，但要处理设备离线时指令怎么补发。分组控制也是同样的问题。

这件事要在首期就定下来，并且 App 界面要让用户看得出当前的定时是保存在设备上还是云端。

在线状态要三方对账

上线后我们遇到过一个典型问题：数据库显示设备在线，但实际早就断开了，用户在 App 里点了半天没反应。

原因一般是几种情况叠加：网络异常时断开消息丢了，服务重启后状态没刷新，旧消息被重新处理把状态改回了"在线"。我们最后的方案是让 App、后台和桥接服务用同一套在线判断依据，并做了三方对账，专门处理消息丢失、服务重启和旧消息重放。

在线状态看起来是小功能，但直接影响用户对产品的信任，值得在设计阶段就想清楚。

VPD 统计

室内种植用户普遍会看 VPD（饱和水汽压差），它由温度和相对湿度算出来，用来判断环境是否适合作物蒸腾。我们的 App 同时显示温度、湿度和 VPD，平台把传感器数据写入 TDengine 时序库，按时间段统计。计算公式和代码可以看 智慧农业监测平台怎么立项。

16 种语言

这个 App 支持 16 种语言。做法不复杂：从第一版就把所有文案抽成语言包，界面布局给长文本预留空间。之后增加语言，主要就是翻译和校对。出海项目要准备的其他内容，可以看 海外物联网 App 开发。

常见问题

设备只有 Wi-Fi，没有蓝牙，可以吗？

可以。只做 Wi-Fi 时，App 通过云平台远程控制，配网环节需要单独设计。是否要加蓝牙，主要看用户是否需要断网时也能控制。

能接入已经在卖的老设备吗？

只要能拿到协议文档或抓包数据，老设备可以通过桥接服务接入，设备侧通常不用改固件。

种植场景能做联动吗？比如湿度高了自动开风扇？

可以。联动规则可以放在设备本地或云端，取舍和定时一样，主要看断网时是否还要继续执行。

想把公版 App 换成自有 App，要怎么做？

要先确认模组固件能否接入自有云。具体可以看 公版 App 什么时候该换成自有 App，或者把设备情况 发给我们 一起评估。