Offline access

Created by Qiang Zheng, Modified on Mon, 12 Aug, 2024 at 11:59 AM by David OBrien

Please note that the information in this article is out of date and will be updated - if there are any questions please contact support@saltoks.com

Offline access or emergency code helps the lock grant the valid user access (The tag is included in the valid access group with the valid lock & valid time frame) when the lock is offline.

The RFnet locks supported up to 39 offline access or emergency Codes.

The first release of BLUEnet locks supports up to 360 offline acccss or emergency Codes.

If the KS site has at least 1 RF lock, then on site level, there will be 39 offline slots.

Currently, the offline access is managed at the site level, so if the user gets the offline access checked for his tag or mobile key, then the user will get offline access across the site.

When the offline access being enabled, the request will be forwarded to the IQ, therefore the lock, so the request will fail if the IQ or the lock went offline before the action. The service will try to sync that whenever the lock is online.

The offline access or emergency code will be saved in the lock memory till the new access synced from the IQ.

The People profile indicates if offline access is given for the tag or the mobile key.

Common question about the offline keys

Question: If you have a system with Bluenet locks ( 360 offline access ) and you add one RFnet with (39 offline access) what will happen all the rest offline access users and who is going to get the 39 offline accesses ?

Answer: The distribution of the 39 offline access on that particular case will be handled randomly from the system. This means the system will automatically remove the offline access from everyone and keep only 39 active for random users. This means, the site administrator should manually configure the access and disable/enable offline access to the desired users.

Offline access based on audit trail

It is configurable if, and if so how many days you allow the lock to look back in its audit log to check for an opening using the credential provided. The range that can be set varies from 1 day to 255 days, with some steps in between.
The amount of events that can be stored in the audit trail is limited and varies per lock type (see list below). Also non-opening related events are store in it, like time synchronisation and connection events, reducing the actual number of available lock openings even further. This means that for locks that have large amounts of openings per day, the number of events that can be stored will run out before the number of days to look back on is reached. This causes the issues with predictability.

Connection Type	Lock Type	Amount of Events in Audit Trail
RFNet	Cylinder	472
RFNet	Escutcheon	472
RFNet	CU (Wall Reader)	1732
BLUEnet	Any	1462

Offline Access decision flow in lock