SMPP подходит для систем, которые получают события от счётчиков, датчиков и терминалов и должны быстро передать уведомление по SMS. В статье разберём схему такой интеграции: как устройство передаёт событие на сервер, зачем нужен промежуточный сервис, какие параметры настроить в SMPP и как проверять доставку через DLR. После чтения можно составить техническое задание для разработчика и подготовить тестовое подключение к SMS-шлюзу.
Какие задачи IoT-системы решают через SMPP?
Счётчик или датчик обычно не отправляет SMS напрямую. Устройство передаёт показание или сигнал на сервер производителя, оператора оборудования либо внутреннее приложение. Сервер анализирует событие и решает, кому нужно отправить уведомление. SMPP подключает этот сервер к SMS-шлюзу и передаёт сообщение на мобильную сеть.
Для малого бизнеса сценарий может выглядеть так: датчик фиксирует отключение питания, терминал сообщает об ошибке, а система контроля объекта получает превышение заданного значения. В каждом случае приложение формирует короткое SMS с типом события, временем и идентификатором оборудования. SMPP отвечает за передачу сообщения в шлюз, а отчёт DLR помогает понять, доставлено ли оно.
Протокол особенно уместен, когда сообщения формирует программа, а не сотрудник в личном кабинете. Сервер может создавать отправки автоматически, задавать приоритет, обрабатывать ответы шлюза и принимать статусы доставки. При небольшом количестве уведомлений разработчику проще начать с API или готового конструктора, но при постоянном потоке событий SMPP даёт прямое подключение к SMS-шлюзу и позволяет контролировать обмен на уровне приложения.
Как выглядит схема отправки SMS от датчика?
Надёжная схема состоит из нескольких отдельных этапов. Датчик передаёт событие в систему мониторинга, система проверяет правила, очередь сообщений удерживает задания, а SMPP-клиент соединяется со шлюзом и отправляет SMS. Такое разделение помогает повторить отправку при временной ошибке и не связывать работу оборудования с состоянием одного сетевого соединения.
- Устройство передаёт событие на сервер мониторинга.
- Приложение определяет тип уведомления и получателя.
- Сообщение попадает в очередь отправки.
- SMPP-клиент открывает соединение со шлюзом и выполняет bind.
- Приложение отправляет сообщение командой submit_sm.
- Шлюз возвращает идентификатор сообщения и принимает его к обработке.
- Система получает DLR и сохраняет итоговый статус.
Очередь нужна даже в простой системе. Если одновременно сработали несколько датчиков, приложение не теряет события из-за задержки сети и не пытается отправить всё одним запросом. Для каждого задания полезно хранить внутренний идентификатор события, время создания, адрес получателя, статус SMPP и текст ошибки.
Связь с шлюзом лучше держать отдельным сервисом. Он следит за соединением, повторяет bind после разрыва, ограничивает скорость отправки и передаёт результат в основное приложение. Такая архитектура пригодится, если один сервер одновременно получает данные от терминалов, счётчиков и датчиков.
Какие настройки SMPP нужны для IoT-уведомлений?
До начала разработки согласуйте параметры подключения со шлюзом. В техническом задании обычно фиксируют адрес и порт, логин, пароль, тип bind, системный идентификатор, допустимую скорость, формат адресов и правила работы с отчётами. Без этого разработчик может подключиться к серверу, но не сможет корректно обработать полный цикл доставки.
| Параметр | Зачем он нужен | Что проверить |
|---|---|---|
| Тип соединения | Определяет режим работы SMPP-клиента | Нужен ли bind_transceiver или отдельные соединения для отправки и приёма статусов |
| System ID и пароль | Позволяют шлюзу распознать подключение | Совпадают ли значения с настройками провайдера |
| Адрес и порт | Определяют точку подключения | Разрешён ли доступ с сервера и открыт ли нужный порт |
| TON и NPI | Описывают тип и план нумерации адресов | Соответствуют ли настройки формату номеров |
| Data coding | Определяет кодировку текста | Корректно ли передаётся кириллица и длинные сообщения |
| DLR | Возвращает статус обработки и доставки | Приходит ли отчёт и связывается ли он с исходным сообщением |
Для текста на русском языке отдельно проверьте кодировку и длину сообщения. Ошибка в data_coding приводит к нечитаемым символам, а длинный текст может разделиться на несколько частей. Практические детали передачи кириллицы, UCS-2 и конкатенации разобраны в материале о кодировках SMS в SMPP.
Отправитель тоже нужно согласовать заранее. Если система передаёт имя отправителя в source_addr, шлюз может применять свои правила к его формату. Для аварийных уведомлений лучше использовать короткий шаблон: название объекта, тип события и действие, которое нужно выполнить. Длинные пояснения оставьте интерфейсу мониторинга.
Как обработать DLR и ошибки доставки?
Для IoT-системы сам факт принятия команды submit_sm недостаточен. Он показывает, что шлюз получил сообщение, но не подтверждает доставку на телефон. Итоговый статус приходит отдельным отчётом DLR, который нужно связать с message_id из ответа шлюза.
Приложение должно различать временные и окончательные ошибки. При временной проблеме соединения задание можно вернуть в очередь с ограниченным числом повторов. Если шлюз сообщает об окончательном отказе, повторная отправка того же текста без изменения причины только создаст лишний трафик. Статус и код ошибки лучше сохранить в журнале, чтобы оператор видел, какое событие не дошло.
- Проверяйте, что DLR включён в параметрах submit_sm.
- Сохраняйте исходный message_id в базе или очереди.
- Сопоставляйте статусы независимо от порядка их поступления.
- Разделяйте timeout, разрыв соединения и отказ шлюза.
- Ограничивайте число повторов для одного события.
- Показывайте оператору время последней попытки и текст ошибки.
При работе с номерами Беларуси отдельный интерес представляют маршрутизация и DLR после переноса номера между сетями. Обработка MNP и отчётов доставки описана в материале о MNP и DLR для белорусских номеров. Это полезно проверить до запуска системы, если оборудование отправляет уведомления на номера разных операторов.
Как протестировать SMPP до подключения реальных датчиков?
Сначала тестируют сам канал, затем бизнес-логику и только после этого подключают оборудование. На первом этапе достаточно тестового SMPP-клиента. Он должен выполнить bind, отправить короткое сообщение, получить response и принять DLR. Если уже здесь возникают проблемы, датчик не поможет их скрыть.
- Проверьте подключение и корректность bind.
- Отправьте сообщение с латиницей и отдельное SMS на кириллице.
- Проверьте короткий и составной текст.
- Сымитируйте временный разрыв соединения.
- Убедитесь, что повтор не создаёт бесконечную очередь.
- Сопоставьте DLR с конкретным событием оборудования.
Для отладки удобно заранее подготовить журнал с полями: время события, время постановки в очередь, message_id, адрес, команда SMPP, ответ шлюза и финальный статус. Не записывайте в журнал весь поток без ограничений: сервис должен уметь фильтровать записи по объекту и периоду, иначе поиск одной ошибки станет отдельной технической задачей.
Если приложение ещё не умеет работать с SMPP, разработчику понадобится клиентская библиотека или собственный транспортный модуль. При выборе шлюза уточните поддержку DLR, пропускную способность и правила подключения. Профессиональные SMPP-интеграции обычно дают прямой доступ к SMS-шлюзу, что позволяет передавать большой поток уведомлений из собственной инфраструктуры.
Типичные ошибки при отправке SMS от устройств
- Приложение считает SMS доставленным сразу после submit_sm.
- Система не хранит message_id и не может связать DLR с событием.
- При разрыве TCP-соединения очередь отправляет одно уведомление бесконечно.
- Кириллица передаётся с неверным data_coding и превращается в нечитаемый текст.
- Датчик отправляет повторные сигналы, а приложение не объединяет одинаковые события.
- В одном соединении смешаны логика мониторинга и транспорт SMPP, поэтому сбой канала останавливает обработку событий.
Для проекта на smpp.by разумно начинать с описания потока: какое устройство создаёт событие, кто получает SMS, какой текст уходит, сколько попыток допускается и какой статус считается успешным. Затем разработчик проверяет SMPP в тестовом режиме, подключает DLR и только после этого связывает канал с рабочим мониторингом. Такой порядок оставляет техническую отправку отдельно от логики оборудования и упрощает дальнейшее расширение системы.
