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

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:

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’.

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?

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?

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

Oh, hah, sorry! :sweat_smile: