POE Wireless Locks Reader
Purpose
This specification describes all aspects of design, development, testing and commissioning of the wireless locks into the BluSky environment.
Description of the presentation
From the customer point of view the underlying hardware should be completely transparent. It should not be any difference between managing the wired locks connected to Mercury or wired locks connected to Allegion or Assa Abloy hardware. It should be a clear distinction between wired and wireless (WiFi) locks on the screen.
There are two types of wireless locks.
a. Bluetooth connected locks are behaving similar to the wired locks. Commands sent to Bluetooth locks are executed in real time.
b. WiFi connected locks are not controllable in the real time, so when those locks are selected on a real time control screen all lock/unlock/release/put on schedule buttons must be disabled.
c. State controls of those WiFi locks should show the last status of the lock. Besides showing the last status of the wireless lock, the icons should indicate the critical messages that are coming from the locks (like low voltage, critical voltage, door forced, door held).
Hardware abstraction
For all wireless platforms from different manufacturers we need to identify existing BluSKY entities the hardware components can be mapped to. Depending on the hardware configuration, this mapping can change (for instance, the controller role can be assigned to a wireless lock itself or to a lock gateway if the latter one is present in the system)
We should create a list of settings common to all wireless lock platforms. And, for each manufacturer platform we need to identify a set of platform-specific settings. This also involves creation of additional configuration pages to manage these platform-specific settings
Similarly, for each platform we need to produce a list of all possible events generated by devices and add platform-specific events to BluSKY
Services
Services for wireless locks should communicate with the corresponding manufacturer services and also with BluSky.
Services must run in Azure or on the local servers. The code for both locations should be the same. The difference in the environment should be configurable in the initialization file. When running in BluSky,
the service connects to the BluSky database. When running on the local server the service connects to the local subset database.
Communication with BluSky should be standardized as much as possible. Essentially all the services should behave similar to windows hardware drivers, I.e. run in the background, be specific to the controlled hardware and look as much identical to BluSKY as possible.
Allegion
Allegion has several types of locks.
1. Bluetooth locks (LE/NDE/BE/FE) that are connected to the Allegion Gateway. They are real time controlled locks. Several actions are required to configure and commission those locks.
a. Lock discovery (made using Allegion Mobile app).
b. Lock linking (made by Allegion Mobile App). This action associates a lock with a particular gateway.
c. Lock configuration in BluSky.
2. Bluetooth locks (AD300/AD400) that are connected to PIM400 module. Those locks are controlled through the Mercury hardware and are not a part of this specification.
Communications between Allegion and BluSky.
BluSky Service (called Allegion Interface) communicates with Allegion Server to send commands, receive replies and transactions (unsolicited events). Commands are coming from BluSky through Service Bus messaging pipeline. Replies and transactions are sent back to BluSky through Service Bus messaging pipeline and also could be logged to the database.
Interaction between Allegion locks and BluSky.
Interaction between Allegion Locks and BluSky is happening on several levels.
a. Configuration.
Configuration pages for Allegion locks should have all general and specific settings needed to configure the locks in Allegion Server.
b. Synchronization.
Synchronization of settings can be automatic or manual depending on the setting that needs to be synchronized. As a general rule (also used in Mercury Synchronization) all the hardware
settings that are made by the integrator require manual synchronization. All the changes made by customers (Facility managers, tenants, etc.) are synchronized automatically.
c. Control.
Real control pages should be the same as control pages for other type of hardware. The only difference should be the states that are specific to the wireless locks. Those states include but not limited to “Low battery”, “Critical Battery”, “Cabinet tamper”.
Assa Abloy
Assa Abloy has several types of locks.
POE locks must be accessible from the computer that runs an Assa ABloy service called Door Service Router (DSR). They are real time controlled locks. Several actions are required to configure and commission those locks.
a. Lock configuration with Assa Abloy Lock Tool.
b. Lock configuration with BluSky pages.
WiFi locks must be accessible from computer that runs DSR. They cannot be controlled from Real time control screen. To conserve the battery they connect to the DSR only one or few times a day using configurable schedule. They also can connect between the scheduled intervals if one of alarms (for which the lock is configured to report) occurred. Example of those alarms are “Low voltage”, “Door forced”, “Door held”.
Communications between Assa Abloy and BluSky.
BluSky Service (called Assa Abloy Interface) communicates with DSR to send commands, receive replies and transactions (unsolicited events). Commands are coming from BluSky through Service Bus messaging pipeline. Replies and transactions are sent back to BluSky through Service Bus messaging pipeline and also could be logged to the database.
Interaction between Assa Abloy locks and BluSky.
Interaction between Assa ABloy Locks and BluSky is happening on several levels.
d. Configuration.
Configuration pages for Assa Abloy locks should have all general and specific settings needed to configure the locks in DSR.
e. Synchronization.
Synchronization of settings can be automatic or manual depending on the setting that needs to be synchronized. As a general rule (also used in Mercury Synchronization) all the hardware settings that are made by the integrator require manual synchronization. All the changes made by customers (Facility managers, tenants, etc.) are synchronized automatically.
f. Control.
Real control pages should be the same as control pages for other type of hardware. The only difference should be the states that are specific to the wireless locks. Those states include but not limited to “Low battery”, “Critical Battery”, “Cabinet tamper”.
Salto
Needs to be developed.
Diagnostics.
BluSKy needs to have diagnostics page for each Wireless platform. The diagnostics page must allow the following test:
1. Show (with filtering) the state of all hardware required to communicate with configured locks.
2. Show the state of all locks (online, lock/unlocked/door held, etc.).
3. Allow to release the locks.
4. Allow lock and unlock the locks.
5. Need to analyze the lock database. Report on how many users, schedules, access levels, etc.
6. Allow to synchronize users, schedules and access levels.
7. Allow to completely reset the lock database and sync it with BluSky.
8. Show all the commands going to the locks and locks network equipment.
9. Show the replies and any other messages that are coming from the locks.
10. Those replies should show the native codes coming from the wireless locks and their network equipment and also human readable description of those codes.