Generic Wiegand system forced open issue.

[jrothwell 0]

I have a generic Wiegand access control system setup as follows:

 

One door example:

-Card reader outside the door

-Door contact sensor

-Request to exit button inside the door

-Electronic strike

 

The issue is as follows:

 

-User A leaves in the morning via the request to exit button.

-User B leaves in the morning about an hour later via the request to exit button.

-User A comes back in the evening and enters via the card reader. No alarm sounds.

-User B comes back in the evening a couple hours later and enters via the card reader. He is granted access, opens the door and the forced open alarm sounds.

 

When I check the logs or monitor the system activity in real-time, everything looks as it should. The user is granted access by the system (after swiping card) and then the door contact shows that the door is open after that. Then it shows a forced open alarm.

 

To test, if User A inside the door activates the request to exit button, after entering, opens the door then closes it but does not leave, when User B tries to enter, there is no alarm.

 

Any feedback or other testing I can do would be appreciated. Thank you.

[jeromephone 6]

In the software does it have an anti passback setting? If you had that activated for user b it could show an alarm as the system is looking for a card swipe outbound as well as inbound. Just something to look at.

[jrothwell 0]

Thanks for your reply. The system does have the anti-passback feature and I have confirmed that is has not been enabled. To test, I enabled it and it resulted in a denial of entry (would not unlock the door) but did not set off the forced open alarm. I know there are some systems that have "hard" and "soft" anti-passback, but this one only has the option to enable or disable.

[ssmith10pn 0]

Is it relocking on time or door contact?

[jrothwell 0]

Time

[avolobuev 0]

What kind of strike? Door contact integrated?

Is A a stronger man than B?

Is the REX set to unlock the door?

Door contact jitter?

Does "Generic" means "no name"?

[jrothwell 0]

-The electronic strike is fail secure.

-The door contact is not integrated with the strike. It's a standard contact mounted near the top of the door.

-Both users are about the same strength. When testing, it didn't matter which user left or come back first, the results were the same.

-The request to exit button does unlock the door from the inside.

-I'm not sure what you mean by door contact jitter, please specify.

-Yes, generic means no name.

 

thank you!

[avolobuev 0]

-The electronic strike is fail secure.

-The door contact is not integrated with the strike. It's a standard contact mounted near the top of the door.

-Both users are about the same strength. When testing, it didn't matter which user left or come back first, the results were the same.

-The request to exit button does unlock the door from the inside.

-I'm not sure what you mean by door contact jitter, please specify.

-Yes, generic means no name.

 

thank you!

 

 

Easy.

Provided that both users do close the door behind them, the door is not possible to open before card releases the strike, both open the door with about the same strength and speed, the issue is strictly inside the "no name" software.

 

Otherwise I would suspect that door contact produces 2 or more changes of status during door opening, or jitter, first one being masked by the software while next ones are not - again, software fault. When set to fire on duration, door contact should be masked for that entire time.

 

Maybe it is worth getting a trusted name access control software...

[ssmith10pn 0]

Short the door contact together and call it a day.

[jrothwell 0]

-The electronic strike is fail secure.

-The door contact is not integrated with the strike. It's a standard contact mounted near the top of the door.

-Both users are about the same strength. When testing, it didn't matter which user left or come back first, the results were the same.

-The request to exit button does unlock the door from the inside.

-I'm not sure what you mean by door contact jitter, please specify.

-Yes, generic means no name.

 

thank you!

 

 

Easy.

Provided that both users do close the door behind them, the door is not possible to open before card releases the strike, both open the door with about the same strength and speed, the issue is strictly inside the "no name" software.

 

Otherwise I would suspect that door contact produces 2 or more changes of status during door opening, or jitter, first one being masked by the software while next ones are not - again, software fault. When set to fire on duration, door contact should be masked for that entire time.

 

Maybe it is worth getting a trusted name access control software...

 

Thanks. The alarm I'm talking about is an audible alarm that's connected to the alarm output on the system board, it's independent of the software. I tested the door contacts and they seem to be sending just one open/close signal.

 

Could you elaborate on "...fire on duration...masked entire time"?

 

Thanks again

[ssmith10pn 0]

The alarm I'm talking about is an audible alarm that's connected to the alarm output on the system board, it's independent of the software.

 

It's still controlled by the software.

[avolobuev 0]

 

Thanks. The alarm I'm talking about is an audible alarm that's connected to the alarm output on the system board, it's independent of the software. I tested the door contacts and they seem to be sending just one open/close signal.

 

Could you elaborate on "...fire on duration...masked entire time"?

 

Thanks again

 

Sure. Most software can be configured to fire a lock output 3 ways:

1. On duration. So, ones valid card read is recognized, output is energized for a certain amount of time. Usually, 5 seconds for door and 1 second for gate control. In good systems, while output is activated, door alarms are shunted, since door is expected to be opened, but software continues to look at door contact status to know that granted entry was actually used or if door remained shut. Some basic soft simply ignores door contact status during this time.

2. On door open. Software detects that door has been opened and re-locks the door as soon as it detects that door contact changed state. Useful to shorten the actual time lock is open to help prevent tailgating, when someone has passed through, door had closed, but lock is still engaged. Works best with maglocks.

3. On door closed. Software detects that door has been opened, and re-locks the door as soon as the door had returned to closed position.

 

In all of the above cases there should be no door forced alarms while the door is legitimately open.

 

On some systems there is a separate setting for alarm shunt time (not to be mistaken with door held alarm time)

 

As far as jitter, in some cases you won't be able to see it without an oscilloscope. Some systems allow you to enter debounce settings, typically in 1/10 secon increments. This is very important for setups 2 and 3, but should be irrelevant for 1, since it is covered by default firing time.

 

Hope it helps,

 

Alex