1. Головна
  2. Довідка
  3. Технічні дані контролера

Технічні дані контролера

Ця сторінка — для монтажника та інтегратора, а не для адміністратора залу. Вона відповідає на одне питання: чи заробить це з тим турнікетом і тим зчитувачем, які у вас уже стоять. Налаштування в інтерфейсі описані окремо — контролери і турнікет.

Контролер — власна плата, а не інтеграція зі стороннім СКД. Сімейство прошивки — snapswitch 3.x на ESP32 (ESP-IDF 5.4), те саме залізо, що працює в системах доступу N-GATE для житлових комплексів і паркінгів.

Ряд плат: MINI, STANDARD, PRO

Для залу різниця між ними зводиться до одного питання — чи потрібні картки.

  • MINI — одне реле, один вхід, зчитувача на платі немає. Підходить, якщо прохід тільки за QR із телефона: сканування перевіряє сервер, а плата лише відмикає. Для карток не годиться — прикладати нема до чого.
  • STANDARD — зчитувач на борту, більше реле й входів. Це мінімальна конфігурація, якщо в залі є картки або брелоки.
  • PRO — старша модель для СКД і паркінгів.

Точні електричні параметри — напруга живлення, номінали реле, клас корпусу — залежать від ревізії плати й підтверджуються під конкретне замовлення. Ми свідомо не публікуємо їх тут одним списком: плата у вашій шафі має відповідати паперу, а не навпаки.

Зчитувач: Wiegand-26

Зчитувач підключається по Wiegand на дві лінії даних, D0 і D1. Прийом побудований на перериваннях, окремий контролер зчитувача не потрібен.

Головне, що треба знати до закупівлі зчитувача:

  • приймається рівно 26 біт — класичний Wiegand-26 із перевіркою парності;
  • кадр іншої довжини відкидається, а буфер скидається. Тобто зчитувач у режимі Wiegand-34 працювати не буде — його треба перемкнути на 26 біт (більшість зчитувачів це вміють перемичкою або командою);
  • формат картки значення не має: плата віддає серверу числовий ідентифікатор, а вже сервер вирішує, чий це абонемент.

Сервер розрізняє чотири джерела ідентифікації: телефон (вхідний дзвінок на SIM плати), RFID-картка, BLE і розпізнаний автомобільний номер. У залі зазвичай працюють два перші плюс QR через кабінет клієнта.

Виконавчий механізм: реле і сухий контакт

Плата керує турнікетом, замком чи хвірткою через реле. Тому підходить будь-який механізм, який відмикається сухим контактом, — турнікет, електрозамок, електрозасувка, привід хвіртки.

У налаштуваннях точки проходу задаються номер реле, тривалість імпульсу і напрямок: вхід, вихід або обидва. Базове правило просте: валідний прохід замикає реле на задану тривалість.

Входи плати мають логічні ролі — зчитувач, кнопка виходу, датчик присутності або петля. Саме роль, а не номер клеми, каже прошивці, як поводитися з тим, що приєднано.

Мережа і MQTT

Звʼязок із сервером — MQTT 5.0 з Topic Alias. Topic Alias тут не прикраса: на мобільному каналі повні імена топіків у кожному пакеті помітно дорожчі за сам корисний вміст.

Транспорт залежить від плати: Wi-Fi як пріоритетний, стільниковий модем як резервний там, де він встановлений. Перемиканням керує сама плата.

Що налаштовується на платі з боку мережі:

  • адреса брокера і порт, логін та пароль;
  • Wi-Fi SSID і пароль, потужність передавача в межах 2–20 dBm;
  • NTP-сервер і зсув часового поясу;
  • період телеметрії — від 10 секунд, і період heartbeat — від 30 секунд.

Контракт обміну описаний машинно, у форматі AsyncAPI, і не може розійтися з прошивкою: і структури в коді, і специфікація генеруються з одного реєстру каналів. Поля, якого немає в джерелі, не існує ніде. Для інтегратора це означає, що документація протоколу — не переказ, а той самий файл, з якого зібрана плата.

