Автономные замки: права доступа живут в карте

Это классика гостиничного доступа и самая распространённая схема в России — так работают электронные гостиничные замки OZLocks (серия H). Замок не подключён ни к какой сети — он автономен и питается от батареек. Вся логика «кому можно открыть эту дверь» хранится в двух местах: в памяти самого замка и на карте-ключе гостя.

Журнал открытий тоже снимается через карту: в Hotelier PRO информацию о проходах считывают с карты данных Mifare или с приёмника записи данных — то есть данные с двери нужно физически донести до считывателя. Это ключевое отличие от онлайн-систем, к которому мы ещё вернёмся.

Несмотря на автономность, программа закрывает весь гостиничный цикл: посуточное и почасовое размещение, групповое заселение, бронирование, отчёты, выгрузку в УФМС, энергосберегающие карманы-выключатели и резервный механический ключ на случай форс-мажора. Главная ценность Hotelier PRO, как формулирует сам производитель — защита владельца от неучтённой сдачи номеров и связанной с этим потери выручки.

TTLock и TTHotel: два разных продукта, которые часто путают

Это, пожалуй, самая распространённая путаница на рынке. TTLock и TTHotel работают на одних и тех же замках, но это две разные системы с разной логикой, и для отеля разница принципиальна. Если коротко: TTLock — это смартфонно-облачный продукт для частника, а TTHotel — гостиничная система, которая копирует логику классических карточных замков. Ниже описываем обе системы по открытой документации вендора (Sciener) и нашей практике интеграции, по состоянию на июнь 2026; производитель вправе менять поведение продукта, поэтому перед закупкой характеристики стоит сверять с актуальной версией.

TTLock — приложение, облако, смартфон

Стандартный TTLock рассчитан на квартиру, апартаменты, посуточную аренду. Главный «ключ» — телефон по Bluetooth; замком управляют из мобильного приложения, ключи выдаются ссылкой (eKey), а аккаунт и журнал живут в облаке Sciener. Характерная деталь: чтобы записать карту в замок удалённо, энкодер TTLock работает только если замок подключён к интернету через шлюз, а сама запись идёт через веб-кабинет. То есть «из коробки» это облачная история, завязанная на смартфон и сеть.

TTHotel — карта на стойке, как у классических замков

А вот гостиничный TTHotel устроен иначе и намеренно повторяет логику обычных гостиничных замков: данные о доступе и список замков записываются в память карты, и карта действует только на оплаченный период проживания. «Мозг» системы — бесплатное ПО для Windows и USB-энкодер на стойке администратора, которым кодируются карты. Ключевое отличие от TTLock: гостиничный энкодер работает и в офлайне (без шлюзов), и в онлайне (со шлюзами) — то есть карту можно выпустить без всякого интернета, доступ уже зашит в неё.

Важная оговорка про данные и автономность. Управляющее ПО TTHotel завязано на облако вендора: оно обменивается данными с облачной платформой Sciener. Более того, само приложение TTHotel без интернета не запускается — поэтому выпустить новую карту на стойке при пропавшей связи не получится (ранее выданные карты дверь при этом открывают, доступ зашит в них). Сам момент открытия двери автономен, но рабочее место администратора — нет. Отсюда два следствия: зависимость от внешнего канала прямо в процессе заселения и вопрос по 152-ФЗ, поскольку часть данных покидает периметр объекта (какие именно — определяется протоколом обмена вендора). Для государственных и ведомственных объектов облачная зависимость часто оказывается стоп-фактором.

Онлайн-замки HTLock: замок отвечает в реальном времени

HTLock — это программно-аппаратный комплекс, где замки уже подключены к системе по радио. Замки серии WR сохраняют автономное питание от батареек, но дополнительно несут на борту два радиоканала: Bluetooth (BLE) для мобильного ключа и Sub-1G (суб-гигагерцевый диапазон) для связи со шлюзом. Здесь важно подчеркнуть: к каждой двери не нужен Wi-Fi или провод — замок общается со шлюзом по дальнобойному радио, а шлюз уже подключён к локальному серверу.

