Lights Dont Come on after Daylight Savings Change

I understand the frustration. It was clearly related to the DST issue, but what I am seeing now is not representative of that issue I would say.

When you first noticed the problem, due to the time change, which schedules failed to work? Did only the back yard schedule fail originally? From what I understood, both failed, rebuilding rules resolved one.

I would not imagine rebuilding the rules would be a fix for one device and not the other, same model, if both originally failed. Rules have been rebuilt twice with the same overall result. That is why I suggest narrowing focus on the Back yard device and re-adding it.

All I can find out about the DST issue now is that they are looking for the cause/necessary variables currently. As soon as I know more I’ll post.

I did not re-pair or do anything. I was informed by somone at the house that the backyard came on tonight.

Hopefully they find the root cause of this so it doesn’t happen in the spring. Since I did not touch the system, I would think it supports the fact that this is on their end.

Thanks for your help

I did not re-pair or do anything...Since I did not touch the system, I would think it supports the fact that this is on their end.

That would not be technically true. Your panel is being “touched”, but it is being done remotely via airfx.

Since I did not touch the system, I would think it supports the fact that this is on their end

That would actually lead me to the opposite in this case.

I have no doubt the local rules are failing at the DST switch due to some interaction with the panel based on how the schedule is saved from the back-end. I have been giving info to ADC and working with support regarding this issue.

However, the back-end does not send commands to turn on lights for schedules, it does not process the action of scheduled changes - rules are created in Alarm.com, sent to the panel, saved in the module memory, and run locally.

All schedules failing at once indicates a problem with the schedule, how it is saved, or how it interacts with the panel. One schedule failing intermittently suggests issues locally.

When you reported schedules had failed, we sent commands to re-save all of your schedules, rebuild the rules, which clears previous saved schedules and replaces them.

Since most schedules started working, one that did not may indicate that it simply did not get saved properly. Rules were sent again.

You reported it did not work again, making me think that locally, there is an intermittent issue.

If it then worked without further intervention, it reinforces that conclusion. Since that device is not providing identical product info to the same model of switch on your account, I would suggest trying to re-enroll to see if that improves function.

Enrolling from too far of a distance can negatively affect performance down the line. Also, if you have added any devices since enrolling the switches and have not run a network rediscovery, that may also cause issues with certain routing commands.

The best troubleshooting step at this time would be to re-enroll that switch close to the panel, run a network rediscovery, then recreate the schedule and then test reliability.

So mine were working fine until tonight. None of my sunset timers fired tonight. The morning timers did fire fine. Alarm.com is getting on my nerves, from the very long delays accepting commands to now this.

So mine were working fine until tonight. None of my sunset timers fired tonight

Same here. Automation never turned off this afternoon. I deleted the rule and recreated it. Tested it. Working again.

Also noticed my image sensor on alarm.com was showing screen as if I had just installed it.

Sounds like a possible ADC update occurred?

Mine were working, then I did all the things you told me to do. Re-“paired” 6 feet away from panel, deleted my old rules and recreated while leaving the switch 6 feet away from the panel for 30 minutes. Rediscovering.

It worked last night.

Tonight, Front lights went on, but the backyard lights (that I re-paired) did not go on tonight.

I really think this is on ADC end, just like it is on the countless times it has been in the past (after all the days and weeks of dialogue telling me differently until they come to the conclusion its on their end)

Information about these issues tends to trickle as more and more evidence is available.

Locally, rules being recreated should solve the issue, temporarily, when it occurs.

The issue, while I do not have much first hand evidence, I would guess to be some error in the calculation occurring when the sunset algorithm runs. Some data variable combination likely causes a failed calculation (date/location/time/etc.) or it could be the panel is not processing the schedule due to some limitation. When I know more of an exact reason I can update.

What is interesting is the different response of the OP’s rules. One sunset schedule works, one does not.

Have all other reported instances here been any and all sunset rules fail? Does anyone else have multiple?

The frustrating thing is the happens every 6 months. I have email threads with Shea and Karven (sp?) where we go over this extensively only to find its on ADC end and they never implement a permanent solution. Last time it was all switches. This time it is only one. We will see what happens tonight because all have gone on in the last week last night was the first time only one went on. When I recreated the rules though, the front yard lights went of and I had to manually turn on

from the very long delays accepting commands to now this.

That would be a separate issue. Can you create a new forum topic regarding this? We can look into signalling. Please list which commands with which you notice a significant delay.

My automation is time based. It should be noted that after I recreated and tested the rule yesterday, it again failed this morning. (makes me wonder if someone tried to “repush” the rules or something last night).

I have again, reset and tested the rule for automation on/off. Seems to be working now (so don’t mess with it on backend).

