Протокол платы замков UPUS-SKB27
Протокол снят эмпирически 2026-08-31 и перепроверен на живом 2026-09-01: все 27 каналов, контрольная сумма сошлась на 28 кадрах из 28. Документа от производителя не существует — в открытом доступе его нет, а вендорское приложение, которое им пользовалось, было стёрто до того, как проект начался.
Здесь — рабочая выжимка. Полная запись с историей поиска живёт в репозитории прошивки
(docs/LOCK-PROTOCOL.md), готовая реализация — в packages/lock-protocol.
Четыре запрета — два из них про необратимую поломку железа.
Кадры 9A и 9B сжигают катушку соленоида за десятки секунд, и плата об этом не сообщит.
Линия
| Значение | |
|---|---|
| Порт | /dev/ttyS0 (узел fdd50000.serial, владелец system:system) |
| Скорость | 9600, 8N1, без управления потоком |
| Физика | RS485, полудуплекс, задний клеммник корпуса |
| Адрес платы | 0x02 — ⚠️ не 1, вопреки DIP-переключателю. Найден развёрткой адресов |
| Каналов | 27, нумерация 1:1 с шелкографией CH01…CH27 |
| Контрольная сумма | XOR всех байтов, кроме последнего |
Соседние порты, чтобы не перепутать: ttyS1 — это Bluetooth-UART, ttyS3 свободен, но
сигнала платы замков там нет, /dev/ttyS2 в системе отсутствует вовсе.
Константы линии живут в packages/lock-protocol/src/protocols.ts: LOCK_PORT, LOCK_BAUD,
LOCK_ADDRESS, LOCK_CHANNELS.
Открыть ячейку
8A <адрес> <канал> 11 <XOR> XOR = 0x8A ^ адрес ^ канал ^ 0x11
CH01 → 8A 02 01 11 98
Плата подтверждает приём эхом того же кадра. Эхо приходит только на кадр со сошедшейся суммой — с испорченной плата молчит вовсе. Значит это разбор, а не закольцовывание линии:
| Послано | Ответ |
|---|---|
| открытие канала 3, сумма верная | эхо кадра |
| открытие канала 3, сумма неверная | тишина |
| чтение всех, сумма верная | кадр состояния |
| чтение всех, сумма неверная | тишина |
| произвольный мусор | тишина |
Эхо говорит «команда принята и проверена». Физический результат знает только датчик: опросить состояние примерно через полсекунды после коман ды (импульс длится 357 мс). Код, который считает подтверждение доказательством открытия, будет ошибаться в поле — и именно там, где ошибку заметит клиент.
Импульс
Длительность задаёт сама плата, команда её не несёт: три измерения по звуку дали 357 / 358 / 357 мс. Это жёсткая константа прошивки платы, удлинить её нашей командой невозможно.
Отсюда правило, зашитое в LOCK_REOPEN_MIN_MS = 500: повторное открытие того же канала
не слать чаще, чем раз в полсекунды, иначе команда придётся на ещё не завершившийся
импульс. Соблюдает его LockBus, а не вызывающий код.
Команды «закрыть» не существует
И существовать не может. Защёлка пружинная, fail-secure: плата даёт импульс, язычок убирается, дальше дверцу закрывает человек рукой и язычок защёлкивается сам.
Следствие для кода: «закрыто» — это показание датчика, а не результат команды. Поля
close в пресете протокола оставлены только на случай моторизованных замков другого вендора.
Прочитать состояние
80 <адрес> <канал> 33 <XOR> XOR = 0x80 ^ адрес ^ канал ^ 0x33
Ответ бывает двух видов:
поканальный (5 байт): 80 <адрес> <канал> <состояние> <XOR>
общий, канал 0 (7 байт): 80 < адрес> <кан.17-24> <кан.9-16> <кан.1-8> 33 <XOR>
| Состояние в поканальном ответе | Смысл |
|---|---|
0x11 | язычок в покое → дверь закрыта |
0x00 | язычок вдавлен → дверь открыта, либо на канале ничего нет |
Общий кадр: три ловушки в одном месте
- Порядок байтов — от старших каналов к младшим. Контринтуитивно, поэтому сверено с поканальным опросом всех каналов.
- Полярность бита обратна полярности байта. В поканальном ответе
0x00= открыто, а в общем кадре бит1= открыто, бит0= закрыто. Оба варианта встречались в старых документах и выглядели противоречием — противоречия нет, просто это разные кадры. - Общий кадр покрывает только каналы 1–24. Три байта состояния — это 24 бита, а каналов 27. Каналы 25–27 читаются поканально, штатными пятибайтовыми кадрами (проверено на живом).
Формула бита канала N (1…24), целочисленное деление:
байт = frame[4 - (N-1)/8]
бит = (N-1) % 8 в бите 0 = закрыто, 1 = открыто
Практическое следствие: полная картина 27 каналов — это один общий кадр плюс три поканальных запроса, а не 27 обменов. Общий кадр стоит одного обмена вместо двадцати четырёх.
0x00 — это два состояния сразу
Ответ 0x00 означает одновременно «дверь открыта» и «на этом канале ничего нет».
Различить их опросом невозможно — ответ платы байт в байт одинаковый. Плат а сообщает
состояние входа, а не наличие железа на нём.
Полярность при этом удачная: неподключённый канал и оборванный шлейф читаются как «открыто», то есть как тревога, а не как ложное «всё заперто». Отказ склоняется в безопасную сторону.
Что из этого следует для архитектуры — состояние ячейки. Коротко: карта «ячейка ↔ канал» приходит из конфигурации и не может быть получена автоопределением.
Кадры открытия по каналам
Считать их в уме не нужно — это делает safeOpenFrame(channel). Таблица приведена, чтобы
можно было сверить руками то, что ушло в порт.
| Ячейка | Кадр | Ячейка | Кадр | Ячейка | Кадр | ||
|---|---|---|---|---|---|---|---|
| CH01 | 8A 02 01 11 98 | CH10 | 8A 02 0A 11 93 | CH19 | 8A 02 13 11 8A | ||
| CH02 | 8A 02 02 11 9B | CH11 | 8A 02 0B 11 92 | CH20 | 8A 02 14 11 8D | ||
| CH03 | 8A 02 03 11 9A | CH12 | 8A 02 0C 11 95 | CH21 | 8A 02 15 11 8C | ||
| CH04 | 8A 02 04 11 9D | CH13 | 8A 02 0D 11 94 | CH22 | 8A 02 16 11 8F | ||
| CH05 | 8A 02 05 11 9C | CH14 | 8A 02 0E 11 97 | CH23 | 8A 02 17 11 8E | ||
| CH06 | 8A 02 06 11 9F | CH15 | 8A 02 0F 11 96 | CH24 | 8A 02 18 11 81 | ||
| CH07 | 8A 02 07 11 9E | CH16 | 8A 02 10 11 89 | CH25 | 8A 02 19 11 80 | ||
| CH08 | 8A 02 08 11 91 | CH17 | 8A 02 11 11 88 | CH26 | 8A 02 1A 11 83 | ||
| CH09 | 8A 02 09 11 90 | CH18 | 8A 02 12 11 8B | CH27 | 8A 02 1B 11 82 |
Канала 0 в команде открытия в этой таблице нет намеренно: он предположительно означает «открыть все» и запрещён барьером — на собранном шкафу он выстрелил бы всеми катушками разом.
Что уже написано в коде
Ничег о из перечисленного не нужно писать заново:
| Задача | Чем решается |
|---|---|
| собрать кадр открытия / чтения | safeOpenFrame(), safeStatusFrame() |
| проверить, что кадр вообще можно отправить | assertFrameAllowed() |
| разобрать один кадр | parseReply() |
| снять кадр с начала буфера | takeReply() |
| собрать кадры из потока байтов с мусором | FrameReader |
| держать порт, очередь и паузы | LockBus в apps/kiosk/src/hardware/ |
FrameReader добавляет к разбору единственную вещь — время. takeReply() при нехватке
байтов честно отвечает «жду ещё», и это правильно, но 5–6 байт мусора без продолжения
пролежали бы в буфере навсегда и испортили первый же законный ответ. Полудуплексный RS485
роняет такие огрызки в приёмник при каждом переключении направления. Порог простоя — 80 мс:
на 9600 бод семибайтный кадр укладывается в 7 мс, то есть порог заведомо больше любой
законной паузы внутри кадра и меньше паузы между обменами.
Что осталось непроверенным
Отмечено честно: ниже — не факты, а дырки, которые закроются только на собранном шкафу.
- ❓ Реальный датчик на каналах 25–27. Плата на них отвечает — это факт. Но на стенде
железа на этих каналах не было, все три отдали
0x00, а0x00неразличим. - ❓ Реакция на обрыв шлейфа датчика в отличие от «датчика нет вовсе». Полярность обещает, что обрыв прочтётся как «открыто», то есть безопасно, но это рассуждение, а не измерение.
- ❓ Канал 0 в команде открытия — действительно ли «открыть все». Не проверяли и проверять не будем нигде, кроме шкафа, где известно, что висит на каждом канале.
- ❓ Почему адрес 2 при DIP «1» — возможно, кодировка DIP+1. При замене платы адрес искать
развёрткой
0x00…0x1F.