Adding (batch) status with TZ = UTC and having PVOutput map it?

Ideas
#1

I’m working on making it as easy as possible to upload heatpump consumption data to PVOutput for non-programmers. I’m hopeful it’ll help drive heatpump adoption for those who are skeptical or scared of making the switch.

As part of that, I’d like to remove any possible confusion/problems around timezone configuration on either the client side or the server (PVOutput) side.

Considerations:

  • UNIX timestamps are UTC. Converting these to YYYYMMDD and HH:MM is trivial.
  • Per the API docs, some endpoints support a tz parameter, but most don’t.
  • PVOutput.org has a timezone setting for every system, this is easy for a user to configure once and then forever forget
  • PVOutput’s per-system settings already have some settings wrt TZ handling: General → Timezone has Data will be adjusted to your selected timezone above as its help text, System → Live settings → Timezone has the same help text, but there’s also System → Adjust for DST has Update time sent to the API for devices that do not support DST as help text.

⇒ it’s trivial to upload data to PVOutput in UTC; this also avoids incorrect TZ configuration on the client
⇒ PVOutput already says in multiple places “data will be adjusted to time zone”, so … it should work
⇒ the Adjust for DST setting links to Live Data — PVOutput documentation, and has rather confusing help text, where it claims to only apply to generation data, not consumption data and claims to only apply a 1-hour time offset for DST? :thinking:

So: what do you recommend? Ideally, I’d upload everything with tz=UTC and have PVOutput convert as needed.

I already experimented with this. Over at G2C — HP inside 0.050kW, I am already uploading using UTC date + time, the system is already configured to my time zone (Europe/Brussels, with currently summer time active, so: CEST), with Adjust for DST off, but the data is not adjusted to my timezone (+0100 and due to summer time currently +0200).

The charts/data are off by 2 hours from the actual clock time, i.e. they’re literally respecting the precise data I provided rather than computing the proper offset.

Looking forward to your recommendations! :blush:

#2

Its possible to add “ts” (unix timestamp) as an alternative to the current “d” and “t” parameters.

The system should have timezone configured however.

Changing this to an ‘idea’.

1 Like
#3

Interesting!

Does that mean I can send a UNIX (i.e. UTC) timestamp and as long as it is aligned to 5-min intervals, it will get converted to the right HH:MM automatically?

So: 1683464100 is 12:55 today UTC, but 14:55 in Brussels (CEST). If I send a request with 1683464100 it will get displayed as 14:55 if my system’s time zone is Europe/Brussels?

#4

Its possible to add “ts” (unix timestamp) as an alternative to the current “d” and “t” parameters.

Tried that with addstatus, but I get:

Bad request 400: Invalid Time [null]

Further, how would I be able to do that using addbatchstatus, since there’s no explicit d and t parameters there, just a sequence of parameters?

#5

This is just a suggestion for future enhancement to the API.

#6

Oh, hah, sorry! :sweat_smile:

#7

Facing a similar problem, why don’t you add a capital T for uploads in UTC and a lower case t for input in local time?

Clarification - are date times in local or UTC