After upgrading the robot to 7.70 on a robot which is also a hub, the user_tag values will not propagate on alarms sent by that robot/hub.
User tags are now propagated in alarms and messages sent by both the hub and the controller (version 7.70).
Previously, both the hub and controller read user tags os_user1 and os_user2 from robot.cfg.
Now, the hub reads user tags from hub.cfg. User tags have been added to the hub’s General Configuration section in Admin Console, which set os_user1 and os_user2 in hub.cfg.
Therefore, if the robot is also a hub, then you would need to set the user_tag at the hub level. If the robot is not also a hub, then you can set the user_tag at the robot level.
This issue have been fixed with hub 7.80, which reads User Tag from robot.cfg and put them into hub.cfg automatically during hub probe upgrade.
With Hub v7.80, when user tags are added/modified to robot.cfg this change will propagate to the hub.cfg automatically after a hub restart.
For this mechanism to work the following key must be enabled (value = 1) via Hub Raw Configure:
os_user_retrieve_from_robot = 1
Note: This only works if the hub.cfg does not have any user tag already. The robot.cfg overwrites the hub.cfg existing user_tags only if the above key is enabled and if only if the user tags on the hub.cfg are empty.
The user tags set in the hub.cfg (via Admin Console) instead will overwrite the robot.cfg user tags.
This is documented on docops article below:
Changes to User Tags for Robot Alarms Sent by the Hub: