1 总体说明
1.1 产品概述
1.1.1 Thingsboard作用
1.置备并控制设备。
2.采集设备数据并进行数据可视化。
3.分析设备数据,触发告警。
4.将数据传输到另一个系统。
5.允许根据用例的具体需求自定义规则并使用插件。
6.是为物联网应用提供开箱即用的物联网云服务器端基础设施。
7.是一个开源IoT平台,用来快速开发、管理、扩展的物联网项目
1.1.2 Thingsboard特点
1.可扩展: 使用领先开源技术构建的可水平扩展平台。
2.容错: 无单点故障,集群中的每个节点都是相同的。强大、
3.高效: 单个服务器节点可以根据用例处理几十甚至数十万个设备。
thingsBoard集群可以处理数百万台设备。
4.可定制: 可轻松使用可自定义的可视化小部件、规则引擎和插件系统添加新功能。
5.持久保存:永远不会出现数据丢失现象。
6.开源: 100%开源
1.1.3 产品架构
Thingsboard性能利用三个主要项目:
Netty用于 IoT 设备的高性能MQTT服务器/代理。
Akka为高性能actor系统协调数百万设备之间的消息。
Cassandra用于可扩展的高性能NoSQL DB,用于存储来自设备的时间序列数据。
使用Zookeeper进行协调和以集群模式使用gRPC。
规则引擎:动态配置设备消息的处理流程
核心服务:租户和客户、设备认证、规则和插件、小组件和仪表盘、告警和事件
安全:SSL用于HTTP和MQTT
设备安全认证:Token和X.509
1.1.3 前后端分离之前端
1.前端知识准备:Nodejs, Angularjs,ES6,Reactjs,webpack。
2.了解thingsboard项目:
3.前端MVC、MVVM框架
4.前端打包方案
5.主要开发可视化小部件,后台管理平台数据ui展示
1.1.4 前后端分离之后端
1.熟悉工业标准IOT通信协议:
- MQTT:发布订阅模式
- COAP:请求响应模式
- HTTP :请求响应模式
2.熟悉postages和cassandra数据库结构
3.规则链的使用
4.其它系统与TB的对接
5.物联网网关:物联网网关主要的三个功能
1、协议转换能力
2、可管理能力
3、广泛的接入能力
物联网网关的两个因素
1、数据安全
2、可维护
对平台来说物联网网关也只是一个设备:只不过网关的消息体和其他设备不一样,网关监听的是消息代理发送的消息,针对MQTT来说,网关只不过选择性监听了topic,构建了一个映射“map”关系。
1.2 ThingsBoard实际接入项目
1.2.1 目前协议支持
1.目前支持HTTP,MQTT, COAP
2.官网原文:
Extend default platform functionality using customizable rules, plugins, widgets and transport implementations. In addition to MQTT, CoAP and HTTP support, ThingsBoard users can use their own transport implementations or customize behaviour of existing protocols.
使用可定制规则、插件、小部件以及传输协议扩展平台默认功能。支持MQTT, CoAP and HTTP 协议,此外,用户可定制MQTT, CoAP and HTTP 协议或使用自己的协议。
3.添加第三方协议,需要二开,项目包名:Transport 代码改动量较大,建议将Thingsboard不支持的协议中间转换为Thingsboard支持协议,再推送到Thingsboard。
4.相似产品及公司协议支持对比
1.2.2 项目接入
- 内网部署设备:
通过MQTT协议对于Thingsboard也是网关的概念去接入
- 通外网设备:
外网设备,对于MQ,WebsSocket WebService等协议可以二开接入ThingsBoard或者统一转换为HTTP协议,建议十分不常见的其他协议不用考虑二次开发Thingsboard接入,对于ThingsBoard平台不支持的常见协议可以开发去接入,一次开发后通用。
- 数据可视化:
- 设备数据可视化对于力石可以起到辅助作用用于实时展示接入数据的变化,可以及时排查第三方接入故障。
- 设备数据接入Thingsboard平台后可以有多种可视化展示方式,echarts图标 数据走势图等,而且可以自己开发组件去展示数据。
- 数据使用:
我司看重的最重要的对于ThingsBoard作用就是对外第三方接入,对于公司需要调用第三方的需求的部分,可以统一接入ThingsBoard平台
1.3 ThingsBoard解决痛点
1.痛点描述:对于公司业务来说项目中大量使用第三方的接口,以及各种协议,没有统一去处理这些第三方的业务,每个新的协议过来,研发去研究接入。
当第三方的调用较少时,或者项目少的时候,痛点还不突出,当业务量越来越大,调用越来越多,项目越来越多的时候,随着项目的时间越来越远,维护起来会变的很痛苦,老旧项目第三方的代码的调用逻辑和管理就会变得很混乱。
2.接入ThingsBoard后 公司对接所需数据是对接中间介质ThingsBoard能解决的问题:
(1)统一了对外调用 我司设备对接完ThingsBoard后,不用再去考虑设备对接问题。
(2)Thingsboard对外提供的对接方式可以统一转换为主流的HTTP接口形式
(3)可扩展性也强大 特殊情况下,不需要HTTP形式的数据,Thingsboard通过规则链也可以对接到管道,例如:Kafka
(4)对于每个厂商可以通过租户(Thingsboard)的概念去区分管理,十分清晰。
(5)协议接入越多,平台功能越强大,类型滚雪球,后期会变得更轻松。
1.4 ThingsBoard难点
- 对于不支持的协议前期接入,当选用在ThingsBoad源码上二次开发,需要研发熟悉Thingsboard 协议接入模块的代码
- 对于不支持的协议接入,如果考虑统一中间转换一下协议再接入ThingsBoard,前期工作量较大,但是该转换协议的项目设计合理的前提下功能强大起来,后期接入其他相同协议的设备会十分省时。
- ThingsBoard部署问题,关键数据库postages和cassandra服务器大小的预估。
- 当内网设备接入时,虽说可以通过网关接入,例如使用MQTT接入需要说服设备厂商本地安装客户应用服务器,MQTT客户端。
1.5 相关资料
1.https://blog.csdn.net/github_35631540/category_10844433.html
2.https://fizzz.blog.csdn.net/article/details/114286380
3.https://thingsboard.io/