1.0 Introduction

From Doors.NET v5.2.0 and onwards, there is a slight difference in setting up a Gateway Node for wireless lock integration. Prior to v5.2.0, a gateway node would be added to a controller bus. From v5.2.0 and onwards, the gateway node is added to the hardware tree as a Network Device. This change improves the setup workflow of wireless lock integration with NXT-MSC and Mercury controllers. Although a controller is still required for the integration, this change also allows for all of the controller buses to be used for general access control.

2.0 Summary of the Main Hardware Browser Changes:

• New object (ControllerPort) displayed when selecting a RS-485 or network node. Based on controller type, this will display the available serial or network protocols that each controller supports. License check is made when hardware is added.
  
  

• MSC hardware - downstream hardware is under each TB node instead of directly off the controller entry. This is now consistent with how the hardware is displayed for NXT and NXT-MSC in 5.1. TB names change to reflect the actual name on the MSC controller.
  
  

• Baud rate for downstream devices - 5.1 had the baud rate setting at the controller, which applied to all ports. 5.2 now ignores that setting (it is hidden) and uses the baud rate setting for each TB/Bus port. Each port can have a different baud rate setting (to downstream devices).
  
  

• Ribbon bar icons - 5.2 now displays the icons relative to the protocol on the bus versus5.1 displaying all icons, then setting each icon disabled that was not supported based on license and/or items present on the bus resulting in a much cleaner look. In addition, the license check moved to when the user tries to add the hardware with the message to the user more descriptive than just showing a disabled icon.
  
  
• MSC Hardware - will display Add ACR for second OSDP reader or adding a normal reader back when selecting a panel object.
  
  
• Network Devices (i.e wireless lock hubs) are Grouped under their own node instead of attached directly to the controller or to a Bus.

3.0 Hardware Tree Example

The figure below shows TB3 and TB4 for a LP2500:

1. Select one of the RS-485 ports (for example, TB3).
2. Selecting TB3 will display the properties of the protocol on the right.
   
   
   
   
3. In the above image, the protocol is Schlage RSI with the baud rate fixed at 9600 bps.

4. This protocol supports the AD-300, PIM, and ENGAGE products from Schlage (Allegion).

5. Therefore, when selecting TB3 or TB4 the ribbon bar icons will reflect which devices can be added.
   
   
   
   
6. It is possible for TB3 and TB4 to use different protocols. TB3 can be configured for Schlage RSI and TB4 can be configured for Mercury. When Mercury is selected, the following options will be available for an LP2500 controller.
   
   
   
   Note: The ribbon bar for Mercury also displays the Aperio AH-30. This is because the AH-30 uses Mercury firmware and it communicates using the Mercury Security
   RS-485 protocol.
   

4.0 Expanded Views of the LP2500 Controller

5.0 Serial Port Protocol

The serial port protocol does change based on the controller type.

LP and EP controllers will show the following options (default is Mercury Security) :

Note: LP and EP controllers do not support Keri Systems protocol.

6.0 Network Port Protocol

Each NXT-MSC, EP and LP controllers will have a Network Devices node added by default.

Selecting that node will allow the user to add a network protocol:

Clicking Add Network Protocol will add a undefined node:

Select the Undefined node to change the network protocol. Each controller type supports a different selection.

6.1 NXT-MSC Network Protocol

Keri NXT-MSC controllers only support the SimonVoss network protocol. This is the same as Doors.NET v5.1.0, however v5.1.0 used a Bus for each SimonsVoss Gateway node.

Here is the network protocol selection for NXT-MSC:

6.2 MSC EP Controllers Network Protocol

MSC EP controllers support Mercury Security (MR51e) and SimonsVoss:

6.3 MSC LP Controller Network Protocol

MSC LP controllers support Mercury Security (mr62e), SimonsVoss, and Aperio (AH40):

Each controller can support multiple network protocols simultaneously. For example, the LP controller could have all 3 protocols added and support mr62e, SimonVoss, and AH40 at the same time. The total number of panels (32) is still enforced at the controller level. This means that any mix of serial/network devices cannot exceed the 32 panel limit. The maximum number of readers is still 64 across all panels (network and/or serial) with the reader number being calculated on the fly as devices are added.

7.0 Ribbon Bar Changes

The ribbon bar has been cleaned up, some icons were replaced/touched up, and licensing moved to the button click instead of disable/enable the button. Selecting a Bus/TB or network node will now only display the icons relative to the protocol defined for that port. 5.1 showed all the icons based on the license with some icons disabled depending on which node was selected. 5.2 does show some icons that change based on node selection (Wi-Q and SimonsVoss) but most are enabled when shown. Examples are shown below:

NXT-MSC controller Bus 1 with Keri Protocol:

7.1 NXT-MSC controller Bus 1 with Keri Protocol:

7.2 NXT-MSC Controller Bus 2 with Mercury Security Protocol