ONITY

PMS Communications Protocol

Hotel Lock Systems

HT22
HT24W
HT28 Smart

May 24, 2005

Document Version 7.1

2005 Onity
This manual covers the Property Management System interface to the Onity Hotel Lock System
HT22, HT24W, and HT28 Smart. The protocol is the same for all 3 systems except as noted in
the document.
 TABLE OF CONTENTS

DESIGNING AN ONITY LOCK SYSTEM PMS INTERFACE ...........................................................................1

PRODUCTS COVERED BY THIS MANUAL.......................................................................................................................1
DESIGN REQUIREMENTS .............................................................................................................................................1
FUNCTION DESCRIPTIONS ...........................................................................................................................................3
Check in a new Guest [CN]...................................................................................................................................3
Copy a guest card [CC] .........................................................................................................................................3
Check in a new Guest with X copies [CNx] ..........................................................................................................3
Make X copies of a Guest card [CCx] ...................................................................................................................3
Check out a guest [CO] .........................................................................................................................................4
Make a One Shot Card [CA] .................................................................................................................................4
Read a card [LT]....................................................................................................................................................4
Track one Data [P1]...............................................................................................................................................4
Track two Data [P2] ..............................................................................................................................................4
Track three Data [P3] ............................................................................................................................................5
Read tracks 1 - 3 [L1 - L3] ....................................................................................................................................5
Authorizations 1 - 8 [Fields 7& 8].........................................................................................................................5
Multiple room key card [fields 4, 5 & 6]...............................................................................................................5
Some common mistakes made in the past: ............................................................................................................5
COMMUNICATIONS PROTOCOL: PMS TO ONITY HT24 ..............................................................................7
BASIC PMS INTERFACE NETWORK .............................................................................................................................8
SERIAL PORT CHARACTERISTICS ................................................................................................................................8
WIRING ......................................................................................................................................................................8
PMS Interface over Ethernet Connection (HT24W and HT28 Only) ...................................................................8
Sockets...................................................................................................................................................................9
COMMUNICATIONS ENVELOPE .................................................................................................................................10
DESCRIPTION OF THE MESSAGE ................................................................................................................................12
Commands ...........................................................................................................................................................13
Parameters of Commands ....................................................................................................................................15
ERROR MESSAGES ....................................................................................................................................................33
COLLECTING EVENTS FROM PERIPHERALS ...............................................................................................................35
Parameters of the Commands WF, WN and WR ................................................................................................35
Response to the Commands WF, WN and WR...................................................................................................35
Error Messages ....................................................................................................................................................37
Using the WF, WN and WR Commands.............................................................................................................38
PRE-CALCULATED DATA FORMATS FOR TRACKS 1 AND 2 ........................................................................................40
CERTIFICATION ....................................................................................................................................................41

ADDENDUM 1 : ENCODING ONITY KEYS ON A 3RD PARTY ENCODER ..................................................42

READING OF ONITY CARDS USING A 3RD PARTY ENCODER.........................................................................43
RETURNING ONITY EQUIPMENT .....................................................................................................................45
 DESIGNING AN ONITY LOCK SYSTEM PMS INTERFACE

PRODUCTS COVERED BY THIS MANUAL

This specification applies to all software versions of the Onity HT24 & HT28 PC based hotel
locking system, as well as the HT22 system which does not use a PC. Where there are
differences between versions it is so noted in this document.

DESIGN REQUIREMENTS

This document will explain the design philosophy of the Onity lock interface and provide
technical details for each of the supported functions.

Before you begin some basic issues must be discussed.

1. The Onity interface is a two-way interface. If your system cannot support a two-way interface
then contact Onity to discuss the options. The two-way communication is essential because
of error messages that may be generated by the Onity system. For example, if a keycard is
defective, the operator needs to know this information before the bad card is handed to a
guest. The Onity interface passes error codes to the PMS software that can be decoded and
displayed to the operator on the PMS screen. A second example is one where the front desk
operator reads a key card to determine its validity. When a card is read the Onity system
passes the information back to the PMS for display on the PMS screen. Any interface not
supporting error messages will cause problems for the property staff. For example, in a PMS
interface that does not support error handling, inter-PC errors such as Syntax errors will not
be reported to the operator.

© 2005 Onity 1
 2. Four basic functions should be included in the interface as a minimum. The 4 basic functions
are:

A. Check in a new guest with x keys encoded at time of check in. It is not advisable to
allow x to equal any number of guests in the room. A better solution is to pop up a
window and allow the operator to fill in a quantity of keys required. If your hotel
customers have suites which are configured as adjoining rooms, you must issue a
command which encodes more than one room on a key. There is a maximum of three
rooms for the manual encoders and four rooms for the motorized encoders. Your
software should be field configurable since the encoder may change.

B. Provide a copy of a key to a guest who is already checked in. One approach might be
to view the guest registration, pop up a "key services" window, and issue the number
of copies required. If your hotel customers have suites which are configured as
adjoining rooms, you must issue a command which encodes more than one room on a
key. There is a maximum of three rooms for the manual encoders and four rooms for
the motorized encoders. Your software should be field configurable since the encoder
may change.

C. Read a key. A key may be rejected by a door lock for a variety of reasons. The front
desk can determine the reason by reading the valid data on the card.

D. One Shot Key. This is admittedly a lower priority than the first three but may be
important to your customer, especially if it is a resort. A one shot key opens a door
one time only. It is commonly used by a potential guest to preview a room before
renting it. Default the expiration time to the checkout hour of the next day.

3. We strongly encourage you to implement the authorizations especially in resort or full service
hotels. This function allows the hotel to allow access to areas of the hotel for certain guests,
and to collect additional revenue. See the relevant section for more details.

© 2005 Onity 2
 FUNCTION DESCRIPTIONS

CHECK IN A NEW GUEST [CN]

This is the most basic function of the key system. When you issue a CN command to our
terminal, with the required parameters, our system instructs the encoder to encode a key card
with the requested room number, date of expiration, optional authorizations, as well as any
information specific to tracks one and two. Although this command is available and backward
compatible with previous versions, it is obsolete in HT24 versions 5.X and later. IMPORTANT
- every time a NEW card is made for a given room with this function, the new card will lock out
the previous card. If a guest requires TWO or more key cards, you must issue a single CN
command and then enough CC (see below) commands to create the number of extra key cards
required.

COPY A GUEST CARD [CC]

This command creates a copy of the current guest card. It must NEVER be used to issue the first
key to a NEW guest. Such an error would result in the previous guest having access to a room
occupied by a new guest.

CHECK IN A NEW GUEST WITH X COPIES [CNX]

This is a function that is available only in the HT24 version 5.X and later versions of the
interface software. Several cards for the same room can be issued by one packet from the PMS.
This single command eliminates the need to send two packets to the Onity terminal. If x is four
then the encoder expects the user to encode one new card along with three copies. x can be a
value between one and nine.
This command is NOT compatible with the virtual encoder (encoder zero).

MAKE X COPIES OF A GUEST CARD [CCX]

Again, this is a function that is available only in the HT24/28 version 5.X and later versions of
the interface software. From one to nine copies can be made of an existing, valid key card.
Several copies of a valid key card for the same room can be issued by one packet from the PMS.
This single command supersedes the CC command from earlier versions. If x is two then the
encoder expects the user to encode two copies.
This command is NOT compatible with the virtual encoder (encoder zero).

© 2005 Onity 3
 CHECK OUT A GUEST [CO]

In our system, this command will cause an active card to cease working in any locks or devices
hard wired to our front desk equipment. Guest cards continue to work in the guest room lock
until either A) a new guest inserts his card in the lock, or B) the active card expires.

MAKE A ONE SHOT CARD [CA]

This card works in a specific guest room door lock one time only. The Onity systems can only
issue four one-shot cards per new guest card. The system will return the error code of 'EA', if
you exceed this limit.

READ A CARD [LT]

This command enables a staff member to see the information encoded on a key. This
information may help the staff member determine the reason why a key card will not work in a
guest door lock, as various fields are displayed.

TRACK ONE DATA [P1]

This command will allow encoding of properly formatted alphanumeric information on track
one. A minimum of three parameters are required for this function, A) the number of the
encoder that will encode the data, B) should the card be ejected upon completion or retained for
track two encoding and C) Point of sale (POS) application specific message. The POS data must
follow the ISO convention for character usage.

TRACK TWO DATA [P2]

Essentially the same as the P1 command except that the information encodes on track two and
can only be numeric.

© 2005 Onity 4
 TRACK THREE DATA [P3]

Onity uses this track for proprietary information. Do not use the P3 command.

READ TRACKS 1 - 3 [L1 - L3]

Interpret and display the ISO formatted information encoded on selected track. Do not use the
L3 command.

AUTHORIZATIONS 1 - 8 [FIELDS 7& 8]

Authorizations are guest service areas that a card has permission to enter. These change for each
property, so a user definable file that establishes the title for each authorization would be useful.
When Onity sets up a property with Authorizations, a brief description that corresponds to an
authorization number is linked together. For example, the demo version you received from
Onity has Authorization one as the spa, two as the swimming pool and three as the safe. This
section of this document contains examples that explain Authorization data formats that will
allow guest access to other parts of the facility besides their guest rooms. Some hotels will want
the flexibility to automatically issue authorizations and some will want to ask the guest whether
or not they would like this amenity at the time of check in. The PMS software should be able to
accommodate both situations.

MULTIPLE ROOM KEY CARD [FIELDS 4, 5 & 6]

These fields allow up to three rooms besides the primary room to be encoded on a single key
card. An example of use may be a parent in one room and children in another. With this key
card the parent has access to both rooms. This must be configurable at the property level to
support either three or four room numbers, as the property may request different types of
encoding equipment.

SOME COMMON MISTAKES MADE IN THE PAST:

1. Programmer not observing the European date format.

2. Issuing a NEW key as the second key when two keys are required.
3. The operator’s name or system login MUST be used for parameter eleven. This is a popular
request by the property staff.

© 2005 Onity 5
 4. Note that all error messages are very important because they can indicate a defective or
improperly inserted key card. This may also produce a warning of an encoder that has not
completed a task.
5. Make sure that the PMS terminals identify the encoder they wish to use as #02, #03, #04, etc.
This should be an on-site definable file. Allow two terminals to send the same identification
in case the property wishes to share an encoder between two terminals. This condition makes
use of the OV error message which is very important since one terminal may not have
completed a task before the second terminal sends a request. Good design would dictate that
you continuously try the request several times and beep the respective terminal each time you
try. Please reserve encoder #01 for the local encoder.
6. Spooling key issuing requests from multiple terminals requires the PMS system to watch for
an acknowledgment for each request sent prior to sending subsequent requests. The PMS
system should only hold requests from different terminals until the current message is
acknowledged, not until the operation is completed. The Onity system will handle individual
requests from multiple stations, return acknowledgments of proper message packets for each,
and also return a completion message to the PMS system when the operator has completed the
task. This is not handled as first in/first out; rather, Onity takes each of the messages,
processes them and waits for the operator to complete the task, then returns the appropriate
completion message to the PMS system. If the commands are not released until completion, a
staff member might become preoccupied with a guest and other staff key card requests would
appear to be ignored. During a busy check-in, these users assume that the system is broken
because they are not receiving a response in a timely manner. By requests from different
terminals, staff members can work at their own pace, and all of the customer’s needs may be
satisfied. The PMS system should keep track of which terminals have transactions pending,
and watch for the response that corresponds to that terminal. Multiple requests from the same
terminal should not be allowed until the previous transaction is complete. If two terminals are
sharing an encoding device, then the second command should be held until the first operation
is completed. It would be helpful to the operator if a message could appear on the second
terminal indicating that the encoder is in use by another station.
7. When testing your system, make sure that the expiration date and time is at a point in time
later than the current system time. The Onity system will reject messages with an expiration
date that is earlier than the current system date with a Syntax error. Similarly, if you include
an activation date and time, you must include an expiration date and time, or you will receive
a syntax error.

Please keep this information CONFIDENTIAL. It is for your use only and is not to be
duplicated or distributed outside of your company.

© 2005 Onity 6
 COMMUNICATIONS PROTOCOL: PMS TO ONITY HT24

The property management system (PMS) handles various specific hotel tasks (invoices, hotel
bookings, etc.). Small modifications in its program will be sufficient to allow the encoding of
guest room cards (new ones or copies) or canceling of cards. (check-out). A more extensive
modification will allow the hotel to perform a much wider variety of operations.

The PMS needs to communicate via RS-232 with the Onity-HT24 system computer. The same is
true for the HT22 non-PC based equipment.

Each PMS terminal that needs to be able to encode cards must have an encoder located next to it.
It is possible to share an encoder with more than one PMS terminal but it is not recommended.

The HT24 system computer is a PC compatible running MS-DOS (minimum v. 5.0) and two RS-
232 serial ports; one to communicate with the PMS and the other one for communications with
the Onity proprietary HTCOM RS485 network for the encoders.

The Onity-HT24 computer has two main functions:

1. To run as an interface between the PMS and the Peripherals of the HT24 system (card
encoders, on-line locks, etc.).

2. To execute the Onity HT24 program for complicated but less frequent tasks such as
encoding master cards, observing the register of openings, configuration or
maintenance work on the Onity HT24 system, etc.

The encoders have to be declared and addressed in the Onity-HT24 software (address 1 to 50
maximum for version prior to 5.X and 1 to 100 for 5.X and later). The HT24 program only
communicates directly with encoder #1 (address 1).

The HT22 system is a self contained unit that does not require a PC. Eight units can be
connected to provide multiple workstations for the hotel. Like the HT24, it connects to the PMS
via a serial connection. It manages the other encoders via the Onity HTCOM RS485 network.

© 2005 Onity 7
 BASIC PMS INTERFACE NETWORK

SERIAL PORT CHARACTERISTICS

