У нас на объекте была довольно приземлённая проблема: контроль посещений.

Гости пользовались инфраструктурой по RFID-браслетам, работала СКУД ZKTeco, но периодически появлялись «зайцы» — люди без действующего права доступа.

Сам по себе браслет не решает такую задачу. Его можно потерять, передать другому человеку или даже продать. А сотруднику на точке контроля нужно за несколько секунд понять, кто перед ним и действителен ли пропуск.

В итоге мы собрали собственную систему проверки. Но самое интересное — мы не стали вводить ещё один пропуск.

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

Мы считали UID существующих парковочных карт и добавили их в нашу систему. Получился удобный дополнительный способ идентификации: сотрудник проверяет карту, сопоставляет данные с гостем и получает актуальный статус.

Не нужно выпускать новый физический носитель или учить посетителей пользоваться ещё одним сервисом.

А что с гостевыми браслетами?

С ними другая логика.

Допустим, кто-то забрал чужой браслет, украл его или купил с рук. Пока мы ориентируемся только на наличие RFID-метки, это риск.

Поэтому для нас важен не просто UID, а актуальное право доступа. После выселения гостя его браслет становится неактивным. Физически он может остаться у кого угодно, но сам по себе уже ничего не даёт.

Таким образом, две уже существовавшие вещи решают разные задачи:

— Именная парковочная карта с фото помогает подтвердить, кто именно проходит проверку.

— Гостевой браслет проверяется на действительность с учётом статуса гостя, а не только по факту наличия метки.

Как это реализовали

Сделали Windows-клиент для USB RFID-считывателя и Android-клиент для мобильных проверок. Оба работают с одним серверным API.

RFID → Windows / Android → Django REST API → PostgreSQL / ZKTeco

Приложение считывает UID, сервер ищет идентификатор, проверяет связанные данные и возвращает результат. Проверки журналируются: время, устройство, UID и статус.

Бизнес-логику оставили на сервере. Поэтому при изменении правил не нужно обновлять их по отдельности на каждом рабочем месте.

С ZKTeco всё оказалось не так просто Казалось бы, готовая СКУД — значит, должен быть удобный API. Но в нашей версии ZKBio CVSecurity нужные данные через доступный API получить нормально не получилось.

При этом игнорировать ZKTeco мы не могли: часть браслетов могла отсутствовать в нашей PostgreSQL, но существовать в действующей СКУД. Решили сделать двухступенчатую проверку: сначала собственная база, при необходимости — ZKTeco.

Для второго этапа использовали Playwright. Автоматизировали взаимодействие с веб-интерфейсом ZKBio CVSecurity и спрятали эту интеграцию за своим backend. Для клиентов это всё тот же запрос к REST API.

Да, браузерная автоматизация хрупче полноценного API: при обновлении интерфейса её придётся проверять. Но это позволило использовать уже установленное ПО без замены всей системы контроля доступа.

Что получилось

У сотрудников появился понятный процесс: приложить карту или браслет и увидеть результат проверки. У нас — единые правила, централизованный учёт и история событий.

А главное, после внедрения проблема «зайцев» в нашей практике исчезла. Мне в этом проекте особенно нравится, что решение родилось не из покупки нового оборудования. Мы взяли уже существующие парковочные карты, учли жизненный цикл гостевых браслетов и связали всё с действующей СКУД, даже несмотря на ограничения её API.

Иногда самая полезная автоматизация начинается с вопроса: «А что у нас уже есть и как это можно использовать по-другому?»

А вам приходилось использовать Playwright как интеграционный слой для корпоративного ПО?