Typescript

.github/workflows/test-and-release.yml

@@ -28,16 +28,12 @@ jobs:
 
     runs-on: ubuntu-latest
 
-    strategy:
-      matrix:
-        node-version: [18.x]
-
     steps:
       - uses: actions/checkout@v4
-      - name: Use Node.js ${{ matrix.node-version }}
+      - name: Use Node.js 22.x
         uses: actions/setup-node@v4
         with:
-          node-version: ${{ matrix.node-version }}
+          node-version: 22.x
 
 
       - name: Install Dependencies
@@ -61,7 +57,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        node-version: [16.x, 18.x, 20.x]
+        node-version: [20.x, 22.x, 24.x]
         os: [ubuntu-latest, windows-latest, macos-latest]
 
     steps:
@@ -72,7 +68,9 @@ jobs:
           node-version: ${{ matrix.node-version }}
 
       - name: Install Dependencies
-        run: npm ci
+        run: |
+          npm ci
+          npm run build
 
       - name: Install Influxdb 1.x (Linux)
         if: startsWith(runner.OS, 'linux')
@@ -102,7 +100,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        node-version: [16.x, 18.x, 20.x]
+        node-version: [20.x, 22.x, 24.x]
         os: [ubuntu-latest]
 
     steps:
@@ -113,7 +111,9 @@ jobs:
           node-version: ${{ matrix.node-version }}
 
       - name: Install Dependencies
-        run: npm ci
+        run: |
+          npm ci
+          npm run build
 
       - name: Install Influxdb 2.x (Linux)
         id: influxdb2
@@ -160,18 +160,15 @@ jobs:
       github.event_name == 'push' &&
       startsWith(github.ref, 'refs/tags/')
     runs-on: ubuntu-latest
-    strategy:
-      matrix:
-        node-version: [18.x]
 
     steps:
       - name: Checkout code
         uses: actions/checkout@v4
 
-      - name: Use Node.js ${{ matrix.node-version }}
+      - name: Use Node.js
         uses: actions/setup-node@v4
         with:
-          node-version: ${{ matrix.node-version }}
+          node-version: 22.x
 
       - name: Extract the version and commit body from the tag
         id: extract_release

.gitignore

@@ -5,3 +5,5 @@ node_modules
 .idea
 exe
 /tmp
+/build/
+*.tgz

.releaseconfig.json

@@ -1,3 +1,6 @@
 {
-    "plugins": ["iobroker", "license"]
+    "plugins": ["iobroker", "license"],
+    "exec": {
+        "before_commit": "npm run build"
+    }
 }

LICENSE

@@ -1,6 +1,6 @@
 The MIT License (MIT)
 
-Copyright (c) 2016-2024 bluefox <dogafox@gmail.com>, apollon77
+Copyright (c) 2016-2025 bluefox <dogafox@gmail.com>, apollon77
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

README.md

@@ -91,6 +91,7 @@ CREATE USER "user" WITH PASSWORD '<userpassword>'
 CREATE DATABASE "iobroker"
 GRANT ALL ON "iobroker" TO "user"
 ```
+
 Enable authentication by editing /etc/influxdb/influxdb.conf:
 ```
  [http]  
@@ -105,6 +106,12 @@ Enable authentication by editing /etc/influxdb/influxdb.conf:
 ```
 - Restart service: ``` service influxdb restart ```
 
+## Self-hosted docker image for InfluxDB
+This version of the adapter could start a self-hosted docker image of InfluxDB 2.x.
+It is not opened for the network and only accessible from localhost. Of course, the docker environment must be installed and running on the host.
+
+The `iobroker` user must have access to the docker CLI. To fix the rights start `iob fix`.
+
 ## Installation of Grafana (Charting Tool)
 There is an additional charting tool for InfluxDB - Grafana.
 It must be installed additionally.
@@ -375,10 +382,9 @@ sendTo('influxdb.0', 'update', [
 If you want to flush the buffers for one or all data points to the Database, you can use the build in system function `flushBuffer`:
 
 ```javascript
