Definition
Device Grouping organizes devices according to business dimensions such as region, project, product type, etc., and supports Static Group and Dynamic Group. Grouping is deeply integrated with OTA, configuration delivery, alarm rules, and RBAC.
Group Types and Hierarchy
Static Group: Devices in static groups are manually added by users, and members are fixed; Dynamic Group: Devices in dynamic groups are automatically selected according to rules (such as Device Tagging, product, firmware version), and members change with device attribute changes. Groups can support hierarchical structures (e.g., region—site—device), facilitating permission inheritance and batch operations. The same device can belong to multiple groups, meeting different business perspectives. Grouping and Device Tagging complement each other: groups focus on target collections for batch operations, while tagging focuses on flexible multidimensional classification.
Integration with DMP
The Device Management Platform uses groups as targets or scopes in scenarios such as OTA tasks, configuration delivery, alarm rules, and RBAC data permissions. After selecting a group, operations are applied to all devices within the group; RBAC can achieve data isolation based on groups, allowing users to access only the devices within their group. Groups support linkage with Report Analytics report analysis and Device Monitoring device monitoring, aggregating and displaying metrics by group. Combined with Remote Maintenance remote maintenance, it supports bulk execution of upgrades, configurations, diagnostics, and other operations for groups.
Use Cases
Applicable for managing devices by region, project, or customer; selecting a target group during bulk OTA; reporting operational metrics by group; and data isolation in multi-tenant scenarios. Device grouping is a fundamental capability for large-scale device management.
A manual list and a rule list cannot be mixed
Device grouping means gathering a set of terminals into a collection that upgrades, configuration, authorization, and statistics can refer to. Members of a static group are put in by a person, one by one or in a batch, and they change only when edited again. Members of a dynamic group are produced by a rule at calculation time. When a device attribute changes, the set may change. Both can be called a group, but which kind a job is bound to decides whether the target at execution is still the set seen when the job was created. An upgrade list that must be kept on record should use a static group or a snapshot of the members at that time. A day-to-day policy that should also include devices that newly meet the condition later is the case for a dynamic group.
Before using a group, decide which business question it answers: a project boundary, a permission boundary, or the target of one operation. A group that takes all three roles changes permission and the statistical definition whenever its members change. In a hierarchy, whether an operation on a parent group includes the child groups must be written down. One device may belong to several groups, so a group is a viewpoint, not a physical location. Used with tags, the tag is the input and the group is the result used for a bulk action. Binding an OTA job directly to a rule group that changes with version lets members enter and leave during the upgrade, and the job scope can no longer be explained.
One device in many groups amplifies an operation
A likely mistake is to forget that a device can be in several groups at once. Delivering one set of parameters to group A and another set to group B writes the devices in the intersection twice. What takes effect is the write that arrives later, not the one that looks more suitable. When permission is granted by group, adding a person to a very wide parent group opens every child group. A dynamic rule with one wrong condition, such as “equals” written as “does not equal,” can suddenly make the members almost every device, and the bulk operation expands with it. An empty group also needs care. When the filter is too strict the group is empty, the job shows success, and no device actually runs it.
A hand-kept group and a rule group with the same name, or treated as the same list, are another kind of incident. The name does not say whether the members will change on their own. Counting online status across groups, if the same device is counted more than once, inflates the total. It should be possible to see the list by group, and also to see which other groups one device is still in. When device monitoring filters by group, it should use the members at the moment of the query, and say whether that is a snapshot or a live rule. Changing members should not rewrite the scope of a historical job that has already finished. The historical job has to keep the target list from that time.
Why permission on a parent group expands
Once groups form a hierarchy, one authorization or one delivery on a parent group lands on every child group. Adding a person to a very wide parent group opens every project underneath, even if that person is only there to handle one site. If the screen shows only the parent-group name, the person running it cannot see how many devices will be touched, and the confirmation means nothing. Before delivery, expand to a concrete list or at least give the count, and make it possible to see which of those devices also belong to other groups. A device in the intersection of several groups is written in turn by each group’s configuration. What takes effect is the write that arrives later, not the group whose name looks like a better match. That overwrite should be visible on the device as which group the last few writes came from.
An empty group is dangerous in the same way. When the condition is too strict and membership is zero, the job shows complete and nothing in the field changes. People think the configuration has taken effect. If a dynamic rule and a hand-kept list share a vague group name, a few days later nobody remembers whether that list will change on its own. Adding groups together in a statistic counts the same device more than once, and the total is larger than the real record. A job that has already ended must keep the target list from the time it ran. Adjusting members afterward must not rewrite that job’s scope. Otherwise the audit sees the group as it is now, not the devices that were actually operated on that night.