Offline wireless locks - Revision history

Telcredstaff: /* Grant access initiated by the server */

2021-10-13T18:05:59Z

Grant access initiated by the server

← Older revision		Revision as of 18:05, 13 October 2021
Line 3:		Line 3:
	=== Grant access initiated by the server ===		=== Grant access initiated by the server ===

	A ''grant access'' command can be initiated by the server either through [[Telcred ~~Entry~~]], the Telcred API, or directly by the administrator from the [[Doors\|door page]]. The command will be received by the Axis controller and result in an ''Access granted'' event, reflecting the fact that this is the decision the controller made. However, as the wireless lock is offline, the lock will not actually unlock. When the lock comes back online, there is no "memory effect" and the door will remain locked until the next successful grant access request.		A ''grant access'' command can be initiated by the server either through an app (e.g. [[Telcred Personal]]), the Telcred API, or directly by the administrator from the [[Doors\|door page]]. The command will be received by the Axis controller and result in an ''Access granted'' event, reflecting the fact that this is the decision the controller made. However, as the wireless lock is offline, the lock will not actually unlock. When the lock comes back online, there is no "memory effect" and the door will remain locked until the next successful grant access request.

	=== Lock mode changes ===		=== Lock mode changes ===

Telcredstaff: /* Lock mode changes */

2020-09-07T09:51:03Z

Lock mode changes

← Older revision		Revision as of 09:51, 7 September 2020
Line 7:		Line 7:
	=== Lock mode changes ===		=== Lock mode changes ===

	A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page). If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change. But contrary to grant access, if the lock is offline the lock mode change will be ~~flagged as successful and~~ carried out as soon as the lock comes back online. In other words, there is a "memory effect".		A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page). If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change. But contrary to grant access, if the lock is offline the lock mode change will be carried out as soon as the lock comes back online. In other words, there is a "memory effect".

Telcredstaff: /* Lock mode changes */

2020-09-07T09:49:44Z

Lock mode changes

← Older revision		Revision as of 09:49, 7 September 2020
Line 7:		Line 7:
	=== Lock mode changes ===		=== Lock mode changes ===

	A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page). If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change. ~~Contrary~~ to ''grant access'', the ~~effect~~ on ~~the~~ ~~physical~~ lock is carried out ~~when~~ the lock comes back online. In other words, there is a "memory effect".		A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page). If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change. But contrary to grant access, if the lock is offline the lock mode change will be flagged as successful and carried out as soon as the lock comes back online. In other words, there is a "memory effect".

Telcredstaff: /* Lock mode changes */

2020-06-30T09:43:36Z

Lock mode changes

← Older revision		Revision as of 09:43, 30 June 2020
Line 7:		Line 7:
	=== Lock mode changes ===		=== Lock mode changes ===

	A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page). If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change. Contrary to ''grant ''access'', the effect ~~of lock mode changes~~ on the physical lock ~~state while a lock is offline is~~ is carried out when the lock comes back online. In other words, there is a "memory effect".		A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page). If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change. Contrary to ''grant access'', the effect on the physical lock is carried out when the lock comes back online. In other words, there is a "memory effect".

Telcredstaff: /* Lock mode changes */

2020-06-30T09:42:12Z

Lock mode changes

← Older revision		Revision as of 09:42, 30 June 2020
Line 7:		Line 7:
	=== Lock mode changes ===		=== Lock mode changes ===

	A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page). If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change.		A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page). If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change. Contrary to ''grant ''access'', the effect of lock mode changes on the physical lock state while a lock is offline is is carried out when the lock comes back online. In other words, there is a "memory effect".

Telcredstaff: /* Lock mode changes */

2020-06-30T09:40:22Z

Lock mode changes

← Older revision		Revision as of 09:40, 30 June 2020
Line 7:		Line 7:
	=== Lock mode changes ===		=== Lock mode changes ===

	A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page. If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change.		A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page). If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change.

Telcredstaff at 09:39, 30 June 2020

2020-06-30T09:39:59Z

