An open-source IoT platform that enables rapid development, management and scaling of IoT projects. With this IoT platform, you are able to:
-
- Provision and control devices,
-
- Collect and visualize data from devices,
-
- Analyze device data and trigger alarms,
-
- Deliver device data to other systems,
-
- Enable use-case specific features using customizable rules and plugins.
This IoT Platform provides an SDK to help you easily and quickly connect your hardware device or your mobile application. This IoT Device SDK enables your devices to connect, authenticate, and exchange messages with this IoT Platform using the MQTT, HTTP, or WebSockets protocols. The Device SDK supports Java/JavaScript, and includes the client libraries, the developer guide, and the porting guide for manufacturers. You can also use an open source alternative or write your own SDK.
IoT Device Gateway enables devices to securely and efficiently communicate with this IoT Platofrm. The Device Gateway can exchange messages using a publication/subscription model, which enables one-to-one and one-to-many communications. With this one-to-many communication pattern, IoT Platform makes it possible for a connected device to broadcast data to multiple subscribers for a given topic. The Device Gateway supports MQTT, WebSockets, and HTTP 1.1 protocols. The Device Gateway scales automatically to support over a billion devices without provisioning infrastructure.
This provides mutual authentication and encryption at all points of connection, so that data is never exchanged between devices and IoT Platform without proven identity. X.509 certificate based authentication is supported.
The Device Registry establishes an identity for devices and tracks metadata such as the devices’ attributes and capabilities. The Registry assigns a unique identity to each device that is consistently formatted regardless of the type of device or how it connects. It also supports metadata that describes the capabilities of a device, for example whether a sensor reports temperature, and if the data are Fahrenheit or Celsius.
Through this Device Shadow, you can create a persistent, virtual version, or “shadow,” of each device that includes the device’s latest state so that applications or other devices can read messages and interact with the device. The Device Shadows persist the last reported state and desired future state of each device even when the device is offline. You can retrieve the last reported state of a device or set a desired future state through the API or using the rules engine.
Device Shadows make it easier to build applications that interact with your devices by providing always available REST APIs. In addition, applications can set the desired future state of a device without accounting for the devices current state. Then it will compare the difference between the desired and last reported state, and command the device to make up the difference.
The IoT Device SDK makes it easy for your device to synchronize its state with its shadow, and to respond to desired future states set via the shadow.
The Rules Engine makes it possible to build IoT applications that gather, process, analyze and act on data generated by connected devices at global scale without having to manage any infrastructure. The Rules Engine evaluates inbound messages published into IoT Platform and transforms and delivers them to another device or a cloud service, based on business rules you define. A rule can apply to data from one or many devices, and it can take one or many actions in parallel.
The Rules Engine can also route messages to external 3rd party cloud services, such as Amazon AWS cloud services, IBM or Azure cloud services, Aliyun cloud services,etc.
Besides these rule based analytics, this IoT Platform also provides the Advanced Analytics including complex and compound computation, Spark streaming based timewindow rules, Spark Machine Learning enabled analytics, etc.
- Frequency Oftentimes, an application wants to control the frequency that continuously generated analytic results are made available to other parts of the application or published to other applications or an event hub.
Actor model enables high performant concurrent processing of messages from devices as long as server-side API calls. Akka is used as an actor system implementation with following actor hierarchies.
Brief description of each actors functionality is listed below:
- App Actor - responsible for management of tenant, system rules & plugins actors. Instance of this actor is always present in memory.
- Tenant Actor - responsible for management of tenant device, rules & plugins actors. Instance of this actor is always present in memory.
- Device Actor - maintain state of the device: active sessions, subscriptions, pending RPC commands, etc. Caches current device attributes in memory for performance reasons. Actor is created when first message from device is processed. Actor is stopped when there is no messages from devices for a certain time.
- Rule Actor - filter and process incoming messages, converts them to actions and forward this actions to plugin actors. Instance of this actor is always present in memory.
- Plugin Actor - process incoming messages, and report results back to rule actor. Also handles server side requests. Instance of this actor is always present in memory.
- Device Session Manager Actor - responsible for management of device session actors. Creates session actors on first message with corresponding session id. Closes session actors when corresponding session is closed.
- Session Actor - represents communication session between device and Thingsboard server. Session may be synchronous (HTTP, CoAP) and asynchronous (MQTT, CoAP with Observe option).
- RPC Session Manager Actor - responsible for management of cluster RPC session actors. Creates session actor when new server is up. Closes session actor when server is down.
- RPC Session Actor - represents communication session between two Thingsboard servers in the cluster mode. Communication is done using HTTP/2 based on gRPC.
This IoT Platform uses Zookeeper for service discovery, where all the nodes are identical and registered as ephemeral in Zookeeper. Apache Curator path cache receipt is used to keep track of all available sibling nodes.
This IoT Platform adopts consistent hashing to ensure scalability and availability. Message from Device A that is received on particular node may be forwarded to the other node based on the hash of the device ID. Although this introduce certain networking overhead, it allows to process all messages from particular device using corresponding device actor on a determined server, which introduce following advantages:
- improve cache hit rate. Device attributes and other device related data are fetched by device actor on a specific server.
- avoid race conditions. All messages for particular device are processed on a determined server.
- allows to target server-side api calls based on device id.
INFO] Reactor Summary:
[INFO]
[INFO] Whole IoT Platform ................................. SUCCESS [ 0.650 s]
[INFO] IoT Information Management ......................... SUCCESS [ 0.203 s]
[INFO] IoT Information Management - Data .................. SUCCESS [ 0.730 s]
[INFO] IoT Information Management - DAO ................... SUCCESS [ 0.734 s]
[INFO] Rule based IoT Analytics ........................... SUCCESS [ 0.006 s]
[INFO] Rule Engine Common Messages ........................ SUCCESS [ 0.125 s]
[INFO] Rule Engine API .................................... SUCCESS [ 0.272 s]
[INFO] Rule Engine Core Extensions ........................ SUCCESS [ 0.342 s]
[INFO] Action Plugins ..................................... SUCCESS [ 0.006 s]
[INFO] Kafka Plugin ....................................... SUCCESS [ 2.126 s]
[INFO] MQTT Plugin ........................................ SUCCESS [ 0.132 s]
[INFO] Webhook Plugin ..................................... SUCCESS [ 0.476 s]
[INFO] IoT Hub ............................................ SUCCESS [ 0.553 s]
[INFO] IoT Platform UI .................................... SUCCESS [02:14 min]
[INFO] IoT Platform Server ................................ SUCCESS [ 0.730 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 02:22 min
[INFO] Finished at: 2017-10-22T21:16:41+08:00
[INFO] Final Memory: 42M/625M
[INFO] -----------------------------------------------------------
xis-macbook-pro:~ xiningwang$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8b0def0e1594 cassandra "/docker-entrypoin..." 3 months ago Up 7 seconds 0.0.0.0:7000-7001->7000-7001/tcp, 0.0.0.0:7199->7199/tcp, 0.0.0.0:9042->9042/tcp, 0.0.0.0:9160->9160/tcp mycassandra
a6975c6bf0c2 spotify/kafka "supervisord -n" 3 months ago Up 14 seconds 0.0.0.0:2181->2181/tcp, 0.0.0.0:9092->9092/tcp
This project is released under Apache 2.0 License. This open source project is based on several other open source projects or libraries, and free for experiments (no any commercial support) with Apache License, Version 2.0. Notice: ThingsBoard project (https://github.com/thingsboard/thingsboard) is the original idea for this project.