企业官网建设流程全解析

1. 从"定时浇水"到"看天浇水"：这个项目到底在解决什么问题

没有养过花的人可能很难理解，给花浇水居然也会成为一种焦虑。定时器浇水，晴天怕不够，雨天怕过量；出门旅行更不敢走太久，生怕系统在暴雨后又按部就班地浇了一遍。我最初做 Plant Intelligence 这个项目，就是因为受够了这种"掐着秒表过日子"的浇水方式。它的核心其实就一句话：让花园自己看天、自己决定今天浇不浇、浇多少。

项目名字里的 "checks the sky" 不是夸张修辞，而是这个系统真正的运转方式。它保存的不只是一套时间表，而是把天气预报、太阳辐射、气温、风速和土壤墒情全部拉进决策过程。也就是说，它的工作方式更像你出门前先抬头看天、再决定带不带伞，而不是像标签机上固定打出的日期那样一成不变。

如果你也想做一套自动灌溉系统，或者家里已经有定时灌溉设备但总觉得效果不如预期，这篇复盘应该对你有用。我会从"为什么要看天"讲起，然后给完整硬件方案、天气数据接入算法、水路施工细节，最后是连续两个月的真实运行数据和一大堆踩坑记录。

1.1 定时器与湿度传感器，各有各的死穴

先说定时器为什么不够用。

大多数市售的定时浇水设备，思路非常简单：设定好每周浇几天、每天几点浇、一次浇多少分钟，然后机器就严格按照这个计划执行。如果昨天刚下了一场透雨，它第二天照样打开电磁阀；如果今天高温暴晒、蒸腾量是平时的两倍，它也不会因此多浇哪怕一分钟。这种系统对"环境变化"是完全失明的，它只有时间概念，没有天气概念。

那有人会说了：加个土壤湿度传感器不就能闭环了吗？确实，带湿度反馈的自动灌溉是下一步，但它依然有一个天然缺陷——滞后。传感器的逻辑永远是"土壤干了才开阀"，而植物在"土壤变干"到"传感器报警"这个时间窗口内，已经开始承受水分胁迫。叶片萎蔫了再浇水，其实已经晚了半拍。再加上湿度传感器测的只是探针周围那一小块土，浇过水后局部湿度上升很快，真实根系区域可能还是干的，判断经常失真。

这种情况和"看天"的逻辑差距在哪里？看天是一种预测。你不是等雨淋到头上才撑伞，而是看到天色不对就提前准备好；你不是等植物蔫了才去浇水，而是根据蒸发趋势和天气预报，在土壤接近萎蔫点之前就把水补上。预测式灌溉，英文里叫 predictive irrigation，这才是 Plant Intelligence 这个项目的底层思路。

1.2 "checks the sky" 的具体含义：把决策拆成两个问题

我在设计系统时，把"怎么浇水"拆成了两个独立的问题：今天要不要浇，以及今天浇多少。

"要不要浇"主要由三件事决定：当前土壤湿度是否低于阈值；未来 12 到 24 小时有没有明显降雨；最近一次下雨是否真的把根系层浇透了。比如预报说未来几小时有暴雨，土也还没干透，那系统就算检测到表层偏干，也会选择等待，而不是白白把水浇进雨水里。

"浇多少"则复杂一些，需要考虑植物的蒸腾需求和土壤的蒸发量。同样 30°C 的天气，如果晴天暴晒，植物一天可能消耗 5 到 6 毫米的水层；如果阴天且没有风，可能只要 2 毫米。这中间的差值，就是系统需要通过额外灌溉来补齐的部分。

所以你看，浇水的本质不是"固定每天执行 N 分钟"，而是每天动态计算一个"水账"：土壤里存了多少、降雨补充了多少、蒸发和蒸腾消耗了多少、缺口还有多少。只要能把账算清楚，浇水就不再是玄学，而是一道简单的数学题。后面几节我会一步步展开这套系统到底怎么把天空和土壤的信息转成电磁阀的开关时间。

2. 系统总览：一台会抬头看天的浇水大脑由哪些部分组成

确定思路之后，下一步是搭建系统。这一节我先给整体架构，再解释每个模块为什么这样选。整套系统的成本控制在一个相对可控的范围，核心元件基本都是开源硬件圈非常成熟的东西，复制起来没有太大门槛。

2.1 硬件拓扑与选型

我的系统一共分五层：感知层、决策层、执行层、供电层和网络层。

