# Cloud documentation > How to set up, run and troubleshoot remote device management in Cloud: sites, devices, portals and the people who use them. --- # Quick start The shortest route from nothing to a device you can see and control remotely. Each step links to the topic that covers it in full. For a new site to be created, you must have a Cloud Site voucher. These vouchers are available via the following methods: 1. Complete the Cloud sign-up form. One of the team will be in touch with a free trial voucher. 2. Purchase a site plan. > _Where the portal has extended trial vouchers:_ > > Some hardware also carries a QR code. Scan it to generate an extended trial voucher. ## 1. Redeem your voucher 1. Navigate to [Cloud](/) 2. Select **Redeem Voucher for a new Site** 3. Follow the instructions in the wizard to create a site and set up the first site owner. > **Have an existing account?** > > If you already have an existing account, first sign in and select **Redeem voucher** from the user menu in the top right. ## 2. Add a device to the site 1. On the **Devices** tab, select **Add Device**. 2. Give the device a name. A device key is generated - select it to copy. 3. Open the device's built-in web interface and find the **Cloud** section of the Home page. Select **Connect**. 4. Paste the key into **Device key** and select **Set Device Key**. The status changes to **Connecting**, then **Connected**. Provisioning can take a few minutes, after which the device appears as **Online** on the **Devices** tab. Device keys expire once a device has made a connection. > _With Pharos Designer or Pharos Express:_ > > ### Or add the device from your software > > You can provision devices from the software that configures them, instead of copying keys by hand. > > > _With Pharos Designer:_ > > > > In Pharos Designer, sign in using the Cloud icon in the top-right corner, choose your site, and assign devices from Network view. > > > _With Pharos Express:_ > > > > In Pharos Express, use the **Configure Cloud** helper, enter your Cloud URL, sign in, then select a site. ## 3. Add more users to the site To invite other users to the site, navigate to the users tab and select **Invite user**. Input the user's email address to invite them to the site. The user will receive an email with a link to the site which will also allow them to create a new user profile if they have yet to do so. ## Next steps - [Permissions](/documentation/sites/permissions) - decide who can do what, per site and per device. - [Site settings](/documentation/sites/settings) - set the site location, which determines local time for schedules. - [Control Panel](/documentation/sites/control-panel) - build a simple interface for the people who use the system day to day. Source: /documentation/overview/quick-start --- # How Cloud works ## Organisation Cloud is split into sites. A site is a collection of devices, usually all the hardware on one project. > _For readers with multi-site access:_ > > Sites can also be grouped into a multi-site, which is managed and controlled as a collective without giving up control of each site individually. A retail chain is the usual case: every branch is its own site, and the multi-site is all of them at once. We recommend each site be given a name that identifies it unambiguously: the project name, the company name, or both, plus the geographical location. ## Site modes A site is always in one of three modes. The mode determines which features are available. **Construction** Commission devices while you are on site, see basic connection status, invite users, set permissions and adjust site settings. Other features stay locked. **Active** Standard operating mode, where all Cloud features are enabled for a site. The site owner starts this with **Activate Site** on the site's **Settings** tab, which begins a free trial of a set number of days, after which a subscription is due. **Standby** Where a site moves after the trial or current site plan ends. It is free, indefinite, and limited in the same way as Construction. Devices and configuration are not lost - the site can be reactivated once a site plan is in place. > **Important** > > When a site is in Standby, it will not run tasks, including those linked to schedules or Control Panel. | Site feature | Construction | Active | Standby | | ------------------------------ | ------------ | --------- | ------- | | See online / offline status | Yes | Yes | Yes | | Add and replace devices | Yes | Yes | Yes | | Invite other users to the site | Yes | Yes | Yes | | All other features | No | Yes | No | | Cost | Free | site plan | Free | ## How devices connect Each device makes an outgoing connection to the Cloud servers over its Ethernet port, using industry-standard encryption. No additional hardware is needed. ## Users Users you invite see only the devices and features their permissions allow, as set by the site owner. See [Permissions](/documentation/sites/permissions). A site owner is the main contact person of a site. The site owner has administrative rights within a site to manage users and devices. Usually the first person to be added to the site will be the first owner. The owner will be able to transfer this permission to other users. There must be at least one owner in each site. There is no cost associated with adding users to a site. Source: /documentation/overview/how-cloud-works --- # Terminology The words this documentation uses for the parts of Cloud, and what each one means. **Cloud** - the product itself: remote monitoring, management and control for compatible devices, reachable from a browser. **Site** - a collection of devices, usually grouped by project. Who can reach them, what they do, and when, is all configured at site level. See [Sites](/documentation/sites/index). **Device** - anything that can connect to a site: controllers, plus network nodes and gateways, and managed switches. (_Where the portal has a published supported devices list:_ See [Supported devices](/documentation/reference/devices).) **Controller** - a device that runs a project file. "Device" covers the wider set above; "controller" is used specifically where a controller, rather than any device, is meant. (_Where the portal has a published supported devices list:_ The controller families this portal manages are named in [the device list](/documentation/reference/devices).) > _For portal owners:_ > > **Portal** - an account that manages several sites from one place, typically for an integrator or a multi-site customer. See [About Portals](/documentation/portals/index). > _For readers with multi-site access:_ > > **Multi-sites** - a portal feature that groups several sites so they can be managed both individually and as a collective. See [Multi-sites](/documentation/portals/multi-sites). **Task** - a collection of actions that can run across several devices in a site. See [Tasks](/documentation/sites/tasks). **Action** - a single command a task performs on a device, such as firing a trigger or starting a timeline. See [Task actions](/documentation/sites/task-actions). **Task scheduler** - a task set to run automatically, on a recurring or one-off basis. See [Scheduling](/documentation/sites/schedules). **Site plan** - the paid subscription that keeps a site in Active mode. See [Vouchers](/documentation/reference/vouchers). **Control Panel** - a simplified interface built for the people who use a system day to day, without exposing the rest of Cloud. See [Control Panel](/documentation/sites/control-panel). Source: /documentation/overview/terminology --- # Sites A site is a collection of devices, usually grouped by project. Everything you configure for a group of devices — who can reach them, what they do, and when — lives at site level. ## Your sites **Sites** is where you land when you sign in, and it lists every site you belong to. A site you have just been invited to appears here as soon as you accept. ### The status cards Two cards sit above the list and summarise everything in it at once, so you can see whether anything needs attention before opening a single site. **Site Status** counts your sites by state: | State | What it means | | ---------------- | ------------------------------------------------------------------------ | | **Active** | A live site with a current subscription | | **Construction** | Being commissioned, and not yet counted as live | | **Demo** | A demonstration site | | **Suspended** | Access withdrawn — see [Subscription](/documentation/sites/subscription) | **Device Status** counts the devices across all of those sites, so a single offline device is visible without opening the site that holds it. Both cards collapse, and stay collapsed the next time you sign in. ### The list | Column | Shows | | ---------------- | ---------------------------------------------------------------- | | **Site** | The site's name, with its state beside it where it is not active | | **Team** | How many people belong to the site | | **Devices** | How many devices the site holds | | **Renewal Date** | When the subscription next needs extending | | **Options** | Actions for the site | Sort by any column with a heading you can select, and filter the list by name with the search box. Use **Add Site** to create one. ### The map Sites you belong to are also plotted on a map, positioned by the location set in each site's own [Site settings](/documentation/sites/settings). A site with no location set does not appear on it. > _For portal owners:_ > > The map is on your own sites only. The portal-wide **Sites** list described in [Portal-wide lists](/documentation/portals/lists) shows the same columns for every site in the portal, without the map. > _For readers who are not portal owners:_ > > The map is shown on your own sites. A portal-wide sites list, where it exists, is a separate view without one. ## What is in a site | Topic | What it covers | | --------------------------------------------------------------- | ------------------------------------------------------- | | [Adding devices](/documentation/sites/devices) | Provisioning devices, device keys, replacing a device | | [Fixtures](/documentation/sites/fixtures) | Discovering and patching RDM fixtures | | [Users](/documentation/sites/users) | Inviting people to the site | | [Permissions](/documentation/sites/permissions) | What each user can do, per site and per device | | [User roles](/documentation/sites/user-roles) | Named sets of permissions, and who holds them | | [Site settings](/documentation/sites/settings) | Contact details, location and local time, notifications | | [Tasks](/documentation/sites/tasks) | Grouping actions to run across devices | | [Task actions](/documentation/sites/task-actions) | Every available action and what it requires | | [Schedules](/documentation/sites/schedules) | Running tasks automatically | | [On Device Schedules](/documentation/sites/on-device-schedules) | Schedules the device keeps running on its own | | [Control Panel](/documentation/sites/control-panel) | A simple interface for day-to-day users | | [Subscription](/documentation/sites/subscription) | Plan, renewal and extending a site | | [Activity log](/documentation/sites/activity-log) | Who did what, and when | | [API keys](/documentation/sites/api-keys) | Integrating another system with a site | ## Renaming a site Hover over the site name until the dashed box appears, select the value, and edit it in the box. This needs **Site:Edit: All** — see [User permissions](/documentation/sites/permissions). New to Cloud? Start with the [Quick start](/documentation/overview/quick-start) instead. Source: /documentation/sites/index --- # Site settings ## Contact details With the correct permissions, these can be edited in place — select the text to open the inline editor. | Field | For | | ------------------------------ | ---------------------------------------------- | | **Primary contact** | Name of the contact for this site | | **Primary contact email** | Email address of the contact | | **Primary contact phone** | Telephone number for the contact | | **Commercial contact email** | Person responsible for commercial arrangements | | **Subscription contact email** | Person responsible for subscriptions | | **Technical contact email** | Person responsible for technical information | Any text is accepted, but accurate contact details are worth the effort — they are how the right person gets reached about this site. ## Notes A free-form notes field for the site, editable in place with the correct permissions. ## Site location and time The site location determines the site's local time, which is what scheduled tasks run against. It must be set before [Scheduling](/documentation/sites/schedules) can be configured. A new site opens on a default position on the map; the location is not set until you choose one. 1. Navigate the map until the site's location is visible. 2. Select the location. 3. If the pin and the address preview look right, select the checkmark to accept. Once a location is set, Cloud calculates: | Field | Notes | | --------------- | --------------------------------------------------------------------------------------------- | | **Latitude** | From the point you selected | | **Longitude** | From the point you selected | | **Geo address** | Derived from the coordinates. It need not be exact for the site to work, but closer is better | | **UTC offset** | Calculated from the coordinates | | **Time zone** | Calculated from the coordinates | > _For portal owners:_ > > ## Enforce two-factor authentication > > Where two-factor authentication is enabled for the portal, site owners can require every user in this site to use it. A user who already has it set up signs in as usual; a user without it is made to set it up at their next sign-in. > > Belonging to one site that enforces two-factor authentication is enough for it to apply to a user everywhere. ## Notifications > _For readers who are not portal owners:_ > > Four types are available. Each user chooses which to receive, either per device or across every device in the site, and how often they are delivered. > _For portal owners:_ > > Four types are available. Each user chooses which to receive, either per device or across every device in the site. By default a user is editing their own settings. Site owners can optionally set another user's notifications by choosing them in the **Select user...** popover. | Type | Fires when | | ------------------ | --------------------------------------------------------------------------- | | **Connection** | A device changes online status (tolerant of brief outages) | | **Warning** | A device raises a warning notification | | **Error** | A device raises an error notification | | **Fixture Status** | A device reports a [fixture status](/documentation/devices/fixtures) change | The digest schedule is set per user, so different users in the same site can receive notifications at different intervals. For what each type fires on, how the schedules differ, and the bell in the top bar, see [Notifications](/documentation/reference/notifications). Source: /documentation/sites/settings --- # Managing devices A device is added to a site from Cloud, using the device's own web interface to complete the handshake, or from Pharos Designer or Pharos Express. Every route needs one thing: an outgoing internet connection on each device's Ethernet port. If your network restricts outbound access, see [Network requirements](/documentation/troubleshooting/network). > _With Pharos Designer or Pharos Express:_ > > Pick whichever route suits you — the result is the same. ## Adding a device from Cloud This route needs access to the device's local web interface. **1. Start in Cloud.** On the site's **Devices** tab, select **Add device** on the right of the screen. **2. Name the device.** It does not have to match the device name set in Designer, though it usually makes sense for it to. **3. Copy the device key.** A device key is generated. Select it to copy. > **Note** > > Keys are valid for seven days from creation. Cloud rejects an older key and the device will not connect. To generate a fresh key for a device, follow [Replacing a device](/documentation/sites/devices#replacing-a-device). **4. Open the device's web interface.** Select **Connect** under **Cloud** on the Home page. ![The Cloud section of the device's Home page, with Connect](/assets/26.314.0/device-web-cloud-connect-C-T8aDaO.png) **5. Paste the key.** Put it in the box and select **Set Device Key**. ![The device key pasted in, with Set Device Key](/assets/26.314.0/device-web-set-device-key-ChAKYmdr.png) **6. Wait for provisioning.** The status changes to **Connecting**, then **Connected**. This can take a few minutes. Once it completes, the web interface updates with site-related information. **7. Check the site.** The device now shows as **Online** on the site's **Devices** tab. > _With Pharos Designer:_ > > ## Adding a device from Designer > > Designer has the integration built in, so a device can be added to a Cloud site without leaving the software. > > **1. Enable the Cloud feature** in project Features. > > ![Cloud enabled in Project Features](/assets/26.314.0/designer-project-features-cloud-B01n6X_f.png) > > **2. Choose the site.** Near the top of the Project Properties tab, select the Cloud site option to **Choose site…**. > > ![The Cloud site option in Project Properties](/assets/26.314.0/designer-choose-site-H-J0i60d.png) > > **3. Sign in.** Enter your Cloud credentials, then choose your site from the list. > > ![The Cloud sign-in dialog](/assets/26.314.0/designer-cloud-login-B1Sserzj.png) > > ![Choosing a site from the drop-down](/assets/26.314.0/designer-site-dropdown-BBweqXwk.png) > > **4. Read the status column.** In Network view, the **Status** column shows each device's Cloud state. > > | Icon | Meaning | > | ---------------- | --------------------------------------------------- | > | Solid blue cloud | Associated and active in your Cloud site | > | Hollow cloud | Previously associated, not currently active | > | Greyed out | Devices exist in the site but you are not signed in | > > ![Cloud status icons in the Network view Status column](/assets/26.314.0/designer-network-view-cloud-status-idqRSMbD.png) > > To sign back in, select the hollow cloud icon beside the issues icon. A solid icon means you are signed in. > > ![The hollow cloud icon, signed out](/assets/26.314.0/designer-cloud-icon-logged-out-NTJLze9Y.png) > > ![The solid cloud icon, signed in](/assets/26.314.0/designer-cloud-icon-logged-in-CezOvCtB.png) > > **5. Add the device.** Select **Add device to Cloud** at the bottom of the device Properties tab in Network view. The connection status dialog appears. > > ![The Add device to Cloud button](/assets/26.314.0/designer-add-device-to-cloud-J8twMI5O.png) > > ![The connection status dialog](/assets/26.314.0/designer-connection-status-vuNX2WAk.png) > > If the button is disabled, either the device has an incorrect network setting — the issues dialog will say which — or it already exists in the Cloud site. In the second case you can upload to it, or use **Disconnect device from Cloud** if it belongs to a different site. > > **6. Confirm.** Once the device has been added, **Add device to Cloud** becomes disabled and the device shows as **Online** in Cloud. > _With Pharos Express:_ > > ## Adding a device from Express > > Express uses the **Configure Cloud** helper, reached from the Cloud icon in device Properties. > > **1. Enter your Cloud URL.** Open the **Configure Cloud** helper and give it the address of your portal. A valid URL is required to continue. > > ![Open the Configure Cloud helper from the property editor](/assets/26.314.0/express-cloud-device-properties-DxTfgX5Z.png) > > ![Entering the Cloud URL in Express](/assets/26.314.0/express-cloud-url-iKVncfgz.png) > > **2. Sign in.** Enter your username and password. If the account has two-factor authentication enabled, you are prompted for a code — see [Signing in](/documentation/reference/signing-in). > > ![Signing in to Cloud from Express](/assets/26.314.0/express-cloud-login-CghRyAb1.png) > > **3. Choose your site** from the list of those available to you. > > ![Choosing a site in Express](/assets/26.314.0/express-cloud-site-list-8RbDfkS0.png) > > **4. Commit the configuration.** The helper summarises the changes it will make. Commit them to save the configuration into the project. > > ![The Cloud Configuration Helper summary](/assets/26.314.0/express-cloud-commit-CsDBLp0U.png) > > **5. Add the device to the site.** The device reports whether it is already connected to the site. If it is not, device Properties offers a single-click option to add it — supply a name for the device as it will appear in the site. > > ![Adding the device to the site from device Properties](/assets/26.314.0/express-cloud-add-device-Bm2qzLDb.png) > > > **Note** > > > > This only works if the account you signed in with holds the permission to add a device to that site. See [User permissions](/documentation/sites/permissions). > > **6. Confirm.** The device then reports that it is connected. If the device is already online in a different site, Express says so rather than moving it. > > ![The device reporting it is connected to the site](/assets/26.314.0/express-cloud-connected-BowWUXkK.png) > > Once connected, you can see the device's status directly in Express and upload project files to it remotely. When uploading, a toggle controls whether the file transfers to the device immediately or only lands in Cloud. > > > **Note** > > > > Express remembers some of these details to make later sign-ins quicker, but you have to sign in again each time you open Express or open a project. ## Device status in Cloud | Status | Meaning | | ----------------------------- | ------------------------------------------------------------ | | **Online** | Communicating with the Cloud service | | **Offline** | Not communicating with the Cloud service | | **Unassociated** | Has not yet connected, or has been moved to a different site | | **Online - upgrade required** | Connected, but firmware is below the minimum required | | **Upgrade required** | Offline, and the last cached firmware was below the minimum | > _Where the portal has a published supported devices list:_ > > For more on supported firmware, see [Supported devices](/documentation/reference/devices). ## Replacing a device Replacing keeps the site entry and swaps the hardware behind it. 1. Select the device using the circle to the left of its name in the device table. 2. Select **Replace** from the options for the given device. 3. Copy the device key to the new device and paste it in, the same way as when adding a device. The device name is retained. Everything else the old device reported is discarded and replaced by the new device's information. > **Important** > > Settings related to the device are retained where possible, but if the device _type_ has changed, tasks and actions associated with it may become invalid. Check the **Tasks** tab for conflicts afterwards. ## Removing a device 1. Select an offline device using the circle to the left of its name. 2. Select **Remove** from the options for the given device. The device is removed from the site and stops trying to connect to it. Source: /documentation/sites/devices --- # Fixtures _Only where the portal has RDM._ ## Fixture status across a site Open a site and select its **Fixtures** tab for an overview covering every controller in the site, with a summary per controller. Users who have the correct permissions to see fixture information for any controller in the site will see those controllers in the summary. **Refresh All** starts a poll across all controllers the user can run polls from in the site, asking you to confirm first because a poll can momentarily disrupt lighting output. Selecting a controller takes you to its dedicated [Fixtures tab](/documentation/devices/fixtures) where fixtures can be managed. Under **Site Fixtures Status** the whole site is broken down by status, and under **Devices** the same breakdown is repeated per controller, each card sizing its bars against that controller's own total. Alongside the fixture statuses, a card counts **Unassigned Devices** — responders no fixture in the project claims — and **No Data**, the fixtures nothing has been reported for at all. These cards use the dashboard's own wording. The [device fixtures tab](/documentation/devices/fixtures) names two of the same statuses differently on the markers in its own table, and lists which word to expect where. A message at the top of this tab records that, while fixture status monitoring is being introduced, it is included in your standard Cloud subscription, and that you will be told in advance if that is going to change. Dismissing it hides it for you on this site. ## Prerequisites **The controller runs a recent enough version.** Below the minimum the device's **Fixtures** tab is not shown at all rather than shown empty — so a missing tab is the thing to check first. On an LPC family controller the minimum is Pharos Designer 2.16.3. On an Express controller it is Pharos Express 2.1.2. **The controller is a model that supports RDM.** The tab is offered per model, and some models, the VLC family among them, do not have it whatever their firmware. **Fixture status is turned on for your portal, and you may see it.** It is a portal feature, so a portal without it has no fixtures tabs anywhere; and the tab is withheld from a user without permission to view fixtures on that device. **Your fixtures support RDM.** Check the manufacturer's documentation. A fixture that doesn't support RDM can still exist in the project and will appear as a fixture in the Fixtures tab for controllers, but Cloud has no way to query it. **Your fixtures have RDM UIDs set in the project file.** Fixtures added by RDM discovery get their UID automatically. Anything added by hand needs the UID entering in the fixture's properties. Without a UID, the device can't match a discovered responder to a fixture in your project. See the [Pharos Designer](https://dl.pharoscontrols.com/software_help/designer2/Default.htm#help/reference/patch/patch.htm) or [Pharos Express](https://dl.pharoscontrols.com/software_help/express/2.1/Content/B-HowTo/2.4.0-WorkWithPatch.htm) help for how to do this in your system. Source: /documentation/sites/fixtures --- # Managing users Anyone who needs access to a site is invited to it by email. What they can then see and do is governed separately, by their permissions - see [Permissions](/documentation/sites/permissions). The site's **Users** tab covers all three, as sub-tabs: **Users** is membership — who belongs to the site, and this page; **Permissions** is the permissions table. > _Where the portal has user roles:_ > > Between them sits **Roles**, the roles those people hold here — see [User roles](/documentation/sites/user-roles). Each sub-tab has its own address, so one can be linked to and the browser's back button moves between them. A sub-tab you may not see is left out rather than refused. ## User states A user in a site is always in one of three states. | State | Meaning | | ------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Active** | Can access the site, according to their permissions | | **Invited** | Has not yet created a Cloud account. Once they do, they can access the site according to the permissions already set for them | | **Suspended** | Cannot sign in or interact with any site | > _For portal owners:_ > > Suspension applies across the whole portal rather than to one site, so a suspended user cannot sign in at all. See [Administration](/documentation/portals/administration) for managing users above site level. > _For readers who are not portal owners:_ > > Suspension applies across the whole of Cloud rather than to one site, so a suspended user cannot sign in at all. Only the portal owner can apply or lift it - ask them if you need a user suspended or restored. ## Inviting a user 1. On the site's **Users** tab, select **Invite user**. 2. Enter the user's email address. You can set the new user's permissions straight away, before they have accepted the invitation - see [Permissions](/documentation/sites/permissions). They receive an email with a link to the site. If they have no Cloud account, they are prompted to create one; if they already have one, they are simply told they have been added to a new site. > **Important** > > Invitation links are valid for seven days. After that the link stops working and the user has to be invited again - select them on the **Users** tab and choose **Re-invite** from the options drop down. ## Removing a user 1. Select the user using the circle to the left of their name. 2. Select **Remove** from the options drop down. 3. Confirm by typing their email address. The site disappears from that user's **My Sites** list. Their Cloud account survives - a user can still sign in while belonging to no sites at all. Source: /documentation/sites/users --- # User roles _Only where the portal has user roles._ A role is a named set of permissions that can be handed to a user in one place and taken away again in one place. Setting permissions directly grants one permission to one user on one resource; assigning a role grants everything the role holds, and revoking it takes all of that back at once. The two are separate systems. A user can hold the same permission through both, and removing it from one leaves the other standing — see [User permissions](/documentation/sites/permissions) for reading a permission a role gave. Every role name on every role screen opens the same read-only summary of what it holds: A role is usable in exactly one scope — the portal, a single site, or a single multi-site — and that scope decides which permissions it may hold and where it can be assigned. > _For portal owners:_ > > ## Role Management > > **Permissions** → **User Roles** holds two sub-tabs: **Role Management**, which is the roles themselves, and **Role Assignments**, which is who holds them. > > The **Scope** column is where the role can be used, **Permissions** opens the summary above, and **Defaults** names the events that hand the role out on their own. > > ### System roles and custom roles > > Cloud ships thirteen system roles covering the usual jobs, three at portal level and five each for a site and a multi-site. They carry a **System Role** badge, and they cannot be edited or deleted — those options stay in the menu and are greyed out. They can be duplicated, and the copy is yours to change. > > | Role | **Scope** | What it is for | > | ------------------------ | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------- | > | Portal Owner | Portal | Owner-level access to every site and multi-site in the portal, and assigning roles | > | Portal Admin | Portal | The same, plus creating and deleting sites, multi-sites and roles themselves | > | Portal End User | Portal | Day-to-day use of every site and multi-site: firing tasks, scheduling, reading devices | > | Owner | Site | Full control of one site, its devices and its people. Given automatically to whoever creates a site | > | Scheduling | Site | The task scheduler and its schedules in one site | > | Control Panel | Site | Opening one site's Control Panel and firing its tasks, and nothing else | > | End User | Site | Day-to-day use of one site, scheduling included | > | Default | Site | The read-only baseline: the site, its users, its Control Panel, its tasks and its devices. Given automatically to a user added to a site | > | Multi-Site Owner | Multi-site | Full control of one multi-site, including which sites belong to it. Given automatically to whoever creates a multi-site | > | Multi-Site Scheduling | Multi-site | The task scheduler and its schedules in one multi-site | > | Multi-Site Control Panel | Multi-site | Opening one multi-site's Control Panel and firing its tasks | > | Multi-Site End User | Multi-site | Day-to-day use of one multi-site, scheduling included | > | Multi-Site Default | Multi-site | The read-only baseline for a multi-site. Given automatically to a user added to one | > > The four marked as given automatically are the ones that arrive with an **Auto assign when** trigger already set; the rest are assigned by hand. > > Two controls exist for a portal that would rather not use them: > > - **Hide System Roles** above the table leaves only the roles you made. It appears once the portal holds a custom role, since there is nothing to hide before that. > - **Disable All System Roles** switches every one of them off in a single step. Custom roles are untouched, and system roles can be switched back on one at a time afterwards. It asks you to type a word to confirm, and it says how many roles it will affect. > > ### Creating a role > > 1. Select **Create Role**. > 2. Give it a **Name**, and a **Description** if it needs one. > 3. Choose the one scope it can be used in under **Can be used in**. > 4. Tick the permissions it grants. They arrive as a tree, grouped the way the permissions table groups them, and a group's own tick box takes the whole group. > 5. Optionally choose the triggers under **Auto assign when**. > > > **One scope only** > > > > Changing the scope clears the permissions already ticked, because the new scope does not offer them — so you are asked to confirm first. A portal-scoped role has no auto-assign triggers at all; the option is only there for site and multi-site roles. > > The triggers on offer follow the scope: a site role can be assigned automatically when a user creates a site or when a user is added to one, and a multi-site role when a user creates a multi-site or is added to one. A role with no trigger is only ever assigned by hand. > > ### Editing, copying and removing a role > > Each row's **Options** menu offers: > > | Option | What it does | > | ------------- | ---------------------------------------------------------------------------------------------- | > | **Edit** | Reopens the same form. Editing a role changes what it grants everywhere it is already assigned | > | **Duplicate** | Copies the role, including its permissions — the way to start from a system role | > | **Delete** | Removes the role permanently | > > The **Enabled** switch in the row is the reversible one. Disabling a role suspends everything it grants: everyone keeps the assignment but loses the permissions until it is enabled again. > > **Copy Permissions** above the table replaces one role's permissions with another's. The source can be any role, the target only a custom one. > > ## Role Assignments > > **Role Assignments** lists every assignment in the portal, whatever scope it was made at, so a person's access can be found without visiting each site in turn. > > **Scope type** is the level the role was assigned at and **Target** the site or multi-site it was assigned on — a portal-wide assignment shows **Portal**, because it is not limited to one resource. **Select users** above the table narrows the list to the people you name; with nobody named it shows everyone. The table is paged, and both the filter and the page are kept in the address, so a filtered list can be linked to. > > - **Assign Role** takes one or more users, a scope, the site or multi-site to assign on, and the role. The role's permissions are previewed under the choice before you commit. > - **Revoke Role** takes an assignment away from several people at once. A single assignment is revoked from its own row's **Options** menu. > > ## Who may manage roles > > The **Portal** permissions tab carries a **Roles** section with four permissions, each granted portal-wide rather than on one site: > > | Permission | Allows | > | ---------- | ---------------------------------------------------------------- | > | **Add** | Create a role, and duplicate one | > | **Edit** | Change a role, copy permissions onto it, and switch it on or off | > | **Delete** | Delete a role | > | **Assign** | Assign and revoke roles anywhere in the portal | > > The **Portal Admin** system role holds all four. **Portal Owner** holds only **Assign**, and so does ownership itself: owning the portal, a site or a multi-site carries the right to hand a role out, never to author one. A control someone lacks is not shown to them at all, rather than shown and refused. > _For readers who are not portal owners:_ > > Roles themselves are made and named at portal level, so the set you can assign is the one the portal owner has set up. Ask them if you need a role that does not exist yet, or one changed. ## Roles on a site or a multi-site A site's **Users** tab holds everything about who can do what, as sub-tabs: **Users** for membership, **Roles** for the roles those people hold, and **Permissions** for the permissions table. A multi-site's Users tab works the same way. Each sub-tab has its own address, so one can be linked to or returned to with the browser's back button. Every assignment on this tab targets the site you are in, so there is no scope to choose — only the people and the role. One row per person lists every role they hold here, and a disabled or system role is tagged in place. - **Select users** above the table chooses whose roles to show. The selection is shared with the **Permissions** sub-tab and remembered per site. - **Assign Role** above the table assigns one role to one or more of them; **Assign new role** in a row's **Options** menu does the same for that person alone. - The bin beside a role revokes that one assignment. ## Reading a role's effect on the Permissions sub-tab The permissions table shows what a user can do from every source at once, so a permission a role gave is visible where it applies rather than only where it was assigned. It is drawn as a ring around an empty dot: the user holds the permission, but nothing on that table granted it, so clearing the dot cannot take it away. Hovering names the role and the level it was assigned at, and points at the tab that would remove it — which is not always the tab you are standing on, since a portal-wide role cannot be unassigned from a site. See [User permissions](/documentation/sites/permissions) for the markers in full. Source: /documentation/sites/user-roles --- # User permissions The site owner controls what every other user in the site can see and do. A user can only interact with a feature if their permissions allow it, and permissions can only be changed by someone holding **Set permissions**. A site owner can always edit permissions. ## Setting permissions 1. Open the site's **Users** tab and select **Permissions** beside it. 2. If the user does not already appear as a column, use **Select users…** to find them in the list. 3. Set each permission for each user. Selecting a white circle turns it blue and grants the permission; selecting a blue circle turns it white and removes it. Permissions apply to the current site, to all devices within it — both current and future — and to specific devices. Permissions can be copied between users by selecting the user's initials at the top of the permissions column. Copying takes only the permissions granted on the table you are looking at — a user's inherited access is not copied onto someone else as a direct grant. ## Where a permission comes from A user can hold the same permission from more than one place at once, and the dot shows which. That matters because the three are removed in three different places, and only one of them is the dot in front of you. A key above the table names each marker: | Marker | Means | Removed | | ------------------- | ----------------------------------------------- | ------------------------------------------------- | | A filled dot | **Granted here** — on this table, for this user | By selecting the dot | | A dashed green ring | **Granted at a higher level** | On the table that granted it | | A solid purple ring | **Comes with a role or ownership** | By unassigning the role, or by removing ownership | A dot can carry both rings at once — the two are drawn differently as well as coloured differently, so they can be told apart when they overlap. ### What the ring is telling you A ring means the user already has the permission without anything on this table granting it, so **clearing the dot will not take it away.** Hover the dot and Cloud names the source exactly and where to go: "Granted at portal level, so it applies to every site", "Granted for all devices in this site" or "Comes with site ownership", with the tab or row that revokes it. Ownership shares the purple ring with roles because it works the same way: it is not a permission granted on this table, but something the user holds that carries a set of permissions with it. An owner gets a fixed group of view permissions on the site and its devices, so those dots are ringed rather than empty even though nobody granted them one by one. They go when ownership goes. Two common cases: - A permission granted portal-wide reaches every site, so it shows a ring in all of them. Removing it from one site means removing it at portal level, which removes it from all of them — see [Administration](/documentation/portals/administration). - A permission granted for all devices in a site rings every individual device in it. > **The dot always does the same thing** > > Whatever rings a dot carries, selecting it grants or removes the permission **on the table you are looking at**, and nothing else. Granting one on top of an inherited permission is allowed and sometimes deliberate — it survives the higher grant being taken away. > _Where the portal has user roles:_ > > ### Roles > > A role is a named set of permissions assigned to a user at portal, multi-site or site level. Roles and the grants you set here are separate systems that do not know about each other: a user can hold the same permission through both, and taking one away leaves the other standing. > > Nothing is stored against the user on this table when a role gives them a permission, which is why the dot stays empty and shows a ring instead. Hover it to see which role, and where it was assigned; remove it by unassigning the role on the matching [roles](/documentation/sites/user-roles) tab, not here - **Roles** on a site or multi-site, **User Roles** at portal level. > **On a touchscreen** > > Hovering needs a pointer, so on a phone or tablet the table offers a **Tap a marker to explain it** switch instead. Turn it on and tapping a dot explains it rather than granting or removing the permission — which also means no permission can be changed by a mis-tap while you are reading. Turn it off again to go back to editing. > > A narrow screen also fits fewer user columns than you may have selected, so the table pages through them with arrows and a count. Only the view is paged: everyone you selected stays selected, and the rest come back when there is room for them. ## Site permissions | Permission | Allows | | --------------------------------------- | ------------------------------------------------------------------------- | | **Site:View: All** | View the site and all its attributes | | **Site:Edit: All** | Edit all attributes of the site | | **Site:Delete** | Delete the site | | **Device management: Add** | Add a device to the site | | **Device management: Firmware** | Manage firmware for devices in the site | | **User: View** | View all users in the site | | **User: Add** | Add users to the site | | **User: Delete** | Remove users from the site | | **Control Panel: View** | View Control Panel | | **Control Panel: Edit** | Edit Control Panel | | **Task: Execute** | Fire tasks | | **Task: View** | View the list of tasks | | **Task: Add** | Create tasks | | **Task: Edit** | Edit existing tasks | | **Task: Delete** | Delete tasks | | **Task scheduler: Calendar event view** | View the calendar widget of scheduled tasks | | **Task scheduler: Calendar event edit** | Disable events on the calendar widget of scheduled tasks | | **Task scheduler: View** | View the list of task schedulers | | **Task scheduler: Add** | Create a task scheduler | | **Task scheduler: Edit** | Edit a task scheduler | | **Task scheduler: Delete** | Delete task schedulers | | **Schedule: View** | View schedules attached to task schedulers | | **Schedule: Add** | Create schedules to associate with task schedulers | | **Schedule: Delete** | Delete schedules | | **Schedule: Edit** | Edit schedules | | **Set permissions** | Set permissions for other users in the site | | **Owner** | All site and device view permissions, plus Set permissions for every user | > _For portal owners:_ > > Sites on portals with API keys switched on carry one more site permission: **API Key management**, which allows viewing, creating, editing and deleting API keys in the site. See [API keys](/documentation/sites/api-keys). > > One more site permission is set portal-wide rather than site by site, so it appears on the all-sites permissions table and not on an individual site's: **Financial** — **Billing purchase**, which allows buying a subscription online. Granting it there gives it for every site. ## Device permissions Set permissions for a user for all devices in a site. | Permission | Allows | | ---------------------- | ----------------------------------------------------------------------------------------------------- | | **View: All** | View all devices | | **Device: Replace** | Replace all devices in the site | | **Device: Delete** | Remove all devices from the site | | **Fixtures: View** | View all fixture Status information for all devices | | **Fixtures: Edit** | Adjust fixture Status information for all devices | | **Fixtures: Identify** | Use Identify functionality for fixture Status for all devices | | **Setting beacon** | Toggle the beacon on all devices | | **Action reset** | Reset all devices in the site | | **Information** | View all device information — basic info, overview, status | | **Control** | View and fire all triggers | | **Maintenance** | View and perform actions that affect all devices — log level, date and time, watchdog, format storage | | **File: View** | View all files held in Cloud for all devices | | **File: Transfer** | Transfer a file from Cloud to all devices | | **File: Add** | Add a file to all devices in Cloud | | **File: Delete** | Delete a file from all devices in Cloud | | **Set permissions** | Set other users' permissions for all devices | Each device then has its own permissions table, which follows the same structure as the permissions listed above. Use **All Device** permissions wherever you can — they save setting the same thing on every device, and they cover devices added to the site later. Source: /documentation/sites/permissions --- # Tasks A Task is a collection of Actions that can run across several devices in a site. ## Creating a Task **1. Start a Task.** On the **Tasks** tab, select **Create task**. **2. Name it.** Give the Task a name and description. The name appears on the **Tasks** tab and anywhere else in Cloud where a Task can be run. The description appears only on the **Tasks** tab and is purely informational. **3. Add an Action.** Select **Add action** and choose the action type from the list. Each type shows how many compatible devices there are in the site. Two actions may look as though they do the same thing while targeting different device types, and only actions compatible with devices the user can view are listed. **4. Choose the devices** the Action runs on, and the Action itself, from the menu. **5. Configure the action.** This differs for each action type. The example below overrides RGB fixtures on a device. **6. Add it.** Select **Add action**. The Action appears in the Task. Add as many Actions to a Task as you need. **7. Create the Task.** Select **Create task** and find the new Task in the Task table. > **Important** > > If two or more devices run the same project file, you may not need a separate Action for each. But a Task that spans project files needs at least one Action per project. ## Task options From the options section of the Tasks table, the following actions can be taken. ### Running a Task Find the task you want to run and select the run icon, then confirm. Your browser shows a notification once the Task has been dispatched. Tasks can also be run from [Scheduling](/documentation/sites/schedules) and from [Control Panel](/documentation/sites/control-panel). ### Editing a Task Select the edit icon in the **options** section of the Tasks table. Changes to the name, description and actions are saved as they are made — close the edit pop-over to stop editing. Actions can be added or removed. ### Deleting a Task Find the task you want to delete, select the delete icon and confirm. Deleting a Task is permanent and cannot be undone. ## Task compatibility Certain tasks only work with certain devices. If a device has to be [replaced](/documentation/sites/devices#replacing-a-device), make sure the replacement is the same device type on the same firmware. Tasks that are incompatible with a device are flagged here and cannot be run. See [Task actions](/documentation/sites/task-actions) for every Action available and any compatibility notes. Source: /documentation/sites/tasks --- # Task actions A task action tells a device what to do when a task runs. Which actions are available depends on the device. ## Designer show controllers LPC, LPC X, TPC, MSC, MSC X, MTPC | Action | What it does | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Triggers** | Fire trigger numbers you type in. Commas and hyphens allow several at once. Numbers not present on a device are ignored and the rest still fire. Can optionally test conditions first | | **Select Triggers** | Fire triggers chosen from a list populated from the device. Can optionally test conditions first | | **Start Timelines** | Start chosen timelines. Optionally release other timelines, scenes or both, filtered by playback group | | **Release Timelines** | Release chosen timelines | | **Pause Timelines** | Pause chosen timelines | | **Pause All Timelines** | Pause every running timeline. No parameters | | **Resume Timelines** | Resume chosen timelines | | **Resume All Timelines** | Resume every paused timeline. No parameters | | **Toggle Timelines** | Toggle chosen timelines | | **Set Timelines Rate** | Adjust the rate of chosen timelines, as a percentage | | **Set Timelines Position** | Jump chosen timelines to a position, as a percentage | | **Start Scenes** | Start chosen scenes. Optionally release others as above | | **Release Scenes** | Release chosen scenes | | **Toggle Scenes** | Toggle chosen scenes | | **Release All** | Release all timelines, scenes or both, optionally filtered by playback group | | **Master Intensity** | Master all fixtures to a percentage intensity. Optionally filter by group. Fade and delay times adjustable | | **Override RGB** | Set a colour with the picker, plus intensity and colour temperature sliders. Unchecked attributes are ignored. Optionally filter by group. Fade time and path adjustable. A **Recent** row under the picker reapplies the last eight colours picked in this browser, and a **Proposed colours** row offers the colours of the site's Control Panel | | **Clear RGB Override** | Clear the override for chosen groups. Fade time adjustable | | **Beacon** | Toggle the beacon on a device | | **Reset** | Software-reset a device | ## Designer video lighting controllers VLC, VLC Plus, Atlas, Atlas Pro Everything the show controllers offer, except **Override RGB** and **Clear RGB Override**, plus: | Action | What it does | | ------------------------------------- | ------------------------------------------------------------------------------- | | **Content Target Intensity** | Set the intensity of a content target | | **Content Target Intensity Filtered** | Set the intensity of a filtered content target. **VLC Plus and Atlas Pro only** | ## Express controllers Express Control | Action | What it does | | -------------------------- | ------------------------------------ | | **Start Scene** | Start a scene in a space | | **Override RGB** | Apply an RGB override to a space | | **Space Intensity Master** | Set the intensity master for a space | | **Activate Tag** | Activate a tag | | **Space Off** | Switch a space off | | **Timed Events** | Enable or disable timed events | | **Reset** | Software-reset a device | | **Beacon** | Toggle the beacon | ## Acuity Brands controllers Animate, Perform | Action | What it does | | -------------------------- | ------------------------------------ | | **Start Scene** | Start a scene in a space | | **Override RGB** | Apply an RGB override to a space | | **Space Intensity Master** | Set the intensity master for a space | | **Activate Tag** | Activate a tag | | **Space Off** | Switch a space off | | **Timed Events** | Enable or disable timed events | | **Reset** | Software-reset a device | | **Identify** | Put the device into identify mode | ## Network nodes and gateways Pathport, Pathport DIN P4, Pathport DIN P8, Pathport RM P4, Pathport RM P8 | Action | What it does | | ------------------- | ------------------------------------------------------------------ | | **RDM Discover** | Run an RDM discovery | | **Port DMX Status** | Enable or disable DMX output on a port. **DIN and RM models only** | | **Identify** | Put the device into identify mode | | **Reset** | Reboot the device | ## Managed switches VIA DIN P8, VIA DIN P16, VIA DIN P24, VIA RM P12, VIA RM P12 PoE, VIA RM TE P12 PoE | Action | What it does | | ------------------- | --------------------------------- | | **PoE Power Cycle** | Power-cycle a PoE interface | | **Identify** | Put the device into identify mode | | **Reset** | Reboot the device | ## Vignette Clock Vignette Clock | Action | What it does | | ------------------ | --------------------------------- | | **Fire Snapshot** | Recall a snapshot | | **Set Zone State** | Set the state of a zone | | **Identify** | Put the device into identify mode | | **Reset** | Reboot the device | Source: /documentation/sites/task-actions --- # Scheduling Scheduling runs tasks at times you specify, much like the scheduling built into a project file — but across different devices and projects at once. Task schedulers can be created by anyone with the right permissions, from a desktop browser or a mobile device, without touching the project file. > **Important** > > Devices store no scheduling information locally. Schedules are sent to a device as they are due, so **a device must have an active connection to Cloud for its schedules to run.** > > > _Where the portal has On Device Schedules:_ > > > > Where behaviour has to survive the site losing its connection, use [On Device Schedules](/documentation/sites/on-device-schedules) instead. Those are held on the controller and keep running while it is offline. Cloud Scheduling can be used alongside Real Time triggers in a project file. There is no priority difference between the two, which is worth bearing in mind when programming the project. Scheduling uses the **site's** local time, not the device's, so the site location must be set first — see [Site settings](/documentation/sites/settings). The Events view at the top of the **Scheduling** tab shows what is scheduled to happen on a given site. Select an occurrence in the calendar to disable that single instance. > **Important** > > The calendar view shows occurrences up to 400 days beyond a task scheduler's start date, with new ones added every 30 days. A scheduler that never ends keeps running even beyond the range the calendar displays. ## Creating a task scheduler Select **Create** above the task schedulers table. ### Step 1 - what to run Choose the tasks and actions the scheduler will run. Existing tasks are added by selecting them in the **Tasks** view; they run as normal when the scheduler fires. Add actions instead where no existing task covers what you need. Actions added here are put into a new task when the scheduler is created — rename that task using the hashed-line box above the actions. Choose the device the action runs on from the drop-down. ### Step 2 - when to run **Recurrence.** | Option | Behaviour | | ------------------ | -------------------------------------------------------------------------------- | | **None** | No schedule configured yet; add one later | | **Specific dates** | Pick each date individually | | **Daily** | Days between each recurrence | | **Weekly** | Weeks between recurrences, a start date, and which weekdays to include | | **Monthly** | Months between recurrences, a start date, and which days of the month to include | | **Yearly** | Years between recurrences, a start date, and which dates of the year to include | **Choosing the days.** Weekly, monthly and yearly each ask which days within the period to run on. A monthly or yearly recurrence can cover several days at once, so "the 10th to the 15th of February, every year" is one scheduler rather than six. | Recurrence | How days are chosen | | ----------- | --------------------------------------------------------------------------------------------------------------- | | **Weekly** | Select the weekdays to include | | **Monthly** | **Repeat on** offers **Specific days** — a grid of 1 to 31 — or **The nth weekday**, such as the second Tuesday | | **Yearly** | **Repeat on** offers **Specific dates** — a grid per month — or **The nth weekday of a month** | In a grid, select a day to add or remove it. Drag across several to select a run, or select one day and then shift-select another to fill everything between them. In the yearly grids, selecting a month's name selects that whole month, and selects it again to clear it. Monthly also offers days counted back from the end of the month — **Last day** through **5th from last**. These always exist whatever the month's length, which is what to reach for when you mean "the end of the month" rather than "the 31st". > **Important** > > A day the period does not reach is **skipped silently**. A scheduler set to the 31st runs in the seven months that have one and does nothing in the other five, and 29 February runs only in leap years. The grids mark these days, but Cloud does not move them to the nearest real date — use the end-anchored days where the last day of every month is what you mean. A monthly or yearly recurrence needs at least one day selected before you can continue. When a start date is chosen and no day has been selected yet, its day of the month is selected for you; edit the grid and it stays as you left it. Daily, weekly, monthly and yearly recurrences each end in one of three ways: | Ending | Behaviour | | ----------------------- | ------------------------------------------------------------------------------------------------------- | | **On a date & time** | Nothing runs on or after that moment | | **After n occurrences** | Counts occurrences, not days — three times a day is three occurrences. Up to 400 for monthly and yearly | | **Never ends** | Runs indefinitely | **Times.** Four ways to add them: | Method | Behaviour | | ---------------- | ------------------------------------------------------------------------------------------ | | **Simple** | A specific time. Select **confirm** to add it — multiple can be added | | **Recurring** | An interval plus start and end time. The preview shows every time about to be added | | **Astronomical** | Sunrise or sunset with an optional offset. Maximum of five astronomical times per schedule | | **Time Mask** | Specify hours, minutes and seconds; every matching time is previewed | Remove a time with the **x** in **selected times**, or use **Clear times**. **Priority and date blocking.** Priority affects only other task schedulers, never timeline priorities in the controller's programming, and applies only to exact time matches. Date blocking prevents any lower-priority occurrence from running at any time on a date on which this scheduler occurs. With date blocking off, priority only affects occurrences with exactly the same start time. ![A worked example of date blocking](/assets/26.314.0/scheduling-date-blocking-example-BIcH_lxE.jpg) ### Step 3 - name it Set the scheduler's name, description, occurrence colour and [Offline Device protection](/documentation/sites/schedules#offline-device-protection). A preview of the actions, dates and times is shown here. Select **Create Scheduler**. Cloud then creates the scheduler, a new task if you specified actions, and a default schedule attached to it. Use the events calendar to see active occurrences. ## Offline Device protection Before an event sends anything, Cloud checks every device its actions target. **Offline Device protection** decides how much of that event is abandoned when one of those devices is offline. Set it in step 3 when creating a scheduler, or later from **Settings** in the scheduler's edit view. | Protection | Behaviour | | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Skip only offline device actions** | The default. Only the actions aimed at the offline device are dropped; the rest of that task, and every other task, still runs | | **Skip task with offline device** | The whole task holding that action is dropped, including its actions on devices that are online. The scheduler's other tasks still run | | **Skip schedule with offline device** | Nothing runs. One offline device anywhere in the event cancels every task in it | As a fallback, a device Cloud holds no status for counts as online, and its actions are sent. Skipped work is never queued or retried — the event is finished with, and the next event is checked afresh. An event that skipped something is never reported as a plain success: it shows as a partial success where other work still ran, and as a failure where nothing did. The setting belongs to the task scheduler rather than to the tasks, so the same task run by hand or from another scheduler is unaffected by it. ## When an event does not run An event that did nothing, or less than expected, records why. Select it in the Events view to read the reason held against each task. | Reason | What it means | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | There is an offline device in one of the actions | A device the event targets was not connected. How much was skipped depends on [Offline Device protection](/documentation/sites/schedules#offline-device-protection) | | Failed due to the Site being in a limited state | The site is in Construction or Standby rather than Active, and runs no tasks — see [How Cloud works](/documentation/overview/how-cloud-works) | | Disabled Multi-site device actions | The multi-site the site belongs to has device actions turned off for it | | The task has an action with an invalid status | An action is no longer valid, usually because the project file changed underneath it | | Task scheduler is disabled | The scheduler's toggle is off, so none of its events run | | Disabled occurrence | That single event was disabled from the calendar | | Overriden by | A higher-priority scheduler took the slot — see priority and date blocking above | | Task was not found | The task was deleted after the scheduler was set up | | Internal error occurred | Cloud could not reach the device, or the service carrying the action failed. Contact us with the event and time | The first four are checked before anything is sent, and [Offline Device protection](/documentation/sites/schedules#offline-device-protection) decides how much of the event is abandoned in each of those four cases, not only the offline one. ## Editing task schedulers Select the edit button for a task scheduler in the Options section. From there you can: - Edit the name and settings of the task scheduler immediately - Add, edit or delete its schedules - Add, edit or delete its tasks ## Deleting task schedulers Select the delete button for a task scheduler in the Options section, then confirm. This cannot be undone. Task schedulers can be disabled with the inline toggle switch instead of being deleted. Source: /documentation/sites/schedules --- # Control Panel Control Panel gives the people who use a system day to day a simple set of buttons, each firing a task, without exposing the rest of Cloud. A new site needs Control Panel enabling first, which creates its first page. Control Panel is designed to work best on a mobile device. The editing interface adds a grey background panel to make editing easier. ## Pages Page settings live in the Control Panel settings pane. | Setting | Notes | | -------------------------- | ----------------------------------------------------------------------------------------------------------- | | **Page Title** | Text shown at the top left of the page | | **Page Background Colour** | A solid background colour for the page | | **Page Background** | An uploaded image. Images fit to the page but are **not** scaled down, so a large file will be slow to load | | Action | Notes | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | **Add page** | Specify where in the page order it goes | | **Duplicate page** | Copies all settings including buttons to a specified page order. Pages can be moved this way, then the original deleted | | **Limit Access** | Select which users in the project can see the current page. Pages are silently removed from navigation when a user cannot see them | | **Remove page** | Deletes the page settings. Tasks assigned to its buttons are kept | ### Page types There are six page types, each containing different controls. - **8 Buttons** Up to 8 customisable buttons on a page, each of which can fire a task. - **4 Buttons + Override Controls** Up to 4 customisable buttons that can fire a task, plus a colour wheel override control on the right of the page. - **Override Controls + 4 Buttons** The same, with the override control on the left of the page. - **2 Override Controls** Up to 2 colour wheel override controls. - **Spaces** Direct Space control, with feedback, on devices that support Spaces. - **Tags** Direct Tag control, with feedback, on devices that support Tags. ## Control configuration Different control types have different configuration options, which can also depend on the devices in a site. Every colour in the editor is picked from a field carrying the same two rows beneath it: a **Recent** row of the last eight colours picked in this browser, and a **Proposed colours** row holding the colours this Control Panel already uses, so a new control can be matched to the pages around it. Page background and page title colours are solid; button and Space colours carry an alpha channel as well. ### Buttons **1. Open the button's configuration** by selecting it. **2. Choose what it fires.** Pick existing tasks, or add new actions. Actions added here go into a new task when the button is created — rename it using the hashed-line box above the actions. **3. Enable the button** with the toggle. **4. Set its appearance.** Set the button text, then its background and text colours. A toggle matches it to the Cloud colours instead. **5. Check it.** **Preview** shows the result. Toggle a dark or light background to see how it will look against yours. **6. Save.** Select **Save Changes** to save the button and create a task for any new actions. ### Overrides **1. Open the override's configuration** by selecting it. **2. Select the fixtures** the override control should adjust. Select several by navigating back to the controller list after each selection. **3. Enable the control** with the toggle. **4. Choose the controls it shows** — just the colour wheel, or intensity and colour temperature sliders as well. **5. Optionally label it** and set its colours. Left unset, the Run button takes the Cloud colours. The colour itself is picked on a wheel, sized for a finger on a phone. Drag it, or type the three channel values beside it — each follows the other. Any slider shown has a field of its own that can be typed into as well as dragged. The wheel carries the same **Recent** and **Proposed colours** rows as the editor's pickers. A light has no transparency, so a swatch applies fully opaque here however it was stored, and the colour picked joins **Recent** only when the Run button is pressed. **Show Raw Values (0-255)** reads every channel it covers — colour, colour temperature and intensity — on the 0–255 scale rather than as percentages, which is a choice about reading them only: what the control sends is the same either way. The percentages themselves are shown as whole numbers. In the editor the same control is a preview: the wheel, the toggle and the swatch rows do not respond, because the whole tile is the button that opens this configuration. The rows still show colours picked elsewhere, but a preview can never add one. ### Spaces The Spaces interface works much like the Spaces tab on a supported device — see [Spaces](/documentation/devices/spaces) for how it behaves. 1. Add a Spaces page and select **(configure)** in the Control Panel editor. 2. Pick the device the page controls, then configure the options for the Space interface. 3. Once enabled, spaces can be edited to be pinned or hidden from users. The line above the interface names that device. Before one has been picked it reads **No compatible device has been configured for this page.**, and if the device the page was pointed at has since gone, **Selected device cannot be found. Configure a new one?** ### Tags The Tags interface works much like the Tags tab on a supported device — see [Tags](/documentation/devices/tags) for how it behaves. 1. Add a Tags page and select **(configure)** in the Control Panel editor. 2. Pick the device the page controls, then configure the options for the Tags interface. 3. Once enabled, tags can be edited to be pinned or hidden from users. Tags pages carry the same device line, and say the same when the device is missing. Both page types are available on a multi-site's Control Panel as well as a site's own; there the device list covers the Express controllers across all of its sites. ## Using Control Panel Select **Go to Control Panel**. It works in a desktop browser and is optimised for mobile. Each site's Control Panel has its own URL, from which users cannot navigate into the wider Cloud interface — they sign in and land straight on the panel. A user needs three permissions to use it: - **Site:View all** - **Control Panel:View** - **Task:Execute** Controls behave in different ways: - **Buttons** — select a button to dispatch a task. The button gives no feedback - **Override** — choose overrides and select to dispatch. The override control gives no feedback - **Spaces** — adjust the live controller state and commit the changes, with feedback on the current state. See [Spaces](/documentation/devices/spaces) - **Tags** — adjust the live controller state and commit the changes, with feedback on the current state. See [Tags](/documentation/devices/tags) Source: /documentation/sites/control-panel --- # On Device Schedules _Only where the portal has On Device Schedules._ An on-device schedule runs on the controller itself. Once the controller has it, it keeps running whether or not the site can reach Cloud — through a broken connection, a router swap, or a weekend of no internet at all. That is the difference from [Scheduling](/documentation/sites/schedules), where a Task Scheduler runs in the cloud and fires tasks at the site. If the site is offline, a Task Scheduler cannot reach it; an on-device schedule does not care. | Use | When | | -------------------------------------------- | -------------------------------------------------------------------------- | | [Scheduling](/documentation/sites/schedules) | You want to run a task, across devices, and you can rely on the connection | | On Device Schedules | The behaviour must survive the site losing its connection | > **Changes are not instant, and that is by design** > > Cloud does not push a schedule at a controller. It records what you asked for and waits for the controller to collect it, which usually happens within a few minutes. Until it does, the schedule shows as **Pending**. That is normal, not a fault. ## The schedule list **Schedules** lists everything scheduled on the site's devices. Each row carries a coloured dot, the action it performs, the devices it runs on, and its status on each of them. Expanding a row shows the per-device breakdown. Filter the list with: - the search box, **Search by name or action**; - the source filter — **All sources**, **Cloud** for schedules created here, **Device** for ones the controller published itself. Each row has an **Enabled** toggle, so a schedule can be turned off without being deleted, and an options menu offering **Edit** and **Delete**. ## Creating a schedule **Create schedule** opens a **New schedule** window with three sections. ### Action Pick what the schedule does. The choices are the ones the selected devices actually support, read from the devices themselves: | Action | Does | | ------------------ | ---------------- | | **Activate scene** | Starts a scene | | **Activate tag** | Triggers a tag | | **Turn off** | Turns output off | Name the schedule here too. Leaving the name blank is fine — it is **Auto-generated if left blank**, from the action you chose, giving names like "Activate scene: Old Pink". ### Devices Choose which devices run it. One schedule fans out across every device you select, so the same behaviour does not have to be built several times over. An action only offered by some of your devices restricts the choice accordingly. ### Timing When the schedule is active. An on-device schedule is a span — it has a beginning and an end, rather than being a single moment. **Start.** Either a clock time, or an astronomical anchor: | Anchor | | | ----------------- | -------------- | | **Nautical dawn** | Earliest light | | **Civil dawn** | | | **Sunrise** | | | **Sunset** | | | **Civil dusk** | | | **Nautical dusk** | Last light | Each anchor takes an offset in minutes, before or after, up to a full day. The controller works the actual time out for itself from the site's location, so an anchored schedule tracks the seasons without being edited. **End.** Either a duration after the start, or a specific time. **Repeat.** Daily, weekly, monthly on a chosen weekday, or monthly on a chosen date. A repeating schedule can run forever, until a date, or for a fixed number of occurrences. Add date ranges as exceptions to skip holidays or shutdowns. ## Seeing what is scheduled Beside **Schedules** there are two calendar views: - **Daily** — one day as a timeline from midnight to midnight, each schedule drawn as a band across the hours it is active, with a marker for the current time. - **Weekly** — the same, a week at a time. These are the views for questions the list cannot answer — whether two schedules overlap, whether anything covers a particular evening, what the site is actually doing at 3am. ## Status Because a controller has to collect a change before it takes effect, every schedule carries a status per device. Expanding a row shows all of them. | Status | Means | What to do | | ------------ | ---------------------------------------------------------------------------- | ----------------------------------------------------- | | **Accepted** | The device has it and is running it | Nothing | | **Pending** | Waiting for the device to collect it | Wait. If it stays pending, check the device is online | | **Rejected** | The device refused it, and says why | Read the reason on the row, fix it, and save again | | **Drifted** | The schedule was changed on the device itself, so your change can never land | Reapply, or accept what the device has | ### Reapply **Reapply** sends a change again. It is the answer to both **Rejected** and **Drifted**. Where several devices need it, **Reapply all** does the row at once. > **Reapplying overwrites the device's local edit** > > A drifted schedule means somebody changed it on the controller, outside Cloud. Reapplying replaces their version with yours. If their change was the deliberate one, edit the schedule here to match it instead. ## Schedules the device already had A controller may hold schedules that were never created here — set up before the site was connected, or written by another tool. Those still appear in the list, marked as coming from the device, and are drawn in grey in the calendar views. Some of them the controller publishes as read-only: **Published read-only by the device and cannot be changed from the cloud**. They are shown so that the list is a true picture of what the site is doing, but they cannot be edited or deleted from here. Change them where they were made. Source: /documentation/sites/on-device-schedules --- # Subscription The **Subscription** tab shows every user in a site the state of its subscription. ## Subscription status | Field | Meaning | | ---------------------- | -------------------------------------------------------------------------------------------------------------- | | **Required Site Plan** | The plan this site needs, calculated from the points total of its devices | | **Subscription Plan** | The plan currently active. It should equal or exceed the required plan. Change it by purchasing a subscription | | **Renewal Date** | The date the site moves into Standby mode if it is not extended | | **Site Id** | A unique identifier for the site, used for commercial and support purposes | Quote the **Site Id** when contacting us about a site. ## Extend subscription If a subscription needs to be extended, simply select a duration from the drop down and add that subscription to the cart. You can then checkout to generate a voucher for the site. Learn more about [vouchers](/documentation/reference/vouchers). Sites in standby can follow these same instructions to move them back to active. ## Redeem voucher If you already have a voucher, follow these steps: 1. Paste the voucher into **Redeem voucher** and validate it. 2. Check the subscription plan and length. 3. Check the projected renewal date and plan. 4. Redeem the voucher. ## Subscription history **Subscription History** lists every change made to the site's subscription, newest first. Only a site's owners see it; for everyone else the tab ends above it. | Column | Meaning | | -------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Field** | The setting that changed. Owners are shown changes to **Renewal Date**, **Subscription Plan** and **Construction End Date** | | **Old Value** | The value before the change, or `--` if it was not set | | **New Value** | The value after it | | **Reason** | Why it changed - a redeemed voucher, an automatic renewal, or a manual change | | **Initiator** | Who made it: a user, an API key, or the system | | **Changed At** | When, in the site's timezone | Every column except **Initiator** sorts, and long histories are paged. The table keeps itself up to date while the tab is open, so a change made elsewhere appears without a reload. Source: /documentation/sites/subscription --- # Activity logging Activity Logging shows site owners how and when users have interacted with a site. The tab is visible to site owners only. ## Generating and viewing logs 1. Choose a start and end date for the logs to cover. 2. Optionally filter by action type before generating. 3. The results appear in a table, which can be narrowed further with the search box or by attributes such as initiator and recipient. Logs can take a while to generate. Once they have been generated, they can be filtered further with a text search or across a range of attributes. The **Raw** tab exposes the displayed messages as JSON, so they can be copied into other tools for parsing. Source: /documentation/sites/activity-log --- # API keys _For portal owners. Only where the portal has API keys._ An API key lets an external system make requests to a Cloud site without a person signing in. Anything holding a valid key has the access that key was issued with, so treat a key like a password. A user needs the **API Key management** [permission](/documentation/sites/permissions) for the site to view and work with API keys. ## Generate a key 1. Open the **API Keys** tab. 2. Select **Add new key**. 3. Give the key a name, a description and an expiry time. 4. Copy the key and store it somewhere safe. > **Warning** > > The key value is shown only once, at the point you create it. Cloud cannot show it again. If you lose a key, delete it and generate a replacement. ## Delete a key 1. Select the API key. 2. Choose **Delete** in the toolbar. 3. Follow the prompt to confirm the deletion. This cannot be undone. ## Edit a key 1. Select the API key. 2. Choose **Edit** in the toolbar. 3. Edit the key's name and description, or toggle its suspension state. ## Manage key permissions Set the scope of a key by selecting it in the permissions section of the tab. By default a key is granted all of the site and device permissions available to API keys. These permissions map to the same [permissions](/documentation/sites/permissions) a user holds. ## API key notes Each API key is rate limited three ways at once, and the first limit reached is the one that stops the request. | Limit | Applies to | | -------------------------- | --------------------------------------- | | 300 requests per minute | Everything the key does, added together | | 4 requests every 4 seconds | Any single endpoint | | 1 request every 2 seconds | The device data endpoint | The per-endpoint limit is the one an integrator meets first: an application polling one endpoint hits 4 requests every 4 seconds long before it gets near 300 a minute. If an application is hitting a limit, ask your portal owner. Full documentation for the Cloud API is [published separately](https://sixeye-api.readthedocs.io/en/latest/). Source: /documentation/sites/api-keys --- # Devices Selecting a device in a site shows information specific to that device. Not every device supports every feature, so which tabs appear depends on what the selected device is. | Tab | What it covers | | ------------------------------------------- | -------------------------------------------------------- | | [Overview](/documentation/devices/overview) | Summary of the device | | [Triggers](/documentation/devices/triggers) | Viewing and firing triggers | | [Spaces](/documentation/devices/spaces) | Current playback and overrides | | [Tags](/documentation/devices/tags) | Current device state and overrides | | [Status](/documentation/devices/status) | Current playback and output state | | [Fixtures](/documentation/devices/fixtures) | Fixture status, and replacing a faulty fixture | | [Files](/documentation/devices/files) | Project and firmware files, and transferring them | | [Firmware](/documentation/devices/firmware) | Firmware compatible with the device, and transferring it | | [Log](/documentation/devices/log) | The controller log | | [IO](/documentation/devices/io) | Inputs and outputs | | [Output](/documentation/devices/output) | Live levels per universe | | [Advanced](/documentation/devices/advanced) | Device configuration | Hardware connected to another controller rather than directly to Cloud is covered separately in [Remote devices](/documentation/devices/remote-devices). ## Renaming a device Hover over the device name until the dashed box appears, select the value, and edit it in the box. Source: /documentation/devices/index --- # Overview Reports what the device knows about itself: hardware and software versions, temperatures, network settings, time and date values, and details of the project it is running. Which rows appear depends on what the device type supports, so two devices in the same site can show different overviews. Hover over a row for a tooltip saying when the device last updated that piece of information. A row highlights briefly when the device has just updated it. Uptime and the current date and time are published by the device roughly every ten seconds, with Cloud advancing the value every second in between so the clock keeps moving between updates. Source: /documentation/devices/overview --- # Triggers _Available on_ Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family Lists the triggers in the device's project, sortable by number, name or description. **Fire** fires the trigger. Optionally choose to **Test conditions** at the top of the table, so a trigger only fires if its conditions are met. > **Important** > > Which triggers appear here is controlled by the **Included** property on each trigger in the Designer project file — not by Cloud. If a trigger is missing from this list, that property is where to look. A user needs the **Control** permission to view and fire triggers. See [User permissions](/documentation/sites/permissions). Source: /documentation/devices/triggers --- # Spaces _Available on_ Express, Animate, Perform A device's spaces can be viewed and overridden from this tab. Live updates are on by default, so what you see is exactly what the device is doing, and it updates in real time as space information changes. ## Viewing Spaces Spaces are shown in the same hierarchy as the device's project file. They are collapsed by default and can be expanded one at a time using the expand icon to the left of a parent space's name, or all at once with **Toggle All**. Pin a space using the pin icon inside it. Pinned spaces stay at the top of the tab with their override controls expanded. Pinning is set for the site rather than per user, so everyone with access to the site sees the same pinned spaces. Use the same icon in a pinned space to unpin it. ## Override Spaces Three properties of each space can be changed from here. - **Scene** Change which scene is active in the space. - **Intensity Master** Change the space's intensity master. - **Colour Override** Override the colour fixtures in the space to output a colour you choose. Edits are made inline: select the current value to queue a change to be sent to the device. Several changes can be queued at once, and are committed to the device together when you are ready. A queued edit is shown in bold with an asterisk beside it until it is committed. **Discard** drops every queued edit. Source: /documentation/devices/spaces --- # Tags _Available on_ Express, Animate, Perform A device's tags can be viewed and overridden from this tab. ## Edit tags Live updates are on by default, so what you see is exactly what the device is doing, and it updates in real time as tag information changes. To change the active tag, select it in its tag set. Several changes can be queued at once, and are committed to the device together when you are ready. A queued edit is shown in bold with an asterisk beside it until it is committed. **Discard** drops every queued edit. ## Toggle schedule Devices that support this tab can have their schedule temporarily disabled, which is useful when a manual override needs to last longer than scheduled events would normally allow. Select the toggle to disable the schedule, and select it again to enable it. Source: /documentation/devices/tags --- # Status _Available on_ Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family Shows the current state of the fixture groups, timelines and scenes in the project, sortable by number, name, status and — where it applies — time. Each section paginates, with a page size of 10, 20 or 50. Sections auto-refresh at a ten-second interval; turn **Auto-Refresh** off and you refresh manually instead. Source: /documentation/devices/status --- # Fixtures _Only where the portal has RDM._ _Available on_ Designer LPC Family, Designer MSC Family, Express, Animate, Perform The **Fixtures** tab reports the status of the luminaires attached to a device. It polls them over RDM, shows you which are online, and lets you replace a faulty one remotely — setting the replacement's mode and address and patching it into the existing programming without uploading a new project file. Fixture status has [prerequisites](/documentation/sites/fixtures): a recent enough device firmware version, fixtures that support RDM, and UIDs set in the project file. The [site's fixtures tab](/documentation/sites/fixtures) rolls status up across every device in the site. > **Fixtures and RDM devices** > > A fixture is an entry in your project file. An RDM device is a physical responder that answers a poll. Most fixtures are one device, but a fixture can contain several — which is why the table has two levels, and why a fixture can be partially offline. > **Fixture status monitoring and your subscription** > > A message at the top of the tab records that, while fixture status monitoring is being introduced, the **Fixtures** tab is included in your standard Cloud subscription, and that you will be told in advance if that is going to change. Dismissing the message hides it for you on this site; it turns nothing off. ## Fixture status A fixture's **Status** is a coloured marker, named by the tooltip it carries. The [site summary](/documentation/sites/fixtures) counts the same four, but the dashboard has its own wording for two of them, so the third column below is the word to look for there. | Marker | Meaning | On the site summary | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------- | -------------------- | | **Online** | Every RDM device in the fixture responded to the last poll | **Online** | | **Partial** | Some of the fixture's RDM devices responded and some didn't | **Partially Online** | | **All offline** | No RDM device in the fixture responded | **Offline** | | **Status unknown** | Nothing has been polled for this fixture at all — usually one with no RDM UID in the project file. Grey, rather than coloured | **No Data** | A responder discovered that isn't attached to any fixture in the project has no fixture status of its own. It appears in the unassigned devices panel described below, and the site summary counts it separately, under **Unassigned Devices**. **Status Changed** gives the time of the poll that last moved a fixture between statuses, so a stale timestamp means stable rather than unmonitored. These are the columns the list carries. | Column | What it holds | | --------------------- | ---------------------------------------------------------------- | | **#** | The fixture's number in the project file | | **Name** | Its name in the project file | | **Manufacturer** | Reported by the fixture over RDM | | **Model** | Reported by the fixture over RDM | | **Custom Properties** | How many custom properties the fixture carries | | **Notifications** | Whether this fixture is included in fixture status notifications | | **Status Changed** | When its status last changed | | **Status** | The status above, as a coloured marker | The number and the name are both there because a project file is free to reuse a name: the number is what identifies a fixture, and it is what the replacement dialogs name it by. - **Unassigned devices** A collapsed panel at the top of the page, appearing when a poll finds a responder that isn't in the project. Its heading carries the number found in brackets, and it lists each one by **Uid**, **Output** and **Manufacturer**. - **RDM fixtures only** The table lists every fixture in the project by default, including ones with no RDM UID configured that Cloud can't report on. Select this to hide them. - **Search** Filters the list by fixture name. - **Refresh All** Runs a full status refresh on this device, polling all of its RDM devices. It can take a few moments depending on how many fixtures are in the project, and it asks you to confirm first: a poll can momentarily disrupt lighting output. - **Notifications** Set per fixture. If turned off, events from that fixture are left out of [fixture status notifications](#get-notified-when-a-status-changes) entirely. ### Custom properties A project file can attach arbitrary properties to a fixture — a circuit reference, a position, an asset number. The **Custom Properties** column counts them, and expanding the row lists them as **Property** and **Value** pairs above the fixture's RDM devices. Neither the column nor the table appears on a device whose project file sets none. ## RDM devices within a fixture Select the arrow at the left of a fixture's row to expand it and list the RDM devices belonging to that fixture. | Column | What it shows | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | **ID** | The device's RDM UID | | **Patch** | Protocol and address, such as `dmx:1` | | **Status** | Last known status: **Online** green, **Missing** red, or grey for a responder the device has never reported on, whose marker reads **Unknown** | | **Updated At** | When the last poll updated it | | **Mode** | Current operating mode — editable | | **Start Address** | Current DMX start address — editable | | **Curve** | Dimming curve — editable | The three editable columns write straight to the luminaire, so choosing a value asks you to confirm it first: **Confirm Change** repeats the value you picked, and nothing is sent until you select **Confirm**. A mis-clicked dropdown therefore never reaches the fixture. **Refresh Fixture** polls just this fixture, which is quicker than **Refresh All** when you are checking one repair. It asks for the same confirmation that **Refresh All** does. ### Device options The **Options** menu on each row changes with the device's status. #### When online **Identify On** and **Identify Off** make the luminaire announce itself, so someone on site can find it. #### When missing A responder that stopped answering polls is offered one entry instead of the pair above. **Replace** opens the [Replace missing device](/documentation/devices/fixtures#replace-a-missing-device) dialog, with this responder as the one being replaced. An unassigned device offers all four: **Identify On**, **Identify Off**, **Replace device** and **Add to fixture**. ## Adding a new device Select a discovered **Unassigned device** option menu and select **Add to fixture**. In the following modal, select a target fixture and set parameters for the new device. This device will then be added as part of the fixtures' devices and contribute to its online status. ## Replace a faulty fixture You can swap out a missing or faulty fixture entirely from Cloud. Once the replacement hardware is connected, Cloud configures it and updates the existing programming to use it — no on-site commissioning, no new project upload. **1. Connect the replacement.** Arrange for the new fixture to be installed and connected, which usually means an engineer attending site. They need do nothing beyond that; mode, start address and project assignment are all set remotely. **2. Refresh fixture status.** Select **Refresh All**. The new fixture appears under **Unassigned Devices**. **3. Open the replacement tool.** Two routes, depending on where you start. They open different dialogs, so pick the one that matches what you are looking at: **From Unassigned devices** Use this route when you are starting from the replacement hardware. Expand **Unassigned Devices** at the top of the page. The new fixture is listed there. Select **Options** > **Replace device**, then choose the device to be replaced under step 1. That list names every assigned responder by its fixture **#** and **Fixture** name, so two fixtures sharing a name stay distinguishable. **From a missing device** Use this route when the responder being replaced is already showing as missing — it is quicker, and the dialog knows which device it is about. Expand the fixture's row, find the missing device and select **Options** > **Replace**. That opens a different dialog, in which step 1 asks for the incoming device instead: see [Replace a missing device](/documentation/devices/fixtures#replace-a-missing-device) below. **4. Set the incoming device's parameters.** These are applied to the replacement: **Mode**, **Start Address** and **Curve**. Set them to suit the installation. **5. Review and commit.** Step 3 spells out which RDM device is being unassigned and which is taking its place, naming the fixture by number and name. Read it, then select **Commit**. ## Replace a missing device Starting from a responder that has gone missing runs the same swap the other way round: the fixture and the outgoing device are already known, so the dialog only has to be told which discovered responder replaces it. Its title names the responder being replaced. **1. Choose the incoming device.** **1. Select an unassigned device for replacement** lists the responders this device has discovered but has no fixture for. Where exactly one has been found it is chosen for you. **2. Set the incoming device's parameters.** The same **Mode**, **Start Address** and **Curve** as above, applied to the responder coming in. **3. Review and commit.** The review names both responders and the fixture they are moving between. ## Schedule status refreshes Status is only as current as the last poll, so on most projects it's worth polling on a schedule rather than by hand. Polling is configured in the project file, so the steps differ by system. Either way, results are published to Cloud as soon as the poll finishes and appear on the **Fixtures** tab at both device and site level. **Designer** Create a **Real Time** trigger with a **Start RDM Poll** action. ![A Real Time trigger with a Start RDM Poll action](/assets/26.314.0/fixture-designer-trigger-CcACjg_d.png) Set the Date Time Mask Editor to the frequency you want. The example below fires at 3am every Wednesday: every year, every month, every day of the month, but only where the day name is Wednesday and the time is 03:00:00. ![The Date Time Mask Editor set to 3am on Wednesdays](/assets/26.314.0/fixture-designer-trigger-date-mask-BJD9LiMZ.png) **Express** Go to **Main Menu** > **Edit Project Properties...** > **RDM Polling**. Turn on **Perform RDM Polling?**, choose a **Frequency** and the time to poll **At**. A weekly frequency also lets you pick which days. Select **Commit**. ![RDM polling in Express project properties](/assets/26.314.0/fixture-express-config-DrOz27-X.png) ## Get notified when a status changes Cloud checks each set of poll results against the last known status and raises notifications for anything that has changed. The **Notifications** toggle on this tab sets whether a fixture is included at all. Everything else is per user, on the site's [Settings](/documentation/sites/settings) tab: scroll to notifications and expand **fixture status**. Each of the four statuses can be sent **Instant**, **Daily** or **Weekly**, set for the whole site under **APPLY TO ALL DEVICES** or per device below it. The counts beside each toggle — `4/4`, `1/4` — show how many devices in the site that setting currently covers, so a partial count means some devices have been set individually. A common arrangement is instant alerts for **Offline** and a weekly summary for **Online**, which tells you about failures as they happen without a message every time something recovers. The next poll that finds an offline fixture then sends an email naming the fixture and linking back to the site. Source: /documentation/devices/fixtures --- # Files _Available on_ Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family, Express, Animate, Perform The **Files** tab holds project and firmware files in Cloud, so what a device is running can be changed without a site visit. A transfer from Cloud to the device can be started at any time. All the steps below assume you hold the relevant file permissions — see [User permissions](/documentation/sites/permissions). ## Uploading a project file A project file can be uploaded in Cloud itself, or sent to Cloud from Designer or Express. **Cloud** 1. In Designer or Express, use the relevant **Export Project** to produce a `[filename].upload` file. 2. In Cloud, on the **Files** tab, select **Upload files**. 3. Drag the file into the dialog and select **Submit**. 4. Once uploaded, select it using the control to its left and select **Transfer** from the toolbar. 5. After a short wait, check the device — the new project should be running. **Designer** Assumes you are signed in to Cloud in Designer and have selected a site. 1. On the Network tab, open the **Upload** dialog. 2. Select the devices to upload to on the **devices** tab. 3. Tick **Transfer to devices after Upload to Cloud** if the file should go straight to the device. If left unticked, the file is only added to the device's file list. 4. Select **Upload to Cloud**. The dialog reports one of six states. | Status | Meaning | | ---------------------------- | -------------------------------------------------------------------------------------------------------- | | **Not Logged In** | Close the dialog and sign in using the Cloud icon at the top right of Designer | | Uploading to offline devices | Allowed, but the project only reaches Cloud - it is not pushed to the device | | Ready for Upload | **Upload to Cloud** is enabled and every device shows a solid blue cloud icon | | Uploading | Uploads are queued; the dialog shows progress | | **Upload failed** | Check your internet connection first, then check you hold upload and transfer permissions on that device | | **Upload complete** | Verify in Cloud | Progress is reported per device, and the uploaded file appears on the device's **Files** tab in Cloud whether or not it was transferred. **Express** > **Important** > > Express always prioritises a **local** connection over Cloud. If the device is reachable locally, that is the route Express uses — so to upload over Cloud you have to remove the device from its local connection first. 1. Ensure you are logged in and connected to the correct site. 2. Open the **Upload** dialog. 3. Check that the site's name is listed in the upload dialog, which confirms the upload will go via Cloud. 4. Set whether the file should transfer to the device as soon as it reaches Cloud. Left off, it is only added to the device's file list. 5. Start the upload. Progress is reported on the device, and the uploaded file appears on the device's **Files** tab in Cloud whether or not it was transferred. ## Uploading firmware Firmware can be uploaded here, but the [Firmware tab](/documentation/devices/firmware) carries a library of compatible firmware for the device already and saves uploading anything by hand. Use this route only when the version you need is not in that library. First find the firmware files, which ship with Designer and Express rather than being downloaded separately. | Application | Platform | Where the firmware lives | | ----------- | -------- | ---------------------------------------------------------------------------------------------------- | | Designer | Windows | `C:\Program Files\Pharos Controls\Designer 2\firmware`, or your install directory | | Designer | macOS | Find the Pharos Designer app, right-click, **Show Package Contents**, then `Contents/MacOS/firmware` | | Express | Windows | `C:\Program Files\Pharos Controls\Express\firmware`, or your install directory | | Express | macOS | Find the Pharos Express app, right-click, **Show Package Contents**, then `Contents/MacOS/firmware` | Then, with the file to hand: 1. On the **Files** tab, select **Upload files**. 2. Drag the file in and select **Submit**. 3. Select it and choose **Transfer**. 4. The device restarts and applies the firmware. ## Managing files ### Remove To delete a file from the **Files** tab: 1. Select the file using the button to the left of its row in the table. 2. Select **Remove** in the toolbar. 3. Confirm the deletion by typing the project file name into the validation box. Deleted files cannot be recovered. ### Download To download a file to your computer: 1. Select the file using the button to the left of its row in the table. 2. Select **Download** in the toolbar. 3. The file is downloaded. What you get is the file as it was uploaded, which is not necessarily the file the device is running now. For that, see [Request file](/documentation/devices/files#request-file). ### Transfer To transfer a file to the device: 1. Select the file using the button to the left of its row in the table. 2. Select **Transfer** in the toolbar. 3. Confirm the transfer. The file is then transferred to the device. Transfers cope with poor internet connections by sending the file in small sections. Check the device's [log](/documentation/devices/log) for more about the transfer. > _For portal owners:_ > > To transfer one file to devices across several sites at once, see [My Files](/documentation/portals/my-files). ### Schedule Transfer To schedule a file transfer to the device: 1. Select the file using the button to the left of its row in the table. 2. Select **Schedule transfer** in the toolbar. 3. Choose a date and time for the transfer, given in the site's local time. 4. Save the changes. 5. The file's row then shows when the transfer is scheduled. To edit or delete a scheduled transfer, select the file again and choose **Schedule transfer** in the toolbar. ## Request file A project file can be requested from the device, so the version you work on is the one actually running. 1. In the **Project file** section, choose **Request download**. 2. The device processes the request and uploads the file to Cloud. 3. The transfer may take some time. 4. Once it is complete, choose to download or delete the file. 5. The file is cleared after 24 hours. Once you have made changes to the file, upload it back to the device the same way as [outlined above](/documentation/devices/files#uploading-a-project-file). Source: /documentation/devices/files --- # Firmware _Available on_ Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family, Express, Animate, Perform The **Firmware** tab carries a library of firmware compatible with the current device, which can be transferred to it without uploading firmware files by hand. Uploading firmware yourself is covered on the [Files tab](/documentation/devices/files). ## Transfer To transfer a firmware file to the device: 1. Select the firmware file using the button to the left of its row in the table. 2. Select **Transfer** in the toolbar. 3. Confirm the transfer. The firmware file is then transferred to the device. Firmware transfers cope with poor internet connections by sending the file in small sections. Check the controller's [log](/documentation/devices/log) for more about the transfer. ## Schedule Transfer To schedule a firmware transfer to the device: 1. Select the firmware file using the button to the left of its row in the table. 2. Select **Schedule transfer** in the toolbar. 3. Choose a date and time for the transfer, given in the site's local time. 4. Save the changes. 5. The firmware file's row then shows when the transfer is scheduled. To edit or delete a scheduled transfer, select the file again and choose **Schedule transfer** in the toolbar. > **Note** > > A firmware file may carry compatibility notes. Read them before transferring the file, so you know it suits the device you are sending it to. Source: /documentation/devices/firmware --- # Log _Available on_ Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family, Express, Animate, Perform The device's log, with a row per message. The log level is set with the drop-down above the log view. This changes the device's actual log level rather than filtering what is already there, so the **Maintenance** permission is required to adjust it. See [User permissions](/documentation/sites/permissions). The number of log messages shown at a time can be adjusted. Larger numbers of log lines may cause performance issues on the device. > **Note** > > Refresh is **off** by default, to keep network traffic down. On page load the device publishes its most recent messages, and after that nothing updates until you refresh manually with the arrow in the refresh settings — which asks the device to publish again. Source: /documentation/devices/log --- # IO _Available on_ Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family IO modules attached to the device can report status information to this tab. Whether a module reports status is a property of the module rather than of Cloud. For which ones do, see the [Pharos IO Modules page](https://www.pharoscontrols.com/support/designer/resources/io-modules/). Source: /documentation/devices/io --- # Output _Available on_ Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family, Express, Animate, Perform Shows the controller's output, by protocol and port. Use the drop-downs above the view to change either. > **Important** > > Refresh is **off** by default to keep network traffic down. The controller publishes current values on page load, then only when you refresh manually — though switching protocol or port also forces a fresh publish. Source: /documentation/devices/output --- # Advanced More advanced device configuration. | Setting | What it does | | ----------------------- | --------------------------------------------------------------------------------------------- | | **Beacon device** | Flashes all the device's status LEDs. On a touch device the screen backlight pulses instead | | **Reset device** | Soft reboot | | **Date & Time** | Adjust the device's local date and time | | **Watchdog** | Enable or disable the watchdog | | **Format Device** | Clears the memory card without losing the Cloud connection | | **Time Report Offline** | How long in minutes a device has to be offline before any connection notifications are raised | These need the **Maintenance** permission — see [User permissions](/documentation/sites/permissions). > **Important** > > Network settings are deliberately absent. A device that loses its route to the internet cannot be recovered remotely, so those stay local-only. Source: /documentation/devices/advanced --- # Remote devices _Available on_ Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family, Express, Animate, Perform Shows every Remote device joined to this device. Expand a row with the arrow for status information about its operation, including input states on devices that support it. ## Syncing firmware A joined device whose firmware is incompatible with the device's own is flagged with a warning. Select **Sync Firmware** to instruct the linked device to download firmware compatible with the device's current firmware. > **Note** > > The firmware is downloaded by **the device** and passed on to the Remote device directly. Watch the [device's log](/documentation/devices/log) to follow the process. ## Unjoined devices The **Unjoined Remote Devices** table lists Remote devices on the same network as the device that are not in its project file. > **Important note about TPS** > > A TPS running firmware 2.14.0 or above appears as a Remote device and behaves as described above. > > A TPS on an earlier firmware version has to connect as a device of its own, like any other [device](/documentation/sites/devices). > > To upgrade a site with a TPS to 2.15.0 or newer, the TPS first needs upgrading to the latest 2.14.x version using the [Firmware tab](/documentation/devices/firmware), and then its firmware synced to the linked device. Source: /documentation/devices/remote-devices --- # About Portals _For portal owners._ > _For portal owners:_ > > A portal sits above sites and lets one organisation administer many of them. > > With a portal, you can apply your own branding and colours, serve Cloud from your own domain, add sites and users as you need them, and manage notifications across the whole estate. > > A portal also enables multi-sites, which drive several sites from a single Control Panel and schedule. That suits an organisation where individual site owners keep day-to-day control but a central team — a city authority, a campus estates department, a head office — needs to operate everything at once. > > | Capability | Topic | > | --------------------------------------------- | ------------------------------------------------------- | > | Several sites, one Control Panel and schedule | [Multi-sites](/documentation/portals/multi-sites) | > | Adding sites, employees and end users | [Administration](/documentation/portals/administration) | > | Every site, user and device in one list | [Portal-wide lists](/documentation/portals/lists) | > > > _Where the portal has portal-wide file uploads:_ > > > > > _On portals with Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family, Express, Animate, or Perform:_ > > > > > > One file can also be sent to many devices of the same model across every site — see [My files](/documentation/portals/my-files). > > ## Per-portal features > > Not every feature is switched on for every portal. These are the ones that are decided portal by portal rather than shipped to everybody, so a topic describing one may cover something your portal does not have. Ask your portal's support contact to have any of them enabled. > > | Feature | What it adds | > | ---------------------- | ------------------------------------------------------------------------------------------------------- | > | API keys | Lets an external system make requests to a site without a person signing in | > | Authentication options | Sign-in methods beyond email and password — single sign-on, passkeys, and a two-factor policy | > | Fixture status | Polls the luminaires attached to a device over RDM, and reports their status per fixture and per site | > | My files | Transfers one file to many devices of the same model, across sites | > | Notifications | Emails users when devices, fixtures or subscriptions change state | > | On Device Schedules | Puts a schedule on the device itself, so it keeps running while the site is offline | > | User Roles | Named sets of permissions, assigned to a user at portal, multi-site or site level | > | Vouchers | Lets a site's subscription be renewed by redeeming a voucher, bought and paid for without involving you | Source: /documentation/portals/index --- # Multi-sites _For readers with multi-site access._ > _For portal owners:_ > > A multi-site combines several stand-alone sites into one place, from which you can drive and override all of them. > > A multi-site offers most of the same tabs a site does. For how any one of them works, see the [Sites](/documentation/sites/index) section. > > ## Sites > > The **Sites** tab lists the sites linked to this multi-site. Expand the map view to see them plotted, each at the location set in its own **Settings**. > > ![A multi-site's map view showing its child sites](/assets/26.314.0/multi-site-map-lm5IjyX_.webp) > > A site's label on the map is coloured by the state of the devices inside it. > > | Colour | What it means | > | ------ | ----------------------------------------------------------- | > | Green | Every device in the site is online | > | Amber | One or more devices in the site are offline or unassociated | > | Red | Every device in the site is offline or unassociated | > > ## Settings > > Set a location for the multi-site. Anything scheduled in the multi-site uses it. > > > **Note** > > > > Scheduling created in a multi-site runs to the multi-site's own local time, not the local time of the site it acts on. A multi-site spanning several time zones fires everywhere at once, not at each site's own clock. > > ### Site links > > Sites are linked to the multi-site from this tab. > > Select **Add new link...** to link a site. You need the **Owner** permission in both the multi-site and the site you are linking. > > The same permissions let you unlink a site: choose **Options** on its row and then **Unlink**, and confirm in the **Unlink from Multi-site** dialog that opens. > > Creating or deleting a link emails every **Owner** of the child site, so the people responsible for a site always know it is being driven from above. > > ## Tasks > > The **Tasks**, **Scheduling** and **Control Panel** tabs of a multi-site can use tasks belonging to the multi-site itself and to any of its child sites. > > Check the filtering on those tabs when you are editing a behaviour, or you may be looking at only some of the tasks available to it. Editing an action that runs on a child site needs permission to edit it in that child site; firing a task from the multi-site does not need execute permission in the child sites it reaches. > > Every site with a linked multi-site gains a task action that enables or disables actions being fired from a multi-site. Disabled, the child site ignores anything the selected multi-site fires at it — which is how a site owner keeps local control of something a central team would otherwise override. Only a user who belongs to both the multi-site and the child site can create that action. Source: /documentation/portals/multi-sites --- # Administration _For portal owners._ > _For portal owners:_ > > A portal owner has access to features that make administering many sites at once straightforward, instead of visiting each site in turn. > > ## Permissions > > A portal owner gets a dedicated permissions menu item, which presents permissions across the three contexts a portal has: > > - Sites > - Multi-sites > - Portal > > **Sites** and **Multi-sites** give you one interface for adjusting permissions across different sites without opening each of them. Add sites to the list or remove them to choose what you are managing. > > **Portal** gives you a whole-portal context for permissions. Granting a permission here grants it to the selected user in that context, with a few special cases below where a permission also enables a feature. > > For example, a user with **Portal:User:Add** can add users to any site they can see, anywhere in the portal, whatever their permissions in that site are. > > That is what makes a portal worth administering as one thing. If your engineers need the same base access everywhere, grant it once at portal level; adding an engineer to a site is then just adding them, plus whatever that one site needs on top. > > As in any other permissions view, permissions can be copied between users by selecting a user's initials at the top of their permissions column. > > Note that a user with any permission at all granted at portal level can see every portal permission. > > ### Special cases > > These portal permissions do something beyond granting their own permission. > > | Permission | Notes | > | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | **All sites:All sites:View all** | Enables the **Sites** tab, where the user can see [every site in the portal](/documentation/portals/lists) | > | **All sites:Financial:Auto renew** | Enables the auto renew workflow in a site. Can only be set by a system administrator | > | **All sites:Financial:Billing purchase** | The user can renew a site's subscription from its [Subscription](/documentation/sites/subscription) tab | > | **All sites:Owner** | Grants the portal admin role — every view and set permission in the **Portal** context — and enables the other portal-level features. Can only be set by a system administrator | > | **All multi-sites:All multi-sites:View all** | Enables the **Multi-sites** tab, where the user can see [every multi-site in the portal](/documentation/portals/lists) | > | **All multi-sites:Owner** | Lets multi-sites be viewed and edited | > | **All users:All users:View all** | Enables the **Users** tab, where the user can see [every user in the portal](/documentation/portals/lists) | > | **All users:All users:Add** | The user can add users in the **Users** context without adding them to a site | > | **All users:All users:Reset two factor** | The user can reset other users' two-factor authentication secrets | > | **All users:All users:Suspend** | The user can suspend and unsuspend users | > > Suspension is portal-wide rather than per site, so a suspended user cannot sign in at all — see [Managing users](/documentation/sites/users). Source: /documentation/portals/administration --- # Portal-wide lists _For portal owners._ > _For portal owners:_ > > A portal owner sees three extra menu items that a site user does not: **Sites**, **Multi-sites** and **Users**. Each widens one of the lists you already know from your own sites to cover the whole portal. > > Each is enabled by its own permission, so a user can be given one without the others — see [Administration](/documentation/portals/administration) for which permission turns on which menu item. > > ## Sites > > Every site in the portal, whether or not you belong to it. The columns are the same as the list on your own [Sites](/documentation/sites/index) page: > > | Column | Shows | > | ---------------- | ---------------------------------------------------------------- | > | **Site** | The site's name, with its state beside it where it is not active | > | **Team** | How many people belong to the site | > | **Devices** | How many devices the site holds | > | **Renewal Date** | When the subscription next needs extending | > | **Options** | Actions for the site | > > The status cards above it count every site and device in the portal rather than only yours, which is what makes this the page to open when you want to know whether anything anywhere needs attention. There is no map here; the map is on your own sites. > > Opening a site from this list takes you into it exactly as if you belonged to it. > > ## Multi-sites > > Every multi-site in the portal. For what a multi-site is and how to link sites into one, see [Multi-sites](/documentation/portals/multi-sites). > > | Column | Shows | > | -------------- | ---------------------------- | > | **Multi-site** | The multi-site's name | > | **Team** | How many people belong to it | > | **Created** | When it was created | > | **Options** | Actions for the multi-site | > > ## Users > > Everyone in the portal, including people who belong to no site yet. > > | Column | Shows | > | -------------- | ------------------------------------------------------- | > | **First name** | The user's first name | > | **Last name** | The user's last name | > | **Email** | The address they sign in with, and where invitations go | > | **Status** | Whether the account is active, invited or suspended | > > Portals that bill through Cloud also show a **Discount** column, and portals that enforce two-factor authentication per user show **2FA enforcement**. > > This is the one place a user can be added without adding them to a site at the same time, and the place to suspend one. Suspension is portal-wide rather than per site, so a suspended user cannot sign in at all — see [Managing users](/documentation/sites/users). Source: /documentation/portals/lists --- # My files _For portal owners. Only where the portal has portal-wide file uploads._ > _For portal owners:_ > > _Available on_ Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family, Express, Animate, Perform > > The **My Files** tab transfers one file to several devices of the same model at once, across every site in the portal — so a show file, a firmware image or a media asset goes out in one operation rather than site by site. > > ## Add files > > Add a file either by uploading it from your computer with **Upload file**, or by promoting a file already uploaded to the **Files** tab of a device you have permission to see. > > Once it is added, give it a name and a description. That is all the reader of the list has to go on later, so name it for what it does rather than what the file happens to be called. > > ## Transferring a file > > In a file's options drop down, choose **Transfer**. In the modal that opens, pick the devices across the portal you want it sent to, or check **All matching devices** to send it to every device of that model in the list. > > The **Select devices** multi-select box searches the list, which is worth using before you reach for **All matching devices** on a large portal. > > ## Editing files > > **Edit** in the **Options** drop down changes a file's name and description; **Delete** removes it. Source: /documentation/portals/my-files --- # Vouchers _Only where the portal has vouchers._ A voucher carries a site plan and a duration. Redeeming one is the usual way to start or renew a site's subscription in Cloud. (_Where the portal has card payments for vouchers:_ It is self-served throughout: you buy the voucher by card and redeem it yourself, against a new site or an existing one.) (_Where the portal does not have card payments for vouchers:_ Your portal supplies the vouchers rather than selling them in the app, and you redeem them yourself, against a new site or an existing one.) > _Where the portal has card payments for vouchers:_ > > ## Purchasing vouchers > > > **Pricing disclaimer** > > > > Any figures above are examples, and the plan shown is priced for one example selection rather than requoted as you move the slider. What a plan costs, which currencies you can pay in and what discounts apply are all set by your portal, and the checkout is the only place that states them. > > ### Select a plan > > Site subscriptions are sold as plans, named Plan A to Plan G with intermediate Plan A+, B+ and C+ levels. Each connected device is worth a number of points, and plans further along the alphabet cover more points - and so more devices. > > There are two ways to find the plan a site needs. > > 1. Open the site's [Subscription](/documentation/sites/subscription) tab and read **Required Site Plan**. It is calculated from the devices already connected, and it also shows the points they use. > 2. Add up the points of the devices you intend to connect, (_Where the portal has a published supported devices list:_ using [Supported devices](/documentation/reference/devices)), (_Where the portal does not have a published supported devices list:_ though your supplier can confirm the points each model uses), and match the total against the thresholds below. > > Once you know the level you need, set it with the points slider or the quick plan selection buttons. > > #### Plan point thresholds > > The plan selector on this tab names the points each plan covers as you move the slider, so the level can be confirmed there as you buy. > > | Plan | Maximum points | > | ------- | -------------- | > | Plan A | 10 | > | Plan A+ | 15 | > | Plan B | 30 | > | Plan B+ | 38 | > | Plan C | 60 | > | Plan C+ | 70 | > | Plan D | 100 | > | Plan E | 150 | > | Plan F | 200 | > | Plan G | 250 | > > ### Select a duration > > Choose how long the subscription should run for. Where your portal offers a discount for committing to several years, it is shown against the longer durations as you pick. > > ### Select plan delivery > > Most projects need a single plan, and the default selection here is the one to take. > > Where a project is several sites, one purchase can be split into several smaller plans, each delivered as its own voucher. Select **Show more** to see the split options available for the plan you have chosen; they change as you adjust it. Only the plan is split, never the duration. > > ### Add to cart > > Check the summary at the bottom of the page before adding, and choose the currency you want to pay in. Several purchases can sit in the cart at once. > > ### Checking out > > Once everything you want is in the cart, follow the checkout. At any point you can select the **?** at the top right for a description of the step you are on. > > You need a valid billing address and card details. VAT numbers and an invoice reference are optional. > > When the payment has gone through, you are taken to your purchase history, where the voucher can be read and copied. An invoice is emailed to you automatically, and can also be downloaded from the options drop down against each order. > > > _For portal owners:_ > > > > > **Important** > > > > > > A voucher is only valid in the portal it was bought in. ## Redeeming a voucher How you redeem a voucher depends on whether the site already exists, and on whether the person redeeming it has an account yet. **A new site** Use this when you are signed in and the voucher is to create a site. 1. Open the user menu and choose **Redeem voucher**. 2. Paste the voucher in and validate it. 3. Check that it gives the plan and length you need. 4. Name the new site. 5. Give the email address of the site's first user. It defaults to you. 6. Confirm and redeem. **An existing site** Use this to extend a site that already exists. 1. Go to the site's [Subscription](/documentation/sites/subscription) tab. 2. Find the **Redeem voucher** section. 3. Paste the voucher in and validate it. 4. Check the plan and length, and the projected renewal date and plan it produces. 5. Redeem the voucher. **A new site, without an account** Use this when whoever holds the voucher has no account yet - it creates the site and their account together, without an invitation. 1. On the sign-in page, select **Redeem Voucher for a new Site**. 2. Paste the voucher in and validate it. 3. Check that it gives the plan and length needed. 4. Name the new site. 5. Give the email address of the site's first user. It can be an existing account, and whoever it is receives the **Owner** permission. 6. Confirm and redeem. A voucher can only be redeemed once. See [Subscription FAQs](/documentation/troubleshooting/subscription-faqs) for more on how subscriptions behave. Source: /documentation/reference/vouchers --- # Supported devices _Only where the portal has a published supported devices list._ Every device family Cloud can manage is listed below, with the points each device contributes to its site's total. Points are what a site plan is sized against: add up the points of the devices you intend to connect and that total is the plan the site needs. The site's [Subscription](/documentation/sites/subscription) tab does the same sum for the devices already connected. > _Where the portal has vouchers:_ > > [Vouchers](/documentation/reference/vouchers) lists which plan covers which point total. ## Designer LPC Family | Device | Manufacturer | Points | | ------ | ------------ | ------ | | LPC | Pharos | 10 | | LPC X | Pharos | 30 | | TPC | Pharos | 10 | | MSC | ETC | 10 | | MSC X | ETC | 30 | | MTPC | ETC | 10 | ## Designer VLC Family | Device | Manufacturer | Points | | --------- | ------------ | ------ | | VLC | Pharos | 30 | | VLC Plus | Pharos | 30 | | Atlas | ETC | 30 | | Atlas Pro | ETC | 30 | ## Express controllers | Device | Manufacturer | Points | | --------------- | ------------ | ------ | | Express Control | Pharos | 10 | ## Acuity Brands controllers | Device | Manufacturer | Points | | ------- | ------------- | ------ | | Animate | Acuity Brands | 10 | | Perform | Acuity Brands | 10 | ## Network nodes and gateways | Device | Manufacturer | Points | | --------------- | -------------------- | ------ | | Pathport | Pathway Connectivity | 2 | | Pathport DIN P4 | Pathway Connectivity | 2 | | Pathport DIN P8 | Pathway Connectivity | 2 | | Pathport RM P4 | Pathway Connectivity | 2 | | Pathport RM P8 | Pathway Connectivity | 2 | ## Managed switches | Device | Manufacturer | Points | | ----------------- | -------------------- | ------ | | VIA DIN P8 | Pathway Connectivity | 2 | | VIA DIN P16 | Pathway Connectivity | 2 | | VIA DIN P24 | Pathway Connectivity | 2 | | VIA RM P12 | Pathway Connectivity | 2 | | VIA RM P12 PoE | Pathway Connectivity | 2 | | VIA RM TE P12 PoE | Pathway Connectivity | 2 | ## Vignette Clock | Device | Manufacturer | Points | | -------------- | -------------------- | ------ | | Vignette Clock | Pathway Connectivity | 6 | Source: /documentation/reference/devices --- # Signing in Cloud signs you in with your email address and a password. Accounts cannot be created from the sign-in page: you are invited to a site first, and the invitation email is what lets you set a password. See [Quick start](/documentation/overview/quick-start). Everything below is an additional sign-in method a portal can offer. Which of them you are given depends on what your portal has turned on and on what you have set up for yourself. ## Two-factor authentication With two-factor authentication set up on your account, a six-digit code is asked for after your email address and password have been accepted. The code comes from an authenticator app and changes every few seconds, so a stolen password on its own is not enough to sign in. You turn it on yourself, under **Two Factor Authentication** on your profile - see [User options](/documentation/reference/user-options). A portal or an individual site can also require it, in which case you are prompted to set it up the next time you sign in. ## Passkeys A passkey signs you in with your device's fingerprint reader, face recognition or screen lock instead of a password. In a browser that supports them you are offered the chance to create one when you sign in, and the passkeys you have are listed under **Passkeys** on your profile - see [User options](/documentation/reference/user-options). > _For portal owners:_ > > ## Microsoft SSO > > A portal can have Microsoft SSO enabled. Where it is, the sign-in page offers to sign in with a Microsoft account. Choosing it hands the user to Microsoft to authenticate, and if the email address on the Microsoft account matches a user account in the portal, they are signed in as that user. Source: /documentation/reference/signing-in --- # User options Select the user icon at the top right of any page to open the user menu. ## Profile Your profile holds the settings that belong to your user account rather than to any one site. ### Details Your **First Name**, **Last Name**, **Email** and **Phone number**. Select the text to edit it in place. > **Note** > > Changing your email address leaves your existing sessions signed in, but new sign-ins have to use the new address. ### Change password Enter your current password and the new one. If the new password passes validation it takes effect immediately. ### Two-factor authentication Two-factor authentication asks for a code from an authenticator app as well as your password. If you have not set it up, this section prompts you to. 1. Scan the QR code with an authenticator app - [Proton Authenticator](https://proton.me/authenticator) for example. 2. The app then shows a six-digit code, which refreshes regularly. 3. Enter your password and a recent code. 4. Select **Submit**. 5. The next time you sign in you are asked for a fresh code. Once it is set up, two further options appear. #### Refresh secret key Generates a new secret key, following the same steps, while leaving two-factor authentication switched on. This is what to use when moving to a new phone or a different authenticator app. #### Disable two-factor authentication Switches two-factor authentication off for your account. If your portal or any site you belong to requires it, you are prompted to set it up again the next time you sign in. ### Passkeys A passkey lets you sign in with your device's fingerprint reader, face recognition or screen lock instead of a password. A passkey belongs to the browser and device it was created on, so register one for each browser you sign in from. Each entry in the **Passkeys** panel names the operating system and browser it was registered on, and the date it was added. #### Register a passkey 1. Select **Register new passkey**. 2. Follow the prompts from your browser or operating system to confirm with your fingerprint, face or screen lock. The passkey joins the list, named after the operating system and browser you registered it on. #### Remove a passkey Select **Remove** beside the passkey. Do this when you no longer use that browser or device, or if the device is lost. ### Notifications The notifications sent to you over the last 90 days, filterable to particular sites and devices. For where they come from and how to change what you receive, see [Notifications](/documentation/reference/notifications). > _Where the portal has vouchers:_ > > ### Billing configuration > > Your default billing details and currency, used when you buy [vouchers](/documentation/reference/vouchers). > _Where the portal has vouchers:_ > > ## Redeem voucher > > Starts redeeming a voucher against a new site. See [Vouchers](/documentation/reference/vouchers). ## Sessions A session is created each time you sign in and stays valid until it expires or is invalidated. The **Sessions** panel lists yours, so you can see where your account is signed in and sign out of anything you no longer use. | Column | Description | | -------------- | -------------------------------------------------------------------------------------------------- | | **User agent** | The browser and operating system the session was created from | | **Created** | The date you signed in | | **Last used** | The date the session was last active | | **Expires** | The date the session expires and you have to sign in again | | **Status** | **Current Session** for the one you are using now, or **Active** for a session that is still valid | | **Options** | Actions for the session | Only current and active sessions are listed by default. Turn on **Show expired/invalidated** to include the rest. ### Invalidate a session To sign one session out, select **Options** on its row and choose the invalidate action. To sign every session out at once, select **Invalidate All**. ## Updating the app When a new version has been released, a banner appears at the top of the page reading **A new version of the app is available.** Select **Update!** and the page reloads on the new version. Nothing you were looking at is lost beyond the page itself; you stay signed in. > **This is your browser only** > > The banner is about the copy of the app running in the browser tab in front of you, not about the portal. Taking the update, or ignoring it, changes nothing for anyone else, and does not update the app for your colleagues or on your other devices — each browser notices the new version for itself, and shows its own banner. ## Sign out Signs you out immediately and invalidates the session you are using. Source: /documentation/reference/user-options --- # Designer actions _Available on_ Designer LPC Family, Designer MSC Family, Designer VLC Family, Designer Atlas Family Designer has three Cloud-specific trigger actions, so a device can reach into Cloud rather than only the other way round. ## Remote Site Notification Sends a notification to the site's subscribed users. Choose **Warning** or **Error** and give a message. Each notification carries the type, the message, the device and site it came from, a timestamp generated by the site, and a link straight to the device. > **Important** > > The action can only be configured while Designer is signed in to the site, at the time of upload. ## Run Remote Site Task Runs one of the site's tasks. To pick the task you have to be signed in to the site in Designer with permission to interact with tasks, and the device has to belong to that site. > **Important** > > Once it is configured the device runs the task itself, so user permissions no longer apply. A task wired into a trigger fires whether or not anyone is signed in. ## Rerun Remote Site Task Asks Cloud to re-send the last task action a task scheduler dispatched to this device. Use it to restore Cloud overrides lost when a device reboots. For more on Cloud integration in Designer, see the [Pharos Designer trigger action help](https://dl.pharoscontrols.com/software_help/designer2/Default.htm#help/reference/trigger/actions.htm?TocPath=Reference%257CTrigger%257C_____4) and its **Remote Management Actions** section. Source: /documentation/reference/designer-actions --- # Notifications _Only where the portal has notifications._ Cloud tells you when something changes on a device without you having to watch for it. Notifications reach you in three places, and they are the same notifications throughout: a bell in the top bar for what has just happened, a log in your profile for what happened over the last 90 days, and an email if you asked for one. What you are told about is set per site, so a person responsible for one site is not paged about another. ## The bell The bell sits in the top bar on every page and carries a mark when something has arrived since you last looked. Selecting it opens the recent notifications, newest first, with **Load more...** at the bottom of the list. With nothing to show it reads **No notifications to display**. Each notification can be marked read or archived on its own row, or you can clear the lot with **Read all** and **Archive all**. Archiving takes a notification out of the bell; it stays in the log. **View all** opens the full log in your profile. ## The log Your profile's **Notifications** section holds everything sent to you over the last 90 days, filterable to particular sites and devices. Anything older has been removed. See [User options](/documentation/reference/user-options). ## Choosing what you are told about Notification settings live on each site's **Settings** tab — see [Site settings](/documentation/sites/settings). Choose them per device, or across every device in the site at once. Four types are available. | Type | Fires when | | ------------------ | --------------------------------------------------------------------------- | | **Connection** | A device changes online status (tolerant of brief outages) | | **Warning** | A device raises a warning notification | | **Error** | A device raises an error notification | | **Fixture Status** | A device reports a [fixture status](/documentation/devices/fixtures) change | > **A device has to be offline for a while before it counts** > > Connection notifications do not fire the moment a device stops answering, or a brief network blip would page everyone. Each device has its own **Time Report Offline** setting — see [Advanced](/documentation/devices/advanced) — and the notification is raised only once the device has been unreachable for that long. ## How often Delivery is per user, so two people watching the same site can be told at different intervals. | Schedule | What arrives | | -------- | --------------------------------------------------------------- | | Instant | Sent as soon as the notification is processed | | Daily | One message at the end of the day, bundling everything from it | | Weekly | One message at the end of the week, bundling everything from it | A digest is one message however many notifications it holds, so a device flapping overnight is a line in tomorrow's summary rather than a hundred emails. Source: /documentation/reference/notifications --- # Device will not connect If a device sits at **Connecting** and never reaches **Connected**, it is almost always network configuration. Settings that can be ignored on a local network have to be set for a device to reach the internet. ## Check these first Both of these are set on the device itself, in whichever configuration application its manufacturer provides. - **Default gateway** The IP address of the device that gives this one its route to the internet — usually the router. Without it, the device has no way out of the local subnet. - **DNS servers** A primary and a secondary DNS server address, so the device can resolve the Cloud service address. Some networks provide their own; public DNS servers also work. ## Network blocks The most common reason for a device not being able to connect is a network stopping it from reaching the internet at all, especially on larger managed networks. See [Network requirements](/documentation/troubleshooting/network) for the addresses and the port a device needs, and for what to ask a network administrator to allow. Source: /documentation/troubleshooting/wont-connect --- # Network requirements What a device needs from the network to reach Cloud, and how the connection is secured. If a network administrator has to approve the installation, this page is the one to send them. ## Network security The platform was designed with security as a first principle, and is intended not to put your network at risk. Devices running the SixEye SDK communicate with the cloud back end and share status information. The tunnel between the device and the back end allows actions to be run on that specific device, and lets the device pull down new firmware or configuration settings. ### Does Cloud expose my network? No. The technology establishes communication only between the specific devices running the SixEye SDK and the back end. Users cannot reach the rest of your network through it. A device running the SDK only supports the features and file types its own manufacturer supports. A lighting device, for example, accepts only its proprietary firmware and project files — it cannot be loaded with generic scripts or executables. ### What connectivity do devices require? A device needs a valid gateway IP address with internet access and a DNS server IP address, in the same way any computer does. Devices make secure outbound connections to remote servers using TLS 1.2 or higher (TLS 1.3 where the endpoint supports it). To perform initial authentication, a device makes a handful of short-lived connections to AWS servers in London, UK. Once authentication completes, the device creates and holds a single TLS connection to an AWS server in London, UK, which carries two-way communication with the device. Devices need access to the following addresses. | Address | What the device uses it for | | ------------------------------------------------------------- | ------------------------------------------------------------------------ | | `a33z5x8196i4vy-ats.iot.eu-west-2.amazonaws.com` | The held connection carrying two-way communication | | `sixeye-firmware-files-production.s3.eu-west-2.amazonaws.com` | Firmware downloads | | `sixeye-file-uploads-production.s3.eu-west-2.amazonaws.com` | Files the device sends up, such as logs and project backups | | `sixeye-file-downloads-production.s3.eu-west-2.amazonaws.com` | Files the device pulls down, such as project files and content | | `cognito-idp.eu-west-2.amazonaws.com` | Initial authentication | | `cognito-identity.eu-west-2.amazonaws.com` | Initial authentication | | `primary.sixeye-api.com` | The back end API | | `dl.pharoscontrols.com` | Required only for access to Pharos Controls remote device firmware files | Every connection uses HTTPS to port 443 on the remote server. All other connections are closed, and no inbound connections are required. Blocking all inbound connections with a properly configured firewall is recommended. > **These addresses can change** > > They are accurate at the time of writing. Some may be retired and others added during ongoing development. Specific IP addresses cannot be supplied, because the underlying services use dynamic IP addressing for load balancing — a firewall rule has to be written against the hostname, not an address. ### Does Cloud support encryption of data in motion? Yes. Encryption of data in motion is always on and cannot be disabled. All connections use HTTPS to port 443 on remote servers over TLS 1.2 or higher (TLS 1.3 where the endpoint supports it). This applies both to connections made by devices and to connections made to the API server by any web client. ### Keeping AV data off the wider network Separating audio, lighting and video network traffic from other traffic is good practice. Configuring the AV network with a dedicated VLAN, or using an additional router between the AV network and the company network, is recommended. Because only an outbound connection is needed, a router can be configured to block all AV protocols and all incoming data, permitting only outbound internet traffic on port 443. ### Is it easier to use a mobile modem? The solution is lightweight and robust, and performs well over 3G, 4G and 5G, so a mobile connection is a viable option. A separate modem does, however, bring an additional subscription, plus its own monitoring and configuration overhead. For IT professionals, supporting compatible devices on the existing network is generally lower risk than allowing a third-party-configured router onto the premises. ### What is the internet usage of these devices? Because the back end already knows about the devices that connect to it, only limited data is needed to update values. The SDK on the device sends changes only, keeping data usage to a minimum. As a guideline, a device being interacted with a reasonable amount uses approximately 2–5KB per minute, or roughly 250Mb per month. File transfers — firmware, project files or content — account for most data usage, with file size and transfer frequency having the largest impact. File transfers are stable and resume partial transfers when a connection is restored, avoiding unnecessary data use. ## User access The sections below cover how data shared with the cloud is protected and accessed. ### How is data in the back end accessed? The SixEye back end offers a multi-tenant web API. An integrator becomes a tenant and accesses their data through their own portal, which can be branded and served from the integrator's own domain using DNS routing. Connections from the web client to the back end are encrypted over HTTPS, using TLS 1.2 or higher (TLS 1.3 where the endpoint supports it). A portal built on SixEye technology can be identified by the "powered by SixEye" mark at the bottom right of each page, and by an Amazon-issued certificate pointing to `https://sixeye.live`. Each portal contains sites, which in turn contain one or more devices — usually one device per physical device on a project. ### How do users get access to connected devices? Access to a site is granted by email invitation only. Users are invited to a site and can be given access to specific devices within it. Other capabilities, from viewing the control panel to running a task or rebooting a device, each carry their own permission — see [Permissions](/documentation/sites/permissions). Site owners set the permissions for their site, and can grant other users the ability to set specific permissions. Users see only the sites they have been invited to. ### Is single sign-on (SSO) supported? Microsoft 365 SSO is available. ### Can two-factor authentication be used? Each user can optionally enable two-factor authentication on their account, based on a time-based one-time password (TOTP) using an app such as Google Authenticator or LastPass Authenticator. Two-factor authentication can also be made mandatory for every user in a portal, at the portal owner's request — ask your portal's support contact to arrange it. Portal admins, and users who have been granted the relevant permission by a portal admin, can reset the 2FA key for a user in the portal. ### What about multiple sessions and automatic logout? A user can be logged in from multiple devices at once, as the nature of the application sometimes requires it. A session lasts ten days from signing in, whether or not it is used in that time. Past the ten days it survives only while it is still in use: fifteen minutes after the last request, it closes and the next one has to sign in again. ### Do admins have access too? At portal level, one or more portal admins — typically employees of the portal owner — can be assigned at the portal owner's request. A portal admin can view all sites and grant themselves access to a site. At platform level, a limited number of SixEye super admins can grant themselves access at the integrator's request. All activity is logged. ### How is a device connected to a specific site? A key is created from a site, with a maximum validity of seven days, and copied onto the device. The device manufacturer provides the means of transferring the key to the device, usually through its normal configuration application. The key contains a set of temporary credentials for the device to connect with, along with the information the device needs to identify which site to connect to. Once the first connection completes, the key becomes invalid and cannot be used to connect any other device. ### Is data encrypted at rest? Yes. Data in the SixEye database is encrypted using AES-256. ### What protection mechanisms are in place? Any client consuming the API, such as a SixEye-powered portal, creates a TLS connection to a load balancer. Application servers sit in an AWS VPC (Virtual Private Cloud) with no public access, and AWS Shield provides DoS protection. Devices verify the server's certificate during the TLS handshake, so an attacker cannot eavesdrop on communications. ### What logging is in place for data access? Access to infrastructure components — load balancer, servers and database — is logged, as are application errors, events, and operations performed by users. All activity within a site is visible to site owners. ### Who owns the data? Data provided by the users of a tenant is owned by that tenant. Data pushed by a device is owned by the manufacturer of the device. ### How is data backed up, and can it be restored? SixEye holds a rolling seven-day backup. ### How is data segregated between tenants? Tenant data is held in separate database schemas, with access restricted to users of the originating tenant. This covers user data, project data, permissions and similar. Devices are handled slightly differently: the use of a device in a particular project is segregated by tenant schema, but some of the status information a device pushes sits outside tenant scope, for the benefit of manufacturers. ### How are vulnerabilities identified in the source code? - Library version dependencies are tracked. - Libraries are upgraded early. - In-house solutions are preferred over unfamiliar libraries. - Tests are automated. - Test coverage analysis tools are used. - Every commit is code reviewed. - Test environments are duplicated before release. ### Are there browser recommendations for best performance? The web app is built using standard web technologies and needs no extensions or plug-ins. Any modern browser will work: - **Desktop** — Firefox 62.0.3 or later, Chrome 70.0.3538.67 or later, Edge 44.17763.1.0 or later, Safari 10.1 or later. - **Mobile** — Safari 10.3 or later, Chrome 70.0.3538.64 or later. A 3G internet connection or better is advised. File transfer performance improves with higher bandwidth. Source: /documentation/troubleshooting/network --- # Subscription frequently asked questions Common questions about vouchers, plans and renewals. For the full detail, see [vouchers](/documentation/reference/vouchers) and a site's [subscription tab](/documentation/sites/subscription). > _Where the portal has extended trial vouchers:_ > > ## What is a trial voucher and how do I redeem it? > > Some hardware carries a QR code that can generate a trial voucher. Scan the code on the device and select the option to generate one. > > Redeem it with the new site steps in [Redeeming a voucher](/documentation/reference/vouchers), depending on whether you already have a Cloud account. > > A trial voucher can only be used to create a new site — it cannot extend an existing one. The plan and duration it provides depend on the hardware scanned. ## I added a device and now my site is moving to Standby. Why? The new device has pushed the site's points total past what its current plan covers. Open the [subscription tab](/documentation/sites/subscription) and compare **Required Site Plan** against **Subscription Plan** to see the plan the site now needs. There are two ways to resolve it: 1. Select **Upgrade Plan** on the subscription tab. This brings the site's renewal date forward in exchange for a higher plan. 2. Purchase a subscription at the required plan and redeem the resulting [voucher](/documentation/reference/vouchers) against the site. ## Will redeeming a voucher change my subscription plan? Yes, unless the voucher's plan matches the one already on the site. The site's **Subscription Plan** is adjusted to match the voucher. If you are upgrading, the time remaining on the current subscription is converted to the higher plan first, so no value is lost by upgrading before the current subscription ends. If you are downgrading, remaining time is not converted, and the renewal date is extended by the voucher's duration. > _For portal owners:_ > > ## I want to demo Cloud to a customer. Can I have a site? > > Yes. Every portal comes with a demo site, which stays active permanently. If your portal does not have one yet, ask your portal's support contact to arrange it. > _For readers who are not portal owners:_ > > ## I want to demo Cloud to a customer. Can I have a site? > > Yes. Ask the portal owner, or your sales contact, about a trial site. Source: /documentation/troubleshooting/subscription-faqs