What the System Does
Bluetooth Mesh allows qualified nodes to exchange messages through a wireless mesh. Bluetooth NLC adds lighting-specific models and interoperable control behavior. A Silvair project may use compatible luminaires, sensor-controllers, light sensors, switches, gateways and drivers, but “Bluetooth Mesh supported” should never be treated as proof that every Silvair function is available. Confirm device documentation, firmware and qualification before specifying a control feature.
The system can coordinate a reduced background level with higher output when activity is detected, influence neighboring zones, adapt daylight-exposed entrances, run local or gateway-based schedules, and provide connected-service data where configured. The right result is not maximum automation; it is predictable lighting behavior that fits the garage’s traffic and safety requirements. That is the practical purpose of silvair parking garage lighting control.
Silvair and an independent sensor light
| Capability | Independent sensor light | Silvair-based control |
| Detection response | Usually local to one fixture or small group | Can coordinate multiple configured zones |
| Zone linking | Limited or unavailable | Uni- or bi-directional relationships can be configured within the same Area |
| Photocell combination | Depends on fixture/controller | Can be combined with occupancy scenarios when supported |
| Scheduling | Often a simple timer | In-node and gateway scheduling options depend on version and configuration |
| Management | Local adjustment | Commissioning, remote management or BMS integration may be available through project services |
Garage Zone Planning
A parking level should not normally be one control zone. Silvair parking garage lighting control begins with this planning decision. Silvair defines Zone as a group used for control logic, Area as a Silvair project-configuration and network-planning boundary, and Project as the overall organization level. A Zone is not automatically an independent mesh network. Zone linking does not operate directly across different Areas, so Area boundaries must support both communication and the relationships the design needs.
| Garage area | Recommended control logic | Sensor considerations | Linking / risk to verify |
| Drive lanes | Progressive high/low response in short travel sections | Direction, speed, overlapping detection and false triggers | Pre-light the next section; verify end-of-lane communication |
| Parking rows | Reduced level until activity is detected | Coverage between parked vehicles and pedestrian movement | Link to circulation lane where useful; avoid lighting a full floor |
| Entry / exit | Day/night logic plus occupancy | Outdoor light, headlights and transition contrast | Coordinate first internal zone; verify thresholds and delay |
| Ramps / turns | Occupancy with forward-zone linking | Vehicle approach direction, concrete and level changes | Link landings; never assume unoccupied means safe to switch off |
| Stairs / elevator lobbies | Pedestrian-oriented profile | PIR, microwave or other sensor suitability | Link to walking path; verify missed detection and manual override |
For a multi-level garage, decide whether each floor, section or connected group should be an Area. This is a central silvair parking garage lighting control decision. The practical guideline of approximately 200 devices or fewer per complex Area appears in Silvair support material; use it as a planning recommendation for the applicable version, not as a product capacity limit. It is one of the checks required before silvair parking garage lighting control is expanded across multiple floors. Topology, message traffic, device types and required links still determine the final layout.
Occupancy and High/Low Dimming
Occupancy-based garage lighting reacts to motion or occupancy information; it does not automatically identify a vehicle. In silvair parking garage lighting control, a sensor event is a control input, not a vehicle identity. PIR, microwave and other technologies have different behavior. Selection should consider vehicle speed, approach direction, metal vehicles, concrete obstruction, pedestrian detection, mounting position and false-trigger sources. Detection distance and vehicle classification must come from the specific sensor datasheet.
Illustrative control sequence
The following is an illustrative project example, not a fixed Silvair three-state template: an occupied state raises the zone to its configured active level; after detection stops, an extension or hold period may maintain that response; a standby or vacant state then reduces output or switches off if the approved project design permits. The scene’s actual names, triggers, durations and levels must be confirmed in the controller and commissioning documentation.
Do not copy universal percentages or timeouts. Drive lanes, parking bays, ramps and pedestrian areas may need different occupied, standby, vacant, fade-time and high-end-trim settings. This keeps parking garage occupancy lighting aligned with the actual project. Minimum maintained lighting, uniformity, emergency lighting and egress requirements are not guaranteed by the platform. A ramp, turn, walkway or entrance cannot be assumed safe to turn off simply because occupancy is absent.
Can parking garage lights dim to off? Sometimes, where the controller, driver, scene and project requirements support it. Dim-to-off is not the same as removing power, and it must not conflict with safety or emergency requirements.
Zone Linking Along Travel Paths
Does Silvair zone linking work across Areas? No. The linked zones must belong to the same Area. Zone linking is a control relationship, not vehicle tracking. A trigger zone, linked zone and their output levels can be configured independently, subject to the supported scene and project design; unlimited cascading should not be assumed.
| Event | Trigger zone | Associated zone | Recovery |
| Vehicle or person enters B | B rises to active level | A and/or C rise to a linked-zone level | Each zone follows its configured hold, fade and return behavior |
| Activity enters a ramp | Ramp uses active profile | Landing before/after can pre-light | Verify communication across slabs and level transitions |
| Lobby activity | Lobby uses pedestrian profile | Path zone can respond | Check missed detection and manual override |
A→B→C→D is therefore a pool-of-light example: B is active, A/C may be linked, and D can remain at standby. The same principle is useful in bluetooth mesh parking garage lighting, especially where wireless parking garage lighting control must preserve forward visibility. Select link direction, level and reach from actual traffic. Over-linking can illuminate too much of the garage.
Entrance Photocell Control
Ordinary photocell control generally increases electric-light output as ambient conditions become darker, using separate Day and Night thresholds and a transition delay to avoid switching from headlights or reflections. In bluetooth NLC garage lighting, this logic is kept separate from reversed photocell behavior. That separation also helps parking garage occupancy lighting respond consistently when daylight changes. It can be combined with occupancy: daytime/no occupancy may use a lower level, while occupancy raises the active level; nighttime can use a different standby level.
Reversed photocell is different. It can support visual adaptation at entrances and exits by allowing a higher electric-light level during bright daytime conditions and a lower level at night. It is not simply “day on, night off”; the final output still depends on the scenario, occupancy logic and safety design. Silvair’s SN-215 Photocell document describes this entrance/exit use case.
Scheduling and Gateway Decisions
Is a gateway required for basic parking garage control? Usually not for local occupancy behavior or in-node scheduling, subject to the specific version and device configuration. In-node schedules execute in the nodes, but time synchronization and behavior after a power or clock event must be verified. Gateway services can support remote modification, broader management and gateway scheduling, including astronomical timing where supported. A gateway is not automatically required for every schedule, nor is it irrelevant to every service.
| Function | Gateway status | Typical use | Important limitation |
| Local occupancy control | Often not required | Immediate zone response | Depends on compatible nodes and local configuration |
| Zone linking | Usually local mesh behavior | Progressive travel-path light | Same-Area boundary applies |
| Photocell | Usually local when sensor/scenario supports it | Entrance, exit and daylight-exposed ramp | Thresholds and delay need commissioning |
| In-node scheduling | Not continuously required | Weekday, weekend and overnight profiles | Time synchronization and version behavior matter |
| Remote / gateway scheduling | Required for the connected service | Remote changes or astronomical schedules | Requires gateway, service and network connection |
| Energy Monitoring | Requires Gateway and service configuration | Estimated energy comparison by zone/Area | Not utility-grade metering |
Retrofit Compatibility: 0–10V and Power
A possible architecture is sensor-controller or controller → 0–10V signal → compatible LED driver → luminaire. Verify the interface type, dimming curve, minimum dim level, dim-to-off behavior, shutdown method, controller supply, relay requirement, polarity and the permitted number of drivers or loads. A 0V command, a driver’s minimum output and true power disconnection are not interchangeable.
Retain existing mains wiring only after checking the control circuit. wireless parking garage lighting control is retrofit-friendly only when the power and control architecture are suitable. A permanently powered node may be required to receive commands, sense occupancy and relay mesh messages. If a wall switch or breaker removes node power, the device may lose those functions. Review switched circuits, controller supply, emergency circuits and maintenance isolation together. A retrofit is suitable when drivers are compatible or can be replaced, network paths can be verified and the owner accepts the control strategy. It is not a direct fit for every non-dimmable driver or special control system. A compatibility review is essential for wireless parking garage lighting control. It is also a prerequisite for smart parking garage lighting when existing drivers are retained. For bluetooth NLC garage lighting, the selected controller and driver must be checked as a pair.
Mesh Planning and Commissioning
Underground garages include slabs, columns, parked vehicles, elevator cores, ramps and long lanes. Do not promise coverage from a fixed Bluetooth distance. bluetooth mesh parking garage lighting requires an on-site network review. Relay-capable, continuously powered nodes and low-power devices may have different relay behavior; the exact role is device-specific. In bluetooth mesh parking garage lighting, this distinction affects how long lanes and ramps are validated. Review communication quality, message traffic and relay distribution instead of assuming every node forwards messages equally.
Test a pilot Area, then record the results before expanding. Silvair’s approximately 200-device planning figure is a practical recommendation, not a hard project limit. Area size depends on topology, traffic, device type and link needs.
| Acceptance test | Method | Expected result | Record |
| Vehicle / pedestrian entry | Approach each sensor path | Correct active zone and intended linked response | Sensor, direction, scene |
| Hold and recovery | Wait through configured extension and return | Predictable fade/standby behavior | Configured values and observed times |
| Night photocell | Test verified day/night conditions or approved simulation | Correct ordinary or reversed behavior | Threshold, delay, output |
| Ramp and obstruction | Test across floors, columns and lane ends | Commands and links reach intended zones | Location and communication result |
| Network / gateway loss | Use approved test procedure | Documented configured behavior, no unverified fail-safe claim | Node state, recovery, manual action |
| Manual / maintenance override | Apply and release override | Expected maintenance behavior restored | Procedure and responsible party |
Failure, Emergency and Energy Boundaries
Sensor failure, mesh interruption, gateway offline status, a single node losing power, manual override and maintenance mode must be tested against the actual controller, driver and scene configuration. This article does not claim a default safe-failure mode. The project must define how required light is maintained when data or communication is unavailable. This boundary belongs in every silvair parking garage lighting control specification and every smart parking garage lighting commissioning plan.
Ordinary parking-light control does not replace a compliant emergency-lighting system. Emergency circuits, outage response, bypasses and emergency drivers require the specific hardware, certification and local requirements. See Silvair’s separate Emergency Lighting / UL 924 material rather than treating this article as an emergency-lighting specification.
Silvair Energy Monitoring is estimated lighting energy: it uses a luminaire energy profile and recorded light level. It is not necessarily a driver measurement, external meter reading or revenue-grade measurement. Use it to compare zones and operating strategies, but do not promise a savings percentage without project data. That is how smart parking garage lighting should be evaluated.
Project Inputs and FY Lighting Evaluation
| Input to share | Why it matters |
| Parking levels, plan and zones | Determines Areas, links and sensor coverage |
| Luminaire count and model | Defines control-device and network scope |
| Driver model and interface | Confirms 0–10V or other compatibility |
| Operating hours and traffic profile | Sets scenes, standby and schedules |
| Daylight entrances and emergency circuits | Separates photocell and life-safety requirements |
| BMS / remote-management need | Determines gateway and integration review |
For Silvair-compatible projects, FY Lighting can provide parking-garage LED luminaires, evaluate 0–10V driver options, review controller integration and support project customization. Its team can assess smart parking garage lighting requirements without assuming unverified compatibility. Only models that have completed the required compatibility or qualification review should be described as Silvair-compatible or Bluetooth NLC-qualified; other products should be treated as available for compatibility evaluation.
Share Your Garage Project Requirements
For a reliable proposal, share parking levels, fixture quantity, existing driver models, control objectives, floor plans, operating schedule and any BMS or remote-management requirement. The FY engineering team can then evaluate the luminaire, controller and network approach rather than promising compatibility before assessment. This process is appropriate for parking garage occupancy lighting and bluetooth mesh parking garage lighting projects alike. It also keeps silvair parking garage lighting control, bluetooth NLC garage lighting and wireless parking garage lighting control tied to verified project requirements.
FAQ
Does Silvair parking garage lighting control require a gateway for occupancy control?
Usually no for local occupancy behavior, when compatible nodes and scenes are configured. This is the normal starting point for parking garage occupancy lighting. A gateway may be needed for remote management, gateway scheduling or Energy Monitoring. This distinction is important in bluetooth NLC garage lighting and should be confirmed before a silvair parking garage lighting control procurement decision. Confirm the exact device and software version, and define behavior during gateway loss.
Can Silvair work with existing 0–10V LED drivers?
It can when the selected controller and driver are electrically compatible. Check interface type, curve, minimum output, dim-to-off, supply, polarity, relay needs and load quantity. A 0–10V label alone does not establish compatibility.
How does zone linking differ from vehicle tracking?
Zone linking causes predefined areas to change lighting when a trigger zone reports activity. It does not identify, locate or follow a vehicle. Direction, linked level and recovery behavior are lighting settings, not a tracking service.
Can parking garage lights dim to off when unoccupied?
Possibly, but only where the driver, controller scene and project requirements support it. Dim-to-off is not the same as cutting node power, and it cannot override maintained-lighting, emergency or egress requirements.
What happens if a sensor or Bluetooth Mesh connection fails?
There is no universal behavior to assume. Test the actual controller, driver and scene configuration for sensor failure, node power loss, communication interruption and recovery. Document the required maintained-lighting and manual-override procedure.
How should a multi-level garage be divided into Areas?
Use communication reliability, device count, traffic relationships, relay paths and required zone linking. Zones that must link should remain in the same Area. Approximately 200 devices or fewer is a practical guideline for complex Areas, not a hard project limit.
Can entrance lighting differ between day and night?
Yes, when the photocell scenario and compatible devices support it. Ordinary logic usually responds to darkness; reversed photocell can provide more transition light by day. Neither strategy is a substitute for the project’s safety and optical design.
Does Silvair Energy Monitoring measure actual electricity consumption?
It generally provides an estimate based on assigned luminaire energy profiles and recorded light levels. It should be distinguished from driver telemetry, an external meter and revenue-grade measurement. Savings claims require project data.
Can emergency lighting remain independent?
Yes, it may need to remain on a separate compliant system. Ordinary dimming control does not automatically satisfy emergency requirements. Review emergency drivers, circuits, bypasses, certification and local rules with the responsible designer.
What information is needed for a Silvair parking garage retrofit?
Provide levels, plans, fixture and driver models, quantities, power circuits, operating hours, sensor goals, emergency-circuit details and BMS or remote-management needs. These inputs allow compatibility, Area and network evaluation.
Can Silvair integrate with a BMS or remote platform?
Integration depends on the gateway, service, API or protocol and the selected project configuration. Treat it as a design review item, not a universal feature of every Bluetooth Mesh device. Confirm the required interface before procurement.
How should occupancy timeouts and standby levels be selected?
Use traffic, pedestrian movement, sensor behavior, safety requirements and owner policy. Set different profiles for lanes, bays, ramps and lobbies when needed. Treat all example values as project parameters subject to commissioning, not universal Silvair defaults.
Official Reference Points
Technical verification should use the current Silvair documentation for the selected version and device. Useful starting points include the Silvair Product Documents library, SN-202 Optimizing Mesh Network Performance, SN-211 Silvair Lighting Control, SN-215 Photocell, the Silvair FAQ, and Silvair Energy Monitoring documentation. Links: https://www.documents.silvair.com/support/product-documents ; https://documents.silvair.com/SN-202_Optimizing_mesh_network_performance.pdf ; https://documents.silvair.com/SN-211_Silvair_Lighting_Control.pdf ; https://documents.silvair.com/SN-215_Photocell.pdf ; https://silvair.com/support/faq/ ; https://silvair.com/solutions/connected-lighting-services/energy-monitoring/