感知层负责收集土壤和环境的实时数据。主控板我选了 ESP32，理由很直接：自带 Wi-Fi、ADC 位数够用、价格低、社区资料多，跑一个灌溉控制器完全不算浪费。土壤湿度传感器我最终用的是电容式传感器，而不是常见的镀铜电阻式——这个选择背后的原因后面会专门讲，这里先埋个伏笔。空气温湿度用了 BME280，温度和气压一起测，比 DHT22 稳定得多。另外还加了一路 DS18B20 测土温，因为低温条件下植物根系吸水能力会明显下降，这个参数对冬季决策很重要。

决策层就是 ESP32 里跑的一段逻辑，负责把传感器数值、天气数据、时间参数汇总，算出阀门开启的时长。网络层用 Wi-Fi 连接家里的路由器，每隔一段时间向天气 API 拉取预报数据缓存起来。执行层是 12V 常闭电磁阀加上一路直流增压泵，每个灌溉分区一个阀门，主控通过继电器控制它们开关。供电方案是 12V 锂电加太阳能板浮充，稳压到 5V 给 ESP32 和传感器供电。

下面这个表格是完整清单，方便照着买：

2.2 软件流程是怎么一圈圈转起来的

硬件只是骨架，让整套系统"活"起来的还是软件循环。我的设计思路是：系统每 15 分钟醒来一次，做一轮数据采集和决策判断，然后回到休眠省电。

每一轮循环分四步：

1. 采集土壤湿度、土温、空气温湿度，每个指标连读 5 次取平均，过滤掉传感器尖峰毛刺。
2. 检查天气缓存：如果缓存超过 6 小时，就重新请求一次天气 API，更新降雨预报和气温数据。
3. 执行浇水决策：先判断"要不要浇"，再计算"浇多久"。如果条件全部满足，打开对应分区电磁阀，同时开始计时。
4. 轮询本地 MQTT 状态，把最新的土壤数据和浇水记录推送到手机面板，方便远程观望。

所有数据都带时间戳写入日志，我用一个简单的表格记录每次浇水的原因。后来回看运行日志时发现，这套流程最重要的其实不是"计算"，而是"缓存"与"降级"。一旦 Wi-Fi 断了或者天气 API 超时，系统不能傻等，必须能用手头已有的数据继续工作。这个降级策略我会在第五部分展开讲。

启动阶段最容易被忽略的是时间校准。ESP32 本身没有可靠时钟，断电重启后时间会回到默认值。我给系统加了 NTP 校时，每次联网都对时，因为无论天气预报还是日落日出计算，都依赖精确的时间基准。否则可能出现"大半夜打开阀门浇水"这种灾难性场景。

3. 天气数据的接入算法：如何用降雨预报和蒸发量决定浇不浇、浇多少

"看天"的关键在于数据接入和决策算法。市面上的天气 API 很多，我最终选了 OpenWeatherMap，原因一是免费配额够家庭项目用，二是它的预报字段比较全，既有逐时降雨，也有每日紫外线指数和风速。下面我会把数据字段怎么用、决策逻辑怎么落地、蒸发量怎么估算这部分讲透。

3.1 天气源选择和关键字段

我拉取的是 OpenWeatherMap 的标准天气数据接口，包含当前天气和 8 天逐日预报。对于灌溉决策，真正有价值的字段如下：

实际用的时候有几个细节需要注意。OpenWeatherMap 免费版默认的单位是公制，但wind_speed单位不是每个人都清楚，最好在请求参数里显式设置units=metric，然后确认返回值的单位。另外，hourly[].pop是降雨概率，不是降雨量，概率高不等于一定下大雨，我建议同时看hourly[].rain的数值，两个条件配合使用，避免"预报说 80% 概率下雨結果一粒雨没有"的尴尬情况。

还需要说明的是，天气数据接口无法完全覆盖"头顶这片云"的局部变化。所以我的系统里天气 API 只负责三个任务：预测大趋势（暴雨、持续阴雨）、估算蒸发趋势、为短期决策提供依据。最终是否信它，还要土壤湿度说了算。

3.2 核心决策逻辑：先跳过，再补差

整个浇水的决策流程我用 Python 伪代码梳理过，实际在 ESP32 上用 C 语言实现的是同一套逻辑。先看"要不要浇"这部分：

def should_water(soil_moisture, forecast, last_rain_amount, soil_temp): # 1. 低温保护：土壤温度低于 5°C 时直接禁止浇水 if soil_temp < 5: return False, "soil_too_cold" # 2. 最近刚下过透雨，土壤不缺，跳过 if last_rain_amount >= 8: return False, "recent_rain" # 3. 土壤湿度高于田间持水量下限，不需要补水 if soil_moisture >= 45: # 百分比体积含水量，按标定后的值 return False, "soil_wet" # 4. 看未来 12 小时累计降雨预报 future_rain_12h = sum(forecast.hourly_rain[i] for i in range(12)) if future_rain_12h >= 2: return False, "rain_expected" # 5. 干旱且无降雨预期，需要浇水 return True, "dry_and_no_rain"

这里"未来 12 小时累计降雨预报 ≥ 2 毫米"这个阈值来自我自己的观察：2 毫米对一场小雨而言，几乎不能渗透到根系层，如果土壤已经明显偏旱，指望这点雨是不够的；但如果预报超过 5 毫米，那大概率能渗进土里，完全可以省下一次浇水。阈值不是死数字，你可以按当地气候习惯微调，雨天多的地方可以调高一点。

一旦判定"需要浇"，接下来就是"浇多久"的问题。我没有简单粗暴地固定为 10 分钟，而是引入了一个蒸发量补偿的思路。因为同样的 3 天不浇水，在 35°C 烈日下和 22°C 阴天里，土壤失去的水量差距可以达到 2 倍以上。

3.3 用 Hargreaves 公式估算一天该补多少水

估计植物每天的需求量，最常见也相对简单的方法是参考蒸散量 ETo（Reference Evapotranspiration）。完整版的 Penman-Monteith 公式需要太阳辐射、饱和水汽压、风速等大量数据，家庭项目用不上那么精细。我采用的是 Hargreaves 公式，它只需要最高温、最低温和一个与月份/纬度有关的太阳辐射系数 Ra：

[ ETo = 0.0023 \cdot Ra \cdot (T_{avg} + 17.8) \cdot \sqrt{T_{max} - T_{min}} ]

其中 ETo 的单位是毫米/天，T 的单位是摄氏度，Ra 是大气层外太阳辐射，单位换算成等效蒸发水柱毫米/天，不同纬度、不同月份取值不同，网上可以直接查到表。

实际浇水时间就按照这个公式做一个缩放：

float eto_mm = 0.0023 * Ra_month * (t_avg + 17.8) * sqrt(t_max - t_min); float crop_factor = 0.85; // Kc 作物系数，叶菜类偏高，沙土地偏低 float daily_need_mm = eto_mm * crop_factor; float soil_storage = (field_capacity - current_moisture) * root_depth_mm; float deficit = daily_need_mm - soil_storage; if (deficit > 0) { irrigation_duration_min = deficit * area_m2 / drip_total_flow_LperMin; }

这段逻辑的含义是：先算植物蒸发蒸腾要消耗多少水，再看土壤自身还能放出多少水，两者相减就是需要额外补的水量。最后根据滴灌管的流量换算出阀门开启时间。

Hargreaves 公式的优点是省去太阳辐射计，缺点是高温高湿的沿海地区和强风天气误差略大，所以我的系统还会用uvi和wind_speed做修正系数。比如紫外线指数大于 8 时，ETo 乘以 1.1 的系数；风速大于 5m/s 时，再乘以 1.08。这些系数没有复杂的推导，都是调试阶段从实际土壤湿度变化中反推出来的，运行两周后基本贴近真实情况。

3.4 边界情况：小雨、中途暴雨和"雷声大雨点小"

天气系统的判断经常会遇到模棱两可的边界情况，我梳理了三种最常见的场景，也给了对应的处理策略。

第一种是"小雨下了半天，土表层湿了但根系层依然干"。我的解决方案是拉取土壤湿度时同时读取 10cm 深处和 20cm 深处的两个探头。表层湿度明显升但深层没升，说明雨量不够，系统不会误判为"已经补水"，还是照常浇水。

第二种是"刚打开阀门十分钟，天突然开始下雨"。这种场景靠天气 API 无法做到实时响应，我的补救办法是接了一个最简单的雨滴感应开关，放在屋檐能正常溅到的露天位置。一旦检测到连续 5 分钟雨滴信号，无论土壤和预报如何，立即强制关闭当前分区阀门，并标记为"路上雨"，顺延当天浇水计划。这个硬件优先级高于一切软件逻辑，相当于一个"物理外挂"。

