1. 为什么我最终选了Ricon组态系统来做物联网监控平台1.1 从一次真实的选型纠结说起去年下半年我接手了一个不大不小的活儿给一个园区做一套设备监控平台要接入的传感器大概有六七十个点位包括温湿度、烟感、水浸、电表、门禁状态这些。需求方给的时间很紧预算也不算宽裕但要求界面得像样、数据要能实时刷新、报警要能推送到手机端还得支持历史曲线查询和报表导出。摆在面前的路其实就三条。第一条是纯自研用Vue或者React写前端后端用Spring Boot或者Node.js数据库上时序库。这条路我熟但工期至少两个月起步而且后期维护成本高需求方自己没人能接手。第二条是直接买商业物联网平台功能全但按点位收费六七十个点位一年下来费用不低而且数据在别人服务器上需求方有点介意。第三条就是组态系统拖拖拽拽把界面搭出来脚本写点逻辑部署到自己的服务器上。我最后选了Ricon组态系统。原因很实在它支持Web端访问内置了物联网常用的组件库有数据采集接口能对接Modbus、MQTT这些协议而且授权方式相对灵活可以本地化部署。最关键的是需求方后续可以自己维护界面改个布局、加个标签不用每次都找我。这篇文章我就把这套平台从零搭起来的过程完整复盘一遍包括选型逻辑、环境准备、数据接入、界面组态、报警配置、性能调优以及我踩过的那些坑。如果你也在做物联网监控平台或者正在纠结用组态还是自研这篇应该能帮你省不少时间。1.2 Ricon组态系统到底是个什么东西先把概念说清楚。组态系统英文叫SCADA Configuration Software本质是一套可视化的开发工具让你不用写大量代码就能搭出监控界面。它的核心能力有三块一是图形组态就是拖控件、画流程图、绑定变量二是数据采集通过驱动去跟PLC、传感器、仪表通信三是逻辑处理用脚本或者配置的方式做报警、联动、计算。Ricon在这三块上都做得比较均衡。它的图形编辑器支持矢量绘图能导入SVG做出来的界面不会像早期组态那样一股“工业风土味”。数据采集这块它内置了Modbus RTU/TCP、OPC UA、MQTT、HTTP等常见驱动物联网场景基本够用。逻辑处理用的是JavaScript脚本对前端开发者友好不用去学什么私有脚本语言。和ThingLinks这类纯物联网平台比Ricon更偏向“监控组态”适合做本地化部署的监控中心和传统组态软件比它又更轻量、更Web化不需要装客户端。这个定位刚好卡在我需要的那个点上。1.3 这套平台最终要解决什么问题我把需求拆成了四个层次后面所有工作都围绕这四个层次展开。第一层是数据接入层。园区里的设备协议不统一有的走Modbus RTU通过串口服务器转TCP有的直接是MQTT上报还有几个老设备只有4-20mA模拟量输出得先接采集模块。这一层要解决的是“把数据拿上来”。第二层是数据处理层。原始数据上来之后要做清洗、单位换算、越限判断、变化率计算。比如温度原始值是寄存器里的整数要除以10才是摄氏度电表读数是累计值要算差值才能得到时段用电量。这一层要解决的是“把数据变成有意义的信息”。第三层是可视化层。用组态界面把设备状态、实时数据、报警信息展示出来支持大屏和PC端两种分辨率。这一层要解决的是“让人看得懂”。第四层是报警与联动层。数据越限要报警报警要能推送到手机某些场景还要触发联动比如水浸报警触发关闭电磁阀。这一层要解决的是“出事了能知道、能处理”。这四层想清楚了后面的技术选型和实施步骤就不会乱。2. 环境准备与基础架构搭建2.1 服务器与运行环境的选择Ricon组态系统支持Windows和Linux两种部署方式。我选的是Linux具体是Ubuntu 22.04 LTS原因是稳定、资源占用低、远程维护方便。服务器配置不用太高我用的是一台4核8G的云主机跑Ricon加上MySQL和MQTT BrokerCPU常年占用在15%以下内存占用大概3G左右。如果点位数超过500个建议上8核16G。安装过程不复杂官方提供了deb包和tar.gz两种。我用的是tar.gz解压到/opt/ricon目录然后配置systemd服务让它开机自启。这里有个细节要注意Ricon默认用的端口是8080和1883MQTT如果服务器上已经有其他服务占了这两个端口要在配置文件里改掉。我就因为服务器上先装了别的Web服务8080被占用排查了半小时才发现。数据库我用的是MySQL 8.0Ricon的历史数据存储支持MySQL和PostgreSQL我选MySQL是因为运维更熟悉。建库的时候字符集要用utf8mb4排序规则用utf8mb4_general_ci不然中文标签会乱码。这个坑我踩过界面上的中文变量名全变成问号后来改字符集重建库才解决。2.2 网络拓扑与设备接入规划网络这块我画了个简单的拓扑传感器和仪表先接到串口服务器或者采集网关网关通过交换机接入园区内网Ricon服务器也接在同一内网。外网访问通过路由器的端口映射只开放Ricon的Web端口MQTT端口只对内网开放。这里要重点说一下物联网网关与传感器的IP关系。很多新手会搞混以为传感器有IP。实际上大部分传感器是Modbus RTU的它们没有IP只有站号Slave ID。串口服务器或者网关才有IPRicon通过网关的IP和端口去轮询下面挂的传感器。所以配置的时候一个网关对应一个IP下面挂多个站号每个站号对应一个传感器。这个逻辑理清楚了后面配数据点的时候就不会乱。我用的网关是支持Modbus RTU转TCP的配置的时候要注意串口参数波特率9600、数据位8、停止位1、无校验这是大部分传感器的默认值。如果传感器手册上写的是其他参数一定要按手册来不然通信不上。我就遇到过一个温湿度传感器波特率是19200的按9600配死活读不到数据后来翻手册才发现。2.3 Ricon的工程结构与变量规划Ricon的工程结构大概是这样的一个工程下面可以有多个画面页面每个画面可以绑定变量变量可以分组管理。我的做法是按区域分组比如“A栋”“B栋”“公共区域”每个区域下面再按设备类型分比如“温湿度”“烟感”“电表”。变量命名我定了一套规则区域_设备类型_编号_属性。比如A栋的1号温湿度传感器的温度值命名为A_TEMP_001_VALUE湿度值命名为A_TEMP_001_HUMI。这样命名的好处是后面写脚本、配报警的时候一眼就能看出这个变量是哪个区域哪个设备的什么属性不用去翻变量表。变量类型也要规划好。Ricon支持多种数据类型我常用的有BOOL用于开关状态INT用于整数读数FLOAT用于需要小数精度的值STRING用于设备编号之类的文本。这里有个经验能用INT就不要用FLOAT因为浮点数在传输和计算时容易有精度问题而且占带宽。比如温度传感器原始值是整数我就在脚本里除以10得到实际值变量本身还是INT。3. 数据采集与协议对接实操3.1 Modbus RTU over TCP的配置细节园区里大部分传感器是Modbus RTU的通过串口服务器转成TCP。在Ricon里配置的时候先建一个Modbus TCP驱动填上网关的IP和端口一般是502。然后建从站填站号。接着建数据点填寄存器地址和数据类型。寄存器地址这块有个容易搞错的地方Modbus的地址有四种线圈0x、离散输入1x、输入寄存器3x、保持寄存器4x。Ricon里配置的时候要选对功能码。比如读温度传感器手册上写的是“输入寄存器地址0x0001”那在Ricon里就要选功能码04读输入寄存器地址填1。如果选错了功能码读出来的数据要么是0要么是乱七八糟的值。数据类型也要注意。Modbus寄存器是16位的如果传感器返回的是32位浮点数就要占两个寄存器Ricon里要选FLOAT32并且注意字节序。字节序有大端小端之分不同厂家的设备可能不一样。我遇到过一个电表手册上写的是大端但实际读出来是反的后来改成小端才正常。这个只能试试之前先查手册手册没写就两种都试一下。轮询周期我设的是5秒。这个值要权衡设太短网关和服务器压力大设太长数据刷新不及时。对于温湿度这种变化慢的5秒足够对于电表这种需要算功率的可以设1秒。Ricon支持对不同从站设置不同的轮询周期这个功能很实用。3.2 MQTT设备的数据接入有几个新装的传感器是直接支持MQTT的它们自己会往Broker发数据。我在服务器上装了个EMQX作为MQTT BrokerRicon通过MQTT驱动订阅这些主题。MQTT接入的关键是主题规划和Payload解析。我定的主题格式是park/{区域}/{设备类型}/{设备编号}/data。比如park/A/temp/001/data。Payload是JSON格式比如{temp: 25.3, humi: 60.2, battery: 95}。在Ricon里配置MQTT驱动的时候填上Broker地址和端口然后订阅主题。Ricon支持通配符订阅比如park////data可以订阅所有设备的数据。收到数据后用脚本解析JSON把值赋给对应的变量。这里要注意JSON解析的性能如果每秒有几百条消息脚本里不要做太复杂的操作不然会阻塞。还有一个细节MQTT的QoS等级。我设的是QoS 1保证消息至少送达一次。QoS 2虽然更可靠但开销大对于监控数据来说没必要。QoS 0可能会丢消息也不适合。3.3 模拟量采集模块的对接有几个老设备只有4-20mA输出我用了模拟量采集模块模块通过Modbus RTU接入。这种模块一般有8个通道每个通道对应一个寄存器读出来的值是0-65535的整数对应4-20mA。换算公式是这样的实际物理量 (读数值 / 65535) * (量程上限 - 量程下限) 量程下限。比如一个压力传感器量程是0-1.6MPa输出4-20mA采集模块读到的值是32768那实际压力 (32768/65535) * (1.6 - 0) 0 ≈ 0.8MPa。这个换算我在Ricon的脚本里做用一个公共函数处理所有模拟量通道都调这个函数。这样以后加通道或者改量程只改函数参数就行不用每个点都改。3.4 数据采集的稳定性调优数据采集最怕的是断线。网关断电、网线松动、传感器故障都会导致数据中断。我的做法是在Ricon里配了通信状态监测每个从站都有一个“通信正常”的标志位如果连续3次轮询失败就置为false界面上对应的设备图标变灰同时触发一条“通信中断”报警。另外Ricon支持数据缓存。当网络中断时采集到的数据可以先存在本地等网络恢复后再补传。这个功能对于网络不稳定的现场很有用。我设的缓存大小是10000条大概能存几个小时的数据。还有一个经验不要把轮询周期设得太短。我一开始设了1秒结果网关的CPU占用很高偶尔会丢包。后来改成5秒稳定多了。对于大部分监控场景5秒的刷新率完全够用人眼根本感觉不到差别。4. 组态界面设计与可视化实现4.1 画面布局与分辨率适配Ricon的画面编辑器支持绝对定位和相对定位两种布局方式。我做的是大屏和PC端两套画面大屏分辨率是1920x1080PC端是1440x900。两套画面共用同一套变量只是布局不同。大屏画面我分成了三个区域左侧是设备列表和导航中间是园区平面图右侧是实时数据和报警列表。平面图上用图标表示设备位置图标颜色表示状态绿色正常、黄色预警、红色报警、灰色离线。这个设计的好处是一眼看过去就知道哪个区域有问题。PC端画面更偏向表格和曲线因为PC端一般是运维人员用他们更关心具体数值和历史趋势。我用Ricon的表格组件做了设备列表支持排序和筛选用曲线组件做了历史趋势可以叠加多条曲线对比。这里有个细节Ricon的组件默认样式比较朴素我通过自定义CSS把按钮、表格、图标的样式调了一遍整体看起来更现代。CSS可以直接在Ricon的样式设置里写也可以外链一个CSS文件。我建议外链方便统一管理。4.2 实时数据绑定与刷新机制Ricon的变量绑定很直观选中组件在属性里找到“绑定变量”选择对应的变量就行。但这里有个性能问题如果画面上有几百个组件都绑定了变量每次数据刷新都会触发大量DOM操作画面会卡。我的优化做法是把不需要实时刷新的组件设为“按需刷新”比如设备列表里的设备名称、编号这些静态信息只在画面加载时刷新一次只有数值、状态这些需要实时更新的才绑定变量。另外Ricon支持数据分片刷新可以把画面上的组件分成几组每组设置不同的刷新周期。我把实时性要求高的比如报警状态设为1秒刷新实时性要求低的比如温度显示设为5秒刷新。还有一个技巧对于数值显示不要直接绑定原始变量而是绑定一个经过格式化的变量。比如温度原始值是253我建一个脚本变量值是(253/10).toFixed(1)显示出来就是25.3。这样既保证了精度又避免了在组件层面做太多计算。4.3 历史曲线与报表功能实现历史曲线是监控平台的核心功能之一。Ricon的历史数据存在MySQL里曲线组件可以直接查询。我配了三种查询方式实时曲线最近1小时、历史曲线指定时间段、对比曲线多设备叠加。实时曲线我设的是每5秒取一个点显示最近1小时的数据这样曲线上有720个点足够看出趋势。历史曲线支持按小时、按天、按周查询数据量大的时候Ricon会自动做降采样保证曲线渲染流畅。报表功能我用的是Ricon的报表组件支持导出Excel和PDF。报表模板我做了三个日报、周报、月报。日报显示每小时的均值、最大值、最小值周报和月报显示每天的统计数据。导出的时候要注意时区问题Ricon默认用的是服务器时区如果服务器时区不对报表上的时间会错。我一开始没注意报表上的时间比实际早了8小时后来把服务器时区改成Asia/Shanghai才正常。4.4 界面交互与用户体验优化组态界面不只是“能看”还要“好用”。我做了几个交互优化第一加了画面跳转和返回按钮。大屏上点击某个设备图标可以跳转到该设备的详情页详情页有返回按钮。这个用Ricon的画面跳转功能实现很简单但很实用。第二加了数据筛选和搜索。设备列表支持按区域、按类型筛选也支持按设备编号搜索。这个用Ricon的表格组件配合脚本实现筛选逻辑写在脚本里。第三加了报警声音。有新的报警时播放提示音。Ricon支持播放音频文件我把音频文件放在工程的资源目录里报警触发时用脚本调用播放。注意浏览器有自动播放限制需要用户先交互一次才能播放声音所以我在画面加载时加了一个“点击启用声音”的提示。第四做了移动端适配。Ricon的画面在手机浏览器上也能打开但布局会乱。我单独做了一套移动端画面用响应式布局组件尺寸用百分比而不是固定像素。这样运维人员用手机也能看数据、收报警。5. 报警配置与联动逻辑实现5.1 报警规则的配置方法Ricon的报警配置很灵活支持多种触发条件越上限、越下限、变化率、通信中断、自定义脚本。我常用的几种温度报警上限30度下限5度死区2度。死区的作用是防止在临界值附近频繁报警。比如温度到了30度触发报警降到28度以下才恢复这样不会在29.9和30.1之间来回跳。通信报警连续3次轮询失败触发。这个前面说过了。变化率报警温度1分钟内变化超过5度触发。这个用于检测异常情况比如设备故障导致温度骤升。自定义脚本报警比如电表功率超过阈值且持续10分钟触发。这个用脚本实现在脚本里做计时和判断。报警级别我分了三级提示蓝色、警告黄色、严重红色。不同级别对应不同的推送策略提示只在界面上显示警告推送到手机严重同时推送到手机和邮件。5.2 报警推送与通知渠道报警推送我用了三种渠道界面弹窗、手机App推送、邮件。界面弹窗是Ricon自带的配置简单但需要用户开着画面才能看到。手机App推送我用的是Ricon的移动端App配置好服务器地址和账号就行。邮件推送需要在Ricon里配置SMTP服务器我用的是企业邮箱的SMTP配置的时候要注意端口和加密方式大部分邮箱用的是465端口SSL或者587端口TLS。这里有个坑邮件推送频率不能太高不然会被邮箱服务商当成垃圾邮件。我设的是同一报警5分钟内只发一次避免报警风暴时邮箱被轰炸。5.3 联动逻辑的脚本实现联动逻辑我用JavaScript脚本实现。Ricon的脚本引擎支持ES6语法可以访问所有变量也可以调用Ricon的API。举几个我实际做的联动水浸报警联动当某个水浸传感器报警时自动关闭对应区域的电磁阀。脚本逻辑是监听水浸变量如果变为true找到对应的电磁阀变量设为false关闭。温度联动当机房温度超过35度时自动开启备用空调。脚本逻辑是监听温度变量如果超过35度且备用空调未开启则开启如果降到30度以下则关闭。照明联动当门禁检测到有人进入且光线传感器显示暗时自动开灯。这个逻辑稍微复杂一点要同时判断两个条件。写联动脚本的时候要注意不要写死循环不要在脚本里做耗时操作不要频繁写数据库。我一般把联动逻辑放在变量变化事件里而不是定时轮询里这样效率更高。5.4 报警记录与统计分析报警记录存在MySQL里Ricon自动建表。我做了个报警统计画面显示每天的报警次数、报警类型分布、报警处理时长。这个对于运维很有用可以看出哪些设备问题多、哪些时段报警集中。报警处理时长是指从报警触发到报警恢复的时间。我设了一个目标严重报警处理时长不超过30分钟警告不超过2小时。超过目标的报警会在统计里标红提醒运维关注。还有一个功能报警确认。运维人员可以在界面上点击“确认”按钮表示已经知道这个报警了。确认后报警不再弹窗但记录还在。这个功能避免了报警一直弹窗干扰操作。6. 性能调优与常见问题排查6.1 系统性能瓶颈的定位与优化平台上线后跑了一段时间我发现几个性能问题第一个是数据库查询慢。历史曲线查询一个月的数据时要好几秒才能出来。原因是数据表没有索引。我在时间字段上加了索引查询时间降到几百毫秒。另外我把历史数据做了分区按月分区这样查询时只需要扫描对应月份的分区速度更快。第二个是画面加载慢。大屏画面有几百个组件首次加载要5秒以上。我做了几个优化组件懒加载不在可视区域的组件不渲染图片压缩把大图压到合适尺寸CSS和JS合并压缩。优化后加载时间降到2秒以内。第三个是MQTT消息积压。设备多的时候每秒有几百条消息Ricon处理不过来消息在Broker里堆积。我把MQTT驱动改成多线程模式并且把消息处理逻辑简化只做必要的解析和赋值不做复杂计算。这样处理能力提升了一倍多。6.2 通信故障的排查思路通信故障是最常见的问题我总结了一套排查流程第一步看Ricon的通信状态。如果某个从站显示通信中断先确认是单个从站还是整个网关下的所有从站都中断。单个中断一般是传感器或线路问题全部中断一般是网关或网络问题。第二步用工具测试。Modbus的话我用Modbus Poll或者mbpoll命令行工具直接连网关看能不能读到数据。如果能读到说明网关和传感器没问题问题在Ricon配置如果读不到说明问题在网关或传感器。第三步检查物理层。网线是否插好、串口线是否接对、传感器供电是否正常。我遇到过一次传感器供电不足导致通信时断时续换了电源就好了。第四步检查配置。站号、波特率、寄存器地址、功能码这些都要跟手册核对。我遇到过一次站号配错把1号配成了2号结果读出来的是另一个传感器的数据数值完全不对。6.3 数据异常的处理经验数据异常有几种情况数值超范围、数值不变、数值跳变。数值超范围一般是量程配错了或者传感器故障。我遇到过一次温度显示200多度后来发现是传感器坏了换了一个就好了。数值不变可能是传感器卡死也可能是通信中断但Ricon没有正确标记。我在脚本里加了一个判断如果某个变量的值连续10次轮询都没有变化就标记为“疑似故障”提醒运维检查。数值跳变可能是干扰也可能是传感器本身的问题。我在脚本里加了滤波用滑动平均法取最近5次的平均值作为显示值。这样曲线会平滑很多但会有一点延迟。对于需要快速响应的报警滤波后的值只用于显示报警判断还是用原始值。6.4 常见问题速查表问题现象可能原因排查方法解决方案通信中断网线松动检查网线指示灯重新插拔网线通信中断网关断电检查网关电源恢复供电通信中断站号配错核对传感器手册修改站号数据为0功能码选错核对寄存器类型修改功能码数据乱码字节序错误试大端和小端修改字节序数据跳变干扰检查屏蔽线接地加滤波或换屏蔽线画面卡顿组件过多查看组件数量懒加载或分页曲线加载慢无索引查看数据库慢查询加索引或分区报警不推送SMTP配置错误测试邮件发送修改SMTP配置中文乱码字符集不对查看数据库字符集改为utf8mb47. 部署上线与后续扩展的一些体会7.1 从测试环境到生产环境的迁移测试环境跑通之后迁移到生产环境不是简单复制粘贴。我做了几件事第一把测试数据清空重新初始化数据库。测试时积累的历史数据不要带到生产环境不然报表统计会乱。第二检查所有配置。IP地址、端口、账号密码这些在测试环境和生产环境可能不一样。我列了个清单逐项核对。第三做压力测试。用脚本模拟所有设备同时上报数据看系统能不能扛住。我模拟了200个点位每秒上报一次跑了半小时系统稳定。第四做备份策略。数据库每天凌晨自动备份备份文件保留30天。Ricon的工程文件也定期备份防止配置丢失。7.2 系统上线后的运维要点上线后我每周做一次巡检检查这几项服务器CPU、内存、磁盘占用数据库大小和增长趋势通信状态有没有频繁中断的设备报警统计有没有异常多的报警。每月做一次优化清理过期数据压缩数据库检查日志看有没有异常报错更新Ricon版本如果有新版本的话。这里有个经验不要频繁更新Ricon版本。新版本可能有新功能但也可能引入新bug。我一般等新版本发布一个月后看社区反馈没问题再更新。更新前一定要备份工程和数据库。7.3 平台后续可以扩展的方向这套平台目前满足了基本需求但还有不少可以扩展的地方。一个是接入更多协议。现在主要是Modbus和MQTT以后可以加OPC UA、BACnet对接楼宇自控系统。一个是做数据分析。现在只有实时监控和历史曲线以后可以加预测性维护用历史数据训练模型预测设备什么时候可能故障。一个是做移动端优化。现在的移动端画面还比较简陋以后可以用Ricon的移动端SDK做原生App体验更好。还有一个是做多租户。如果以后要给多个园区用可以做成多租户架构每个园区独立管理自己的设备和数据。7.4 我踩过的几个印象深刻的坑最后分享几个我踩过的坑希望能帮你避开。第一个坑服务器时间不对。Ricon的报警记录、历史数据都依赖服务器时间如果时间不对所有记录都会错。我一开始没注意服务器时间是UTC比北京时间早8小时结果报警记录的时间全是错的。后来把服务器时区改成Asia/Shanghai并且配了NTP自动同步才解决。第二个坑数据库连接数不够。Ricon默认的连接池大小是10点位数多了之后连接不够用偶尔会报“too many connections”。我把连接池调到50并且优化了查询避免长连接占用。第三个坑MQTT主题订阅过多。我一开始用通配符订阅所有主题设备多了之后Broker要匹配大量主题性能下降。后来改成按区域订阅每个区域一个主题前缀减少了匹配开销。第四个坑脚本里的异步操作。Ricon的脚本引擎支持异步但如果用不好会导致变量赋值顺序错乱。我一开始在脚本里用了setTimeout结果变量值更新不及时报警判断出错。后来改成同步操作或者用Promise链才稳定。第五个坑界面组件绑定变量过多。一个画面上绑了几百个变量每次刷新都卡。后来把不需要实时刷新的组件改成静态显示只在需要的时候用脚本更新流畅多了。这套平台从零搭起来前后花了大概三周时间其中一周在调试通信和报警。现在运行了半年多整体稳定需求方也比较满意。如果你也在做类似的项目希望这篇复盘能帮你少走点弯路。组态系统不是万能的但在监控平台这个场景下它确实能省很多事。关键是前期把变量规划好、把通信调通、把报警配准后面就轻松了。