Однажды, в студеную зимнюю пору... Нет, не так.

Давным-давно, в далекой галактике... Черт, опять не то.

Наверное правильней начать с того, что я прочитал на Хабре статью "Как я через ioBroker шлагбаумы в поле шатал" и ажно заколдобился. К этому моменту у меня уже скопилось пяток брелков для управления воротами, ну и был какой-никакой опыт работы с IOBroker. Конечно, я примерно повторил концепт автора - подкинул ко всем воротам такие же двухканальные реле, завел в IOBroker видеопотоки с ближайших камер, наклепал объектов-пользователей, объектов-команд, слепил инлайн-меню, скрипты для соединения всего этого в одно, раздал доступ к боту пользователям и начал радоваться. Все ворота работали отлично, видосики радовали глаз, журнал посещений строился, ну и так далее. Пара ренегатов, пользующихся кнопочным телефоном, обошлись все тем же ворохом брелков, но это уже была не моя проблема.

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

Не, я конечно понимаю, что можно было обучить под сотню людей пользоваться проксями, впн, корпоративными средствами обхода, и так далее, но я подумал что я не хочу сажаться на техподдержку борьбы с запретом ТГ, и решил решить проблему радикально.

Не, понятно что в пределе заблокировать могут и радиочастоты 433/867 МГц, и тогда - только физические ключи, могут выключить электричество и тогда только ручной привод, но хочется же верить в хорошее и я решил остановиться на том, что как мне кажется, заблокируют в последнюю очередь - на сотовой связи.

К этому моменту на нескольких воротах уже стояли модули какого-то прибалтийского производителя, установленные инсталляторами ворот, но они были уж слишком просты - принимали звонок, сбрасывали его, и в зависимости от совпадения номера звонящего с базой в памяти приборчика, открывали или не открывали ворота. Как и у многих других подобных поделий, все администрирование - через СМС или облачную админку (по 2G, Карл!!!!111), к тому моменту уже недоступную. Я купил еще несколько разных реле, позиционирующихся как управляющие воротами, и везде встречал то же самое - ужос с админкой, ограниченность логов, ограниченность коммуникаций.

Формулируем концепцию

Итак, что же наша душенька возжелала? А возжелала она следующего:

1. Принимать входящий сигнал с мобильного

2. Различать от кого пришел сигнал

3. Отдавать в удобоваримом виде

4. 24/7, не зависить ни от чего.

5. Не требовать ощутимых денег

6. Не требовать текущей настройки, поддержки и администрирования

Конечно первой идеей было пустить все через рабочий астериск, и мне даже удалось заставить его работать. Но детекция входящих работала, как ни странно, не очень стабильно - то ли с настройками админы что-то недосмотрели, то ли провайдер не всегда отдавал. Поскольку астериск не моя зона ответственности, да и вообще экспериментировать на рабочем инструменте с десятками линий и федеральным номером не хотелось - отказался от дальнейшего рассмотрения этого варианта. В этот момент добавился пункт "автономность, отсутствие привязки к инфраструктуре"

Дальше рассмотрел банальный gsm-модем, и тут внутренняя жаба начала нашептывать что на каждые ворота по модему - это еще ничего, а вот платить за 5 (для старта, дальше возможен рост) симок я не хочу, не хочу отслеживать здоровье модемов, в случае их выхода из строя искать ту же модель, и так далее. И вообще, мало ли чем я еще захочу управлять. И добавилось требование "принимать неограниченное количество команд и различать их", и тут я познал DTMF.

Тональный набор, тональный сигнал (англ. Dual-Tone Multi-Frequency, DTMF) — двухтональный многочастотный аналоговый сигнал, используемый для набора телефонного номера. Сфера применения тональных сигналов: автоматическая телефонная сигнализация между устройствами. (с) Вики

