Update Multiple Attributes

Who it’s for

Anyone who needs a dashboard to capture input rather than only display it — commissioning engineers entering per-device calibration constants, operators recording a manual reading, technicians setting thresholds the rest of the platform depends on. The alternative is editing attributes one at a time in the entity details, which does not scale past a handful of devices.

What it does

The Update Multiple Attributes widget builds an input form from the data keys you configure and writes every field back to the entity on save. Each key becomes a field, with its own input type and optional conversion function, and the values are stored as attributes or as time series depending on how each key is set up.

• A form, not a control — several values entered together and committed in one action, which matches how commissioning data is actually collected.
• Each field carries its own input type, so text, numbers, booleans and dates each get an appropriate control.
• Conversion functions shape what is stored, so what the operator types and what the device expects need not be the same.
• Fields for several entities can be grouped under titles, which lets one form cover a device and its parent asset.
• Layout is configurable — rows or columns, a set number of fields per row, and explicit gaps — so a long form stays readable.
• Save and undo buttons are optional and relabellable, and the form can be set to write every field rather than only the changed ones.
• The Update Multiple Attributes widget writes what is in its fields: it sends no RPC and commands nothing, so a device that must act immediately needs a control widget as well.

How to set up

Data keys

The Update Multiple Attributes widget takes one form field per data key.

Key	Role	Type	Description
Any key	One input field	Attribute	Time series keys work too and are written as telemetry. Each key’s own settings decide its input type, its label, whether it is required, and any conversion applied before saving.

Add one key per field, set each one’s input type, and check the write scope. A key added as a server attribute is written where the platform can read it and the device cannot, and a form intended to configure firmware needs shared scope instead.

Form

Setting	Default	Effect
Show action buttons	On	Shows the save and undo buttons
Update all values, not only modified	Off	Writes every field on save rather than only the changed ones
‘SAVE’ / ‘UNDO’ button label	Platform default	The button text
Show title for group of fields	Off	Captions each entity’s group of fields
Fields alignment	Row	Lays fields out in rows or in a column
Number of fields in the row	Platform default	How many fields share a row
Show result message	On	Confirms the save on screen

How to customize

• To lay out a long form — set Fields alignment and the Number of fields in the row, then adjust the row and column gaps.
• To label the action in the operator’s terms — set the ‘SAVE’ button label to something like Apply calibration.
• To write everything every time — turn on Update all values, not only modified, which suits a form whose values must be re-asserted together.
• To separate entities visually — turn on the group title and set its text, so a device’s fields do not run into its asset’s.
• To make a form read-only-ish — turn off Show action buttons where the form is submitted by a dashboard action instead.
• To shape what is stored — set a conversion function on the individual data key.

Tips

• Mark the fields that must be filled as required on the key rather than trusting the operator. Commissioning forms get completed under time pressure, and a missing calibration constant is discovered weeks later as a sensor that reads plausibly and wrongly.
• Keep one form to one purpose. A form mixing calibration constants with an occasional manual reading gets saved in full every time, and the setting nobody meant to touch is re-asserted along with everything else.