Tags
Group devices in a workspace so that rules, dashboards, filters, and bulk actions can address them together.
A tag is a label put on devices so they can be treated as a group. Where a custom field describes one device, a tag connects many: every sensor on the first floor, every CO2 sensor, every device belonging to one customer.
Using tags for grouping devices, a single rule can cover all of its devices, a filter can list them, a dashboard component can aggregate and visualize data for all of the devices belonging to a tag, without anyone maintaining a list of device IDs by hand.
Tags belong to the workspace. A tag name is limited to 64 characters and has to be unique within its workspace, so the same name can exist in another workspace without the two being related.
Adding tags when you create a device
Tags can be assigned in the device creation step. Existing tags are offered in the tag field, and typing a name that does not exist yet creates it.
Adding tags to an existing device
On the device detail page you can pick from the tags already in the workspace or create a new one. A device can carry as many tags as you need, which is what makes tags worth using: a sensor can be part of a floor, a device class, and a customer at the same time.
Managing tags for the workspace
Tags in the workspace settings lists every tag in the workspace, where they can be created, edited, and imported in bulk. Each tag has a name, an optional description, and a color, which is what makes it recognizable at a glance in the inventory.
A set of tags can be imported from a CSV file with these columns:
name
The tag name, unique in the workspace and at most 64 characters.
description
An optional explanation of what the tag stands for.
color
A hex color such as #40A9FF.
Using tags as rule input
A tag can be selected as the input of a rule, which then runs for every device carrying that tag. The rule keeps up on its own: tag a newly installed sensor and it is covered, without editing the rule.
Devices addressed through one tag have to share a data schema, meaning the same topic and data keys. The rule logic reads a specific key from the incoming sample, so a device that structures its data differently will not produce the value the rule expects.
This is the practical reason to keep at least one tag per device class. A tag such as co2 is safe as a rule input in a way that building_a, spanning every kind of sensor in a building, is not.
Using tags as a dashboard data source
A dashboard component reads either from one device or from a tag. On the component's Source tab, set Type to Tag, pick the tag, and choose the data point to read. The component then covers every device carrying that tag, and combines their values into the figure it shows, according to the aggregation settings of the component.
A trend component pointed at a tag such as 1og and the data point count, aggregated by maximum, reports the peak number of people counted across that floor, regardless of how many sensors contribute to it.
Two things follow from this:
The dashboard keeps up with the fleet. A sensor tagged after the dashboard was built is included the next time the component loads, without anyone editing the dashboard.
The data point has to exist on every device with the tag, for the same reason it has to for rules. A device that does not report the selected key contributes nothing to the result.
Naming tags
Tags are flat labels, with no hierarchy and no nesting, so the structure has to live in the names. A convention worth adopting:
By device type, for example
temperature,co2,water-meter. These are the tags that work as rule inputs.By location, for example
floor_1,building_a. These are what you filter the inventory by.By responsibility, for example a customer, a tenant, or the team that maintains the devices.
Agree on the separator and the case before the fleet grows. floor1 and floor_1 are two tags, and nothing later merges them.
Last updated
Was this helpful?