I've been exploring GoSungrow. I've noticed a few "oddities" but I don't know whether they represent the expected behaviour or are worthy of a bug report.
Apologies in advance for the length of this.
tl;dr
I started out wondering what timezone was being displayed for GoSungrow show point data commands.
The answer seems to be local time, as known to the server (ie UTC+11 at the moment).
I wondered if I could influence that to return UTC+10 365 days a year? Changing the timezone for a command or the whole machine does have an effect but not the one I expected.
the detail
Here's my example command:
$ GoSungrow show point data 202302270000 202302280000 5 1203625_1_1_1.p5 1203625_1_1_1.p7
In words, "I want the MPPT voltages (.p5 & .p7) at five minute intervals, for the whole day of February 27 2023."
On the face of it, the panels started generating at 06.35 and shut down at 20:25. Where I am (Cootamundra), sunrise on 27 Feb was 06:53 AEDT, sunset 19:48 AEDT, so "what the panels saw" includes 20-30 minutes of twilight-photons.
The alternative hypothesis is the report is in AEST (UTC+10). If so, sunrise would be 05:53 AEST, sunset 18:48 AEST. That doesn't make sense in terms of the observed PV output so I think it's reasonable to conclude that the time-range parameters and the report are both being interpreted in terms of one of:
The timezone set for the inverter in iSolarCloud (UTC+10); or
The timezone for the augateway.isolarcloud.com server; or
The local timezone on my requesting system (Australia/Sydney), currently UTC+11.
So far, so good. But I really want NEM time (UTC+10) throughout the year. On Unix, local system time can be overridden, per command, via the TZ environment variable:
As an aside to anyone unfamiliar with this syntax, yes, Australia/Sydney is either UCT+10 (standard time) or UTC+11 (summer time) so it does look like that "GMT-10" is wrong but this syntax where the sign of the offset is illogical comes from a time way way back in computer history and we're sort of stuck with it.
Using that strategy with GoSungrow:
So, the body of the table is not affected at all but, for some reason, setting TZ changes the order in which that summary line is produced. I interpret that as saying:
There's some response to a timezone change within the GoSungrow code, although why that should affect the metadata is not immediately obvious.
The table body remaining unchanged invites the conclusion that I'm seeing the server's timezone in the data rows.
I can go one step further:
Even though I'm pretending to be in Perth, there's still no change to the body of the table. Timestamps are pinned to AEDT. As mentioned before I selected UTC+10 in iSolarCloud (and double-checking shows it has stuck) so these UTC+11 timestamps must be the server's.
Which likely implies they'll switch between AEST/AEDT twice a year. Which, to my mind, is suboptimal when it comes to storing time-series in databases, which is what I actually want to do. Still, I now know the answer to the question I started with and I can deal with that.
That leaves the metadata changing around. I find that behaviour puzzling. I've been in the coding game since 1975 and if there's one thing I've learned it's that s/he who ignores unexplained behaviour is likely to wind up with teeth-marks where the Dread Dog of Destiny has had an unexpected snack. That's really why I felt motivated to pen this issue.
So: feature or bug?
one more oddity
In the earlier examples I picked metrics .p5 and .p7 to keep the output manageable. I'm interested in a few more metrics than just those two but here's a slightly different selection:
$ GoSungrow show point data 202302270000 202302280000 5 1203625_1_1_1.p2 1203625_11_0_0.p83072 1203625_7_1_1.p8018
Although I'm new to this, my understanding is 1203625_1_1_1 is the inverter, 1203625_11_0_0 is the plant, and 1203625_7_1_1 is the meter. In other words, that command is asking for one metric from each.
These are just the first few lines:
All the column titles have come back with 1203625_11_0_0 (the plant). But if I stick those same keys back into the command:
$ GoSungrow show point data 202302270000 202302280000 5 1203625_11_0_0.p2 1203625_11_0_0.p83072 1203625_11_0_0.p8018
the answer is:
So, the "inverter" and "meter" metrics have been dropped.
Not being able to use the column titles from the preceding step as selectors in the subsequent step is another thing that has the feeling that it's less feature, more bug, but again, I'm very new to this so I really have no idea.
I've been exploring GoSungrow. I've noticed a few "oddities" but I don't know whether they represent the expected behaviour or are worthy of a bug report.
Apologies in advance for the length of this.
tl;dr
I started out wondering what timezone was being displayed for
GoSungrow show point datacommands.The answer seems to be local time, as known to the server (ie UTC+11 at the moment).
I wondered if I could influence that to return UTC+10 365 days a year? Changing the timezone for a command or the whole machine does have an effect but not the one I expected.
the detail
Here's my example command:
In words, "I want the MPPT voltages (.p5 & .p7) at five minute intervals, for the whole day of February 27 2023."
This is the pattern I see when I run that:
On the face of it, the panels started generating at 06.35 and shut down at 20:25. Where I am (Cootamundra), sunrise on 27 Feb was 06:53 AEDT, sunset 19:48 AEDT, so "what the panels saw" includes 20-30 minutes of twilight-photons.
The alternative hypothesis is the report is in AEST (UTC+10). If so, sunrise would be 05:53 AEST, sunset 18:48 AEST. That doesn't make sense in terms of the observed PV output so I think it's reasonable to conclude that the time-range parameters and the report are both being interpreted in terms of one of:
So far, so good. But I really want NEM time (UTC+10) throughout the year. On Unix, local system time can be overridden, per command, via the TZ environment variable:
Using that strategy with GoSungrow:
So, the body of the table is not affected at all but, for some reason, setting TZ changes the order in which that summary line is produced. I interpret that as saying:
I can go one step further:
Even though I'm pretending to be in Perth, there's still no change to the body of the table. Timestamps are pinned to AEDT. As mentioned before I selected UTC+10 in iSolarCloud (and double-checking shows it has stuck) so these UTC+11 timestamps must be the server's.
Which likely implies they'll switch between AEST/AEDT twice a year. Which, to my mind, is suboptimal when it comes to storing time-series in databases, which is what I actually want to do. Still, I now know the answer to the question I started with and I can deal with that.
That leaves the metadata changing around. I find that behaviour puzzling. I've been in the coding game since 1975 and if there's one thing I've learned it's that s/he who ignores unexplained behaviour is likely to wind up with teeth-marks where the Dread Dog of Destiny has had an unexpected snack. That's really why I felt motivated to pen this issue.
So: feature or bug?
one more oddity
In the earlier examples I picked metrics .p5 and .p7 to keep the output manageable. I'm interested in a few more metrics than just those two but here's a slightly different selection:
Although I'm new to this, my understanding is
1203625_1_1_1is the inverter,1203625_11_0_0is the plant, and1203625_7_1_1is the meter. In other words, that command is asking for one metric from each.These are just the first few lines:
All the column titles have come back with
1203625_11_0_0(the plant). But if I stick those same keys back into the command:the answer is:
So, the "inverter" and "meter" metrics have been dropped.
Not being able to use the column titles from the preceding step as selectors in the subsequent step is another thing that has the feeling that it's less feature, more bug, but again, I'm very new to this so I really have no idea.