Silvair HVAC Integration with Bluetooth NLC

Definition, Release Status, and System Architecture

The Bluetooth SIG published a draft HVAC Integration NLC Profile in March 2025. On July 8, 2025, the Bluetooth SIG adopted HVAC Integration NLC Profile 1.0 and opened the associated qualification path. Silvair announced on the same day that it had delivered a qualified solution compliant with the new specification. This distinguishes a qualified Silvair firmware or solution from a specific thermostat that is already commercially available: product availability must be confirmed with Silvair or the thermostat manufacturer.

Silvair HVAC integration is therefore a standards-based lighting-to-HVAC occupancy link. Bluetooth NLC HVAC integration is the profile-based form of that lighting-to-HVAC occupancy sharing. It allows a thermostat acting in the HVAC Integration NLC Profile role to subscribe to occupancy information from a sensor in a Bluetooth Mesh system. It does not give Silvair direct control of AHUs, VAV boxes, chillers, boilers, or every other HVAC asset.

Technical architecture: data path and optional services

Bluetooth NLC Occupancy Sensor  →  Bluetooth Mesh  →  Compatible Thermostat
↓
HVAC controller / equipment

Optional branch: Bluetooth Mesh / Silvair gateway  →  connected services or BMS
(not required solely for local occupancy sharing)

Bluetooth NLC carries occupancy information from the sensor to the thermostat. The thermostat may use a wired or other manufacturer-defined interface to its HVAC controller or equipment. The exact interface—BACnet, Modbus, 0–10 V, relay, or another method—must come from the thermostat data sheet; it must not be inferred from Bluetooth support.

How Silvair Enables HVAC Integration

In a real silvair HVAC integration project, Silvair contributes a qualified firmware and commissioning ecosystem for manufacturers and integrators working with Bluetooth NLC commercial lighting. Its value is the relationship between an existing NLC lighting network, qualified device roles, and a common commissioning environment. The Bluetooth SIG defines the profile; Silvair should not be credited with every capability of the underlying Bluetooth standard.

For a device manufacturer, the qualified Silvair solution can support development and integration of lighting products, occupancy sensors, and HVAC-related thermostat products within the same standards-based ecosystem. For an integrator, the benefit is a shared project context for device provisioning, zone mapping, diagnostics, and acceptance testing. No specific SDK, hardware model, or firmware version should be assumed without the current Silvair technical documentation.

Profile Roles and Compatibility: What Must Be Verified

Bluetooth radio capability, Bluetooth Mesh capability, Bluetooth NLC profile support, product qualification, and Silvair firmware compatibility are separate layers. A Bluetooth or Mesh logo alone does not prove interoperability. A thermostat needs an appropriate HVAC Integration NLC Profile implementation, while the sensor needs the relevant Occupancy Sensor NLC Profile implementation.

Before specifying silvair HVAC integration, request the current product evidence. Because no public, current product list was supplied with the brief, this article does not invent thermostat models, Bluetooth Qualification IDs, or firmware numbers. Request the actual compatibility matrix from Silvair and the thermostat manufacturer before the equipment schedule is approved.

Occupancy Data, Delays, and Multi-Sensor Rules

An occupancy sensor does not automatically report a live headcount or a person’s location. It detects conditions through its own sensing method, delay timers, and state logic, then publishes the states and values supported by its product implementation. A thermostat applies its own delays and control rules after receiving that information. Confirm the selected sensor’s states, timeouts, and configurable parameters in its documentation.

When several sensors serve one HVAC area, the key question is how their states are combined. For example, one sensor may report occupancy while another reports vacancy. The correct result could be an occupied zone, a retained state, or a product-specific combined value—but the profile alone should not be treated as a mandatory “any sensor means occupied” rule. The selected Silvair firmware, sensor implementation, thermostat, and commissioning design must identify which device performs the merge and how vacancy delay is applied.

Zone Mapping: An Illustrative Engineering Example

Illustrative mapping: three meeting rooms and one open office

Meeting Room A: sensors A1/A2 → lighting zone A → thermostat T1 → HVAC zone 1
Meeting Room B: sensor B1    → lighting zone B → thermostat T2 → HVAC zone 2
Meeting Room C: sensor C1    → lighting zone C → thermostat T3 → HVAC zone 3
Open Office: sensors O1/O2/O3 → lighting zones O1/O2/O3 → thermostat T4 → HVAC zone 4

This example shows why a lighting zone is not automatically an HVAC zone. The open office has several sensing and lighting areas but one physical HVAC zone. Software can share occupancy with T4, but it cannot create independent temperature control for O1, O2, and O3 if the mechanical system cannot do so. A zone plan should be approved jointly by the lighting integrator, HVAC contractor, and building systems integrator.

The same principle applies to “responsive zoning.” Lighting-to-HVAC occupancy sharing improves the information available inside an existing zone; it does not redraw the mechanical system. Occupancy data can enable occupancy-aware control within existing HVAC zones; it cannot change ductwork, VAV capacity, fan-coil boundaries, or the thermostat’s physical outputs.

