免费物联网组态平台选型指南：ThingsBoard与FUXA实战解析

我前阵子帮人评估一个设备远程运维项目，对方找了一圈商业组态软件，报价基本按“点”算钱，一套画面加几十个变量，授权费直接够买两三块工业网关。他很无奈地问我：有没有那种不花钱买授权、平台自带组态画布、设备接上就能拖拽出监控界面的物联网云平台？

这个问题很典型，但答案没有想象中简单。市面上确实有不少带“可视化”或“组态”能力的平台，真正免费的路径也有几条，但每条路的边界、坑、隐藏成本都不一样。这篇文章我就从“组态”到底是什么需求出发，把免费自带组态的主流方案盘一遍，再讲清楚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 平台特点对照表

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，默认租户账号是tenant@thingsboard.org，密码tenant，进入后第一件事改成自己的强密码。

这里有个容易踩的坑：如果你用的是云厂商的服务器，8080端口必须在安全组/防火墙里放行，否则网页打不开。系统防火墙那边同样要加白名单：

ufw allow 8080/tcp

3.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/telemetry，Payload必须是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组件”和“嵌入组件”，可以直接写HTML+JavaSript，甚至嵌入ECharts。很多高端大屏其实就是用这类Widget自研的。

3.4 规则引擎：让画面自己“报警”

组态页面光看数据还不够，报警动作得让平台自动做。ThingsBoard的规则引擎是这个平台最值钱的地方之一。

左侧菜单“规则链”打开默认的“Root Chain”，在里面添加一条处理温度的规则。思路是：

1. 添加一个“Script”节点，判断msg.temperature是否大于32。
2. 如果为真，接到“Create Alarm”节点，生成一条报警记录。
3. 报警记录可以在仪表盘里用“报警列表”组件直接显示。

Script节点里写的是JS：

if (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 启动FUXA

FUXA是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的“设置”或者“设备”页面，新建一个设备：

• 类型选择MQTT
• Broker地址填你的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软件。开源方案能帮你把项目早期验证成本压到最低，但不要迷信“免费能解决所有问题”。

我个人现在给任何人推荐平台前，都会先问三个问题：数据最后给谁看？设备规模到多少？现场谁会来维护系统。这三个问题想清楚，再回头看这些免费平台，其实选择已经不太多了。

最后分享一个小经验：无论选哪一款，先在本地用模拟设备跑一周，把部署、画页面、告警、重启、备份这些动作全部过一遍，再决定要不要用到生产环境。平台的功能清单再漂亮，也不如你自己亲手踩一次坑来得实在。