Способов открыть дверь у HTLock заметно больше, чем у автономного решения: карта Mifare (зашифрованная под объект), мобильный ключ по Bluetooth, пользовательский PIN-код, временный offline-код и даже отпечаток пальца. Система работает через локальный сервер с протоколом MQTT, поддерживает бизнес-сценарии «Объект / Хостел / Апартаменты», управление лифтами и поэтажными считывателями. Привязку и пусконаладку замков ускоряет портативный программатор OZLocks-HS — он позволяет быстро привязать большое количество замков на крупном объекте (в автономном Hotelier PRO он не используется — там настройка идёт картами).

За счёт онлайн-канала появляются сценарии, которые автономному замку недоступны в принципе: мгновенный отзыв доступа, журнал проходов в реальном времени прямо в системе, удалённый контроль заряда батарей и состояния замков. Интеграция с PMS реализуется через OZLocks Plus — отдельный сервер интеграции OZLocks, который связывает HTLock (и автономный Hotelier PRO) с системами управления отелем. Именно онлайн-обратная связь — главное, за что доплачивают по сравнению с автономной схемой.

Замки на LoRa: дальнее радио и его обратная сторона

Часть конкурентов строит гостиничные системы на LoRa (Long Range) — радиотехнологии, изначально созданной для интернета вещей. Архитектурно это похоже на HTLock: сеть строится по топологии «звезда» из трёх частей — оконечный узел (замок), шлюз и сервер приложений. Замок передаёт данные на шлюз по дальнобойному радио, шлюз пересылает их на сетевой сервер.

Сильная сторона LoRa — это дальность и проникающая способность. Технология работает в нелицензируемых суб-гигагерцевых диапазонах (433, 868, 915 МГц) и бьёт на большие расстояния при формально низком энергопотреблении. Один шлюз способен покрыть крупную территорию — на открытых объектах это порядка нескольких десятков замков на дистанции более километра в прямой видимости. Для разрозненной застройки (санаторий с корпусами, кампус, база отдыха) это реальное преимущество: меньше шлюзов на гектар.

Но у дальности есть цена, и она техническая. LoRa проектировалась под редкую передачу маленьких пакетов, а не под интенсивный двусторонний обмен. Скорость передачи измеряется единицами–десятками килобит в секунду — это очень мало. Для датчика протечки, который шлёт статус раз в сутки, такого запаса хватает с лихвой, но у дверного замка в час пик профиль нагрузки совсем другой.

Бюджет батареек на LoRa: почему «годы от батарейки» — не вся правда

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

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

2. Приёмные окна — за отзывчивость платит батарея. В самом экономичном режиме (Class A) замок открывает всего два коротких приёмных окна сразу после собственной передачи — и снова засыпает. В этом и есть секрет «батарейки на годы»: устройство почти всё время спит. Но плата за это — сервер может прислать команду замку только в эти окна, то есть только после того, как замок сам что-то передал. Команда «открыть сейчас» или «заблокировать карту» не уходит мгновенно — она ждёт в очереди до следующего выхода замка на связь.

3. Парадокс отзывчивости. Чтобы замок реагировал на удалённые команды быстро, есть два пути, и оба бьют по батарейке. Либо замок часто выходит на связь коротким «пульсом» — но каждая передача тратит заряд и упирается в лимит занятости канала. Либо переводится в режим почти всегда включённого приёмника (Class C) — тогда команды доходят мгновенно, но непрерывный приём потребляет столько, что такие устройства, как правило, питают от сети, а не от батареек. Промежуточный режим с расписанием приёмных окон (Class B) — компромисс, но всё равно расходует заметно больше, чем спящий Class A.

Остальные оговорки

Низкая пропускная способность и особенности полудуплекса означают, что массовые операции в реальном времени (одновременная рассылка команд на десятки дверей) идут медленнее, чем хотелось бы. Кроме того, многие LoRa-решения для замков завязаны на облако: данные замка синхронизируются с облачной платформой, а управление идёт через интернет. Для российского отеля это сразу поднимает вопросы 152-ФЗ и зависимости от внешнего канала. Справедливости ради — у зрелых LoRa-замков есть и автономный режим, и шифрование AES-128, и набор способов входа (карта, код, QR, отпечаток). Технология рабочая. Вопрос в том, решает ли она задачу конкретного отеля лучше, чем локальная связка на Sub-1G — особенно на компактном объекте и при требовании держать данные у себя.

