Elk-M1KAM door modules randomly fail. Elk rules not carried out.

[tckeiter]

We have an Elk-M1 gold installed with 15 Elk-M1kam door modules. They control various access doors and gates throughout the property. There is a series of rules which unlocks 3 doors Monday - Friday for about 10 hours each. This rule works without issue 95% of the time. Every other month or so, the doors will lock mid day for no apparent reason. All of the 3 doors lock simultaneously not carrying out the remainder of time for the rules set. These are the only doors running a timed rule throughout the day. The rest of the doors respond to a reader swipe which unlocks corresponding door for 5 secs. When the issue occurs and these 3 doors lock off schedule, the doors still respond to the card swipes (5 sec rule) immediately after they have locked. I have confirmed that the rules do in fact fire properly each morning as well.
 
I originally thought this was a power issue and the modules may loose power briefly which results in the relay flipping thus locking the doors. I have checked the amp drawl in the system and it is below .5 amps for the M1 itself. I have an auxiliary power supply installed (Elk P1215K rated at 1.5 amps) that powers the rest of the devices. Elk calculator totals the amp draw on this aux supply to .81 amps. It has the 15 door modules, 1 M1KP2 keypad and 1 M1XIN wired input expander on it. Both Elk m1 main power supply and aux power have battery backups.
 
I must admit that I am baffled with this one. If it is not a power issue, could it be something else in the Elk system that may cause these doors to jump off schedule? There is nothing in the logs that shows these door modules starting up or that power was lost when the issue occurrs. I was hoping someone with more expertise could point me in a direction to resolve this issue. Any help would be appreciated since the tenants get very upset when this happens.
 
Thank you!

 

[mikefamig]

The first thing that comes to my mind is a wiring problem but do you think that maybe it could be a malfunction of the card reader? It is going to be very hard to troubleshoot being that it only happens once a month or so.
 
I would first check all of the wiring splices starting with the outside wires.
 
Mike.

 

[Del91574]

How does the rule unlock on schedule? Phantom output? conditional?

 

[tckeiter]

The rule just triggers 3 different outputs to open for 10 hours Monday - Friday. We have never seen the rule not trigger since the random locking only happens midday and the doors were open prior to the failure. We try to check the doors by swiping them immediately after it is reported and the door modules always respond to the card read and unlock. The failure must happen quickly but just long enough to flip the relay back to the close position on each module. It didn't use to happen the first 3 or 4 years it was installed. Are there more detailed logs somewhere besides what can be found inside ElkRP?

 

[mikefamig]

Are the phantom outputs that control the locks on the M1 panel or an output expander? What powers the outputs, the panel or the p215K? And how are the locks powered?
 
I'm thinking that maybe the backup battery and it's periodic voltage check and charging may have to do with it. How old are your backup battery/batteries?
 
Mike.

 

[tckeiter]

The outputs are triggered from the m1 panel which then triggers the relay on each door module. No output expander connected to the system. I assume then that the outputs are powered by the panel but each door module is on the P215K. The P215K is brand new with new battery. I moved all the data bus stuff over to it as a troubleshooting step because I thought the panel may have been overdrawn occasionally resulting in the door modules to drop current past what is needed to keep the relay energized. Unfortunately, this didn't fix the issue. The locks are all on their own 12 volt power supply separate from the Elk. Elk m1 backup batteries were replaced in August 2016. Thanks

 

[mikefamig]

What is unique to these three doors?  You mentioned rules. Are the rules the same for all doors or just these? If rules are the only thing common to these three doors then I would try sending all to the panel from the RP database. It can't hurt as long as nothing has been changed lately.
 
Mike.

 

[mikefamig]

Have you connected with ElkRP to check for differences between the DB and the panel?

 

[tckeiter]

What is unique to these 3 doors is that they run off a timed rule. None of the other doors on the system have a rule to keep them open during business hours because they are not common doors. The rule is triggered Monday - Friday at 8:00 am and output stays on for 10 hours. This part works flawlessly. The rule is triggered every time and all doors unlock. It is the once every month or 2 months that the rule triggers fine in the morning. Doors remain open most of the day and then all just lock not carrying out the full 10 hour period. The DB between the panel and M1XEP shows no differences between the two. It is indeed difficult to troubleshoot and that's why I'm on the forum to see if I might be missing something because I'm out of ideas. I was hoping there was some deeper logging in the system that could point me towards the root cause. 

 

[RAL]

If I understand things correctly, I think you've told us:
 
1.  When the problem occurs. all 3 door locks re-lock simultaneously.
2.  The locks themselves have their own power, but the M1KAMs are powered from the P1215K.   But previously, when the problem started, the M1KAMs were powered by the M1.
 
Question: Is the NEG terminal of the P1215K connected back to the NEG terminal on the M1 to provide a common signal ground reference.
 
