Diese Seite hilft, wenn sich ein Gerät nicht mit Hermetry verbinden kann, beim Login abgelehnt wird oder seine Verbindung immer wieder abbricht. Sie behandelt MQTT und die HTTP-API für Geräte. Für LoRaWAN-Geräte siehe Troubleshooting joins; für abgefragte (polled) Geräte siehe Polling intervals, back-off and quota.
Wo zuerst nachsehen
| Ort | Zeigt |
|---|---|
| Der Reiter Log des Geräts | Jede Login-Ablehnung mit ihrem Grund und jede Trennung mit ihrem Grund. Der Grund einer Ablehnung wird nie an das Gerät gesendet: er steht nur hier. |
| Die Karte Connection details des Geräts | Der Broker-Host und die Ports, die Ihr Gerät verwenden muss |
| Das eigene Protokoll des Clients | Der empfangene CONNACK-Code bzw. HTTP-Status oder der TLS-Fehler |
Schritt 1: Kann das Gerät den Broker erreichen?
| Symptom am Gerät | Ursache | Abhilfe |
|---|---|---|
| DNS-Auflösung schlägt fehl oder die Verbindung läuft in ein Timeout | Falscher Host, oder eine Firewall blockiert den ausgehenden Port | Verwenden Sie den Host auf der Karte Connection details für die Region Ihrer Organisation. Erlauben Sie ausgehendes TCP 8883 (und 443 für HTTPS). |
| Der TLS-Handshake schlägt fehl | Das Gerät verbindet sich per IP-Adresse (SNI ist erforderlich), hat kein CA-Bundle, oder seine Uhr geht stark falsch, sodass das Zertifikat ungültig erscheint | Per Host-Name verbinden; den CA-Speicher des Systems verwenden; Uhrzeit setzen (NTP) |
| TLS schlägt auf einem sehr kleinen Gerät fehl | Es unterstützt nur alte Cipher-Suites oder TLS 1.0/1.1 | TLS 1.2 ist das Minimum, mit ECDHE- und GCM- bzw. ChaCha20-Suites. Aktualisieren Sie die TLS-Bibliothek. |
| Port 1883 wird abgelehnt | Das Profil ist TLS only (port 8883), die Standardeinstellung | Verwenden Sie 8883 oder erlauben Sie, nur in einem privaten Netzwerk, unverschlüsseltes MQTT im Profil |
| Ein Client-Zertifikat wird beim Handshake abgelehnt | Das Zertifikat stammt nicht von der Geräte-CA von Hermetry, oder es wurde widerrufen | Ein nicht vertrauenswürdiges Zertifikat beendet den Handshake; es gibt keinen Rückfall auf ein Passwort. Siehe Device certificates. |
Siehe Device transport security.
Schritt 2: Wird der Login akzeptiert?
MQTT antwortet auf das CONNECT mit einem CONNACK-Code:
| CONNACK | Bedeutung | Übliche Ursachen |
|---|---|---|
| 1 | Protokollversion nicht unterstützt | Der Client sendet MQTT 5. Hermetry spricht MQTT 3.1.1. |
| 2 | Client-ID abgelehnt | Die Client-ID ist leer, länger als 64 Zeichen oder enthält Zeichen außerhalb von A–Z a–z 0–9 . _ : - |
| 3 | Server nicht verfügbar | Der Dienst startet oder ist ausgelastet, oder Ihre Adresse ist nach wiederholten fehlgeschlagenen Logins kurzzeitig gesperrt. Warten Sie ab (back-off) und versuchen Sie es mit Jitter erneut. |
| 4 | Ungültiger Benutzername oder Passwort | Das Token oder Passwort ist falsch, wurde rotiert oder widerrufen; ein Benutzername ohne Passwort wird als Zugriffstoken gelesen |
| 5 | Nicht autorisiert | Siehe die Tabelle unten. Der genaue Grund steht im Reiter Log des Geräts. |
| Grund hinter CONNACK 5 | Abhilfe |
|---|---|
| Das Gerät ist deaktiviert | Auf der Geräteseite aktivieren |
| Das Zertifikat ist widerrufen oder abgelaufen | Lassen Sie das Gerät erneuern oder stellen Sie es wieder her. Siehe Device certificates. |
| Das Profil erlaubt diesen Login-Typ nicht | Allowed authentication im Reiter Transport & auth des Profils |
| Die Adresse des Geräts liegt außerhalb der Allowed networks des Profils | Netzwerk hinzufügen, oder prüfen, welche öffentliche Adresse Ihr Standort tatsächlich nutzt (NAT, Mobilfunkanbieter) |
| Unverschlüsseltes MQTT in einem Profil nur für TLS | Port 8883 verwenden |
| Die Organisation ist gesperrt | Wenden Sie sich an einen Inhaber der Organisation. Siehe Organisations and tenants. |
| Das Geräte- bzw. Verbindungslimit des Tarifs ist erreicht | Siehe Plans and the IoT add-on |
Über HTTP liefern dieselben Prüfungen 401 (Token fehlt oder unbekannt), 403 (deaktiviert, gesperrt, außerhalb der erlaubten Netzwerke, oder eine Befehlsabfrage über unverschlüsseltes HTTP, die das Profil nicht erlaubt: tls_required) oder 404 (ein Token in der URL bei einem Profil ohne Token in the URL). Siehe Device HTTP API.
Hinweise zum Login
| Zugangsdaten | Client-ID | Benutzername | Passwort |
|---|---|---|---|
| Zugriffstoken | beliebige gültige ID | das Token | leer |
| MQTT basic | beliebig, oder der fixierte | der Benutzername | das Passwort |
| X.509-Zertifikat | die Geräteseriennummer, gleich dem CN des Zertifikats | ignoriert | leer |
Das Geheimnis einer Zugangsdaten wird nur einmal angezeigt, bei Erstellung oder Rotation. Ist es verloren, rotieren Sie es und aktualisieren Sie das Gerät. Siehe Device credentials.
Schritt 3: Das Gerät verbindet sich, trennt dann aber
Der Reiter Log nennt den Trennungsgrund:
| Grund | Bedeutung | Abhilfe |
|---|---|---|
keepalive_timeout | Innerhalb der Keepalive-Zeit kam nichts an | Ein Keepalive von 30 bis 300 Sekunden verwenden und PINGREQ senden; die Mobilfunkverbindung prüfen |
takeover | Eine zweite Verbindung desselben Geräts hat übernommen | Zwei Geräte teilen sich eine Zugangsdaten, oder ein Client verbindet sich neu, ohne die alte Verbindung zu schließen. Geben Sie jedem Gerät eigene Zugangsdaten. |
auth_revoked | Die Zugangsdaten, das Gerät oder die Organisation sind nicht mehr erlaubt | Sitzungen werden etwa alle 60 Sekunden erneut geprüft; rotierte Zugangsdaten beenden die alte Sitzung |
rate_limit | Das Gerät hat wiederholt sein Ratenlimit überschritten (mehr als das Dreifache seines Minutenkontingents innerhalb einer Minute verworfen) | Messwerte bündeln, seltener senden oder die Limits des Profils erhöhen |
inflight_exceeded | Zu viele unbestätigte QoS-1-Nachrichten (standardmäßig 20) | Auf PUBACKs warten, bevor weitere Nachrichten gesendet werden |
server_shutdown | Ein Broker-Knoten wurde neu gestartet | Neu verbinden; nichts zu beheben |
uplink_window_expired | Das Online-Fenster Recent message ist abgelaufen | Erwartet bei Geräten, die nur zum Senden verbinden |
protocol_error, socket_error | Der Client hat das Protokoll verletzt, oder das Netzwerk ist ausgefallen | Client aktualisieren; Verbindung prüfen |
Ein Gerät, dessen Sitzung von zwei Netzwerken aus immer wieder übernommen wird, wird eine Zeit lang zurückgehalten, und Ihre Administratoren erhalten eine Meldung „takeover fight“.
Schritt 4: Das Gerät verbindet sich, wird aber als offline angezeigt
| Ursache | Prüfung |
|---|---|
| Die Online-Regel des Profils | Live connection, Recent message oder Last seen only legen fest, was „online“ bedeutet. Siehe Connection status and activity. |
| Quarantäne | Ein selbst registriertes Gerät, das in Quarantäne wartet, verbindet sich, aber seine Daten werden bestätigt und verworfen, bis ein Administrator es aktiviert. Siehe Quarantine. |
| Das Gerät ist ein Gateway-Kindgerät | Sein Status stammt aus den Nachrichten v1/gw/connect und v1/gw/disconnect des Gateways. Siehe Devices behind a gateway. |
Ein falsch konfiguriertes Gerät sperrt andere aus
Wiederholte fehlgeschlagene Logins von einer Adresse sperren diese Adresse kurz, für jedes Gerät dahinter. Mehrere Geräte hinter einem NAT oder einem mobilen Router werden dann alle mit CONNACK 3 (HTTP 429) abgelehnt. Finden Sie das Gerät mit falschen Zugangsdaten (sein Reiter Log zeigt die Fehlversuche), beheben Sie es, und lassen Sie die anderen mit back-off erneut versuchen.
Empfohlenes Geräteverhalten
- Per TLS über den Host-Namen verbinden, mit einem Keepalive zwischen 30 und 300 Sekunden.
- Nach CONNACK 0 die Downlink-Topics abonnieren, gemeinsame Attribute anfordern, Client-Attribute melden und dann gepufferte Messwerte senden.
- Bei einer Ablehnung zurückhalten (back off): CONNACK 3 mit Jitter erneut versuchen; nach CONNACK 4 mindestens 5 Minuten warten; bei CONNACK 1 und 2 nicht mehr erneut versuchen, bis sich die Konfiguration ändert.
Siehe MQTT.