Timings

[Edinburgh_lad1]

I've mentioned this before, though probably in passing: I find it strange that my modes, even though they're scheduled to activate at 7am, 1pm and 11:30pm, actually don't always do: 7:03, 1:03 etc etc. For a system that is meant to watch over your property, that's rather poor.

And it's not my connection before anyone starts blaming access to the internet: I have FTTP and I've tested using twk different smart hubs and two different routers. 

 

[alex_loo]

interesting.  I suppose you are referring to Routines >> Automations >> schedules.  I have created 2 schedules there (7:30am switching to from STANDBY to ARM HOME, and 11:30pm switching from ARM HOME to STANDBY).  Both schedules have been running flawlessly, up to the minute.

(and this is on the of the crappy ARRIVE/LEAVING aka geofencing that has been failing most of the time)

[Edinburgh_lad1]

Cheers @alex_loo 

Do they show exactly those times in the Feed, too?

What is recorded in my Feed does correspond to the times the system is armed/disarmed. So, even though one of the cameras is scheduled to arm at 1pm, it does arm at 1:03pm or 1:04pm. And either 1:03pm or 1:04pm does show as the time in the Feed. 

[alex_loo]

Yes, I can see the modes switched ON at the exact time I have scheduled ---- in the FEED

[alex_loo]

I don't understand.  You don't see arming on device level, but on mode level (home or away or standby).  Then you assign cameras to these modes, or NOT.

[Edinburgh_lad1]

Yes, I do have cameras assigned to different modes. Once the mods have approved the picture, you'll be able to see it yourself. My modes are also linked to schedules. So, at 1pm, only the front door camera records, whereas at 11:30pm, all are active. The interesting thing is that these modes don't activate at the times they're supposed to, but with a wee delay of usually 2-3 minutes and not all of them have this kind of delay and not always - sometimes they activate at the times they're supposed to.

[alex_loo]

are you on subscription?  wondering if schedules are kick-started differently from non-subscriptions.

(I am still having my trial subscription)

[jguerdat]

Just a thought @Edinburgh_lad1 , do you have a security hub, too? My modes change properly but I may not get the notifications/chirp from the hub until as late as 10 minutes later. It's usually much quicker but can be delayed.

[MichaelT90]

I've just had it confirmed that you absolutely cannot, under and circumstances have both schedules and geofencing, only 1 or the other, and they've half advised against geofencing.

So if you have anything relating to geofencing remove it, and see if it behaves better. 

Also, I find a similar thing, sometimes it's on time, sometimes it's after a few minutes, sometimes it can be hours before it switches. Opening the app sometimes kicks it into gear, other times I can manually switch it, then it will switch back to the previous mode... Are you suffering with anything like that?

[Edinburgh_lad1]

Are geofencibg and schedules not working because by design or because there is an issue? These two are different. 

That aside, I have no geofencing on. Just schedules and these don't kick in at the correct time, though there has been an improvement lately.

So, something to do with the Arlo side of things, rather than my configuration.

[StephenB]

---

@Edinburgh_lad1 wrote:

Are geofencing and schedules not working because by design or because there is an issue? These two are different. 

---

Both are simply triggers in "Feed". 

1. At time X switch to Mode A
2. When everyone leaves, switch to Mode B
3. when everyone arrives, switch to Mode C

This creates some challenges when you combine geofencing and scheduling, since in general the mode you want to switch into when someone arrives or leaves depends on the time of day.

Arlo's attempt to solve the challenges is to allow you enable/disable automations from other automations

• When everyone leaves, switch to mode B and disable Automations X and Y 
• When someone arrives, switch to mode C and enable Automations X and Y

And I think also have the automation trigger include the current system mode

• At time x, switch to mode B if the system is in Mode C

Getting the automation logic right for all scenarios is pretty hard (I suspect impossible for some scenarios without more modes) -  and if you get it wrong you can end up with automations stuck in the disabled state until you manually start them again.  So IMO there is a big design flaw here. 

FWIW, personally I'd have provided a home and away schedule, and automatically switched when geofencing kicked in.  I'd also switch to the appropriate schedule when someone selects "home" and "away" from the app or from the home security system.  

But there are also bugs, since several users have found that some of the advanced settings in the automations don't actually work.

[MichaelT90]

@Edinburgh_lad1 that's the part I want an answer to...

@StephenB thank you for the explanation to us all. Unfortunately your theory is spot on, but in practice, the automations don't always enable/disable when schedules dictate. Often they even get stuck, so I've had it where we're away, and they're struck in home mode, or we're home and they're struck in away mode... If I switch modes, the automation switches it back... The only solution for me is to remove automations and do it manually... Hoping I remember, and hoping it saves. 

For me the issue isn't the logic, rather the processing behind the logic, which I think is also @Edinburgh_lad1 s issue.

[MichaelT90]

in fact I've just double checked my feed, it's randomly setting to arm away throughout the day, even when it is set to arm away... Often around 11:00am, but never bang on, but then again at other random times throughout the day... Hey you don't reckon the automations are really just some guy in a shed trying to keep up and manually setting it for us all do you? 🤣

