Question on minimumSince (influxdb)

Setup, Configuration and Use Scripts & Rules
1

Hi there,

short question because I think I may got it wrong: What exactly is delivered with these lines:

var Number Tmin_1m = Weather_Out_Temp.minimumSince(now.minusDays(31), “influxdb”).state as DecimalType
var Number Tmin_3m = Weather_Out_Temp.minimumSince(now.minusDays(93), “influxdb”).state as DecimalType

Wheather_Out_Temp is a outdoor temperature sensor.

I wonder because of this: Tmin_1m gives me -7.2°C and Tmin_3m gives me -4.6°C. This is strange: The temperature -7.2°C should be inside the 93-days interval so that Tmin_3m should also report -7.2°C. I double checked that I did not swapped the variable names.

Can somebody explain this or is it a bug?

Thanks in advance and greetings from Germany!

  • Platform information:
    • Hardware: Intel NUC
    • OS: debian 9, kernel 4.9
    • Java Runtime Environment: zulu 8.31.0.1
    • openHAB version: 2.3.0
2

That sounds like a bug. But I can‘t see where it is. How often do you persist the value?

3

I made this entry in persistence/influxdb.persist:

Items {
// … many other items …
Weather_Out_Temp, Weather_Out_Hum : strategy = everyChange
}

It is a Homematic Outdoor Temp./Humidity Sensor (HG-HM-WDS10-TH-O) by the way if this is of any relevance.

I can send the whole data array or any other information that helps tracking down the issue (with the condition that you tell me how - I am not an expert in every part of OpenHAB and especially not with influxdb).

Looks like this only shows up with minimumSince- maximumSince looks reasonable. I may get the chance to switch to OpenHAB 2.4.0 within the next weeks. But I do not have hope that it’ll solve the issue.

4

Checked it again today and you can see the last 93 days in my image.

Around the last nights in January we got -7.2°C here which is delivered as Tmin_1m. With Tmin_3m I currently get -5.5°C which is the current temperature I am measuring at the moment.

I checked the two values by writing them to the log directly after they were calculated.

Capture
Capture.PNG1016×591 35.5 KB

I think it should be possible to construct a much simpler dataline to achieve the same fault. Where can I leave a bug report then?

5

[Edit:] The following post talks about rrd4j database and not about InfluxDB. I should have read the question more closely.

IMHO this is no bug!
You have to understand how rrd4j works, especially how the archives work.
rrd4j uses archives to store the data, each archive is setup for a specific time (counting from now backwards). The first archive holds data for every time step (each Minute). All other archives do have larger steps, the value stored for that step is CALCULATED from the oberserved (minutewise) steps (for example MAX, MIN, AVERAGE, LAST)
When you request data from rrd4j, the database will look into that Archive that covers the requested timeframe.

Coming back to your example. You have a value of -7.2C observed during the last month, but you do not see a corresponding value when looking into the last 3 month.
Assuming you are using the Default Settings for the archives:
“AVERAGE,0.5,1,480:AVERAGE,0.5,4,360:AVERAGE,0.5,14,644:AVERAGE,0.5,60,720:AVERAGE,0.5,720,730:AVERAGE,0.5,10080,520”);
That way way the
1.archive has 480 values , each for a minute step (covering 480 minutes, i.e. 6 hrs)
2. archive has 360 values, each for a 4 minute step (covering 1440 minutes, i.e. a day)
3. archive has 644 values, each for a 14 minute step (covering 5040 minutes, i.e. 3.5 days)
4. archive has 720 values, each for a 60 minute step (covering 43200 minutes, i.e. 30 days)
5. archive has 730 values, each for a 720 minute step (covering 525600 minutes, i.e. 365 days)…

Looking into the last month, you got values from archive 4 (averages over 60 minutes), looking into the last 3 month you got values from the archive 5 (averages over 720 minutes).
Since all values are calculated from averages, a value seen in archive 4 migth not be oberserved in archive 5.

If you have REST Docs installed, you can display all values saved in the different archives (by using the correct requested timeframe).

1 Like
6

But the OP is saying he is using influxDB…

1 Like
7

Ups!
:blush:
Disregard all said about rrd4j. I’m sorry.

Regarding infuxdb, doesn’t influxdb have a consolidation function as well? Can’t remember the used name for that. The effect should be the same as in rrd4j.

8

Yes but only if is it set-up and I understand that is not straightforward

9

Good that I installed influxdb and am not using rrd4j - loosing history data by a number cruncher algorithm would not be a good idea to archive data. But good to know how rrd4j is working; didn’t know that.

I logged in with influx to see the data by myself. With SELECT * FROM Weather_Out_Temp; I could see every measurement from the last 1.5 years. Especially this one is of interest:

2019-01-21T05:36:14.831Z -7.2

So as long as minimumSince uses this series to determine the minimum I would call it a bug then.

10

Just a thought; are your Items dimensioned now with Units of Measurement e.g. Number:Temperature? Did that change some months ago? Maybe there is a subtle difference how they get recorded.

11

This is the line for including the Item in openHAB:

Number Weather_Out_Temp “Temperatur[%.1f°C]” { channel=“homematic:HG-HM-WDS10-TH-O:homegear:SOME_SERIAL:1#TEMPERATURE” }

I have a decent backup system running on all systems. So I looked into the declaration that was used on August 2018 - it was the same there. And I do not have in mind that I changed it somewhen. Good thinking anyway.

12

If you do see the value in question using the command above, I’d suspect the “bug” in the way the values are plotted. How did you create the posted chart, with openhab directly, habpanel or even with grafana?