SmartIntego settings: Difference between revisions

From Telcred documentation
Jump to navigation Jump to search
No edit summary
No edit summary
Line 9: Line 9:
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 '.
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 [[Privileges|privilege]] with the setting ''Use whitelist when possible''.
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 [[Privileges|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. 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 type, the credential ID will be stored in the lock's own whitelist. In contrast, for privileges of type ''Regular'', it is the controller that makes the access control decision.

Revision as of 18:11, 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).


SmartIntego settings


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. 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.