Timestamps and Timezones on GIV API Data

3 comments started 2023-06-27 last 2023-06-27
APIsHome Automation
U
#1 unclebob

Hi all,

I am writing some Python code to pull down my half hourly readings using the template already provided in the API docs.

All of my other data (Octopus and N3rgy) I have stored in GMT regardless of the actual timezone I am in- both have the timezone in the date/time data so easy to check and correct as needed...

Giv Data on the otherhand does not!

So my understanding was that the data was based on the inverter time - so I pulled the inverter time, and then todays data, which doesnt match! The inverter time is '2023-06-27T08:50:56Z' but the latest data on the inverter is currently 09:30

{'time': '2023-06-27T08:50:56Z', 'solar': {'power': 1622, 'arrays': [{'array': 1, 'voltage': 155.5, 'current': 3.4, 'power': 534}, {'array': 2, 'voltage': 194.9, 'current': 5.5, 'power': 1088}]}, 'grid': {'voltage': 244.6, 'current': 2, 'power': 9, 'frequency': 50}, 'battery': {'percent': 64, 'power': -1088, 'temperature': 22}, 'inverter': {'temperature': 34.5, 'power': 451, 'output_voltage': 242.2, 'output_frequency': 49.96, 'eps_power': 0}, 'consumption': 441}
2023-06-27T08:50:56Z
2023-06-27 00:00 0 0 0 0 0 0.25 0
2023-06-27 00:30 0 0 0 0 0 0.24 0
2023-06-27 01:00 0 0 0 0 0 0.21 0
2023-06-27 01:30 0 0 0 0 0 0.22 0
2023-06-27 02:00 0 0 0 0 0 0.19 0
2023-06-27 02:30 0 0 0 0 0 0.21 0
2023-06-27 03:00 0 0 0 0 0 0.2 0
2023-06-27 03:30 0 0 0 0 0 0.21 0
2023-06-27 04:00 0 0 0 0 0 0.2 0
2023-06-27 04:30 0 0 0 0 0 0.2 0
2023-06-27 05:00 0.03 0 0 0 0 0.19 0
2023-06-27 05:30 0.04 0 0 0 0 0.14 0.01
2023-06-27 06:00 0.12 0.02 0 0 0 0.07 0.01
2023-06-27 06:30 0.19 0.1 0 0 0 0 0
2023-06-27 07:00 0.16 0 0 0 0 0.06 0
2023-06-27 07:30 0.21 0.1 0.02 0 0 0.16 0
2023-06-27 08:00 0.25 0.54 0 0 0 0 0
2023-06-27 08:30 0.24 0.76 0.01 0 0 0 0
2023-06-27 09:00 0.35 0.6 0.02 0 0 0 0
2023-06-27 09:30 0.18 0.19 0 0 0 0 0
2023-06-27 10:00 0 0 0 0 0 0 0
2023-06-27 10:30 0 0 0 0 0 0 0
2023-06-27 11:00 0 0 0 0 0 0 0
2023-06-27 11:30 0 0 0 0 0 0 0
2023-06-27 12:00 0 0 0 0 0 0 0
2023-06-27 12:30 0 0 0 0 0 0 0
2023-06-27 13:00 0 0 0 0 0 0 0

So is there a definitive way to check the timezone of the data provided or request it in a certain timezone.

Timezone has been collected from 🇦
inverter/{inverter_serial_number}/system-data/latest

And inverter data from:
inverter/{inverter_serial_number}/energy-flows

T
#2 Tim

I think the inverter operates and posts data to the cloud in Zulu (UTC) timezone but the API knows that you're in the BST timezone. Unfortunately, you can't specify UTC in the POST parameters whereas I'm sure you would be able to with N3rgy (I can with Glow). It's also a pity that the objects returned in the POST object don't qualify the time period as either BST (which I think you're right in thinking this is), or UTC/Z.

I use Node RED for my automation logic within Home Assistant and knowing whether daylight savings time is currently active or not is a continuous issue almost everywhere. To that end, I have a few lines of code which I use to set a variable in the trigger message which I then use to adjust the time and also set a flag to indicate whether DST is active now or not. You may not be familiar with the syntax, but I'm sure its close enough to Python for you to get the gist.

var tStamp = new Date()
var localH = tStamp.getHours()
// node.warn("Local Hour " + localH)
var utcH = tStamp.getUTCHours()
// node.warn("UTC Hour " + utcH)
var tzOffset = tStamp.getTimezoneOffset()   //  minutes to adjust for timezone offset from UTC
// node.warn("Timezone Offset " + tzOffset)
msg.dstNow = (utcH != localH) //  Daylight Savings Time is/is not current

This code gives the correct offset minutes and dtsNow flag value while in daylight savings time and not.

U
#3 unclebob

Tim
Thanks for the info.

I may have to have a play and see if I can set the timezone of my python code somehow and trick the request into thinking its from a UTC timezone rather then having to mess about with working out the timezone and adjusting if possible...

Otherwise I will have to have a punt at the current timezone data (which I want to avoid incase Giv change it in the future!) and convert it to UTC.