第三种是"预报有大雨，结果一滴没下"。这是天气预测天然的不确定性。我做不到解决它，只能让系统在第二天自动检查实际降雨量。如果实测降雨为 0，而土壤湿度已经掉到阈值以下，系统会在早上自动补一次浇水，误差延迟控制在一晚以内，对植物来说完全可以接受。

4. 硬件执行链路：电磁阀、滴灌管与一套不炸管的实战水路

前面讲的都是软件怎么"看天"，但最终水还是要通过物理管道流到植物根部。这一节是实战环节，我把水路设计、元器件选型和现场施工的经验一次性写清楚。

4.1 水路设计与元件选型

设计水路前先明确自己的水源。我是从阳台水龙头的三通接出一路主管道，然后分到两个灌溉分区：菜地区（20 个滴头）和木本花盆区（12 个滴头）。主水路上先接一个 120 目的叠片过滤器，再接减压阀。这里有个省钱优先级：过滤器不能省，减压阀大多数情况可以省。滴灌系统最怕的是泥沙堵塞滴头，一旦堵了整条滴灌管报废，而减压阀只有在入户水压很高时才必须装。

执行元件方面，电磁阀选了 12V 常闭型。常闭的意思是断电时阀门自动关闭，电压异常或程序死机时系统会回到"不浇水"的安全状态，而不是哗哗淌水。这一点比常开型安全太多，尤其人不在家时心智负担完全不同。

为了防"水锤效应"，我没有用快速开闭的园艺电磁阀，而是选了一款带缓冲功能的隔膜式电磁阀。水锤简单说就是阀门突然关闭，管道里的水流因惯性撞击阀芯，产生类似管道"砰砰"撞击声的压力波。对滴灌系统这种低压管路，水锤不会炸管，但会缩短电磁阀寿命，而且声音很烦。带缓冲的阀在关闭最后阶段会减慢阀芯动作，把冲击降到最低。

还有个容易被忽略的决策：水泵要不要加？这取决于你的水源水压。如果水龙头出水本身有稳定压力，电磁阀直接控制即可，不需要泵。但我的水压波动厉害，高峰期甚至带不动滴灌，所以我加了一路 12V 隔膜增压泵，额定扬程 20 米，实测出水量完全够用。注意泵必须放在电磁阀上游，否则泵抽水时会把电磁阀当作负载，导致阀前后压差异常。

4.2 控制电路与接线方案

ESP32 的 GPIO 输出电流很小，不能直接驱动电磁阀和水泵，中间必须加继电器模块。我用的是两路 10A 继电器，一路管水泵，一路管电磁阀。继电器线圈供电用 5V，由 ESP32 的 VIN 或降压模块供给。

接线有一个特别容易翻车的地方：电磁阀和水泵是感性负载，断电瞬间会产生反向电动势，如果继电器模块不带光耦隔离和续流二极管，高电压尖峰可能顺着 GPIO 倒灌进 ESP32，轻则重启，重则烧掉主控。网上有人遇到"每次关水之后系统就重启"，多半就是这个问题。我在继电器模块外部并联了一个 1N4007 续流二极管，正极接负载端电源，负极接负载另一端，从此再也没有异常重启过。

主控和传感器共地也很重要。12V 电池同时给电磁阀、水泵和稳压模块供电，ESP32 的 GND 必须和 12V 电源的 GND 连在一起，否则继电器吸合时可能出现压差导致的误动作。

户外防水方面，电磁阀和水泵都放在一个 IP65 的塑料配电箱里，电线通过防水接头引出，全部采用快速端子连接，方便检修。传感器虽然裸露土中，但连接处用热缩管加硅橡胶密封。ESP32 板载的 USB 口不能直接露在外面，我用环氧树脂封住了。

4.3 滴灌管布设与流量匹配

布管阶段最影响效果的是滴头流量与浇水时间的匹配。我用的滴灌是 2L/h 的压力补偿滴头，每隔 30cm 一个。菜地区 20 个滴头，理论总流量 40L/h；花盆区 12 个滴头，总流量 24L/h。

如果你按我前面 Hargreaves 公式算出一天需要补 5 毫米水，假设菜地面积 5 平方米，那就是需要 25 升水。40L/h 的流量对应大约 37 分钟。这就能算出阀门要开多久。多数新手失败的根本原因不是算法不准，而是滴头流量跟面积不匹配：要么滴头太多、开几分钟就淹了，要么太少、开两小时还没浇透。

布管时给每滴头附近留一小块浅沟，浇水时可以肉眼判断水有没有横向蔓延。主管道末端接一个冲洗阀，每隔一个月打开冲洗一次，把管道内沉淀的杂质排出来，这个动作对延长滴灌寿命非常有效。

我的水路实物清单和关键参数汇总如下：

5. 长期运行避坑记录：传感器漂移、断网降级与冬季排空

硬件接线做完，系统跑起来只是开了个头。真正决定这个项目好不好用的，是后面几个月的长期可靠性。这一章我把实际运行中暴露的问题和对应的修复措施完整记录一遍，很多坑都是使用一个月之后才浮出来的。

5.1 土壤湿度传感器：电阻式真的会"自杀"

刚开始我贪便宜买了经典的电阻式土壤湿度传感器，就是那种两片裸露镀铜探针、插进土里测电阻的。它的原理很简单：土壤越湿，导电性越好，输出的模拟值越小。

问题在于直流电通过探针会给土壤加电压，阳极探针表面的铜会逐渐电解溶出，几个月后探针表面就出现绿色铜锈，读数越来越偏。更尴尬的是，被电解的铜离子残留在探针周围，会改变那一点点土壤的物理性质，导致传感器局部区域又湿又导电，测出来的湿度比真实值偏高，系统越来越"懒"，浇水次数越来越少。

后来我全部换成电容式土壤湿度传感器。它用 PCB 铜箔做成电容的一个极板，通过测量电容器值变化推算含水量，探针表面不直接接触直流电流，电解反应大幅减少。实际使用半年，读数依然稳定。

但电容式传感器也不是永远不漂移。插在同一个位置久了，探针表面会附着生长微生物、肥料结晶和细根，导致读数缓慢偏移。所以我保留了每三个月的重新标定期。标定方法很简单：把传感器完全暴露在空气中，记下读数当作 0%；把它插进一杯充分吸水、沥干至不再滴水的盆栽土里，稳定后读数为高限；再按照这两个点做线性映射，最终换算成百分比体积含水量。

5.2 断网和天气 API 超时：系统怎么活着等网络回来

家庭 Wi-Fi 不可能 24 小时稳定。路由器重启、光猫拨号失败、家里停电检修，都会导致 ESP32 断网。如果没有降级策略，主控会一直重试联网，卡住整个决策循环。

我的思路是把"数据新鲜度"作为决策的权重。每次断网时，系统读取本地 Flash 中缓存的最后一份天气 JSON，检查时间戳。如果缓存不超过 24 小时，继续使用这份数据执行正常决策，只是在日志里标记"stale_forecast"；如果超过 24 小时甚至根本没有缓存，则切换到兜底模式：每 3 天浇一次水，每次 20 分钟，并且每次浇水前检查过去 24 小时累计雨量日志，如果本地记录到降雨，就把当前浇水日顺延一天。

Wi-Fi 重连在代码里用非阻塞方式实现：每 30 分钟尝试一次，不成功就休眠，绝对不让主循环卡在连接函数里。NTP 校时也只在成功联网后才执行，本地临时用系统上电时间加递增计时器维持相对逻辑。这样即使完全断网，系统也会按保守策略维持植物的最低生存，不会干死也不会涝死。

5.3 冬季排空和低温保护：别让一管水冻裂整个春天

北方冬天温度一旦持续低于零度，这是最危险的时期。管路里的残留水结冰后会膨胀，PE 管容易裂，电磁阀内部的密封圈也会被冻坏。我入冬前把电磁阀整体从水路拆下来，倒置存放在室内；管道系统的每个低点加装排水阀，把水放干。如果不方便拆阀，可以用泵向管道内吹压缩空气，直到出水口只有气流没有水珠。

除了物理排水，我还把软件的温度保护阈值设到了 5°C。只要 DS18B20 测到土壤温度低于 5°C，无论其他条件怎么满足，一律禁止浇水。这个做法的逻辑是：低温下土壤水活性下降，很多植物根系基本停止吸水，此时灌水不仅没帮助，反而会让根际长时间处于冷湿环境，诱发烂根。

