# UZEL X: единая система и продуктовая линейка

Рабочая карта идей от 21 сентября 2026 года.

Это сводка обсуждений и предложение по структуре продуктов. Она не подтверждает готовность перечисленных функций в текущей сборке. Существующий сайт содержит демонстрации; код основной системы и прежние архивы в рамках этой сводки не проверялись.

## 1. Главная идея

**UZEL X — платформа для разработки, управления оборудованием и локального ИИ.**

Инженер собирает проект из устройств, готовых драйверов, карточек и шаблонов, добавляет интерфейс и логику, проверяет поведение и развёртывает проект на подходящем оборудовании. Пользователь управляет пространством через панель, а инженер видит состояния, историю и причины сбоев. Локальный ИИ использует контекст этого же проекта.

Единица системы — проект, а не отдельная кнопка или аппаратная коробка.

Основные аудитории: интеграторы, разработчики систем управления, службы эксплуатации и организации с переговорными, залами и инженерными системами.

## 2. Что уже обсуждали

- Программная платформа важнее отдельного контроллера: готовые драйверы, карточки оборудования, шаблоны управления и удобный редактор.
- Designer/Studio, Runtime, отдельная браузерная панель и синхронизация состояний между панелями.
- Сцены, визуальная логика, скрипты, интеграции, проверка проекта и развёртывание.
- Learner: запись доступного обмена, отделение фона, сравнение повторений, выделение параметров, библиотека команд и черновик драйвера.
- Packet Diff, Live Trace, Replay/Virtual Device и симуляция.
- Импорт существующих проектов с отчётом о потерях, сопоставлением устройств, тегов, графики и логики.
- Каталог драйверов с паспортами совместимости, ограничениями и проверками по функциям.
- Диагностика «Почему не работает?» и история «Кто изменил состояние?».
- Теневая миграция: сравнение старой и новой системы без отправки команд новой системой.
- Замена устройства без полной переделки интерфейса и логики.
- Шаблоны комнат с индивидуальными адресами, каналами и исключениями.
- Отдельный аппаратный контроллер и конструктор конфигурации под задачи, интерфейсы и резерв.
- Meeting: запись, транскрибация и живой протокол, естественные исправления, итоги, задачи, проверка, экспорт, рассылка и история.
- Локальная обработка и Project Context: терминология, оборудование, помещения, документы, участники и история решений.

Названия CORE, Server, Studio, Panel, Local AI, Learner, Meeting и Assist перечислены пользователем как состав линейки. Границы CORE/Server/Assist ниже — рабочее предложение, а не ранее утверждённая спецификация.

## 3. Линейка

| Продукт | Предлагаемая роль | Что в него входит | Граница ответственности |
|---|---|---|---|
| UZEL X CORE | Аппаратный контроллер на объекте | Исполнение проекта, драйверы, сценарии, опрос и обратная связь, локальные интерфейсы подключения, журналы | Не редактор. Физические порты и возможность выполнения ИИ зависят от утверждённой конфигурации |
| UZEL X Server | Серверное ПО в инфраструктуре заказчика | Службы проекта, хранение и история, пользователи и права, управление несколькими помещениями, развёртывание, интеграционные API | Не требует обязательного внешнего облака. Возможность работы без CORE зависит от требуемых физических интерфейсов |
| UZEL X Studio | Рабочее место инженера | Редактор интерфейсов, устройства и теги, карточки и шаблоны, сцены, визуальная логика и скрипты, импорт, диагностика, симуляция, проверка и Deploy | Создаёт и обслуживает проект, но не должна быть постоянно открыта для управления объектом |
| UZEL X Panel | Пользовательский интерфейс управления | Управление помещениями, сценами, источниками, звуком, камерами, светом, климатом и шторами; статусы и уведомления | Клиент проекта. Отдельно уточнить программное приложение и возможную линейку физических панелей |
| UZEL X Local AI | Общий локальный сервис ИИ | Распознавание речи, анализ, поиск по проекту, работа с Project Context и предложения для прикладных модулей | Не второй бренд Meeting. Размещается локально на подходящем контроллере или сервере, по результатам проверки ресурсов |
| UZEL X Learner | Инженерная лаборатория изучения оборудования | Запись доступного обмена, фильтрация фона, Packet Diff, параметры, кандидаты обратной связи, библиотека команд, черновик драйвера | Не обещает восстановление любого закрытого или зашифрованного протокола. Результат требует проверки |
| UZEL X Meeting | Прикладной продукт для совещаний | Запись, live-транскрипция, живой протокол, решения, задачи, ответственные, сроки, естественные исправления, итоговый документ, экспорт и история | Использует Local AI; слушание разговора не даёт ему права управлять оборудованием |
| UZEL X Assist | Контекстный помощник пользователя и инженера | Вопросы о проекте, поиск в документации, объяснение состояний и сбоев, предложение сценариев и помощь с настройкой | Предлагаемая роль. Разделить консультацию, подготовку изменения и исполнение; права, подтверждения и журнал обязательны |