Вкратце, это та самая штука, которая противно пищит когда кнопку ухом нажимаешь. Или которую распознает рободевица в недрах АТС, требующая для связи с техподдержкой нажать "9". Работает на чем угодно, включая кнопочные телефоны, как при наборе (просто ждем ответа и продолжаем набирать цифры), так и при сохранении контакта (долгое нажатие * на айфонах, через выпадающее меню на андроидах, через долгое/мноократное нажатие звездочки или решетки на кнопочных, пока не появится на экране "," или "P").

Я поискал модемы с поддержкой DTMF и нашел их. Только как-то они под линуксом у меня не завелись, а держать включенную вин-машину для этой цели мне показалось расточительным.

Тогда я решил сделать модем сам, с шахматами и поэтессами. Почти standalone, на проводах, отдающий входящие сигналы в MQTT, а дальше уже IOBrokerом разрулю. К этому моменту я уже активно переводил всё, что попадается под руку, на модули WT32-ETH, наклепал с помощью ИИ боль-мень универсальную модульную прошивку с поддержкой сети, веб-сервера и MQTT, поэтому задача не показалась мне сложной.

И понеслось железо

Модулей WT32-ETH у меня валяется пачечка - как я уже сказал, я их нынче вместо ардуинки использую, если нет вопросов про автономность. Дешево, универсально, уже есть пул на подмену, небогатого набора лап хватает на бОльшую часть задач.

Модуль модема на SIM900 у меня тоже валялся. Но дохлый. Покопав окружающие магазины и всякие маркетплейсы, я понял что SIM800 - мой выбор. Купил сразу парочку, потому что как я понял, часто это модемы б/у, и качество может плавать.

Подсистема питания меня несколько тревожила. По всем отзывам модем жрет до 2А на старте, что приводит к нестабильной работе устройства в целом, если не заложиться на питание. Да еще и разночтения про напряжение - в разных статьях пишут что у кого-то завелся только от 5В (при 3.7-4.2 паспортном), кто-то пишет что ровно 4 и не десяточку вверх-вниз. В первой версии я использовал большой bulk преобразователь, но в какой-то момент придумал - выкинул его к такой матери и вместо него поставил Li-Ion аккумулятор 14500 и модуль powerbank на TP4056 - это дает модему и родное для него напряжение 4,2В, и возможность жрать от души в пределах 10А, ну и обеспечивает микро-UPS, спасающий от кратковременных пропададний электричества. Аккум - отходивший свой регламентный срок в каком-то станке, но в данном случае мне безразлична его ёмкость, по факту - это не аккум, а конденсатор-переросток.

В общем, на этом железо и завершилось. Еще две кнопки воткнул позже - одну в разрыв батарейки, чтобы можно было ресетнуть модуль по питанию не отпаивая батарею, вторую - когда у меня не завелась от TP4056 ESPха при отключенном питании, оказалось что TP надо бустнуть, если хочешь получить 5В, а потребления нет.

Паяем

Принципиальная схема примерно такая (прошу не пинать, вот вообще не шарю как это правильно рисовать, по наитию в EASYEDA мышкой водил)

Макетка в руки и вперед. Получилось страшное, но добродушное:

Да, я знаю что ЛУТа бояться - вообще ничего не делать, и я его не то чтобы боюсь, но прототипирую таки на макетках. В лучших национальных традициях рабочий прототип становится постоянным изделием - в данном виде устройство работает уже полгода, а желание сделать-заказать-запаять нормальную плату постоянно ускользает за прочими задачами и прокрастинацией.

Я мог бы накидать еще кучу самого разного интересного - все промежуточные этапы, мои танцы с strapped-pin и так далее, но не вижу смысла. Данная конкретная схема опробована и работает, переработка - на страх и риск, только если понимаете что делаете.

Прошивка

Как я уже говорил, у меня есть самописная модульная прошивка для ESP32 поделок в platformio. Базовые модули - web для сервера, network для сети - обеспечивают вебморду, wifi client, wifi STA, OTA, остальное подключается по требованию. В данном случае требовалось добавить уже существующий MQTT модуль и дописать взаимодействие с модемом и морду для него.

