посоветуйте USB-модем для рассылки SMS

Специализированные онлайн-сервисы. Иначе тебя может заблочить провайдер, оштрафовать и передать дело в суд.

Иначе тебя может заблочить провайдер, оштрафовать и передать дело в суд.

Это когда у нас провайдерам делегировали право штрафовать и передавать дела в суд?

https://habrahabr.ru/post/228499/

Провайдеры просто на вас нажалуются чтобы вы им канал не забивали. А вас увезут в домик

А, ну это таки две большие разницы :3

Я уж было заволновался просто.

ZTE MF626

Спасибо за идею! Но мне хотелось бы мониторить даже при условии пропадания связи с междусетью. :-)

По хабрассылке в частности сказано:

Рассылка по сети подвижной радиотелефонной связи (далее также – рассылка) должна осуществляться при условии получения предварительного согласия абонента, выраженного посредством совершения им действий, однозначно идентифицирующих этого абонента и позволяющих достоверно установить его волеизъявление на получение рассылки.

Все админы, которым надо, согласны получать SMS-трафик, а те, которые были в своё время несогласны, вычеркнуты из рассылки. Так что где здесь нарушение?

А как он видится: как /dev/ttyUSB* или как сетевуха? От этого зависит, каким способам отправлять SMS-ки. У меня есть билайновский ZTE MF823D, видится как сетевуха, на хабре была статья, как telnet-ом отправлять SMS. Но мне предпочтительней gammu*.

В последнее время задолбал тем, что меняет имя устройства
и прекращает, то снова начинает рассылать SMS-ки.

В смысле меняет ? У меня E169, вроде работает. Единственное - это надо организовывать очередь тем или иным способом и контролировать успешность отправки.

/dev/ttyUSB

либо проблема преувеличена, либо проблема с питанием по usb.

Несколько лет использую связку nagios+gammu-smsd.

gammu-smsd запускается скриптом в цикле.

        while [ -f $RUNFLAG ] ; do
          echo "`date \"+%Y%m%d %H:%M:%S\"` SMSD start" >>/var/log/smsd_output.log
          if ! gammu identify | grep -q E173 ; then
                  echo "`date \"+%Y%m%d %H:%M:%S\"` Modem not found. Reset." >>/var/log/smsd_outpu
                  usb_modeswitch -R -v 0x12d1 -p 0x1001
                  echo "12d1 1001" > /sys/bus/usb-serial/drivers/option1/new_id
                  sleep 5
                  if ! gammu identify | grep -q E173 ; then
                          logger -p daemon.err "Modem FAILED"
                          exit 1
                  fi
          fi
          [ -f $RUNFLAG ] || exit 0
          gammu-smsd -c /etc/gammu-smsdrc -p /var/run/gammu-smsd.pid -l -f 1
          echo "`date \"+%Y%m%d %H:%M:%S\"` SMSD exit" >>/var/log/smsd_output.log
        done

Можно взять копеечный sim800l и копеечный переходник usb-uart. В итоге получится такое же USB устройство, управляемое теми же at-командами, но на порядки более стабильное (модули sim800 ставят во всякие сигнализации, где они работают месяцами, если не годами, переходник же usb-uart вообще выполнен на жесткой логике и если взять какой нибудь хороший типа ft232, то вещь безотказная). 3G-модемы операторов же изготавливаются исходя из домашнего использования, когда их никто не гоняет 24/7, а в случае чего не проблема переткнуть.

Только если получатель не давал согласия получать СМС. Если давал, то с точки зрения закона все чисто. И это правильно. Бывает удобно получать по СМС всякие уведомления.

Ну и у той же ft232 можно прошить официальной программой серийный номер и простейшим правилом udev гарантировать, что порт имеет правильное имя.

Плата за все это - необходимость соединить 4 проводами две китайских платки.

У меня именно Мегафон E173. Рассылаю SMS с помощью утилиты, идущей в комплекте.

Ну и у той же ft232 можно прошить официальной программой серийный номер

Внутри микрухи прямо ?

У FTDI есть EEPROM, в который можно писать значения с помощью официальных утилит. Там хранятся помимо прочих настроек VID, PID и серийный номер USB-устройства. VID/PID менять не очень удобно, потому что тогда драйвер не увидит устройство. А вот серийный номер - самое то.

Спасибо за домашнее задание! Заказал две платки для того, чтобы навелосипедить супер-пупер надежный промышленный USB-модем. Посмотрим, что из этого выйдет. :-)

На самом деле программа должна уметь определять зависание модема и проводить его рестарт в случае необходимости.

