Quick Answer
Silvair scheduling recalls predefined lighting scenes at selected times and on selected days. It can operate through in-node scheduling, where compatible Bluetooth Mesh devices store and execute up to 16 events locally, or through a Silvair Gateway, which adds centralized management and sunrise/sunset scheduling. In-node operation requires project version 202101 or later, firmware 2.20.2 or later on all devices, accurate network time and 100% Mesh Quality.
Scene definition → Scheduling event → Time source → Scene recall → Lighting behavior
What Is Silvair Scheduling?
Silvair scheduling links a predefined scene to an event. The event specifies the target zone or zones, trigger time, selected days and scene to recall. The event determines when a change occurs, while the recalled scene determines the light level and automatic behavior that apply. In this way, Silvair scheduling is more capable than a basic on/off timer.
A Silvair lighting schedule may, for example, recall a preparation scene at 6:00 AM, a working-hours scene at 8:00 AM, a reduced scene at 6:00 PM and a night scene at 11:00 PM. These are example times, not Silvair defaults. The same Silvair lighting schedule can use fixed local time or, when gateway-based, an astronomical event.
There are two architectures: in-node scheduling, which runs inside the lighting network, and gateway scheduling, which is managed through a Silvair Gateway. Choose by functional requirements, not building size.
How Silvair Scenes and the Multiple Scenes / Scheduling Scenario Work
Silvair scenes are preconfigured operating states in a Multiple scenes / Scheduling profile. A scene defines a lighting level and automatic control behavior. Tunable-white control may be available with compatible fixtures and firmware, but whether color temperature is stored per scene must be verified for the specific device and control profile.
Illustrative scene design
The following names and values are illustrative examples rather than Silvair default settings. Scene names, light levels and automatic behaviors are configured for the project requirements.
| Example scene | Illustrative behavior |
| Preparation | 50% output before normal occupancy. |
| Working Hours | 100% example value or normal automatic control. |
| Cleaning | 80% example value for task visibility. |
| Night | 20% example value or a minimum/security state. |
Silvair scenes allow one zone to change between meaningful modes without redefining the system at every event. Effective lighting scene control starts with the building activity—preparation, work, cleaning or security—and then assigns the appropriate scene.
A shared profile does not automatically give its zones a shared schedule. Zones can expose the same scene definitions, but each zone must be included in the relevant event. This distinction is central to reliable lighting scene control.
How a Scheduling Event Recalls a Scene
A scene may be recalled by a scheduled event, a compatible wall control or other supported manual control. An 8:00 AM event can recall the Working Hours scene; the zone then adopts the behavior already defined for that scene. This makes time-based and user-initiated scene recall compatible within one profile.
With Silvair in-node scheduling, a manual value can remain active after an event until the next event recalls its scene. Do not create two different recalls for the same zone at the same moment: both can trigger, but one may immediately overwrite the other. Linked zones also do not automatically share a schedule; they can hold different schedules and trigger independently.
A manual scene action in a linked zone that does not use in-node scheduling can affect the visible state of a linked zone, so linked-zone behavior should be tested as part of lighting scene control validation.
What Is Silvair In-Node Scheduling?
Silvair in-node scheduling is decentralized Bluetooth mesh scheduling. The mobile app sends configured events to compatible devices during commissioning; devices store the events, follow network time and recall scenes locally. Once configured, normal operation needs neither a gateway nor an Internet connection.
Silvair in-node scheduling supports up to 16 events, each recalling one of up to four scenes in the Multiple scenes / Scheduling scenario. It supports fixed local time, not astronomical sunrise/sunset time. It is appropriate where local autonomy and recurring schedules matter more than remote management.
Mandatory compatibility and profile conditions
- The project must be version 202101 or later.
- All devices in the project must use firmware 2.20.2 or later; older devices can prevent event triggering, time propagation and time recovery.
- The zone must use a Multiple scenes / Scheduling profile. In-node scheduling cannot be added directly to a zone using the standalone Photocell scenario. Required control behavior must be configured inside the scenes.
- Each area must pass a Mesh Quality Test with 100% Mesh Quality. In multi-area projects, also verify communication between the Time Authority area and other areas.
These conditions make Bluetooth mesh scheduling a designed capability rather than a feature assumed from Bluetooth NLC compliance alone. Correct Bluetooth mesh scheduling depends on all of them.
How Does Silvair Gateway Scheduling Work?
Gateway lighting scheduling uses a Silvair Gateway between web/cloud configuration and the Bluetooth Mesh network. It supports scheduled scene recall at defined times and on selected days, plus sunrise- and sunset-based astronomical events. Each recalled scene applies its predefined light level and automatic control behavior; an event does not reconfigure a control scenario at runtime.
Gateway lighting scheduling is useful where an exterior Night scene should begin at sunset rather than at a fixed example time such as 6:30 PM. This avoids repeated seasonal edits when daylight changes. It also supports centrally managed changes when a project already uses a gateway or connected services.
Schedule update latency and loss of connectivity
The gateway reads cloud event configuration every 4–6 minutes. A changed start time reaches the mesh a few minutes later; an edit only 4–6 minutes before start can miss that occurrence and apply on the next cycle. If connectivity drops while powered, it continues with its last downloaded configuration for at least one week. Cloud changes made during the outage download after reconnection; missed events are not replayed.
If the gateway restarts while offline, it loses its time settings and scheduling stops until Internet connectivity restores the time.
In-Node vs Gateway Scheduling
| Comparison point | In-node scheduling | Gateway scheduling |
| Where it runs | Compatible mesh devices | Silvair Gateway |
| Maximum events | Up to 16; up to 4 scenes | No public limit stated here |
| Configuration delivery | Mobile app sends events on site | Gateway receives cloud configuration |
| Time source | Mesh Time Authority | Gateway time |
| Fixed-time events | Local mesh time | Gateway-managed time |
| Sunrise / sunset | No | Yes |
| Automatic DST handling | No; manual mesh time sync required | Yes; repeated/skipped-hour rules apply |
| Time drift | Up to ~2 min/month without RTC; ~30 sec/month with RTC | Events follow gateway time |
| RTC / battery role | Recommended for accuracy and outage recovery | Not required in the same mesh-time role |
| Mesh Quality | 100% required for correct INS operation | Not the INS time-propagation condition |
| Remote changes | More limited | Yes; normally reaches gateway in 4–6 min |
| Offline restart | Local stored events remain device-based | Gateway loses time settings if restarted offline |
Gateway scheduling can coexist with local mesh operation in a project, but the design should avoid conflicting events for the same zone. Select Silvair scheduling by astronomical timing, remote-change needs, local autonomy, recovery expectations and available infrastructure.
Time Authority, RTC, Battery Backup and Time Synchronization
Sometimes informally described as a Silvair time keeper, the official Bluetooth Mesh role is the Time Authority (TA). Only one device is active at a time. The app initially assigns the first device as TA; a later battery-powered device with a more accurate RTC may become the TA. The active TA appears in the Commissioning Report and can be assigned manually in the Silvair iOS/iPadOS app when necessary.
An RTC and a battery solve different problems. An RTC reduces drift; a battery helps a device preserve time through an outage. Neither is an absolute prerequisite for in-node operation. However, a battery-backed device with an accurate RTC is strongly recommended when scheduling accuracy and recovery after a power outage are important. Adding more RTC devices does not improve accuracy by itself because only one TA is active.
The TA distributes current time to mesh nodes. Returning devices can synchronize if only part of the network loses power. After a complete outage, a battery-powered device can help restore time even when it is not the active TA, provided a relay is available in its zone.
Time Drift, DST and Power-Outage Recovery
Time drift is the difference between actual and mesh time. Silvair indicates maximum drift of about two minutes per month without an RTC and 30 seconds with one. For Bluetooth mesh scheduling, 100% Mesh Quality, compatible firmware and a dependable time source are necessary for predictable results.
In-node scheduling does not automatically adjust for daylight saving time; mesh time must be synchronized after each change. If the whole network loses power without a suitable battery-backed source, it may lose correct time and scheduled events may not work correctly until synchronization is restored.
Gateway scheduling follows gateway time, but DST still has defined boundaries. When clocks move back from 2:00 AM to 1:00 AM, events within the repeated 1:00–2:00 AM hour can run twice. When clocks jump from 2:00 AM to 3:00 AM, only the last event in the skipped hour runs at 3:00 AM.
How to Configure Silvair Scenes and Scheduling
Configuration should be planned as a controlled workflow rather than an ad hoc sequence of event entries:
- Create or select a Multiple scenes / Scheduling profile.
- Define up to four scenes, including project-specific light levels and automatic control behavior.
- Create each event with its target zone, scene, selected day(s), time and fade-in setting.
- For INS, use the on-site mobile app to send event configuration to devices.
- Verify project version, firmware on all devices and the active Time Authority; synchronize network time.
- Run a 100% Mesh Quality Test in every area and validate cross-area communication where relevant.
- Test each scene manually and verify actual scheduled events, including the next-event response after a manual override.
A Silvair lighting schedule should be documented by zone, scene, day, time, fade-in and intended operating behavior. This makes later review and remote changes less ambiguous.
Application Examples for Offices, Warehouses, Retail and Parking Areas
An office can use example values such as 50% preparation, normal automatic control during work hours, reduced after-hours behavior and a 20% night state. Warehouses can align scenes with shifts and security; retail can use stocking, customer-facing, cleaning and closed-store scenes. These are design examples, not defaults.
Parking and exterior areas often benefit from gateway lighting scheduling because sunset and sunrise track seasonal daylight. For all applications, a Silvair lighting schedule can combine time periods with supported occupancy or daylight-related behavior inside the selected scene. Good lighting scene control also keeps those behaviors aligned to each operating period.
Scheduling Limitations and Troubleshooting
| Symptom or design risk | Likely condition and action |
| INS event does not run | Confirm project 202101+, firmware 2.20.2+ on all devices, correct event target and 100% Mesh Quality. |
| Time is inaccurate after outage | Check battery-backed source, RTC recommendation, Time Authority and relay availability in the battery device’s zone. |
| DST timing is wrong with INS | Synchronize mesh time after the daylight-saving change. |
| Photocell zone cannot use INS | Use a Multiple scenes / Scheduling profile and configure required behavior within scenes. |
| Two expected states conflict | Separate simultaneous recalls for the same zone; linked zones retain independent schedules. |
| Gateway change did not apply in time | Allow the 4–6-minute cloud polling interval; late edits may wait for the next cycle. |
| Gateway schedule stopped offline | If the gateway restarted while offline, restore Internet access so it can recover time. |
Use these checks before assuming a device fault. Silvair in-node scheduling depends on the complete project state: firmware, profile type, time authority, time synchronization, mesh quality and event targeting.
Compatibility Note
Bluetooth NLC compliance alone does not confirm every Silvair scheduling function. Verify firmware, implemented Bluetooth Mesh models, project version and commissioning compatibility. Bluetooth Mesh includes Scene, Time and Scheduler concepts, but each device must implement the required capability. Use Silvair scheduling only after this verification. Gateway lighting scheduling should be verified against the deployed gateway and project version.
Technical references: Silvair FAQ (https://silvair.com/support/faq/); Silvair Wireless Lighting Control (https://silvair.com/solutions/wireless-lighting-control/); Silvair Bluetooth Standard Resources (https://silvair.com/support/pub/bluetooth-standard-resources/).
FAQ
What is Silvair scheduling?
Silvair scheduling recalls a predefined scene for specified zone or zones at selected times and on selected days. It runs locally through compatible mesh devices or centrally through a Silvair Gateway. This keeps a Silvair lighting schedule tied to a defined scene, zone and time.
What firmware and project versions are required for in-node scheduling?
INS requires project version 202101 or later and firmware 2.20.2 or later on all devices in the project. Older devices can interfere with event triggering and network-time propagation.
How many events and scenes does INS support?
Silvair in-node scheduling supports up to 16 events. Each event can recall one of up to four scenes in a Multiple scenes / Scheduling profile.
Does Silvair scheduling work with a Photocell control profile?
Not directly with the standalone Photocell scenario for INS. The zone must use a Multiple scenes / Scheduling profile, with the needed automatic behavior configured inside its scenes.
What mesh quality is required for in-node scheduling?
Silvair states that only 100% Mesh Quality ensures INS works correctly. Test every area and verify cross-area communication from the Time Authority area where applicable.
Can a user override an INS schedule?
Yes. A manual change can remain active until the next event recalls its scene. The next event returns the zone to the planned time-based behavior.
What happens after a complete building power outage?
A battery-powered source can preserve or restore mesh time, especially when supported by a relay in its zone. Without a suitable source, the network can lose correct time and needs synchronization before reliable INS operation resumes.
Can in-node and gateway scheduling be used in the same project?
They can be designed in the same project, but events for the same zone must not conflict. Define ownership of each zone’s time-based behavior and test interactions before handover.
How does gateway scheduling behave during a DST change?
At the autumn clock rollback, events in the repeated hour can run twice. At the spring forward change, only the last event in the skipped hour runs at the new hour.
How quickly does a gateway apply schedule changes?
The gateway reads cloud event configuration every 4–6 minutes. A late change close to its new start time can miss that occurrence and apply at the next scheduled cycle.
Do linked zones automatically share the same schedule?
No. Zone Linking does not automatically copy an INS schedule. Linked zones can have different events and trigger independently, so their interaction should be tested. This is a key lighting scene control boundary.