Control Boundaries, Comfort, and Failure Handling

A thermostat may use occupancy for occupied settings, an unoccupied setback, recovery, or another configured strategy. It should not be described as “turning off HVAC immediately” whenever a sensor becomes vacant. Thermal inertia, equipment protection, required ventilation, short absences, and comfort targets all affect the correct delay and recovery behavior.

If occupancy data is lost, a sensor goes offline, communication stops, or a state is not updated for an extended period, the safe response is product-specific. A thermostat may retain the last state, fall back to a schedule, use a default mode, or apply another documented strategy. None of these should be presented as the universal Silvair default. Test the selected behavior during commissioning. Loss of Bluetooth communication is also not automatically the same event as loss of normal power; the physical HVAC design determines what happens in each case.

Commissioning and Acceptance Workflow

A useful commissioning process has clear owners and evidence rather than a single instruction to “test on site.”

• Lighting integrator: confirm device qualification, firmware, addresses, sensor placement, Bluetooth Mesh coverage, and lighting/HVAC zone table.
• HVAC contractor: confirm thermostat model, HVAC Integration NLC Profile support, HVAC-side interface, control limits, schedules, setbacks, recovery, and failure behavior.
• Building systems integrator: confirm any gateway or BMS branch, network conditions, data ownership, and project acceptance criteria.
• Joint team: configure sensor-to-thermostat relationships, verify occupied and vacant transitions, test vacancy and recovery delays, simulate communication loss, and record the final response.

A defensible silvair HVAC integration handover includes a repeatable acceptance sequence. The acceptance sequence should be: confirm qualification and firmware; establish the zone map; document the lighting-to-HVAC occupancy sharing path; provision and associate devices; verify the published occupancy state; test occupied and unoccupied delays; verify the thermostat response; test a communication-failure case; and archive the results. A lighting response alone does not prove that the HVAC mapping is correct.

Commissioning record checklist

• Sensor and thermostat manufacturer, model, device identifier, qualification evidence, and firmware;
• Sensor states, delay settings, thermostat setpoints, schedules, and failure strategy;
• Lighting zone to HVAC zone mapping and the person responsible for approval;
• Test date, test result, observed response, exceptions, corrective action, and retest evidence.

Network Quality and Retrofit Considerations

Reliable HVAC occupancy sharing depends on device placement, wireless coverage, building materials, metal partitions, and interference from dense mechanical or electrical areas. Large buildings should validate the actual communication path on site. Detailed node planning, hop count, capacity, and radio design belong in a dedicated Silvair Bluetooth Mesh Network Planning guide rather than being repeated here.

For a retrofit silvair HVAC integration assessment, ask whether the existing Silvair Bluetooth Mesh network can support HVAC Integration NLC through a firmware update, whether existing sensors implement the required profile, whether network and commissioning data can be retained, and whether hardware replacement is necessary. These answers are manufacturer-specific. Do not promise that every installed Silvair project can be upgraded by software alone.

Gateway, Connected Services, and BACnet/BMS Boundaries

Local occupancy sharing between compliant Bluetooth Mesh devices does not require an additional cloud gateway solely for that exchange. This does not mean an entire HVAC project needs no gateway, nor does it mean every Silvair function is available offline. Remote services, analytics, remote management, and BMS data exchange may require separate infrastructure.

BACnet/BMS integration is not a more powerful version of the HVAC Integration NLC Profile. It is a different architecture with different data points, gateways, and control responsibilities. Verify the current Silvair gateway documentation for the actual BACnet objects and values; never assume it exposes every HVAC point or can directly command any HVAC asset.

Energy Measurement, Applications, and Limitations

Occupancy-aware HVAC control may reduce conditioning during periods when rooms are unused, but the result must be measured. Compare before-and-after HVAC runtime, occupied hours, setpoint changes, and energy or BMS data under similar operating conditions. Account for weather, business hours, occupancy rate, and seasonal changes. Do not combine lighting savings, HVAC savings, and whole-building savings into one unsupported claim.

Comfort and energy are a control trade-off. Vacancy delay, setback depth, recovery time, and frequent occupancy changes should be selected for the building’s thermal response and equipment type. Necessary ventilation, equipment protection, and safety requirements must remain in force.

Where the approach fits

Private offices and meeting rooms are useful where real occupancy differs from calendars and existing lighting sensors can be reused. Classrooms can benefit from schedule changes and after-hours use if the thermostat can apply the required strategy. Retail and shared amenity spaces may benefit during low-traffic periods. In each case, confirm the thermostat capability and physical zone limits.

When it is not a good fit

Consider another architecture when the thermostat does not support the profile, the HVAC plant cannot control the target zone independently, sensor coverage is inadequate, profile or firmware evidence is unavailable, or the project requires complex BMS-level sequences rather than occupancy sharing. Do not force Bluetooth NLC HVAC integration into a system that cannot verify these prerequisites.

Silvair HVAC Integration vs BACnet/BMS Integration