If the problem occurred when the M1KAMs were on the M1's power, and still occurs with the P1215K power, then that makes me think it is probably not a power problem.  Unless there is a problem with the power cable to the M1KAMs that occasionally shorts or goes open, causing them to drop power briefly.  If the interruption was brief, the M1 might not notice the loss of communication on the data bus.
 
If it's not a power problem, since each M1KAM has its own data bus address, and the output that controls the relay is part of each M1KAM, it would require 3 separate data bus commands to lock all 3 doors.  It seems unlikely that a data bus glitch of some sort would cause all 3 doors to lock at the same time.
 
So that points back to some sort of problem with the execution of the rules.   
 
You could try adding rules that test for when the M1KAM outputs turn off during the 10 hour workday, and then send you an e-mail message to notify you.  That might give you a better picture of exactly when it happens, and maybe knowing the time will allow you to connect it with some other event.  And if the doors lock without the notification happening, then that would tell you that the M1 isn't aware that the output was turned off.
 
Has this problem always been present, or had things been running fine for a long time before it started happening?

 

[Del91574]

I'd change the operation from a timed event to having the KAM look at a phantom output. Best guess is you're having a hiccup on the bus and the output is dropping and the system is only sending the timed event once when disarmed, so the KAM's drop out and then they won't re-energize the relay unlocking the door.....
 
Try re-writing your rules to drive a phantom output then having the system look at the state of the phantom output for a longer window, instead of once and for the timed event.
 
I had a similar issue when driving KAM's on a schedule with conditionals based on time of day, and if disarmed/access outside of the initial window, the "schedule" didn't fire, but the access did.

 

[tckeiter]

Yes, the P1215K and M1's negative terminals are connected and yes the problem occurred in the same manner whether being powered by the M1 directly or the newer P215K. No, it did not always happen. It has only been the last 1 1/2 years or so but it was installed about 4 years ago. I agree that it seems highly unlikely for a databus glitch to close outputs on 3 devices simultaneously. That's why I always keep going back to a power issue.
 
I wrote some rules to monitor the closing of each problem door's output during their unlock period. Thank you for this suggestion. I should be able to at least now if the Elk knows the output is closing or if is is happening under the radar.
 
I'm also interested in re-writing the rules to drive a phantom output. I didn't think there was any other way to keep a door open besides a timed rule. Currently my rule looks like this...
 
Whenever the time is 7:00 AM
 And the days of the week is/are -MTWTF-
 Then turn output 202 on for 10 hours
 Then turn output 200 on for 10 hours
 Then turn output 206 on for 10 hours
 
How would I re-write this rule using a phantom output?
 
Thank you for all your input everyone! It is much appreciated.

 

[mikefamig]

I think that what del is suggesting is to check each of the outputs periodically and if it is between 7am and 5pm and the output is off then turn it on or visa/versa. You might check every ten minutes or maybe even every ten seconds, whatever you are comfortable  with. This would be one way to protect yourself from glitches in the system.
 
Mike.

 

[tckeiter]

Oh ok... So instead of doing a timed rule break it into 3 rules. 1)Tell the outputs to turn on in the morning at set time mon - Fri. 2) Write a rule that checks every minute or so if those outputs are on and if not turn them on 3) Turn off the outputs at set time at end of day. It may take more rules than 3 actually but I see what you are suggesting. Given how infrequent this happens, this is a great solution for us as long as the output actually reports being off when the failure occurs.
 
I'm going to re-write the rules and see what happens.
 
Thank you Mike, Del and Ral for all your assistance! Only time will tell on this one...
 
Tom

 

[mikefamig]

Oh ok... So instead of doing a timed rule break it into 3 rules. 1)Tell the outputs to turn on in the morning at set time mon - Fri. 2) Write a rule that checks every minute or so if those outputs are on and if not turn them on 3) Turn off the outputs at set time at end of day. It may take more rules than 3 actually but I see what you are suggesting. Given how infrequent this happens, this is a great solution for us as long as the output actually reports being off when the failure occurs.
 
I'm going to re-write the rules and see what happens.
 
Thank you Mike, Del and Ral for all your assistance! Only time will tell on this one...
 
Tom

 
You don't need the first  rule to turn it on if you start checking the output's condition at 7am it will turn it on at 7am and then just continue monitoring it all day until 5pm. Then you will need a rule to turn it off at 5pm and maybe check it a
ll night to make sure that it stays locked again until 7am.
 
I would use a rule that checks
WHENEVER "every X minutes"
time is "later than 7am"
and time is "earlier than 5pm"
and "output not on" 
then turn it on for the daytime
 
and just the opposite for the night time rule.
 
That is what I am thinking but RAL and DEL may have more to offer. They are who I go to when I'm stuck.
 
Mike.
 
EDIT - You don't really start checking at 7am as I mis-spoke above, it would check every "X" minutes around the clock.