For the complete documentation index, see llms.txt. This page is also available as Markdown.

Custom fields

Store your own structured information on devices, such as a serial number, an installation date, or a location.

Custom fields add your own information to a device, alongside the data it sends. A serial number, the date a battery was last replaced, the room a sensor hangs in, the contact responsible for it: none of this arrives in an uplink, but all of it is needed to run a fleet.

A custom field is defined once for the workspace and can then be filled in on any device in it. The definition holds the name, the type, and, for text and number fields, the values that may be chosen.

Field types

Type
Use it for

Text

Anything written, such as a serial number, an asset tag from another system, or a responsible team.

Number

Values you want to compare or sort, such as a floor number or an installation height.

Date

Points in time, such as commissioning, last maintenance, or warranty expiry.

GPS coordinates

A fixed position for a device that does not report one itself.

JSON

Structured information that does not fit the other types, for example a block of configuration carried over from another system.

Pick the narrowest type that fits. A date stored as text cannot be sorted sensibly, and a number stored as text will not compare the way you expect.

Select options

For Text and Number fields you can define the values that may be chosen, which turns the field into a list instead of free input. This is what keeps a fleet consistent: Floor 1, floor 1, and 1st floor are three different values when they are typed by hand, and one value when they are picked from a list.

Options are added, edited, and removed in the custom field management page, and a field can be marked as required so that a value has to be supplied rather than left empty.

Adding a custom field to a device

A custom field can be set while the device is being created, with + Add Custom Field. An existing field can be selected, or a new one created on the spot.

Adding a custom field during device creation
Custom fields during device creation
The field types available for a custom field
The available field types

The same fields can be set later on the device itself, so nothing has to be decided at creation time.

Managing custom fields for the workspace

Custom Fields in the workspace settings lists every field defined in the workspace. From there you can create a field, edit an existing one including its select options, and import a set of fields at once.

Definitions and values are separate things: editing a definition changes the field for every device that uses it, while a value belongs to the one device it is set on.

Importing definitions

A set of custom fields can be imported from a CSV file with these columns:

Column
What it holds

name

The field name as it appears on devices.

description

An optional explanation of what belongs in the field.

type

STRING, NUMBER, DATE, GPS, or JSON.

required

true or false.

selectOptions

The permitted values for a text or number field, one per line inside the cell. Leave empty for free input.

This imports the definitions. To fill in values across many devices, use the asset inventory: custom field values are one of the properties supported by bulk edit, and they can also be set per device during a bulk import of devices.

Where custom fields show up

  • In the asset inventory, as columns you can show alongside the built-in ones.

  • In filters, so you can list every device sharing a value, for example all sensors on one floor or every device due for a battery change.

  • In outputs, template custom field values as part of the events sent by an output connector.

Custom fields describe a single device. To group devices so that rules and filters can address them together, use tags. To model how devices relate to a building, its floors, and its rooms, use the Data Fusion Layer.

Last updated

Was this helpful?