|
| 1 | +<!-- |
| 2 | +
|
| 3 | + Licensed to the Apache Software Foundation (ASF) under one |
| 4 | + or more contributor license agreements. See the NOTICE file |
| 5 | + distributed with this work for additional information |
| 6 | + regarding copyright ownership. The ASF licenses this file |
| 7 | + to you under the Apache License, Version 2.0 (the |
| 8 | + "License"); you may not use this file except in compliance |
| 9 | + with the License. You may obtain a copy of the License at |
| 10 | + |
| 11 | + http://www.apache.org/licenses/LICENSE-2.0 |
| 12 | + |
| 13 | + Unless required by applicable law or agreed to in writing, |
| 14 | + software distributed under the License is distributed on an |
| 15 | + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| 16 | + KIND, either express or implied. See the License for the |
| 17 | + specific language governing permissions and limitations |
| 18 | + under the License. |
| 19 | +
|
| 20 | +--> |
| 21 | + |
| 22 | +# ThingsBoard |
| 23 | + |
| 24 | +## 1. Overview |
| 25 | + |
| 26 | +ThingsBoard is an open-source IoT platform for device management, data collection |
| 27 | +and visualisation. It stores device telemetry, latest-value telemetry and entity |
| 28 | +attributes through three storage SPIs, which allows the storage layer to be |
| 29 | +replaced without changing the platform itself. |
| 30 | + |
| 31 | +`iotdb-thingsboard-table` implements those three SPIs on top of the IoTDB Table |
| 32 | +Model, so a ThingsBoard deployment can keep its telemetry in IoTDB instead of |
| 33 | +Cassandra or a relational database: |
| 34 | + |
| 35 | +| ThingsBoard SPI | Implementation | Purpose | |
| 36 | +| --- | --- | --- | |
| 37 | +| `TimeseriesDao` | `IoTDBTableTimeseriesDao` | Historical telemetry: batched writes, raw and time-bucketed aggregation reads, deletes | |
| 38 | +| `TimeseriesLatestDao` | `IoTDBTableLatestDao` | Latest value per telemetry key | |
| 39 | +| `AttributesDao` | `IoTDBTableAttributesDao` | Entity attributes, scoped by `SERVER_SCOPE` / `SHARED_SCOPE` / `CLIENT_SCOPE` | |
| 40 | + |
| 41 | +This page covers the **Table Model** integration, which runs against a stock |
| 42 | +ThingsBoard release and is enabled by adding a jar and setting a few properties. |
| 43 | +There is a separate, earlier integration for the **Tree Model**, described in |
| 44 | +[ThingsBoard (Tree Model)](../../latest/Ecosystem-Integration/Thingsboard.md); |
| 45 | +that one stores data under `root.thingsboard` and requires an IoTDB-adapted |
| 46 | +ThingsBoard build rather than a stock one. The two are independent — pick the one |
| 47 | +that matches the data model you are using. |
| 48 | + |
| 49 | +Writes are batched through a bounded asynchronous queue into IoTDB tablets. |
| 50 | +Reads cover both the raw path and the aggregation path: fixed-width millisecond |
| 51 | +buckets use IoTDB's native `date_bin`, while calendar buckets |
| 52 | +(`WEEK` / `WEEK_ISO` / `MONTH` / `QUARTER`) are walked per bucket so that |
| 53 | +boundaries match ThingsBoard's own semantics in the timezone carried by each |
| 54 | +query. |
| 55 | + |
| 56 | +## 2. Usage Steps |
| 57 | + |
| 58 | +### 2.1 Version Requirements |
| 59 | + |
| 60 | +* `IoTDB: 2.0.8` (Table Model) — the version the integration tests are executed |
| 61 | + against (`apache/iotdb:2.0.8-standalone`). Other 2.x releases are untested. |
| 62 | +* `ThingsBoard: 4.3.1.2` |
| 63 | +* `JDK: >= 17` |
| 64 | + |
| 65 | +The module is compiled against the ThingsBoard 4.3.1.2 SPI surface. Because |
| 66 | +ThingsBoard's `common/data` and `dao` artifacts are not published to Maven |
| 67 | +Central, the module builds against a compile-only surface of the types it uses; |
| 68 | +those classes are excluded from the packaged jar, so at runtime the real |
| 69 | +ThingsBoard classes are used. |
| 70 | + |
| 71 | +### 2.2 Obtain the jar |
| 72 | + |
| 73 | +Build it from the `iotdb-extras` repository. The module sits behind an explicit |
| 74 | +opt-in profile, so a plain reactor build does not include it: |
| 75 | + |
| 76 | +```bash |
| 77 | +# from the apache/iotdb-extras repository root, with JDK 17+ |
| 78 | +# https://github.com/apache/iotdb-extras |
| 79 | +mvn -pl iotdb-thingsboard-table -am -P with-thingsboard clean package |
| 80 | +``` |
| 81 | + |
| 82 | +The jar is produced under `iotdb-thingsboard-table/target/`. |
| 83 | + |
| 84 | +### 2.3 Deploy into ThingsBoard |
| 85 | + |
| 86 | +1. Install and start IoTDB, see [IoTDB QuickStart](../QuickStart/QuickStart.md). |
| 87 | +2. Add the module jar to ThingsBoard's classpath. ThingsBoard runs as a Spring |
| 88 | + Boot application, and exactly how the classpath is extended depends on how it |
| 89 | + was installed: the Docker images launch through Spring Boot's |
| 90 | + `PropertiesLauncher` and already honour a `LOADER_PATH` entry, while the |
| 91 | + deb/rpm packages execute the distribution jar directly. Consult ThingsBoard's |
| 92 | + own deployment documentation for the installation method you use. |
| 93 | +3. Add the configuration below to ThingsBoard's `thingsboard.yml`, or supply the |
| 94 | + equivalent environment variables. |
| 95 | +4. Restart ThingsBoard. On first start the module creates its database and tables |
| 96 | + in IoTDB, unless that bootstrap is disabled. |
| 97 | + |
| 98 | +The module is a Spring Boot auto-configuration, so no component scanning or code |
| 99 | +change is required on the ThingsBoard side. |
| 100 | + |
| 101 | +## 3. Configuration |
| 102 | + |
| 103 | +### 3.1 Activation |
| 104 | + |
| 105 | +Historical telemetry needs the timeseries selector plus the explicit opt-in: |
| 106 | + |
| 107 | +```Properties |
| 108 | +# select this backend for historical telemetry |
| 109 | +database.ts.type=iotdb-table |
| 110 | +# explicit opt-in; required together with the selector above |
| 111 | +iotdb.ts.experimental-raw-only=true |
| 112 | +``` |
| 113 | + |
| 114 | +Latest-value telemetry needs its **own** selector in addition to those two. If it |
| 115 | +is omitted, historical telemetry is stored in IoTDB while latest values stay on |
| 116 | +ThingsBoard's default backend, with no error at startup: |
| 117 | + |
| 118 | +```Properties |
| 119 | +database.ts_latest.type=iotdb-table |
| 120 | +# required when the latest DAO is active: sticky-routing | disabled |
| 121 | +iotdb.ts_latest.cluster_mode=sticky-routing |
| 122 | +``` |
| 123 | + |
| 124 | +Entity attributes are a separate, independent opt-in and are inert unless enabled: |
| 125 | + |
| 126 | +```Properties |
| 127 | +database.attributes.type=iotdb-table |
| 128 | +# required when the attribute DAO is active: sticky-routing | disabled |
| 129 | +iotdb.attributes.cluster_mode=sticky-routing |
| 130 | +``` |
| 131 | + |
| 132 | +### 3.2 Connection and schema |
| 133 | + |
| 134 | +| Property | Default | Meaning | |
| 135 | +| --- | --- | --- | |
| 136 | +| `iotdb.host` / `iotdb.port` | `127.0.0.1` / `6667` | IoTDB node address | |
| 137 | +| `iotdb.username` / `iotdb.password` | `root` / `root` | IoTDB credentials | |
| 138 | +| `iotdb.database` | `thingsboard` | Target IoTDB database | |
| 139 | +| `iotdb.session-pool-size` | `8` | Table session pool size | |
| 140 | +| `iotdb.schema.bootstrap` | `true` | Create the database and tables on first start; set to `false` to manage the schema out of band | |
| 141 | + |
| 142 | +### 3.3 Cluster mode |
| 143 | + |
| 144 | +`iotdb.attributes.cluster_mode` and `iotdb.ts_latest.cluster_mode` must be set |
| 145 | +explicitly when the corresponding DAO is active. Accepted values: |
| 146 | + |
| 147 | +* `sticky-routing` — writes for one identity are pinned to a single node |
| 148 | +* `disabled` — single-node deployment, or best-effort convergence accepted |
| 149 | + |
| 150 | +Any other value, including leaving it empty, fails at startup rather than |
| 151 | +silently. These write paths converge within a single JVM, so a multi-writer |
| 152 | +cluster needs one of the two acknowledgements above. |
| 153 | + |
| 154 | +## 4. Known Limitations |
| 155 | + |
| 156 | +* Attribute and latest-overlay writes converge within a single JVM. A clustered |
| 157 | + deployment must either pin each identity to one node (`sticky-routing`) or |
| 158 | + explicitly accept best-effort convergence (`disabled`) — which is why the |
| 159 | + cluster mode has to be stated rather than defaulted. |
| 160 | +* The latest-value path is derived from the telemetry table, with a small overlay |
| 161 | + for the latest-only write and delete paths that a pure derivation cannot |
| 162 | + express. |
| 163 | +* Table-level TTL is used for retention; see the module's |
| 164 | + [user guide](https://github.com/apache/iotdb-extras/blob/master/iotdb-thingsboard-table/docs/user-guide.md) |
| 165 | + for how it maps onto ThingsBoard's own retention settings. |
0 commit comments