Multi-camera dashboards: map devices to sites before you open players

How can I build a multi-camera monitoring dashboard? Start with a data model, not a wall of players: sync cameras with listDeviceDetailsByPage, map each deviceId/channel to your tenant and site records, define a fixed number of on-demand slots, then mint short-lived credentials (getKitToken + ImouPlayer, or bindDeviceLive for HLS) only for active tiles. Default to SD (streamId = 1). Do not open every camera in HD at login.

Why it matters

Dashboards fail when product teams treat OpenAPI inventory as the UI list and treat every row as a live stream. Operators think in sites, floors, and exceptions. Your SaaS already owns sites and roles; Imou Open Platform owns device connectivity and streaming subject to entitlements. Mapping devices to sites first keeps ACL honest, bandwidth predictable, and player count intentional.

Overview: Video Monitoring.

Data model first

Minimum entities to design before writing player code:

Suggested camera row fields after sync:

• deviceId, channelId (from OpenAPI)
• tenantId, siteId (your ACL keys)
• display name, online/offline hints from last sync
• optional capability flags (talk/PTZ/playback) only when you can verify device + subscribed services

listDeviceDetailsByPage  →  your camera ledger
        │
        ▼
site_id ←→ deviceId/channelId   (many cameras per site)
        │
        ▼
dashboard: pick site → assign N cameras to slots → mint play creds

Inventory API: listDeviceDetailsByPage (pageSize 1–50). Re-sync on a schedule or after bind/unbind events. Cameras that exist only in a consumer account are not automatically API-visible—bind them to your developer asset pool first.

Architecture (ledger → sites → slots → players)

SaaS UI (site picker + N slots)
        │
        ▼
Your BFF (session ACL + accessToken + kitToken / live URL cache)
        │
        ▼
Imou OpenAPI ── listDeviceDetailsByPage
             ── getKitToken / bindDeviceLive / createDeviceRtmpLive

• Ledger: which cameras exist for your app.
• Site map: which cameras belong on which operational page.
• Slots: how many concurrent streams the UI allows.
• Players: ImouPlayer or HLS instances bound to active slots only.

This order prevents the anti-pattern “open 16 HD ImouPlayers for every deviceId in the page response.”

Why mapping before players changes the build

Without a site map, engineers often wire the left-hand list directly to listDeviceDetailsByPage and create a player for every row. That couples OpenAPI pagination to UX, skips tenant scoping, and turns a browsing page into a live-view storm. With a map, the list page stays cheap (DB reads), and only slot assignment triggers OpenAPI live calls.

A practical onboarding rule: if a camera has no siteId, show “Assign to site” instead of Live. That single gate prevents operators from streaming cameras they cannot place in an operational context—and prevents support tickets about “random device IDs on the wall.”

When multiple channels exist on one device, store channel as part of the binding key. Site pages should present human labels (“Dock door 3”) while the BFF resolves to deviceId + channelId only after ACL passes.

Steps

1. Bind and sync. Create an application on open.imoulife.com, bind devices, then page through listDeviceDetailsByPage into your database.
2. Map to sites. Provide an admin or onboarding flow that attaches each camera to a site (and tenant). Until mapping exists, do not render a monitoring wall—render a setup checklist.
3. Authorize by site. When a user opens a site dashboard, load only cameras for sites they may access under your SaaS ACL. OpenAPI accessToken proves your developer app—not end-user rights.
4. Define slot policy. Cap concurrent live tiles. Assigning a camera to a slot triggers minting; clearing a slot destroys the player.
5. Mint on demand. Prefer getKitToken + ImouPlayer for interactive walls; use bindDeviceLive when slots consume HLS. Keep accessToken and appSecret on the server. Cache kitToken ~1 hour (TTL ~2 hours).
6. Default SD, promote HD. Grid tiles: streamId = 1. Focus inspection: streamId = 0 for one tile.
7. Destroy on close. Tear down players on slot clear, route change, and tab hide so quota and browser decode cost stay under control.

APIs and SDKs

JS player: JavaScript development. Live summary: Custom live broadcast.

Acceptance checklist for the data-model milestone

Before you celebrate “dashboard MVP,” confirm:

• Every playable camera has tenantId + siteId in your ledger.
• Site dashboards never call live mint APIs for the full camera list—only for assigned slots.
• Role checks happen on site (or camera) before getKitToken / bindDeviceLive.
• Slot caps are documented in UX (operators know why the next tile is blocked).
• Default tile quality is SD (streamId = 1); HD is an explicit focus action.
• Player teardown is part of navigation, not an afterthought.

Hitting this checklist usually matters more than adding another protocol adapter.

Limits and pitfalls

• Players before mapping create ACL and UX debt: operators see raw device IDs and request the wrong streams.
• One shared cache for all tenants risks cross-tenant credential reuse—key by tenant + device.
• Prefetching every live source at site load burns quota and can expire before anyone watches.
• HD everywhere saturates uplinks and live-view resources; plan against My Resources.
• Talk/PTZ/playback availability depends on device and subscribed services—map capabilities into the model only when verified; hide unsupported controls.
• Do not invent Mbps SLAs; measure on your target networks and publish local evidence only.

Register at https://open.imoulife.com — Imou Open Platform is cloud video and AIoT focused, providing APIs, SDKs, and low-code components so vendors and developers can ship multi-camera monitoring products faster. See Video Monitoring.