CUPS и LNS: раздельная диагностика Basics Station
Шлюз может успешно обратиться к сервису конфигурации, но не передавать измерения в сетевой сервер. Возможна и обратная ситуация: текущий обмен работает, а обновление конфигурации недоступно. В Basics Station эти состояния нужно различать, иначе успешный ответ одного сервиса создаёт ошибочное впечатление исправности всей цепочки.
Нарисовать два назначения соединений
Документация Semtech описывает CUPS как протокол обмена конфигурацией и обновлениями. (Semtech — LoRa Basics Station CUPS Protocol2.0.6) LNS протокол относится к взаимодействию с сетевой частью и передаче данных. (Semtech — LoRa Basics Station LNS Protocol2.0.6) Для установленной версии уточните фактические адреса, доверенные данные и последовательность подключения.
В паспорте шлюза заведите отдельные строки для каждого пути. Не объединяйте их одним полем «сервер доступен». Даже если сервисы размещены у одного поставщика, они могут иметь разные конечные точки, сертификаты и эксплуатационные причины недоступности.
Определить последнее подтверждённое действие
Сохраните журнал запуска и последующие события. Найдите обращение к CUPS и результат обработки ответа, затем отдельно установление рабочего LNS соединения. Отсутствующее событие не заменяйте предположением, что шлюз обязательно выполнил следующий этап автоматически.
Проверьте, какие параметры действительно применены после ответа сервиса. Получение новой конфигурации и её успешное использование являются разными фактами. Если требуется перезапуск, это должно следовать из документации конкретной сборки и быть отражено в программе испытания.
Исследовать каждый путь независимо
Для недоступного соединения проверьте разрешение имени, сетевую достижимость, время системы и доверие к конечной точке в пределах доступной диагностики. Не подменяйте проверку отключением контроля сертификата. Для отчёта достаточно статуса и описания ошибки без публикации закрытых данных.
Если LNS соединён, выполните безопасный контрольный обмен реального узла. Если CUPS отвечает, подтвердите ожидаемое действие конфигурационного механизма на учебной установке. Не отправляйте произвольный пакет обновления на рабочий шлюз только ради появления успешного события в журнале.
Проверить восстановление без выезда
По согласованному сценарию воспроизведите кратковременную потерю доступности одного сервиса. Установите, сохраняется ли нужный текущий обмен и как возвращается соответствующее соединение. Поведение зависит от реализации, поэтому универсальная последовательность команд здесь не назначается.
В эксплуатационной карте сохраните независимые признаки состояния CUPS и LNS, а также ответственного за каждый сервис. После обновления доверенных данных повторите оба контроля. Такая приёмка позволяет быстро определить, нарушено ли получение конфигурации, рабочий поток измерений или оба пути, не маскируя различие общей зелёной отметкой «шлюз онлайн».