Meaning / correctness of timestamps of device.get_energy_data

[goofy2k]

I am currently testing the tapo module with my P110 smart plugs. I can get the data from the devices with all of your API calls in the TAPO_p110.py example, which is great !

I am now specifically looking into the device.get_energy_data calls for hourly, daily and monthly data and am trying to understand the various output parameters. The code delivers values for start_timestamp and end_timestamp. To understand their meaning I convert them to a Python datetime object and print them.

For the hourly data I get results that make sense, but for daily and monthly data the start and end values are equal. Is that something in the device output or in the post-treament in your module? I give example results below.

Energy data (hourly): {'data': [12, 12, 12, 12, 13, 12, 12, 12, 12, 12, 12, 12, 11, 12, 12, 12, 12, 4, 0, 0, 0, 0, 0, 0], 'end_timestamp': 1716422399, 'interval': 60, 'local_time': '2024-05-22T17:20:07', 'start_timestamp': 1716336000}
start date_time: 2024-05-22 02:00:00 start_ts: 1716336000
  end date_time: 2024-05-23 01:59:59   end_ts: 1716422399

Energy data (daily): {'data': [8254, 10030, 6695, 4636, 3577, 1448, 499, 632, 2044, 3888, 3002, 1391, 725, 284, 5862, 8314, 9891, 5180, 9461, 7752, 3727, 6723, 5831, 4619, 8553, 4575, 4301, 3228, 3523, 962, 289, 289, 716, 3948, 2240, 1047, 905, 3385, 2470, 711, 290, 290, 293, 292, 289, 287, 288, 288, 286, 286, 291, 208, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'end_timestamp': 1711929600, 'interval': 1440, 'local_time': '2024-05-22T17:20:07', 'start_timestamp': 1711929600}
start date_time: 2024-04-01 02:00:00 start_ts: 1711929600
  end date_time: 2024-04-01 02:00:00   end_ts: 1711929600

Energy data (monthly): {'data': [238328, 327085, 236519, 139607, 19388, 0, 0, 0, 0, 0, 0, 0], 'end_timestamp': 1704067200, 'interval': 43200, 'local_time': '2024-05-22T17:20:07', 'start_timestamp': 1704067200}
start date_time: 2024-01-01 01:00:00 start_ts: 1704067200
  end date_time: 2024-01-01 01:00:00   end_ts: 1704067200

[mihai-dinculescu]

This is a quirk of the tapo API.

When requesting the data, an end timestamp is always required. However, this end timestamp is not used for daily and monthly data. So rather than pointlessly asking the user for an end date that won't be respected or calculating the quarter end, I made it send an end timestamp equal to the start.

Unfortunately, the response contains both timestamps as provided in the request, and I agree that this is confusing.

I'm not sure how to address this. My current best guess is to remove the end_timestamp from the response.

[goofy2k]

From your answer I conclude that the start_timestamp should be meaningful. Going to have a look on that...

Op do 23 mei 2024 10:26 schreef Mihai Dinculescu @.***>:

This is a quirk of the tapo API.

When requesting the data, an end timestamp is always required. However, this end timestamp is not used for daily and monthly data. So rather than pointlessly asking the user for an end date or calculating it, I made it send an end timestamp equal to the start one.

Unfortunately, the response contains both timestamps as provided in the request, and I agree that this needs to be clarified.

I'm not sure how to address this. My current best guess is to remove the end_timestamp from the response.

— Reply to this email directly, view it on GitHub https://github.com/mihai-dinculescu/tapo/issues/221#issuecomment-2126523364, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGII3TQV5DGZUCBME4CAWO3ZDWR3JAVCNFSM6AAAAABID5G4COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRWGUZDGMZWGQ . You are receiving this because you authored the thread.Message ID: @.***>

[goofy2k]

I checked the timestamps and data against the graphs in the app. ALL start_timestamps are indeed meaningful and corresponding with the start of the data in a period. This is also true for the end_timestamp for the hourly data.

So, having start_timestamps is sufficient for connecting a datapoint to the specific time period. The reported local_time can be used recognize the last fully completed time period in a series.