API requests for 'overTimeData10mins' returns data not matching the suggested value format

General
,
1

Hello,

I'm using overTimeData10mins to get the latest requests count for the 24h period (API 3.0).

After taking a look here, it seems that the expected result should be in the format of: 00:00:00 - 00:09:59, 00:10:00 - 00:19:59, and so on.
But, after checking the output, it's in the format of: 00:05:00 - 00:14:59, 00:15:00 - 00:24:59, and so on.

Example output shown in JSON format (epoch time in seconds):

  • Expected output: {"1488150000":xx,"1488150600":xx,"1488151200":xx,(...)}
  • Actual output: {"1696586100":xx,"1696586700":xx,"1696587300":xx,(...)}

I'm building a project where I will show an hourly graph, so I need to take into consideration all the queries from xx:00:00 to xx:59:59. And if it's from xx:55:00 to xx:54:59 it makes it harder to calculate the correct amount of queries in an hour, because I have to add the corresponding queries of the first 5 minutes (previous hour), and substract the corresponding queries of the firsts 5 mins (next hour) o be able to have statistics for a complete hour.

But, the data that Pi-hole shows on its WebUI (graphs) are in the correct format.

Maybe, some offset has to be applied to compensate the output of the API?

2

(If that's indeed your expected output, you should check your system's time:
1488150000 translates to Feb 27th 00:00:00 2017 (for a system in CET).) :wink:

I can confirm that api.php?overTimeData10mins returns 10 minutes slots starting at 5 minute boundaries, which is a deviation from the 0 minute boundaries shown on the dashboard.

@rdwebdesign, is this intentional, or is the web api calling FTL with an unwanted 5 minutes offset?

3

(If that's indeed your expected output, you should check your system's time:
1488150000 translates to Feb 27th 00:00:00 2017 (for a system in CET).)
My system time is correct, no delay is shown on my system.
I just put today's time to show an example.

4

If 1488150000 is today's time on your system, its clock would be off by more than 5 years.
Are you sure that's your time?
What does date +s% return on your system?

5
  • Expected output: {"1488150000":xx,"1488150600":xx,"1488151200":xx,(...)}, taken from the example of the FAQs page (copy paste). Not my system.
  • Actual output: {"1696586100":xx,"1696586700":xx,"1696587300":xx,(...)}, generated from my system.
6

This is calculated in FTL, but I think the 5 minutes offset is expected to correctly position the bars on the graph, between two timeslots.

The INTERVAL is 10 minutes. The values are shifted 5 minutes (INTERVAL/2):

1 Like
7

Actually, the data from each interval (from 0 to 10 minutes) is aggregated and placed exactly in the middle of the interval.

The point at 00:05 stores data from 00:00 to 00:10.

This difference is understandable. The FAQ was created many years ago. A lot of changes were made after that. The current output is centering the data, like described above.

3 Likes
8

Thank you guys for the explanation. I got it now.

9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.