---
title: "Connecting Multiple Cores"
description: "Share devices between TapHome Core control units: expose them on one Core over Modbus TCP and read them on another, or use the local TapHome API."
url: "https://taphome.com/en/docs/configuration/multiple-cores/"
language: en
lastmod: 2026-11-08
generator: hugo
ai:
  topics: ["multiple-cores","device-sharing","modbus-tcp","expose-devices","network-configuration"]
  questions: ["How do I connect multiple TapHome Cores together?","How can one Core control devices of another Core?","Which protocol should I use to connect two Cores?","How do I expose devices of one Core over Modbus TCP?","How does the second Core read the exposed devices?","What is not transferred between Cores?","What happens when the connection between Cores is lost?","Should I use the Integration Protocol to connect Cores?"]
---

# Connecting Multiple Cores

Connect two or more TapHome Core control units: one Core exposes its devices over Modbus TCP and the other reads them, each Core keeps running its own modules and smart rules.

Last updated: 2026-11-08

Two or more TapHome Core control units share devices over the local network: one Core exposes the devices in **Expose Devices** over Modbus TCP, and the other reads them through a **Modbus TCP** interface. Each Core keeps running its own modules and smart rules, and the shared devices can be used in smart rules and dashboards of the other Core.

## When to Use More Cores

- **Another building** of the same site with TapHome modules — the bus runs over copper only, so the building gets its own Core connected over LAN ([devices in another building](https://taphome.com/en/docs/wiring/remote-buildings/)).
- **Separate units** in one building, such as apartments, each with its own Core, and a common Core for shared areas.
- **More modules** than one Core and its [Bus Extenders](https://taphome.com/en/docs/wiring/bus-extender/) can serve.

## Connecting Cores over Modbus TCP

In the example, Core B has the devices and Core A reads them.

**On Core B:**

1. In **Expose Devices**, select **Add new interface** → Modbus TCP and set its TCP port and Slave ID ([TapHome to Modbus](https://taphome.com/en/docs/expose-devices/modbus/)).
2. With **Add device**, add the devices Core A needs and pick the values and actions to expose. Each one gets its own register with the register type, index, data type, byte order and multiplier.
3. For each value, add a validity register: Core A then knows when a value is not valid, for example when the device on Core B is unavailable.
4. Give Core B a fixed IP address, a DHCP reservation in the router.

**On Core A:**

1. In **Hardware**, add a **Modbus TCP** interface and a module with the IP address of Core B and the same Slave ID ([Modbus](https://taphome.com/en/docs/integration/modbus/)).
2. Add each device by the registers that Core B lists for it. Through a register of an action, Core A also triggers device actions on Core B, such as blind commands.

> [!IMPORTANT]
> Since TapHome 2026.1, the exposed Modbus TCP interface answers only its own Slave ID; a request with another Slave ID, for example 0 or 255, gets the Modbus exception 0x0A instead of values. Several Modbus TCP interfaces can share one port if they have different Slave IDs ([release notes 2026.1](https://taphome.com/en/docs/release-notes/2026-1/#expose-devices)).

## TapHome API

Core B also offers the [TapHome API](https://taphome.com/en/docs/expose-devices/taphome-api/) over the local network. Core A can read and control Core B's devices through it with a Packet Parser HTTP script; it is also the way for apps and other systems.

## What Is Not Shared

- Modbus carries values and actions. Names, icons, zones and categories are set again on Core A.
- The operation mode of a device on Core B (automatic or manual) is not shown on Core A.
- When the connection is lost, Core B keeps running its own modules and smart rules; Core A loses the shared devices until the connection returns.

## Integration Protocol

The Core also offers the [Integration Protocol](https://taphome.com/en/docs/expose-devices/integration-protocol/) for third-party control systems such as AMX, Crestron or Control4. It is not recommended for connecting Cores: it transfers only a fixed set of device types, without icons, zones or the operation mode, and its UDP variant accepts commands without any authentication.

**See also** — [Devices in another building](https://taphome.com/en/docs/wiring/remote-buildings/), [Network architecture](https://taphome.com/en/docs/configuration/network-architecture/), [Requirements for Third-Party Devices](https://taphome.com/en/docs/setup/requirements/).