-sendTo('influxdb.0', 'flushBuffer', {id: 'mbus.0.counter.xxx'
-, result => console.log('deleted, error: ' + result.error));
+sendTo('influxdb.0', 'flushBuffer', {id: 'mbus.0.counter.xxx'}, result => console.log('deleted, error: ' + result.error));
 ```
-if no id is provided all buffers will be flushed.
+if no id is provided, all buffers will be flushed.
 
 ## History Logging Management via Javascript
 The adapter supports enabling and disabling of history logging via JavaScript and also retrieving the list of enabled data points with their settings.
@@ -707,7 +713,7 @@ sendTo('influxdb.0', 'getEnabledDPs', {}, function (result) {
 
 The MIT License (MIT)
 
-Copyright (c) 2015-2024 bluefox, apollon77
+Copyright (c) 2015-2025 bluefox, apollon77
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

RetentionPolicies.md

@@ -1,48 +1,49 @@
 # Understanding retention policies
 
-It is important to understand how **Retention Policies** and **Shard Group Durations** are related in order to determine how long data will be kept in InfluxDB.
+It is important to understand how **Retention Policies** and **Shard Group Durations** are related in order to determine how long data
+will be kept in InfluxDB.
 
-
 
-Influx stores all measurements within a given time range into the same **Shard** which itself is part of a **Shard Group**. The Shard Group enforces a time range defined by `Shard Group Duration` to all shards, but it is set differently depending on the Influx release.
+Influx stores all measurements within a given time range into the same **Shard** which itself is part of a **Shard Group**.
+The Shard Group enforces a time range defined by `Shard Group Duration` to all shards, but it is set differently depending on the Influx release.
 
 When exceeding the configured `Shard Group Duration`,
 
 - a new Shard is created which stores newer measurement data from that point onwards
 - the old Shard with all its measurement-data is still kept in the database, but will be dropped, once the retention policy for the measurement is exceeded
-
 
 Measurement data-points are not deleted by Influx via "looking" at their retention policies individually, but instead the Shard as a whole is subject to retention policy check and will be dropped, if the retention policy is exceeded. The check however will only be performed on old Shards, meaning Shards that are still active are not checked, as they also still can receive new measurement data points.
 
-*Please refer to https://docs.influxdata.com/influxdb/v1.4/concepts/schema_and_data_layout/#shard-group-duration-management for more explanation and examples.*
-  
+*Please refer to https://docs.influxdata.com/influxdb/v1.4/concepts/schema_and_data_layout/#shard-group-duration-management
+for more explanation and examples.*
 
-The following two examples illustrate how the same retention period will be enforced differently, depeding on the configured Shard Group Duration.
+The following two examples illustrate how the same retention period will be enforced differently, depending on the configured Shard Group Duration.
 
-| | Example 1 | Example 2 |
-|--|--|--|
-| Retention Period | 2 hours | 2 hours |
-| Shard Group Duration | 1 hour | 1 day |
-| How long will data be kept at max? | 2 hours | 1 day |
-| Why? | The Shard is switched every hour, hence Influx will enforce the configured RP once **every hour** and keep only data from the **last 2 hours**. | The Shard is switched once a day, and Influx will then enforce the configured RP, meaning it will only keep data from the last **2 hours**. Because of this, measurement-data inserted at the beginning of the Shard-lifetime in theory should only be kept for 2 hours, but effectively will be kept a **whole day**. |
+|                                    | Example 1                                                                                                                                       | Example 2                                                                                                                                                                                                                                                                                                              |
+|------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Retention Period                   | 2 hours                                                                                                                                         | 2 hours                                                                                                                                                                                                                                                                                                                |
+| Shard Group Duration               | 1 hour                                                                                                                                          | 1 day                                                                                                                                                                                                                                                                                                                  |
+| How long will data be kept at max? | 2 hours                                                                                                                                         | 1 day                                                                                                                                                                                                                                                                                                                  |
+| Why?                               | The Shard is switched every hour, hence Influx will enforce the configured RP once **every hour** and keep only data from the **last 2 hours**. | The Shard is switched once a day, and Influx will then enforce the configured RP, meaning it will only keep data from the last **2 hours**. Because of this, measurement-data inserted at the beginning of the Shard-lifetime in theory should only be kept for 2 hours, but effectively will be kept a **whole day**. |
 
  ## iobroker.influxdb Adapter
 The Influx Adapter only allows you to select a **Retention Period** and itself will automatically choose the **Shard Group Duration** according to [official InfluxDB recommendations](https://docs.influxdata.com/influxdb/v2.0/reference/internals/shards/#shard-group-duration).
 
-| Bucket retention period | Default shard group duration |
-|--|--|
-| less than 2 days | 1h |
-| between 2 days and 6 months | 1d |
-| greater than 6 months |7d |
+| Bucket retention period     | Default shard group duration |
+|-----------------------------|------------------------------|
+| less than 2 days            | 1h                           |
+| between 2 days and 6 months | 1d                           |
+| greater than 6 months       | 7d                           |
 
 
-The Shard Group Duration can still be altered manually in the DB itself, but in order to keep the adapter configuration manageable, it can not be changed directly within ioBroker.
+The Shard Group Duration can still be altered manually in the DB itself, but in order to keep the adapter configuration manageable,
+it can not be changed directly within ioBroker.
 
-By design the adapter enforces only one global retention policy that applies to all measurements - regardless of the DB version that is used. The policy can be changed at any time, but for the reasons described earlier it might take a while for the changes to take effect.
+By design, the adapter enforces only one global retention policy that applies to all measurements - regardless of the DB version that is used. The policy can be changed at any time, but for the reasons described earlier, it might take a while for the changes to take effect.
 
 ## Additional considerations
 
 - The shard group duration is often configured shorter than the retention period, in order to be enforced effectively. But it is difficult to state this as a general advice, since other factors, like performance should be considered, too. If shard group durations are configured extremely short, this might be beneficial for housekeeping, but it could negatively impact performance, like causing longer query times, or slow write speeds.
-- A retention policy may not be lower than 1 hour. This was a choice made by Influx devs (https://github.com/influxdata/influxdb/issues/5198#issuecomment-166629531) and can only be bypassed by building InfluxDB from latest source with changed values directly.
--  Retention policies are checked by default every 30 minutes. This can be changed however in [server configuration for Influx 1.x](https://docs.influxdata.com/influxdb/v1.8/administration/config/#retention-policy-settings) and [server configuration for Influx 2.x](https://docs.influxdata.com/influxdb/v2.0/reference/config-options/#storage-retention-check-interval). This does **not** bypass the principles explained earlier. 
+- A retention policy may not be lower than 1 hour. This was a choice made by Influx devs (https://github.com/influxdata/influxdb/issues/5198#issuecomment-166629531) and can only be bypassed by building InfluxDB from the latest source with changed values directly.
+- Retention policies are checked by default every 30 minutes. This can be changed, however, in [server configuration for Influx 1.x](https://docs.influxdata.com/influxdb/v1.8/administration/config/#retention-policy-settings) and [server configuration for Influx 2.x](https://docs.influxdata.com/influxdb/v2.0/reference/config-options/#storage-retention-check-interval). This does **not** bypass the principles explained earlier. 
 - **Influx 1.x**: For existing dbs the adapter is able to detect the current default retention policy and will update it. If you modified retention policies manually and now are still experiencing missing data in the adapter, it might be related to the changed default-policy. See also here for more information: https://docs.influxdata.com/influxdb/v1.7/troubleshooting/frequently-asked-questions/#why-am-i-missing-data-after-creating-a-new-default-retention-policy.