A connected Silvair project has two layers. Bluetooth NLC devices execute the commissioned lighting behavior inside the building, while a gateway connects selected project data and approved actions to external services. That distinction is more than architecture: it determines what still works during an outage, what data can be trusted for analytics, and what a third-party application can actually do.
What the Silvair Gateway Does—and Does Not Do
A Silvair gateway connects a Bluetooth mesh network commissioned with Silvair tools to the Silvair cloud. It supports connected services such as scheduling, energy and occupancy monitoring, remote monitoring, remote control, and API-based integration. It is not the mandatory path for ordinary local behavior. For an application developer, the Silvair API is the controlled bridge to this connected layer, rather than a replacement for local mesh behavior. Sensors, switches, controllers, and luminaires can exchange local mesh messages after commissioning, so a room can continue to respond to presence, manual control, or daylight logic without a round trip through the cloud. [1]
This distributed arrangement is important in commercial projects. The gateway provides a managed bridge between an assigned set of Areas and external applications; it does not turn the network into a conventional centralized controller. The Silvair cloud is the service environment on the external side of that bridge. The architecture below shows the intended flow. It also explains why a Bluetooth mesh lighting API should be designed around the commissioned topology, not around an assumption of direct internet access to a luminaire. External software reaches the service layer, which reaches the gateway, which communicates with the assigned Bluetooth mesh. It does not directly address every luminaire over the internet.
Figure 1. Connected services extend the local distributed mesh; they do not replace local device communication.
Local Control, Connected Services, and What Happens Offline
The table separates functions that belong to local operation from functions that need the connected layer. It also avoids the common but inaccurate claim that every form of scheduling has the same dependency on a gateway.
| Function | Primary dependency | Behaviour if internet is unavailable |
| Occupancy, daylight and wall control | Commissioned local devices and mesh messages | Continues locally |
| Commissioned local scenes | Local devices and configuration | Continues locally |
| Gateway scheduling | Powered gateway plus downloaded schedule | Can continue for at least one week if the gateway remains powered; a restart while offline can stop it until time is restored |
| In-node scheduling | Configured nodes and a mesh time source | Runs in the devices; no gateway is required once correctly configured |
| Remote monitoring and remote commands | Gateway, connectivity, enabled service and authorization | Unavailable while the connected path is unavailable |
Gateway scheduling versus in-node scheduling
Gateway scheduling is managed remotely and the gateway sends the configured events into the mesh. If the gateway is powered and its internet connection drops, it can continue with previously downloaded scheduling configuration for at least one week. If it is restarted while offline, it can lose its time setting and scheduling may stop until internet connectivity restores the time. In-node scheduling is executed by the devices themselves. It requires a qualifying project version and firmware, a source of time in the mesh, and on-site device reconfiguration when the event configuration changes. [2]
Remote Monitoring and Remote Lighting Control
The monitoring and remote-control services are intended for operational use cases that need current network information or authorized commands. Monitoring can provide low-latency light-level and sensor-status traffic, but not every API result is a live state. Energy and occupancy services use retained, aggregated data for historical analysis. Project configuration, device models, publication settings, the target address, and enabled services determine what is available. [3]
Silvair remote lighting control can use supported mesh messages for on/off control, lightness or level changes, and scene recall. Individual-device control is technically possible when a command is sent to the selected element address, but it should not be presented as the default operating pattern for a large facility. Zone or group addressing is usually more maintainable. A silvair remote lighting control workflow should be specified against the actual commissioned models and scene configuration; an external application does not automatically inherit every action available in a local commissioning app. [3] A properly scoped Silvair remote lighting control integration documents which group or element addresses may receive each supported command.
Silvair API: Services, Data, Conditions and Limits
The Silvair API is a project-enabled integration layer, not a generic public feed. It allows approved software to discover the project topology, work with schedules, obtain calculated energy and occupancy information, and use monitoring or remote control where those services are enabled. A Silvair API implementation should use the published versioned interface contract rather than assume that a legacy example remains supported. The following specification view is deliberately practical rather than a developer tutorial. [3] It helps a Silvair lighting API team distinguish a historical reporting service from a low-latency operational service.
| API or service | What it provides or performs | Typical use | Required conditions | Important limit |
| Project Data API | Projects, Areas, Zones, nodes, commissioned context | Map the installation in a dashboard | Enabled project; authenticated Owner or Manager | Use current topology before addressing zones or nodes |
| Scheduling API | Retrieve, create, modify or delete lighting events | Coordinate facility schedules | Enabled API and valid project context | Gateway and in-node events have different execution requirements |
| Energy Consumption API | Calculated use for project, Area or Zone | Energy reporting and comparison | Energy profile, gateway and monitored configuration | Stored as 15-minute aggregates; it is not automatically meter telemetry |
| Occupancy API | Zone occupancy derived from sensor status | Space-utilization analysis | Enabled service and compatible sensor data | Occupancy is not a people count; data is aggregated |
| Monitoring API | Low-latency light-level and sensor-status traffic | Operations dashboard or diagnostics | Gateway serving the relevant Area | Treat it as current operational traffic, not historical reporting |
| Remote Control API | Supported command messages, including on/off, level and scene operations | Authorized operational actions | Enabled service, valid topology and supported target/model | Action availability depends on configured capabilities and address |
A concrete access flow
A typical integration path is: commission the project; add a compatible, connected gateway; accept the Gateway and Services terms; ask Silvair to enable API access for the project; confirm that the user has an Owner or Manager role; authenticate to obtain a token; retrieve the Project ID and topology; then use the applicable service. The token and permissions are part of the integration design, not an afterthought. This Silvair API sequence also provides an auditable handoff between a project owner and the application team. API versions can change, and older interfaces may be deprecated or removed. Integrators should verify the current OpenAPI documentation before using an endpoint or copying an older tutorial. [3]
Energy and Occupancy Data: What the Numbers Mean
Energy Monitoring should be described as calculated energy consumption unless a separate metering arrangement has been designed. Silvair energy use is calculated from an Energy Profile, measured luminaire power values defined during setup, and the light level reported over time. It should not be described as a default real-time meter reading from every driver. The profile represents a luminaire type across defined light levels; a zone should contain luminaires of the same type for this calculation. [4]
Energy can be viewed at project, Area, Zone and, in service-specific reporting, luminaire/device-related levels. The API retains energy data as 15-minute aggregates for up to 24 months. Occupancy is likewise sensor-status-derived rather than a precise headcount: it is recorded per zone and aggregated in 15-minute periods, with a shorter retention period stated in the API documentation. A Bluetooth mesh lighting API therefore supports both operational signals and analytical series, but they should not be conflated. This distinction is particularly important when a Silvair lighting API is used in sustainability reporting.
Connectivity failure and data continuity
When connectivity fails, local control can remain functional, but remote commands and remote visibility cannot traverse the connected path. The gateway does not cache occupancy data for later upload, so occupancy records may be missing during the interruption. Energy monitoring also does not store unsent records in the gateway; for short gaps of up to 45 minutes, the energy method may interpolate data, while longer outages reduce continuity. The data-quality implication is clear: dashboards should expose completeness or gap conditions rather than quietly treating all historical intervals as equally observed. [4] A Bluetooth mesh lighting API dashboard can then present live observations separately from aggregated history.
Gateway Hardware and Network Requirements
For the SGW-102 Silvair Gateway, the published guide identifies a 4.5–5.5 V DC, 2 A supply or Power over Ethernet at 36–57 V DC under IEEE 802.3af, plus one RJ45 10/100 Ethernet port. The enclosure dimensions are 127 × 127 × 30 mm. The guide specifies wall or surface mounting, positioning as near as practical to the geometric center of the lighting network and away from likely interference sources. Its stated ambient operating range is 32–140°F (0–60°C). [1]
The same guide documents Ethernet using DHCP or a static IP, Wi-Fi with WPA2-PSK using DHCP or a static IP, and cellular options only for specified Cascade-500 variants. The Silvair cloud connection should be planned with the building network team before hardware is installed. Certified-country availability, radio arrangements, and connectivity options can vary by supplied hardware; project teams should verify the current SGW-102 guide and the actual partner gateway data sheet rather than assuming every gateway has identical certification or cellular capability. [1]
Deployment Planning: A Practical Checklist
Use the following checks before treating a gateway as a simple add-on:
- Define the project and Area structure, then identify which Areas each gateway will serve.
- Confirm that the gateway has a direct wireless connection to at least one device in every Area it serves, and that assigned Areas can communicate with each other.
- Count devices across all Areas served by that gateway—not 200 devices per Area. A single gateway handles approximately 200 Bluetooth mesh devices across its served Areas; exceeding that planning reference can make energy and occupancy data inaccurate. [1][4]
- Assess sensor message frequency, device density, building materials, interference sources, power and internet availability, and the connected services required.
- Plan multiple gateways where topology, separation, service coverage or total served devices justify them; validate the design with site testing.
This is why “one gateway per floor” is not a sound universal rule. The actual wireless relationship and service load matter more than floor area alone.
Third-Party Integration and the Boundary with BACnet
A silvair lighting API can make lighting and occupancy information useful outside the lighting application. For example, the Silvair API can pass approved zone context into a facilities workflow without disclosing control privileges more broadly than needed. Consider a commercial office: a zone sensor produces occupancy status; connected services expose the approved data through the API; a space-utilization or HVAC platform consumes that status; and that external platform applies its own business rules. This is an integration workflow, not a promise that Silvair automatically supplies complete HVAC control.
A remote bluetooth lighting management deployment may also show selected light status on a facilities dashboard, synchronize schedules with wider operations, or make an authorized zone action available to a service team. A lighting control API is the layer that makes such approved software workflows possible; it does not prescribe the application’s own business logic. For custom cloud-connected software that needs project data, monitoring, and remote control, the API is the relevant path. For a BMS that needs BACnet protocol objects, the Silvair BACnet Gateway is the relevant path. BACnet object mapping, PICS, and BACnet/IP design belong in the dedicated “Silvair BACnet Gateway and BMS Integration” article, not here.
Security and Operational Ownership
API access should be managed as part of the building’s connected-system governance. A lighting control API should receive the same ownership, change-control, and credential-management attention as any other building integration. Store credentials securely, use the smallest practical set of permissions, maintain an inventory of authorized third-party applications, revoke access when an integration or contractor relationship ends, and include account ownership in project handover. Network and application access controls still need to be assessed by the building’s IT and security stakeholders. API access does not replace that assessment.
FY LIGHTING Silvair-Compatible Lighting Solutions
FY LIGHTING can support project teams with commercial luminaires, controller or driver integration options, OEM/ODM development, and project-oriented selection support. Compatibility must be confirmed for the exact luminaire, driver, controller, Silvair component, gateway arrangement, and service scope proposed for the project. A Silvair-compatible luminaire does not by itself mean that the luminaire contains a gateway or independently provides API access.
FAQ
Does Silvair Gateway scheduling work without internet?
If the gateway remains powered, previously downloaded gateway schedules can continue for at least one week while internet access is down. If the gateway restarts while offline, it can lose time and scheduling may stop until it reconnects. In-node scheduling is different: it is run by qualifying devices and does not require a gateway once correctly configured. [2] The Silvair API can manage supported scheduling records, but it does not remove the execution conditions of either scheduling method.
What happens to occupancy data when the gateway is offline?
The gateway does not cache occupancy data for later upload. Occupancy records can therefore be missing during the interruption. The data represents zone occupancy derived from sensor status, not an exact people count.
Does Silvair API provide measured or calculated energy data?
The Energy Consumption API provides calculated energy consumption based on the configured Energy Profile and monitored light levels over time. It should not be assumed to be a live electrical meter reading for every luminaire.
How many gateways are needed for 500 devices?
Start by mapping Areas, direct gateway-to-device wireless connections, topology, device density, traffic, and required services. Because approximately 200 devices is a planning reference across all Areas served by one gateway, a 500-device design normally requires multiple gateways, but the final count must be verified on the project design and site test. A Bluetooth mesh lighting API integration does not eliminate the need to prove the underlying radio design on site.
Can Silvair API control individual lights and scenes?
The API documentation includes supported messages for on/off, level/lightness, and scene operations, and commands can be directed to an individual element address. Whether an action is suitable and available depends on the configured model, target address, scene configuration, gateway Area coverage, and enabled service. [3] This is why a Silvair remote lighting control design should be reviewed against the commissioned project, not only a marketing capability list.
What permissions are required to access Silvair APIs?
API access is enabled per project by Silvair. The installation needs a connected compatible gateway, and the user must have an Owner or Manager role. The integration obtains an authentication token before using the relevant API. [3] A Silvair lighting API integration should keep that token and its associated account under the project owner’s access-management process.
Can a third-party BMS use Silvair API instead of BACnet?
Use the API for custom cloud-connected software integration with project data, monitoring, and remote control. This is the role of a lighting control API in a custom integration. Use the BACnet Gateway when a project needs BACnet protocol objects for BMS integration. They solve related but different integration requirements. A lighting control API is therefore not a BACnet protocol replacement.
Is remote bluetooth lighting management available in every project?
No. Remote bluetooth lighting management depends on a commissioned project, a compatible connected gateway, enabled services, appropriate permissions, and the supported capabilities of the configured devices. It also depends on the Silvair cloud path remaining available for the external service. It should be defined during the project design rather than assumed after installation. The remote bluetooth lighting management scope should identify its users, permissible actions, and required service continuity.
Technical References
[1] SGW-102 Silvair Gateway User Guide, rev. 5.5, 2 October 2025: https://documents.silvair.com/SGW-102_Silvair_Gateway_user_guide.pdf
[2] SN-201 Silvair Scheduling Application Note, rev. 5.7, 25 September 2025: https://documents.silvair.com/SN-201_Silvair_Scheduling.pdf
[3] SN-221 Silvair APIs Application Note, rev. 2.13, 5 March 2026; current API documentation: https://api.platform-prod.silvair.com/docs/public/
[4] SN-222 Silvair Energy Monitoring Application Note, rev. 5.0, 19 March 2026: https://documents.silvair.com/SN-222_Silvair_Energy_Monitoring.pdf
[5] SN-218 Silvair Occupancy Monitoring and SN-213 Recommendations for Complex Lighting Installations: consult the current Silvair Product Documents library: https://www.documents.silvair.com/support/product-documents
Technical references checked: 7 September 2026.
English