当前位置: 首页 > 工具软件 > ThingsBoard > 使用案例 >

谈谈thingsboard中设备相关的

马奇略
2023-12-01

大家都知道thingsboard是物联网平台,其中最核心的实体就是设备,也就是device。thingsboard中实体关系比较复杂,基本上是不同的用处,都建立了相应的类来支持,具体的好处,我暂时还领悟不到,为了方便移植,基本上舍弃了这种方式,也就是整个系统涉及到设备的地方,我都会用一个实体类来实现完成。

另外说明一点的就是,估计为了灵活性,thingsboard中实体的的属性,大量的使用了json字段,尤其是在在持久化层。

我们就具体分析一下设备相关对象,记录移植原则和过程,我们就从源头开始,设备直接的持久化对象在thingsboard中叫做DeviceEntity

public final class DeviceEntity extends AbstractDeviceEntity<Device> {

    public DeviceEntity() {
        super();
    }

    public DeviceEntity(Device device) {
        super(device);
    }

    @Override
    public Device toData() {
        return super.toDevice();
    }
}

这个类其实没什么,主要的功能就是转换Device类。所涉及的字段都在他的父类AbstractDeviceEntity中

@Column(name = ModelConstants.DEVICE_TENANT_ID_PROPERTY, columnDefinition = "uuid")
private UUID tenantId;

@Column(name = ModelConstants.DEVICE_CUSTOMER_ID_PROPERTY, columnDefinition = "uuid")
private UUID customerId;

@Column(name = ModelConstants.DEVICE_TYPE_PROPERTY)
private String type;

@Column(name = ModelConstants.DEVICE_NAME_PROPERTY)
private String name;

@Column(name = ModelConstants.DEVICE_LABEL_PROPERTY)
private String label;

@Column(name = ModelConstants.SEARCH_TEXT_PROPERTY)
private String searchText;

@Type(type = "json")
@Column(name = ModelConstants.DEVICE_ADDITIONAL_INFO_PROPERTY)
private JsonNode additionalInfo;

@Column(name = ModelConstants.DEVICE_DEVICE_PROFILE_ID_PROPERTY, columnDefinition = "uuid")
private UUID deviceProfileId;

@Column(name = ModelConstants.DEVICE_FIRMWARE_ID_PROPERTY, columnDefinition = "uuid")
private UUID firmwareId;

@Column(name = ModelConstants.DEVICE_SOFTWARE_ID_PROPERTY, columnDefinition = "uuid")
private UUID softwareId;

@Type(type = "jsonb")
@Column(name = ModelConstants.DEVICE_DEVICE_DATA_PROPERTY, columnDefinition = "jsonb")
private JsonNode deviceData;

上面就是真实的DecviceEntity中的属性,对应数据表中的字段,我项目直接建立对象Device。移除继承关系,目前没有想到这些继承关系的实际用处,这样移植也是为了以后重构的便利性,个人愚见各个层中业务对象保持一致,除了必要。不当之处大神指教。

为了后续的一些逻辑处理,我直接保留了全部的属性信息,唯一的一个不同点就是把uuid直接换成String,目前主要是为了方便,和不希望和uuid绑定太死。还有写效率方面的考虑,目前还没想清楚,以后在说。

大家可以看出来除了,租户,客户,名称、以及设备配置的id,还有他的固件ID和软件版本ID。这些固定参数,其他都是保存是json字段,这些字段是代码中直接构建对象,这种方式可以带来灵活性,但是也带来前端开发的复杂性和代码的易读性方面的困扰,我们以后再说。

这些其实都是设备一些基本属性,为了更灵活的描述,千差万别的设备,thingboard对设备对应的其他信息,分为两种对象来保存,也就是大家熟悉的属性和遥测数据。来和设备进行关联,灵活的描述各种设备信息。

这两种信息结构,在我看来其实是一样,就是键值对。根据类型的不同,进行一些封装 ,不同之处也就是应用层面。

属性信息AttributeKvEntity,主要描述设备一些固有信息,如软件版本,颜色,尺寸大小等,这些信息又分为三类,服务端属性,客户端属性和共享属性。主要是区别这些信息由谁来维护的问题。

遥测信息TsKvEntity 这个主要设备一些动态新题,如开关状态,位置信息,温度,湿度这样的信息,和属性信息最大的区别就是这些信息带有时序信息,可以记录历史装填,对应的为了能快速高效的展示设备状态,有个TsKvLatestEntity用户保存这些遥测信息的最后状态。

因为TsKvEntity是典型的时序数据,就会有海量的数据进行存储,和大量的查询分析,说thingsboard支持时序数据库来保存这些数据,这也是物联网系统中一个非常重要的特点,后面还会做详细的讨论。

个人认为,thingsboard中这样的处理设备,也是大多数物联网系统通用模式,基本上可以应对物联网系统中对设备的信息处理的要求。

上面提到设备中有个设备配置ID,这个在thingsboard中也是非常重要的。相对设备来说就是可以想象是个产品。里面包含这个设备消息处理的规则链,报警配置,等相当多的内容,下一篇我我们详细分析。

 类似资料: