A device profile describes how one kind of device behaves. Every device uses exactly one profile. Change the profile, and every device of it follows. Create one profile per kind of device: a profile per sensor model, per firmware family, or per security need (for example one TLS profile and one for old devices that cannot do TLS).
Open profiles in Device Profiles in the IoT menu. Viewing needs the User role; changing needs Admin. The provisioning strategy and keys need the separate permission to manage provisioning (administrators).
The profiles list
The list shows Name, Transport, Online rule, Devices (the count updates every 30 s) and Updated, with badges for Default, Built-in and Platform template. Search by name and filter by transport and online rule.
To create a profile, select New profile, enter a Name, a Description and the Transport, and select Create profile. Limits, topics and logins start from the protocol defaults; you change them on the profile page. You must choose an online rule before the profile can be saved.
The default profile
Each organisation has exactly one default profile. Hermetry creates a profile named Default the first time it needs one. It uses:
- the Live connection online rule,
- the default topic scheme,
- access-token login only,
- the protocol’s standard limits,
- provisioning Disabled,
- TLS only (port 8883).
Your first own profile also becomes the default. To make another profile the default, open it and select Make default. New devices that name no profile get the default one.
Built-in profiles
Some protocols come with a built-in profile, marked Built-in profile. Hermetry creates it the first time it is needed:
| Built-in profile | Used by |
|---|---|
| LoRaWAN EU868 Class A OTAA (1.0.3) | LoRaWAN sensors added with New device > LoRaWAN device |
| LoRaWAN gateway | Basics Station gateways |
| The camera protocol’s profile | Cameras and recorders of that protocol |
A built-in profile keeps its transport (“A built-in profile keeps its transport: devices of its protocol are registered with it.”) and cannot be deleted. Everything else on it is editable, and you may rename it.
Profiles from a template
A licensed device that you claim gets a copy of its model’s profile, made from a platform template. The profile header says which template and version it came from, and some fields show from template. Such a profile accepts X.509 certificates only (“This profile accepts X.509 certificates only”). Provisioning stays Disabled on a copy.
Profile sections
| Tab | What you set |
|---|---|
| General | Name (1 to 128 characters, unique in your organisation), Description (up to 2,000 characters). Shows when the profile was created and last changed, its ID, and what uses it (In use). |
| Transport & auth | Transport, allowed logins, plain MQTT, token in the URL, allowed networks, commands allowed without TLS, topic schemes, custom topics. |
| Online status | How Hermetry decides that a device is online. |
| Limits | Rate limits, payload sizes, the in-flight window, inactivity, gateway children, the default command timeout. |
| Telemetry keys | The keys the devices send, with labels, units, decimals and ranges. |
| Configuration keys | The cfg.* keys you may set on the devices. |
| Provisioning | How devices without credentials register themselves. |
Other modules add tabs: Alarm rules, Commands, Firmware, LoRaWAN (LoRaWAN profiles) and SNMP (SNMP profiles).
Transport & auth
Transport
| Transport | Devices |
|---|---|
| MQTT | Connect over MQTT. |
| HTTP | Send over HTTPS only. |
| MQTT and HTTP | Either. |
| LoRaWAN | Join through the Hermetry LoRaWAN network server. They do not log in themselves. |
| A polling protocol | Are polled by the platform through an endpoint (SNMP agents, cameras, recorders). The MQTT, token and network settings do not apply. |
Changing the transport never changes the online rule; a rule the transport cannot use blocks saving.
Allowed authentication (at least one): Access token, MQTT basic (username and password), X.509 certificate. See Device credentials.
Transport security
| Setting | Default | Effect |
|---|---|---|
| Plain MQTT | TLS only (port 8883) | A device that logs in on the plain port 1883 is refused. Switching a profile to TLS only ends its devices’ plain sessions at once. Plain MQTT allowed (port 1883) is for devices that cannot do TLS. |
| Token in the URL (devices that cannot send headers) | Off | Allows POST /api/v1/{token}/telemetry and /attributes. Such a profile becomes HTTP-only: every MQTT login of its devices is refused. |
| Allowed networks | Empty (any network) | Up to 64 IPv4 or IPv6 networks (203.0.113.0/24) or single addresses. Devices outside them are refused (MQTT CONNACK 5, HTTP 403). |
| Commands allowed without TLS | Empty | Up to 32 exact command names a device may receive over a session in clear. Every other command waits for a TLS session. |
Warning
Only list commands without TLS whose misuse is harmless, such as sys.info or sys.ping. Never list sys.reboot, ota.check or cert.renew. Firmware updates and device settings are never sent in clear, and a factory reset is never sent at all.
Topic schemes (at least one):
| Scheme | Topics |
|---|---|
| The default scheme | v1/telemetry, v1/attributes, v1/rpc/… and the rest of the default set. Unknown v1/… topics are rejected. |
| Legacy compatible | v1/devices/me/telemetry and v1/devices/me/attributes only, for existing firmware: no commands, claiming, provisioning or gateway topics. |
With both on, old and new firmware share one profile; downlinks follow what each device subscribed to.
Custom topics (Accept topics outside v1/ as telemetry): any topic outside v1/ is accepted as telemetry. A JSON object becomes keys; anything else becomes one size-capped raw key.
| Field | Default | Range |
|---|---|---|
| Prefix keys with the topic | Off: when the same key arrives on two topics, the last write wins | — |
| Max topic depth (levels) | 8 | 1 to 16 |
| Max topic length (characters) | 128 | 16 to 256 |
| Distinct topics per device | 50 | 1 to 1,000 |
| Max raw payload (bytes) | 4,096 | 256 to 65,536, never above the payload cap |
Online status
| Rule | A device is online when |
|---|---|
| Live connection | It holds its MQTT connection. Recommended for devices that keep MQTT open. |
| Recent message | Its last message is younger than Expected interval (seconds) × Factor. The page shows “Shown offline after … without a message.” |
| Last seen only | Never shown as online or offline. Lists show when it was last seen. |
Expected interval is 60 to 604,800 seconds and required for Recent message. Factor is 1.5 to 10 (one decimal), 3 by default. HTTP and LoRaWAN devices hold no connection, so Live connection is not offered for them; polled devices use Last seen only. See Connection status and activity.
Limits
Rate limits use the form count:seconds; several windows apply together, each longer than the one before (at most 4 per family, a count of 1 to 1,000,000 over 1 second to 1 day). Protocol default puts a family back.
| Family | Default |
|---|---|
| Telemetry messages | 10:1,300:60 |
| Telemetry points | 200:1,6000:60 |
| Attribute updates | 5:1,60:60 |
| Attribute requests | 5:1,60:60 |
| RPC messages | 5:1,60:60 |
| Certificate requests | 1:3600 |
| Connects | 6:60 |
Hermetry applies the telemetry messages, telemetry points and attribute updates limits to each device. Over a limit, the message is acknowledged and dropped. Owners and administrators get one notice per device per hour. Each device receives its effective limits in the shared attribute session_limits.
| Field | Default | Range |
|---|---|---|
| Replay messages per second | Empty: half the per-second telemetry count | 1 to 10,000 |
| Max message payload (bytes) | 65,536 | 1,024 to 65,536 |
| Max downlink payload (bytes) | 65,536 | 1,024 to 65,536 |
| Max unacknowledged messages (MQTT) | 20 | 1 to 1,000 |
| Inactivity timeout (seconds) | 600 | 10 to 604,800. A device that sends nothing this long is inactive (not the same as offline). |
| Max children of a gateway | 500 | 0 to 10,000 |
| Profile of new children | Generic child profile | Any profile; used when the gateway names no type |
| Default RPC timeout (seconds) | 10 | 1 to 300 |
Telemetry keys
List the keys the devices send (up to 500). Each key has a Type (Number, Whole number, Yes / no, Text, JSON) and optionally a Unit (up to 32 characters), Label (up to 128), Min, Max and Decimals (0 to 10). Dashboards use them: a gauge takes the range as its default scale. Keys follow the key rules: up to 64 characters from A–Z a–z 0–9 _ . -, and not starting with _, fw_, current_fw_ or cfg..
Keys that are not listed are still stored. Refuse keys that are not listed is stored but not applied yet; the page says so.
When you remove or rename keys, the profile shows Removed keys are still in use with the alarm rules and other readers that read them, and offers Update them to the new names or Keep.
Configuration keys
The cfg.* keys a device accepts as shared attributes, each with a type, label and limits: Min, Max, Allowed values (up to 100), Min length and Max length, and Secret (write-only). Configuration drift (Report differences or Enforce) is stored but not applied yet. See Attributes.
Provisioning
The strategy (Disabled, Allow creating new devices, Only pre-provisioned devices) and the provisioning keys. See Adding and claiming devices.
Saving changes
- Save changes sends only the fields you changed; Discard drops them. Your changes stay in the form while you switch tabs.
- Saving changes to transport, logins, networks, topic schemes or limits of a profile in use asks Change how the devices of … connect?: live sessions that no longer qualify end now. Select Save and apply.
- If someone else saved the profile after you opened it, your save is refused: “Someone else saved this profile after you opened it.” Use Reload profile.
Duplicate and delete
- Duplicate profile makes “a new profile with every setting of this one; provisioning starts off and no key is copied”, named
<name> (copy). - Delete profile is refused for the default profile (“make another profile the default first”), a built-in profile, a platform template, and a profile that devices, alarm rules or commands still use (“Still used by …: move or remove them first.”).