当前位置：首页 > news >正文

我的第一个开源项目【IOT-Tree Server】

news 2025/10/23 22:24:27

IOT-Tree Server也是我目前唯一一个开源项目。从第一次提交代码到现在已经4年，现在回头看整个软件的功能，连我自己有时候也会惊叹，这是我搞出来的么？感觉自己这些年，不断的积累改进，弄出了一栋大楼。如果当初以现在这个软件为目标，那很可能就不敢开始了。

在此先有个感慨，持续专心做一件事真的很重要！！！

先给大家看一下这个软件使用界面吧

一个实际的产线数据采集项目

一个实际的机房监控项目

1 开发这个软件的缘由

首先，我是个Java程序员，并且担任架构师和研发经理多年。开发软件到一定时间之后，总感觉缺点什么。网络上看到人家做的四轴飞行器、各种好玩的设备，心里那个痒啊！因此，在疫情之前的一些年，我除了软件开发之外，还干了如下这些事：

1 自学电子技术，玩单片机，电路设计。学习各种单片机通信协议，什么I2C,SPI之类的，也做过一些数据采集电路，并用到了一些项目中——结果就是，设备故障率怎么那么高，汗！

2 后来朋友介绍了一些物联网项目，需要对接工业控制领域设备获取数据到云端，云端使用Java开发管理平台软件。接触工业现场设备多了之后，我才意识到，我之前做的一些采集设备就是玩具——工业设备的研发，需要一颗安全可靠的敬畏之心：

真正好的产品，主线功能实现投入占比很低，设计者需要对各种可能的异常情况做应对，也需要考虑生产的效率和成本。还需要时间的考验持续改进。

我搞电子电路是半路出家，纯业余选手，就决定不继续往下搞了。

2021年的疫情期间，特殊时期只能呆家里，闲不住的我开始反思自己应该干点什么！

首先，我最擅长的还是软件开发，特别是对Java的理解，得发挥出我的优势；

其次，如果做个传统的纯软件系统，我兴趣又不大，因为类似工作流引擎、消息中间件之类的，我都尝试着做过。

再次，在工业现场对接设备时，我曾经实现过最简单的Modbus通信协议，可以从一些串行接口设备中获取数据；也曾经使用开源OPC DA库对接组态王之类的组态软件。但对于各种PLC，当时由于不了解，只能借助第三方软件——这一直是我心中的一根刺。

能不能我搞个软件，把这些对接都搞一起呢？搞一起之后，我再弄些更好用的接口（比如RESTful）不就可以让类似的物联网项目轻松实现了么？

于是我开始查找分析各种PLC的通信协议资料，最终得出结果：就干这个了。

2 软件名称为何是IOT-Tree Server