Написание для материалов: UZEL X CORE, UZEL X Server, UZEL X Studio, UZEL X Panel, UZEL X Local AI, UZEL X Learner, UZEL X Meeting, UZEL X Assist.

Control можно оставить названием направления «управление», а не ещё одним продуктом рядом с CORE и Server.

## 4. Общая архитектура

Это логические связи, не утверждённая схема сети и не требование отдельных физических машин.

1. Studio создаёт и проверяет проект.
2. Learner, каталог драйверов, шаблоны и импорт помогают наполнить этот проект.
3. Runtime исполняет проект на CORE или Server; распределённое исполнение требует отдельного проектирования.
4. Драйверы, шлюзы и API связывают Runtime с оборудованием.
5. Panel показывает состояния и отправляет разрешённые действия.
6. Server организует общие службы, историю, права и взаимодействие помещений в выбранной конфигурации.
7. Local AI получает разрешённый контекст проекта и обслуживает Meeting и Assist.

Runtime — общий исполнительный слой, а не девятое равноправное название на главной странице.

Базовое управление должно продолжаться при недоступности Local AI. Закрытие Studio или сбой интерфейса Panel не должны уничтожать работающие сценарии. Требования к автономности CORE при потере Server нужно зафиксировать отдельно.

## 5. Единая модель проекта

Общий контекст связывает продукты и позволяет повторно использовать результаты работы.

- Объект, здания, помещения и зоны.
- Устройства, модели, версии прошивок, подключения и подтверждённые физические связи.
- Возможности устройства: команды, параметры, единицы, диапазоны и обратная связь.
- Состояния: ожидаемое, подтверждённое, устаревшее, неизвестное, конфликтующее.
- Интерфейсы, сцены, правила, расписания и скрипты.
- Документы, схемы, терминология и материалы проекта.
- Участники, роли, разрешения и зоны ответственности.
- Совещания, решения, задачи и история их изменений.
- Журналы действий, версии проекта, результаты испытаний и отчёты ПНР.

Не все модули получают все данные. Доступ к контексту должен учитывать пользователя, проект и назначение операции. Контекст для ИИ не равен автоматическому переобучению модели.

## 6. Обычные функции управления

Их нельзя потерять за описанием ИИ и Learner.

- Включение и выключение оборудования, подтверждение готовности и контроль связи.
- Сцены «Презентация», «ВКС», «Совещание», «Завершение» и пользовательские сценарии.
- Маршрутизация источников на экраны, матрицы и зоны.
- Громкость, mute, DSP-пресеты, микрофоны и конгресс-системы.
- PTZ, zoom, stop, пресеты и автонаведение на активный микрофон при наличии соответствующего драйвера.
- Освещение, диммирование, шторы, климат и датчики через подходящие интерфейсы.
- События, условия, расписания, таймеры, блокировки и приоритеты.
- Опрос, подписки на события, таймауты, повторные подключения и аварийные статусы.
- Синхронизация нескольких панелей, ручное управление и разграничение прав.
- Журналы, уведомления, резервные копии, версии проекта и контролируемое обновление.

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

## 7. Studio, библиотека и скрипты

### Готовые сущности

Карточка оборудования объединяет понятное управление, состояния и привязки к драйверу. Шаблон комнаты добавляет типовые страницы, сценарии и требования к устройствам. Инженер задаёт адреса и локальные параметры, а не собирает одинаковую комнату заново.

### Удобный редактор

Страницы, попапы, переиспользуемые компоненты, состояния элементов, привязки к тегам и действиям, редактор сценариев, предпросмотр и проверка ссылок. Нужен переход из ошибки непосредственно к проблемному элементу.

### Логика и скрипты

Визуальная логика для типовых связей; скрипты для нестандартных алгоритмов, обработки данных, протоколов и интеграций. В прежних обсуждениях фигурировал Node-RED. Поддерживаемые языки, версии движков и доступные API следует подтвердить по коду, а не назначать в маркетинговом тексте.

Скриптам нужны ограничения ресурсов и разрешений, отладка, журналирование и отделение от критичного исполнения.

## 8. Learner и инструменты интегратора

### Понятная цепочка обучения

