В 2016 году поставило руководство одному знакомому задачу: развернуть с нуля СКУД. Да чтоб автоматизировано всё было: с выгрузкой данных в 1С, с табелированием, с отчётами по опоздунам и т.д. Было выбрано решение под ключ за 600 тыс. рублей. Ого, говорит, начальство, как дорого! Мы найдём дешевле. Нашли за 200. Проработала система "за 200" не больше полугода. Обратились к подрядчику, а он обанкротился и закрылся. Зам начальника СБ привёл "моих рексов, которые всё умеют и щас сделают по-красоте!". По-красоте вышло на 450 тысяч. Когда с наступлением сырого времени года начали отказывать считыватели, оказалось, что они не предназначены для применения вне помещений. "Моим рексам" подкинули ещё 150 тыс на устранение недочётов. Через год оказалось, что рексы наэкономили не только на железе, но и на софте. И когда БД упёрлась в лимит 4 Гбайта, она сказала "кря", и отказалась дальше работать. После рексов пришла третья контора и сделала всё с нуля под ключ за 800 тысяч. Шёл 2018 год.
Обычно система контроля доступа напоминает о себе в самый неподходящий момент: сотрудник не может попасть в офис, у посетителя не оформляется пропуск, а на проходной выстраивается очередь. В техподдержку в этот момент уходит короткое и не слишком информативное сообщение: «Не работает».
Для клиента это одна проблема. Для инженера – десятки возможных причин: от неверной настройки и ошибки в базе данных до сбоя оборудования, сети или сервера. Чтобы не искать их вслепую, поддержке нужен не только технический опыт, но и понятный процесс работы с обращениями.
О том, как этот процесс устроен в Parsec и почему для руководителя техподдержки важнее не число закрытых заявок, а отсутствие растущей очереди, рассказал Кирилл Баранов, руководитель отдела технической поддержки pARSEC
— Расскажите о себе и своей работе в Parsec.
— Меня зовут Кирилл Баранов, я руковожу отделом технической поддержки Parsec. Компания разрабатывает оборудование и программное обеспечение для систем контроля и управления доступом – СКУД.
В Parsec я работаю с июня 2024 года. До этого тоже управлял сервисными подразделениями, но в другой отрасли. Сегодня моя задача вместе с командой – помогать клиентам и организациям, которые эксплуатируют наше оборудование и ПО, разбираться с техническими вопросами и поддерживать работоспособность систем на объектах.
— Какая главная задача у техподдержки?
— С точки зрения клиента – помочь обеспечить стабильную работу системы на объекте. С точки зрения руководителя поддержки – сделать так, чтобы обращения не накапливались и проблемы решались в понятные сроки.
Парадоксально, но хорошая техподдержка – это не та, у которой постоянно много работы. Наоборот: в идеале клиенты редко обращаются, потому что система стабильно работает, типовые вопросы закрываются документацией, а на объекте есть люди, которые понимают, как с ней работать.
— Почему СКУД вообще может работать нестабильно? Кажется, что это просто считыватель, карта и, скажем, замок.
— На самом деле СКУД – сложный программно-аппаратный комплекс. В ней есть оборудование на объекте, сеть, серверная часть, программное обеспечение, настройки прав доступа, графиков и учёта рабочего времени, интеграции с другими системами.
На каждом этапе могут возникнуть ошибки. Например, оборудование могут неправильно подключить, сеть неверно настроить, подобрать сервер без запаса под будущую нагрузку. Бывает и человеческий фактор: кто-то меняет настройки, не до конца понимая последствия.
Многое закладывается ещё на этапе запуска. Качественный монтаж – это не только аккуратно смонтированное оборудование. Это понятная коммутация, подписанные линии, доступная документация. Когда через год или два возникает проблема, специалисту гораздо проще понять, что происходит на объекте, если система собрана и настроена аккуратно и прозрачно.
Мы ждем снимки из самых разных сервисных будней: инженеров на выездах, специалистов техподдержки за работой, сервисных центров, монтажей, диспетчерских, командировок, оборудования, рабочих процессов и команды. Главное — чтобы в кадре была настоящая сервисная работа.
🏆 Что можно выиграть?
🥇 1 место — сертификат Ozon на 10 000 ₽ 🥈 2 и 3 место — сертификаты Ozon на 5000 ₽ 🥉4, 5 и 6 место — сертификаты Ozon на 3000 ₽
После видео логично перейти к датчикам. Камера фиксирует то, что уже произошло, «на глаз». Датчик же часто срабатывает раньше: температура ползёт вверх, влажность уходит, воздух «задыхается» — а в зале визуально всё ещё «вроде нормально».
На многих объектах с датчиками повторяется одна и та же история: цифра на экране есть, а пользы от неё мало. График нарисован «для галочки», тревоги шумят по мелочам, а когда датчик перестаёт отправлять данные — система молчит, и оператор продолжает смотреть на вчерашнее значение как на актуальное.
В EAS сенсорный блок создавался не ради красивого слайда, а под реальную эксплуатацию: важно, что видит пост, что попадает в отчёт, и когда система честно говорит: «данные устарели».
Что должно быть у нормального сенсорного контура
Минимум, без которого датчики превращаются в декор:
понятный статус — норма, предупреждение, критично;
привязка к месту на схеме (см. статью 2 — те же метки на плане);
быстрый переход от проблемы к конкретному датчику и его истории;
отчёт за период — не только «сейчас», но и «как шло за смену / неделю»;
отдельный контроль «датчик перестал обновляться» — не путать с «всё спокойно».
Без этого — просто красивые цифры без решений.
«Молчащий» датчик и состояние sensor_stale
В мониторинге EAS есть отдельный тип проблемы — sensor_stale: показания не обновлялись дольше допустимого.
На практике датчик может:
зависнуть прошивкой;
потерять связь с хабом;
отправлять данные редко.
Но система должна это знать, а не показывать старую цифру как свежую.
Пороги по умолчанию настраиваются (предупреждение — около 15 минут, критично — около часа). Смысл один: тишина на проводе не должна выглядеть как «всё в порядке».
На «Схеме (онлайн)» такие датчики автоматически поднимаются в ленту проблем рядом с камерами и СКУД. Оператору не нужно помнить, когда в последний раз мигала температура в подвале.
Мониторинг: график из реальных точек, а не «нарисованный»
Вкладка «Мониторинг датчиков» (группа «Датчики» в боковом меню) — это рабочее место, а не витрина.
Вы выбираете датчик из дерева (подписи человекочитаемые, не только entity_id), период 1 ч / 24 ч / 7 д / 30 д, и смотрите «Историю значения». Под графиком — служебная строка вроде «Точек: N»:
если N большое — кривая построена из накопленной телеметрии;
если ноль — честно пусто, без фальшивой линии.
С 2026 года графики в админке приведены к единому стилю (Chart.js, линии без заливки под кривой — так проще читать несколько рядов, цветовая тема из CSS). На скриншоте это мелочь, но при работе в смену глаза устают меньше.
Мониторинг датчиков: история температуры, счётчик точек телеметрии
Как читать график без инженерного образования
Достаточно простых правил:
линия растёт — значение растёт;
падает — значение падает;
резкий скачок — было нетипичное изменение (открыли дверь, включили обогрев, сбой);
долгая полка без новых точек — возможно, датчик не отправляет данные (см. sensor_stale).
Этого достаточно, чтобы оператор понял: «спокойно» или «надо проверить». Без споров «мне кажется, было жарко».
Как читать график без инженерного образования
Достаточно простых правил:
линия растёт — значение растёт;
падает — значение падает;
резкий скачок — было нетипичное изменение (открыли дверь, включили обогрев, сбой);
долгая полка без новых точек — возможно, датчик не отправляет данные (см. sensor_stale).
Этого достаточно, чтобы оператор понял: «спокойно» или «надо проверить». Без споров «мне кажется, было жарко».
Три кривые на одном полотне
Отдельная картинка — не скриншот админки, а выгрузка тех же трёх температур из telemetry_samples (склад А, офис Б, узел TVOC). Хорошо видно, что линии шумные и живые — как в реальной эксплуатации.
Температура: три кривые из telemetry_samples
Отчёты: график, сводка, выгрузка
Вкладка «Отчёты датчиков» — для смены, руководителя и расследования.
Вы выбираете несколько датчиков, тип показаний («Температура» и др.), период, режим «График», нажимаете «Построить». Появляются легенда, сводная таблица и линии по времени (с агрегацией по корзинам, если точек много — чтобы график не превращался в кашу). При наведении на линию показываются значения в точке. При необходимости — выгрузка в CSV / XLSX с тем же набором данных.
Отчёты по датчикам: три температуры за неделю после нажатия «Построить»
(Три температуры: склад А, офис Б, узел TVOC, период около 7 суток. Если период пуст или выбраны «не те» метрики — интерфейс явно пишет «нет данных», а не рисует пустышку.)
Формат отчёта сделан так, чтобы его можно было переслать без перевода с айтишного: понятно, какой интервал, какие датчики и что было по значениям.
Пример из жизни
Утром в зоне хранения на экране +18 °C — «норма». Ночью датчик перестал обновляться, а система без контроля свежести не подняла тревогу. К обеду проблема уже «на полу», а в журнале нет ни одной точки за ночь.
С sensor_stale и историей в мониторинге сценарий другой: тишина ловится до того, как склад превращается в новость.
Короткий итог
Хороший сенсорный контур — это не только «выше порога — пищать». Это:
живые данные с понятным возрастом;
график, на который можно опереться в споре;
отчёт, который поймёт не только интегратор;
молчание датчика как отдельная проблема, не хуже перегрева.
Тогда датчики работают раньше камеры, а не висят пятой вкладкой «для галочки».
В двух словах
Датчики полезны, когда система объясняет смысл показаний, строит графики из реальной телеметрии и вовремя замечает устаревшие данные.
После шумного, неспокойного, хипёжного и шебутного GITEX AI Kazakhstan сходка международных партнёров Sigur была как глоток Old Fashion посреди кислотной тусовки с Long Island Extazy Acid Shok.
Тут случилось неприличное: мероприятие оказалось хорошо, почти идеально сделанным. Даже парочка мелких нюансов, казались намеренно вплетёнными в повествование дабы у участников не разорвалось сердце от восторга.
Sigur Partners Day by Artorius
10 мая всё началось в уютном ресторане в горах рядом с уже опустевшими трассами Шымбулака, а затем продолжилось в гольф-клубе, где я понял, что махать клюшкой тоже нужно уметь.
Публично само мероприятие, конечно же, не освещалось, так что у вас есть шанс заглянуть в закулисье. Ресторану отдельный респект за его шеф-повара и "спагетти с казы". А про «Жайляу» можно сказать отдельно: это не просто красивая локация, а гольф-курорт у подножия Заилийского Алатау с 18-луночным полем, тренировочными площадками и, конечно же, банкетными залами.
Sigur Partners Day by Artorius
Это была просто партнёрская встреча. Но, по сути, это было то, что многие вендоры пытаются изображать годами, а получается редко: нормальное живое событие для людей, которые не просто покупают и продают железо, а строят вокруг продукта отношения.
Были руководители и техно-топы компаний-партнёров из разных стран: Азербайджан, Армения, Узбекистан, Казахстан, Беларусь. Уже одно это создавало ощущение не очередной презентации «у нас новая версия, посмотрите на слайд 47», а настоящей международной профсреды.
Sigur в лице Констанина Малеева и Сергея Лещёва немного рассказал о будущем развитии, особенно о софте. А Тимур Абдуллаев, директор ArtoriusCorp - представительства Sigur в Казахстане, приветствовал участников и высказал надежду на дальнейшее развитие этого "международного клуба". Но, как мне показалось, главная цель была другой: собрать людей, дать им поговорить, обменяться опытом, провести время вместе и почувствовать, что они не отдельные дилеры, разбросанные по карте, а часть партнёрской экосистемы.
И это сработало.
В отличие от GITEX, где масштаб местами пожирал смысл, здесь смысл был именно в формате. Программа, локации, активности и общая атмосфера: всё работало на одну задачу. Не продать ещё один контроллер. Не пересказать прайс. Не утомить людей обязательной презентацией, чтобы потом они заслужили шашлык. А создать связи.
Были выступления. Короткие. Местами, скажем честно, нудноватые. Константин как опытный спикер обыграл и локацию и само событие и просто задал тон мероприятию. А вот выступления Тимура и Сергея немного проиграли на фоне пейзажей и смены вкусных блюд на потрясающие десерты. Можно было сделать гвозди программы, потому что содержательный потенциал там был. Но в текущем виде они скорее ощущались как обязательная часть перед тем, ради чего все действительно приехали: общением.
И вот здесь важный урок для организаторов. Если у вас есть сильные люди внутри компании, не надо выпускать их на сцену в формате «ну расскажи что-нибудь». Это преступление против спикера, аудитории и здравого смысла. Хороший эксперт без подготовки может выглядеть скучным. А слабый, но подготовленный спикер иногда выглядит лучше, чем заслуживает. Несправедливо, но так устроен жанр. Сцена любит тех, кто её уважает.
При этом выступления не испортили общего впечатления. Потому что мероприятие было собрано правильно. Общение было живым. Интерактив был. Люди не просто присутствовали, они взаимодействовали. И главное: аудитория была лояльной, активной и "в контексте". Организаторы понимали, кого зовут, зачем зовут и что этим людям нужно.
Sigur Partners Day by Artorius
Это, по моим ощущениям, был лучший формат партнёрской конференции из тех, что я видел. Не потому, что я там не просто слушатель. Нет. Не потому, что там были торжественные речи. К счастью, нет. А потому, что Artorius сделал то, что партнёрское мероприятие и должно делать: укрепил связи.
Вендор на таком событии перестаёт быть только поставщиком. Он становится центром сообщества. А это уже совсем другая капитализация. Её сложно положить в Excel, хоть и есть такая строка в финансовых отчётах как Goodwill, это легко почувствовать в разговорах, в доверии, в готовности делиться опытом, в том, что люди после мероприятия уезжают не просто с буклетом, а с ощущением: «мы в одной истории».
Посоветуйте пожалуйста какой-нибудь уличный считыватель, котортый работает по Wiegand-интерфейсу и умеет читать метки Ntag2**. У меня есть ридер-копир для карт/брелков и контроллер с простым 13,56 мГц считывателем, и они мои метки Ntag216 не видят, получается просканировать только телефоном с NFC.
Я нашел на али какой-то продвинутый считыватель, который стоит в разы дороже обычных (которые умеют только Mifare Classic читать), вроде заявлено, что он в том числе с Ntag-метками работает, но у него минимальная температура работы указана только -10, боюсь зимой на улице замерзнет.
Может кто-то из распространенных у нас производителей такие делает? Smartec, Hikvision, Dahua, Hunter и тд
О видео обычно говорят просто: "ну подключили камеры, и все". На практике именно видео чаще всего и начинает ломаться первым, когда система сталкивается с реальной нагрузкой.
С видеонаблюдением часто повторяется одна и та же история: на первом запуске или «на показе» всё красиво, а под реальной нагрузкой начинаются «черные плитки», таймауты, реконнекты и странные просадки.
У меня это тоже было — и это нормально: под нагрузкой впервые видно, где слабые места. Дальше текст не «из методички»: конспект того, что уже раз пришлось пройти руками — смотреть `top`, логи трансляции, поменять одну вещь и снова проверить, ушёл ли симптом.
Локальный стенд: VirtualBox и «всё сразу»
Домашний стенд на ПК — VirtualBox.
Сервер в рабочей сети — через него идёт работа с датчиками, камерами и остальным нужным оборудованием. У меня он тоже стоял в VirtualBox: 6 виртуальных ядер, 6 ГБ оперативной памяти, под систему и приложения 25 ГБ диска, отдельно 50 ГБ под видеоархив.
Одновременно все камеры в полном качестве, постоянная запись архива, движение и просмотр по архиву и много окон live для такой конфигурации — слишком плотный пакет: процессор и диск быстро упираются в потолок, отклик «плавает», кажется, что «сломалось всё». На стенде в «жаркие» минуты служба трансляции (go2rtc) в `top` доходила примерно до ~250–350% CPU — это сумма по ядрам, не «одна строка = одно ядро»; при таких цифрах на VM с шестью ядрами сразу видно, почему «всё и сразу» без компромиссов не взлетит.
По отдельности обычно спокойнее: одна камера крупно, или только сетка с облегчёнными превью, или только архив. Выделение отдельного физического сервера на объекте пока не удалось согласовать с руководством — поэтому остаётся тестовая VM с жёсткими лимитами. На нормальном серверном железе ту же схему разумно ожидать заметно ровнее, с большим запасом под «всё сразу».
Что перебирали, пока остановились на текущем варианте
Ниже не «история коммитов», а смысл: сколько разных рычагов пришлось пощупать, пока картинка и нагрузка не сошлись в рабочий баланс. Порядок в жизни мог быть любой — важнее, что почти никогда не хватало одной правки.
Полноценный поток на каждую плитку в сетке — слишком тяжело для сервера и сети при одновременном открытии; пришлось уйти к более лёгкому потоку в сетке, а «как в мониторе» — только для одной выбранной камеры (крупный просмотр).
Несколько тяжёлых вариантов встраивания видео в браузере сразу — давали всплеск нагрузки и на клиенте, и на сервере; схему показа и запасные режимы пришлось упростить.
Запасной кадр, если с камеры временно ничего не приходит — чтобы оператор не смотрел в пустой чёрный прямоугольник (в том числе на стенде без настроенной трансляции).
Нестабильные камеры — перевод на запасной канал с меньшей нагрузкой (типичный субпоток с регистратора), подбор параметров «картинка vs стабильность» на проблемных точках.
Повторные подключения из‑за обрывов по сети — убирал лишние «хвосты» подписок, следил, чтобы не копились фоновые процессы записи после перезапуска сервера.
Баланс по ядрам — когда сеть и трансляция грузят систему, без нормального распределения прерываний узел может «косить» под одним ядром сильнее остальных. Сервер на объекте у меня тоже на VM — не домашний ноутбук, но всё равно виртуалка, не выделенное железо в стойке. После включения балансировки IRQ (`irqbalance` в Ubuntu) в одном спокойном срезе простой CPU вырос примерно с ~41% до ~76%: не волшебство, просто меньше «залипаний» и перекоса, системе легче дышать.
В сумме это много мелких шагов с проверкой «до / после», а не одна правка. Итог — компромисс: не «идеальная картинка на каждой плитке всегда», а устойчивый просмотр в реальных условиях.
Что чаще всего ломает картинку
В работе чаще всего всплывали такие причины:
нестабильный сигнал с отдельных камер или регистратора;
частые переподключения;
перегруз сервера службой трансляции, когда много окон смотрят одновременно;
сеть и очереди пакетов (на узле с ограниченными ресурсами это особенно заметно).
Поэтому искать «один баг» почти всегда промах: чаще это связка камеры, сети, сервера и того, сколько окон открыто одновременно.
Как это чинили
Не «перезагрузил вкладку — и авось», а по делу:
проверка потоков по камерам;
уборка устаревших настроек трансляции;
запасные варианты для слабых мест;
контроль фоновых задач, которые держат нагрузку;
повторные замеры после каждой правки.
Именно так постепенно получилось убрать самые болезненные сценарии. Параллельно неплохо держать в порядке список потоков, запасные варианты для проблемных камер, зависшие просмотры и метрики до/после — иначе легко перепутать «кажется лучше» с реальным улучшением.
Онлайн видео: режим «Сетка (все сразу)»
Каталог камер (IP, поток, запись в архив — через «Изменить») открывается отдельно — «Камеры» в том же разделе меню:
Каталог камер (настройка)
Список камер и кнопки «Изменить» / «Удалить»; живой просмотр — только во вкладке «Онлайн видео».
Ещё есть вкладка «Видеорегистраторы». Она нужна, чтобы не заводить каждую камеру отдельно по IP: подключаешь к EAS уже стоящий в сети регистратор и подтягиваешь с него каналы в каталог камер — так проще, когда камер много и они уже сидят на NVR. Но по опыту важно знать другое: когда сигнал идёт через регистратор, тот часто отдаёт не «полный» поток, а облегчённый (типичный субпоток для веба или телефона) — на экране это обычно выглядит заметно хуже, чем при прямой схеме «камера → сервер». Удобство массового импорта и качество картинки здесь часто меняются местами: адресов меньше, а «картинка как в кино» ждать не стоит, пока на стороне регистратора не настроят нормальный канал.
Видеоархив: поиск и таймлайн
Вкладка «Видеоархив»: выбор камеры и интервала, таймлайн и список клипов; что реально попало в архив, зависит от галочки «Записывать в архив» и режима записи по каждой камере.
Какие камеры пишут в архив и куда складываются файлы
Писать не обязательно все камеры сразу — у каждой записи в каталоге (Админка → Камеры, кнопка «Изменить») есть галочка «Записывать в архив». Включил её только там, где запись реально нужна — остальные не грузят диск и CPU «про запас». Ниже по той же форме задаётся режим (по событиям СКУД, по расписанию, непрерывно и т.д.) и качество — это уже про баланс «сколько крутим ffmpeg» против «сколько храним».
Камера: «Записывать в архив» и режим записи
Форма редактирования камеры: запись в архив включается отдельно для каждой камеры.
Каталог, куда складываются клипы, задаётся во вкладке «Видеоархив», блок «Настройки хранилища» — поле «Путь на сервере». Это любой каталог, который видит Linux на машине EAS: можно взять локальный диск или каталог на отдельном томе, а можно указать путь к уже смонтированной сетевой шаре (SMB/CIFS, NFS и т.п.) — если администратор ОС смонтировал ресурс, например, в `/mnt/video-archive`, то в поле пишем именно его
Лимит, ГБ — сколько места отводим под архив по сумме клипов в учёте. Циклическая перезапись: если включена, при переполнении лимита система удаляет самые старые записи, пока объём снова не укладывается в квоту — диск не раздувается бесконечно. Если цикл выключить и лимит исчерпан, новые фрагменты могут не записаться (в логах будет предупреждение) — тогда либо поднимают лимит, либо чистят архив вручную. «Предзапись» и «После события, сек» — сколько секунд «до» и «после» тянуть вокруг срабатывания СКУД по считывателям, чтобы в клип попал нужный хвост, а не одна секунда события.
Видеоархив: путь хранилища и квота
На скрине: путь на сервере, лимит в гигабайтах, предзапись/хвост после события, циклическая перезапись.
Почему "все камеры сразу" - это испытание
Когда в сетке много камер, растут нагрузка на обработку потоков, сеть и параллельные просмотры. Слабое место всплывёт: дёргается картинка, тёмные плитки, задержка, рост нагрузки на сервер. Тут помогает не «ещё одна вкладка», а замерить, урезать лишнее или разнести нагрузку — иначе снова те же цифры в `top`.
Архив и расследование
Видеоархив в EAS — не «просто склад»: по нему возвращают момент события, сверяют время и подтверждают выводы после инцидента; вместе со схемой и событиями он помогает снять спор («когда это было», «что повторяется»). Удобно, когда архив открывается из того же экрана, где вы уже смотрите проблему — не нужно «перескакивать» в другую вселенную.
Видео на объекте: нагрузка и проверки
Камера может быть «вроде рабочая», а при нескольких потоках или полной сетке давать задержки и обрывы. Смотрю не на разовый «успешный показ», а на устойчивость в повторяемом режиме. Проверка у меня простая: симптомы → одно понятное действие → снова те же условия — иначе шаг за успех не считаю.
В двух словах
Если совсем коротко: стабильное live — это не галочка в настройках, а привычка смотреть нагрузку и не обманываться. Мониторинг, сетка потоков, запасные сценарии, проверка после каждой правки — и учёт реальных ресурсов (например VM на тесте: 6 CPU, 6 ГБ ОЗУ, 25 ГБ под систему и приложения, 50 ГБ под архив). «Всё сразу» от узла, который уже честно показал сотни процентов CPU в `top`, лучше не ждать — тогда картинка перестаёт «сыпаться», а архив остаётся рабочим инструментом разбора.
Далее — датчики: как сделать так, чтобы они не просто «рисовали цифры», а помогали видеть риск и принимать решение вовремя.
После разбора «карты объекта» — как этой картой пользуются операторы, когда всё происходит в реальном времени пойдем дальше и расскажу о TV Wall.
У оператора на дежурстве задача простая: быстро понять, где проблема, и не терять время. Под это в EAS сделаны два режима:
TV Wall — постоянный визуальный контроль на пульт и большой экран;
«Схема (онлайн)» — привязка инцидентов к месту и контексту.
TV Wall: что на экране и зачем
Вкладка «TV Wall (пульт)» открывается из раздела Видеонаблюдение. Сначала показывается выбор режима — два крупных блока:
Открыть сетку — все активные камеры плитками; управление с пульта (стрелки, Enter, Back/Esc).
Открыть план — тот же план этажа, что и на «Схеме (онлайн)», в укрупнённом «ТВ-» виде: план, Проблемы, Лента, без лишних разделов админки.
TV Wall: выбор режима — сетка или план
В режиме сетки каждая плитка — одна камера: живой поток и подпись с названием. Снизу и сверху — пояснение и кнопки: «К выбору режима» (возврат к двум плиткам), «Сетка на весь экран» — убирает боковую панель и растягивает рабочую зону; в полноэкранном режиме удобно смотреть с большого экрана.
TV Wall: сетка плиток
Сетка: обзор всех камер; фокус с пульта (подсветка рамки) и Enter открывают выбранную камеру крупно.
TV Wall: сетка в полноэкранном (kiosk) режиме
Тот же режим с кнопкой «Сетка на весь экран»: скрыты меню и боковая панель, остаётся максимум полезной площади.
Клик по плитке (или Enter на выбранной) открывает одну камеру на весь блок плеера: сверху заголовок и «Назад к сетке»; ниже — поток в рамке.
TV Wall: одна камера крупно после выбора из сетки
Полноэкранный просмотр выбранной камеры; Esc/Back — обратно к сетке.
TV Wall: план (без отдельной вкладки «Схема»)
Открыть план переключает TV Wall на ту же схему, что и вкладка «Схема (онлайн)»: холст плана, масштаб, легенда, справа — Проблемы и Лента, фильтры по типу инцидентов. Это удобно, когда на посту один большой экран и нужны и камеры (через возврат к сетке), и контекст по зоне.
TV Wall: режим «План»
План с проблемами и лентой в формате TV Wall; сверху — выбор этажа и «Обновить план».
TV Wall: план в полноэкранном режиме.
План на весь экран — для ТВ без отвлечения на остальной интерфейс.
Почему такая связка работает
TV Wall даёт панораму. Схема онлайн даёт контекст.
Что происходит в обычном дежурстве
Обычно рабочее дежурство чередуется: спокойные периоды, мелкие события, иногда важный инцидент. Для разных состояний удобны разные экраны:
TV Wall — держать общую картинку;
схема онлайн — разбирать конкретную ситуацию.
Если пытаться всё делать на одном экране, получается тесно. Если TV Wall и схему развести по задачам — обзор отдельно, разбор отдельно — работать заметно проще.
Как оператор принимает решение на практике
Сначала «что-то не так», затем быстро: где, насколько критично, разовый случай или повтор. Дальше — открыть камеру, сверить с СКУД, проверить датчики. В EAS эта последовательность не разваливается на каждом шаге.
В двух словах
TV Wall и «Схема (онлайн)» закрывают разные задачи, но вместе дают рабочий темп: первая держит обзор и умеет сетку / план / полноэкран, вторая даёт полный контекст в привычной админке.
В следующей части — видео под нагрузкой: когда на отдельных камерах пропадает картинка и как обеспечивается устойчивая работа потоков.