Взаимодействие с модемом писал по очень подробной статье, огромное спасибо автору Кравченко Виктору. Единственное, с чем пришлось повозиться - с блокирующими состояниями. В результате вся логика - это набор состояний и таймеров, которые крутятся в общем loop(): инициализация модема, ожидание звонка, разбор DTMF, опрос статуса сети, всё живёт параллельно, никто никого не ждёт.

Логика собственно шлюза простая: модем живет и изредка подергивается опросом служебных AT-команд, результаты опроса публикуются в MQTT и отдаются в веб. Если прилетает RING, вытаскиваем номер звонящего из CLIP, поднимаем трубку, глушим микрофон (чтобы в трубку не летел писк самого модема), и начинаем слушать тональные сигналы. Каждая цифра DTMF копится в буфер, по таймеру кладем трубку где взяли. После этого весь буфер улетает в MQTT одним сообщением — а что с этим делать, разруливает уже основная автоматизация, прошивка сама никаких решений не принимает.

В процессе отладки прикрутил терминал прямо в веб-морду, чтобы отправлять и принимать AT-команды без UART переходников. Но надо сказать, что после первой отладки не пользовался, просто не было необходимости.

Длинный скриншот вебморды модема

Отдельно потанцевал с вотчдогом - иногда модем зависает намертво, поэтому при неответе на служебные AT-команды, ESP 10 раз пинает больного, а потом дёргает ресет.

Вкратце перечислю встретившиеся по дороге грабли:

1. Изначально я подцепил модем на IO14 и у меня WT32 отказалась стартовать когда модем запитан. Оказалось что это strapping-pin, который при старте смотрит состояние и выбирает режим загрузки. Естественно, модем шлет туда данные, и WT32 приходит в полное недоумение и вываливается в циклический ребут.

2. Детектор DTMF в SIM800 включается командой AT+DDET. В доках часто фигурирует AT+DDET=1, но на моей прошивке модема эта форма стабильно возвращает ERROR. Рабочий вариант оказался таким: AT+DDET=1,0,0 . Судя по всему, конкретная ревизия прошивки модема требует явного указания всех трёх параметров (включение, порог, режим), хотя по спецификации последние два опциональны. Пять минут разглядывания даташита сэкономили бы вечер, но и вечер - не худшая цена за рабочий DTMF.

3. Пока не включил задержку 500мс перед AT+CMUT=1, команда не успевала отрабатывать и в линию неслись наводки от платы. Оч мерзко, особенно по громкой связи в машине. Конечно правильно бы что-нибудь подключить к входу микрофона модема, но я еще тот схемотехник, поэтому решил проблему программно.

Ну и что с этим делать?

А дальше - у каждого свой вкус, свои предпочтения. Шлюз отдает в MQTT желаемое - номер телефона звонящего и DTMF-команду. Лично у меня все это принимает IOBroker, DTMF-команда из 5 цифр (может прикручу checksum когда-нибудь), дальше скрипт сверяет наличие в объектах пользователя с таким номером и разрешение у этого пользование на использование команды, пишет в лог, и собственно исполняет команду. Понятно, что гибкость не как у текстового чата ТГ или другого мессенджера, но зато надежность - на высоте.

Перспективы

Честно говоря, мне эта штука понравилась. Причем на концептуальном уровне - я реально не встречал такого в продаже, хотя мне кажется что потребность у народа есть. Есть несколько перспективных направлений для продолжения разработки, например использование GPRS для администрирования, отправка SMS или звонки по сигналу от MQTT, но делать это для себя откровенно лень. Если у кого есть идеи коллаборации для себя или для возможной коммерционализации проекта - велкам в обсуждения, мне кажется железка этого достойна.

PS

В принципе могу описать скрипты IOBroker и PWA для мониторинга и администрирования (оно же альтернативная управлялка), еслси интересно - пишите, опубликую.