Automation Delay

[643]

I’m experiencing random Automation Delays with the new app (version 5.5.0.)

For example; I have an automation to change mode from “Arm Away” to “Arm Home” set for 8AM every day.  When I look at the “Feed” the mode actually changes at times of 8:06, 8:07, 8:15, etc.  It never actually changes at 8AM.  This appears to have started occurring with the "new" app.  Any suggestions?

[643]

 @BrookeN I have been watching my feed for the past few days and the Automation is now changing at the expected times.  Can you please let myself (and others) know what caused this issue and what the resolution was.   Thanks. 

[jguerdat]

Glad it's better for you but that's not the case here. The daytime schedule change is usually at 6:00AM (but not always) and the nighttime change is usually at 11:03PM instead of 11:00PM.

[BrookeN]

@jguerdat thank you for letting me know you are still seeing the same behavior. I reached out to the development team to let them know. I will update you as soon as possible. 

[643 · Accepted solution]

Per an email I just received from Jeff N. (L3 Support) "There was some resource issue with our servers and now our Dev Team were able to fix it."

As far as the issue I was seeing this appears to be fixed.  However, I will continue to monitor and report back if things change.

[Edinburgh_lad1]

Not fixed for me either. 7:03am this morning and yesterday instead of 7:00am.

@BrookeN can we please have it fixed pronto (within days, not another few months of messages back and forth asking whether it's fixed yet; it's been long enough anyway)?

[Edinburgh_lad1]

21:01

Still not 21:00 as it's supposed to be. And it's now nearly Wednesday, even though we were told that this would be resolved by Monday.

[643]

@BrookeN have they fixed the resource issue across all the servers.  @Edinburgh_lad1 still has the timing issue, where my automation changes have been changing dead on schedule since last Thursday. 

[BrookeN]

Correct it should be fixed for everyone, I have the development team investigating the few users that are still seeing the behavior.

[jguerdat]

Checking my Feed, I see that starting on Monday every scheduled mode change is working as scheduled. The last time it changed a few minutes later was Sunday (3/23) night.

[BrookeN]

Can you watch it throughout the weekend and let me know by Monday if you are seeing it as resolved?

[jguerdat]

I'll keep checking.

[Edinburgh_lad1]

We should cast bets. As to when this is going to get fixed.

Anyways, mine is 3 min behind tonight. 

I'm not going to bother posting more about it unless I see it resolved, in which case I shall notify the Arlo team on here. Until then, one should assume that it's not fixed. 

 

[jguerdat]

---

@BrookeN wrote:

Can you watch it throughout the weekend and let me know by Monday if you are seeing it as resolved?

---

@BrookeN - Welp, it's Monday and...

At first all seemed well - every change was noted as on the hour as set. However, as of Saturday, 3/29, the issue started back up. It wasn't always one or the other mode switch but could be both. No rhyme nor reason...

[BrookeN]

Thank you for letting me know, I have reached out and let them know you are still seeing the same behavior. I will update you as soon as possible. 

[Edinburgh_lad1]

Mine seems to be working fine now. Not sure why it needed 6 months to fix this issue but I suppose one needs to be grateful it was fixed in the end. 

[Edinburgh_lad1]

It didn't last long, did it. 7:01 this morning. Can your team ever get anything right, or does it need to always be with several follow-ups? I find that tiring and unprofessional. 

[StephenB]

---

@Edinburgh_lad1 wrote:

It didn't last long, did it. 7:01 this morning.

Just wondering - how accurate do you think it needs to be to meet your needs?

Being one minute off on scheduling would be good enough for my purposes (my personal schedule is less precise than that).  The longer lags we had before would certainly have been a problem.

[jguerdat]

@StephenB while I agree that my delays aren't worth worrying about (in my specific case), I also agree that there's no known reason that a setting shouldn't happen at the time it's supposed to happen. I've had delays of as much as ~10 minutes although recently it's either dead on or off by maybe 2-3 minutes.

[StephenB]

---

@jguerdat wrote:

 there's no known reason that a setting shouldn't happen at the time it's supposed to happen. 

