SmartIntego settings: Difference between revisions
Telcredstaff (talk | contribs) No edit summary |
Telcredstaff (talk | contribs) No edit summary |
||
| Line 16: | Line 16: | ||
If the privilege has been defined with this setting, the credential ID will be stored in the lock's own whitelist and the lock will make the access control decision. In contrast, for privileges of type ''Regular'', it is the controller that makes the access control decision. If the setting results in a situation where more than 250 card IDs should be written to the lock's whitelist, NO cards will be written to the whitelist. |
If the privilege has been defined with this setting, the credential ID will be stored in the lock's own whitelist and the lock will make the access control decision. In contrast, for privileges of type ''Regular'', it is the controller that makes the access control decision. If the setting results in a situation where more than 250 card IDs should be written to the lock's whitelist, NO cards will be written to the whitelist. |
||
By using privileges both with and without the ''Use whitelist when possible'' setting, it is possible to let ''some'' users have access by whitelist, and some not, to the same lock. This can be very useful in a situation with a large number of users, where you want to make sure that some of them always have access to the lock, even if e.g. the power is out. |
|||
Finally, unrestricted [[Keys]] always have the Use whitelist when possible setting set to Yes, while those with a restriction in time or doors have it set to No. |
|||
Revision as of 18:21, 4 November 2021
There are a few settings that are necessary in order for locks from SimonsVoss SmartIntego to work correctly. A few overall settings are found in the Organization Owner view and must match the programming of the SmartIntego locks (done with the SmartIntego software from SimonsVoss).
First, it is necessary to define whether the card ID is Mifare UID or data stored in the encrypted card memory. If the card ID comes from the card memory, it is also necessary to specify how long (how many bytes) the card ID is. This setting has to match both the physical cards and the programming of the SmartIntego locks. For example, if DESFire application is used, and the card ID stored on the cards is seven bytes, this settings should be ' 7 '.
In the Organization Owner view it is also possible to define whether to enable whitelist, where up to 250 card identities can be stored in the lock itself. In most cases you want to set this to ' Yes ', but in some special cases you may not want door controllers to try to write to the lock whitelist. In this case it is possible to prevent this for all controllers and locks in the organization by setting ' Enable whitelist ' to ' No '.
Enabling whitelist on organization level is not enough for card IDs to actually end up in the whitelist of one or more locks. For this to happen, it is necessary to define a privilege with the setting Use whitelist when possible.
If the privilege has been defined with this setting, the credential ID will be stored in the lock's own whitelist and the lock will make the access control decision. In contrast, for privileges of type Regular, it is the controller that makes the access control decision. If the setting results in a situation where more than 250 card IDs should be written to the lock's whitelist, NO cards will be written to the whitelist.
By using privileges both with and without the Use whitelist when possible setting, it is possible to let some users have access by whitelist, and some not, to the same lock. This can be very useful in a situation with a large number of users, where you want to make sure that some of them always have access to the lock, even if e.g. the power is out.
Finally, unrestricted Keys always have the Use whitelist when possible setting set to Yes, while those with a restriction in time or doors have it set to No.