Hi,
The script I have written to analyse the downloaded logs bombed out, whereas it had not before (I download the logs a month at a time)
After investigation I found that the DATE TIME in the logs changes as follws:
2024-03-31 00:55:34 GMT+0000
2024-03-31 02:00:34 BST+0100
My understanding is this...
Now we are one hour ahead of GMT
BST indicates that we are operating in British Summer Time… this year we pt the clocks forward 1 hour, so BST indicates we are one hour ahead
So to me BST+0100 indicates we are two hours ahead, as BST iss one hour, and +0100 means we are one hour ahead
Have you come across this before…
I need to know how I take account of it
Effectively my calculation is trying to work out the time interval; between the two times
Larger time – smaller time = Interval
2024-03-31 02:00:34 BST+0100 - 2024-03-31 00:55:34 GMT+0000 = -55mins to me which is why the script is going wrong
If it were
2024-03-31 02:00:34 GMT+0100 - 2024-03-31 00:55:34 GMT+0000 = +5mins which would be right
Or of it were
2024-03-31 02:00:34 BST+0000 - 2024-03-31 00:55:34 GMT+0000 = +5mins which would be right
So I think the Fox app is incorrect, it should be showing :
Either BST+0000, with the time it is currently showing
or
GMT+0000 with the current hour being shown -1
Effectively FOX have doubled the Britich Summer Time change
Everyone agree?
Or have I got it wrong somehow?
App 2 - Logs GMT/BST log date confusion
-
- Posts: 19
- Joined: Sun Jan 21, 2024 10:32 am
16 x 420 Watt Panels (REC420AA Pure-R). 8 East, and 8 West facing
1 x H1-6.0 (6kW Inverter)
1 x ECS2900-H4 (11.52 kWh Total Battery Storage)
1 x H1-6.0 (6kW Inverter)
1 x ECS2900-H4 (11.52 kWh Total Battery Storage)
This caught me out on Sunday as I had my inverter set to charge the batteries at the cheap rate from 4am until 5am. I picked this time so it was away from the clock change but for some reason it charged from 5am until 6am instead, possibly due to the reason you highlight.
Everything was normal the next day though.
Everything was normal the next day though.
-
- Posts: 1411
- Joined: Thu Oct 13, 2022 7:21 pm
The actual date times in the cloud are stored in UTC standard and then converted into your timezone, so it looks like what it is doing is it is telling you that the first is in 'GMT' timezone which is UTC time +00:00 , the second time appears to have been adjusted to be in the timezone BST which is UTC time +01:00.
It's a strange way of doing it, i've never really thought of BST as being a timezone but it makes sense that it is GMT in summer time.
For data consistency you would have to convert back to UTC to store them, and then convert back to local timezone to display them - but I think the net result would be the same as using their conversion which gives you the actual time in your timezone.
It's a strange way of doing it, i've never really thought of BST as being a timezone but it makes sense that it is GMT in summer time.
For data consistency you would have to convert back to UTC to store them, and then convert back to local timezone to display them - but I think the net result would be the same as using their conversion which gives you the actual time in your timezone.
-
- Posts: 19
- Joined: Sun Jan 21, 2024 10:32 am
Thanks Guys
I think you have confirmed that it is not me
It seems that Fox have converted to a log time, by doubling the Summer Time change
So whereas the two logs should be 5 minutes apart, the following indicates -55mins
2024-03-31 00:55:34 GMT+0000
2024-03-31 02:00:34 BST+0100
Maybe in my script I will edit the +0100 always back to +0000, before parsing it. Then just the BST part should be taken into account
Shame as I was trying to create a generic analysis script, and this makes it Fox specific
I wonder if Fox employees ever tread these posts?
I will send the issue back in the App feedback form
Thanks
Malcolm
I think you have confirmed that it is not me
It seems that Fox have converted to a log time, by doubling the Summer Time change
So whereas the two logs should be 5 minutes apart, the following indicates -55mins
2024-03-31 00:55:34 GMT+0000
2024-03-31 02:00:34 BST+0100
Maybe in my script I will edit the +0100 always back to +0000, before parsing it. Then just the BST part should be taken into account
Shame as I was trying to create a generic analysis script, and this makes it Fox specific
I wonder if Fox employees ever tread these posts?
I will send the issue back in the App feedback form
Thanks
Malcolm
16 x 420 Watt Panels (REC420AA Pure-R). 8 East, and 8 West facing
1 x H1-6.0 (6kW Inverter)
1 x ECS2900-H4 (11.52 kWh Total Battery Storage)
1 x H1-6.0 (6kW Inverter)
1 x ECS2900-H4 (11.52 kWh Total Battery Storage)
-
- Posts: 19
- Joined: Sun Jan 21, 2024 10:32 am
Hi all
It seems that Fox have changed the app since last month
Previously…
2024-06-01 00:02:09 BST+0100
Now…
2024-06-01 00:02
However this is for the same Date Time
Does anybody know if they are now showing GMT correctly for the whole year from now on
I must admit I had forgotten my previous post above... and finished my script ages ago.
So I assume that I now have to change it again
Anyone know for sure???
Thanks
Malcolm
It seems that Fox have changed the app since last month
Previously…
2024-06-01 00:02:09 BST+0100
Now…
2024-06-01 00:02
However this is for the same Date Time
Does anybody know if they are now showing GMT correctly for the whole year from now on
I must admit I had forgotten my previous post above... and finished my script ages ago.
So I assume that I now have to change it again
Anyone know for sure???
Thanks
Malcolm
16 x 420 Watt Panels (REC420AA Pure-R). 8 East, and 8 West facing
1 x H1-6.0 (6kW Inverter)
1 x ECS2900-H4 (11.52 kWh Total Battery Storage)
1 x H1-6.0 (6kW Inverter)
1 x ECS2900-H4 (11.52 kWh Total Battery Storage)
-
- Posts: 1411
- Joined: Thu Oct 13, 2022 7:21 pm
I don't use it much but there was a change a couple of weeks back that broke the download so it's probable they did something then to correct it - I can confirm when I look at the .csv's on my system I see exactly what you are seeing i.e. Now… 2024-06-01 00:02Malcolm_(User) wrote: Fri Aug 02, 2024 3:03 pm Hi all
It seems that Fox have changed the app since last month
Previously…
2024-06-01 00:02:09 BST+0100
Now…
2024-06-01 00:02
However this is for the same Date Time
Does anybody know if they are now showing GMT correctly for the whole year from now on
I must admit I had forgotten my previous post above... and finished my script ages ago.
So I assume that I now have to change it again
Anyone know for sure???
Thanks
Malcolm
Unfortunately this being Fox, it's likely only the developers will know for sure and as much as we ask for release notes they don't issue them - that said I would recommend checking the download on the 27th October to see if it has auto-adjusted to DST
-
- Posts: 19
- Joined: Sun Jan 21, 2024 10:32 am
Thanks David
I wish I would get notified of responses on the forum (apologies for my late thanks)
Cheers
Malcolm
I wish I would get notified of responses on the forum (apologies for my late thanks)
Cheers
Malcolm
16 x 420 Watt Panels (REC420AA Pure-R). 8 East, and 8 West facing
1 x H1-6.0 (6kW Inverter)
1 x ECS2900-H4 (11.52 kWh Total Battery Storage)
1 x H1-6.0 (6kW Inverter)
1 x ECS2900-H4 (11.52 kWh Total Battery Storage)
-
- Posts: 19
- Joined: Sun Jan 21, 2024 10:32 am
I have just raised this:
There are two issues with the app now
1) Firstly as I have raised below previously. The downloaded logs continue to download in the following form:
2024-03-31 00:55
to
2024-03-31 02:00
2024-10-27 01:57
to
2024-10-27 01:02
They should either download as GMT permanently, or (preferably) add a single time zone offset to indicate what time zone is being used (in the form +0000, +0100 for instance)
2) There is a new problem when downloading Octobers data. If you try and download either using ‘Month’ Oct, or select Custom ‘2024-10-1 to 2024-10-31’. You get a ‘Data report query exception’. Further if you try to download the custom time ‘2024-10-1 to 2024-11-1’, you get the different error as follows ‘The time is less than 30 days’ (strangely).
However you can successfully download the logs in two parts 1st to 30th, then 31st to 31st
Cheers
There are two issues with the app now
1) Firstly as I have raised below previously. The downloaded logs continue to download in the following form:
2024-03-31 00:55
to
2024-03-31 02:00
2024-10-27 01:57
to
2024-10-27 01:02
They should either download as GMT permanently, or (preferably) add a single time zone offset to indicate what time zone is being used (in the form +0000, +0100 for instance)
2) There is a new problem when downloading Octobers data. If you try and download either using ‘Month’ Oct, or select Custom ‘2024-10-1 to 2024-10-31’. You get a ‘Data report query exception’. Further if you try to download the custom time ‘2024-10-1 to 2024-11-1’, you get the different error as follows ‘The time is less than 30 days’ (strangely).
However you can successfully download the logs in two parts 1st to 30th, then 31st to 31st
Cheers
16 x 420 Watt Panels (REC420AA Pure-R). 8 East, and 8 West facing
1 x H1-6.0 (6kW Inverter)
1 x ECS2900-H4 (11.52 kWh Total Battery Storage)
1 x H1-6.0 (6kW Inverter)
1 x ECS2900-H4 (11.52 kWh Total Battery Storage)
-
- Posts: 1411
- Joined: Thu Oct 13, 2022 7:21 pm
yes agree - not good, they do use UTC internally but must convert to local 'display' time without any offset marker when downloading which is unusual ...