Skip to documentation content

Overview

System Architecture

Understand the gateway, Casambi interface, local services, and cloud connection.

On this page

Overview

The C-Bridge system architecture is designed around a local edge gateway that connects a Casambi lighting network to cloud services, local network services, APIs, and building automation systems.

The architecture combines local site operation with remote management.

At a high level, C-Bridge includes:

  • C-Bridge hardware gateway.
  • Local Casambi communication interface.
  • Gateway software stack.
  • Local database and services.
  • Cloud portal.
  • APIs and WebSocket services.
  • BACnet/IP and third-party integration layers.
  • OTA update services; backup availability requires confirmation.

Main System Layers

1. Casambi Lighting Network

The Casambi network contains the lighting devices, sensors, switches, groups, scenes, schedules, and control logic.

This layer remains responsible for local lighting behavior.

Examples of Casambi-side objects include:

  • Fixtures.
  • Groups.
  • Scenes.
  • Schedules.
  • Switches.
  • Sensors.
  • Device states.
  • Light levels.
  • Color temperature values.
  • RGBW values.
  • Presence and lux readings.
  • Device online/offline status.

2. C-Bridge Hardware Gateway

The C-Bridge hardware gateway is the physical device installed on-site.

Typical hardware functions include:

  • Raspberry Pi-based compute platform.
  • Custom HAT board.
  • Casambi radio or serial interface.
  • Ethernet connection.
  • Optional Wi-Fi setup.
  • RTC for timekeeping.
  • Status LEDs.
  • Power input.
  • Local storage.
  • Optional cellular backup support.

The gateway is installed on the same site as the Casambi network and connected to the building network through Ethernet or Wi-Fi.

3. Local Gateway Software

The local software stack runs on the C-Bridge gateway.

It is responsible for:

  • Reading data from the Casambi interface.
  • Sending commands to Casambi.
  • Managing local device state.
  • Handling local API requests.
  • Running WebSocket services.
  • Mapping data to BACnet/IP points.
  • Storing logs and events.
  • Managing internet connectivity.
  • Communicating with the cloud portal.
  • Handling OTA updates.
  • Running startup and health checks.

4. Local Database

C-Bridge uses a local database to store site and gateway information.

The database may store:

  • Devices.
  • Device states.
  • Groups.
  • Scenes.
  • Schedules.
  • Energy logs.
  • Events.
  • Gateway status.
  • Configuration.
  • BACnet mappings.
  • Error logs.
  • Sync history.

This local database helps the gateway maintain state and provide local access even when cloud connectivity is interrupted.

5. Cloud Portal

The C-Bridge cloud portal provides remote access to sites, gateways, users, and lighting network data.

The portal can display:

  • Site overview.
  • Gateway status.
  • Device status.
  • Live network data.
  • Events and logs.
  • Floor plans.
  • User permissions.
  • Firmware versions.
  • Integration settings.
  • BACnet configuration.
  • Remote support information.

The cloud portal allows centralized management across multiple installations.

6. API Layer

The API layer provides structured access to C-Bridge data and controls.

APIs may include:

  • Device endpoints.
  • Group endpoints.
  • Scene endpoints.
  • Schedule endpoints.
  • Gateway status endpoints.
  • Energy data endpoints.
  • User and site endpoints.
  • BACnet mapping endpoints.
  • Third-party integration endpoints.

The API layer allows developers and external systems to interact with C-Bridge without needing direct access to the underlying serial or mesh communication layer.

7. WebSocket Layer

The WebSocket layer provides real-time updates.

It can be used for:

  • Live dashboard updates.
  • Real-time device state changes.
  • Gateway health status.
  • Event notifications.
  • Lighting level updates.
  • Connection status.
  • Integration feedback.

WebSockets reduce the need for constant polling and allow the portal or third-party applications to react quickly when something changes.

8. BACnet/IP Integration Layer

The BACnet/IP layer exposes selected Casambi lighting data as BACnet points for building management systems.

This layer can map:

  • Devices.
  • Groups.
  • Scenes.
  • On/off status.
  • Dimming levels.
  • Occupancy values.
  • Fault states.
  • Online/offline status.
  • Energy values.
  • Demand response states.

BACnet/IP allows C-Bridge to communicate with BMS platforms, including systems that cannot communicate with Casambi directly.

9. Cloud Backup and OTA Update Layer

C-Bridge uses over-the-air updates. Cloud backup scope and recovery procedures remain unverified; see Backups & Restore before planning recovery.

This layer helps with:

  • Gateway software updates.
  • Configuration backup.
  • Recovery after failure.
  • Version tracking.
  • Release management.
  • Remote maintenance.

OTA support allows deployed gateways to be updated without physically accessing the device.

Local Gateway Responsibilities

The C-Bridge gateway handles:

  • Casambi communication.
  • Local network communication.
  • API requests.
  • BACnet/IP services.
  • Real-time data handling.
  • Local state storage.
  • Device sync.
  • Health monitoring.

Cloud Responsibilities

The cloud platform handles:

  • Remote gateway access; confirm multi-site dashboard availability for your deployment.
  • User access.
  • Remote management.
  • Long-term visibility.
  • Backup planning, subject to confirmed support for the installed release.
  • Gateway registration.
  • Remote support tools.
  • Software update coordination.

Offline Behavior

C-Bridge is designed around edge gateway behavior.

If internet connectivity is lost, the local Casambi network continues operating normally.

Depending on configuration, the C-Bridge gateway may continue to:

  • Communicate locally with Casambi.
  • Store logs locally.
  • Maintain local API services.
  • Preserve BACnet/IP communication on the local network.
  • Sync data to the cloud once internet is restored.

Security Considerations

C-Bridge architecture should support secure access and controlled permissions.

Security considerations include:

  • Authenticated cloud access.
  • Role-based user permissions.
  • Secure API tokens.
  • Local network restrictions.
  • Firewall coordination.
  • Encrypted cloud communication.
  • Controlled remote access.
  • Secure OTA update process.

Summary

C-Bridge architecture is built around a local edge gateway that connects Casambi lighting networks to cloud dashboards, APIs, WebSocket data, BACnet/IP, and third-party systems.

The system keeps local site functionality close to the lighting network while enabling remote management, integration, data logging, and support.