我前阵子帮人评估一个设备远程运维项目对方找了一圈商业组态软件报价基本按“点”算钱一套画面加几十个变量授权费直接够买两三块工业网关。他很无奈地问我有没有那种不花钱买授权、平台自带组态画布、设备接上就能拖拽出监控界面的物联网云平台这个问题很典型但答案没有想象中简单。市面上确实有不少带“可视化”或“组态”能力的平台真正免费的路径也有几条但每条路的边界、坑、隐藏成本都不一样。这篇文章我就从“组态”到底是什么需求出发把免费自带组态的主流方案盘一遍再讲清楚ThingsBoard、FUXA这两条最值得走的路怎么落地最后给出按场景可以直接抄的选型清单。1. 别急着选平台先把“组态”想清楚1.1 组态不是“画个好看的图”而是要解决现场问题很多人一上来就问“哪个平台有组态”但“组态”这个词在不同行业里含义完全不同。做工业自动化的工程师组态指的是像WinCC、组态王、MCGS那样把水泵、阀门、管道、温度传感器做成SVG图形连上PLC变量在电脑上模拟出一块真实的生产流程图做物联网App的人组态更多是数据可视化看板把设备的温度曲线、电量、地理位置尽量直观地摆出来还有一批人想要的其实是大屏展示领导视察用的重点在华丽的数据动效。这三类需求需要的技术栈不一样。第一类需要图形编辑器、图元绑定、告警闪烁这些工控属性第二类需要实时数据库、时间序列曲线、设备管理第三类则需要地图、图表库、3D效果。选平台之前不把这些需求拆开很容易出现“装好了发现画不了阀门状态”或者“能画阀门但是数据刷新跟不上”的尴尬。1.2 三类常见组态需求匹配完全不同的平台我习惯把物联网组态需求分成三类。第一类是设备调试型。典型场景是你手上有一批4G模块、ESP32、DTU往云平台上报温度和湿度你想快速画一个能看实时数据、查历史曲线的页面方便自己远程调试。这类需求不需要太强的工控图形能力只要设备接入快、界面能拖拽、免费额度够用就行。第二类是业务流程型。设备数据不只是“看”的还要触发动作温度超过阈值要告警门禁被打开要出事件电池电量低要通知维护人员。这类需求要求平台有规则引擎、告警中心、消息推送组态界面只是其中一个环节更重要的是数据能“流动”起来。第三类是生产监控型。面向车间、泵站、配电房等场景画面要还原现场工艺流程要有管道、泵、阀门、小车最好还能从CAD图纸导入底图。这种需求对图形组态的要求最高普通的可视化看板不够用得用SCADA风格的组态工具。现在很多人在推荐平台时不区分这三种需求只告诉你“支持MQTT、有可视化”结果往往要自己二次开发填坑。1.3 免费不等于零成本先列出你的约束条件判断一个物联网云平台能不能用不要只盯“免费”两个字还要看四个约束条件。第一免费是使用年限免费还是每天有配额有的平台提供“免费试用30天”到期后设备数、消息数、存储天数都缩水。第二你能否接受自托管开源平台本身免费但需要一台能7x24小时运行的服务器还要自己维护数据库、升级版本、处理故障。第三组态能力是“卡片式拖拽”还是“自由画布”大部分云平台的可视化只是把图表组件拖进页面做不到像素级自由的工控组态。第四数据掌握在谁手里用别人的云平台数据从设备到平台再到你手里链路清晰但数据归属和迁移要提前想清楚。把这些问题列出来选型方向立刻就清晰了。2. 自带组态的免费平台全景盘点2.1 运营商级云平台OneNET的免费额度与可视化能力OneNET是国内被大量物联网毕设和中小项目使用的云平台上手门槛低官方文档齐全设备接入用MQTT、HTTP、CoAP都行。在“免费自带组态”这个命题下OneNET的定位是托管的SaaS平台不需要你自己维护服务器注册账号就能用。OneNET的可视化能力叫作OneNET View核心价值是“基于设备数据流直接拖出页面”。你把设备通过MQTT接入平台数据流进入数据流服务然后在View工程里拖图表组件、绑定数据流就能生成一个可分享的监控页面。对于温度、湿度、GPS坐标、开关状态这类型数据非常顺手。但它不是万能的。OneNET View适合做数据可视化看板、设备状态总览不太适合做“阀门管道泵”那种工控流程图。而且OneNET的免费模式不是无限量设备数和API调用次数都有配额超出部分要按量计费。我见过不少做毕设的同学把设备数据周期设成1秒上报结果免费额度很快耗尽。这一点后面详细说。2.2 开源自托管一哥ThingsBoard CE如果只能推荐一个“功能最全、组态也够用”的免费方案我会选ThingsBoard社区版。ThingsBoard是一个开源的物联网平台社区版CE使用Apache 2.0协议可以免费商用、自行部署。它自带设备管理、数据采集、规则引擎、RPC控制、报警管理和可视化仪表盘Dashboard。这里的Dashboard虽然不是传统SCADA组态软件但它支持实体别名、Widget绑定、仪表盘状态互相跳转配合HTML Widget能够实现绝大多数物联网监控场景。ThingsBoard的设备接入体验做得很好MQTT、HTTP、CoAP、OPC UA这些主流协议都有设备创建后生成Access Token设备端只要把Token塞进MQTT的username里往指定Topic发数据平台就自动接收并存储。数据链路非常透明排查问题也容易。社区版免费代价是自己部署。一台2核4G内存的云服务器装Docker和官方compose文件跑起来后你是这套平台的真正拥有者。没有按设备数计费没有数据保留期限限制很多做产品原型、私有化交付的公司都在用这条路。它的规则引擎也能实现“温度超限后自动创建报警”配合仪表盘的报警组件实时告警界面几分钟就能搭出来。2.3 工业组态气质FUXA如果你想画的不是“花哨看板”而是真正的工业监控画面FUXA是值得关注的开源组态软件。FUXA定位是Web SCADA/HMI它的画布逻辑和组态王很像左侧是图元库中间是自由画布右侧是属性面板。你可以导入SVG底图把电机、阀门、液位罐等图元拖到画布上再为每个图元绑定数据源数据一变图形颜色、文字、旋转角度都跟着变。FUXA本身不带设备管理、用户权限、报警工单这些物联网平台该有的完整链路它更像一个“组态引擎”负责把数据变成图形交互界面。它支持MQTT、OPC UA、Modbus TCP/RTU等协议也内置了一个MQTT Broker可以直连设备。实际项目里很多人把FUXA和ThingsBoard配合用ThingsBoard负责接设备、存数据、跑规则FUXA负责呈现工控画面。也有更轻量的用法不管平台FUXA直接连MQTT网关当一个纯上位机画图工具。2.4 灵活编排Node-RED Dashboard还有一类不算严格“组态”但也经常被拿来当组态用的方案就是Node-RED。Node-RED是一个可视化流编辑工具浏览器里拖拽节点就能把MQTT消息、HTTP请求、数据库读写串起来。它自带的Dashboard节点可以提供图表、仪表盘、开关、滑动条等组件虽然样式偏网页风但胜在极其灵活。适合什么场景呢快速原型、内部工具、或者需要把不同系统数据揉在一起展示的场景。比如你有一台设备走MQTT另一套系统暴露了HTTP接口你想把两边数据放在同一块屏幕上看Node-RED半个小时内就能搭完。缺点是没有账号权限体系、没有组织架构管理、界面风格比较“开发感”不适合直接交付给客户。2.5 平台特点对照表平台是否免费自带组态部署方式适合场景OneNET有免费配额超出计费OneNET View可视化托管云平台毕设、中小项目、快速上云ThingsBoard CE开源免费自行承担服务器Dashboard Widget自托管产品原型、私有化、长期生产FUXA开源免费类SCADA自由画布自托管工业监控画面、工艺流程图Node-RED开源免费Dashboard图形块自托管快速原型、多系统数据融合Grafana开源免费图表类可视化自托管时序数据监控、运维看板Grafana严格来说不是物联网平台但它在时间序列数据可视化上很强如果你的设备数据已经落入InfluxDB或Prometheus用它做监控大屏很合适。3. ThingsBoard落地实操从设备上云到拖出一块实时监控大屏这一部分我用一个具体例子走一遍完整流程一台模拟温湿度设备通过MQTT上报数据到ThingsBoard然后在Dashboard上拖出实时卡片、曲线图并配置一条温度过高报警。3.1 部署阶段一台2核4G服务器就够了ThingsBoard CE的部署方式有很多种最省事的是Docker Compose。服务器我用的是2核4G、40G系统盘、Ubuntu 22.04实测跑社区版加少量设备绰绰有余。第一步安装Docker和Compose插件curl -fsSL https://get.docker.com | bash systemctl enable --now docker第二步获取官方compose文件git clone https://github.com/thingsboard/thingsboard-docker-compose.git cd thingsboard-docker-compose这个目录里默认有一份docker-compose.yml社区版默认使用的是PostgreSQL数据库。如果你想省内存可以把目录里不需要的组件注释掉如果完全按官方默认来直接启动docker compose up -d第一次启动要拉镜像、初始化数据库耗时比较长一般五到十分钟。结束后访问http://服务器公网IP:8080默认租户账号是tenantthingsboard.org密码tenant进入后第一件事改成自己的强密码。这里有个容易踩的坑如果你用的是云厂商的服务器8080端口必须在安全组/防火墙里放行否则网页打不开。系统防火墙那边同样要加白名单ufw allow 8080/tcp3.2 设备接入MQTT客户端连上ThingsBoard进入ThingsBoard后创建一台设备左侧菜单“实体” - “设备” - 右上角“” - “新建设备”设备名称填“温湿度模拟器”保存后打开设备详情会看到一个Access Token类似Wq9jKx2mTvNc5Y8pE1sA这个Token就是设备的“门禁卡”设备端用MQTT连接时用户名填Token密码留空Broker地址填你的服务器IP端口1883。我用Python的paho-mqtt库模拟设备上报代码很简单import random import time import json import paho.mqtt.client as mqtt BROKER 你的服务器IP PORT 1883 ACCESS_TOKEN Wq9jKx2mTvNc5Y8pE1sA client mqtt.Client() client.username_pw_set(ACCESS_TOKEN) client.connect(BROKER, PORT, 60) client.loop_start() while True: data { temperature: round(random.uniform(20, 35), 1), humidity: round(random.uniform(40, 80), 1) } client.publish(v1/devices/me/telemetry, json.dumps(data)) time.sleep(5)关键点是Topic必须是v1/devices/me/telemetryPayload必须是JSON。数据发过去后在设备详情页的“最新遥测”Tab里马上就能看到temperature和humidity两条数据在滚动。除了遥测数据ThingsBoard还区分“属性”和“RPC”。属性适合存设备配置比如固件版本、安装位置RPC适合下发控制指令比如远程开关继电器。设备端订阅v1/devices/me/rpc/request/这个Topic就能收到平台下发的指令处理完再把结果发回v1/devices/me/rpc/response/请求ID。3.3 Dashboard组态把数据角色拖上画布数据上来之后开始建组态页面。左侧菜单“仪表盘” - 右上角“” - 创建新仪表盘名字叫“车间环境监控”。进入仪表盘编辑模式后第一步不是拖组件而是配置“实体别名”。原因是ThingsBoard的Widget不认识具体设备只认识“别名”。一个别名可以指向一台设备也可以指向一组设备。点击仪表盘编辑界面右上角的“实体别名”按钮新建一个别名别名类型选“单实体”过滤器选“设备”然后选定“温湿度模拟器”。这样后续所有组件都可以直接引用这个别名如果以后换设备只需要改别名不用重画页面。配置好别名后点击“”添加Widget。Widget类型很多最新遥测卡片显示温度、湿度当前值时间序列曲线显示一段时间的趋势仪表盘圆形表盘适合展示温度、压力报警列表显示规则引擎产生的告警我常用的是先把Latest Values里面的“卡片”拖进来数据源选择别名“温湿度模拟器”键名分别绑定temperature和humidity。再把Time series里的“曲线图”拖进来同样指向别名两分钟之内曲线就会出来。如果你觉得默认组件不够用ThingsBoard还有“HTML组件”和“嵌入组件”可以直接写HTMLJavaSript甚至嵌入ECharts。很多高端大屏其实就是用这类Widget自研的。3.4 规则引擎让画面自己“报警”组态页面光看数据还不够报警动作得让平台自动做。ThingsBoard的规则引擎是这个平台最值钱的地方之一。左侧菜单“规则链”打开默认的“Root Chain”在里面添加一条处理温度的规则。思路是添加一个“Script”节点判断msg.temperature是否大于32。如果为真接到“Create Alarm”节点生成一条报警记录。报警记录可以在仪表盘里用“报警列表”组件直接显示。Script节点里写的是JSif (msg.temperature 32) { return { msg: msg, metadata: msg.metadata, msgType: msgType }; } else { return null; }Create Alarm节点的具体配置可以选报警类型为“高温度”严重程度“重要”。保存规则链并重新启动再运行设备脚本温度一旦超过32仪表盘右上角就会出现未读报警。报警有了还可以继续接“发送邮件”节点或者Webhook节点把告警推给值班人员。这些节点社区版都自带不需要额外付费。3.5 实操中容易翻车的三个点第一设备脚本挂了但页面不报错。这种情况八成是Topic写错了或者Access Token填的不是用户名而是Client ID。先用MQTT客户端工具连一次确认能不能收到平台端订阅的消息。第二仪表盘上曲线是断的。要么是设备上报间隔太长要么是ThingsBoard默认的时间跨度太大数据点被聚合了。在Widget高级设置里把数据聚合函数改成“无”或者把时间窗口缩小到最近一小时就能看到变化。第三服务器重启后设备连不上。ThingsBoard启动比较慢数据库没准备好之前端口不监听。用docker compose ps看容器状态等各个容器都healthy了再重连设备。不要一看到端口没起来就反复重启反而容易把数据库搞坏。4. FUXA快速上手把SVG图元拼成车间监控画面ThingsBoard适合做物联网平台侧的业务但如果要画一张“像工控上位机一样”的流程图FUXA更对路。4.1 启动FUXAFUXA是Node.js项目可以源码运行。在服务器上执行git clone https://github.com/frangoteam/FUXA.git cd FUXA npm install npm start默认监听1881端口浏览器打开http://服务器IP:1881首次登录账号admin密码admin登录后第一件事改密码。FUXA的界面逻辑和传统组态软件一致左侧是图库、图元、工程树中间是画布可以设置背景、底图右侧是选中图元的属性面板和数据绑定区你可以直接拖一个矩形、圆形或者文字框也可以导入外部SVG文件FUXA会把它当成图元放进画布。这也是工业场景常见的操作用AutoCAD或者AI画好车间平面图导出SVG再导进FUXA作为底图然后在底图上叠加设备状态。4.2 关联MQTT数据源FUXA本身不带“设备管理”它的数据源叫做“设备”可以是MQTT、OPC UA、Modbus等协议。我拿MQTT为例。在FUXA的“设置”或者“设备”页面新建一个设备类型选择MQTTBroker地址填你的MQTT服务器地址比如ThingsBoard或者EMQX端口填1883用户名密码按Broker的要求填保存后FUXA会订阅你指定的Topic。然后回到画布选中一个图元在属性面板里找到“数据绑定”相关的配置输入Topic和字段路径比如/temperature。运行时这个图元就会根据消息内容更新显示。比如画一个液位罐罐体的填充高度绑定液位Topic文字标签绑定液位数值再画一个水泵运行状态颜色绑定泵启停Topic。设备一上报画面就活了。4.3 FUXA用来做什么最合适FUXA最舒服的场景是“你需要一块工控画面但没有复杂的多租户业务”。比如一个泵站监控项目设备数量几十台画面两三张用FUXA足够了。它的画布自由度远高于ThingsBoard的Dashboard更接近组态王的使用体验。但要注意FUXA不擅长的事情也很明显没有完整的用户权限体系报警功能相对基础数据不落库或落库要自己配。所以我的建议是如果你的项目核心是“画面”而非“平台”优先FUXA如果你的项目核心是“设备管理、告警、多用户协作”那还是ThingsBoard可靠。5. 免费平台的隐性门槛与常见避坑经验很多人选免费平台时只想着“不用掏钱”结果用起来才发现时间成本和运维成本都不低。下面几个隐性门槛你要提前有心理准备。5.1 自托管的服务器成本与运维压力开源平台免费但不代表部署成本为零。一台长期运行的云服务器按2核4G配置来算一年也有好几百块。这个钱和商业组态软件的授权费比确实很少但你要负责的事情变多了操作系统安全补丁、Docker镜像升级、数据库备份、磁盘空间清理、宕机恢复。ThingsBoard这种Java系应用比较吃内存2G内存会非常紧张我建议至少4G。数据量上来后PostgreSQL的磁盘占用也要盯。我见过有人跑了一年才发现日志把磁盘撑满数据库直接拒绝写入。所以拿开源平台做生产项目运维必须当回事。5.2 托管平台的配额与计费边界用OneNET这类托管平台省心的代价是要仔细阅读配额规则。每个平台免费额度各有侧重有的限制在线设备数有的限制每日消息条数有的限制历史数据存储天数。设备上报频率直接决定消息消耗1台设备按10秒上报一次一天就是8640条消息100台设备就是86万条这个量级很多免费额度撑不住。测方案的时候建议把上报频率拉长到30秒或60秒曲线图虽然没那么丝滑但配额能省一大截。等真正上线前再根据业务需求调整。5.3 网络安全与数据归属设备接入公网平台最常见的安全问题是设备Token泄露。MQTT的Topic里带着设备Token如果有人抓包或者盗取固件就能伪造设备上报数据。建议有条件时使用MQTT over TLS也就是8883端口同时给每台设备分配独立的设备凭据不要所有设备共用一个Token。数据归属也要在选型前想清楚。托管平台的免费额度通常不代表数据永久开放导出有些平台的数据销毁策略写在非常隐蔽的条款里。如果你做的是客户交付项目客户很可能要求数据落回本地这时候开源自托管平台就是唯一能答应的选项。5.4 数据丢了怎么办备份和导出要提前做免费平台最容易让人掉以轻心的就是备份。托管平台虽然帮你存数据但你不一定能按想要的方式导出自托管平台数据在自己服务器上丢了只能怪自己。拿ThingsBoard来说数据库定期备份是基本操作。用PostgreSQL的话写个cron脚本每天凌晨执行pg_dump把备份文件传到另一台机器或对象存储。规则链、仪表盘这些配置最好也导出一份JSON放在工程目录里否则服务器重装后画面还得重新画。6. 按场景给你的选择清单6.1 毕业设计或快速原型选型优先级OneNET ThingsBoard Node-RED。原因很现实毕设周期短一个人既要写论文又要做实物没有太多时间折腾服务器和Docker。OneNET注册就能用设备接入链路短View的拖拽方式也符合评审老师对“可视化平台”的预期。把Access Token写进ESP32代码数据上报后打开OneNET View拉两个图表一个完整演示闭环就有了。如果老师要求“自己部署一套开源平台”那就用ThingsBoard在论文里写到“基于开源技术栈的私有化物联网平台”会让技术含量高出一截。6.2 小规模设备运维选型优先级ThingsBoard FUXA Node-RED。当设备数量在几十台到一两百台之间并且你需要远程监控、报警、下发命令ThingsBoard社区版是性价比首选。规则引擎可以做到“设备离线超时通知”“数值超限告警”Dashboard可以按项目分页面展示多用户账号体系也够用。FUXA适合在这些场景里作为“画面层”做补充ThingsBoard负责数据FUXA负责把数据画成一张直观的工艺图。6.3 中大型生产监控或客户交付项目选型优先级ThingsBoard FUXA / 商业组态软件。如果客户要求1000台设备以上或者需要多租户、集中权限管理、审计日志ThingsBoard社区版会开始吃力那时候要么上ThingsBoard专业版要么引入企业级商业平台。组态层面也一样流程越复杂、图形要求越高越需要用专业SCADA软件。开源方案能帮你把项目早期验证成本压到最低但不要迷信“免费能解决所有问题”。我个人现在给任何人推荐平台前都会先问三个问题数据最后给谁看设备规模到多少现场谁会来维护系统。这三个问题想清楚再回头看这些免费平台其实选择已经不太多了。最后分享一个小经验无论选哪一款先在本地用模拟设备跑一周把部署、画页面、告警、重启、备份这些动作全部过一遍再决定要不要用到生产环境。平台的功能清单再漂亮也不如你自己亲手踩一次坑来得实在。