Креденшели брокера

Пароль до брокера видається платі рівно один раз: у базі лишається тільки хеш. Загубили — перевипускаєте, і перевипуск миттєво розлогінює стару плату.

Це не зайва суворість. Спільний пароль на флот означав би, що будь-яка знята зі стіни плата відмикає чужий зал.

Офлайн-база перепусток

Головна відповідь на питання «а що буде, коли зникне інтернет».

Чинні абонементи дублюються на саму плату: хто людина, до якого числа діє її абонемент і в які ворота пускає. Плата зберігає це у власній файловій системі і вирішує проходи сама.

Синхронізація — дельта, а не повне перезаливання. У кожного запису на сервері є прапорець «доставлено»:

  1. Права змінилися — запис позначається як брудний.
  2. Сервер надсилає платі брудні записи, плата застосовує їх і підтверджує.
  3. Плата була офлайн — запис лишається брудним і доїде, щойно звʼязок зʼявиться.

Видалення передається окремо, як відкладена зміна, — на видаленому рядку прапорець не поставиш. Застосування ідемпотентне: якщо підтвердження загубилось і сервер надіслав запис удруге, повторне застосування нічого не зіпсує.

Звірка бази

При кожному підключенні плата сама надсилає статистику: скільки в неї користувачів і токенів, контрольну суму бази і час останнього оновлення. Сервер порівнює це зі своїм очікуванням.

Якщо кількість або контрольна сума не збігаються — сервер стирає базу на платі й заливає її заново. Сюди ж потрапляє випадок, коли плату перепрошили або скинули до заводських: у неї нуль записів, сервер це бачить і відновлює. Окремої команди «мені потрібна синхронізація» від плати не треба.

Чого офлайн-база НЕ робить

Це місце, де чесність важливіша за рекламу.

Офлайн синхронізується головне — кого пускати і в які ворота. А от вікно часу тарифу офлайн не застосовується: абонемент «до 17:00» за відсутності звʼязку відчинить турнікет і о десятій вечора.

Це свідома поступка, і вона названа: без інтернету зал радше пустить свого клієнта, ніж зачиниться перед ним. Онлайн правило працює повністю — і саме воно основне.

Поведінка без звʼязку

Режим обирає власник залу, платформного значення за замовчуванням немає:

  • не пускати нікого — без сервера точка зачинена;
  • пускати за офлайн-базою — звичайний режим;
  • тільки офлайн-база — плата не питає сервер узагалі;
  • локальні правила завжди — вони діють і при живому сервері.

Окремо налаштовується аварійний режим: через задану затримку після втрати звʼязку вхід починає керувати реле напряму, рівнем сигналу. Коли звʼязок повертається, режим вимикається, а реле повертається у свій базовий стан — не просто «вимкнено».

Журнали і доставка команд

Проходи, зроблені платою самостійно, зберігаються в ній і віддаються серверу, коли звʼязок повернеться. Вони зʼявляться в журналі із затримкою, але не загубляться.

Команда «відкрити» має три результати, а не два:

  • підтверджено — плата відповіла, прохід відкрито;
  • надіслано — команда пішла, відповідь не дійшла;
  • не надіслано — не вдалося навіть опублікувати.

Середній стан існує не для краси. Плата могла крутнути турнікет, а підтвердження загубитись у мережі; сказати «не вийшло» означало б показати ресепшену червоне там, де людина вже пройшла, — і адміністратор натиснув би вдруге.

Що підготувати до монтажу

  • Зчитувач із виходом Wiegand-26 (якщо потрібні картки — і плата зі зчитувачем, тобто не MINI).
  • Механізм із сухим контактом і розуміння, яка тривалість імпульсу йому потрібна.
  • Мережу на обʼєкті: Wi-Fi або, для плат із модемом, покриття стільникового.
  • Адресу брокера й одноразовий пароль для плати з інтерфейсу.
  • Рішення, що робити без інтернету, — один із чотирьох режимів вище.

Далі — склад і каса.