An SI member on your team can read your devices and, where you allow it, operate them. It is held to stricter limits than a person.
The SI policy
Go to Settings → Devices (IoT) → SI. You need the Manage IoT Settings right. The SI policy has two choices:
- Let SI members use devices. It is on for a new organization.
- Highest class SI members may use. It starts at Security. Safety-critical is never available to SI members.
Turning it on, or raising the highest class, asks for your password. Turning it off or lowering the class does not.
The policy only sets the ceiling. An SI member starts with no device access: it can use only what is granted to it.
What an SI member can use
- Only functions that are granted to it, and only as far as its supervisor's own access goes. An SI member with no supervisor can use nothing.
- Only functions that are verified as working, on a connection that is healthy.
- Never safety-critical controls, controls that need two people, cameras and live video, camera snapshots or health readings. Nor devices from a vendor that does not allow SI members, such as Google Nest.
- It can list devices, alarms, automations and recent activity, send a command, acknowledge an alarm and turn an automation on or off. It cannot create or edit automations or alarm rules.
- It can never hold Manage IoT Access, Manage IoT Sharing, Manage IoT Connections, Manage IoT Alarms, Manage IoT Settings or Export IoT Data. Those are for people.
Physical actions ask a person first
By default, an SI member asks a person before every physical action: sending a command to a device, turning an automation on or off, and acknowledging a Critical or Major alarm. The request names the device or alarm, what it would do and why, and it appears among the approvals a person can answer on the web or on KamoMobile. Your organization's charter for SI members can change this, for example letting lights, climate and equipment run without asking while security devices still ask.
The approver's own access is checked as well: an approval never lends access the approver does not have. If the function's class was raised between the request and the answer, nothing is sent and the SI member must ask again. A command to an offline device is refused before anyone is asked.
When an SI member acknowledges an alarm, it must say in the note who is dealing with it.
See exactly what one can do
Choose Check an SI member's access on the SI tab. It opens Check access on the Access tab with By person chosen: pick the SI member. You need the Manage IoT Access right to see that tab. See How to See Who Can Operate a Device.
Where it is recorded
Every action is recorded in the command log as "SI member" and its name, so you can tell it from a person's.
Related articles
Other guides that answer questions close to this one.
How to See Who Can Operate a Device
Check access shows exactly what a person can do, who can use a device, and why. It answers "why can't I?" without guessing. Before you start You need the Manage IoT Access right. Check access 1. Go to Settings → Devices…
Device Functions and Safety Classes Explained
Every device is made of functions: the things you can read or do with it, such as reading a lock's state, locking, unlocking, setting a level or reading a temperature. Access in IoT Devices is given per function, not…
What You Can and Cannot Ask Alexa to Do
Alexa can do only what its link was given. A link starts with no access; see How to Connect Amazon Alexa. What works by voice Where the link was given the function on the device: Turn lights, switches and plugs on and…
