chiller plant monitoring

冷水机组监控+推荐系统

A. 冷水机组监控+推荐系统 它结合了：

• 实时监控仪表板 （设备状态、冷却器/泵/热成型机功率、温度、流程、图表）
• 成本和能源汇总 （千瓦时/泰铢）
• 基于规则的业务建议 （例如，根据负载/温度稳定性，保持1台冷水机组与运行2台冷水机组）
• 通过Langflow集成LLM（MCP工具） 因此，用户可以提出“Thermoform怎么样？”等问题，并获得结构化的“决策/推理”输出。

结果（端到端堆栈）

工作管道：

1. InfluxDB时间序列数据\

→ 2) FastAPI后端\ → 3) Next.js前端控制面板+Swagger\ → 4) MCP工具\ → 5) 基于Langflow聊天的推理

______________________________________________________________________

目录

• \[系统架构\]
• \[后端API\]
• \[推荐引擎\]
• \[实体模型模式\]
• \[Langflow+Docker+MCP集成\]
• \[技术栈\]

______________________________________________________________________

系统架构

A） 数据层（InfluxDB→ 流量查询）

• 后端从以下位置读取时间序列数据 InfluxDB 使用官方Python客户端和 通量 查询。
• 通过配置 .env （URL/TOKEN.ORG/BUCKET）。
• 查询分组方式 植物标签列表 （P1/P2），例如：

- 冷却器功率、泵功率、油箱温度、冷却器温度、热成型功率

• 支持：

- 快照（最新点） 用于实时KPI图块 - 历史记录（聚合窗口） 用于图表+决策逻辑

B） 后端服务（FastAPI）

• 用于仪表板和分析的REST端点
• 包括：

- 跨域资源共享 用于本地前端 - 植物选择器 通过请求头 X-Plant-ID （回退默认值，如P2）

C） 业务逻辑/分析层

服务模块职责：

• 将原始流入数据标准化为 用户界面友好的插槽ID （CH1/CH2/P9/TF4等）
• 计算指标：

- 冷却能力 （来自流量和ΔT） - 缔约方大会 - 泵能源成本历史 (kWh → THB)

• 生产 规则的推荐 和 防拍打 （N点的条件必须稳定）

D） LLM+Langflow集成（MCP工具）

Langflow暴露的MCP工具：

• recommend_rule() → UI使用的基于规则的建议
• get_state() → LLM的紧凑数字快照
• decide_actions() → 结构化输出结合指标+推荐

包括 MCP代理 致：

• 转发 /mcp 请求：
• 重写 Host header（修复常见的本地集成问题）
• 支持 SSE流媒体 （文本/事件流）

E） 前端（Next.js）

演示

Dashboard 监控仪表板功能：

• 设备选择器+实时连接状态
• 冷水机组图可视化（CH/TF/P节点）
• 实时KPI卡（千瓦、温度、流量）
• 交互式图表（例如，带限制线的24小时冷水机功率趋势）
• 成本和能源汇总（千瓦时，泰铢）
• 推荐小组（建议行动+推理）

______________________________________________________________________

后端API

健康与实时监控

• GET /health

快照端点（最新点）：

• GET /api/chill_pw --冷却器功率快照
• GET /api/pump_pw --泵功率快照
• GET /api/pump_flow --流快照
• GET /api/chiller_temp --evap进入/离开temps
• GET /api/chiller_tank_temp --回油箱/供油箱温度
• GET /api/thermoform_power --热形态kW

历史端点（图表）

每个都有共同的参数：

• start （默认值： 24h)
• every （默认值： 10m)
• 可选的 from 和 to 时间戳

示例：

• GET /api/chiller_pw_history
• GET /api/pump_pw_history
• GET /api/pump_flow_history
• GET /api/chiller_temp_history
• GET /api/chiller_tank_temp_history
• GET /api/thermoform_power_history
• GET /api/cooling_capa_history

分析

• GET /api/cop --根据功率、流量和油箱温度计算COP
• GET /api/pump_power_cost_history?rate=4.0

- 将电源历史记录转换为： - 总千瓦时 - 总泰铢 - 每间隔历史记录

推荐

• GET /api/recommend --基于规则的操作建议（1台vs 2台冷水机组）
• GET /api/limit_chiller_power_input --UI限制取决于是否有任何冷却器在线

______________________________________________________________________

推荐引擎

设计目标：

• 可解释的：返回 status / suggest / reason / metrics
• 稳定：使用回望窗口+N点持久性进行防拍打
• 植物意识：工厂定义（P1/P2）、标签列表、UI插槽映射、集中在配置中的COP映射

关键概念：

• “冷却器开启”推断如下 power > threshold （例如，50千瓦）
• 通过以下方式估算冷却需求 制冷量 来自流量和ΔT（回水-供水）
• 切换规则：

- 如果运行1台冷水机组且负载/温度持续较高→ 推荐2台冷水机 - 如果运行2台冷水机组且冷却持续偏低→ 建议减少到1台冷水机

______________________________________________________________________

模拟模式

在没有真实工厂数据的情况下支持开发：

• 由env标志控制的模拟提供者
• 生成具有抖动/噪声的真实快照+历史记录
• 使用真实工厂的配置标签列表，使UI+逻辑行为相同
• 实现一致的演示行为

______________________________________________________________________

Langflow+Docker+MCP集成

Dashboard

做了什么

• Langflow通过 码头工人 作为LLM管道的编排UI
• 后端公开MCP工具，因此Langflow将工厂系统称为工具（而不仅仅是文本）
• 聊天界面输出结构化操作，如：

- Action: ON/OFF - Target: CH1 / TF4 ... - Reasoning 使用返回的度量（例如，热形式总千瓦、冷器计数） Dashboard

为什么存在MCP代理

由于主机标头+流限制，某些设置失败。代理：

• 将请求转发到MCP服务器
• 重写 Host 头球
• 支持 text/event-stream （SSE流媒体）

MCP工具端点

• recommend_rule(plant_id)
• get_state(plant_id)
• decide_actions(plant_id, objective="chiller_only" | "optimize")

______________________________________________________________________

技术栈

后端

• python
• FastAPI（REST API+Swagger）
• httpx（代理MCP请求）
• pandas/numpy（数据整形、旋转、成本和冷却计算）
• InfluxDB Python客户端+Flux查询

数据

• InfluxDB（时间序列存储）

人工智能/编排

• Langflow（Docker）
• MCP服务器（LLM工具）
• MCP代理（主机/SSE兼容性）

前端

• Next.js（React）
• 仪表板UI（工厂图、图表、KPI、推荐卡）

DevOps/协作

• Docker（Langflow运行时）
• Git（版本控制）

______________________________________________________________________

备注

• 通过以下方式选择植物 X-Plant-ID 标头（回退默认工厂，例如P2）
• 支持UI和决策逻辑的快照+历史查询