**Нажал кнопку → записали обмен → отфильтровали фон → сравнили повторения → нашли изменяемые поля → сохранили команду → собрали библиотеку или черновик драйвера.**

Источники примеров: Web UI, штатное приложение, KNX-панель, BUS77-панель и существующая система управления. Обязательна доступная и разрешённая точка обмена: сетевой захват, интерфейс или шлюз. Одного присутствия в той же сети недостаточно для гарантированного доступа ко всему трафику.

### Инструменты

- Packet Diff: сравнение записей, постоянных и изменяемых полей.
- Feedback: отдельно кандидат команды и кандидат подтверждения фактического состояния.
- Live Trace: путь от действия пользователя через правило и драйвер до ответа оборудования.
- Replay / Virtual Device: проверка записанных последовательностей в изолированной среде без отправки в рабочую сеть.
- Паспорт драйвера: точная модель, прошивка, функции, проверки и ограничения.
- Подсказка следующего опыта: «измени другой выход», «проверь крайнее значение», «запиши ответ физической панели».
- Замена устройства: сопоставление возможностей нового драйвера с прежней карточкой и сценариями.

В прежнем обсуждении описан прототип анализа PCAP/PCAPNG. Живой захват, полноценный Replay и произвольный бинарный разбор там не выдавались за готовые функции. Эти статусы требуют повторного аудита исходников.

## 9. Импорт и миграция

Направления из обсуждений: iRidi, Crestron, Extron, Tesira/Biamp, BUS77, KNX/ETS, Modbus-таблицы, Node-RED, CSV/XLSX и другие доступные форматы.

Важно разделять поддержку управления оборудованием производителя и импорт его инженерного проекта. Наличие драйвера не означает наличие конвертера проекта.

Процесс: открыть доступные исходники или выгрузку → извлечь структуру → показать отчёт → сопоставить устройства, теги и действия → проверить в симуляторе → принять изменения → развернуть.

Неперенесённые скрипты, закрытые драйверы, графические состояния и нестандартные элементы остаются видимыми в отчёте. Импорт не должен автоматически включать непроверенные действия.

Отдельная идея: Shadow Migration. Старая система управляет объектом, новая только наблюдает и сравнивает ожидаемое поведение. Переход выполняется по комнатам или функциям; одновременно активен один владелец управления.

## 10. Диагностика и Assist

### «Почему не работает?»

Пример: питание дисплея подтверждено; маршрут матрицы подтверждён; сигнал на входе отсутствует. Система предлагает проверить источник и соединение, не объявляя кабель неисправным без доказательств.

### «Кто изменил состояние?»

Пример: оператор задал 23 °C; расписание через 12 секунд вернуло 21 °C. История связывает инициатора, правило, команду и feedback.

### Воспроизведение неисправности

Сохранение команд, ответов, задержек и версий, затем проверка исправления в симуляторе без воздействия на оборудование.

### Assist как интерфейс к этим знаниям

Пользователь спрашивает «почему нет изображения?» или «подготовь переговорную к ВКС». Assist получает факты из системы, объясняет ситуацию и предлагает разрешённое действие.

Доступ к микрофону Meeting не является разрешением выполнять услышанные команды оборудованию. Для Assist необходим отдельный явный режим обращения и правила подтверждения. Это предлагаемая граница безопасности, которую ещё нужно утвердить.

## 11. Local AI и Meeting

**Совещание → локальная транскрибация → Project Context → Local AI → решения / задачи / протокол.**

Распознавание и анализ выполняются внутри инфраструктуры заказчика на подходящем CORE или локальном сервере. Не обещаем обработку в реальном времени на любой конфигурации: модели, ресурсы и число одновременных встреч проверяются на стенде.

Для Meeting сохраняем все ранее предложенные особенности:

- Запись с панели, телефона или аудиотракта переговорной; загрузка готового файла.
- По возможности запись с DSP, включая удалённых участников; сопоставление микрофонных каналов и мест как отдельный вариант определения говорящих.
- Основная запись независима от задержек live-анализа.
- Одновременно видны транскрипт и живой черновой протокол.
- Естественные исправления без кодовой фразы: «Нет, это делает Антон, не Сергей».
- Различение предложения, обсуждения и согласованного решения.
- Обновление и отмена пунктов вместо накопления противоречащих записей.
- Ссылки из пунктов на цитату и время записи; неназванные ответственные и сроки не придумываются.
- Решения, задачи, открытые вопросы и риски.
- После встречи: сверка по полной записи, учёт исправлений и проверка человеком.
- Экспорт, архив, поиск, история решений и незакрытые задачи предыдущих встреч.
- Рассылка после проверки содержания и получателей; локальная обработка не означает, что последующий экспорт в облачную почту тоже остаётся локальным.
- Явное начало записи, индикатор, пауза и настраиваемые сроки хранения.

