Every other Friday rule? (House Keeper Access)

elias1693

Member
I've setup a user ID and code for my house keeper. While going through the rules I enabled her access on Fridays during a certain time period. I could not find a way to enable to rule every other Friday. The only choices I found were every Friday. It what I'm trying to do possible? If so how?
 
Only way I can see an way to do bi-weekly would be to start using a counter and having a rule automatically add 1 to the counter every week, then make a pair of rules where your cleaner resets the counter and a rule that would only enable the user(s) if the counter was equal to or greater to the counter value.

I don't know if I'd go the whole complex route and would set up an event for when they disarm/arm the system personally, but that's me.
 
Using a counter or output is the only way I would know too - make sure you add provisions for if/when there's a power outage that resets it.

I'm on the wrong computer right now - but if there was a way to access week number that would be ideal.
 
Yes, counters or outputs are the only way to do that. The same holds true for doing something every x number of days (unless x is 7).

Write a rule that basically says the following. For every other you can use the toggle mode to save a rule.

Whenever the time is 12am
And it is Friday
Toggle output 100

Whenever the time is (whatever time you want you cleaning lady to start having access)
And it is Friday
And output 100 is on
Then enable user cleaning lady

Whenever the time is (whatever time you want her to lose access, no need to specify a day here)
Then disable user cleaning lady

So long as you have a good battery and you don't have really long power outages, you shouldn't need to worry about power failures.
You may need to manually change the output from on/off to start things off depending on whether the cleaning lady is comming this Friday or the next. After that it will stay on the every other schedule.
 
Lou,
You could do this without a phantom output, just via a counter, then increment/decrement using that user's arming or last user, and usually with users I tell my end users that they only have to have them enter a code to arm/disarm and no other functions. The rule I benched to try this uses the counter to increment/decrement and disables the user when the counter doesn't equal the normal value, and the condition of a time window would be easiest to address as a "later than" because I could foresee the issue of disabling the user while they still might be there or before they're onsite.

Takes up the same amount of "space" in rules

I had a massive "lesson" in doing similar with one of my commercial sites where we're using the M1 as access control and security...and a pile of outputs.
 
Lou,
You could do this without a phantom output, just via a counter, then increment/decrement using that user's arming or last user, and usually with users I tell my end users that they only have to have them enter a code to arm/disarm and no other functions. The rule I benched to try this uses the counter to increment/decrement and disables the user when the counter doesn't equal the normal value, and the condition of a time window would be easiest to address as a "later than" because I could foresee the issue of disabling the user while they still might be there or before they're onsite.

Takes up the same amount of "space" in rules

I had a massive "lesson" in doing similar with one of my commercial sites where we're using the M1 as access control and security...and a pile of outputs.

Del,

If I understand what you are saying, then the user only gets to disarm/arm the system once and then gets locked out. ??

Personally I like the fact that the cleaning people get locked out at a certain time, not after having done an arm. If they walk out and realize they forgot something, this lets them get back in.

In addition to the above rules, it would be good to add one that sends an email or calls you if the system is not armed by the expected time.

I chose to use output here rather than counter since output has a toggle mode. Since it was an every other Friday event toggle does what you need with just a single line of programming. If it were an every third Friday event, toggle wouldn't work and you would need several more lines of programming.

Personally I look at outputs as a binary variable whose only advantage over a counter (aka non-binary variable) is the toggle command. The disadvantage of course is that it is binary, so if you need more than a 0/1 it is a no go. With the Elk having vastly more outputs than virtually anyone would ever use, it is a pretty reasonable use of them.
 
You can do it for any time period with a single output and two rules. For example, say the cleaning lady comes in between 9:00AM and 5:00PM every third Friday...

Whenever time is 9:00AM
And day of week is Friday
And output is off
Allow cleaning lady to arm/disarm.

Whenver time is 5:00PM
And day of week is Friday
And output is off
Turn output on for 20 days 15 hours 59 minutes
Disallow cleaning lady to arm/disarm.

May take a little tweaking, and a little effort to get it "started" correctly, but I think it will work.
 
You can do it for any time period with a single output and two rules. For example, say the cleaning lady comes in between 9:00AM and 5:00PM every third Friday...

