influxDB - if item changes to fast, only the last state are stored in database

Dear all,
I want to migrate from rrd4j to influxDB because I need older data and not aggregated data.

Everything works fine and data are arriving in the database. As I understand ON = 1 and OFF = 0 in the database, fine

my config:

Items {
    gINFLUXDB* : strategy = everyChange

Now my problem:
I use this code for testing influxDB.

rule "etwas testen"
        Item SW_ZumTesten changed to ON
		logInfo("Logger", "SW_ZumTesten is started")

But only one entry is created in the database (0), the second one which changes to OFF. The first one (1) (ON) is not stored in the database.

If I use:

rule "etwas testen"
        Item SW_ZumTesten changed to ON
		logInfo("Logger", "SW_ZumTesten is started")

Both entries “1” and “0” are stored in the database.

For me it looks like influxDB persistance service is to slow for that very fast item state change?

I see no HTTP request for the “1” in the influxDB log.

If I remember correctly, that’s by design, only the last change is stored based on some time window. I have “one minute” in my mind.

Did you see such fast changes on rrd4j? I wouldn’t think so!

Anyhow, if the unwanted data aggregation was the only reason for deselecting rrd4j, that could be solved with rrd4j. Just by the use of a single archive. The remaining downside would be the fixed maximum time the data is kept, which has to be selected upfront.

Don’t want to hijack this thread, but I too have issues with the influxdb data transfer (OH3.3).
I’m monitoring the power returned from a device (solar plant). Every evening the power switches to 0 and rrdj4 shows 0 correctly (default persistence), but in influx it still shows a low value.
Since the strategie is OnChange, it stays at this low value - which is not the latest one. I have no idea which is happening :frowning:


I think I know whats happening. At 21:19 (19:19 UTC) there where many power changes according to the events.log. I wrote all entries in a excel sheet and made an average - it’s -2,753 (same as in influxdb).
Problem is that OH is not comparing the average from one minute to the next minute to write a new persistence entry using OnChange.

openHAB writes to persistence based on what your Item does. An onChange strategy would be linked to the Item state changes that you can see in your events.log.

What does that do? Does your Item really go to 0, or to UNDEF? (which will not be persisted)

Thank you for your respond. The Item really went to 0 and stayed this way.
I was looking closer into the data written in InfluxDB and it’s not an openhab issue.
Influx was aggregating the data into 1minute pieces. Because after the value 0 no other updates arrived, the average of the last minute (-2,753) stayed in the chart. I’ll have to find a solution in the chart.

I’m using influxDB with no changes. On my side there is no calculation or aggregation done in influxDB. The value from the item is directly written into the database.

Maybe you change the standard “retentionPolicy=autogen”

From the documentation:
When you create a database, InfluxDB automatically creates a retention policy called autogen with an infinite duration, a replication factor set to one, and a shard group duration set to seven days. See Database Management for retention policy management.