AD110 Timezone Issue

[scribby]

Hi,

I have an issue with my doorbell where the time is out by an hour, timezone is currently set to UTC+9:30 for Adelaide/Australia time however with daylight savings the time should be UTC+10:30

Issue is the DST setting in the app makes no difference, I have tried hard defaulting the unit and changing the DST value with reboots in between with no success. There is no UTC+10:30 option either which I could use to temporally fix the problem.

I'm also running the latest firmware.

[GaryOkie]

Try running this command to see exactly what the internal DST settings are and to confirm if the app is actually changing them...

<ip_addr>/cgi-bin/configManager.cgi?action=getConfig&name=Locales

Mine shows the DST year start/end as "2020", but otherwise I am getting the right hour. You can change these values via the API. For example:

/cgi-bin/configManager.cgi?action=setConfig&Locales.DSTEnable=false

/cgi-bin/configManager.cgi?action=setConfig&Locales.DSTStart.Year=2021

You can also set the time but I don't think that will help as the AD110 will contact an NTP server every 5 minutes to adjust the time if necessary.

Here's the command to verify your time zone and NTP server settings.

/cgi-bin/configManager.cgi?action=getConfig&name=NTP

and to change NTP settings, for example contact an Australia NTP server once an hour...

/cgi-bin/configManager.cgi?action=setConfig&NTP.Address=ntp1.anu.edu.au&NTP.UpdatePeriod=60

[scribby]

Thanks Gary,

Updated the DST start and end dates, had the wrong months and years which explains why DST setting didn't work.

[GaryOkie]

great - thanks for confirming that helped solve it.

[pspeirs]

Hi All,

I found I have the same problem, I'm looking at making the adjustments via the API, but I do have a few questions on this.

table.Locales.DSTEnable=true
table.Locales.DSTEnd.Day=1
table.Locales.DSTEnd.Hour=0
table.Locales.DSTEnd.Minute=0
table.Locales.DSTEnd.Month=3
table.Locales.DSTEnd.Week=0
table.Locales.DSTEnd.Year=2022
table.Locales.DSTStart.Day=2
table.Locales.DSTStart.Hour=0
table.Locales.DSTStart.Minute=0
table.Locales.DSTStart.Month=10
table.Locales.DSTStart.Week=0
table.Locales.DSTStart.Year=2022
table.Locales.TimeFormat=yyyy-MM-dd HH:mm:ss


