Definition
Dynamic Group (dynamic grouping) automatically selects devices according to rules (such as Device Tagging tags, product model, firmware version, etc.), with members automatically updating as device attributes change. Complementary to Static Group, it is suitable for bulk OTA, regional batch operations, and other scenarios.
Rule configuration and updates
Dynamic grouping rules can be based on attributes such as Device Tagging tags, products, firmware versions, online status, and regions. The rules are expressed in the form of expressions (e.g., tag.region=East China AND firmwareVersion<1.2.0), and the platform calculates the matching device set periodically or in real time. When device attributes change, members are automatically added or removed without manual maintenance. Suitable for dynamic target scenarios like "all devices in East China pending upgrade" or "all devices offline for more than 7 days." Combined with Device Grouping, it supports hierarchical and hybrid grouping.
Integration with DMP
The Device Management Platform supports using dynamic groups as targets in OTA tasks, configuration delivery, bulk operations, alert rules, and other scenarios. When a dynamic group is selected, task execution resolves members in real time to ensure target accuracy. It can coexist with Static Group static groups, where dynamic groups focus on automatic matching and static groups focus on manually managed fixed sets. It also supports converting the current members of a dynamic group snapshot into a static group for auditing and traceability.
Use Cases
Suitable for bulk firmware upgrades, bulk configuration by region, and filtering devices to be maintained based on health. Dynamic groups can significantly improve the efficiency and accuracy of large-scale device management.
When a rule recalculates group members
A dynamic group means describing, with a rule that can be calculated again, which devices count as inside. It does not save a list a person picked by hand. The inputs to the rule are usually attributes already written on the record, such as tags, product, firmware version, online status, or health score. Members are produced each time the rule is calculated. Calculation may run when an attribute changes, or when someone views the group or a job runs. The set seen at those two moments may differ, so it must be said when this group is recalculated at the moment it is used. The rule itself does not keep historical members, unless the system separately takes a snapshot.
A dynamic group fits when the condition itself is the purpose, for example devices that are still below a firmware version. It does not fit when legal review or a change window requires reconstructing afterward exactly which units were upgraded that night. That list has to be frozen before execution. Every field in the rule must be one the device really has, and its meaning must be stable. A condition on a freely written remark makes the result fluctuate with the wording. Combined with OTA, creating a job may preview the members at that time, and execution should say whether it used the preview snapshot or a recalculation at the instant of execution. An empty result should be shown as no match. It must not be shown as the rule having failed, or people repeatedly loosen the condition and finally include too many devices.
When membership changes after the job has been sent
The incident that happens most easily is an upgrade job bound to a dynamic group, running for several hours. During that time some devices change version after a successful upgrade and are removed by the rule, and some devices have just been tagged and are added by the rule. A device that joined midway also receives the package, and a device that already finished is handled by another rule. The operator remembers the count at creation time. The count at the end does not match. Another problem is a tag the rule refers to being renamed in bulk. The group becomes an empty set or the full set without anyone editing the rule. When online status is written into the rule, a device chattering online enters and leaves the group repeatedly, and alarms that depend on the group chatter with it.
Deleting one device by hand from the current members of a dynamic group adds it back at the next recalculation. The operator thinks the exclusion has taken effect. If the business needs an exclusion, write the exclusion into the rule, or switch to a static list. Nested rules that refer to each other may never produce stable members. When the preview count and the execution count disagree, the execution list is the one that counts, and that list should be kept. After device health score weights have just been adjusted, a group selected by score changes as a whole. That is not devices suddenly getting worse. It is the rule input changing. Automatic actions that depend on that group should pause until the score window is stable again.
Preview counts and the execution list
The count a dynamic group produces when a person is looking, and the count it produces when a job actually runs, have every attribute change in between. If an upgrade lasts several hours, a device that has successfully upgraded is removed by the rule because its version changed, and a device newly tagged is added, so a device that joined midway also receives the package. The operator remembers the count at preview time. The end does not match, and there is no way to answer who was included that night. A job that needs accountability or a review should freeze the members into a list before it runs. Later changes to the rule no longer affect this run. If the business really is “handle everyone who meets the condition now,” the execution record should save the actual list, not recompute yesterday’s scope with today’s rule afterward.
Deleting one device by hand from the preview does nothing. The next recalculation adds it back. To exclude it, write that into the rule, or use a list that does not change on its own. When a tag the rule refers to is renamed in bulk, the group may become an empty set or the full set without anyone editing the rule. Writing online status into the rule makes a chattering device enter and leave repeatedly, and alarms hung on the group chatter with it. Nested rules that refer to each other may not produce stable members. An empty preview should show no match and prompt the person to check the condition, not show an error that tempts them to loosen it until almost every device is included. Just after health-score weights are adjusted, members selected by score change as a whole. That is the input changing, not devices suddenly getting worse. Automatic actions that depend on it should pause first.