АУРА: не замок, а система, которая управляет замками

Здесь важно сменить оптику. Автономные, TTLock, HTLock и LoRa — это решения уровня доступа: они отвечают на вопрос «как открыть дверь». АУРА работает уровнем выше. Это российская GRMS-система АУРА (Guest Room Management System) — одна из первых отечественной разработки. Её ключевое отличие проверяемо: АУРА объединяет в одном интерфейсе доступ, климат, свет, сервис и аналитику и сама управляет замками OZLocks — и автономными, и онлайн, чего отдельный замок ни одной из перечисленных систем не делает.

АУРА кроссплатформенна, распространяется в виде Docker-контейнера и ставится локально. Один из ключевых тезисов системы — «никаких облаков»: ПО устанавливается на территории объекта, а архив данных ограничен только размером вашего хранилища. Инженерная инфраструктура — климат, питание, датчики — подключается через Modbus-шлюзы: список шлюзов, подключённые устройства, регистры и задачи Modbus, мониторинг состояния и привязка к триггерам.

Логичный вопрос — а где здесь «проводное на Modbus», вынесенное в заголовок? Modbus в АУРА отвечает не за сами замки, а за инженерную обвязку умного номера: это промышленный проводной протокол, по которому система общается с климатом, питанием и устройствами в номере. Замки при этом могут быть и автономными, и онлайновыми OZLocks. То есть АУРА совмещает проводную надёжность инженерных шин с гибкостью электронных замков.

Замок отвечает на вопрос «как открыть дверь». АУРА отвечает на вопрос «как управлять всем отелем» — и доступ здесь лишь один из модулей.

Бюджет батареек: незаметная, но реальная статья расходов

Об этом редко думают на этапе выбора, но на горизонте нескольких лет расход батареек превращается в ощутимую строку: на сотне дверей это десятки комплектов в год плюс время персонала на обход и замену. И здесь разные радиотехнологии ведут себя по-разному — потому что именно радио, а не сам факт открытия двери, съедает основную энергию.

Автономные замки — самый скромный аппетит. Радиомодуля нет вовсе: замок «спит» и просыпается только в момент поднесения карты. Поэтому комплект батареек живёт долго, а расход предсказуем. Платой за эту экономию становится изоляция замка — но по энергетике это эталон.

Bluetooth (TTLock / TTHotel) — зависит от режима. В чисто карточном офлайн-режиме TTHotel замку не нужно постоянно держать радио — расход ближе к автономному. Но как только добавляется онлайн (шлюз) или ставка делается на мобильный ключ, замок начинает периодически «слушать» эфир по BLE, и расход растёт. BLE сам по себе экономичен, но постоянное прослушивание тратит заряд заметнее, чем спящий автономный замок; а режим сна ради экономии добавляет задержку событий.

Sub-1G (HTLock) — разумный баланс. Суб-гигагерцевый канал энергоэффективнее Wi-Fi и работает короткими пакетами: замок выходит на связь со шлюзом, передаёт событие и снова засыпает. В итоге вы получаете онлайн-обратную связь, но без драматичного роста расхода батареек по сравнению с автономной схемой.

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

Что происходит при разрыве связи со шлюзом

Главный страх отельера про онлайн-системы: «упадёт сеть — и гости останутся в коридоре». Поэтому важно честно разобрать, как каждое решение ведёт себя, когда связь со шлюзом, контроллером или сервером пропала.

Автономные, HTLock и АУРА — продолжают работать. Здесь всё надёжно: автономному замку сеть не нужна в принципе; HTLock при потере связи со шлюзом откатывается в автономный режим и пускает гостя по карте; у АУРА сервер стоит на объекте, а в каждом номере есть контроллер комнаты, который работает автономно — так же, как HTLock или Hotelier PRO. Поэтому при обрыве связи с сервером номер продолжает функционировать, заселение и работа с бронями не останавливаются, а данные синхронизируются после восстановления. Гость войдёт в номер в любом случае.