Общий акцент: **LOCAL AI · Данные остаются внутри системы.** Для этой формулировки должны быть определены границы системы и режим внешних интеграций.

## 12. Подбор конфигурации

Нужен конструктор решения, а не произвольная цена за коробку.

Входные данные: тип объекта, число помещений, перечень функций, количество и типы интерфейсов, шины и шлюзы, резерв, панели, требования к записи, локальному ИИ, хранению и автономности.

Результат: состав ПО, требования к CORE/Server/Local AI, перечень интерфейсов, необходимые шлюзы, ограничения, открытые вопросы и выгружаемое задание.

Пока нет утверждённых моделей, характеристик и цен, конструктор не выдаёт вымышленный артикул или стоимость. Текущий конструктор сайта уже формирует требования к задачам, портам и резерву, но не рассчитывает реальные аппаратные модели.

Примерные сценарии комплектации:

- Управление одной комнатой: Studio + подходящее исполнение Runtime + Panel + драйверы.
- Несколько помещений: CORE по потребности, общие службы Server, несколько Panel.
- Локальные совещания: Meeting + Local AI + запись и хранение; подключение управления помещением необязательно для первого пилота.
- Модернизация объекта: Studio + Learner + Migration + тестовая среда.

## 13. Структура нового сайта

Главная должна называться UZEL X и показывать всю систему. Control не должен подменять собой всю линейку.

### Первый экран

Заголовок: **UZEL X**.

Описание: **Платформа для разработки, управления оборудованием и локального ИИ.**

Короткая конкретизация: **Соберите проект из драйверов и шаблонов, запустите его на контроллере или сервере и управляйте пространством через панели и контекстные сервисы.**

Первый экран объясняет кому нужен продукт, что инженер создаёт и где проект работает. Визуально показывается один сквозной проект, а не восемь независимых рекламных обещаний.

### Группы навигации

- Система: CORE, Server, общая архитектура.
- Разработка: Studio, Learner, драйверы и шаблоны, импорт.
- Управление: Panel, сценарии и диагностика.
- Локальный ИИ: Local AI, Meeting, Assist.
- Подбор решения: конструктор требований.

На главной достаточно трёх коротких разделов после первого экрана: состав системы; сквозной сценарий; выбор решения. Подробности уходят на страницы продуктов.

### Страница продукта

Одинаковый порядок: что это и кому нужно → одна содержательная демонстрация → ключевые возможности → с чем работает → ограничения и статус → следующий шаг.

Навигация не должна превращаться в ряд из десяти названий. Существующие переходы на Meeting и конструктор сохраняются. Выбранный пользователем объёмный логотип остаётся общим для всех страниц.

Визуальный принцип: компактный инженерно-архитектурный стиль, читаемая типографика, изолированные демо-контейнеры, проверка 1440/1280/1024/768/390 px, без наложений и горизонтальной прокрутки.

## 14. Что нужно зафиксировать перед обещаниями на сайте

1. CORE — только аппаратная линейка или ещё название программного ядра? Рекомендация этой карты: аппаратная линейка, ядро называется Runtime.
2. Server — самостоятельное исполнение проекта, управление парком CORE или оба режима? Какие ограничения при работе без CORE?
3. Panel — приложение для существующих устройств, собственная физическая панель или оба варианта?
4. Assist — инженерный помощник, пользовательское голосовое управление или два режима одного продукта?
5. Какие драйверы, импортеры, языки скриптов и модели аппаратуры подтверждены текущим кодом и реальными испытаниями?
6. Что уже можно выдать пользователю, что является прототипом, а что остаётся концепцией?

Для функций нужны статусы «проверено в указанной версии», «прототип», «в разработке», «концепция». Список брендов и протоколов не заменяет перечень реально проверенных устройств.

## Источники этой сводки

- Текущее обсуждение сайта: уточнения о драйверах, шаблонах, редакторе, отдельном контроллере, конструкторе и локальном ИИ.
- [Создание сайта UZEL X](chatgpt-conversation://6aac1f92-d820-83eb-bb93-0ac8a15fca24): позиционирование, Learner и Meeting.
- [Продолжение разработки системы](chatgpt-conversation://6aa8ca80-144c-83ed-9727-b8b75e402a4b): Studio/Runtime/Panel, Integration Lab, Migration, диагностика, локальные совещания и естественные исправления.

Границы продуктов и структура сайта в разделах 3, 4 и 13 — предложение по систематизации найденных идей, а не утверждение о ранее согласованной спецификации.