Why are the years not shown as current, but set to 2020? Doesn't this come from the NTP server?
Does the Day represent the day number of the week, if so, is the format 1-7 or 0-6 and which day is the start day. I ask this because the Week parameter is currently set to 0, whereas it would normally be represented as 1-4 (sometimes 5).
Once updated correctly, could I expect that it will change years (although I'm not sure why the year is even included in the DST table) automatically or will I need to go through this process again next year?

Is the API documentation actually available somewhere?

Regards,
Paul

[Revo2Maxx]

Hello Paul and Welcome to the Forum

To be honest if your start and stop time is showing a different year I am wonder if they were installed in that year. I say this because if I run the commands on some of my Cameras they come back different years. Like my AD110 I just reset and it shows 2022 however my AD410 I have had installed since last year and haven't reset it since last year and it shows 2021. So I think that is the year the setup was made for that camera..

Now that is a guess because I do so much testing a Resetting of my cameras and recorders that all of my hardware is showing 2021 and 2022.. That is why I am guessing it is data from installed year..

for the API maybe here
https://support.amcrest.com/hc/en-us/ar ... TP-API-SDK

[pspeirs]

Much appreciated, thats probably the most comprehensive API documentation I've seen in a long time. Working through, we'll see how it all ends up.

[dahai8]

The problem appears to be that Amcrest missed a bit with DST settings on their doorbell cameras.
For Instance: In the midwest (US), the dates those "Spring-Forward" and "Fall-Back" times are not on fixed calendar dates.

Central Standard Time Zone
Central Standard Time (CST) is a standard time zone in use from the first Sunday in November to the second Sunday in March—when Daylight Saving Time (DST) is not in effect. Central Daylight Time (CDT) is used during the remainder of the year.

https://www.timeanddate.com/time/zones/ ... the%20year.

Whereas on my camera, set for UTC-6:00 and DST enabled, the firmware shows:

Code: Select all

table.Locales.DSTEnable=true
table.Locales.DSTEnd.Day=1
table.Locales.DSTEnd.Hour=0
table.Locales.DSTEnd.Minute=0
table.Locales.DSTEnd.Month=11
table.Locales.DSTEnd.Week=0
table.Locales.DSTEnd.Year=2020
table.Locales.DSTStart.Day=2
table.Locales.DSTStart.Hour=0
table.Locales.DSTStart.Minute=0
table.Locales.DSTStart.Month=3
table.Locales.DSTStart.Week=0
table.Locales.DSTStart.Year=2020
table.Locales.TimeFormat=yyyy-MM-dd HH:mm:ss

Notice it is fixed at Nov 1 (Tuesday this year (2022)) and NOT the first Sunday of November. So my camera started timestamping incorrectly starting Tuesday this will, but will again be correct from Sunday Nov 6th on...at least until March 2, of next year.

Reading the API Docs, it appears that the 'Day' field is 1-31 (day) if Week=0, or 0-6 (Sunday - Saturday) if Week > 0.
So it is

Code: Select all

DSTEnd.Week=1
DSTEnd.Day=0

and

Code: Select all

DSTStart.Week=2
DSTStart.Day=0

Basically setting Week to the Day values instead and setting Day to 0

it might work correctly for Central Time Zones in the US with DST. Caveat Emptor. I have not tried this.

P.S. I check the firmware on my IP2M-841B Camera at it does shows the settings I described above for correct DST Start/End and that camera does switch over on the correct dates.

Code: Select all

table.Locales.DSTEnable=true
table.Locales.DSTEnd.Day=0
table.Locales.DSTEnd.Hour=0
table.Locales.DSTEnd.Minute=0
table.Locales.DSTEnd.Month=11
table.Locales.DSTEnd.Week=1
table.Locales.DSTEnd.Year=2022
table.Locales.DSTStart.Day=0
table.Locales.DSTStart.Hour=0
table.Locales.DSTStart.Minute=0
table.Locales.DSTStart.Month=3
table.Locales.DSTStart.Week=2
table.Locales.DSTStart.Year=2022
table.Locales.TimeFormat=yyyy-MM-dd HH:mm:ss

[raw65]

I just encountered this issue as well. Setting Day/Week start and end worked for me. Thank you!

BTW, use digest authentication when using curl or Postman. Took me a few minutes to notice that!

[ExTechjunkie]

My DST settings for my AD110 specify EasternTime (GMT -5) with DST enabled, DST beginning on the 2nd Sunday of March. (Settings below.) Why then has my AD110 jumped ahead one hour on March 2nd at midnight (from Friday into Saturday)?

table.All.Locales.DSTEnable=true
table.All.Locales.DSTEnd.Day=0
table.All.Locales.DSTEnd.Month=11
table.All.Locales.DSTEnd.Week=1
table.All.Locales.DSTEnd.Year=2024
table.All.Locales.DSTEnd.Minute=0
table.All.Locales.DSTEnd.Hour=2
table.All.Locales.DSTStart.Day=0
table.All.Locales.DSTStart.Month=3
table.All.Locales.DSTStart.Week=2
table.All.Locales.DSTStart.Year=2024
table.All.Locales.DSTStart.Minute=0
table.All.Locales.DSTStart.Hour=2

Coincidentally, several of my ONVIF cams made the same jump a week early on the 1st Sunday at 2AM (instead of the 2nd Sunday).

Why is it so hard for the firmware programmers to get NTP & DST right?