Site devices

A site’s Devices page lists the hardware that serves its doors: the relays that release a lock, the lights that come on with it, and the cameras pointed at it. It answers the question a door page can’t—what is actually installed, and which integration owns it?

Reaching the page

Open Access in the dashboard and choose your site.
Open the Devices card on the site overview, or go to /dashboard/access/{siteId}/devices.

Doors reference hardware; this page reverses it

A door in OpenApp is a device of kind virtual_access_portal. Its configuration names the hardware it uses:

Door configuration	What it names
`openers`	Entities that release the lock
`lights`	Entities turned on when the door opens
`go2rtc_camera_device_ids`	Camera devices for the door

The Devices page reads those references in reverse. It starts from devices and shows, for each one, which door or doors it serves. That inversion is the point: the door page tells you what a door needs, and this page tells you where that hardware lives.

The three sections

Section	What it lists
Openers	Devices with an entity that releases a lock or drives a gate
Lights	Devices with an entity turned on when a door opens
Cameras	Camera devices a door references

A section is a role view, not an inventory. One device can appear in more than one: a relay board with a door relay and a light relay shows up under both Openers and Lights. Seeing the same device twice is expected—it means one piece of hardware is doing two jobs.

What an entry shows

Each entry is one device:

Device name — opens the device details page (/dashboard/resources/devices/{id}), where you can edit the device and see all of its entities.
Integration — the connection that owns the device. This is often not the site’s own integration: a Shelly or Waveshare connection you added separately can own the relay behind a Virtual Access door.
Doors served — every door on the site that references the device. A device serving three doors is listed under all three.
Entities — the entities on the device that the door uses.

Finding what you need

All three sections share the same controls:

Search by device or entity name.
Filters for door, integration, and status.
Sort, plus three view modes: list, cards, and table.
Group by door — a device that serves several doors appears under each one, so a door-scoped view still shows everything that door depends on.

Actions on openers and lights

Openers and lights have inline actions: open the door, or turn the light on. Two things can stop them:

Permission — you need entities:set_state. Without it, the action is hidden.
Door readiness — the action is blocked while the door’s life-safety classification or commissioning attestation is incomplete. Classify the opening and complete the attestation on the door to enable it. See Life safety and egress.

Camera live feeds

Live feeds are off by default. The Cameras section has one Live feeds switch; turning it on starts streams.

Even with the switch on, only the tiles currently scrolled into view open a stream—scroll away and they stop. That’s deliberate: a site can have dozens of cameras, and every open stream costs bandwidth at both ends. Turning feeds on is a choice you make for this visit, not a setting that quietly starts video in the background.

When a reference no longer resolves

If a door points at hardware that no longer exists—a deleted entity or a removed device—the page shows it in a warning banner instead of dropping it. A door whose opener was deleted is still a door that can’t open, and hiding it would make the site look healthier than it is. Open the door and point it at working hardware to clear the warning.

Access portals — the door side of the same references.
Set up access control — where doors and openers come from.
Life safety and egress — classification and commissioning attestation.
Devices — the device model behind these entries.
go2rtc — the camera integration behind live feeds.