TTHotel — тут есть серьёзная оговорка. Ранее выданные карты дверь открывают: доступ зашит в карту на срок проживания, и открытие — локальная операция (карта, код, механический ключ работают и без сети). Но, по документации вендора, само приложение TTHotel без интернета не запускается — а значит, при обрыве связи вы не сможете выпустить новую карту на стойке и, по сути, не заселите нового гостя, пока интернет не вернётся. Это и есть ключевая разница с по-настоящему автономными решениями: у Hotelier PRO, HTLock и АУРА стойка продолжает работать и заселять при пропавшей сети, а у TTHotel — нет.

LoRa — зависит от реализации вендора, и это надо проверять. Архитектурно LoRaWAN устроена так, что шлюз — это мост к серверу, а обработка идёт на сетевом сервере; без него устройства, по образному выражению инженеров, «кричат в пустоту». Это значит, что автономность при разрыве у LoRa-замка не гарантирована по умолчанию — она появляется, только если вендор специально её заложил: поднял локальный сетевой сервер на объекте или реализовал заранее выданные офлайн-ключи. Бывают и такие решения, но это не свойство технологии, а решение конкретного производителя. Поэтому к LoRa остаётся та же оговорка: уточняйте у поставщика, где хранятся данные и работает ли замок без связи с сервером.

У автономных, HTLock и АУРА ответ один: гость войдёт, и стойка продолжит заселять. У TTHotel ранее выданная карта откроет дверь, но без интернета приложение не запустится — нового гостя не заселить. У LoRa — как заложил вендор.

Обновление HTLock: функции, которых нет у автономных систем

Свежее обновление HTLock усиливает именно онлайн-сторону — то, ради чего вообще берут сетевые замки. Эти возможности наглядно показывают разрыв между автономным замком и замком, который всегда на связи.

Автономный замок узнаёт о потерянной карте только когда вы дойдёте до двери. Онлайн-замок узнаёт об этом за секунду — и сам заносит карту в чёрный список.

Сравните это с автономной схемой: чтобы заблокировать утерянную карту персонала на всех дверях, в автономной системе пришлось бы либо перепрограммировать замки, либо полагаться на срок действия карты. В HTLock это одна удалённая команда. То же с режимом офиса — открыть на день все двери конференц-зоны в автономной системе физически невозможно без обхода каждого замка.

Кому какое решение подходит в России

Универсального ответа нет — есть профиль объекта и российская специфика: импортозамещение, 152-ФЗ, нестабильный интернет на части объектов и требование держать данные у себя. Вот короткий ориентир по всем пяти.

Российский контекст добавляет ещё один слой. Где данные покидают объект — а это TTLock и TTHotel (оба завязаны на облако вендора) и часть LoRa-решений — отелю придётся отдельно прорабатывать соответствие 152-ФЗ, а для госсектора это нередко стоп-фактор. Точный состав того, что уходит в облако, определяется протоколом обмена конкретного вендора. Локальные решения (автономные, HTLock, АУРА) этот вопрос снимают по умолчанию: данные остаются на сервере объекта. Там, где важно импортозамещение, дополнительный плюс отечественной разработки — независимость от зарубежных облаков и поддержки.

Короткий вывод. Если задача — только доступ, для большинства отелей в одном или нескольких зданиях оптимальна связка онлайн-замков HTLock на Sub-1G с локальным сервером: все онлайн-сценарии и пакетные операции, но без зависимости от облака. Там, где сеть шлюзов ещё не развёрнута, те же замки работают автономно по картам — переход на онлайн поэтапный.

Если же вы строите умный отель целиком — с экономией ресурсов, сценариями номера и защитой от заселения «мимо кассы» — то правильный уровень разговора уже не замок, а GRMS. Здесь АУРА объединяет всё перечисленное в одной локальной системе и сама управляет вашими замками OZLocks. Замковое решение в этом случае становится фундаментом, а не самоцелью.

Коротко о главном