Английский
Китайский
Испанский
Португальский
Французский
Немецкий
Индонезийский
Тайский
Вьетнамский
Арабский
Итальянский
Турецкий
Польский
Японский
Отказы соединения шлюза MQTT следует исследовать на первом неудачном этапе: разрешение адреса назначения, сетевое соединение, TLS при необходимости, приём брокером или разрешение операции с сообщением. Изменение темы не исправит неудачное рукопожатие TLS. Сохраните ошибку клиента и соответствующий журнал брокера, чтобы следующий тест касался нужного этапа.
Подтвердите, что выполняет установленный шлюз
Для шлюза METRAVON TG451 MQTT указан среди программных функций, но нужный режим прошивки и формат сообщений платформы всё ещё требуют подтверждения. Запишите прошивку, версию MQTT, транспорт, имя узла брокера, порт сервиса и идентификатор этой установки.
Проверьте фактическую спецификацию сервиса: обычный TCP, TLS или другой поддерживаемый транспорт. Не выводите правильный порт из запомненного значения по умолчанию. Подтвердите, что назначение — конечная точка брокера, а не адрес веб-консоли или маршрут балансировщика для другого сервиса.
Ищите отказы соединения MQTT в журналах
| Результат | Вероятный этап | Полезные данные |
|---|---|---|
| Ошибка имени | Разрешение имени назначения не дало пригодного адреса. | Запишите имя узла, результат разрешения и активный сетевой путь без изменения учётных данных. |
| Ошибка порта | Соединение с запрошенным сервисом не установлено. | Сопоставьте попытку с записями прослушивающего сервера и межсетевого экрана. |
| Ошибка TLS | Защищённый сеанс не установлен. | Сохраните ошибку рукопожатия и проверьте время, имя узла и необходимые сертификаты. |
| Отказ брокера | Сервер вернул результат соединения MQTT. | Интерпретируйте результат по согласованной версии протокола и журналу брокера. |
| Нет полезных данных | Приём соединения не дал ожидаемого результата приложения. | Проверьте права тем, обработку содержимого и журнал принятых платформой записей. |
Исправляйте доверие и идентификацию без их обхода
Для TLS подтвердите часы шлюза, срок действия сертификата и имя узла. Частному центру сертификации нужна соответствующая настройка доверия. При взаимном TLS установите совпадение клиентского сертификата с закрытым ключом и их принадлежность нужному устройству.
Не загружайте закрытые ключи в обращения поддержки и не отключайте проверку сертификатов для исчезновения ошибки. Запросите у владельца сервиса ожидаемую цепочку доверия и поддерживаемые настройки соединения, затем применяйте их утверждённым процессом настройки.
Идентификатор клиента MQTT и права публикации — разные вопросы. Брокер может принять соединение, отклонив неразрешённую операцию. Проверьте точную тему, регистр символов и политику учётной записи. В MQTT 3.1.1, принимая новое соединение с идентификатором уже подключённого клиента, брокер отключает прежнего клиента. Поэтому два шлюза с этим идентификатором могут многократно вытеснять друг друга при переподключении. До смены антенн или настроек поддержания соединения сравните идентификаторы клиентов и время соединений брокера.
Отделяйте успешную публикацию от правильного измерения
Брокер передаёт содержимое сообщения; сам по себе он не проверяет инженерный смысл значения датчика. Сравните захваченное сообщение с согласованной схемой и проверенным показанием источника. До объяснения отсутствующего тренда связью проверьте единицы, масштаб, идентификацию источника и время измерения.
PUBACK при QoS 1 подтверждает принятие получателем MQTT ответственности за сообщение, а не сохранение измерения в конечной базе данных. QoS 1 допускает дубликаты; QoS 2 предотвращает повторную доставку в рамках своего протокольного обмена, но не подтверждает обработку последующей базой. Проверьте QoS установленной прошивки и принимающего сервиса, затем определите распознавание и согласование повторных записей приложением. Сохранённое сообщение темы не является архивом временных рядов, а наличие сеанса не доказывает доступность всех прежних измерений.
При нестабильных сеансах сопоставьте настройки поддержания соединения, сетевые перерывы и причины закрытия со стороны сервера. Задавайте повторы и поддержание соединения по требованиям сервиса и наблюдаемым условиям. Агрессивные циклы повторов могут скрыть исходную ошибку и нагрузить получателя.
Сравнивайте с отдельным клиентом только для конкретного вопроса
Утверждённый тестовый клиент в той же сети помогает отделить доступность сервиса от ошибки настройки шлюза. Назначьте ему отдельный идентификатор и разрешённую тестовую тему. Не дублируйте идентификатор работающего устройства и не публикуйте тестовые значения в производственные измерения.
Сохраняйте запись проверенных конечной точки, транспорта и класса учётных данных. Успешное соединение ноутбука через другую сеть полезно, но не подтверждает маршрут, часы или хранилище доверия шлюза.
Вопросы интеграции MQTT
Вопрос 1. Нужно ли менять темы, если брокер вообще не принимает сеанс?
Сначала устраните отказ этапа соединения. Обычное сопоставление тем телеметрии важно после приёма, хотя функции, связанные с установлением соединения, могут иметь собственные требования политики. Используйте реальный результат отказа брокера вместо изменения несвязанных полей.
Вопрос 2. Доказывает ли успешная аутентификация право публикации?
Нет. Подтвердите разрешённые операции и точные пути тем учётной записи. Затем проверьте содержимое, принятое последующим приложением; разрешение передачи и проверка приложением различны.
Вопрос 3. Что включить в запрос поддержки MQTT?
Отправьте модель и прошивку, версию протокола, транспорт, конечную точку, время ошибки и очищенные от секретов результаты клиента/брокера. Если сеанс работает, но данные — нет, приложите пример темы и содержимого со скрытыми конфиденциальными сведениями. Исключите пароли, токены и закрытые ключи.
Итоги
Диагностируйте отказавший этап соединения, затем отдельно проверьте права сообщений и инженерные данные. Запросите у METRAVON проверку конфигурации MQTT с записанной ошибкой и спецификацией сервиса, а не только снимком экрана со статусом «не в сети».