И в случае gammu видимо д.б. какой-то лог.

Отвал модема - это зависание и отвал устройства на шине USB, так что ни копеечный переходник, ни sim800 скорее всего не помогут.

А еще СМС могут забивать внутренюю память симкарты.

А еще связь с базовой станцией может теряться.

Лучше gsm шлюз openvox взять.

Я забыл тебе кое-что сказать очень важное. Скорее всего тебе ещё нужно приобрести понижающий DC-DC преобразователь (подойдёт самый дешёвый рублей за 30-40, крохотная платка). Потому что USB выдаёт 5В, а у SIM800L максимальное напряжение питания 4.4В. Нужно его немного понизить. Чисто технически ничего сложного - у переходника на UART должны быть пара контактов - GND и 5В. Вот эти контакты надо пропустить через DC-DC преобразователь (у него есть пара входных контактов и пара выходных) и всё.

Больше из аппаратной начинки ничего не потребуется, теперь уже ничего не забыл (разве что тебе мало СМС и ты захочешь ещё голоса, но это совсем другая тема). Если возникнут какие-то вопросы, то обязательно отвечу.

Отвал модема - это зависание и отвал устройства на шине USB, так что ни копеечный переходник, ни sim800 скорее всего не помогут.

Внутри 3G-модема от оператора находится микроконтроллер или даже целый SoC (возможно, даже с Linux'ом на борту), который помимо прочего реализует стек USB и представляется соответствующим девайсом. Так вот, прошивки этих модемов обычно глючные и при длительной работе рано или поздно могут подвиснуть. Соответственно, устройство перестаёт отвечать на USB-запросы. Но всем на это плевать, потому что 99% пользователей не использует модемы 24/7.

Переходник USB-UART это гораздо более примитивное устройство. Зачастую там даже прошивки нет, а жёсткая логика. К тому же ЦА совсем другая - использовать подобный переходник 24/7 вполне вероятный сценарий использования.

Модуль SIM800, безусловно, имеет свою прошивку. Но она таки менее глючная, чем у 3G-модемов. Во всяком случае за это говорит тот факт, что в сети полно отзывов людей, у которых зависают 3G модемы просто от долгой работы, а про SIM800 подобной информации нет. Да, могут быть баги в прошивке, но точно не такие, что модуль превращается в тыкву тупо от нескольких дней работы. Помимо опять же другой ЦА (производитель знает, что его GSM-модуль часто будут пихать в девайсы, которые долго работают) сказывается ещё и меньшее количество функций (нет 3G и 4G). Опять же SIM800 вполне успешно применяется во всяких сигнализациях и т. п., где важна отказоустойчивость. А 3G-модемы используются в ответственных местах только с костылями типа релюшки для переключения питания USB.

В общем, мой вариант не будет глючить по двум причинам:

1) Он примитивнее. А чем проще конструкция, тем меньше точек отказа.

2) Каждый компонент заточен производителем под работу 24/7, ЦА производителей включает всякие автономные девайсы, а не простых домашних пользователей.

Используй онлайн сервисы. Если проблема с специализированными, можешь написать веб-скрабера для публичного мегафоновского (если есть).

Я для двух своих грёбанных монополистов как-то написал, может пригодится стянуть идейку, или хз чего. В профиле ссылка на гитхаб.

у меня есть sim800 правда на обычном uart, и он иногда виснет) Про зависание симкомовских модемов можно почитать на электрониксе.

Обычно зависание модема лечится отключением питания. Не кнопки PWR_KEY. А именно питания. У тебя такое предусмотрено?

А 3G-модемы используются в ответственных местах только с костылями типа релюшки для переключения питания USB.

Да, да. Там реле тоже для этого.

Еще раз. USB не предназначена для 24/7. Устройства на USB со временем отваливаются.

Данная проблема лечится снятием питания с порта USB хаба. USB хаб твоего устройства позволяет управлять питанием?

Модуль SIM800...

Все это домыслы. Прошивок под симкомовские модемы море: баги закрываются - баги открываются. Сигнализации и тревожные кнопки не рассылают массово SMS.

В общем, мой вариант не будет глючить по двум причинам

это же волюнтаризм?

1) Он примитивнее. А чем проще конструкция, тем меньше точек отказа.
2) Каждый компонент заточен производителем под работу 24/7,

ни один производитель не может предусмотреть условий эксплуатации и режима работы в конечном изделии. Так что обломайся)

ЦА производителей включает всякие автономные девайсы, а не простых домашних пользователей.

Охренеть. У некоторых производителей есть ЦА «для всякого неотказоустойчивого домашнего дерьма»? Вообще как бы у всех РЭК есть комерческое, индустриальное и тп исполнение. Эти не исключение.

https://cdn-shop.adafruit.com/datasheets/sim800h_hardware_design_v1.00.pdf

если прочитать мануал от производителя - можно узнать много нового, например что требуется согласовывать уровни управляющих сигналов, pp 31-33

В смысле было /dev/ttyUSB0 стало /dev/ttyUSB1 или /dev/ttyUSB2, или /dev/ttyUSB3. Потому как перестает со старым именем работать, но меняешь конфиг, и с новым ок отправляет.

Ага, спасиб за добавление. Буду учитывать. Конечно, надо преобразователь поставить, т.к. обычная пара резистор-стабилитрон явно не справится из-за большого тока, необходимого для питания передатчика.

В смысле было /dev/ttyUSB0 стало /dev/ttyUSB1

Понятно. Тогда можно для udev сделать правило, формирующее симлинк на событие. Имя придумать какое-нибудь а-ля /dev/ttySMS0 и его использовать: SUBSYSTEM=="tty", KERNEL=="ttyUSB*", <бла-бла ещё условия>, ACTION=="add", SYMLINK+="ttySMS0". «ещё условия» необходимы, так как ttyUSBn создаётся три штуки обычно. Кстати, может потребоваться фиксированное имя более, чем для одного ttyUSB - это уже от используемого ПО зависит.

Ну с сигналами 3.3В модуль отлично работает. А 3.3В уровни любой нормальный переходник usb-uart выдавать умеет. Там обычно джампер или микропепеключатель для выбора между 5 и 3.3.

Линейный регулятор справится, но тут другая проблема. Ток от USB ограничен и терять мощность на таком не стоит.

ну, так понимаю, рекомендации разработчиков модуля не пронимают, <ирония>чего они там знают-то о разрабатываемом ими модуле эти разработчики... </ирония>

на картинке 20 в документе http://simcom.ee/documents/SIM800/SIM800_Hardware Design_V1.08.pdf модуль развязан от 3,3В интерфейса резисторами. При чем входное сигналы подаются на модуль через токоограничивающие резисторы. А выходные - через делитель и также с ограничением по току.

про питание тоже интересно - пиковый ток применяемых стабилизаторов - до 3А с серьезной емкостью по входу и увеличенной индуктивностью для DCDC. В документе черным по белому пишут про 2A peak current in burst mode of the module

как такое подключать к питанию usb порта пк: т.е. из 2,5..4,5 Вт в случае чего получить 8,5Вт - непонятно.

проще уж тогда вместо модема взять обычный сотовый телефон с возможностью работать через Data кабель - в нем хотя бы аккумулятор есть. Siemens С35 в свое время неплохие были) Ну или модемы Siemens TС35

Или купить нормальный индустриальный модем для M2M, а вместо usb - pci контроллер 2xRS232 или MB c интегрированным RS232 портом.

Или еще есть тема - перевести usb модем на прошивку hilink и отправлять sms через api веб-интерфейса. Правда это не гарантирует, что модем перестанет отваливаться.

Насколько понимаю, сейчас модем теряет связь с базовой станцией или что. Далее gammu посылает ему команду сброса, после которого udev заново присвает ему имя. И так до бесконечности.

Т.е. начинать нужно с логов работы, а не с паяния на коленке собственного мега-модема.

Ну я опираюсь на реальный опыт использования данных модулей в своих проектах. Без 2А питания он вполне обходится, хватает большого электролита, который уже стоит на плате. В любом случае даже если оно изредка будет терять сеть это лучше необратимо зависания 3G модема. На практике оно даже сеть не теряет. А вот например если запитать от лабораторного БП (который точно тянет 2а) и выставить напряжение около 3.6в (вполне допустимое по даташиту), то модуль может написать low voltage и отрубиться. Но я и посоветовал ТСу подавать максимум - 4.4В.

Тоже приходится заниматься с симкомовскими модулями с тех пор как они еще sim300 выпускали. При чем в серийной продукции.

если запитать от лабораторного БП (который точно тянет 2а) и выставить напряжение около 3.6в

непонятно, к чему этот эксперимент. Напряжение скорее всего меряется на выходе БП, интегрально.На модуле в случае резкого потребления им мощности, напряжение может упасть ниже 3.6В. Т.е. нужно мерять стрелочным вольтметром и на модуле, чтобы скачок этот увидеть.

Модуль 2 А в пике потребляет. Лабораторный источник как и любой другой может просто не успеть в пике отдать столько энергии. Поэтому в референсе предлагают запасать энергию в накопительном конденсаторе, а в случае DCDC также увеличивать накопительную индуктивность (33->100 uH)

Но я и посоветовал ТСу подавать максимум - 4.4В.

Дело не в напряжении, а в максимальной мощности, который может отдать порт USB. Для 2.0 - это 5В*0,5A=2,5Вт. Для 3.0 - 4.5Вт. Т.е. в случае 4.4В максимум, что можно получить с DCDC это 2.5/4.4*КПД < 0,55 А, с линейного - не более 0,5А. Какую-то часть энергии при пике нагрузки конечно может отдать конденсатор, но в общем случае питать такой модем от USB порта нельзя. Нужен внешний источник с запасом до 3А, причем с достаточно быстрым стабилизатором.

Ну вы поняли, есть такие USB-аккумуляторы, иной вопрос, будут ли они заряжаться от 2.0 ?

Здравствуйте, скажите пожалуйста какая аппаратная начинка потребуется для передачи голоса?

UP! В связи с продолжающимся ухудшением качества отправки сообщений в системе, продолжаю наблюдение, переведя модем в режим «только модем», начал играться с разными комбинациями дистров и виртуалок (дебиан 9, убунту 18.04), но всё стало резко лучше, когда поднял виртуалку с FreeBSD 11.2-RELEASE-p4 AMD64 и пробросил туда девайс. Причем видно, что до начала отправки gammu долго ждет чего-то и не сразу начинает отправлять, но потом все же отправляет; причем я заметил, что во фре не было ни одного случая неудачной отправки, хотя ради справедливости стоит отметить, что фря геометрически в другом месте, нежели производственный тазик. Во фрёвой сборке указаны какие-то хитрые длинные таймауты, которых нет в линуховой? Навскидку, не нашел где поуказывать таймауты модема в /etc/gammurc. Посещают мысли пересобрать пакетик gammu, переконфигурировав таймауты.

Лог на центоси:

