docker版jxTMS使用指南：使用jxTMS采集数据之三
本文是如何用jxTMS进行数据采集的第三部分，整个系列的文章请查看：docker版jxTMS使用指南：4.4版升级内容
docker版本的使用，请查看：docker版jxTMS使用指南
4.0版jxTMS的说明，请查看：4.0版升级内容
4.2版jxTMS的说明，请查看：4.2版升级内容
新增一个站点要做的工作
1、确定现场的数据采集方案以及如何传递回后端的jxTMS
笔者在这些文章中罗列了很多，但依然只会是很少很少的一部分，所以这一部分工作内容，docker版jxTMS大部分情况下是无法覆盖到的，需要由开发者自行完成。
目前，docker版jxTMS主要以MQTT进行现场与后端的数据传输，其优势包括：
-
很多DTU现在都支持MQTT
-
MQTT还具有一定的QoS能力
-
在不影响生产的情况下，通过再分出一路数据，就可执行故障排查、测试、调试等工作
-
相比DTU普遍拥有的TCP/UDP等直接的数据传输模式，MQTT将现场与后端进行了解耦合，大大提高了系统的弹性、伸缩性和灵活性，也方便了双方的调试工作
DTU的MQTT使用方式大多采取串口透传模式，可以直接将RS232或RS485接口收到的数据以固定的主题【jxTMS默认为站点名】直接发送到MQTT服务端。
docker版jxTMS演示了三种现场采集+MQTT传输，如果大家的现场环境类似，可直接采用：
-
单设备通过串口主动发送，则通过DTU连接后直接推送到MQTT，可参考【app/vrs20】目录，其实就是啥都不需要做，只要配置站点时指定相应的设备类型就可以了
-
现场modbus采集然后通过本地网络推送到MQTT，可参考【app/sinosoarSP30H】目录下的sp30h_slave.py，其通过datasource来采集现场的modbus设备的数据，然后创建一个jx.mqtt.mqttClient，并通过该mqttClient来发布数据
-
多设备通过MQTT采集，可参考【app/sinosoarSP30H】目录下的sp30h_master.py，其就是采集现场的sp30h_slave.py发布的json型数据
2、设备解码与数据处理
参考【app/vrs20】目录下的policy.py，如果前端采集到的数据有其特殊格式，则需定义一个数据解析策略，然后注册到jxTMS中。
在注册时，如果明确知道本策略就是专用给某型设备的，可以直接用该设备的类型进行注册，如【app/vrs20】目录下的policy.py中所演示的。
如果本策略可能会用于一系列各型设备，如ais设备的解码，就是通用于所有ais设备的。那就需要给本策略起一个专用名，然后以此专用名进行注册，然后在设备初始化时在配置参数时以该策略名设置policyType参数即可。
如果需要对解析后的数据进行处理，则如【app/vrs20】目录下的device.py中所演示的，重载onReceive函数并完成相应的数据处理。
3、保存设备数据
参考【app/data】目录下的vrs20.py，按java侧的data文件中相应的数据类，来定义python中对应的数据类。然后进行注册：
-
ORM.register，将相应的数据类注册到jxTMS中。如果不使用python侧的任何查询能力，可以不注册，但为了万一需要日后的能力升级时不出问题，建议注册
-
Device.register，将创建数据对象的函数注册到Device数据类中，以在需要时创建设备数据对象
和数据解析策略一样，如果该数据类专用于某型设备，则可直接用该设备类型进行Device.register注册，否则就以本数据类对应的数据表名进行Device.register注册，然后在设备初始化时在配置参数时以该策略名设置dataType参数即可。
如果设备数据需要实时保存，则在设备配置参数中将saveDataInterval设为0，此时只要收到新数据【解析正确】，就会立刻将其保存到数据库中。如果saveDataInterval大于0，则jxTMS会每隔saveDataInterval分钟保存一次新收到的实时数据。
注：saveDataInterval默认是15分钟
jxTMS的device基类还自带超时检测能力：如果timeOut秒未收到新数据，则认为该设备失联；同时如果timeOutCheckInterval参数大于0，则每timeOutCheckInterval分钟就会执行一次超时检测。
所以，如果需要执行超时检测，则应设置timeOutCheckInterval与timeOut两参数，由于只要检测到超过timeOut秒尚未收到新数据就会报超时失联，所以timeOut应设为数据发送间隔的3倍左右，而timeOutCheckInterval一般则可以比数据发送间隔稍大一点，因为短了没必要，太长又会影响对超时失联的反应灵敏性。
注：timeOutCheckInterval默认是3分钟，timeOut默认是600秒
如果设备数据所保存到的数据表需要分表，主站最好是在java侧的data文件中定义java中的数据类时指定rename属性，从站则可如【app/data】目录下的DieselGenerator.py所演示的，定义建表语句，并在注册时指定renameType：
ORM.registerSQL_createTable('DieselGenerator',_sql_createTable,renameType='day')
但jxTMS默认是不执行分表操作的，所以还需要在main.py文件中手动启动分表的调度器：
from jx.jxMysql import ORM
ORM.startRenameTableScheduler()
4、告警处理
jxTMS内部的默认告警策略是通过钉钉发送告警信息，参考【module/warnPolicy_dingding.py】文件。
目前jxTMS的告警在新版本中已经调整到站点进行，在站点初始化时，自动创建一个全局的默认告警策略，就是【module/warnPolicy_dingding.py】中注册的default策略。
而使用钉钉告警，需要【在新版本中，嗯，当前版本忘了:(】执行：
-
先创建一个钉钉群，如：故障告警
-
然后在钉钉后台为申请该群webhook的token和secret
-
并在jxTMS中设置token和secret，快捷栏【安全管理->增加钉钉群组】
如果需要其它告警策略，则先要按【module/warnPolicy_dingding.py】中写自己的告警策略，然后注册为default，最后将自己的告警策略代码模块，copy到module目录下，并在【module/__init__.py】中引用自己的代码文件。
注：为确保自己的告警策略能覆盖掉warnPolicy_dingding模块中的告警策略，则应在【module/__init__.py】中注释掉warnPolicy_dingding的引用，或将自己的代码文件的引用放到warnPolicy_dingding之后
5、业务联动
参考上篇文章中的数据联动章节，以及【本地数据总线】一文，通过jxLocalDataBus.registerTarget注册感兴趣的设备的数据，则可实现当该设备接收并处理保存完毕新数据后，抄收处理后的实时数据来实现需要的业务功能。
参考资料：
jxTMS设计思想
jxTMS编程手册
下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能：
如何用jxTMS开发一个功能
下面的系列文章讲述了jxTMS的一些基本开发能力：
jxTMS的HelloWorld