谈谈thingsboard中设备相关的
大家都知道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中也是非常重要的。相对设备来说就是可以想象是个产品。里面包含这个设备消息处理的规则链，报警配置，等相当多的内容，下一篇我我们详细分析。