冬天还有一种特殊情况：白天太阳好，气温升到 8°C，地却还是凉的。这种时候系统也不会浇水，因为真正对根系起决定作用的是地温，不是气温。用土温传感器做阀门，比根据天气预报里的气温做判断靠谱得多。

5.4 雨滴开关和天气预报警报：双保险不是过度设计

前面提到的雨滴感应开关，是这套系统里唯一一个"非电子逻辑"的物理传感器。它的工作方式很简单：板子表面有露珠时会短路，输出低电平。我用它对冲天气 API 的最大短板——预报滞后和局部阵雨。

实际使用中发现，雨滴开关同样有坑。它太灵敏了，清晨的露水、细雾甚至蜘蛛网造成的短路，都有可能让它误判为"正在下雨"。我的处理是加一个 5 分钟的持续触发判断，只有连续 5 分钟都是低电平才认为真在下雨。同时，为了避免板面积尘导致一直低电平，我每周在日志里检查一次它的状态，超过两次误报就远程重启一次，或者直接忽略它几天。

用天气 API 做趋势判断、用雨滴开关做即时中断、用土壤湿度做最终仲裁，三层冗余设计让我这两个月基本没做过人工干预，也没出现真正意义上的"灌溉事故"。

6. 素材与调参经验：连续两月无人工浇水的真实运行数据

系统的最终检验标准是植物状态和用水数据。我记录了从七月到九月整整两个月的运行日志，这里截取最有代表性的部分。数据不是实验室理想条件，而是真实阳台气候环境的产物。

6.1 连续八周运行记录

下表是每两周汇总一次的均值数据。整个期间，我完全没有手动开过阀门，只在第三周换过一次滴头位置。

对比之前用的定时器同期数据，老方案每隔一天浇一次、每次 15 分钟，耗水量明显更多，而且在两场暴雨后都发生了花盆托盘积水。新系统在保证植物长势的前提下，总用水量下降了约 37%——这是最直观的收益。

6.2 调参过程中最值得讲的三个参数

第一个是作物系数 Kc。Hargreaves 公式算出来的是参考蒸散量，它对应的是标准草地，不代表你的菜地和花盆。我调试时发现，叶菜类夏季晴天 Kc 接近 0.9，而木本植物在充分灌溉时只要 0.6 左右，所以按分区给不同 Kc 值非常关键。如果把菜地的 Kc 误设成 0.6，一周内就会看到叶缘焦卷。

第二个是"未来 12 小时累计降雨 ≥ 2mm 就跳过"这个阈值。北方夏季局地强对流很常见，天气预报经常说"下午雷阵雨"，但实际只落在某个小区上空，误差很大。我把阈值从 1mm 调到 2mm 之后，因为"冤枉雨"而少浇的情况明显减少，植物也没出现过水分亏缺。

第三个是每次浇水的短时分次策略。滴灌系统常用"浇-停-浇"的方式，避免水流灌不满就横向流失。我的策略是每次计划水量分成三份，每份之间停 20 分钟。比如计算得出需要浇 36 分钟，系统会先开 12 分钟，停 20 分钟，再开 12 分钟，停 20 分钟，最后再开 12 分钟。这样水分能充分下渗，不会在地表形成径流。这个细节对黏性土壤尤其有用。

6.3 两个月跑下来，我对"智能灌溉"的真实体会

如果只让我留一句话总结，我会说：这个项目的大头不是接线，不是写代码，而是理解植物和土壤之间的水分账本。ESP32、电磁阀、天气 API 都是现成工具，真正让系统变得好用的，是一遍遍调试决策阈值、观察植物响应、根据数据修正系数的过程。

两个月运行中，我最满意的一点不是"它自动浇了水"，而是它学会了"选择不浇"。连续三天暴雨时自动停水，太阳最毒的那周自动把每次补水拉长，午后阵雨前果断中断灌溉——这些动作在定时器时代根本不可能发生。植物不会说话，但叶片的状态会告诉你它渴不渴，我的系统只是把这些信号换成了温度和雨量数字。

目前这套系统还在运行，下一版我计划加入更多分区控制，比如按植物生长期动态调整 Kc 值、用光照计替代紫外线指数估算蒸发量。如果你也要搭一套"看天"的灌溉系统，我的建议是从一个分区、一种植物开始，用小面积验证决策逻辑，再慢慢扩展。自动化的乐趣不在于机器永不出错，而在于你终于不用每天惦记着"今天到底要不要浇水"这件事了。