Go to platform.silvair.com. You need Chrome v.70 or higher, and an internet connection. The Silvair mobile app requires an iOS device with iOS 12+ and an internet connection (WiFi or cellular).

Use the web app to plan your project - you can set up zones, control scenarios, link zones, predefine scenes, and create schedules before anything is built on site. This configuration is stored in the cloud, so once you’re ready and the devices have been installed and powered up you use the mobile app to transfer the settings into the actual devices on site. The web app can also be used to set up and access other services such as energy consumption monitoring or scheduling (but you will need a gateway for this).

The Mobile app: 

• is used to communicate with the mesh devices directly (you cannot do this with the web app). 

• Is used to transfer the configurations created in the web app to the devices, 

• Is used to adjust some lighting behaviour parameters on site. See below for a comparison of the features available in the mobile and web apps.

All new accounts require you to confirm your email address. Check your email and spam folder for an activation email from "noreply@silvair.com". If you have not received an email, click “Resend Activation Link” on the popup when you try to login.

Check your spam folder, or try logging in and resending the confirmation email.

• A Silvair account (register via the Silvair web app or Silvair mobile app).

• A lighting control plan for your project so you know what lighting behaviour you want in each zone.

• A floor or a site plan image in PNG or JPG image (optional)

If your project is going to have over 150 devices, or have sparsely distributed nodes, follow the guidelines in our SN-213 Large lighting installations Application Note.

In the web app, navigate to the area, right-click anywhere in the area view, and select “Edit Area”.

Please make sure that the file is the right size (<10MB) and format (only PNG and JPG are accepted)

You can only upload the floorplan with the web app. This feature is unavailable in the mobile app.

It looks like you do not have the appropriate permissions to edit the project: only an “Installer”, “Manager” or “Owner” can make project changes. Contact the owner or manager of the project and ask them to change your role.

Select one or more collaborators by clicking the checkboxes next to their names on the collaborators page. Then select “REVOKE ACCESS” (displayed in the right corner of the table). Confirm by clicking “REVOKE” on the pop-up window.

You cannot revoke access for the user with the “Owner” role in the project. There is always one Owner per project.

Check your role in the project. Installers and above should be able to drag and drop the zones. Sometimes you also need to enlarge the floor plan to be more precise with dropping the zones.

It looks like you have created a draft zone, i.e. the zone has been created but does not have a profile assigned yet. Select a profile for the zone.

No, you cannot add a device using the web app, you can only change certain parameters. Any changes are applied to the devices using the mobile app.

This appears when the zone has been commissioned but has some issues that require user-intervention, e.g. requires reconfiguration. These errors can be simple (reconfigure a zone) or more serious (RPL errors). First, check what errors need to be resolved by right-clicking on the affected zone, and selecting “Zone Details”. Note the message under the “Alert” heading. 

Possible causes of this may be: 

• settings were changed in the web or mobile app but have not yet been applied to the devices

• daylight harvesting/photocell has not been calibrated

• RPL errors have occurred if your project is very large

• the project version was updated in the web app but the devices themselves have not been reconfigured 

Follow the recommendations above and resolve each of the alerts.

Don’t forget that if you adjust any settings using the web app (e.g. any of the profile settings) you still need to go on site and reconfigure the affected devices in the project. Once you are on site, open the mobile app, navigate to the project and find the zones displaying a red circle and exclamation mark. Press ‘reconfigure’. When the new settings have been uploaded to the devices, the zone will show a green check mark.

This means that daylight control in the zone has not been calibrated yet or there is no light sensor selected to control the light in the zone (e.g. the previously selected light sensor has been removed from the zone). 

If the zone has a daylight harvesting scenario based profile selected, follow the instructions in daylight harvesting calibration.

If the zone has a photocell profile selected, follow the instructions in photocell calibration

• Remove all nodes from all zones in the project.

• Navigate to the selected project.

• Place the cursor on themenu icon on the area to open the context menu, then select “REMOVE”.

• Confirm your decision by clicking “REMOVE” on the confirmation popup. In order to prevent accidental removal of the area, the button becomes clickable after 3 seconds.

• Navigate to the project list.

• Click the context menu iconon the project you want to remove and select “REMOVE”.

• You will see the “Remove” option only if you have the “Owner” role for this project. 

