Телеграм-бот для беспокойных родителей

Здравствуйте. Не знаю, приветствуется ли здесь упоминание о первом посте, поэтому его здесь не будет, так как это мой первый пост, и не хотелось бы сразу фокусировать на себе неприязнь аудитории.

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

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

Где-то в 2017-18 годах в районные школы пришло распоряжение об обязательной установке турникетов на входе (вследствие терактов в СПб), выделены средства из бюджета, даны соответствующие сроки. Турникет установили, СКУД подключили, настроили, выдали шесть сотен карт для выдачи ученикам и сотрудникам. Карты Mifare с уникальным идентификатором, каждый из которых должен быть вручную внесён в БД СКУД перед использованием. На время тестирования всей этой великолепнейшей системы карточки было решено выдать только сотрудникам, за исключением пары уборщиц, электрика и сторожей за ненадобностью. Ну и не было бы этого поста, если бы я напрямую этим не занимался, ибо в то время был вхож в школу от нечего делать.

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

— так в голову пришла идея создать систему, которая будет оповещать родителей о приходах их детей в школу, а по факту — о проходах через турникет с помощью карты ребёнка (да, одно из слабых мест любой СКУД или первый звоночек).

Данные локальный сервер будет отправлять на указанный адрес — мой скрипт, написанный на PHP в связке с MySQL, стандартный набор. Сервер установленного турникета, с которым я работал, устроен таким образом, что любой поворот ступицы создаёт запись в логе проходов, который немедленно отправляется на локальный сервер (а оттуда уже на внешний URL-адрес). Весь лог. Я приложил карточку и прокрутил ступицу.

Поймав отправленные турникетом данные я ужаснулся: там был целый лог с сотнями записей о проходах за все дни с момента установки турникета. «Неужели мне каждый раз придётся это обрабатывать?» — подумал я и прокрутил ступицу второй раз. Пришёл тот же лог, но вдобавок ещё, как нетрудно догадаться, там была и новая запись. «Ну ладно, раз есть идея, значит должна быть реализация», — решил я и начал оформлять БД и запись всех новых проходов в неё через скрипт, чтобы была история проходов, ибо это односторонняя связь, получить лог по запросу от локального сервера всё равно нельзя. Конечно, очень неприятно было бы день за днём получать мегабайты лишних данных каждую секунду (а лог почему-то приходил каждые несколько секунд, даже если не было проходов) и забивать память сервера. По мере реализации сохранения входящих логов было принято решение не записывать в логи проход по кнопке, потому что это бесполезно, ведь сервис должен знать только о тех проходах, которые необходимо доставить родителям. Ну или о тех, которые в принципе можно куда-то доставить с пометкой «такой-то пришёл/ушёл». То есть оставляем только те записи, которые содержат номер карты — это говорит о том, что проход инициирован не по кнопке.

Отлично. Мы имеем скрипт, который сохраняет все проходы по картам. Представим, что прошла парочка лет, и скрипт уже со скрипом обрабатывает входящие мегабайтные логи, если они вообще смогут приходить в таком объёме. Помимо всего этого логи дублировались. То есть после того, как был обработан очередной лог, он снова приходил в течение минуты. Так дело не пойдёт. Пишу в техподдержку, мол, «как так, неужели нельзя отправлять только последние записи и только один раз?», в ответ на что я получаю документацию, в которой говорится о необходимости ответа, чтобы турникет узнал, что данные приняты. «А наряду с остальными ненужными документациями на сайте почему нельзя было эту секретную разместить?» – подумал я и вернулся к работе уже с новыми сведениями.

Хорошо. Учим скрипт отвечать на принятые данные и снова пару раз проворачиваем ступицу – всё работает как требовалось: приходит только что созданная запись без остального лога. Прекрасно. Наводим красоту в коде, создаём проверку авторизации, таблицу карт, включающую в себя алиас карты и её номер, а также таблицу получателей карт (ID пользователей в Телеграме) и много ещё забытой магии, в числе которой структура папок на сервере, названия скриптов, связи в БД и т.д.

(Надеюсь, никому не интересен процесс программирования бота? Если вкратце — без фреймворков, всё с нуля и вручную)

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

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

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

На стадии тестирования турникета картами пользовались только сотрудники (я писал об этом ранее). Самое забавное, что из пары десятков сотрудников картами пользуются 3-4 человека, остальные «забыли дома», «открывайте, опаздываю на урок», «ой, доставать её ещё, она в сумке где-то, откройте так» (надеяться, после такого, что дети не будут терять карты, передавать другим и забывать дома – глупо или второй звоночек).

Для проверки работоспособности бота был установлен Телеграм на школьный мобильный телефон, и добавлены все розданные карты в аккаунт. Всё работало прекрасно. Периодически я и ещё один учитель получаем сообщения о проходах друг друга, чтобы быть в курсе, кто где находится — на улице или в помещении, ну и для тестирования нескольких получателей уведомлений от одной карты.

Какие проблемы могут быть при использовании бота?

• Использование персональных данных (всё же это школа, а защита данных детей – это важно; но отмечу, что карты можно называть как угодно, хотя в таком случае теряется смысл в уведомлениях, ибо родителям придётся ещё и шифр разгадывать: «Ученик №152» – это Маша, Петя или Ахмед? Подзабылось что-то…»).
• Огромный поток малышей с утра и после уроков. В таком случае на данный момент турникет отключается и дети просто-напросто заходят/выходят, и ни о каких картах не может идти речи (так было в моей школе).
  
