Inglese
Cinese
Spagnolo
Russo
Portoghese
Francese
Tedesco
Indonesiano
Tailandese
Vietnamita
Arabo
Turco
Polacco
Giapponese
I guasti di connessione MQTT vanno esaminati alla prima fase fallita: risoluzione della destinazione, connessione di rete, TLS se richiesto, accettazione del broker o autorizzazione del messaggio. Cambiare un argomento non ripara una negoziazione TLS fallita. Conservare errore del client e registro corrispondente del broker per indirizzare il test successivo alla fase corretta.
Confermare cosa esegue il gateway installato
Il gateway METRAVON TG451 elenca MQTT tra le funzioni software, ma vanno ancora confermate modalità firmware richiesta e struttura dei messaggi per la piattaforma. Registrare versione firmware, versione MQTT, trasporto, nome host del broker, porta di servizio e identità assegnata all’installazione.
Verificare la specifica effettiva del servizio per TCP non cifrato, TLS o altro trasporto supportato. Non dedurre la porta da un valore predefinito ricordato. Confermare che la destinazione sia l’endpoint del broker, non la console web o una rotta del bilanciatore per un altro servizio.
Localizzare i guasti MQTT nei registri
| Risultato | Fase probabile | Prove utili |
|---|---|---|
| Nome non risolto | La risoluzione della destinazione non ha prodotto un indirizzo utilizzabile. | Registrare nome host, risultato del risolutore e percorso attivo senza cambiare credenziali. |
| Porta non raggiunta | La connessione al servizio richiesto non è stabilita. | Confrontare il tentativo con registri del servizio in ascolto e del firewall. |
| Errore TLS | La sessione sicura non è stabilita. | Conservare l’errore di negoziazione e verificare ora, nome host e certificati richiesti. |
| Rifiuto del broker | Il server ha restituito un risultato di connessione MQTT. | Interpretarlo usando versione negoziata e registro del broker. |
| Nessun dato utile | L’accettazione della connessione non ha prodotto il risultato applicativo atteso. | Verificare permessi sugli argomenti, trattamento del contenuto e registro dei dati accettati. |
Correggere fiducia e identità senza aggirarle
Per TLS confermare orologio del gateway, validità del certificato e nome host. Un’autorità di certificazione privata richiede la corretta configurazione di fiducia. Se è richiesto TLS reciproco, verificare che certificato client e chiave privata corrispondano e appartengano al dispositivo previsto.
Non caricare chiavi private nelle richieste d’assistenza né disabilitare la verifica dei certificati per far sparire l’errore. Chiedere al responsabile del servizio catena di fiducia e impostazioni supportate, poi applicarle tramite la configurazione autorizzata.
Identità del client MQTT e permessi di pubblicazione sono aspetti separati. Un broker può accettare la connessione ma rifiutare un’operazione non autorizzata. Verificare argomento esatto, maiuscole/minuscole e regole dell’account. Con MQTT 3.1.1, quando un broker accetta una nuova connessione con un identificativo client già collegato, disconnette il client esistente. Due gateway con lo stesso identificativo possono quindi espellersi ripetutamente riconnettendosi. Confrontare identificativi e orari di connessione prima di cambiare antenne o mantenimento della connessione.
Separare pubblicazione riuscita e misura corretta
Il broker trasporta un contenuto, ma non ne convalida intrinsecamente il significato ingegneristico. Confrontare un messaggio acquisito con lo schema concordato e una lettura sorgente verificata. Verificare unità, scala, identità sorgente e ora di acquisizione prima di diagnosticare l’assenza della tendenza come problema di connettività.
Un PUBACK QoS 1 conferma che il ricevitore MQTT ha assunto la responsabilità del messaggio, non che il database finale abbia memorizzato la misura. QoS 1 può consegnare duplicati; QoS 2 impedisce consegne duplicate nel proprio scambio di protocollo, ma non certifica l’elaborazione successiva nel database. Verificare il QoS supportato da firmware e servizio ricevente, poi definire come l’applicazione identifichi e riconcili dati ripetuti. Un messaggio conservato non è un archivio temporale e l’esistenza di una sessione non prova che ogni misura precedente sia ancora disponibile.
Per sessioni instabili confrontare mantenimento della connessione, interruzioni di rete e motivi di chiusura lato server. Impostare tentativi e mantenimento dai requisiti del servizio e dalle condizioni osservate. Cicli aggressivi possono nascondere l’errore originale e caricare la destinazione.
Usare un client di confronto isolato solo per una domanda precisa
Un client approvato sulla stessa rete può distinguere raggiungibilità del servizio e configurazione del gateway. Assegnargli identità separata e argomento di prova consentito. Non duplicare l’identità di un dispositivo attivo né pubblicare valori di prova nelle misure produttive.
Registrare endpoint, trasporto e categoria di credenziali provati. Una connessione riuscita da un portatile su un’altra rete è utile, ma non verifica rotta, orologio o archivio di fiducia del gateway.
Domande d’integrazione MQTT
D1. Vanno cambiati gli argomenti se il broker non accetta mai la sessione?
Risolvere prima la fase di connessione fallita. La normale mappatura degli argomenti telemetrici è pertinente dopo l’accettazione, anche se funzioni associate alla connessione possono avere proprie regole. Usare il risultato reale di rifiuto del broker invece di cambiare campi estranei.
D2. Autenticazione riuscita significa permesso di pubblicare?
No. Confermare operazioni autorizzate e percorsi esatti degli argomenti dell’account. Poi verificare il contenuto accettato dall’applicazione a valle; autorizzazione al trasporto e convalida applicativa sono distinte.
D3. Cosa includere nella richiesta d’assistenza MQTT?
Inviare modello e firmware, versione del protocollo, trasporto, endpoint, ora dell’errore e risultati client/broker senza dati riservati. Includere esempi oscurati di argomento e contenuto se la sessione funziona ma i dati no. Escludere password, token e chiavi private.
Riepilogo
Diagnosticare la fase di connessione fallita, poi verificare separatamente permessi dei messaggi e dati ingegneristici. Richiedere una verifica della configurazione MQTT METRAVON con errore registrato e specifica del servizio, non solo una schermata di stato non in linea.