I should add, I work from home and all phones were indeed at home when this arm away happens.

[StephenB]

---

@MichaelT90 wrote:

but in practice, the automations don't always enable/disable when schedules dictate.

---

I agree that its buggy (and said as much above).  But if they just fix the bugs, I still think that most users will find geofencing+scheduling too difficult.  So IMO it needs a major overhaul.

It is curious that the scheduled changes are a couple minutes off.  I see several ways that could happen, depending on whether the schedule changes are driven from the cloud or whether they are instead stored in the cameras.  I am wondering how much it actually matters (as long as the changes are within a couple of minutes). 

---

@MichaelT90 wrote:

in fact I've just double checked my feed, it's randomly setting to arm away throughout the day, even when it is set to arm away

---

Are there any indications that it is setting to an incorrect mode (not just randomly re-setting to the mode it is supposed to be in?)

[MichaelT90]

So, at 8am ours are supposed to disarm, they might, sometimes between 8:00 and 8:10, sometimes between 11:07 and 11:15, but about 50% of the time they just don't disarm, and on those days I try to do it manually and they rearm within a couple of hours without notification. 

I think this sounds similar to @Edinburgh_lad1 but slightly more erratic. I have had to just permanently arm them now, when I run out of fair use, so be it. 

It's resetting to the mode it thinks it should be in. 

Interesting thing I did do, to test the modes set correctly if I "test" the automation and they don't reset. Ever! (I then have to recreate all my automations again to get them to even have a hope in working)

[StephenB]

---

@MichaelT90 wrote:

but about 50% of the time they just don't disarm

---

That's a big fail, and not one I've seen a lot of posts about.

Are you also using Arrive and Leave automations?  Or just timed schedules?

[Edinburgh_lad1]

That's very erratic indeed with those big delays.

@StephenB it's not a big issue on the surface but since we're dealing with computers and CCTV systems, you'd want the timings to be accurate, no? So, if your car is stolen at 7:00 and the system arms at 7:04 for some reason, but is supposed to arm at 7:00, can you sue a CCTV company that the crime would have been preventable but wasn't because of the bug in the system in the sense that had you been notified about the suspicious activity taking place (= motion), you'd have gone out to check and to prevent it?

There's a very famous and current case here in the UK about the Horizon system used by the Royal Mail that simply caused financial inaccuracies because of software bugs, resulting in *a lot* of personal, and in some cases very tragic, circumstances. Of course, it's a different situation in terms of the  emotional impact on individuals at the moment (but see my example above), with people being deeply personally affected by their faulty Horizon system, but the idea/principle of responsibility is the same: if you argue that something is done by a system, then it needs to be done by a system; if it isn't, then it needs to be fixed.

And I just find it bizarre that the times are not accurate.

Also, since you mentioned: what features in automations don't work properly?

[MichaelT90]

I was using both, then just timed, the geofencing was ignored, and my day routine was ignored and overridden 50% of the time (literally works properly every other day, which is even weirder!!)

[MichaelT90]

That's a very interesting comparison... And the erratic nature of when things arm/disarm it wouldn't surprise me at all if what we're seeing is manual corrections... It would explain a lot. 

From what I've been told so far, it appears that you can have either geofencing or schedules, but in my experience neither work reliably.

[StephenB]

---

@Edinburgh_lad1 wrote:

@StephenB it's not a big issue on the surface but since we're dealing with computers and CCTV systems, you'd want the timings to be accurate, no?

---

I do want the timing to be accurate, and agree this should be fixed.  But if the lag is small, then I'd prioritize the other issues with automations.

I think geofencing automations have to be triggered by the cloud (getting location info from the app).  Schedule changes could be triggered by the cloud as well, though it is also possible that the on-premise cameras (and smarthubs if you have them) are triggering them.

Either way, there are several possible causes of the lag.  I am wondering if you see the lag only when arming the cameras, or if you also see the lag when disarming (getting recordings after the disarm time).

---

@Edinburgh_lad1 wrote:

Also, since you mentioned: what features in automations don't work properly?

---

I don't have a full list, and it is a moving target.  Some folks have tried to use the exception feature (change to mode X at time Y only if the mode is Z) and found that the "only if" wasn't handled correctly.   There have been other posts on the disable/reenable other automations not working right in the past.

[Edinburgh_lad1]

@StephenB both airing and disarming. There's no pattern. Top level support put me in contact with technical support. Let's wait and see, but if they ask me to reboot/reset the whole system, which they will, I'll scream! 

I've not checked about whether recordings are made before the lag, but I really have no time. Besides it's support that should figure all that out, not us, though I'm very appreciative of your help and contributions, as well as those of others. 

[MichaelT90]

Funny enough, I had this issue yesterday! 

Doorbell rang (Arlo doorbell, mechanical chime). Chime rang, a whole 3 minutes later, my phone rang, and another 5 or so minutes after that, our Amazon echoes finally announced the doorbell rang! 

I darent report it, I expect I'll be asked to turn it all off and on again, and remove and re-add everything... Again... It's not worked any of the 10s of times before, what's changed? Lol!