The two approaches can coexist, but they answer different project needs. Silvair HVAC integration is a focused occupancy-sharing path, while BMS integration has a broader interface scope. Local profile-based occupancy sharing is a narrow path from sensor to thermostat. BACnet/BMS is a broader building-system interface whose actual objects and commands must be verified.

Silvair-Compatible Lighting Solutions from FY LIGHTING

FY LIGHTING can support project evaluation around commercial luminaires, occupancy-sensor integration, controller installation space, wiring, OEM/ODM requirements, and project-specific lighting configurations. The practical next step is a compatibility review of the proposed luminaire, driver, sensor, controller, firmware, and thermostat combination. FY LIGHTING should not be presented as the supplier of a certified HVAC thermostat unless the relevant product and evidence are confirmed. Silvair profile support, controller compatibility, and any required certification remain model-specific.

Purchase Checklist: Five Questions to Ask Before Ordering

• Does the selected sensor implement the required Occupancy Sensor NLC Profile?
• Does the selected thermostat implement HVAC Integration NLC Profile 1.0 or the applicable current version?
• Do the exact firmware releases and qualification records match the proposed combination?
• Can the existing HVAC zone deliver the desired occupancy-aware strategy without implying new physical zoning?
• Have the lighting integrator, HVAC contractor, and systems integrator agreed who owns commissioning, failure testing, and acceptance?

For a quotation or compatibility review, provide the project country and applicable requirements, floor plan, luminaire and sensor models, thermostat model, normal and HVAC power architecture, firmware information, network conditions, and whether remote monitoring or BMS integration is required.

FAQ

Which thermostats are compatible?

Compatibility is product-specific. Request the current Silvair or manufacturer matrix showing the model, HVAC Integration NLC Profile version, qualification evidence, firmware, HVAC-side interface, and commercial status. No model should be inferred from a Bluetooth logo.

Can an existing Silvair lighting network be upgraded?

Possibly, but it requires confirmation of sensor profile support, controller and firmware compatibility, retained project data, and any hardware replacement or recommissioning. It is not a universal software-only upgrade.

Does local occupancy sharing require a gateway?

Not for the basic exchange between compliant Bluetooth Mesh sensors and a compatible thermostat. Remote services and BMS architectures may require their own gateway and network conditions.

How do multiple sensors map to one HVAC zone?

The mapping and state-merge rule depend on the selected sensor, Silvair firmware, thermostat, and commissioning design. Document which device combines states and how vacancy delay is applied.

Can the profile directly control an AHU or VAV box?

No. It shares occupancy with the thermostat. The thermostat and the HVAC controller determine what equipment can be controlled through their documented interfaces.

What happens if Bluetooth communication fails?

The result is product-specific: the thermostat may retain a state, revert to a schedule, or use a default mode. Test and record the actual behavior; do not treat communication loss as identical to power failure.

How is energy performance verified?

Compare measured runtime, occupancy, setpoints, and energy or BMS data before and after implementation under comparable weather and operating conditions.

What should be checked for a retrofit?

Confirm sensor and thermostat profiles, firmware, qualification, network coverage, existing zone mapping, project-data reuse, and whether hardware or recommissioning is required.

Can FY LIGHTING provide a compatible solution?

FY LIGHTING can conduct a model-specific compatibility assessment and support commercial lighting or OEM/ODM project coordination. The final Silvair, sensor, thermostat, firmware, and certification combination must be verified from technical documents.

What is the difference between Bluetooth NLC HVAC and BACnet integration?

Bluetooth NLC HVAC integration shares occupancy from a qualified sensor to a compatible thermostat. Bluetooth NLC HVAC integration remains a focused local profile path, while BACnet integration is a separate building-system interface with its own gateway, objects, commands, and limitations.

Technical References

Bluetooth SIG, “HVAC Integration NLC Profile 1.0 Adopted,” https://www.bluetooth.com/specifications/specs/hvac-integration-nlc-profile/ (accessed September 9, 2026). Supports the profile version, wall-thermostat role, qualification documents, and adopted status.

Silvair, “HVAC Control,” https://silvair.com/solutions/hvac-control/ (accessed September 9, 2026). Supports Silvair’s stated solution positioning and the relationship between lighting occupancy data and HVAC integration; product availability remains manufacturer-specific.

Silvair, “Silvair Delivers the First Qualified Bluetooth NLC Solution for HVAC Applications,” https://silvair.com/blog/silvair-delivers-first-qualified-bluetooth-nlc-solution-hvac-applications/ (accessed September 9, 2026). Supports the July 2025 qualification announcement.

Silvair, “Bluetooth NLC Expands into HVAC Control,” https://silvair.com/blog/bluetooth-nlc-expands-hvac-control/ (accessed September 9, 2026). Supports the development and profile context; current product claims must be checked against current manufacturer documents.

For any model, firmware, Bluetooth Qualification ID, interface, or availability claim, attach the current manufacturer data sheet, qualification record, and Silvair compatibility confirmation to the project submittal.