> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/products/integrations/elevators/kone/kone-serial-standard.md).

# KONE serial integration

Understand the legacy KONE serial integration, limits, and controller requirements.

| Attribute    | Value                                                     |
| ------------ | --------------------------------------------------------- |
| Status       | Current, legacy / serial                                  |
| Protocol     | **Kone Protocol v2.5** (Conventional Dispatching System)  |
| Architecture | RS232 serial cable from C6000 directly to Kone Controller |
| Licensing    | **Non-licensed**, no additional licence required          |
| Relationship | Predecessor to Kone ELI (IP-based)                        |
| Coexistence  | Each serial connection requires its own Controller        |

Kone Serial supports **older Kone elevator systems** that use the Conventional Dispatching System and communicate via Kone Protocol v2.5.

## How it works

### Access zones per floor

Each elevator-serviced floor is assigned an **access zone**, representing the area directly outside the elevator on that floor.

### Access-control behaviour

* If an access zone is in **Free Access**, its floor button in the elevator is **enabled**.
* If an access zone is **Secure**, the button is **disabled** unless access is granted.

### Cardholder access flow

1. The cardholder presents their card at the elevator reader.
2. The Gallagher Controller authorises access and enables the relevant floor buttons.
3. After a floor is selected (or after a timeout), the buttons return to their default state.

### Access beyond Gallagher's control

**Cardholders always retain access to any floors not controlled by Gallagher.** These floor buttons remain unaffected by Gallagher's access zones.

## Polling and monitoring

* **Ongoing polling:** Gallagher continuously polls the elevator system to detect connection loss and send updates when access permissions change.
* **Alarms on disconnection:** if the connection is lost, an alarm is triggered in Command Centre.

## Communication interface

![Kone Serial architecture - Gallagher CC Server and Workstation over Ethernet TCP/IP to two C6000 Controllers, each connected via RS232 to an Elevator Group Controller, supporting 4 lifts total](https://328339335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6bM8WhlBE9BYizPWJaPN%2Fuploads%2Fgit-blob-fabadb98b2d9247ceefce8cc539ef02b0837f15d%2FSECHUB-kone-serial-01-diagram.png?alt=media)

* Each serial connection to the elevator system requires its **own Controller**.
* Use a **Controller 6000** to handle high-level serial communication with Kone systems.
* ⚠️ A single Controller can manage **only one serial connection** due to its single serial port.

### Limits

| Connection type | Max Elevator Shafts/Cars per Controller |
| --------------- | --------------------------------------- |
| RS232           | **8**                                   |
| TCP/IP          | **2**                                   |

> Full configuration setup: refer to **User Guide Documentation Volume 1** under *High Level Interface Elevator Cars*.

## Lost connection to the elevator system

If communication between the Gallagher Controller and the elevator system is lost:

* **The elevator system itself determines what access is allowed from elevator cars.**
* **Typically, all floors are temporarily set to Free Access** until the connection is restored.
* Gallagher continues polling the elevator system at regular intervals.
* Once communication is re-established, Gallagher automatically recognises the restored connection and re-secures access to controlled floors based on the latest access permissions.

## Reader and access behaviour

### Cardholder override behaviour

If a second cardholder badges their card before the first has selected a floor:

* The **second cardholder's access takes priority**.
* The first cardholder must re-badge to select a floor.

### PIN-protected floors

* If a floor requires a **PIN**, the floor buttons will not enable unless the PIN is correctly entered.
* Access to other, non-PIN-protected floors remains unaffected.

## Can Kone readers be used with Gallagher's Kone lift feature?

| Reader type                                                                 | Supported?                                                           |
| --------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| Kone-controlled reader (not wired to a Gallagher Controller)                | **No**, not supported                                                |
| Kone-branded third-party Wiegand reader, wired to Gallagher Controller 6000 | **Potentially yes**, may work if wiring and protocols are compatible |

## Rear door access

Kone ELI supports both Front and Rear door access. For Kone Serial, refer to **Elevator HLI** and **Floor Arrangement** configuration in [Kone ELI Configuration](/knowledge-hub/products/integrations/elevators/kone/kone-eli/kone-eli-configuration.md); the 7.80 release notes contain the relevant section.

***

🔗 **Related**

* [Kone Integration](/knowledge-hub/products/integrations/elevators/kone.md). The three Kone integration methods.
* [Kone ELI](/knowledge-hub/products/integrations/elevators/kone/kone-eli.md). The current IP-based successor to serial.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.security.gallagher.com/knowledge-hub/products/integrations/elevators/kone/kone-serial-standard.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