Whenever time is 9:00AM
And day of week is Friday
And output is off
Allow cleaning lady to arm/disarm.

Whenver time is 5:00PM
And day of week is Friday
And output is off
Turn output on for 20 days 15 hours 59 minutes
Disallow cleaning lady to arm/disarm.

May take a little tweaking, and a little effort to get it "started" correctly, but I think it will work.

OK, a challenge to get down to two rules. I can merge rules 1 and 3.

Whenever the time is (whatever time you want you cleaning lady to start having access)
And it is Friday
And output 100 is on
Then enable user cleaning lady

Whenever the time is (whatever time you want her to lose access)
And it is Friday
Then Toggle output 100
Then disable user cleaning lady

The second rule disables the cleaning lady every Friday, even the ones where she was never enabled in the first place, but disabling a user who is already disabled causes no harm and keeps you from needing a third rule.
 
In my case, I had a pile of outputs used in between KAM's XOVR's and RB's triggering other items. The counters are easy enough to modify and tweak just the same as the output, I used them to create access windows to enable/disable users based on time and day. The part of the logic equation for greater than, etc. takes that issue and then you decrement it to disable access, depending on how you want the person to lose access (time window, arm/disarm cycle, day of week, etc.)
Depending on the equation(s) and variables involved, that determines whether or not they get locked out, just have to take into consideration how much to "throw on the counter" and increment so if the date/time is within spec, then, for example, with enough "on the clock" so to speak, they'd be able to arm/disarm within their window multiple times, however once the clock struck midnight on their access, the decrement is automatic to below the threshold that allowed access in the first place.

If the counter is set appropriately to automatically increment by day, IE:14 allows access, then you have that user's disarm add 10 to that #, which would allow them multiple arm/disarm cycles, then at the end of their access window or day, then you pull the access down to a threshold that doesn't allow access or enable that user until it auto increments to that point.

It's just another way to accomplish the same thing, and the boolean choices are slightly more robust than a toggle.

That said, I wouldn't want to have to do this with a lot of users to create access windows and limit the users further, but I had a cleaning crew scenario, just not bi-weekly, and I also had a keyed shunt switch that was only enabled via a schedule, which would allow them to come in, use a code (credential accually) to gain access and disarm, and the shunt switch was designed to shunt interior protection in areas they were working in, but leave the perimeter armed. The system would auto re-arm the interior unless the shunt key was installed.
There were REX motions installed with KAM's/readers at the doors used for access so they'd auto-relock after someone walked out, keeping the building secure per se, with reports sent on a forced door or prop using outputs to trigger zones (as non-burg) to the CS.

Granted, this isn't the same as a full blown access control system and panels, like C-Cure, AMAG, Linel, CardKey or others, but in a small access control setting with security, it is doable.
 
So, I can totally see doing this for access control - where you just wouldn't let the cleaning lady in on the wrong days... but what is the real point of all this effort when she has a key? I mean - if she uses her key on Thursday, now you've got her inside the house but unable to disarm - which means a police dispatch and major disruption when you could otherwise know who it is.

Personally I'd have it text me (via emailing my cell phones text message address) when she comes and goes - and if she comes on the wrong day, I can do something about it. Otherwise if her code doesn't work but she uses her key, all you or the alarm company knows is the front door was opened and the alarm sounded - but you have no idea who it is. I'd possibly do the rule for fridays between 8 and 5 or so though and tell her that's the only time she can disarm - but I wouldn't even bother with the "every other friday" rule.
 
I have a similar cleaning situation. There’s an eight hour access window. Elk sends a text message for arm/disarm. Occasionally, the schedule gets bounced around, but the day-of-week is very static. Is it really worth all the programming trouble to be 100% stringent – especially if you are not home? For me, the lock-out is mostly a peace of mind for when I am home. Each new programming rule is a potential source of mistake – especially more complex ones with counters and virtual outputs.

I changed all my glass breaks to interior burglar because a “cleaning tool” happened to accidently trip a glass break and police was dispatched. Getting the situation sorted out remotely was a pain. Glass breaks or wonderful housekeeper - guess which one lost?
 
Back
Top