← Older revision		Revision as of 09:39, 30 June 2020
Line 7:		Line 7:
	=== Lock mode changes ===		=== Lock mode changes ===

	A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page.		A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page. If the controller is online, the lock mode change will be flagged as successful and generate the corresponding event as well as ''lock state'' change.

Telcredstaff at 09:37, 30 June 2020

2020-06-30T09:37:56Z

← Older revision		Revision as of 09:37, 30 June 2020
Line 4:		Line 4:

	A ''grant access'' command can be initiated by the server either through [[Telcred Entry]], the Telcred API, or directly by the administrator from the [[Doors\|door page]]. The command will be received by the Axis controller and result in an ''Access granted'' event, reflecting the fact that this is the decision the controller made. However, as the wireless lock is offline, the lock will not actually unlock. When the lock comes back online, there is no "memory effect" and the door will remain locked until the next successful grant access request.		A ''grant access'' command can be initiated by the server either through [[Telcred Entry]], the Telcred API, or directly by the administrator from the [[Doors\|door page]]. The command will be received by the Axis controller and result in an ''Access granted'' event, reflecting the fact that this is the decision the controller made. However, as the wireless lock is offline, the lock will not actually unlock. When the lock comes back online, there is no "memory effect" and the door will remain locked until the next successful grant access request.

			=== Lock mode changes ===

			A ''lock mode'' change can be initiated either by the controller due to a schedule or by the administrator or API through an ''Override schedule'' action (for more information see the [[Doors]] page.

Telcredstaff at 09:32, 30 June 2020

2020-06-30T09:32:44Z

← Older revision		Revision as of 09:32, 30 June 2020
Line 1:		Line 1:
	When one or more wireless locks from SimonsVoss are connected to an Axis controller, there are some things to be aware of that apply to the situation where the controller is online but the wireless lock is not.		When one or more wireless locks from SimonsVoss are connected to an Axis controller, there are some things to be aware of that apply to the situation where the controller is online but the wireless lock is not.

			=== Grant access initiated by the server ===
⚫	* ''Grant access initiated by the server''. A ''grant access'' command can be initiated by the server either through [[Telcred Entry]], the Telcred API, or directly by the administrator from the [[Doors\|door page]]. ~~This~~ command will be received by the Axis controller and result in an ''Access granted'' event, reflecting the fact that this is the decision the controller made. However, as the wireless lock is offline, the ~~door~~ will not actually ~~open~~. When the lock comes back online, there is no "memory effect" and the door will remain locked until the next successful grant access request.

		⚫	A ''grant access'' command can be initiated by the server either through [[Telcred Entry]], the Telcred API, or directly by the administrator from the [[Doors\|door page]]. The command will be received by the Axis controller and result in an ''Access granted'' event, reflecting the fact that this is the decision the controller made. However, as the wireless lock is offline, the lock will not actually unlock. When the lock comes back online, there is no "memory effect" and the door will remain locked until the next successful grant access request.

Telcredstaff at 09:31, 30 June 2020

2020-06-30T09:31:14Z

← Older revision		Revision as of 09:31, 30 June 2020
Line 1:		Line 1:
	When one or more wireless locks from SimonsVoss are connected to an Axis controller, there are some things to be aware of that apply to the situation where the controller is online but the wireless lock is not.		When one or more wireless locks from SimonsVoss are connected to an Axis controller, there are some things to be aware of that apply to the situation where the controller is online but the wireless lock is not.

	* ''Grant access initiated by the server''. A ''grant access'' command can be initiated by the server either through [[Telcred Entry]], the Telcred API, or directly by the administrator.		* ''Grant access initiated by the server''. A ''grant access'' command can be initiated by the server either through [[Telcred Entry]], the Telcred API, or directly by the administrator from the [[Doors\|door page]]. This command will be received by the Axis controller and result in an ''Access granted'' event, reflecting the fact that this is the decision the controller made. However, as the wireless lock is offline, the door will not actually open. When the lock comes back online, there is no "memory effect" and the door will remain locked until the next successful grant access request.