Shared Device Cores

Device Core Sharing allows a Reactor instance to use device cores running on a different Blue Pill. This enables distributed architectures where device communication happens close to the equipment while control logic remains centralized.

Why Share Device Cores?

Hardware Connection Requirements

Some device cores require direct physical connections:

  • Serial/RS-422: PTZ cameras, legacy routers, certain production equipment
  • USB: Some camera control systems, specialized hardware
  • GPIO: Tally systems, custom integrations

When equipment requires these connections, you need a Blue Pill physically present at the equipment location. Device Core Sharing lets your main Reactor instance access these locally-connected cores.

Example: Camera control via serial connection. A Blue Pill near the cameras has the physical serial connections and runs the camera device core. Your main control room Reactor connects to this shared core.

Load Balancing Across Controllers

When you have a large number of devices to control (for example, 20 or more), running all device cores on a single Blue Pill can strain system resources. By distributing device cores across multiple controllers, you can:

  • Balance processing load: Each Blue Pill handles a subset of device protocol communication
  • Improve system stability: No single point of failure for all device connections
  • Scale flexibly: Add more Blue Pills as your facility grows

Example: A facility with three operator positions and 20 devices. Instead of each Blue Pill running all 20 device cores:

  • Controller A runs cores for devices 1-7
  • Controller B runs cores for devices 8-14
  • Controller C runs cores for devices 15-20

Each Reactor instance connects to the shared cores on the other controllers. Any operator can control any device, but the protocol processing is distributed across all three Blue Pills.

Geographic Latency

When controlling devices across long distances (different buildings, cities, or continents), network latency can significantly impact the responsiveness of device protocols. By placing the device core close to the equipment:

  • Protocol communication between the device core and equipment has minimal latency
  • Blue Pill-to-Blue Pill communication handles the longer distance more gracefully
  • User experience remains responsive even with geographic separation

Example: An ATEM switcher at a remote broadcast venue. A local Blue Pill runs the ATEM device core, communicating directly with the switcher. Your main Reactor instance at headquarters connects to this shared core over the internet.

Limited Client Connections on a device

Some devices, eg some PTZ Cameras do not allow more than a certain number of connections before running into issues. This has also been a case for earlier versions of the ATEM Mixers. If we now want to use several controllers, GPI Boxes and other devices to access them you might run into trouble. This is why sharing the same devicecore can be beneficial, so that the end device only sees one connection.

Example: A older ATEM Switcher shall be used to provide Tally feedback to several PTZ Extremes and RCPPros. more than 5 connections to the device are not possible. To solve this, we setup one device to connect to the atem core, and add this device on all others as "remote devicecore".

Enabling Device Core Sharing

Device Core Sharing is configured on the Blue Pill that will host the device cores (the one with direct access to the equipment).

Step 1: Access System Settings

Navigate to the Settings page in the main Menu.

Step 2: Enable DeviceCore Sharing

In the Devicecore Sharing section:

SettingDescription
EnableToggle on to allow remote access to device cores
Advanced ConfigAccess detailed sharing permissions
DeviceCore Sharing settings
DeviceCore Sharing configuration with Enable toggle and Advanced Config link

Step 3: Configure Access Permissions (Optional)

Click Advanced Config to manage which cores are shared and authentication settings:

  • Define which specific device cores can be accessed remotely
  • Set up authentication requirements for each core
  • Control access on a per-core basis
DeviceCore Sharing Advanced Config
Advanced Config showing access mode and per-core permissions

Tip

By default, all device cores on the hosting Blue Pill become available when sharing is enabled. Use Advanced Config to restrict access if needed.

Connecting to Shared Device Cores

Once sharing is enabled on the hosting Blue Pill, you can connect from another Reactor instance.

Step 1: Add a Shared Device

On your main Reactor instance:

  1. Go to the Home page
  2. Click Add Device in the Devices section
  3. Search for Shared Core (not the specific device core name)
image

Step 2: Select from Discovery

If the hosting Blue Pill is on the same network:

  • Discovered shared cores will appear in the list
  • Select the specific device core you want to connect to
  • Each device connected through that remote core appears individually

Step 3: Manual Configuration (if needed)

If auto-discovery doesn't find the remote host:

  1. Click Add manually
  2. Select Remote option from the device type list
  3. Enter the IP address of the hosting Blue Pill
image

Warning

When searching for shared cores in "Add manually" use the "Remote" option and enter the IP of the remote Blue Pill device.

Step 4: Configure Core Details

After adding the shared core, access its settings to configure:

SettingDescription
AddressIP address of the remote Blue Pill hosting the core
EncryptionEnable TLS encryption for secure communication

Network Considerations

Default Port

Device Core Sharing uses port 8502 by default. Ensure this port is accessible between devices.

Encryption

For cores shared across untrusted networks (internet, shared infrastructure):

  • Enable the Encryption option on the shared core connection
  • This enables TLS for the gRPC communication channel
  • Recommended for any deployment outside a trusted local network

Firewall Configuration

If you have firewalls between devices:

  • Allow TCP port 8502 (or your configured port)
  • For encrypted connections, standard TLS traffic rules apply

Understanding Shared Core Behavior

Configuration Source

When using a shared core:

  • Device configuration is typically managed on the hosting Blue Pill
  • Your Reactor instance receives the configuration from the remote core
  • Changes made locally may not persist if the remote configuration takes precedence

Connection Status

Shared cores show connection status in the Home page device list:

  • Connected: Communication with remote core established
  • Disconnected: Unable to reach the remote Blue Pill
  • Error: Configuration or authentication issues

Latency Considerations

While device core sharing adds a network hop, the benefits often outweigh the costs:

  • Device-to-core latency is minimized (local connection)
  • Core-to-Reactor latency is typically acceptable for control operations
  • Visual feedback (tally, status) may have slight delay compared to local cores

Troubleshooting

Shared Core Not Discovered

  • Verify DeviceCore Sharing is enabled on the hosting Blue Pill
  • Check both devices are on the same network or have routing configured
  • Ensure port 8502 is not blocked by firewalls
  • Try manual configuration with the direct IP address

Connection Refused

  • Confirm the hosting Blue Pill is running and accessible
  • Check Advanced Config for access restrictions
  • Verify authentication settings if configured
  • Ensure the device core is actually running on the host

Device Not Responding

  • Check the device connection on the hosting Blue Pill first
  • The device must be working locally before it can be shared
  • Verify network stability between the two Blue Pills

Configuration Not Syncing

  • Shared cores may have their configuration managed remotely
  • Check if Enable Remote Config is set appropriately
  • Review which Blue Pill should be the source of truth for device settings