The communication PMS-PC interface goes through an RS-232 serial port having the following
configuration: (see section on PMS Interface over Ethernet Connection on page Error!
Bookmark not defined.)

- 8 bits characters (ASCII)

- full-duplex
- 1 start-bit
- 2 stop-bits
- no parity
- 1200, 2400, 4800, 9600 or 19200 baud

All characters going through this serial port are ASCII characters. The communication PMS-PC
contains two parts: the message itself and its envelope.

WIRING

Use the following diagram for constructing a serial cable. Only 3 pins are required; Transmit,
Receive and Common.

PMS PC Interface

2 2
3 3
7 7

Common is on pin 5 in the DB9 connectors.

The PC interface program does not need RS-232 control signals (RTS, CTS, DSR, DTR .... ). If
the PMS communications routine cannot be set so that it does not require specific levels on those
control signals, the levels have to be physically pulled up or down (generally pins 5, 6 and 20
connected together)

PMS INTERFACE OVER ETHERNET CONNECTION (HT24W AND HT28 ONLY)

An additional feature offered by HT24W / HT28 Smart is the ability to interface over an
Ethernet based LAN rather than an RS232 serial connection. HT24W / HT28 Smart uses
standard Socket communication over the Ethernet. We have implemented sockets as a
mechanism for transferring data between remote or local processes (similar to named pipes). We
© 2005 Onity 8
 have not implemented it as a mechanism for making the Transmission Control Protocol/Internet
Protocol (TCP/IP) suite available to user applications.
When connecting over Ethernet, the packets do not change. They all begin with STX and end
with ETX and an LRC. These control characters are not truly necessary with Sockets, all of the
data integrity checking is built in. But to remain consistent, the data packets remain the same.

SOCKETS
Sockets are a standard Ethernet packet transfer protocol. Like RS232 serial communications,
sockets use ports. However, for sockets, ports are simply addresses identifying the sender and
the receiver of the data packets.
Some ports are reserved and should not be used. For example, port 80 is reserved for FTP
transfers. In general, any port greater than 6000 should be available. HT24W / HT28 Smart
defaults to port 6669. This is the port the software is 'listening' on. The PMS must know this
port number in order to connect.

© 2005 Onity 9
 COMMUNICATIONS ENVELOPE

The transmission protocol uses the following ASCII control characters

STX (02H) Start of message transmission

ENQ (05H) Communication check (query)
ETX (03H) End of message transmission
ACK (06H) Affirmative identification/recognition
NAK (15H) Negative acknowledgment
The complete message has the following format:

STX message ETX LRC

Every packet has to be followed by a longitudinal redundancy check (LRC). The LRC is the
character result of the exclusive OR (XOR) of all the message characters (STX not included)
plus the ETX character. It has to be calculated with NUL seed (00h).

Instead of calculating the LRC, it is possible to send the ASCII character 13 (RETURN key).
The PC interface will take it as a correct LRC. This is useful for the PMS communication driver
development process, however the final product should include the LRC.

For example, in the sequence STX|CO|0|ETX the LRC is calculated (in HEX) as
(B3)XOR(43)XOR(4F)XOR(B3)XOR(30)XOR(B3)XOR(03)=8C

1011 0011 = B3 (|)

XOR 0100 0011 = 43 (C)
1111 0000 = (B3 XOR 43) = F0
XOR 0100 1111 = 4F (O)
1011 1111 = (F0 XOR 4F) = BF
XOR 1011 0011 = B3 (|)
0000 1100 = (BF XOR B3) = 0C
XOR 0011 0000 = 30 (0)
0011 1100 = (0C XOR 30) = 3C
XOR 1011 0011 = B3 (|)
1000 1111 = (3C XOR B3) = 8F
XOR 0000 0011 = 03 (ETX)
1000 1100 = (8F XOR 03) = 8C = (î)

© 2005 Onity 10
 The control characters ACK and NAK are transmitted by the PC interface to indicate the
affirmative or negative acknowledgment. The PC interface answers NAK if it is not already
prepared to receive a new message or to indicate that the last message was not correct (bad
LRC). If the PMS receives NAK it needs to repeat the message until it receives ACK from the
PC interface. The PMS may send ENQ to know if the PC interface is free to receive a
mainframe.

See the following example of communication below:

PMS PC Interface

STX message ETX LRC

NAK

ENQ
ACK

STX message ETX LRC

ACK

STX operation result ETX LRC

The PMS needs to perform the following operations:

• Calculate and send the LRC of the characters following STX including the ETX (The LRC
can be simulated by the ASCII character #13).

• Wait until the acknowledgment (ACK) of the previous task before sending a new one.

• If there is no acknowledgment for 2 seconds, the PMS has to decide what to do because the
link with the PC interface has been cut.

• Show in the corresponding monitor the messages corresponding to every operation in order
to guide the operation.

© 2005 Onity 11
 • The swipe encoders require that the card be inserted a second time to verify the encoding
quality.

• The encoders have indicator lights on the front panel which show the status or expected
action of the encoder.

The Onity interface software performs the following operations:

• Checks the LRC to determine the integrity of the message received.

• Replies ACK or NAK before executing the received message.

• Replies NAK if the LRC is not correct.

• Keeps the task active until its execution or until the PMS aborts it.

DESCRIPTION OF THE MESSAGE

The message itself has two fields:

The command
The command parameters

Every field is delimited by separators. The separator is the ASCII B3h (179 represented as  in
this document).

Warning: A field with only one or various spaces will be considered as empty.

© 2005 Onity 12
 COMMANDS
COMMAND OPERATION

CNx To encode a new guest key card and x copies minus one. This card will
automatically cancel the previous guest's key card. This command is NOT
compatible with the virtual encoder (encoder zero).

CCx To encode copy(s) of a valid new key card. x is the number of copy(s) that will be
made. This command is NOT compatible with the virtual encoder (encoder zero).

CN To encode a card for a new guest. This card will automatically cancel the card of
the previous guest. The CNx command supersedes this command in HT24
version 5.x or later versions.

CC To encode a copy for a person that shares the room. The CCx command
supersedes this command in HT24 version 5.x or later versions.

CO Check-out of a guest. All guest cards of the corresponding room will be canceled.

CA To encode a single opening card. The single opening cards are only valid for that
particular guest room lock. They are automatically canceled after check out of
the guest or after having been used the first time.

EX Resets the encoder. Ejects card (if any) out of the encoder and aborts the last non
completed operation.

LT Read and interpret data on track 3 according the Onity standard.

P1 Encode information on track 1 of the magnetic card according to the ISO standard
for track 1. (Not available with the HT22 System)

P2 Encode information on track 2 of the magnetic card according to the ISO standard
for track 2. (Not available with the HT22 System)

P3 Encode information on track 3 of the magnetic card according to the ISO standard
for track 3. Do not use this command. (Not available with the HT22 System)

L1 Read the information on track 1, according to the ISO standard for track 1. (Not
available with the HT22 System)

L2 Read the information on track 2, according to the ISO standard for track 2. (Not
available with the HT22 System)

© 2005 Onity 13
 L3 Read the information on track 3, according to the ISO standard for track 3. (Not
available with the HT22 System)

WF Returns the oldest event stored in a peripheral controller’s memory. If there are
no events stored yet, the Onity terminal returns a WO command to the PMS
terminal. (Not available with the HT22 System)

WN Returns the next consecutive registered event. Continue using this command to
build a data base of events on the PMS system. When the WO command is
received by the PMS system, all of the registered events have been retrieved. (Not
available with the HT22 System)

WR Returns the last event stored in the peripheral controller’s memory. The PC
interface will confirm when the operation has been carried out successfully by
transmitting the same command and the number of encoder involved. (Not
available with the HT22 System)

The programming and reading of the tracks 1 and 2 are only possible on motorized encoders (not
in swipe encoders).

WF, WN and WR are only available in the HT24 version 4.1 and later software versions.
The 5.1 version is the first version in which the INTER program for PMS interfacing was
integrated into the HT24 program, so that both could run in tandem on one terminal. Because of
this, when peripherally intensive operations are occurring, the PMS terminal may receive a NAK
until the peripheral activity level is reduced. Functions in the HT24 software such as Peripheral
Diagnostics, Load Portable Programmer, Audit List, and Lock Report will warn the system user
that the PMS link will be interrupted until the operation is complete, and asks if they want to
continue. If they answer Y (yes), the computer will interrupt the PMS link and any HT24
Terminal communications until the operator completes the operation and returns to the HT24
menu.

© 2005 Onity 14
 PARAMETERS OF COMMANDS
PARAMETERS OF COMMANDS CN, CC, CN[X], CC[X] AND CA

Up to THIRTEEN fields:

- Number of the encoder to encode the card.

- Retain or eject the card.
- Room assigned as no. 1. (primary room)
- Room assigned as no 2.
- Room assigned as no 3.
- Room assigned as no 4.
- Authorizations assigned to guest.
- Authorizations denied to guest.
- Initial (start) date of the card.
- Expiration date of the card.
- Data of operator encoding the card.
- Information encoded on track 1.
- Information encoded on track 2.

Important: The message needs to contain at least the first three parameters. The others are
optional. If some parameters are omitted, their (empty) fields have to be put in
the message until the last non omitted parameter.

x: The number of card(s) to be encoded.

Several cards for the same room can be issued with one single command from the PMS.

For instance:

Using CN4 command will issue 1 new guest card + 3 copies.

Using CC3 command will issue 3 guest card copies.
Using CN1 ( or CN ) will issue only a new guest card.

the variable x can be an integer from 1 to 9.

Commands CN and CC (equal to commands CN1 and CC1) are still available, so
previously installed PMS interfaces will work properly with versions later than 5.1.

If more than one error occurs at the same time, the HT24 program will report to the PMS
the worst error. The operation must be completely re-started.

© 2005 Onity 15
 Parameter number 1: Number of the encoder

The list of peripherals in the HT24 software shows the address assigned to each encoder. For the
purposes of development, assume that the encoders start with number 1 and are numbered
sequentially. The property will know how many encoders have been ordered. This parameter is
linked to the address of the terminal originating the request for a key. So, if PMS terminal #3
(numbers 1 and 2 may be in the back office) is positioned next to encoder number 2, then this
terminal must always say that it needs a card made in encoder number two (Encoder number one
is generally reserved for management workstation functions.)

See the Addendum for special information regarding the virtual encoder zero.

Parameter number 2 : Ejection or retention of the card

When finishing the encoding operation, the card can remain in the encoder for successive
operations or it can be ejected.

E: Ejection
R: Retention
T: Ejection from the back of the encoder. This is used only in special situations with
motorized encoders.

Parameter numbers 3, 4, 5 and 6: Rooms

Rooms that can be opened by the card (max. 7 characters per field.)

NOTE: The command CA (single opening card) only works for the first, or principle
room, so parameters 4, 5 & 6 are meaningless.

Parameter number 7 : Assigned authorizations (Max. 8 authorizations)

Specify the numbers of the authorization assigned to the guest. The ones not specified
will take the value pre-established in the locking plan.

© 2005 Onity 16
 Parameter number 8: Denied Authorizations (Max. 8 authorizations)

Specify the numbers of the authorization denied to the guest. The ones not specified will
take the value pre-established in the locking plan.

As an example, if we want to allow a guest to use the swimming-pool and the safe
(authorizations number 2 and 3 respectively in the locking plan), and deny them access to
the spa (authorization number 1) the fields will be:

231

Warning: The number given to each authorization and its description can differ in each hotel.
Please consult Onity for the number and description of each authorization, or write the
software so that it can read a file that can be modified in the field for each job.

Important: The authorizations that are not specified will take the pre established value of the
locking plan.

Parameter number 9: Initial date

Eight characters total : hour (00 to 23), day, month and year. Two characters each.

For example:

12100792

indicates that the card will be operative from 12.00 p.m. on the 10th of July, 1992.

Complete omission of this field means that the card will be valid immediately after
encoding it.

Note: If motorized encoders are used and four rooms are required on a key card, the initial date
must be omitted.

© 2005 Onity 17
 Parameter number 10: Expiration date

Date on which the card will become invalid. This command has the same format as the
initial date.

Omitting this field indicates that the card has no time limit. It will be canceled by the next
new guest card.

The longest expiration date goes up to the 31st of December of the next year.

Important: The Onity system allows the encoding of an initial date only if an expiration date
is also encoded. If the encoding of a card with only initial date is requested, the PC interface will
answer with a syntax error message (ES). Please also note that the date MUST be in European
format. (HH DD MM YY)

Parameter number 11: Operator's data (Max. 20 characters)

The audit trail of the Onity system will register the encoding operation of this card with
the name of the operator written in this field. If you can extract the name of the user who
is logged into this terminal it is a good idea to insert it into this field. Most properties
management staff would like this to display the initials of the user. Complete omission
of this field means that the operation will be registered with the name "PMS" and in most
cases is unacceptable to the management staff.

Optional Password Validation (HT24W and HT28 v3.35 and later only)

With this feature enabled, the data included in parameter 11 of the interface data packet
will be validated against the passwords in the Operator table of the Onity software. If the
password is valid, the key encoding is allowed. If the password is not valid, an error is
returned.

Example:
STX|CN1|2|E|101||||2468|1357||13060205|1234|||ETX
The above line is an example of the data packet received from the PMS system to encode
a new card for room 101. This message is broken down as follows:
STX – the Start of Text command
Parameter 1 – ‘CN1’ – New Card command
Parameter 2 – ‘2’ – Use Encoder 2
Parameter 3 – ‘E’ – Eject card (for use with motorized encoders)
Parameter 4 – ‘101’ – Room 101
Parameters 5,6, and 7 – ‘ ’ – Used for multiple room cards
Parameter 8 – ‘2468’ – Assigned Authorizations
Parameter 9 – ‘1357’ – Denied Authorizations
Parameter 10 – ‘ ’ – Start date and time
Parameter 11 – ‘1234’ – Password
© 2005 Onity 18
 Parameter 12 – ‘ ’ – Track 1 Data
Parameter 13 – ‘ ’ – Track 2 Data
ETX – the End of Text command

In the above example, the password ‘1234’ will be validated by the Onity software. If it
is a valid password, the key will be encoded. If it is not a valid, an error message will be
returned.

Parameter numbers 12 and 13 : Message on track 1 and track 2

Encoding ABA tracks 1 and/or 2 is available using CNx and CCx commands. Just the
useful information has to be mentioned because the HT24 program automatically inserts
the STX, ETX and LRC characters corresponding to the ABA norms.
(Commands P1 and P2 do not automatically insert the STX and ETX characters. See
commands P1 and P2 for more detail).
These parameters are ignored by the HT22 system.

© 2005 Onity 19
 Characters and formats of tracks 1 & 2

The ISO standard for Track 1 allows the encoding of 79 characters. The message may be 76
characters long, and may contain both alpha and numeric characters. The other characters are the
two control characters, and the 1 character LRC.

- start sentinel character %

- end sentinel character ?
- redundancy check (LRC) character

There are 64 valid characters that may be written to track 1. They are:

SP ! “ # $ % & ′ ( ) * + , - . /
0 1 2 3 4 5 6 7 8 9 : ; < = > ?
@ A B C D E F G H I J K L M N O
P Q R S T U V W X Y Z [ \ ] ^ _

Note: Note that only capital letters are available.

The ISO standard for Track 2 allows the encoding of 40 characters. The message may be 37
characters long, and may contain only numeric characters. The remaining characters are the 2
control characters, and the 1 character LRC.

- start sentinel character ;

- end sentinel character ?
- redundancy check (LRC) character

There are 16 valid characters that may be written to track 2. They are:

0 1 2 3 4 5 6 7 8 9 : ; < = > ?

© 2005 Onity 20
 Example of message:

Let’s suppose that we want to encode one new guest-card in encoder number 1 with the
following features :

- Card ejected when encoding completed.

- To open the rooms 101 and 102.
- Parking assigned (authorization nº 6 in this hotel).
- Without initial date.
- Expire at 12.00 p.m. on 14th January 1993.
- Name of the Guest on track 1.
- Number of the room on track 2.

The PMS has to send the following message (correctly integrated in its envelope) :

STX|CN1|1|E|101|102| | |6| | |12140193| |MR SMITH|101|ETXLRC

Keep in mind that fields which are not used remain empty but their separators must be in
place.

If the operation has ended without errors the PC interface will send the following
message to the PMS:

STX|CN1|1|ETXLRC

Fig. 6-4. Example of CN[x] command with Track 1 and Track 2 messages

EXAMPLE OF A MESSAGE:
© 2005 Onity 21
 Lets suppose that we want to encode one new guest and one copy key card in encoder number 2
with the following features :

- Card ejected when finished encoding.

- To open rooms 101 and 102.
- Parking assigned (authorization number 6 in this hotel).
- Without initial date.
- Expire at 12.00 p.m. on 14th January 1993.

The PMS has to send the following message (correctly integrated in its envelope)

STXCN22E101102612140193ETXLRC

Keep in mind that fields which are not used remain empty, but their separators must be in place.

If the operation ended without errors the PC interface will reply to the PMS with the following
message:

STXCN212ETXLRC

Lets suppose that we want to encode two more copies for the same room number on encoder
number 2 with the following features :

- Card ejected when finished encoding.

- To open rooms 101 and 102.
- Parking assigned (authorization number 6 in this hotel).
- Without initial date.
- Expire at 12.00 p.m. (noon) on 14th January 1993.

The PMS has to send the following message (correctly integrated in its envelope)

STX CC22E101102612140193ETXLRC

Again, keep in mind that fields which are not used remain empty but their separators must be in
place.

If the operation ended without errors the PC interface will send the following message to the
PMS:

STXCC22ETXLRC

© 2005 Onity 22
 NOTE: The CN and CC commands are still supported for reasons of backward compatibility,
and to support the virtual encoder (encoder zero). If the new guest desires more than one card at
the time of check-in you must repeat the same command exactly but replace the CN command
with CC. This must be done for as many copies as are needed. Every NEW guest MUST have
his first key encoded with the CN command. PMS interfaces written using the HT24 versions
5.X or later should utilize the CN[x] and CC[x] commands. While these systems can still accept
the older CN and CC commands, the CN[x] and CC[x] perform the same task with less traffic on
the PMS system, allowing the Onity system to perform the task of queuing the new card and
copy card requests to the proper encoder. Please note that the CN[x] and CC[x] are not supported
for the virtual encoder zero. A request for more than one key for a new guest must consist of a
CN command followed by CC commands.

Parameters of command CO: CHECK OUT

Two parameters:

Encoder number (The encoder number for this operation is always 0, as an encoder is not used.)

Room Number

Example:

Let us suppose that we want to cancel the card of room 101 (check-out of the corresponding
guest).

The PMS has to send the message:

STXCO0101ETXLRC

If the operation has ended without errors the PC interface will send the following message to the
PMS:

STXCO0ETXLRC

© 2005 Onity 23
 Parameter of command EX: RESET THE ENCODER

This function requires the EX command to be followed only by the encoder number.

The message:

STXEX2ETXLRC

sent by the PMS will eject the card (if any) and will abort the current task (if any) of encoder
number 2.

The PC interface will reply with:

STXEX2 ETXLRC

Parameters of command LT: READ THE GUEST CARD

2 parameters

- Number of encoder
- frontal ejection, retention or rear ejection

The PMS can recognize every card of the hotel, but will only identify a valid guest card. This
command is used to discover why a card may not be working in a particular room or may not
operate a particular authorization.

This command will cause one of the following 4 messages to be returned by the PC:

1. - Card recognized and identified

2. - Card recognized, but not identified
3. - Card not recognized
4. - Error message (see the section on error messages for a complete list)

© 2005 Onity 24
 1.- Card recognized and identified
Only if guest card or single opening card.

The reply from the PC Interface after having read the card, repeats the name of the
command (LT), the number of the encoder involved, and with the following fields.

- Room number 1(primary) opened by the card. This field will never be empty.

- Room number 2 opened by the card or empty field.

- Room number 3 opened by the card or empty field.

- Room number 4 opened by the card or empty field.

- Valid card or previously canceled by using the check-out command.

CI: Card with valid code for the primary room.

CO: Card whose code for the primary room has been canceled by check out.

- Indication of the number of the card copy or single opening card. (of the primary room)

0: original card
1: first copy
2: second copy
3: third copy
4: fourth copy
I: undefined copy (fifth and successive)
A: single opening card

- Given authorizations.
Numbers(1 to 8) of the authorizations given to the card or empty field when no
authorizations are given.

- Initial date given to card or empty field if no initial date.

- Expiration date given to the card or empty field if no expiration date.

- Name of operator who issued the card, if this information is still in the audit trail, or
an empty field.

© 2005 Onity 25
 Figure 6-5. Answer for a LT command.

Example 1 (shown in Figure 6-5 above)

The PMS wants to identify a card in encoder number 1, and after that eject it. The PMS
must send the following command.

STXLT1E ETXLRC

The PC Interface asks encoder number 1 to read the card and answers to the PMS:

STXLT1101102CI212612150693PMSETXLRC

© 2005 Onity 26
 which means:

LT Card read without errors

1 In encoder number 1
101 Opens room 101
102 Also opens room 102
(empty field)
(empty field)
CI Card still has a valid code
2 Copy #2 of the primary door 101
126 Authorized for 1, 2 and 6.
(empty field) without starting date.
12150693 Expiration date 12 p.m., 15th of June 1993.
PMS issued by the PMS.

Note that the reply shows all of the fields, even if they are empty.

2.- Card recognized, but not identified.

The PC Interface will reply with the command (LT) and the number of the encoder
together with the following fields.

LC Guest card NOT valid

LM Master card or special card.(programming, canceling or blocking card)

LR Spare card (backup card).

LS Diagnostic card.

Example 2

The PMS wants to identify a card in the encoder no 3 and retain it. The PMS must send
the following message:

STXLT3RETXLRC

The PC Interface asks the encoder number 3 to read the card and answers to the PMS:

STXLT3LMETXLRC

© 2005 Onity 27
 which means:

LT Card read without error.

3 In reader/writer number 3.

LM Master card or special card.

3.- Unidentified card

The PC Interface will reply with the command (LT) and the number of the encoder
together with the following field:

- LD Unidentified card (Belongs to another hotel or has been erased in the locking plan).

Example 2

The PMS wants to identify a card in the encoder no 3 and eject it. The PMS must
send the following message:

STXLT3EETXLRC

The PC Interface asks the encoder number 3 to read the card and answers to the
PMS:

STXLT3LDETXLRC

which means:

LT Card read without error.

3 In reader/writer number 3.
LD Unidentified Card.

4.- Error message

Error in the operation of reading a card.

Refer to the section on error messages for the list of possible errors.

© 2005 Onity 28
 Parameters for Command P1, P2 and P3: Encode Track(s) 1, 2 and 3. (Not available with the
HT22 System)

3 Parameters.

- Number of encoder
- Frontal ejection, retention or rear ejection of the card.
- Message to be encoded. This message should respect the ISO norms for
encoding on the selected track.

Example:

We want to encode the message:

%SQUASH CLUB MEMBER?

On track 1, according to the ISO norms for track 1, and retain the card in the encoder
number 1. The PMS has to send the following message:

STXP11R%SQUASH CLUB MEMBER?ETXLRC

Note: ISO requires that the message in track 1 be preceded by character % (start sentinel) and
be followed by character ? (end sentinel).

If the operation has been carried out successfully PC Interface sends the following
message to the PMS.

STXP11ETXLRC

Note: The Interface PC translates the ASCII characters into ISO symbols for track 1, 2 or 3. It
also calculates the parity of the message in such a way that it respects the ISO norms for
track 1, 2 or 3.

IMPORTANT: Read the ISO specification for track 1, 2 and 3 in for the following information:

- Allowed symbols for each track

- Maximum number of characters for each track
- Characters for start, end, and separator for each track.

© 2005 Onity 29
 Parameters for Command Ll, L2 & L3. READ TRACK 1,2 OR 3. (Not available with the HT22
System)

2 Parameters.

- number of encoder
- Ejection, retention or rear ejection.

Example:

If we want to read the encoded card of the previous example and eject it at the end of the
operation, the PMS must send the following message:

STXL11EETXLRC

The PC Interface orders the encoder number 1 to read the card and will send the
following message to the PMS:

STXL11%SQUASH CLUB MEMBER?ETXLRC

© 2005 Onity 30
 Succession of tasks in different encoders

The PC interface will spool unfulfilled tasks.

Your PMS software can order the encoding of another card before the completion of a
previous card encoding. The PC interface will respond with the result of the first task it
is able to complete. It is possible that the first task completed was not the first task sent.

Example:

Lets suppose that the PMS orders the encoding of a new guest card for room 101 in encoder
number 2 and then immediately orders the encoding of a copy of a card for room 102 in encoder
number 3.

PMS PC Interface

STXCN2E101ETXLRC

ACK

STXCC3 E102ETXLRC

ACK

The operator on station number three might encode their card first, while the operator on station
number two is still working with the guest on other issues, then encodes their card. The PC
Interface will send the following messages to the PMS in the order that the operations were
completed:

STXCC3ETXLRC

STXCN2ETXLRC

In this example the operator at station number two was slow to insert the blank card in the
encoder. That's why the task for room 102 was completed first.

© 2005 Onity 31
 Warning: The PC interface keeps the list of tasks to be accomplished in different encoders. To
order the execution of a new task in the same encoder, it is imperative to wait until the previous
task has been accomplished. This will probably happen by default in your software anyway
since the encoders are associated with the PMS terminals and it is unlikely that the front desk
clerk would be able to start another transaction before the current one is complete. If the front
desk clerk does not encode the requested key card, and the PMS does not receive
acknowledgment of the operation within a few minutes, the PMS should send an error message
to the front desk clerk and an EX package to the respective encoder. This will reset the encoder
in question and prevent an OV error message from being sent to the PMS. If the clerk is allowed
to proceed with the operation, and the PMS does not send an EX command to the PC Interface
for the respective encoder, the Onity system will respond to the PMS with an OV error message,
indicating that the encoder is waiting for the operator to perform an operation.

© 2005 Onity 32
 ERROR MESSAGES

If the operation requested by the PMS could not be carried out correctly, the Onity system will
generate the following error messages:

ERROR MESSAGE CAUSE

EA Requested copy corresponds to a room that has been

checked-out. This message also appears when requesting a
fifth one shot card, because a maximum of 4 one shot cards
per each new guest can be encoded.

ED Card not inserted or jammed in the encoder. In the

Automatic Check in Terminal, this is also used to indicate
that the magazine is empty.

EE Operation Canceled. The requested function was canceled

by the Onity program. This can occur when exiting to DOS
or shutting down the PMS communications link for special
operations.

EF Magnetic format error. The magnetic strip may be

damaged.

EL End of Rent to Own period. The program is locked until the

new RTO code is entered on the HT24 console.

EN Low recording level. The card has been encoded with a

low magnetic level due to dirt on the magnetic heads of the
encoder, or a low quality or damaged card was used.

EO Requested room data being processed by another station.

EP Card inserted incorrectly. The card was inserted

backwards or does not have a magnetic stripe.

ES Syntax error. The message envelope or format is not

correct (unknown command, invalid parameters, invalid
characters, or too many characters to write according to the
ISO norms, incorrect date or date format, etc.).

ET Card jammed in encoder. The card does not have the proper
physical dimensions and is stuck in the encoder, or a
foreign object may have been inserted into the encoder.

© 2005 Onity 33
 NC No communication. The corresponding encoder does not
answer. Failure in the communications, the encoder is not
turned on or plugged in, or the encoder does not exist.

NF No files. The HT24 data files in the PC interface are

damaged or have been deleted.

OS Room out of service.

OV Overflow. The encoder / operator has not performed the

previous task.

PE Password Error. If using the password validation option,

an invalid password in the operator name field, parameter
11 will generate this error. (HT24W / HT28 version 3.35
and later ONLY)

TD Unknown room. The room number requested by the PMS

system does not exist in the Onity system.

The error message is followed by the number of the corresponding encoder.

The PMS must display the error message on the appropriate PMS terminal screen and
repeat the transmitted message if it was not a fatal error. For example, if the card was
inserted backwards, simply pause, alert the operator, and reissue the same command.

Example:

The PMS requests the encoding of a new guest card for room 101 in encoder number 2.

1. All others parameters use the system defaults.

The PMS sends:

STXCN2E101ETXLRC

If the card has been inserted backwards the PC interface answers:

STXEP2ETXLRC

2. The PMS displays the error on the screen of the appropriate terminal, and
then sends through the command again.

© 2005 Onity 34
 COLLECTING EVENTS FROM PERIPHERALS
Only versions 4.x and later of the HT24 software support this function. The HT22 does not
support this function.

The PMS can retrieve the event registers (openings and attempts of opening) from the
peripherals (on-line wall readers and card identifiers) through the PC interface that controls the
peripheral network (HTCOM). The peripherals have to be declared in the MODI2 program with
"automatic collection of openings" to update the PC interface files. The PMS must manage its
own database of events which is updated by requests to the PC interface.

The following three commands are used to retrieve the data from the peripherals:

WF Gives the PMS the oldest event register of a peripheral.

WN Gives the PMS the next event register of a peripheral.

WR Gives the PMS the last received event register.

PARAMETERS OF THE COMMANDS WF, WN AND WR

The command is followed by the peripheral number.

EXAMPLE:

The PMS asks for the first (oldest) event register of the Swimming-pool wall reader (peripheral
number 2). The PMS needs to send to the Onity PC interface:

STXWF2ETXLRC

RESPONSE TO THE COMMANDS WF, WN AND WR

The PC interface sends the requested event register to the PMS:

STXWxPeripheral #DateHourTypeWayCardCopy #UserETXLRC

Wx Repeats the command sent by the PMS (WF, WN or WR)

Peripheral # Repeats the same peripheral number with the same format as sent by the PMS (If
the PMS has sent 002 the PC interface repeats 002).