• On the confirmation pop-up, click “REMOVE” again. In order to prevent accidental removal of the project, the button becomes clickable after 3 seconds.

• The project will be removed and will not be available for any users collaborating on the project.

Zone linking allows occupancy and switch control to be shared by multiple zones, i.e..

• controlling multiple zones with a single wall switch

• triggering the lights in multiple zones with an occupancy sensor, e.g. a hallway outside meeting rooms when they are occupied.

There are two ways in which you can update a project to the newest version: 

Option1: 

• Click on the Project box context menu in the top-right corner and select “Update”. You will see a pop-up appear.  Update your project by clicking“UPDATE NOW”. 

• Click “More details” to access the release notes for the newest version of our software. Additionally, you will find there information about firmware compatibility, e.g.
  Ver. 201808. Compatible with firmware: >=2.8.0

Option 2: 

• Open a project. If the project is not in the newest version, under the navigation bar the current version number will appear with an “update to v.XXX” link.

Click on the new version link and select “Update”. The update should start automatically.

A node can be assigned as a relay either manually via the mobile application, or automatically during the commissioning process. 

The automatic mechanism works as follows.

  If you have added between 0-20 nodes and no relays have been assigned then commissioning each additional node (up to the 20th) has a 10% chance of turning it on as a relay. If you are commissioning node #20 and there are still no relays, then this node is automatically set as a relay.

The energy monitoring does not differentiate between power outages or devices being off. In such cases the result is calculated as a linear interpolation from the last data point before the failure to the first one after the failure.

Currently there is no mechanism to store data to the non-volatile memory, so the data is lost on power failure.

