自動控制邏輯開發(fā)閾值觸發(fā)自動澆水、自動通風(fēng)、溫控聯(lián)動作者黒漂技術(shù)佬前面四篇文章都在講數(shù)據(jù)怎么采集、怎么傳輸、怎么存儲。這當(dāng)然重要——但說實話純「數(shù)據(jù)大屏」的項目農(nóng)戶看了只會說一句「好是好但能不能幫我干點活」本文就來回答這個問題怎么讓系統(tǒng)自動干活。溫度高了自動開風(fēng)機土壤干了自動澆水光照不夠自動補光——真正的智慧農(nóng)業(yè)數(shù)據(jù)不是終點控制才是。一、自動化的核心價值傳統(tǒng)大棚種植最痛苦的是什么是「人不能離」。夏天中午棚內(nèi)溫度飆升到 40℃你必須沖進去開風(fēng)機開天窗凌晨濕度驟降又得爬起來開加濕器。一個疏忽一季的收成就打了水漂。自動化控制要解決的就是這個痛點。它的核心價值有三層解放人力24 小時自動值守人不用綁在大棚里精準(zhǔn)控制傳感器采集的精度遠超人的感知28.5℃ 和 30℃ 的區(qū)別你感覺不到但機器能聯(lián)動決策溫度和濕度不是孤立問題——開風(fēng)機降溫的同時會帶走濕度系統(tǒng)能自動計算平衡點人就很難做到二、控制閉環(huán)架構(gòu)自動控制的本質(zhì)是一個「感知→決策→執(zhí)行→反饋」的閉環(huán)┌─────────┐ 傳感器數(shù)據(jù) ┌─────────────┐ 控制指令 ┌─────────┐ │ 傳感器 │ ───────────────→ │ 規(guī)則引擎 │ ──────────────→ │ 執(zhí)行器 │ │ (溫度等) │ │ (閾值判斷) │ │ (風(fēng)機等) │ └─────────┘ └─────────────┘ └─────────┘ ↑ │ │ ┌─────────┐ │ └───────────────────────│ 反饋 │←───────────────────────┘ 傳感器持續(xù)采集驗證效果 └─────────┘ 執(zhí)行后傳感器值變化舉個具體例子溫度傳感器上報 32℃ → 規(guī)則引擎判斷超閾值 → 下發(fā)「開風(fēng)機」指令 → 風(fēng)機啟動 → 1 分鐘后溫度降到 29℃ → 規(guī)則引擎判斷達標(biāo) → 關(guān)閉風(fēng)機。這就是一個完整的控制閉環(huán)。三、閾值觸發(fā)規(guī)則設(shè)計先列一個智慧農(nóng)業(yè)的典型控制規(guī)則表控制場景觸發(fā)條件執(zhí)行動作恢復(fù)條件高溫降溫溫度 30℃開風(fēng)機 開天窗溫度 28℃低溫加熱溫度 15℃關(guān)天窗 開加熱器溫度 18℃土壤干旱澆水土壤濕度 30%開水泵灌溉濕度 70%濕度過高排濕濕度 90%開風(fēng)機排濕濕度 80%濕度過低加濕濕度 60%開噴霧/加濕器濕度 70%光照不足補光光照 5000 Lux開補光燈光照 8000 LuxCO2不足補充CO2 300ppm開CO2發(fā)生器CO2 500ppm注意每個規(guī)則都有觸發(fā)閾值和恢復(fù)閾值而且兩者不同這叫「滯回控制」。比如溫度高于 30℃ 開風(fēng)機要等溫度降到 28℃ 才關(guān)——如果觸發(fā)和恢復(fù)用同一個閾值設(shè)備就會在邊界上瘋狂開關(guān)振蕩電機燒了都不知道為啥。四、規(guī)則引擎實現(xiàn)三種方案對比方案一定時輪詢最簡單適合初期ComponentpublicclassThresholdCheckScheduler{AutowiredprivateInfluxDBServiceinfluxDBService;AutowiredprivateControlServicecontrolService;// 每30秒檢查一次閾值Scheduled(fixedDelay30000)publicvoidcheckThresholds(){// 查詢最近一次所有傳感器的讀數(shù)ListSensorReadinglatestReadingsinfluxDBService.queryLatestReadings();for(SensorReadingreading:latestReadings){ThresholdRuleruleruleConfig.getRule(reading.getGreenhouseId(),reading.getSensorType());if(rule.isExceeded(reading.getValue())){controlService.execute(reading.getGreenhouseId(),rule.getAction());}}}}優(yōu)點是實現(xiàn)簡單缺點是有延遲最多 30 秒而且每條規(guī)則都要查庫傳感器多了效率低。方案二MQTT 實時消費推薦直接在消息消費時判斷閾值延遲最低ComponentpublicclassRealTimeThresholdHandler{AutowiredprivateControlServicecontrolService;AutowiredprivateRuleConfigruleConfig;// 防抖計數(shù)器Key greenhouseId:sensorType, Value 連續(xù)超閾值次數(shù)privatefinalMapString,IntegerexceedCountersnewConcurrentHashMap();// 冷卻記錄Key greenhouseId:action, Value 上次觸發(fā)時間privatefinalMapString,LongcooldownMapnewConcurrentHashMap();privatestaticfinalintDEBOUNCE_COUNT3;// 連續(xù)3次超閾值才觸發(fā)privatestaticfinallongCOOLDOWN_MS300_000;// 5分鐘冷卻publicvoidonSensorData(SensorDatadata){StringruleKeydata.getGreenhouseId():data.getSensorType();ThresholdRuleruleruleConfig.getRule(ruleKey);if(rulenull||!rule.isExceeded(data.getValue())){// 未超閾值重置防抖計數(shù)器exceedCounters.remove(ruleKey);return;}// 超閾值 → 防抖計數(shù) 1intcountexceedCounters.merge(ruleKey,1,Integer::sum);if(countDEBOUNCE_COUNT){return;// 還不夠次數(shù)繼續(xù)觀察}// 檢查冷卻時間避免頻繁觸發(fā)同一個設(shè)備StringactionKeydata.getGreenhouseId():rule.getAction().getName();LonglastTriggercooldownMap.get(actionKey);if(lastTrigger!nullSystem.currentTimeMillis()-lastTriggerCOOLDOWN_MS){return;}// 觸發(fā)控制cooldownMap.put(actionKey,System.currentTimeMillis());exceedCounters.remove(ruleKey);// 觸發(fā)后重置計數(shù)器controlService.execute(data.getGreenhouseId(),rule.getAction());log.info(閾值觸發(fā): 大棚{}, 傳感器{}, 當(dāng)前值{}, 閾值{}, 動作{},data.getGreenhouseId(),data.getSensorType(),data.getValue(),rule.getThreshold(),rule.getAction().getName());}}這里有兩個關(guān)鍵的保護機制防抖Debounce傳感器可能因為電磁干擾等原因偶爾讀到一個異常值比如溫度突然跳到 50℃ 又瞬間回來。如果讀到一次異常就觸發(fā)控制就可能誤開風(fēng)機。解決方案是「連續(xù) N 次超閾值才觸發(fā)」——連續(xù) 3 次如果是 5 秒一次采集就是 15 秒內(nèi)持續(xù)超標(biāo)才算真的超標(biāo)。冷卻Cooldown控制操作執(zhí)行后環(huán)境變化需要時間。比如開水泵灌溉后土壤濕度不會立刻從 25% 跳到 60%。如果不加冷卻接下來的 5 分鐘內(nèi)系統(tǒng)會反復(fù)檢測到「濕度 30%需要澆水」。冷卻機制規(guī)定「同一設(shè)備同一動作 5 分鐘內(nèi)不再重復(fù)觸發(fā)」避免控制指令滿天飛。方案三EMQX 規(guī)則引擎Broker 內(nèi)置如果你用的是 EMQX 企業(yè)版它的規(guī)則引擎可以直接在 Broker 側(cè)做簡單的閾值判斷-- EMQX 規(guī)則引擎 SQLSELECTpayload.temperatureastemp,payload.humidityashum,topicFROMagriculture///sensor/#WHEREpayload.temperature30超閾值后可以直接觸發(fā) HTTP 回調(diào)到你的控制服務(wù)。這個方案的好處是延遲極低處理發(fā)生在 Broker 內(nèi)部適合對實時性要求極高的場景。缺點是邏輯不能太復(fù)雜而且依賴 EMQX 企業(yè)版。推薦組合拳方案二 方案三。EMQX 規(guī)則引擎做第一層快速過濾對超出明顯安全范圍的數(shù)據(jù)直接觸發(fā)告警SpringBoot 消費者做第二層精細化判斷考慮防抖、冷卻、聯(lián)動邏輯。五、聯(lián)動控制別顧此失彼溫室環(huán)境是相互耦合的——你不能孤立地控制某一個參數(shù)。舉個典型場景溫度 33℃超了、濕度 55%也低了。如果只看溫度系統(tǒng)開風(fēng)機降溫——結(jié)果風(fēng)機一吹濕度從 55% 降到了 40%掉進更低的坑里。正確的聯(lián)動做法是publicclassLinkedControlLogic{publicvoidhandleTemperatureHigh(SensorDatadata){doubletempdata.getTemperature();doublehumiditydata.getHumidity();// 開風(fēng)機降溫controlService.sendCommand(data.getGreenhouseId(),fan_on);// 聯(lián)動如果溫度高且濕度低同時開啟加濕器if(humidity60){log.info(聯(lián)動降溫同時加濕當(dāng)前濕度{}%,humidity);controlService.sendCommand(data.getGreenhouseId(),humidifier_on);}// 聯(lián)動開風(fēng)機前檢查天窗是否已開DeviceStatusskylightdeviceService.getStatus(data.getGreenhouseId(),skylight);if(!skylight.isOpen()){controlService.sendCommand(data.getGreenhouseId(),skylight_open);}}}聯(lián)動邏輯的核心是「不要只看一個變量」。在做任何控制決策時都要檢查組關(guān)聯(lián)參數(shù)是否在安全范圍內(nèi)。六、手動/自動模式切換自動控制再聰明也得給人留個「剎車」。有時候農(nóng)戶要進棚作業(yè)、要噴藥、要采摘——這些場景下自動控制可能會幫倒忙。Topic 設(shè)計agriculture/{farmId}/{greenhouseId}/mode Payload: {mode: auto} 或 {mode: manual}控制服務(wù)在執(zhí)行前必須檢查當(dāng)前模式publicvoidexecute(StringgreenhouseId,ControlActionaction){// 先查模式StringmoderedisService.get(greenhouse:mode:greenhouseId);if(manual.equals(mode)){log.info(手動模式跳過自動控制: 大棚{}, 動作{},greenhouseId,action.getName());return;}// 自動模式正常執(zhí)行mqttCommandService.sendCommand(greenhouseId,action);// 記錄控制日志controlLogService.record(ControlLog.builder().greenhouseId(greenhouseId).action(action.getName()).mode(auto).triggerCondition(action.getTriggerCondition()).threshold(action.getThreshold()).currentValue(action.getCurrentValue()).timestamp(System.currentTimeMillis()).result(success).build());}手動模式優(yōu)先級高于自動——這是鐵律。機器可以輔助人但不能凌駕于人。七、控制日志審計比控制還重要每執(zhí)行一次控制操作都要留下完整的日志記錄。不是為了形式主義而是有實際價值CREATETABLEcontrol_log(idBIGINTPRIMARYKEYAUTO_INCREMENT,greenhouse_idVARCHAR(50)NOTNULL,actionVARCHAR(50)NOTNULLCOMMENTfan_on/humidifier_on/pump_on等,modeVARCHAR(10)NOTNULLCOMMENTauto/manual,trigger_conditionVARCHAR(200)COMMENT觸發(fā)條件描述,threshold_valueDECIMAL(10,2)COMMENT閾值,current_valueDECIMAL(10,2)COMMENT觸發(fā)時的傳感器值,execute_timeDATETIMENOTNULL,resultVARCHAR(20)NOTNULLCOMMENTsuccess/fail,fail_reasonVARCHAR(500)COMMENT失敗原因,INDEXidx_time(execute_time),INDEXidx_greenhouse(greenhouse_id,execute_time));這些日志的用途事后排查哪天作物狀態(tài)不對可以回溯「當(dāng)時系統(tǒng)干了什么」閾值優(yōu)化統(tǒng)計分析觸發(fā)頻率——如果降溫風(fēng)機一天開了 50 次說明你閾值設(shè)得有問題設(shè)備健康度某水泵觸發(fā)頻率突然翻倍可能是傳感器失準(zhǔn)或管路泄漏的預(yù)警信號總結(jié)自動控制的五條軍規(guī)滯回控制觸發(fā)和恢復(fù)用不同閾值避免設(shè)備振蕩防抖 冷卻連續(xù) N 次超標(biāo)才觸發(fā)觸發(fā)后 N 分鐘內(nèi)不重復(fù)聯(lián)動判斷做任何控制前檢查關(guān)聯(lián)參數(shù)手動優(yōu)先手動模式一開自動全部讓路控制必記日志沒有審計的控制是定時炸彈數(shù)據(jù)采集做得再好最終產(chǎn)生價值的還是「控制」。畢竟農(nóng)戶要的不是漂亮的溫濕度曲線而是好收成。