2.2.1 brings remote device settings.
A device that describes its own settings can be configured from its Settings tab: its settings in sections, each with its status, when it was last applied and whether the last change came from here or from the device. You change a value, the device applies it and reports back.
For many devices there are baselines and change jobs, under Bulk settings in the IoT menu. A baseline is a named set of settings for your device models; only the settings you include in it are changed, and it never holds a password or a key. A job applies a baseline to the devices you pick (or every device of a profile or of some models) in waves, and stops when a wave goes worse than you allow. Before it starts, Check shows what the job will do.
All of it is also in the API: per device under /api/iot/devices/{deviceId}/settings, baselines and jobs under /api/iot/device-settings/. See Remote device settings and Firmware and device settings API.
One smaller change in the same release: built-in device profiles can’t be deleted and keep their transport.
So my ESP32 boards will get a Settings tab? They’re on MQTT with my own firmware.
Not this way, sorry. Two things have to be true: the firmware announces its settings sections when it connects, and Hermetry has the settings description (the manifest) for that model and firmware. Licensed devices have both.
For your own boards, declare cfg.* keys on the profile’s Configuration keys tab (type, limits, allowed values) and let the firmware read them as shared attributes. You get typed keys with limits, and the Attributes tab shows each one as In sync, Pending, Rejected or Drifted, without writing a manifest. Attributes has the device side.
What happens when a job is running and one of my technicians changes the same device by hand from its page?
The person wins. Only one writer changes a device’s section at a time, and a person’s change on the device page wins over the job; “Changed by a person” is one of the states a device can show in the job. When two jobs want the same device, the job’s setting decides whether it waits or skips the device.
Dangerous settings are Owner only. Am I right that an API key can never write those then?
Right. iot_device_settings.dangerous.write is Owner only, so an API key never has it, and the request also needs “confirm”: true.
Ran our first job last week, 38 routers, one value in the network section. We set our own wave sizes (5 and 25, then the rest). The two routers that had been offline longer than the wait setting were left out, which is what we wanted. Typing START felt silly the first time but I get why.
- You must be logged in to reply to this topic.
Join the conversation
Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.