当时物联网IOT这个概念很流行，所以我这个软件就以IOT开头，那为什么跟着一棵树(Tree）呢？这里我发个开源软件首页一张图：

软件先要对接设备，吸收数据养分——这就是树根部分；汇总之后数据要被顶层各种分析使用获得价值——这不就是树上部分的枝叶和花果么。

另外，我不准备为这个软件做专门的客户端管理工具和使用工具，web管理端开发即轻松又方便人使用，因此这个软件本身是个独立运行的Server。

所以，最终取名为：IOT-Tree Server

3 这么些年的开发心路历程

3.1 树根部分开发（设备通信和驱动）

说实在，最初设计软件框架的时候，以为这就是软件的全部了。只需要统一设备接入之后的数据组织结构，剩下的就是不断添加各种设备驱动了。

我最先实现的设备驱动是Modbus RTU，因为之前做过，但放到这个产品级的开源软件中时，相对而言之前实现的设备对接程序通用性和完整性就太差了。这个协议看着简单，但要考虑更多的如下问题：要能够对接所有的Modbus设备，能够自动适应各种不同的数据点地址集合，要能够支持各种细致的访问控制。总之，万事开头难！

实际项目是我的一个重大推动力

Modbus RTU协议完成差不多之后，就碰到一个项目要对接西门子S7-200 PLC，并且把数据发送到用户的云端系统中。幸好之前了解过这个PLC的RS485口的PPI协议，感觉能搞定，就硬头皮直接答应用户要求。然后，赶快弄了个旧PLC开始没日没夜的西门子PPI驱动开发（驱动没出来，心里就没底，也就睡不着觉了啊），中间甚至简单学习了一下西门子PLC的编程。还好辛苦没白费，顺利完成了用户要求（并且程序运行一直很稳定）。

这个项目的成功，给了我很大的信心。同时也深刻理解，软件要成为好产品，用实际项目打磨是最好的选择。

3.2 交互界面的开发支持

在上面PPI协议完成并成功用到项目中之后，我心态有点膨胀了。在用户中控现场，看到工控机上的组态软件可以自由地制作现场监控画面，稍微研究学习了一下，反思自己之前h5 canvas开发经验，感觉我也可以搞定，顺便就决定在软件中优先加入hmi功能（纯web展示），并且要完全支持浏览器中在线编辑。

这是一个巨大的坑，因为监控画面由各种基础图元组成，我一开始使用js实现基础图元绘制，接下来就是各种问题各种烦躁。幸好幸好后来了解并学习TypeScript，并立刻以这个重新开始，这个改变使得前端绘图代码结构定义和严谨程度接近Java，可以充分发挥面向对象的优势，这才让整个开发过程顺利推进——大型前端代码工程强烈建议上TypeScript。

整个开发过程不用多说，基本也是没日没夜，特别是一开始，充满了激情和动力。基础功能完成之后，自己尝试制作了一个简单的demo，在这个demo实现过程中，本身也是对这段劳动成果的测试——总之就是感觉各种难用。

还是很幸运，又有一个自动化升级小项目：用户要求在厂区对远程的泵房进行自动调配，需要根据厂区运行工况，自动判断是否要启动远程的泵房。此项目我不仅加速实现了IOT-Tree基于JS脚本的定时任务（Task）功能，同时，使用我新做的交互界面功能，给用户画了一个简洁的总图（非大饼），没想到用户感兴趣也要了。于是，围绕这个项目，直接把我这些新做的功能全部锤炼了一遍。

项目实施过程本身也即是IOT-Tree软件各方面功能的实际演练。我只要发现哪个地方用的不爽，那就花大时间改进。其实整个项目1-2周就能够完成，但我前期就花费了2-3个月自我折磨的准备。

完成此项目，我才感觉IOT-Tree才勉强有点产品的样子了。

实际项目的监控画面

3.3 消息流的实现

随着驱动的增多，树根部分框架越来越稳固。我的主要精力慢慢往树上部分转移。但我也克制，不希望这部分内容变成各种纷繁复杂的业务需求，只希望能够提供顶层业务系统需要的支撑功能即可。

一开始专注于标签数据的事件（含报警）生成策略和后续处理(handler)，为此实现了一个可视化的简单框架（触发-处理框架）：事件触发节点+后续处理handler，并实现了一个直观的可视化展示。

其中，事件的触发可以支持规则、js脚本等内容；而Handler是个抽象，可以不断积累各种实现，如MQTT发送、写数据库等等。弄出这个框架主要目标是让软件使用者在后续数据基本处理上直接可视化配置即可——更复杂的就不管了。

触发-处理框架(已弃用)

但总感觉差点意思——还是有点弱了，唉!

直到一天我突然看到Node-RED这个IBM搞出的软件，一下子就被吸引了，原来差点意思就是和这个相比差了。这个流程图很简洁，但比我的“触发-处理”框架强大多了。并且我有着组态画面实现经验，感觉照着实现一个类似的很容易。

美工界面设计是我的极弱项，因此我就边学习Node-RED边抄作业（不知道是否丢人）。但从中我发现了Node-RED节点粒度太细——试图使用流程能够完全替代程序的开发，这和我的理念不同。既然用到了流程，那就不能使得使用过程比实际的JS脚本更复杂，我设计的消息流程节点，除了基础几个辅助节点之外，必须是中粒度复杂程度。使用过程要尽可能的使流程简单。

另外，我还改进引入模块节点概念，使得一些节点只能依附于模块节点。这样能够更好的表达功能集合和资源对象。如关系数据库模块节点，内部可以包含只对自己指向的数据库资源进行各种操作。

这是一个标签触发报警自动进行记录的流程

有了消息流，之前的定时任务、“触发-处理”框架就都被覆盖了。同时，从整体结构上也保证了IOT-Tree的两大概念，树根部分和树上部分。树上部分就是这个消息流。

3.4 ARM Linux设备中的移植

IOT-Tree Server整个软件核心都基于Java实现，如果没有充分利用这个跨平台特性，那实在可惜。因此，我整了几个嵌入式ARM Linux开发板和模块，内部资源足够运行Java虚拟机尝试移植。没想到出奇地顺利。并且经过长时间测试之后，很快就被用到了用户现场——直接使用以太网口对现场的PLC（RS485口已经被触摸屏占用）进行数据获取，然后转换成Modbus模拟设备，并通过设备自带的RS485口对接DTU接入云端。

有了这些小体积的设备支持，IOT-Tree Server的能力又被放大，可以直接把ARM Linux设备变成强大的物联网边缘设备或协议转换网关。