本文讲解4.4版jxTMS中的站点的调整,整个系列的文章请查看:[docker版jxTMS使用指南:docker版jxTMS使用指南:4.4版升级内容
docker版本的使用,请查看:docker版jxTMS使用指南
4.0版jxTMS的说明,请查看:4.0版升级内容
4.2版jxTMS的说明,请查看:4.2版升级内容
在4.0版中,设备device类是非常核心的模块,其主要负责:
根据数据收发的情况来跟踪设备状态
确定本设备接收到的数据该如何解析
根据业务需要对接收到的数据进行处理
确定本设备接收、处理后的数据该保存到哪张数据表中
确定设备数据的保存策略【实时保存还是周期性保存,以及保存的周期】
确定告警策略以在设备出现问题时发出告警
而站点site则只是一个逻辑上收容设备的存在,只是因为从业务逻辑上来说设备都是通过站点统一管理、集中配置、统一接收前端数据的,所以site类主要是以类函数来进行启动、配置等管理动作,业务方面只有一个最基本的数据接收函数:receive。
但随着更多类型的设备、各种接入方式的增多,站点的重要性就在三个方面凸显出来了:
1、如何与数据点打交道
目前已经有三种方式:
通过MQTT推送原始数据
类似modbus型设备的主动拉取
通过MQTT推送自定义协议包
2、如何分发数据
笔者很想和数据源一样,内置一个自动分发数据的机制,但仔细研究过上述的数据采集方式后,由于推送模式和拉取模式的巨大差异,如果想强行统一,那干嘛不在数据源中就完成呢?!
当时既不考虑通过数据源来统一数据接收,自然就是因为接收数据的方式方法难以统一。
所以思考再三,最终还是根据站点类型分别实现各自的接收数据方法,而且具体的站点还可进一步的细化自己的数据接收。
3、如何根据业务需要来综合数据
前面在数据源时讨论这个问题。结合数据源时的讨论和上面site分类的考虑,在site中增加了数据处理接口:
def onReceive(self, type, data):
#各站点自己的数据处理事件,默认不做任何额外的处理,相当于只转发
#返回True代表接收并处理后的是需保存到数据库中的数据
#返回False代表不要保存
return data,True
def recevieData(self, type, data):
#具体site的数据处理函数,是site的数据处理流的入口,不应重载
#和receive的区别在于,recevieData是站点自身处理数据工作流的入口
#receive是推送模式下收并分发数据
供各种类型的站点在数据处理完毕后显式或隐式将数据回送给站点进行综合处理。
考虑到上述问题,4.4版jxTMS将站点划分为如下的四种基础的站点类:
单设备直接推送型,就是最基础的site类
多设备推送型,site_multiDev_push类
多设备自定义协议包推送型,site_packet类
多设备拉取型,site_multiDev_poll类
后三者都直接或间接继承自site类,所以整体的设备管理、控制、配置和数据处理流都是一致的,区别只在于数据接收、分发、综合这三者的区别。
site完成设备管理、配置、数据保存【如果有的话】等最基础的管理和业务工作,之前已经讲述过,不复赘述。数据方面:
1、接收
以自己的站点名订阅MQTT主题,然后等待现场设备通过MQTT推送给自己,数据是设备直接发送的原始字节串,以utf8编码转为字符串。
2、分发
将转换好的字符串直接递交给自己的设备【就一台】。
3、综合
receive函数中已经隐式调用了recevieData函数进行了数据回送。
site类调整或增加的对象函数:
init(self, type, name, saveDataInterval=15)
站点的构造函数
参数:
type:站点类型
name:站点名
saveDataInterval:默认的站点数据保存间隔,0则直接保存实时数据
receiveData(self, dn, data)
本站点接收数据的入口
参数:
dn:设备名或自己约定的事件、命令等
data:对应的数据或参数
返回值:
无
说明:
receiveData主要完成调用站点数据处理函数来处理数据,然后保存数据
onReceive(self, dn, data)
数据处理
参数:
dn:设备名或自己约定的事件、命令等
data:对应的数据或参数
返回值:
rd:处理后的数据
newData:接收到的是需要保存的数据,还是予以忽略的其它消息
说明:
如果newData为True则保存rd【注意,不是原始的data,而是处理后的rd】
默认的onReceive函数是:
def onReceive(self, dn, data):
return data,True
newOrmData(self)
获取一个新的站点数据对象
参数:
无
返回值:
ormSiteData:保存本类型site的数据对象,jxTMS会从回送的数据中根据本类的属性为其准备数据
说明:
本函数默认返回None,即不保存任何站点数据
构造函数同site,重写receive函数。
1、接收
以自己的站点名订阅MQTT主题,然后等待现场的数据采集器通过MQTT推送给自己。默认一次接收到的就是一个设备的一条消息【未必就一定会是数据,可以是一条数据中的一部分,也可以是命令、事件等】,数据为json格式,本站将其解析为dict。
2、分发
数据打包为json格式,本站将其解析为dict,其中的dn指示设备名,然后根据此设备名将数据直接转交给相应的设备。
3、综合
receive函数中已经隐式调用了recevieData函数进行了数据回送。
构造函数同site,重写receive函数、addDevice。
1、接收
以自己的站点名订阅MQTT主题,然后等待现场的数据采集卡通过MQTT推送给自己。默认一次接收到的就是一个设备的一条消息【未必就一定会是数据,可以是一条数据中的一部分,也可以是命令、事件等】,数据格式为自定义协议包,本站将其解析为dict。
2、分发
自定义协议包的包名,指示系统状态报告、事件等,其它则视为设备名或类型【改写addDevice就是用类型取代设备名来添加设备,参考之前的4.2版数据源部分】,然后据此将数据转交给相应的设备。
3、综合
receive函数中已经隐式调用了recevieData函数进行了数据回送。
之前的数据源相关文章中已经介绍过了,拉取模式下数据源已经接管了整个数据流的处理包括回送机制,所以site_multiDev_poll的主要工作就是定义并为下属设备使用好数据源提供接口,然后重写receive函数以旁路推送模式下的数据送达。
构造函数:
**init(self, type, name, dataSourceType=‘modbus’, saveDataInterval=15,
Test=False, Debug=False)
参数:
type:站点类型
name:站点名
saveDataInterval:默认的站点数据保存间隔,0则直接保存实时数据
dataSourceType:数据源的类型,默认是modbus
Test:数据源工作于测试模式,即数据不来自实际的拉取,而是由数据产生式模拟
Debug:数据源工作于调试模式,对每一步都进行报告
dataSourceParams(self)
获取数据源配置参数
参数:
无
返回值:
指定数据源格式的数据源所需要的dict格式的配置参数
示例:
#app/sinosoarSP30H/site_slave.py中给出的modbus数据源的配置参数是:
def dataSourceParams(self):
return {
'afterPullDual':self._afterPull,
'ip':'xx.xx.xx.xx',
'port':ppp,
'taskInterval_milliseconds':500,
'interval_seconds':300
}
addWantReceiveOver(self, dn, receiveFunc)
为下属设备提供数据源添加某设备数据拉取结束的接口
参数:
dn:设备名
receiveFunc:其接收函数
返回值:
无
示例:
#app/sinosoarSP30H/device_pcs_slave.py中:
self._informMain = mySite.addWantReceiveOver(name,self.receive)
addWantReceive(self, t, productStatement, compareStatement)
为下属设备提供数据源添加拉取数据点参数的接口
参数:
t:约定的数据点拉取参数元组,具体参考前述数据源相关文章以及数据源的定义
productStatement:数据产生式
compareStatement:数据校验式
返回值:
无
示例:
#app/sinosoarSP30H/device_pcs_slave.py中:
self.site().addWantReceive(t,productStatement,compareStatement)
最后,旁路receive函数:
#拉取模式不用
def receive(self, msg):
pass
参考资料:
jxTMS设计思想
jxTMS编程手册
下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能:
如何用jxTMS开发一个功能
下面的系列文章讲述了jxTMS的一些基本开发能力:
jxTMS的HelloWorld