简介一套基于C#与51普中开发板联合开发的温室监控系统源码适合正在学习C#上位机编程、串口通信以及嵌入式下位机开发的学员或开发者。系统围绕温室环境管理展开能够实时采集温湿度、光照等传感器数据通过上位机界面进行展示并依据预设策略控制通风、灌溉、加热等设备形成完整的远程监控闭环。压缩包共1065个文件大小约50.71MB主要包含C#工程文件.cs、.sln、.csproj、运行所依赖的dll库、xml配置与txt说明文档以及单片机侧的.c/.h源码和hex固件方便同时研读上下位机两端实现。目前已有2308人次学习下载。源码中界面逻辑、通信协议、数据存储和控制策略划分清晰附带的工程与依赖便于直接还原编译环境既有完整项目结构也有底层驱动细节很适合作为课程设计、毕业设计或入门农业物联网开发的参考范例。1. 温室监控上位机C# 到底在帮你解决什么问题做过温室项目的人都清楚真正的难点从来不是那几个温度湿度传感器而是数据从设备到屏幕这条路怎么走通。一个标准的连栋温室大棚里少则几十个、多则几百个采集点分布在通风、灌溉、卷帘、补光这些子系统里如果每个设备都配一套独立软件值班人员要在七八个界面之间来回切换光看数据就够累的更别提联动控制了。C# 上位机温室监控系统源码解决的就是这件事把分散的传感器数据汇总到一台工控机上统一显示、统一存储、统一报警必要的时候还能反向下发控制指令。这套方案在行业里非常成熟适合三类人一是刚转入上位机开发、想找一个完整项目练手的学习者二是要给温室项目做配套软件的工程师需要一套能改能扩展的底子三是甲方或集成商的技术负责人想搞清楚一个可落地的温室监控系统到底该包含哪些模块避免被供应商拿着半成品糊弄。C# 在这个领域里之所以被反复选择是因为它的 WinForms/WPF 做工业界面足够快串口和网络通讯库齐全SQLite/SQL Server 接得顺而且 Visual Studio 社区版免费——对一个预算不高的温室项目来说这套技术栈几乎没有额外成本。光说不练没有意义。这篇文章直接用一套典型温室监控系统的架构做主线去掉花哨的框架包装把通讯采集、界面刷新、数据落库、报警联动这几块说透每一段都给出能直接复制的代码和参数说明。读者按章节走一遍改一改 IP 和寄存器地址就能搭出自己的版本。2. 温室监控的通用架构与选型为什么是 C# WinForms Modbus/OPC2.1 温室监控系统的四层结构一个能真正跑到生产环境里的温室监控上位机通常分成四层设备层温度、湿度、光照、土壤水分传感器加上风机、卷膜电机、水泵、补光灯这些执行机构。传感器输出的信号要么是 4-20mA 模拟量要么走 RS485 总线通过 Modbus RTU 协议上报也有一部分新型传感器直接出网口走 Modbus TCP 或 OPC UA。采集层这一层是上位机的核心。PC 通过串口服务器或工业网关把 RS485 总线上的数据转成网络数据或者直接通过以太网口读取设备数据。C# 程序在这一层负责定时轮询、协议解析、异常重试。监控层包括实时数据界面、趋势曲线、报警窗口、设备控制面板。这一层直接面对操作员要求界面刷新不卡死、数据不闪烁跳动。管理层历史数据存储、报表导出、用户权限。用 SQLite 存最近几个月的明细用 CSV 做日报导出足够覆盖大多数温室场景。很多新手犯的错误是一上来就画界面把大量时间花在按钮美化上结果通讯层没设计好设备数据一多就丢帧乱码。正确顺序是先跑通采集层再往界面上堆功能。2.2 通讯协议选型Modbus TCP、Modbus RTU 还是 OPC温室监控里最常见的协议有三种选择依据是设备端支持什么——上位机永远是被动适配的一方。Modbus RTU最普遍走 RS485 总线一条总线可以挂 32 个设备波特率常见 9600 或 19200一帧数据包含地址码、功能码、数据区和 CRC 校验。优点是硬件便宜、设备兼容性好、几乎所有温湿度变送器都支持缺点是轮询速度慢挂 20 个设备、每个设备读 5 个寄存器一轮下来可能要两三秒不适合做高频采集。Modbus TCP是 RTU 的以太网改造版把 RTU 帧直接封装进 TCP 报文里省掉了 CRC由 TCP 保证传输完整性地址也变成 IP:端口。采样速度比 RTU 快得多适合大屏多设备场景。OPC DA/UA是工业通讯的上层抽象专门解决「不同品牌设备各自为政」的问题。如果现场用了西门子 PLC 做灌溉控制传感器又来自不同厂家直接用 Modbus 去对接 PLC 的寄存器非常痛苦而 OPC 服务器把底层协议差异屏蔽掉上位机只面向 OPC 的 Item 读写数据。C# 连接西门子 OPC 是热门的搜索词实际做法是引用 OPC 的互操作 DLL或者用 OPC UA 的官方 SDK。我个人在这个项目里推荐主用 Modbus TCP、保留 Modbus RTU 预留接口。原因是温室传感器绝大多数原生支持 ModbusTCP 方便调试Wireshark 抓包直接看然后又单独留一个抽象类给 OPC万一甲方后面要求接 PLC改动范围控制在通讯层。2.3 界面框架WinForms vs WPF温室项目选哪个更划算这是一个能吵三天三夜的问题。我的结论很直接按团队的熟悉程度来不要跟风。WinForms开发速度快学习曲线平缓网上现成控件多对低配工控机友好。缺点是界面样式老旧自绘控件麻烦。WPF界面能做得很现代支持 MVVM、数据绑定、动画但是这些特性的学习成本不低。一个温室监控项目界面最多用两到三周时间开发花一半时间去学 MVVM 框架不划算。除非团队里已经有人熟练 WPF或者甲方明确要求现代化大屏风格。从岗位搜索结果来看大量 C# 上位机岗位要的就是 WinForms 熟手这也侧面说明工业现场存量系统还是 WinForms 的天下。源码项目也大多以 WinForms 为底座因为更容易被初学者读懂、改造成自己的东西。如果是给别人做交付项目建议外层留一个接口界面项目UI和通讯项目Communication分两个工程这样后续如果甲方想从 WinForms 升级到 WPF通讯层一个字节都不用改。2.4 一个简化了的目录结构源码拿到手先认识代码一个合格的温室监控系统源码工程结构通常长这样GreenhouseMonitor/ ├── GreenhouseMonitor.sln # 解决方案文件 ├── GreenhouseMonitor.UI/ # WinForms 界面工程 │ ├── Forms/ │ │ ├── MainForm.cs # 主窗体数据总览 │ │ ├── AlarmForm.cs # 报警列表窗体 │ │ └── HistoryForm.cs # 历史曲线窗体 │ └── Controls/ │ ├── SensorCard.cs # 单路传感器卡片控件 │ └── TrendChart.cs # 趋势图控件封装 ├── GreenhouseMonitor.Core/ # 核心工程通讯与业务逻辑 │ ├── Modbus/ │ │ ├── ModbusTcpClient.cs # Modbus TCP 客户端封装 │ │ └── ModbusRtuClient.cs # Modbus RTU 串口封装 │ ├── OPC/ │ │ └── OpcDaClient.cs # OPC DA 客户端封装 │ ├── Models/ │ │ └── SensorPoint.cs # 测点模型地址/名称/上下限 │ └── Services/ │ ├── PollingService.cs # 轮询调度服务后台线程 │ └── AlarmService.cs # 报警判定与通知服务 ├── GreenhouseMonitor.Data/ # 数据层工程 │ ├── SQLiteHelper.cs # SQLite 读写封装 │ └── DataArchiver.cs # 历史数据落库服务 └── Config/ └── device_config.json # 设备与点位配置文件这个结构是大多数 C# 上位机通用框架的变形UI、Core、Data 三层分离配置外置。目的是让团队里写界面的人不需要关心协议细节写通讯的人不碰界面逻辑。device_config.json是这个项目里最重要的文件上位机启动时读它构建出所有测点的采集清单。测点模型长这样public class SensorPoint { public int DeviceId { get; set; } // 设备ID1号采集器、2号采集器 public string PointName { get; set; } // 测点名称东区第1路温度 public byte SlaveId { get; set; } // Modbus从站地址1~247 public ushort StartAddress { get; set; } // 寄存器起始地址从0开始 public ushort RegisterCount { get; set; } // 寄存器数量温度通常2个32位float public float Scale { get; set; } // 缩放系数寄存器原始值 * Scale 实际值 public float Offset { get; set; } // 偏移量实际值 原始值 * Scale Offset public float HighAlarm { get; set; } // 上限报警值 public float LowAlarm { get; set; } // 下限报警值 public bool Enabled { get; set; } // 是否参与轮询 }这里的Scale和Offset是温室项目最容易栽跟头的地方。很多传感器把温度放大 10 倍上报寄存器存 326 表示 32.6 度如果上位机忘记除以 10屏幕上就会出现 326 度这种诡异数据。源码拿到手后先花半小时核对每个点位对应的配置比后面调试两小时强得多。3. 数据采集与通讯实现Modbus TCP 轮询、CRC 校验与断线重连3.1 用 C# 实现一个可用的 Modbus TCP 客户端写 Modbus 客户端有两个选择用开源库 NModbus4 / NModbus或者自己写一个精简版。从学习角度强烈建议自己手写一遍 TCP 协议帧代码量不大但对理解协议帮助巨大。从工程角度生产环境用 NModbus 更稳因为它处理了异常响应的各种边界情况。这里给出一个手写精简版用于教学和调试足够public class ModbusTcpClient { private TcpClient _tcpClient; private NetworkStream _stream; private readonly object _lock new object(); // 串行化请求Modbus不允许并发 public bool Connect(string ip, int port, int timeoutMs 3000) { try { _tcpClient new TcpClient(); var task _tcpClient.ConnectAsync(ip, port); if (!task.Wait(timeoutMs)) { throw new TimeoutException(连接超时); } _stream _tcpClient.GetStream(); _stream.ReadTimeout timeoutMs; _stream.WriteTimeout timeoutMs; return true; } catch (Exception ex) { Console.WriteLine($[ModbusTCP] 连接失败: {ex.Message}); return false; } } public bool ReadHoldingRegisters(byte slaveId, ushort startAddr, ushort count, out ushort[] values) { values null; lock (_lock) { if (_tcpClient null || !_tcpClient.Connected) return false; byte[] request new byte[12]; ushort transactionId (ushort)(DateTime.Now.Millisecond 0xFFFF); // MBAP头事务ID(2) 协议ID(2) 长度(2) 单元ID(1) request[0] (byte)(transactionId 8); request[1] (byte)(transactionId 0xFF); request[2] 0x00; // 协议ID高字节Modbus固定0 request[3] 0x00; // 协议ID低字节 request[4] 0x00; // 后续字节长度高字节 request[5] 0x06; // 长度 单元ID(1) 功能码(1) 地址(2) 数量(2) 6 request[6] slaveId; request[7] 0x03; // 功能码03读保持寄存器 request[8] (byte)(startAddr 8); request[9] (byte)(startAddr 0xFF); request[10] (byte)(count 8); request[11] (byte)(count 0xFF); try { _stream.Write(request, 0, request.Length); byte[] header new byte[9]; ReadExactly(_stream, header, header.Length); int byteCount header[8]; byte[] data new byte[byteCount]; ReadExactly(_stream, data, byteCount); values new ushort[count]; for (int i 0; i count; i) { values[i] (ushort)((data[i * 2] 8) | data[i * 2 1]); } return true; } catch (Exception ex) { Console.WriteLine($[ModbusTCP] 读寄存器异常: {ex.Message}); return false; } } } private void ReadExactly(NetworkStream stream, byte[] buffer, int length) { int offset 0; while (offset length) { int read stream.Read(buffer, offset, length - offset); if (read 0) throw new IOException(连接被关闭); offset read; } } }这一段代码有两个关键参数需要说明帧结构Modbus TCP 的请求帧是 12 字节固定结构很多人第一次写抓不到数据是因为忘了长度字段只计算「单元ID 功能码 数据区」不包含 MBAP 头自身。上面的代码里长度写0x06这是读保持寄存器的固定值。如果换成读输入寄存器功能码 0x04长度仍然是 6但事务 ID 每次请求最好递增否则被设备判定为重复帧而丢弃。超时与锁Modbus 是串行协议同一时刻只能发一个请求所以必须用lock保证线程安全。ReadTimeout设为 3000 毫秒一旦设备无响应ReadExactly会抛出异常外层捕获后返回 false轮询线程据此触发断线重连逻辑。3.2 温湿度、光照的寄存器换算Scale 和 Offset 的来历读出来的原始寄存器值不能直接用。以最经典的 SHT 系列温湿度传感器经 Modbus 变送器上报为例温度寄存器常常存的是有符号 16 位整数表示实际温度的 10 倍湿度可能存 100 倍。光照变送器的量程可能是 0~200000 Lux对应寄存器 0~20000缩放系数就是 10。寄存器值换算到工程值的公式是实际值 寄存器值 * Scale Offset这个公式对应到SensorPoint模型里就成了逐点配置。怎么知道某个设备固件的 Scale 是多少翻设备说明书里的「数据地址表」——正规厂家会写明每个寄存器地址、数据类型、分辨率和量程。常见的数据类型有两种16 位无符号整数UInt16和32 位浮点数Float。浮点数占用两个寄存器分高位在前和低位在前两种字节序这是温室数据错乱的重灾区。一段处理浮点数的代码示例public static float ReadFloatFromRegisters(ushort[] regs, bool bigEndian) { // regs 长度为2比如 [0x419A, 0x0000] 表示 19.5 byte[] bytes new byte[4]; if (bigEndian) { bytes[0] (byte)(regs[0] 8); bytes[1] (byte)(regs[0] 0xFF); bytes[2] (byte)(regs[1] 8); bytes[3] (byte)(regs[1] 0xFF); } else { bytes[0] (byte)(regs[1] 8); bytes[1] (byte)(regs[1] 0xFF); bytes[2] (byte)(regs[0] 8); bytes[3] (byte)(regs[0] 0xFF); } return BitConverter.ToSingle(bytes, 0); }bigEndian到底取 true 还是 false没有规律可循完全取决于变送器固件的设计。我的做法是在 Config 里给每个点位加一个字节序字段然后用一台已知温度的设备和一台手持温度计做校准读到 19.5 就是顺序正确读到 1.737e-41 这种天文数字就该换字节序。源码里如果预留了这个字段恭喜你如果没预留这可能是第一个要改的代码位置。3.3 轮询调度多设备并发还是按顺序扫温室监控的轮询策略要回答三个问题多久读一次先读哪个后读哪个读失败了怎么办最常见的设计是一个后台线程用Timer驱动按设备 ID 的顺序遍历所有点位依次发送请求。伪代码如下public void StartPolling(int intervalMs) { _timer new System.Threading.Timer(_ PollOnce(), null, 0, intervalMs); } private void PollOnce() { foreach (var group in _deviceGroups) { bool ok _client.ReadHoldingRegisters(group.SlaveId, group.StartAddr, group.Count, out var raw); if (ok) { var value ConvertRawWithScale(raw, group); OnDataReceived(group.PointName, value); // 触发事件UI订阅后更新 } else { OnDeviceOffline(group.DeviceId); } } }这里有几个参数需要调优intervalMs轮询周期温室环境变化本来就慢温度 5 秒一变已经很快了。一般把周期放在 2000~5000ms 之间。设置得太短比如 200ms一旦设备响应稍慢上一次请求还没读完下一次就来了会出现 socket 缓冲区残留数据导致解析错位。设备分组不要每个点位单独发一次请求。同一台采集器上的多路传感器它们的寄存器地址往往是连续的用一次ReadHoldingRegisters把整块地址读回来能大幅减少报文数量。例如一台 8 路温湿度采集器寄存器起始地址 0长度 16一次请求读回 32 字节代替 8 次单独请求。失败处理单次读失败不应该立即重试同一点位因为网络抖动很常见连续失败 3 次再判定设备离线界面上的状态灯从绿变灰。同时记录失败时间戳离线的设备跳过轮询避免它拖慢整条链路的节奏。任务版的 C# 上位机项目里轮询服务常用Task.RunCancellationToken实现好处是方便优雅退出。这里用System.Threading.Timer是为了代码简短生产环境建议换成后台Task循环加Task.Delay便于控制退出时机和捕捉未处理异常。4. 实时数据界面与历史存储UI 刷新不卡顿的套路4.1 上位机 UI 跨线程更新别用 Timer 直接改控件温室监控界面上实时更新的控件可能有几十个温度标签、湿度进度条、光照数字、设备状态灯。最容易翻车的写法是直接在通讯线程里改界面控件的Text属性然后运行时抛出一个InvalidOperationException跨线程操作无效。WinForms 的黄金法则是所有控件操作必须在 UI 线程执行。标准做法是用Control.BeginInvoke把更新逻辑丢回 UI 线程public void OnDataReceived(string pointName, float value) { if (_labelTemperature.IsHandleCreated) { _labelTemperature.BeginInvoke(new Action(() { _labelTemperature.Text ${value:F1} °C; _labelTemperature.ForeColor IsNormal(value) ? Color.Black : Color.Red; })); } }但这里有个性能问题如果每收到一个测点数据就BeginInvoke一次一秒哪怕只有 20 个测点更新也会有 20 次跨线程调用界面会出现轻微掉帧。更好的方式是批量更新通讯线程把数据塞进一个并发队列UI 线程每 500ms 批量取出并统一刷新。// 通讯线程只往队列写入 private ConcurrentQueue(string PointName, float Value, DateTime Time) _dataQueue new(); public void OnDataReceived(string pointName, float value) { _dataQueue.Enqueue((pointName, value, DateTime.Now)); } // UI 线程定时器每 500ms 批量处理 private void UiRefreshTimer_Tick(object sender, EventArgs e) { while (_dataQueue.TryDequeue(out var item)) { var label _labelMap[item.PointName]; label.Text ${item.Value:F1}; } }ConcurrentQueue是线程安全的入队出队都不加锁。UI 定时器的间隔设 500ms 是一个折中人眼对 500ms 内的刷新感知不明显但系统负载大大降低。串口波特率 9600 时这个刷新率绰绰有余哪怕设备数据源是 grbl 控制器发来的高频位置信息队列模型也能扛住只是把UiRefreshTimer的间隔调短到 200ms 而已。4.2 历史数据落库SQLite 批量写入的取舍温室监控要求保留历史数据至少能查最近几个月的温度曲线、报警记录。SQLite 是现场唯一不需要安装的数据库一个文件搞定备份。上位机里写 SQLite 最常见的坑是每个数据点都插入一条 SQL 语句单线程循环执行。当点位较多、间隔又密时磁盘 IO 扛不住数据库文件越来越大最后 UI 打开历史查询卡好几秒。解决方案是攒批写入。定义一个内存缓冲队列每 5 秒或者攒满 200 条开一个事务一次性提交private ListHistoryRecord _pendingRecords new(); private readonly object _recordLock new object(); public void AddRecord(string pointName, float value, DateTime time) { lock (_recordLock) { _pendingRecords.Add(new HistoryRecord { PointName pointName, Value value, Timestamp time }); if (_pendingRecords.Count 200) { FlushRecords(); } } } private void FlushRecords() { if (_pendingRecords.Count 0) return; using var conn new SQLiteConnection(Data Sourcegreenhouse.db); conn.Open(); using var tx conn.BeginTransaction(); using var cmd conn.CreateCommand(); cmd.Transaction tx; cmd.CommandText INSERT INTO history(point_name, value, ts) VALUES(p, v, t); foreach (var r in _pendingRecords) { cmd.Parameters.Clear(); cmd.Parameters.AddWithValue(p, r.PointName); cmd.Parameters.AddWithValue(v, r.Value); cmd.Parameters.AddWithValue(t, r.Timestamp.ToString(yyyy-MM-dd HH:mm:ss)); cmd.ExecuteNonQuery(); } tx.Commit(); _pendingRecords.Clear(); }事务批量提交比逐条插入快一到两个数量级。参数p/v/t防止 SQL 注入的同时也避免了字符串拼接转义问题。_pendingRecords.Clear()在提交后执行注意要先在锁外执行数据库操作否则锁内写入期间通讯线程全部堵在AddRecord上这是最容易忽视的死锁隐患。数据文件会随运行时长不断膨胀一套 50 个测点的系统5 秒存一条一天产生 86 万条记录一个月下来 2600 万条。SQLite 对这种量级不是不能处理但查询会明显变慢。常见的做法是DataArchiver服务每天凌晨把昨天的数据导出成 CSV然后DELETE FROM history WHERE ts date(now, -90 day)把库保持在百万条量级内。4.3 实时曲线的轻量实现不用第三方图表库也能看趋势如果不想引入 LiveCharts / ScottPlot 这些第三方库用 WinForms 自带的Panel自绘一条简易趋势线其实非常可控public class TrendPanel : Panel { private Queuefloat _values new Queuefloat(600); // 存最近600个点10分钟数据(1秒1点) private Pen _linePen new Pen(Color.Green, 2); public void PushValue(float v) { if (_values.Count 600) _values.Dequeue(); _values.Enqueue(v); Invalidate(); // 触发重绘 } protected override void OnPaint(PaintEventArgs e) { base.OnPaint(e); if (_values.Count 2) return; float stepX (float)Width / 600; float minV -10, maxV 50; // 温度显示范围可配置 var pts new ListPointF(); int i 0; foreach (var v in _values) { float x i * stepX; float y Height - (v - minV) / (maxV - minV) * Height; pts.Add(new PointF(x, y)); i; } e.Graphics.DrawLines(_linePen, pts.ToArray()); } }自绘曲线对新手最大的价值是搞懂了控件的刷新模型Invalidate()只是通知系统重绘实际绘制发生在 UI 线程空闲时。push 数据再Invalidate不用立即 Draw避免在通讯线程里调用 GDI 引发句柄冲突。手写这一套之后再切换到正式图表库时你更能知道第三方库帮你封装了什么。5. 温室监控的避坑指南5 个让项目延期的高发问题5.1 现象界面温度数值在 0 和真实值之间来回跳原因Modbus 寄存器的数据类型读错了。很多温室变送器实际用的是 16 位有符号整数低温时出现负值比如 -0.5 度。如果上位机用ushort无符号短整型接收-0.5 的补码 0xFFFF 被翻译成 65535乘上 Scale 再除以 10 就是 6553.5 度。解决确认设备的数据类型。说明书上写「带符号整型」代码里就要short接收再转 float。多路温室控制器常见的是 4 路温度 4 路湿度起始地址 0 代表温度 4 个字、地址 8 代表湿度 4 个字每个字都是 signed short。用 NModbus 库时不要直接用ReadHoldingRegisters返回的 ushort 数组手动强制转换为 short 是必要的一步。5.2 现象程序运行两三个小时之后轮询突然全部超时原因TCP 连接受到了 TCP Keep-Alive 的影响或服务端闲置超时被断开。温室环境远端的采集器网关多数是嵌入式 Linux空闲连接默认 120 秒没数据传输就断开。上位机如果一直没检测到断线下一次ReadHoldingRegisters会在ReadExactly抛IOException如果异常处理不当轮询线程直接崩掉。解决两点。第一轮询间隔超过 60 秒的场景下单独开一个轻量心跳线程每 30 秒发一次0x03读一个寄存器保持连接活跃。第二Connect()方法里设置 TCP KeepAlive 系统参数让操作系统层面每隔 10 秒探测连接。生产级代码里断线后要做指数退避重连比如 5 秒、10 秒、20 秒、60 秒避免设备重启期间上位机疯狂重连把网关打挂。5.3 现象设备在调度室明明看到有数据上位机页面上状态却显示离线原因不是设备离线是轮询线程死锁。最常见的位置在AddRecord方法里lock (_recordLock)作用范围过大把数据库操作也锁在内部而数据库写操作偶尔会因为磁盘繁忙卡住几秒这段时间内通讯线程调用AddRecord被堵死轮询无法继续界面当然收不到新数据。解决锁的作用范围要尽量小。只保护_pendingRecords的读和清空数据库连接和提交一律在锁外完成。另一个做法是引入BlockingCollection作为数据管道生产者通讯线程只管 Add消费者定时落库线程用GetConsumingEnumerable批量取两端互不阻塞。这个改造通常让温室监控系统的稳定性从「两小时重启一次」提升到「半年不关机」。5.4 现象重启上位机后昨天的历史曲线消失了原因SQLite 事务没有提交或者提交时机不对。早期版本如果直接cmd.ExecuteNonQuery()逐条插入只要没显式调用BeginTransactionSQLite 默认自动提交模式下每写一条落一次盘断电或程序崩溃时最后几条会丢。更隐蔽的问题是用了事务批量插入但Commit()前主线程崩了所有未提交数据一起丢。解决把提交频率和时机明确每 200 条或者每 5 秒触发一次FlushRecords程序退出事件里调用FlushRecords把尾部数据落完数据库文件写完后用PRAGMA synchronous NORMAL折合性能与安全。上位机断电属于正常现象不要承诺零丢失但 5 秒粒度内的数据丢失是可以做到的。5.5 现象串口转 Modbus 时偶尔读到一帧错乱的大数值原因RS485 串口通讯没有 TCP 的可靠传输保障总线上的噪声、浪涌、地电位差都可能让一帧数据的某个位翻转。如果上位机的串口驱动没做校验和处理CRC 错误的帧会被直接丢弃正确数据丢失更糟的情况是上位机把错误帧里某个字节解析成了极高的值比如把寄存器 0xFFFF 当作 65535。解决Modbus RTU 自带 CRC16 校验上位机如果接了DataReceived事件手动解析一定要校验 CRC 再处理数据同时给数据加范围过滤温度超过 0~60 度、湿度超过 0~100% 的点位直接标记异常不参与落库。还有个工程办法给每个测点加一个「最大变化率」限制一秒钟温度跳变 20 度必然不对直接丢弃等待下一轮更新。工业抗干扰设计讲究的是——不是防住所有错误而是让错误的危害最小。6. 进阶玩法用 C# 给温室监控加一个 OPC 接入层和 Web 远程看板6.1 必要时再接 OPC西门子 PLC 联动场景如果温室里灌溉用的是西门子 S7-1200 PLC传感器数据通过 Modbus 网关还能绕过去但你要是想反向控制 PLC 开启灌溉阀门最干净的方案是接 OPC。C# 连接西门子 OPC 的常见做法有两种。一种是 OPC DA 2.0引用OpcRcw互操作程序集通过Opc.Da.Server连接本机或远程 OPC 服务器读取 Item 的方式是// 需要引用 OPC Core Components Redistributable var server new Opc.Da.Server(new Opc.URL(opcda://192.168.1.100/OPC.SimaticNET)); server.Connect(); var item new Opc.Da.Item { ItemName S7:[S7 connection_1]DB1,REAL0 }; var result server.Read(new[] { item }); // result[0].Value 就是PLC里的温度值另一种是 OPC UA用官方 SDK配置证书和端点地址代码结构类似但类型是异步的。OPC 的坑在于Item Name 的语法没有统一标准西门子用S7:[连接名]DB块,偏移量施耐德又是另一套所以配置一定要外置到device_config.json而不是写死在代码里。6.2 C# 内置 HttpListener做一个局域网温室看板很多甲方会在办公室而不是大棚里看数据。不需要额外装 Web 服务器C# 自带的HttpListener就能承担一个轻量级 APIpublic void StartWebServer(int port) { var listener new HttpListener(); listener.Prefixes.Add($http://:8080/); listener.Start(); Task.Run(() { while (_webRunning) { var ctx listener.GetContext(); var res ctx.Response; if (ctx.Request.Url.AbsolutePath /api/current) { string json JsonSerializer.Serialize(_currentValues); byte[] data Encoding.UTF8.GetBytes(json); res.ContentType application/json; charsetutf-8; res.ContentLength64 data.Length; res.OutputStream.Write(data, 0, data.Length); } res.Close(); } }); }http://:8080/表示监听所有网卡地址局域网内手机访问http://工控机IP:8080/api/current就能拿到当前的实时数据 JSON前端页面用 ECharts 画曲线整个远程看板不需要额外安装任何运行时。需要注意HttpListener在非管理员权限下监听非 localhost 前缀可能抛AccessDenied用管理员运行上位机或者用netsh http add urlacl urlhttp://:8080/授权。这个技巧在 LabVIEW 上位机里要用到 Web 模块付费功能C# 里是原生支持对比下来也是很多项目选择 C# 的原因之一。6.3 给源码加一个控制下发通道从「只看」到「能控」温室监控系统做完采集和显示后下一步必然是控制——卷膜电机的开关、风机的启停、补光灯的亮度调节。Modbus TCP 的控制比读取要简单寄存器写入即可public bool WriteSingleRegister(byte slaveId, ushort address, ushort value) { byte[] request new byte[12]; ushort transactionId (ushort)(DateTime.Now.Millisecond 0xFFFF); request[0] (byte)(transactionId 8); request[1] (byte)(transactionId 0xFF); request[2] 0x00; request[3] 0x00; request[4] 0x00; request[5] 0x06; request[6] slaveId; request[7] 0x06; // 功能码06写单个寄存器 request[8] (byte)(address 8); request[9] (byte)(address 0xFF); request[10] (byte)(value 8); request[11] (byte)(value 0xFF); // 发送并读取响应响应帧应当与原请求完全一致 // ... 省略发送代码 }写控制功能要遵循一条铁律写之前先确认当前设备状态写之后要立刻回读确认。例如控制卷膜机上位机下发0x0001表示开启然后马上读一次运行状态寄存器如果设备没有反馈「已开启」界面要弹出红色警告而不是假装成功。手动控制是温室事故的高发区——半夜温度骤降值班员远程点了「关窗」结果执行器没动作第二天冻伤一批苗追责起来就是上位机的反馈逻辑不到位。我做这类项目养成的习惯是任何控制指令都写审计日志包括指令内容、操作人、下发时间和设备回读确认结果。这个日志不用单独建表直接复用现有 SQLite 库加一条control_log表几行代码的事换来的是事故出现时能说清楚责任边界。希望这个习惯对你也有用它能在交付后帮你少接很多半夜电话。从拉通通讯到界面刷新从 SQLite 落库到 Web 看板再到控制下发这一套下来一个能真正跑在现场的 C# 上位机温室监控系统源码才算完整。照着文章把代码敲一遍、把设备的寄存器地址表对一遍你手上就有了一个可以无限扩展的底子——下一台设备、下一个大棚改配置就能上这才是这份源码真正值得投入的地方。希望帮到你。本文还有配套的精品资源点击获取