Mon 2018/11/12 18:03:12: [Gammu            - 1.39.0]
Mon 2018/11/12 18:03:12: [Connection       - "at19200"]
Mon 2018/11/12 18:03:12: [Connection index - 0]
Mon 2018/11/12 18:03:12: [Model type       - ""]
Mon 2018/11/12 18:03:12: [Device           - "/dev/ttyMODEM"]
Mon 2018/11/12 18:03:12: [Running on       - Linux, kernel 3.10.0-862.14.4.el7.x86_64 (#1 SMP Wed Sep 26 15:12:11 UTC 2018)]
Mon 2018/11/12 18:03:12: Locking device
Mon 2018/11/12 18:03:12: Serial device: DTR is up, RTS is up, CAR is down, CTS is down
Mon 2018/11/12 18:03:12: Setting speed to 19200
Mon 2018/11/12 18:03:12: [Module           - "auto"]
Mon 2018/11/12 18:03:12: Escaping SMS mode
Mon 2018/11/12 18:03:12: SENDING frame type 0x00/length 0x02/2
Mon 2018/11/12 18:03:12: 1B |0D                                                          ..              
Mon 2018/11/12 18:03:12: Sending simple AT command to wake up some devices
Mon 2018/11/12 18:03:12: SENDING frame type 0x00/length 0x03/3
Mon 2018/11/12 18:03:12: 41A|54T|0D                                                      AT.             
Mon 2018/11/12 18:03:33: Enabling echo
Mon 2018/11/12 18:03:33: SENDING frame type 0x00/length 0x05/5
Mon 2018/11/12 18:03:33: 41A|54T|45E|311|0D                                              ATE1.           
Mon 2018/11/12 18:03:43: Phone does not support enabled echo, it can not work with Gammu!
Mon 2018/11/12 18:03:43: It might be caused by other program using the modem.
Mon 2018/11/12 18:03:43: See <https://wammu.eu/docs/manual/faq/general.html#echo> for help.
Mon 2018/11/12 18:03:43: Init:GSM_TryGetModel failed with error TIMEOUT[14]: Превышен тайм-аут ожидания ответа. Возможно, телефон не подключён.
Mon 2018/11/12 18:03:43: [Terminating]
Mon 2018/11/12 18:03:43: [Closing]

Лог на фре:

Mon 2018/11/12 18:05:00: [Gammu            - 1.39.0]
Mon 2018/11/12 18:05:00: [Connection       - "at19200"]
Mon 2018/11/12 18:05:00: [Connection index - 0]
Mon 2018/11/12 18:05:00: [Model type       - ""]
Mon 2018/11/12 18:05:00: [Device           - "/dev/ttyU0.0"]
Mon 2018/11/12 18:05:00: [Running on       - FreeBSD, kernel 11.2-RELEASE-p4 (FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 UTC 2018     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC)]
Mon 2018/11/12 18:05:00: Locking device
Mon 2018/11/12 18:05:00: Serial device: DTR is up, RTS is up, CAR is down, CTS is down
Mon 2018/11/12 18:05:00: Setting speed to 19200
Mon 2018/11/12 18:05:00: [Module           - "auto"]
Mon 2018/11/12 18:05:00: Escaping SMS mode
Mon 2018/11/12 18:05:00: SENDING frame type 0x00/length 0x02/2
Mon 2018/11/12 18:05:00: 1B |0D                                                          ..              
Mon 2018/11/12 18:05:00: Sending simple AT command to wake up some devices
Mon 2018/11/12 18:05:00: SENDING frame type 0x00/length 0x03/3
Mon 2018/11/12 18:05:00: 41A|54T|0D                                                      AT.             
Mon 2018/11/12 18:05:01: 1 "T"
Mon 2018/11/12 18:05:01: 2 "OK"
Mon 2018/11/12 18:05:01: Checking line: OK
Mon 2018/11/12 18:05:01: AT reply state: 1
Mon 2018/11/12 18:05:01: RECEIVED frame type 0x00/length 0x08/8
Mon 2018/11/12 18:05:01: 54T|0D |0D |0A |4FO|4BK|0D |0A                                  T...OK..        
Mon 2018/11/12 18:05:01: 
Mon 2018/11/12 18:05:01: UNKNOWN frame. Please report the error, see <https://wammu.eu/support/bugs/>. Thank you
Mon 2018/11/12 18:05:01: LAST SENT frame type 0x00/length 3
Mon 2018/11/12 18:05:01: 41A|54T|0D                                                      AT.             
Mon 2018/11/12 18:05:01: RECEIVED frame type 0x00/length 0x8/8
Mon 2018/11/12 18:05:01: 54T|0D |0D |0A |4FO|4BK|0D |0A                                  T...OK..        
Mon 2018/11/12 18:05:01: 
Mon 2018/11/12 18:05:20: Enabling echo
Mon 2018/11/12 18:05:20: SENDING frame type 0x00/length 0x05/5
Mon 2018/11/12 18:05:20: 41A|54T|45E|311|0D                                              ATE1.           
Mon 2018/11/12 18:05:20: 1 "ATE1"
Mon 2018/11/12 18:05:20: 2 "OK"
Mon 2018/11/12 18:05:20: Checking line: OK
Mon 2018/11/12 18:05:20: AT reply state: 1
Mon 2018/11/12 18:05:20: RECEIVED frame type 0x00/length 0x0B/11
Mon 2018/11/12 18:05:20: 41A|54T|45E|311|0D |0D |0A |4FO|4BK|0D |0A                      ATE1...OK..     
[--------пропущен-большой-кусок-лога-------------------]   
Mon 2018/11/12 18:05:26: SMS sent OK
Mon 2018/11/12 18:05:26: Parsing +CMGS: 185 with +CMGS: @i
Mon 2018/11/12 18:05:26: Parsed int 185
Mon 2018/11/12 18:05:26: Sent SMS on device: "/dev/ttyU0.0"
Mon 2018/11/12 18:05:26: [Terminating]
Mon 2018/11/12 18:05:26: [Closing]

С разными экземплярами модемов, но они одной модели. На фре до этого работал ОК тот экземпляр модема, который сейчас на центоси пытаюсь завести.

Кажется, научился использовать именно нулевой COM-порт модема. Делается это так:

$ cat /etc/udev/rules.d/99-modem.rules
ACTION=="remove", GOTO="modem_end"

SUBSYSTEM=="tty", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1001", ENV{ID_USB_INTERFACE_NUM}=="00", SYMLINK+="ttyMODEM", GROUP="dialout", MODE="0660"

LABEL="modem_end"

где «00» — нулевой порт, для первого будет «01», для второго — «02».

/тред

Можно еще рестартовать службу gammu-smsd по событию от модема.

В общем, я нашел в продаже новый небрендованный HUAWEI E303, и переключил его с помощью at команды перманентно из NDIS или как его там, в компорты. Похоже, это совсем всё. Гы гы.