Definition
Static Group refers to a user manually adding devices to a group, with fixed members. It complements Dynamic Group and is suitable for Device Grouping scenarios with a fixed division by project, region, etc.
Features and Usage
Static groups are explicitly added or removed by administrators or authorized users, with a clear and auditable member list. They support batch import, conversion from Dynamic Group snapshots to static groups, and other operations. Groups can be set up in a hierarchical structure (e.g., region—site—device), facilitating permission inheritance and batch operations. They are suitable for scenarios with relatively stable members, such as project-based deployments, fixed production lines, or specific customer device pools, complementing dynamic groups that match devices automatically based on tags or attributes.
Collaboration with DMP functionality
As target units for batch operations, static groups support unified execution of OTA upgrades, configuration distribution, and Remote Maintenance for devices within the group. The permission model can implement RBAC data isolation based on groups; alarm rules and operation dashboards can be aggregated and displayed by group. Groups can be used in combination with Device Tagging; static groups focus on fixed sets managed manually, while tags emphasize flexible multidimensional classification.
Use Cases
Suitable for device clusters at energy sites, workstation devices on manufacturing lines, floor devices in buildings, etc. When device ownership is clear and changes are infrequent, static groups make it easier for operation personnel to quickly locate and operate devices; when the device scale is large and attributes change frequently, dynamic groups or hybrid strategies can be used to balance management efficiency and flexibility.
The member list is an explicit set, not a query result
A static group stores a list of device identifiers that were explicitly added. Changing a device's site, tag, or firmware does not by itself put it on or take it off that list. That is the opposite of a dynamic group, which filters at the moment of the query: its members are a query result and can change on every run. Members of a static group change only when someone adds or removes them. A bulk upgrade, an authorization, or an alarm subscription that needs "the batch approved yesterday" has to use an explicit list. It cannot use a query that would calculate a different result today.
The list should store identifiers, not the display name or a copy of the attributes at the time. Display names change, copies go stale, and what must be constrained is which device this is. The same device can sit in several static groups at once, for example both in a project and in a nighttime maintenance batch. If permission is granted by group, overlap must be defined in advance as a union or an intersection. Otherwise two administrators compute different visible sets. Removing a device affects only this list. It should not delete the device itself, or its membership in other groups.
It fits cases where membership changes rarely and must be audited
A static group fits a project delivery list, the fixed stations of one production line, or the devices at a site that have already been accepted. Those sets change infrequently, and every entry and exit needs a record of who changed it and when. It does not fit a set such as "every device whose temperature is above a value," which changes from moment to moment. That is work for a query or a dynamic group. Before using a static group, confirm that someone is responsible for maintaining the list. A static group with no owner still contains dismantled devices months later.
Generating a static snapshot from a dynamic group is a sound handover. Freeze the filter result at one moment and hand it to an upgrade task that cannot tolerate drifting members. After the freeze, the two sides no longer sync automatically. A newly installed device joins the upgrade only if someone adds it again or freezes again. Rules and reports on the group need to know whether they are reading a frozen list or a live query. A group name alone in the configuration does not settle that meaning.
Keeping a snapshot group and still treating it as a dynamic list
The usual mistake is to build a static group from one export or one filter result, then still expect later devices that meet the condition to appear on their own. The new device is already provisioned, the upgrade task covers only the old list, and the devices that were missed show up in the report as "not yet in the project." The task creation page should show when the list was frozen and how many units it has, and before execution it should allow a comparison with the current filter, so a person decides whether to absorb the difference.
Another mistake is to use a static group as a permission boundary while letting any editor add or remove members. If a member can be added when the editor could not otherwise reach that device, the group becomes a path around the permission check. Adding or removing a member should check again that the operator could already access that device. Identifiers that are dismantled or scrapped, if left on the list, make batch tasks fail against them repeatedly, and the failure count is misread as an upgrade-quality problem. List maintenance should move out identifiers that can no longer connect and have been scrapped, and keep a historical membership record for audit. Do not delete the group and recreate it. That loses the evidence of which devices were approved at the time.
When the list changes, show the identifiers about to be added and about to be removed, and require a confirmation, so one paste does not import a thousand wrong units that can be undone only by deleting the whole group. The confirmation record includes the operator and the counts before and after. When the group is bound to an upgrade or a permission task, lock a copy of the members at the start of the task. Edits to the group during execution do not affect this run. The next task uses the new list. Without the lock, someone can remove a device halfway through, and the result rows no longer match the approval at creation time. The locked copy is read-only until the task ends, and it is cleaned up afterward according to the retention period.