Мы ждем снимки из самых разных сервисных будней: инженеров на выездах, специалистов техподдержки за работой, сервисных центров, монтажей, диспетчерских, командировок, оборудования, рабочих процессов и команды. Главное — чтобы в кадре была настоящая сервисная работа.
🏆 Что можно выиграть?
🥇 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 и «Схема (онлайн)» закрывают разные задачи, но вместе дают рабочий темп: первая держит обзор и умеет сетку / план / полноэкран, вторая даёт полный контекст в привычной админке.
В следующей части — видео под нагрузкой: когда на отдельных камерах пропадает картинка и как обеспечивается устойчивая работа потоков.
Вот здесь начинается самое приземленное: не разговоры "как было бы красиво", а конкретный план, на котором нужно расставить все так, чтобы оператор этим пользовался в рабочем сценарии.
Это не абстрактная картинка, а демонстрационный план объекта из проекта EAS, на который нанесены камеры, датчики и точки СКУД.
За основу взят план из демо в проекте использовал с сайта rgsecru (по факту используется реальный план схема здания-территории объекта), а инфраструктура разложена так, как оператору удобно читать объект:
где смотрят камеры;
где стоят датчики (TVOC/температура/влажность);
где критичные точки доступа (двери/ворота/проходы).
Почему это принципиально
Потому что инцидент без привязки к месту - это половина информации. Когда событие сразу "сидит" на точке плана, становится понятно:
что рядом;
какие камеры перекрывают зону;
есть ли по этому месту тревога датчика;
были ли проходы по СКУД до или после события.
И это уже не просто "таблица событий", а полноценная картина.
Как размещены элементы на схеме
Нужна простая логика:
камеры закрывают обзорные точки и коридоры;
датчики ставятся по зонам риска (склады, бытовка, офисы);
СКУД ставится на контрольные входы.
При такой раскладке даже новый оператор за короткое время понимает объект визуально, а не по длинным спискам.
Что это дает в работе оператора
На практике оператор смотрит не "какой id у события", а:
где это произошло;
что было вокруг;
куда быстро перейти дальше.
Схема в таком виде становится рабочим инструментом, а не просто красивым фоном в интерфейсе.
План объекта с маркерами камер, датчиков и СКУД (иллюстрация размещения)
Панель вкладки «Схема (онлайн)»: что реально есть в программе
Ниже — не маркетинг, а элементы интерфейса, которые уже выведены на вкладку «Схема (онлайн)» в веб-админке:
Схема — выпадающий список этажей/планов; «Обновить план» — перезагрузить данные плана.
«Онлайн на схеме» — периодический опрос; рядом интервал (секунды) и при необходимости свой интервал (1–120 с).
«На схеме показывать» — фильтр проходов СКУД на подложке: «Все проходы», «Только допуск», «Только отказ и прочее» (именно этот переключатель часто нужен, чтобы не засорять схему «зелёными» проходами и сосредоточиться на отказах и нестандартных событиях).
«Только проблемы» — флажок: на плане и в списке остаются устройства с активными инцидентами (удобно для обхода объекта «по красному»).
«Серьёзность» — отбор списка проблем: все / Предупреждение / Критично.
Дополнительно в этой же зоне: «Звук при отказе», «Следить за событием (центр на метке)», окно тишины для звука (местное время), быстрые камеры, «Полный экран», автопереключение схем, счётчик «Отказов в сессии» с кнопкой сброса.
Справа от плана — блок «Проблемы» с быстрыми кнопками типа «Датчики» / «Камеры» / «СКУД», «Лента событий» с теми же фильтрами по типу (СКУД / Датчики / Камеры) и подсказкой, что лента учитывает текущий фильтр отображения на схеме.
Панель фильтров и режимов вкладки «Схема (онлайн)» (верхний блок карточки)
Только панель настроек над планом (без списка «Проблемы»). Здесь нет ни устройств, ни интеграций по имени — только фильтры интерфейса.
Тот же экран с включённым «Только проблемы»
Включён «Только проблемы»: на плане и справа остаются открытые инциденты по тем же типам точек, что на разметке — камеры, двери/СКУД, датчики Home Assistant. Надпись про TVOC на карточке — предупреждение по показанию через HA, это не облако MagicAir. Отдельные строки про MagicAir в «Проблемах» появляются только если в базе есть учётная запись/устройство MagicAir (`magicair_*`).
Что на этой вкладке есть кроме самой схемы
Чтобы не было ощущения "просто картинка на плане", важно отдельно назвать реализованные блоки этой же вкладки:
Проблемы — список текущих warning/critical по датчикам и точкам, с быстрым переходом к контексту и фильтром серьёзности.
Лента событий — последние изменения состояния по объекту в хронологии; фильтры СКУД / Датчики / Камеры управляют тем, что попадает в ленту.
События проходов учитываются в фильтре «На схеме показывать» и в ленте.
Именно сочетание плана с этими блоками дает рабочую картину:
на плане видно где;
в «Проблемах» видно насколько критично;
фильтры «Только проблемы» и «Только отказ и прочее» помогают сузить картину до действительно важного.
Схема онлайн: полный экран вкладки (план, проблемы, лента)
Полный вид вкладки «Схема (онлайн)»
Как читать такую схему обычному человеку
Когда оператор впервые открывает схему, ему не нужны сложные термины. Ему нужно быстро понять три вещи:
где это;
что именно там стоит;
куда нажимать, если что-то пошло не так.
Поэтому логика сделана максимально прямой:
камера = вижу картинку;
датчик = вижу текущее состояние и историю;
СКУД-точка = вижу кто проходил и когда.
Даже если оператор не "технарь", через пару минут он начинает уверенно ориентироваться.
Почему используется план объекта, а не условная картинка
Потому что план объекта сразу убирает много ошибок. На условной схеме легко перепутать зоны. На плане объекта оператор узнает помещение так, как оно выглядит в реальности.
Это особенно важно ночью и в стрессовых ситуациях:
оператор видит "тот самый коридор", а не абстрактный прямоугольник;
быстрее связывает событие на экране с реальным местом;
быстрее дает команду на месте.
Небольшой жизненный пример
Допустим, пришла тревога по датчику в зоне склада. Оператор делает по шагам:
Видит датчик на плане, понимает точную зону.
Смотрит ближайшую камеру в этой же зоне.
Проверяет, был ли проход по СКУД рядом с этим временем.
Если нужно, зовет ответственного уже с понятным контекстом.
В разрозненной схеме это обычно занимает больше времени. Когда все точки сведены в один экран, разбор идет заметно быстрее и без лишних переключений.
Почему добавлены подписи и легенда
Иногда кажется, что легенда "мешает". На практике она экономит время новым операторам.
Когда оператор видит:
цвет камеры,
цвет датчика,
метку точки доступа,
он быстрее "въезжает" в логику и меньше делает ошибочных действий.
Это мелочь, но именно из таких мелочей складывается работа без нервов.
Что было бы ошибкой и почему так не делается
Самая частая ошибка - пытаться поставить маркеры "как попало", лишь бы на плане что-то мигало. Тогда оператору кажется, что система есть, но пользы с нее мало.
Здесь работает простое правило: каждая точка на схеме должна отвечать на конкретный вопрос. Если точка не помогает принять решение, значит она там лишняя.
Простой пример правила размещения на плане:
Камера — там и под таким углом, чтобы в обзор попадало то, что нужно проверять при инциденте (подход к двери, перекрёсток коридоров, зона погрузки), а не «точка посередине комнаты ради галочки».
Датчик — в помещении или зоне, где вы действительно следите за климатом/воздухом/утечкой и т.п., то есть там, где есть риск или режим, а не там, где на чертеже симметричнее.
СКУД (дверь, ворота, считыватель) — на реальном проходе людей или транспорта, где выдаётся допуск; маркер ставят у этого прохода, а не «где удобно нарисовать» и не «рядом со столом оператора» — оператор поста к объекту может вообще не выходить.
Тогда схема превращается из "рисунка" в рабочую карту объекта.
В следующей части перейду к тому, как это работает в реальном ритме дежурства: TV Wall, схема онлайн и почему именно связка этих экранов дает скорость, а не хаос.
Всем привет, возникла проблема с приводом электрическим автоматическим для дверей dema-01-r-04-fi. установлены данные привода у нас в подъезде (г. Москва). Периодически дверь почти невозможно открыть, привод не дает, приходится прикладывать большую силу чтобы открыть. Решил сам глянуть что к чему, скачал к нему инструкцию, снял защитный кожух, там на табло моргает ошибка в виде 08, в инструкции написано что это ошибка связанная с разомкнутой перемычкой 4-4а, но она на месте.. Пытался сбросить в завод и заново настроить по инструкции - ничего не получается. (еще и табло относительно меня вверх ногами стоит). Может есть кто в Москве, кто сможет помочь?