Yes, if the internet connection is lost the gateway can store the captured data (up to the size of available non-volatile memory) provided the gateway does not lose power or is not rebooted (see #Q2).

Scheduling requires a Silvair gateway to be added to the project. Additionally, scheduling only works with the “Multiple Scenes” Scenario. Please see SN-201 - Scheduling.pdf for additional information.

INS is a scheduling service that allows users to set up events that trigger predefined scenes at desired times. Contrary to gateway-based scheduling, it does not require a gateway device or Internet connection. Other notable functional differences include the following:

• INS does not support astronomical clock (events based on sunrise and sunset)

• INS is exposed to a slight time drift. In installations that include an RTC (real-time clock) node, the worst-case scenario is ~30 seconds per month. In installations without RTC, the maximum time drift increases to ~2 minutes per month.

• With gateway-based scheduling, users can adjust schedules remotely if needed. With INS, all adjustments need to be performed on-site via the mobile app.

For every zone, you can configure up to 16 time events and 4 scenes triggered by those events.

Yes, schedules can be temporarily overridden by users via manual control. If this happens, the luminaires automatically return to their schedule when the next scheduled event is triggered.

Not yet, but this feature is on our roadmap. Until released, the time needs to be synchronized using the mobile app whenever DST begins or ends within the time zone relevant for the project.

An RTC node is a dedicated piece of hardware with a real-time clock chip and, preferably, extended battery life which keeps the time running even when the power supply is off.

The main goal of the RTC hardware is to minimize the gradual time drift and thus ensure the high precision of the scheduling service. If the RTC device includes battery backup (most of them do), it also allows automatic time synchronization in the event of a network-wide power outage.

No. Installations using INS are recommended to include an RTC node for optimal performance. However, this is not a mandatory requirement as the mobile app can always be used for time synchronization (e.g. after a power outage, to adjust for DST, or to offset the time drift).

One is enough. Only one device can perform the role of the so-called Time Authority for the entire project at a given time. Therefore, adding multiple RTCs will not produce any benefits in terms of scheduling precision. A general requirement for Bluetooth mesh lighting control systems is that communication is maintained at all times between different zones and areas, allowing each device to communicate with any other device in the network. As long as this requirement is met, a single RTC device will effectively handle time synchronization across the entire project. If project-level communication is not provided, both the scheduling service and other lighting control features might not perform as expected.

The app does not have a feature enabling detection of devices with battery backup.

Yes, this will happen automatically as long as there is a relay node within its zone. Information about relay nodes can be found i.a. in the commissioning report.

The current time is automatically injected from the mobile app to the network during the INS configuration/commissioning process. What happens next depends on whether the network includes an RTC node. If it does, the RTC takes care of ongoing time synchronization, ensuring minimum time drift and high scheduling precision. If RTC is not available, time management happens within network nodes and the expected time drift slightly increases. In both cases, the mobile app can be used to offset any time drift that has already occurred.

No. If only a group of nodes is powered down, their internal clocks will be automatically synchronized with the remaining nodes as soon as the power supply is restored. This automatic time recovery procedure might not work in some very rare edge cases - so it’s recommended to verify whether scheduling works properly after a power outage takes place. If it doesn’t, the mobile app must be used to synchronize the time.

This depends on whether the network includes a battery-powered node. This could be an RTC device (most of RTCs include a battery) or any other node with battery backup. In case of a network-wide power outage, a battery-powered node will automatically share its internal clock with the entire network as soon as the power supply is restored. This procedure might not work in the event of some particularly long power outages (longer than ~24 hours). When a power outage lasts longer than the RTC’s battery capacity, the mobile app will have to be used for time synchronization.

If the installation doesn’t include any nodes with battery backup, a network-wide power outage will result in time desynchronization. Once the power supply is restored, the mobile app will have to be used to inject the current time into the network. This is a simple operation requiring the user to click a relevant button in the app, but it needs to be carried out on-site. If the time is not synchronized following a power outage, INS schedules won’t be implemented.

In the case of practically foreseeable power outages, time drift will not be affected. Theoretically, it might increase slightly in a network with a non-typical node layout that suffers very frequent power outages, but this is an extremely rare edge-case scenario that we do not expect to come up in commercial implementations.

Currently, there is no such possibility. The app automatically assigns the Time Authority role to a node that is best suited for it (in terms of timekeeping precision and/or battery backup).

A node performing the Time Authority role is the node that determines the time for the entire network. If the network includes an RTC device, such a device will automatically be selected as a Time Authority.

No, there is no automatic time synchronization between the mobile app and the Time Authority device. Time can be injected into the network in the following three cases:

• when the Time Authority role is being assigned

• when the project’s timezone is changed and Time Authority reconfiguration takes place as a result

• when the user manually requests time synchronization by pressing the Sync time button in the mobile app

Yes, existing installations based on older FW versions can be easily updated to enable INS as long as OTAU has been made available for devices used in the project.

1. Update the firmware of all your devices via over-the-air update (OTAU)

2. Remove all devices from the project.

3. Add devices back to your project.

Once these steps are performed, you can start setting up your schedules.

Yes, INS will work just fine in such projects as long as all nodes are updated to FW 2.20.2+. In-node scheduling can be implemented independently of gateway-based scheduling.

Currently, in-node scheduling does not support the Photocell scenario and cannot trigger Photocell behavior.

We strongly recommend that each node is updated before the INS feature is used. Even a single node with older firmware can cause a number of problems. Not only will it fail to execute scheduling events, but it will also be unable to propagate time through the network or participate in the time recovery procedure. In certain cases, this might lead to time synchronization issues affecting also the nodes with the latest firmware.

It has to be 100%. Only full network-wide connectivity ensures the flawless performance of the in-node scheduling feature. In fact, maintaining 100% connectivity at the project level is strongly recommended for every mesh lighting control network, regardless of whether or not it uses the INS feature.

It is not possible to manually adjust the Time Authority setup via the app. Also, only one device can perform the Time Authority role for the entire network at a given time.

If the project includes only 1 area, you should perform a standard mesh quality test to verify whether 100% mesh connectivity is maintained across that zone. If there are multiple areas, you should perform the mesh quality test for each zone independently to make sure that 100% connectivity is maintained within every single zone. In addition, you can verify cross-area connectivity by launching the app in the area where the Time Authority node is located and, while still remaining in that location, testing at least one node from each other area. The location of the Time Authority node can be verified in the commissioning report. In the future, we plan to add a more convenient testing tool that will allow users to easily verify mesh quality at the project level.

Yes, the manual event will override the scheduled event in the linked zone.

Zone linking does not affect in-node scheduling in any way. Specified schedules will be executed independently for each of the zones.

Both will be triggered at the same time but one of them will instantly ‘overwrite’ the other. As a result, only one of these scenes will be visible in a given space. It cannot be precisely determined which scene will prevail as this is dependant on multiple factors. The user should make sure that such a conflict of schedules does not take place in a project configuration. In the future, we plan to introduce system warnings that will prevent this from happening.