© 2005 Onity 35
 Date Day/Month of the event (5 characters). If the Onity system has been set to show
dates in USA format the date is given in Month/Day format.

Hour Hour : Minutes of the event (5 characters).

Type Type of event (1 character). It is a number from 0 to 5. Only 0 means that the
opening took place. Numbers 1 to 5 denote why the opening has been rejected.

0 Opening fulfilled
1 Card does not belong to the property (from another hotel, another
locking system, visa card, etc.)
2 Card has expired or has been checked-out.
3 Card is not valid for this lock.
4 Card out of time shift.
5 Anti pass-back.

Way Entrance or Exit (1 character)

I Entrance reader
O Exit reader

The wall readers can be configured to control the entrance and the exit using two
card readers on a single controller.

Card Card identification (8 characters)

Copy # Copy number of the card (2 characters)

#0 Original card
#1 First copy
#2 Second copy
#3 Third copy
#4 Fourth copy
#D Undetermined copy (Fifth and successive)
@1 Single opening card number 1
@2 Single opening card number 2
@3 Single opening card number 3
@4 Single opening card number 4
MT Temporary master card
Regular master cards (not temporary) are always original (#0)

User Name of the user of the master card (20 characters). This field is not used if the
card is not a master card.

© 2005 Onity 36
 Special events in on line readers

If the field CARD is empty (8 spaces) it means that it is a special event. The next field COPY#
gives more information:

Card (8 spaces)

Copy #
S0 Master canceling card
S1 Spare card
S2 Opening made by the exit button
S9 Unknown card. (Master belonging to a user deleted from the
master users list, guest card belonging to a room deleted from
the room list, etc. )

ERROR MESSAGES

The commands WF, WN and WR can produce two error messages:

WE The peripheral does not exist or it is not programmed to automatically retrieve its
events.

WO No more events. The definition depends on the command that made this error.

After WF No event resisters at all.

After WN No more event registers. The last (most recent) event register has
already been sent to the PMS.
After WR The PMS has not asked for an event register, so the Onity PC
interface cannot repeat the last communication.

The error message is followed by the corresponding peripheral number.

© 2005 Onity 37
 EXAMPLE:

The PMS sends this packet to the Onity PC interface:

STXWF9ETXLRC

The Onity PC interface receives the communication, sends ACK and answers to the
PMS:

STXWE9ETXLRC

The peripheral number 9 does not exist or it is not programmed to automatically retrieve its
events.

USING THE WF, WN AND WR COMMANDS

With these three commands the PMS can continuously build and update its own database.

1. Building the PMS database

When the PMS requires a registered event.

- Send the WF command to retrieve the first registered event (the oldest).
- Continuously send the WN command until the Onity PC interface answers WO (no
more events registered).
- Repeat the operation for each peripheral.

2. Updating the PMS data base

- Periodically send the command WN to get the last registers.

- When the PMS gets the error message WO repeat the operation for the next
peripheral.

If after a WN command the PMS does not properly receive the communication or the
communication has been lost, the PMS has to send the WR command to make the Onity PC
interface repeat the event register previously sent.

All of the fields have a constant length. If the information contained in a field does not fill it in
completely, the remainder will be filled with spaces.

© 2005 Onity 38
 EXAMPLES:

The PMS sends

STXWN2ETXLRC

The Onity PC interface receives the correct message and sends ACK. It processes the
command and answers to the PMS:

STXWN210/0814:270I101 #2 ETXLRC

The next event registered in peripheral number 2 was made on the 10th of August at
14:00 hours and 27 minutes. The opening was made by the second key card copy for
room 101.

The Card field has the identification plus five spaces to complete the required eight
characters. The "User" field is empty (20 spaces) because it is not a master card.

If the PMS does not properly receive this message, it must send;

STXWR2ETXLRC

The Onity PC interface receives the message and sends ACK. It processes the command
and answers to the PMS:

STXWR210/0814:270I101 #2 ETXLRC

It is exactly the same register sent before by the Onity PC interface.

The PMS may update its database by periodically sending the WN command to each peripheral.
It is the responsibility of the PMS provider to manipulate and report against this database.
Options that allow an operator to request specific information concerning events from the front
desk terminals are preferred by most hotels requesting this feature.

The Onity system keeps a buffer within each peripheral with the last 8000 events of each wall
reader and 2000 events of each card identifier. The PMS may poll for this information frequently
during the course of the day, or periodically as a part of a schedule of operations just a few times
per day.

© 2005 Onity 39
 PRE-CALCULATED DATA FORMATS FOR TRACKS 1 AND 2

With the addition of the TRACK1=PMS and TRACK2=PMS statements to the FLAGS.HT2 file,
the Onity HT24 system will encode pre-calculated guest data on the specified track. This data
includes the following information:

Room Number (8 Characters)

Authorizations (8 Characters)
Expiration Date (8 Characters)

All of the fields must contain the appropriate number of characters. If the room number field has
less than 8 characters, padding characters are added to fill the open trailing positions.

In the authorizations field, the position will correspond to the authorization number, i.e., the
number 1 in the third position indicates that authorization 3 is granted. The number 1 in any
position indicates an authorization is granted. The number 0 in any position indicates a denied
authorization.

The expiration date includes time, and is in the format HHDDMMYY. If a card has no
expiration date, this position will be filled with zeros.

The following table shows what characters are used on each track to perform each function:

Character Type Track 1 Track 2

Separator Character ^ =
Padding Character Space :
Start Sentinel % ;
End Sentinel ? ?

Example of message:

Let’s suppose that we encode a guest card for room 101, with an authorization for
parking (number 6 in this example), and the card is set to expire at 2p.m. on August 14,
1998. The data on Track 1 would be:

%101 ^00000600^14140898^ ?

The Data on Track 2 would be:

;101:::::=00000600=14140898=::::::::::?

© 2005 Onity 40
 CERTIFICATION
When you feel as if everything is operational, you may certify your system at your option. At
the very least, we would like to know what functionality you implemented, This certification
may be done using the interface tools program which is available from the Product Manager. If
you want to certify your system, contact Onity at (770) 447-4105 and ask to speak to the Product
Manager for Hotel Lock Systems. The following explains the requirements for each certification
grade.

Grade C interfaces support the following functions:

1. New Guest
2. Copy Guest
3. One Shot Card

Grade B interfaces support all of the functions of grade C, and the following items:
1. Check Out
2. Read Card
3. Display of all Onity messages (including errors) on the PMS terminal screen.

Grade A interfaces support all of the functions of grades B and C, and the following items:
1. Authorizations
2. Multiple rooms on one card (configurable to either 3 or 4 rooms).
3. Support for high volume requests from multiple terminals without degradation of PMS
system performance.

Grade AA interfaces support all of the functions of grades A, B and C, and any of the following
functions:
1. Read and Encode Tracks 1 and 2.
2. Retrieve information from Onity online devices.
3. Kiosk support.

The error messages are listed in this technical documentation. It is critical that error messages
are supported by all interfaces of grade B or better.

© 2005 Onity 41
 ADDENDUM 1 : ENCODING ONITY KEYS ON A 3RD PARTY ENCODER

Applicable to HT22 version 3.03 and later, and all versions of HT24W and HT28 Smart

The ONITY PMS protocol allows property management systems to request a card at an encoder in the
ONITY system. If the PMS sends a new guest or copy command to the ONITY virtual encoder, Encoder
0, the ONITY system will respond with the information required for the PMS to encode the card on any
track 3 encoder that will accept raw data input. This document explains the manipulation required to
perform third party encoding. Note that throughout this document the standard ONITY PMS separator
character (ASCII 179) is represented by '|'.

Supported Systems
The virtual encoder is supported by the PC based front desk systems referred to as HT24 &
HT28. It is not supported by the HT22 front desk system (hardware only, no PC).

Commands
The virtual encoder (encoder zero) accepts the CN and CC commands only. The CNx command
is not supported. To ask for 2 keys for a new guest you must send on CN command followed by
one CC command.

Format
When a CN (new guest) command is sent by the PMS to ONITY encoder 0, the reply contains all
of the information necessary to encode the card. For reasons of security, however, this
information must be manipulated before a valid card can be encoded. The ONITY reply is in the
following format:

STX | Leading zeros | data | ETXLRC

The 'Leading zeros' field is a number between 40 and 60 that indicates the number of zeros to lay
down on track 3 before encoding any actual data. These zeros are used by ONITY locking
devices to establish timing and to prevent data loss if the edge of the card becomes worn.
The 'Data' field is hexadecimal data that requires manipulation before a card can successfully be
encoded.

Example:
PMS sends ---> STX|CN1|0|E|101|102| ... |ETXLRC
ONITY replies ---> STX|40|048FE83...(DATA)...DF53|ETXLRC

Manipulation
The information in the 'Data' field above must be rearranged and reformatted before encoding the
card. There are four 'rules' to the formatting of the information.
0) Leading zeros are encoded first.
1) The data is broken into bytes and an extra "1" bit is added between every byte and at the
beginning and end of the packet
2) The bytes are written in reverse order -- from LSB to MSB.
3) The rest of the card is filled with zeros.