• Подмена карт, потеря карт, отсутствие карт по забывчивости. Вася заходит за Стёпу, пока Стёпа прогуливает (ну тут классный руководитель должен следить); кто будет платить за потерянные карты, перерегистрировать новые, менять данные в случае смены владельцев и т.д.? Никто не отправит ребёнка домой за картой. За «сменкой» – ещё может быть, но за картой – да глупость какая-то.
• Идентификация карт. Как быстро определить, кто посеял найденную кем-то карту? Никак. Ну или по-костыльному, типа наклейки с именем, поиска в БД, опроса учащихся, ведения списков или при помощи ещё чего-нибудь интересного. Вздор.
  
• Временные выходы на улицу (физкультура, магазин, двор – у кого какая школа и какую свободу предоставляет) = лишние уведомления, и, как следствие, возможные ненужные переживания родителей. Хотя... кто будет брать карту на физкультуру?
• Нагрузки, которые не сможет выдержать сервер. Поскольку система не имела возможности протестироваться на большом потоке данных, то и проблем таких пока не возникало, но они точно будут, вопрос только в величине нагрузки. В этом пункте ещё и отсутствие ограничений на количество обращений к скрипту, да и Телеграм тормозит ботов, которые отсылают слишком много сообщений в минуту.

Проблем может быть много, но все вспомнить я не смогу, потому что они специфические и проявятся только при увеличении нагрузки.

В общем наборе с картами для прохода лежал брелок в качестве прототипа, который можно было заказать за немножко чутьбольшетысячи денег, на который, помимо самой школьной карты, можно было записать «Тройку» и «Стрелку». Нельзя просто так взять и не добавить уведомление о том, что ребёнок в автобусе. Дети ведь не всегда рядом со школой живут. Со «Стрелкой» можно работать, а вот у «Тройки» нет даже сайта для банальной проверки баланса, ибо всё находится на карте, кроме подвешенных зачислений (вероятно, какой-нибудь API есть, но не для публичного доступа). В общем, простого способа получить какие-то данные об этой карте невозможно.

При обращении к представителям «Стрелки» по вопросу доступа к API я получил отказ, мол, публичного API нет и вряд ли планируется. Как скажете. Но вы — не «Тройка», у вас сайт есть, а там есть возможность смотреть всё. Идея есть, реализация будет. Немножко изучения отправляемых запросов и получаемых данных на сайте, немножко программируемой магии и всё готово. Почти по той же схеме добавляем аккаунты стрелки, сохраняем пароли (чтобы скрипт мог авторизовываться), делаем кэширование запросов во избежание лишней нагрузки на сайт и т.д., и т.п. Актуальные поездки в этом случае теперь придётся доставать вручную. Конечно, это будет делать крон раз в минуту: заходит в каждый известный ему аккаунт, сохраняет данные о поездках по картам, затем рассылает всё получателям уведомлений. Помимо всего прочего была установлена актуальность данных в 10 минут для «Стрелки». Дело в том, что информация о поездках на сайте появляется не сразу, а в течение 15 минут. Самое минимальное, что мне удалось поймать — 1 минута, но всё зависит от терминала и серверов «Стрелки», и, чаще всего, в истории запись появляется, в среднем, через 4 минуты. Снова наводим красоту в оформлении бота, добавляем возможность просмотра поездок, пополнений и иной базовой информации о картах. Кроме того, для тех, кому незачем добавлять аккаунт в бота, в качестве вишенки на торте сделана функция проверки баланса по номеру карты.

• Была создана документация для регистрации предприятий, использующих СКУД, чтобы кто-то тоже имел возможность подключить свою систему к боту (всё бесплатно, мне просто хочется знать, что это может быть кому-то нужно), а если нет локального сервера – ещё и документация к осуществлению ручных запросов для отправки проходов.
• Добавление, редактирование и удаление карт производится путём загрузки xlsx файла в диалог с ботом.
  
• Конечно в каждом моём боте есть команда для полного удаления информации о себе из сервиса. Удаляются полностью все записи из БД, связанные с аккаунтом, а также все файлы, если они были созданы. Ни у одного бота я такого не встречал, но это необходимо. Очень часто приходится блокировать ботов из-за отсутствия в них возможности остановить рассылку.

Когда я поговорил с директором об этом боте, предвкушая огромный фидбек от его использования, тот сказал, что это всё замечательно и интересно. Но дальше произошёл такой диалог:

— Когда раздадут карты, чтобы родители могли отслеживать детей?

— Никогда. А зачем? Всё равно будут терять, толпиться, забывать…

Третий звоночек и занавес.

Сейчас бот используется мной для отслеживания баланса «Стрелок» и поездок членов семьи, а возможность регистрироваться закрыта. Нет, всё работает, просто закрыто за невостребованностью. Какая-то школа в какой-то далёкой области год пользовалась ботом (уведомления, правда, приходили на один аккаунт и только о проходах сотрудников (забавно)), а потом перестала, и данные так и лежат в базе мёртвым грузом.

А обещанная мораль… Не умеешь продавать – забудь об исключительности своих идей.