Device ID vs Channel ID on Imou Open Platform: The dev and cam Resource Model

On Imou Open Platform, dev identifies a device resource and cam identifies a channel resource. A device resource uses dev:<deviceId>; a channel uses cam:<deviceId>:<channelId>. The documented permission model says a cam belongs to its dev, and permissions granted on the device can pass to its channels. Still, device APIs commonly require an explicit channelId, especially for NVR or multi-channel addressing.

Why it matters

Using “camera” as though it always means one physical box and one video channel works only until a recorder or multi-channel device appears. Inventory, authorization, and operations then drift apart: a user may see a device but target the wrong channel, or a broad device grant may reach more channels than intended.

Approach / architecture

Maintain two related records. The device record is keyed by deviceId and stores device-level facts. The channel record is keyed by (deviceId, channelId) and stores channel-level facts. Never invent a globally unique channelId; its meaning is within the parent device.

For authorization, represent official resource strings exactly:

dev:<deviceId>
cam:<deviceId>:<channelId>

The Imou sub-account documentation states that cam belongs to dev and a device permission can pass to the channel. Therefore, use channel-scoped resources when the application needs narrower access, and evaluate a device-scoped grant as potentially covering child channels. This is an authorization design consequence of the documented inheritance rule.

Six implementation steps

1. Retrieve device and channel details using the current device-query interfaces.
2. Upsert a device row by deviceId; do not overwrite it once per channel.
3. Upsert each channel by the composite key (deviceId, channelId).
4. Build official policy resources as dev: or cam: strings only at the authorization boundary.
5. Before a channel operation, authorize the application user, then send both deviceId and documented channelId.
6. Reconcile deleted, newly visible, or permission-changed resources during later inventory passes.

APIs / SDKs

The sub-account function description defines the two resource types, their identifiers, permission vocabulary, and inheritance. addPolicy applies policies to resources. listDeviceDetailsByPage returns paginated device information with channel data and accepts an administrator or sub-account accessToken.

Keep policy administration and signed API calls on a trusted backend. A UI may display friendly names, but it should send stable identifiers selected from backend-authorized inventory rather than constructing resource strings from unchecked input.

Limits & pitfalls

• Do not publish an undocumented maximum channel count.
• Do not assume channel numbering, names, or capabilities are identical across devices.
• A device-level permission can inherit to child channels; it is not automatically least privilege.
• DevControl is broad and includes currently defined and later-defined device-operation permissions according to the official description; grant specific documented permissions where narrower access is required.
• A channel shown in inventory does not prove every operation is supported. Check capabilities and the target interface.
• Device removal, sharing changes, and permission changes require reconciliation; a cached row is not perpetual authority.

Designing the internal model

Use foreign-key semantics even if the storage engine is not relational: every channel points to exactly one known device record, while a device can own zero or more currently visible channels. Store the raw source relationship and capability fields needed by the product, but avoid treating unrecognized capability text as a promise. Preserve observation timestamps so operators can tell fresh inventory from stale cache.

Separate display names from identity. Users may rename a device or channel, and two devices may expose similar names. URLs and API jobs should use opaque internal IDs that resolve server-side to the authorized (deviceId, channelId) pair. This avoids authorization decisions based on labels.

Permission review example

Suppose an application user needs real-time access to one recorder channel. A Real policy on cam:<deviceId>:<channelId> expresses narrower scope than the same permission on dev:<deviceId>. If the user later needs another channel, add that explicit resource after review. This example follows the documented resource and permission vocabulary; the decision to prefer explicit channel grants is architecture guidance.

When access is revoked, clear or delete the relevant Imou policy through the documented account interfaces and revoke the corresponding application authorization. Verify both layers. Imou resource policy does not know the business meaning of your tenants, sites, or employment lifecycle.

Inventory QA

Test a single-channel device and every recorder or multi-channel family the business supports. Confirm parent-child mapping, channel operation routing, device-level inheritance, channel-level grants, renamed labels, and removal. Log internal correlation IDs and official API request IDs, not tokens. Review the live interface documentation whenever a returned field or capability is unfamiliar.

Query and job boundaries

Inventory collection, permission assignment, and device operation should be separate jobs even when they share identifiers. A collector discovers deviceId and channelId; an authorization service decides which internal principal may use them; an operation worker invokes only the documented interface after both checks pass. Do not let a successful inventory response double as permission to operate.

For queued work, snapshot the internal authorized resource ID, operation type, and policy version. Resolve the current official identifiers again immediately before execution, because access may have been revoked since the job was created. Reject a job if the channel no longer belongs to the expected device in current inventory. These controls are application recommendations that follow from the mutable inventory and inherited permission model.

Handling capability differences

Capabilities can exist at device or channel context and should be treated as observed metadata, not a permanent contract. Preserve the source payload needed for troubleshooting, but map only understood values into product features. Unknown values should remain visible to engineering without automatically enabling UI controls. Before invoking an operation, check both application authorization and the current interface’s documented requirements.

This model also supports gradual rollout. A team can enable a function for an explicitly tested device/channel cohort, observe results, and expand after QA. It avoids a global assumption based on one device family and keeps capability decisions independent from friendly labels.

Use the current sub-account resource documentation to model dev and cam explicitly before scaling a fleet. Preserve both identifiers in diagnostics so support cases can distinguish device scope from one channel without reconstructing resource strings from display names.