Definitely seems like an ADC issue to me.

they never implement a permanent solution. Last time it was all switches. This time it is only one.

Think of it not based on switches. The switches do not retain any info, they have no memory. It is based on calculations in the schedule rules saved at the panel. Different failures from one instance to the other indicate changes have been made.

I understand the frustration. If it doesn’t affect all instances where the rules exist it is very difficult to track down, especially given that testing amounts to going over instances of failure after the fact.

Is everyone experiencing the issue using a 2GIG Go!Control Panel?

My automation is time based

So the failure you noticed was not a sunset/sunrise schedule, but a specific time-based rule?

How many schedules failed to run? Did any successfully run around the same time?

How many schedules failed to run? Did any successfully run around the same time?

I only currently use one time based light automation rule (aquarium on at 7am, off at 4pm). Evolve dimmer plugin module, mult level scene switch

One active Alarm based rule for all light GE/Jasco switches (on for alarm event, off when disarmed)

The others GE/Jasco binary power Switch automation rules are disabled (used to simulate morning and evening, and late night activities (like turning on lights at 4am to get a late night snack from kitchen, then turn off lights 10 min later, or on at at dusk, and off around 11pm, or on at 5am off an hour after sunrise) when we are gone for extended period of time to mimic someone being home.

Please to do not mess with my backend automation rules. It is working again, and I don’t want to keep messing with it.

Please to do not mess with my backend automation rules. It is working again, and I don’t want to keep messing with it.

No troubleshooting has been done on your system.

I am asking so I can have a detailed picture of what rules have failed on which accounts. ADC engineers are looking into the error, presumably expecting sunrise/sunset errors due to DST and focusing on that, but if you have a specific time set that did not work, that is a different type of schedule activation, does not use the same algorithm, and could be handy as a cross-reference.

Post above edited

ADC engineers are looking into the error,

That is what worries me, once they start mucking around on the back end, all kinds of stuff starts to go wrong. They evidently have no clue what the problem is, so they are messing with (trial and error?) config changes across the board.

I know something happened yesterday, because the IS page on alarm.com was on the multi hour test screen just like you see when you initially install the alarm.com sensor, and then my empower automation rules failed.

…like an update was pushed across the board, or a reset, or something to that extent.

I find it inexcusable for this issue to drag on for years. Daylight savings comes every 6 months and this consistently happens. And it always starts out the same, being told it is something on the customer’s end. Then I have to argue for weeks. Please re-read my original post.

And every six month, you have to start from scratch and argue with all kinds of new people as you are being told its on your end each time. Like there is no record of this kept even though it happens every 6 months!

The person I emailed to after Shea Lowrey at ADC was Carven Krekelberg. There are countless people I have spoken to, but don’t have names.

If my switch was bad, why did it work for so many months? If all the information was sent months ago to the swtich and its not kept at ADC, why did it fail? Why is my switch completely adressable when I manually bring up the on and off setting on the panel or on a webpage and have it work?

Please give customers the benefit of the doubt. Please have ADC work going forward like they have accountability instead of going forward that the customer is messed up or is not doing something right.

ADC: The first step at recovering for alcoholism is admitting you are an alcoholic. (That was an analogy BTW)

My concern is when I need ADC will they be there. I have been a customer for about 7 months and while I understand this is a complex technology, my old school alarm worked flawlessly for 23 years until I decided to upgrade. Now there are all the issues with ADC, they are just asking for a competitor to swoop in and take some business and if the right one comes in with the right solutions, bye bye ADC. Also ADC is just looking into it? If I were travelling what confidence do I have that this system will work? Also mine worked fine until a massive miss on numerous rules last night. I am eager for a competitor to prove to me they can do better and well as I said bye, bye.

Companies like this typically get bought out and I think there is regulation and laws that prevent them from just going under without notice. The other good thing is that if you are with SuretyCam, your panel is unlocked and it is easy to switch service to someone else.

On a side note, my lights came on tonight. Both of them. Did not touch a thing.

What I would do if I was ADC is:

#1 State the issue they found
#2 State how they resolved it
#3 State what steps they are taking from preventing it from happening again
#4 Apologizing on the low side. On the high side; apologizing and compensating people for the hassle (like a free month of service or being really smart and giving affected people something free like a image sensor almost forcing them to buy more service and further entrenching them into their service)
#5 Making sure SuretyCam has this info so they can post it on this thread

These are basic customer service skills.

I am eager for a competitor to prove to me they can do better and well as I said bye, bye.

Well if you have 2GIG you can use other competitors to ADC (Uplink and Telguard). Good luck. Features and Quality will be like going from Lexus to Fiat.

The new Ferrari 488 is technically a Fiat