Ein Geräteprofil beschreibt, wie sich eine Gerätesorte verhält. Jedes Gerät verwendet genau ein Profil. Ändern Sie das Profil, folgen alle Geräte dieses Profils der Änderung. Legen Sie ein Profil je Gerätesorte an: ein Profil pro Sensormodell, pro Firmware-Familie oder pro Sicherheitsbedarf (zum Beispiel ein TLS-Profil und eines für alte Geräte, die kein TLS können).
Öffnen Sie Profile unter Device Profiles im IoT-Menü. Zum Anzeigen wird die Rolle User benötigt, zum Ändern Admin. Die Provisioning-Strategie und die Schlüssel benötigen die separate Berechtigung zur Verwaltung des Provisionings (Administratoren).
Die Profilliste
Die Liste zeigt Name, Transport, Online-Regel, Geräte (der Zähler aktualisiert sich alle 30 s) und Aktualisiert, mit Kennzeichen für Default, Built-in und Platform template. Suchen Sie nach Name und filtern Sie nach Transport und Online-Regel.
Zum Anlegen eines Profils wählen Sie New profile, geben einen Name, eine Description und den Transport ein und wählen Create profile. Grenzwerte, Topics und Logins beginnen mit den Protokollstandards; Sie ändern sie auf der Profilseite. Sie müssen eine Online-Regel wählen, bevor das Profil gespeichert werden kann.
Das Standardprofil
Jede Organisation hat genau ein Standardprofil. Hermetry legt ein Profil namens Default an, sobald es eines benötigt. Es verwendet:
- die Online-Regel Live connection,
- das Standard-Topic-Schema,
- nur Login mit Zugangstoken,
- die Standardgrenzwerte des Protokolls,
- Provisioning Disabled,
- TLS only (port 8883).
Ihr erstes eigenes Profil wird ebenfalls zum Standard. Um ein anderes Profil zum Standard zu machen, öffnen Sie es und wählen Make default. Neue Geräte ohne Profilangabe erhalten das Standardprofil.
Vordefinierte Profile
Einige Protokolle bringen ein vordefiniertes Profil mit, gekennzeichnet mit Built-in profile. Hermetry legt es an, sobald es benötigt wird:
| Vordefiniertes Profil | Verwendet von |
|---|---|
| LoRaWAN EU868 Class A OTAA (1.0.3) | LoRaWAN-Sensoren, die mit New device > LoRaWAN device hinzugefügt werden |
| LoRaWAN gateway | Basics-Station-Gateways |
| Das Profil des Kameraprotokolls | Kameras und Recorder dieses Protokolls |
Ein vordefiniertes Profil behält seinen Transport („A built-in profile keeps its transport: devices of its protocol are registered with it.“: Geräte seines Protokolls werden damit registriert) und kann nicht gelöscht werden. Alles andere darauf ist bearbeitbar, und Sie dürfen es umbenennen.
Profile aus einer Vorlage
Ein lizenziertes Gerät, das Sie beanspruchen, erhält eine Kopie des Profils seines Modells, erstellt aus einer Plattformvorlage. Die Profilkopfzeile zeigt, aus welcher Vorlage und Version es stammt, und manche Felder zeigen from template. Ein solches Profil akzeptiert nur X.509-Zertifikate („This profile accepts X.509 certificates only“: Dieses Profil akzeptiert nur X.509-Zertifikate). Das Provisioning bleibt bei einer Kopie Disabled.
Profilabschnitte
| Reiter | Was Sie festlegen |
|---|---|
| General | Name (1 bis 128 Zeichen, eindeutig in Ihrer Organisation), Description (bis zu 2.000 Zeichen). Zeigt, wann das Profil erstellt und zuletzt geändert wurde, seine ID und was es verwendet (In use). |
| Transport & Authentifizierung | Transport, erlaubte Logins, unverschlüsseltes MQTT, Token in der URL, erlaubte Netzwerke, Befehle ohne TLS, Topic-Schemata, eigene Topics. |
| Online-Status | Wie Hermetry entscheidet, dass ein Gerät online ist. |
| Grenzwerte | Ratenbegrenzungen, Nutzlastgrößen, das In-Flight-Fenster, Inaktivität, Gateway-Kindgeräte, das Standard-Zeitlimit für Befehle. |
| Telemetrieschlüssel | Die Schlüssel, die die Geräte senden, mit Bezeichnungen, Einheiten, Nachkommastellen und Wertebereichen. |
| Konfigurationsschlüssel | Die cfg.*-Schlüssel, die Sie auf den Geräten setzen dürfen. |
| Provisioning | Wie sich Geräte ohne Zugangsdaten selbst registrieren. |
Andere Module fügen Reiter hinzu: Alarm rules, Commands, Firmware, LoRaWAN (LoRaWAN-Profile) und SNMP (SNMP-Profile).
Transport & Authentifizierung
Transport
| Transport | Geräte |
|---|---|
| MQTT | Verbindung über MQTT. |
| HTTP | Senden nur über HTTPS. |
| MQTT and HTTP | Beides. |
| LoRaWAN | Beitritt über den Hermetry LoRaWAN Network Server. Sie melden sich nicht selbst an. |
| Ein Abfrageprotokoll | Werden von der Plattform über einen Endpunkt abgefragt (SNMP-Agenten, Kameras, Recorder). Die MQTT-, Token- und Netzwerkeinstellungen gelten nicht. |
Eine Änderung des Transports ändert nie die Online-Regel; eine Regel, die der Transport nicht nutzen kann, verhindert das Speichern.
Erlaubte Authentifizierung (mindestens eine): Access token, MQTT basic (username and password), X.509 certificate. Siehe Gerätezugangsdaten.
Transportsicherheit
| Einstellung | Standard | Wirkung |
|---|---|---|
| Unverschlüsseltes MQTT | TLS only (port 8883) | Ein Gerät, das sich über den unverschlüsselten Port 1883 anmeldet, wird abgewiesen. Wird ein Profil auf TLS only umgestellt, werden die unverschlüsselten Sitzungen seiner Geräte sofort beendet. Plain MQTT allowed (port 1883) ist für Geräte gedacht, die kein TLS können. |
| Token in der URL (Geräte, die keine Header senden können) | Aus | Erlaubt POST /api/v1/{token}/telemetry und /attributes. Ein solches Profil wird nur noch HTTP: Jeder MQTT-Login seiner Geräte wird abgewiesen. |
| Erlaubte Netzwerke | Leer (beliebiges Netzwerk) | Bis zu 64 IPv4- oder IPv6-Netzwerke (203.0.113.0/24) oder einzelne Adressen. Geräte außerhalb davon werden abgewiesen (MQTT CONNACK 5, HTTP 403). |
| Befehle ohne TLS erlaubt | Leer | Bis zu 32 exakte Befehlsnamen, die ein Gerät während einer Sitzung im Klartext empfangen darf. Jeder andere Befehl wartet auf eine TLS-Sitzung. |
Warnung
Listen Sie nur Befehle ohne TLS auf, deren Missbrauch harmlos ist, etwa sys.info oder sys.ping. Listen Sie niemals sys.reboot, ota.check oder cert.renew. Firmware-Updates und Gerätekonfigurationen werden nie im Klartext gesendet, und ein Werksreset wird gar nicht gesendet.
Topic-Schemata (mindestens eines):
| Schema | Topics |
|---|---|
| Das Standardschema | v1/telemetry, v1/attributes, v1/rpc/… und der Rest des Standardsatzes. Unbekannte v1/…-Topics werden abgewiesen. |
| Legacy compatible | Nur v1/devices/me/telemetry und v1/devices/me/attributes, für bestehende Firmware: keine Befehle, kein Claiming, kein Provisioning und keine Gateway-Topics. |
Sind beide aktiv, teilen sich alte und neue Firmware ein Profil; Downlinks folgen dem, was jedes Gerät abonniert hat.
Eigene Topics (Accept topics outside v1/ as telemetry): Jedes Topic außerhalb von v1/ wird als Telemetrie akzeptiert. Ein JSON-Objekt wird zu Schlüsseln; alles andere wird zu einem einzelnen, in der Größe begrenzten Schlüssel raw.
| Feld | Standard | Bereich |
|---|---|---|
| Schlüssel mit dem Topic präfixieren | Aus: Wenn derselbe Schlüssel auf zwei Topics ankommt, gewinnt der letzte Schreibvorgang | — |
| Maximale Topic-Tiefe (Ebenen) | 8 | 1 bis 16 |
| Maximale Topic-Länge (Zeichen) | 128 | 16 bis 256 |
| Verschiedene Topics je Gerät | 50 | 1 bis 1.000 |
| Maximale Rohnutzlast (Bytes) | 4,096 | 256 bis 65.536, niemals über der Nutzlastobergrenze |
Online-Status
| Regel | Ein Gerät ist online, wenn |
|---|---|
| Live connection | Es hält seine MQTT-Verbindung. Empfohlen für Geräte, die MQTT offen halten. |
| Recent message | Seine letzte Nachricht ist jünger als Erwartetes Intervall (Sekunden) × Faktor. Die Seite zeigt „Shown offline after … without a message.“ (Offline angezeigt nach … ohne Nachricht.) |
| Last seen only | Wird nie als online oder offline angezeigt. Listen zeigen, wann es zuletzt gesehen wurde. |
Erwartetes Intervall beträgt 60 bis 604.800 Sekunden und ist für Letzte Nachricht erforderlich. Faktor liegt bei 1,5 bis 10 (eine Nachkommastelle), standardmäßig 3. HTTP- und LoRaWAN-Geräte halten keine Verbindung, daher wird Live-Verbindung für sie nicht angeboten; abgefragte Geräte verwenden Nur zuletzt gesehen. Siehe Verbindungsstatus und Aktivität.
Limits
Ratenlimits verwenden die Form count:seconds; mehrere Zeitfenster gelten gleichzeitig, wobei jedes länger sein muss als das vorherige (höchstens 4 pro Familie, eine Anzahl von 1 bis 1.000.000 über 1 Sekunde bis 1 Tag). Protokollstandard setzt eine Familie zurück.
| Familie | Standard |
|---|---|
| Telemetrienachrichten | 10:1,300:60 |
| Telemetriepunkte | 200:1,6000:60 |
| Attributaktualisierungen | 5:1,60:60 |
| Attributanfragen | 5:1,60:60 |
| RPC-Nachrichten | 5:1,60:60 |
| Zertifikatanfragen | 1:3600 |
| Verbindungsaufbauten | 6:60 |
Hermetry wendet die Limits für Telemetrienachrichten, Telemetriepunkte und Attributaktualisierungen auf jedes Gerät an. Bei Überschreitung eines Limits wird die Nachricht bestätigt und verworfen. Eigentümer und Administratoren erhalten pro Gerät eine Benachrichtigung pro Stunde. Jedes Gerät erhält seine wirksamen Limits im gemeinsamen Attribut session_limits.
| Feld | Standard | Bereich |
|---|---|---|
| Wiedergabe-Nachrichten pro Sekunde | Leer: die Hälfte der Telemetrieanzahl pro Sekunde | 1 bis 10.000 |
| Max. Nachrichtennutzlast (Bytes) | 65,536 | 1.024 bis 65.536 |
| Max. Downlink-Nutzlast (Bytes) | 65,536 | 1.024 bis 65.536 |
| Max. unbestätigte Nachrichten (MQTT) | 20 | 1 bis 1.000 |
| Inaktivitäts-Timeout (Sekunden) | 600 | 10 bis 604.800. Ein Gerät, das so lange nichts sendet, ist inaktiv (nicht dasselbe wie offline). |
| Max. Kinder eines Gateways | 500 | 0 bis 10.000 |
| Profil neuer Kinder | Generisches Kindprofil | Beliebiges Profil; wird verwendet, wenn das Gateway keinen Typ angibt |
| Standard-RPC-Timeout (Sekunden) | 10 | 1 bis 300 |
Telemetrieschlüssel
Liste der Schlüssel, die die Geräte senden (bis zu 500). Jeder Schlüssel hat einen Typ (Zahl, Ganzzahl, Ja / Nein, Text, JSON) und optional eine Einheit (bis zu 32 Zeichen), eine Bezeichnung (bis 128), Min, Max und Dezimalstellen (0 bis 10). Dashboards nutzen sie: Ein Messgerät übernimmt den Bereich als Standardskala. Schlüssel folgen den Schlüsselregeln: bis zu 64 Zeichen aus A–Z a–z 0–9 _ . -, und sie dürfen nicht mit _, fw_, current_fw_ oder cfg. beginnen.
Nicht aufgelistete Schlüssel werden trotzdem gespeichert. Nicht aufgelistete Schlüssel ablehnen wird gespeichert, aber noch nicht angewendet; die Seite weist darauf hin.
Wenn Sie Schlüssel entfernen oder umbenennen, zeigt das Profil Entfernte Schlüssel werden noch verwendet mit den Alarmregeln und anderen Lesern, die sie lesen, und bietet Auf die neuen Namen aktualisieren oder Behalten an.
Konfigurationsschlüssel
Die cfg.*-Schlüssel, die ein Gerät als gemeinsame Attribute akzeptiert, jeweils mit Typ, Bezeichnung und Grenzwerten: Min, Max, Erlaubte Werte (bis zu 100), Min. Länge und Max. Länge sowie Geheim (nur schreibbar). Konfigurationsabweichung (Unterschiede melden oder Durchsetzen) wird gespeichert, aber noch nicht angewendet. Siehe Attribute.
Bereitstellung
Die Strategie (Deaktiviert, Neue Geräte anlegen erlauben, Nur vorab bereitgestellte Geräte) und die Bereitstellungsschlüssel. Siehe Geräte hinzufügen und beanspruchen.
Änderungen speichern
- Änderungen speichern sendet nur die geänderten Felder; Verwerfen verwirft sie. Ihre Änderungen bleiben im Formular, während Sie zwischen den Registerkarten wechseln.
- Beim Speichern von Änderungen an Transport, Anmeldungen, Netzwerken, Themenschemata oder Limits eines verwendeten Profils fragt das System Verbindungsart der Geräte von … ändern?: Live-Sitzungen, die nicht mehr passen, enden sofort. Wählen Sie Speichern und anwenden.
- Wenn jemand anderes das Profil gespeichert hat, nachdem Sie es geöffnet haben, wird Ihr Speichern abgelehnt: „Jemand anderes hat dieses Profil gespeichert, nachdem Sie es geöffnet haben.“ Verwenden Sie Profil neu laden.
Duplizieren und löschen
- Profil duplizieren erstellt „ein neues Profil mit allen Einstellungen dieses Profils; die Bereitstellung beginnt ausgeschaltet und kein Schlüssel wird kopiert“, benannt
<name> (copy). - Profil löschen wird verweigert für das Standardprofil („zuerst ein anderes Profil als Standard festlegen“), ein integriertes Profil, eine Plattformvorlage und ein Profil, das noch von Geräten, Alarmregeln oder Befehlen verwendet wird („Noch verwendet von …: zuerst verschieben oder entfernen.“).