2-GIG Go!Control panel: Time did not adjust correctly coming off DST

Support
, , , ,
1

I use a 2-GIG Go!Control panel / system. It is interesting to note the many threads / entries in the forums which deal with devices not functioning after a daylight savings time (“DST”) change, but my little issue is far more fundamental: the time did not even adjust properly from “daylight” to “standard” in the first place.

I checked the Go!Control panel today (Sun Nov 5) at about 11:45 am PST (correct time), and the clock on the panel showed “10:45 am”. The clock adjusted back not just one, but TWO hours. If it had not adjusted at all, it would have still shown “12:45 pm”.

I have had this panel for about 7 years. For all that time, the change between daylight and standard time has been automatic, and always correct. The firmware was upgraded to the latest rev. level when I switched over to Surety from Vivint earlier this year, and also the cell card was changed from ATT to Verizon. That was after DST started in 2017, so there was no issue then, of course. Today, being the 1st Sunday in November, the clock should have instantly (more or less) been adjusted BACK one hour at 2 a.m. today (Sun Nov 5).

I have no automation associated with the system, so nothing to fail there, and am still able to arm and disarm as normal. Whether this proves to be a “technical” issue or a “service” issue - well - I guess we will see. I am in the Pacific Time Zone (North America), and the system uses cellular for base station communication (Verizon).

I have read replies in the forums that state that systems with cell communication should be adjusted for “DST” / “no DST” automatically. One would think this would be true anyway because of the default settings in the panel. I checked system Q-66 and indeed it is “enabled”, and Q-67 thru Q-70 are all set to the correct (default) parameters of current daylight time standards.

Even if the “DST” time was not correct previously, it would be logical that the controlling NTP source (either at Telco or Surety / Alarm.com) should have taken care of setting it correctly (in fact, I believe, the correct system time should be maintained by the upstream provider at all times).

Can you offer any insight regarding this system behavior? I’m perfectly willing to wait until March 2018 to see what happens then, but it would at least be interesting to know if my system is acting as a “one-off” or if you are familiar with others that have seen the same issue. Cell system (Verizon) problem, perhaps?

BTW - I “resolved” the issue for now by manually moving the system time up to the correct setting. I have never had to do that before.

Thank you!

2

When connected to an Alarm.com service provider, time on the panel and the timezone settings are controlled via Alarm.com settings. You can actually view the time-zone setting by logging into Alarm.com and navigating to Settings - Account Management - System Information.

For clarity, The time on the panel cannot be manually controlled other than at the panel. We have an option to set panel time, however it is simply a single “Set Time” command that sets the panel time based off of current settings.

As a test, I’ve used that command to set the panel time. Does it remain at the correct time, or has it reverted to the incorrect time?

Anecdotally at least I can offer that neither my own home panel, nor any test 2GIG panel connected to ADC accounts here show an incorrect time.

I am not 100% sure how 2GIG’s own software handles the switch if no provider is connected. It is possible this is simply a +1h, -1h within the 2GIG Panel. I’m curious if the panel time simply synced to ADC and then the Go!Control subtracted an hour. If no communication/commands happened between ADC and the panel Time may not have synced again by the time you noticed it that morning. I’m not sure how else that might occur, considering timezone settings for this system appear to have always been correct.

3

Thanks for the reply, Jason. Currently the time on the panel is still correct. I think it will be the best approach to observe time sync behavior next March, when going back on to DST. If it still can’t do the automatic changeover at that point, we can delve into this more deeply. Thanks again.

4

That’s probably the only thing to do here. I would say with pretty solid confidence that the issue is that 2GIG changes occurred after ADC changes, and the panel and ADC had not yet synced again. If you ever do notice it again, just try running a cell phone test at the panel. This should force a sync with ADC. If it resolves the time difference then that would be a very convincing answer.