Example:

40 to 60 leading zeros from the beginning of the mag. stripe.

'1'
First byte of the message (8 bits representing the hex value) beginning from LSB.
© 2005 Onity 42
 '1'
Second byte
'1'
Third byte
'1'
Fourth byte
'1'
... continue
'1'
Zeros until the end of the mag- stripe.

This example shows a bit by bit representation of the following ONITY response
STX|40|C11A2B3D32|ETXLRC

40 to 60 zeros 1 C1(LSB to MSB) 1 1A 1 2B 1 3D 1 32 1 zeros until end

000...000 1 10000011 1 01011000 1 11010100 1 10111100 1 01001100 1 000...

reading/writing direction >>>>>>>>>>>>>>>

By encoding the raw data generated using the procedure outlined in this document, a PMS can encode
ONITY cards on a third party encoder. There is no similar method for reading ONITY cards, but cards
should be verified against the data to be certain there were no encoding errors.

READING OF ONITY CARDS USING A 3RD PARTY ENCODER

Instead of reading the card using a ONITY encoder, it can be read also using a standard encoder by sending this
information to the ONITY main computer in order to obtain the interpretation of the card’s message.

The extended command to read a card with a standard encoder has the following syntax:

‰ |LT|0|message|

The message passed to the ONITY main computer (third parameter) must be obtained following the
next rules1:
1) Read the message of the card.
2) Delete the leading bits with value 0.
3) Delete the trailing bits with value 0.
4) Each byte is separated with a bit ‘1’. Delete these delimiters.
5) Each byte is represented beginning with the least significant bit (lsb). Rotate each byte
before sending it to the ONITY computer.

Example:

Step Message
1 Read the card’s message 00000 1 11001000 1 11101010 1 11010101 1 000000000000
2 Delete leading 0’s 1 11001000 1 11101010 1 11010101 1 000000000000
3 Delete trailing 0’s 1 11001000 1 11101010 1 11010101 1
1
This is the inverse of the process made when encoding a card using the CN 0 command.
© 2005 Onity 43
 3 Delete delimiters bit 1’s 11001000 11101010 11010101
4 Rotate each byte 00010011 01010111 10101011
Message to send in Hex 13 57 AB

The answer of the ONITY main computer is exactly the same answer obtained when reading from a
ONITY encoder. (Refer to the “PMS INTERFACE” document “LT command” section).

-end-

© 2005 Onity 44
 RETURNING ONITY EQUIPMENT
If you have Onity equipment, please return it to the following address:

Onity Inc.
2100A Nancy Hanks Drive
Norcross, GA. 30071
Attention: Product Manager

© 2005 Onity 45