---

Of course Arlo doesn't say much about their architecture.  But based on the earlier fix, I think the scheduled mode changes are being executed in the Arlo Cloud.  In which case, reducing the uncertainty further might be quite difficult for them.

My question was intended to get a better sense for what accuracy @Edinburgh_lad1 (and others) need (and ideally some details motivating that need).

Arlo needs to assign a severity to each of their bugs, so they can prioritize the problems that have the biggest customer impact.  If I were involved in that activity, I'd prioritize a 2-3 minute lag as minor.  But I might be missing some use cases (and more importantly, so might Arlo). 

[Edinburgh_lad1]

Not to sound pedantic, i want to say that if I wanted my cameras to start recording at 7:01, I'd have had that as my change mode setting. Given your background @StephenB , I'm surprised you even asked that question, let alone contemplating asking it. 

So, going forward, if I set my cameras to start recording at a specific time, I expect Arlo to deliver that. If they don't, then their system has a fault and needs attention. It's also about responsibility, isn't it, that if my home gets burgled at 7am and Arlo didn't activate as it was supposed to, and knowing that this is a bug that hasn't been addressed yet, this can then easily be used in court.

Frankly, I don't care what level of urgency they apply to this case - it's their internal problem - but 6 months to address this issue, which seemed to have been addressed within a week, is ridiculous. We as customers have been more than patient. 

Not sure what level of customer service is expected in the US, but it sounds like it's different than what is expected here in Europe. 

[StephenB]

---

@Edinburgh_lad1 wrote:

Not to sound pedantic, i want to say that if I wanted my cameras to start recording at 7:01, I'd have had that as my change mode setting.

---

No idea what my background has to do with it.  But generally I don't stress about things that I don't think matter.  And when problem-solving I want to understand what's at stake (from the perspective of the person with the problem).

I am hearing that this is really an expectation (as opposed to an actual need).  Is that a correct appraisal?

There are a lot of real-time responses we actually need from the cloud.  Notifications, recording availability, livestreaming delay are three that IMO still aren't good enough, and which I think are a lot more important than tightening up a minute or two lag in scheduled mode changes. 

[Edinburgh_lad1]

>There are a lot of real-time >responses we actually need from the >cloud. Notifications, recording >availability, livestreaming delay are >three that IMO still aren't good >enough, and which I think are a lot >more important than tightening up a >minute or two lag in scheduled mode >changes. 

Absolutely. If they fixed things properly and with the necessary testing involved, they would not be in that position to have a backlog of things and overall, a very poor outcome. I'm not a beta user but a customer that chose, upon what they'd said they'd deliver, to spend my hard earned money. I therefore expect them to deliver. 

I thought your background was IT and you knew about the importance of testing etc. before releasing to the user. 

[StephenB]

---

@Edinburgh_lad1 wrote:

I thought your background was IT and you knew about the importance of testing etc. before releasing to the user. 

---

I never worked in IT, though I have sometimes worked with IT on various projects. My background is actually in software development with a focus on real-time communication systems. 

I totally understand the need for testing, and we all see the need for quality improvements in the Arlo system.  

I want Arlo to stay focused on fixing the issues that matter most, before they move on to minor irritations.  Arlo clearly needs a major rewrite of automations (too many bugs and too complex for real-world users).  So further reducing the automation lag time in the current implementation isn't something I'd spend any effort on now. They have much bigger problems they need to work on.

[Edinburgh_lad1]

What was wrong with the other version of the app? Why was there a need to re-write a good and, most importantly, working product? It's clearly a waste of resources and someone should have been fired for that decision. 

Who thought that those automations was a good idea? Whoever approved that should have been fired, too. 

Why was the deployment of the buggy app not stopped immediately? Why was there never an apology for the mess? Why is the management of addressing fixes so slow and convoluted ? 

Most importantly, why is Arlo directing its resources to making the current users' experience so miserable by implementing deliberate 'fixes' that result in their systems not operating properly (I refer here to HD, Pro, Pro 2 camera users)?