Koobique связывает измерения, модель физического объекта и управляемое действие. Первый проверяемый контур работает в одном кабинете.

Человек входит в кабинет. При разрешённой автоматике датчик фиксирует движение, станция проверяет свежесть наблюдений и освещённость, выбирает светильник, отправляет команду релейному узлу и проверяет сообщённый результат. Физический эффект подтверждается отдельно. В голосовом расширении человек говорит «выключи подсветку»: система отличает её от основного освещения и уточняет неоднозначный объект. Локальное управление сохраняется без интернета. При недоступной станции физическая кнопка исполнительного узла продолжает работать в пределах своего питания и локального режима.

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

Рассмотреть схему

Состав первого комплекта#

Станция Koobique Hub — отдельный Linux-компьютер, преимущественно подключённый к домашнему роутеру по Wi-Fi. На нём работают Rust-ядро, локальное хранилище, службы управления и, когда выбрана подходящая конфигурация, обработка голоса. Ethernet сохраняется как дополнительный интерфейс. Приложение не требует переключать телефон в отдельную сеть станции.

Sense — узел освещённости и температуры. Для первого стенда это отладочная плата ESP32-C6 и готовые сенсорные модули. Сенсоры располагаются вне горячего вычислительного корпуса. В дальнейшем температурный и оптический каналы можно разделить, если одной точкой установки не удаётся корректно измерять обе величины.

Presence — узел присутствия. Начальный вариант использует PIR, расширенный — PIR и радар. Это не устройство определения личности и не достоверный счётчик людей: система хранит оценку занятости комнаты с понятными ограничениями.

Actuator — исполнительный узел с физической кнопкой и реле. Первая нагрузка — низковольтный светильник 12 В. Измерение тока добавляется отдельным этапом. Работа с открытыми сетевыми цепями 230 В не нужна для проверки архитектуры и не входит в предлагаемый учебный стенд.

Koobique App — пользовательский клиент; целевое мобильное приложение строится на KMP для Android и iOS. Оно подключает станцию и устройства, показывает состояние, передаёт намерения и может служить голосовым пультом. Клиент обращается к API Core. KQIP описывает отдельную связь Core с узлами; общий формат данных не означает общий набор полномочий. Платформенные библиотеки выбираются после проверки на реальных телефонах.

Три понятия, которые нельзя смешивать#

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

Что означает «готово к первому экземпляру»#

Эта книга задаёт инженерную основу, сравнение деталей, схемы соединений, расчётные примеры и программу проверок. Она не выдаёт предполагаемую совместимость за испытанную. До заказа окончательных панелей необходимо измерить реальные компоненты; до переноса релейного узла с макета на плату — проверить электрическую схему; до использования постоянного автономного управления — прогнать отказные сценарии.

В тексте используются три вида утверждений. Документированный факт сопровождается ссылкой вида [14]. Проектное решение описывает предложенную архитектуру Koobique. Расчёт или цель опирается на явно названные исходные данные и ещё требует измерения. Это позволяет менять детали, не разрушая логику системы.

Первое практическое решение#

Не покупать всю станцию сразу. Сначала запустить ту же серверную архитектуру на имеющемся ПК и собрать три низковольтных узла. Отдельный вычислитель выбирается после измерения нагрузки и голоса. Это не упрощённый «одноразовый прототип»: формат сообщений, модель устройств и проверка прав остаются теми же.

Как устроена эта книга#

Сначала мы проследим один сценарий кабинета и разберём устройство станции. Затем соберём корпус, питание, измерительные и исполнительные узлы. После этого пройдём программный путь от загрузки Linux и прошивки микроконтроллера к протоколу, данным, моделям и решениям. Приложение, голос, обновления и испытания замыкают эту цепочку.

Для последовательного изучения сохранены все 51 глава. Во время сборки удобно идти по маршруту E0 и возвращаться к монтажным картам, расчётам и проверкам. Разработчику Core/MCU и исследователю данных доступны собственные маршруты через те же полные главы. Учебные источники собраны в конце книги. Проектные размеры и настройки сверяются с приобретёнными деталями перед изготовлением.

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

Профиль E0 — одна комната, один активный Core, один владелец, измерение температуры и света, PIR-only и одна низковольтная лампа. Успех означает: свет можно предсказуемо включить, ручное решение не отменяется само, отказ виден, а после перезапуска есть понятный путь восстановления. Пакеты процессов, голос, радар и AI остаются в книге, но не становятся обязательными зависимостями этого первого результата.

«Зафиксировано проектом» в этой редакции означает выбранное поведение, а не проведённое испытание. Нормативные пункты E0, примеры и будущие варианты визуально разделены. Для замены компонента не требуется переписывать всю книгу, но требуется заново пройти затронутую проверку.

Физический цикл: Sense → State → Model → Decision → Act#

Sense получает наблюдение с временем, единицей и качеством. State сохраняет то, что сейчас известно об объекте, включая пропуски и неопределённость. Model описывает связи и ожидаемый эффект действия. Decision выбирает разрешённое намерение с учётом цели и ограничений. Act проверяет условия, исполняет команду и возвращает результат, который следующий Sense сопоставляет с физическим миром. В E0 некоторые шаги выполняет простой автомат; отдельная нейросеть для каждого шага не требуется.

Устройство отвечает за безопасный выход, станция — за координацию, приложение — за намерение пользователя.

worker — отдельный вычислительный помощник · ManualOverride — ручной режим; E0 сохраняет его до явного освобождения, временный lease относится к расширению E1 · snapshot — согласованный снимок состояния

Сервер не должен быть единственным местом, где известно, как выключить реле. Приложение не должно быть единственным местом, где хранится расписание. Датчик не должен решать, какой светильник считается основным в комнате. Такое разделение не только упрощает код: оно ограничивает последствия сбоя каждого узла.

Рассмотреть схему

Три уровня исполнения#

На микроконтроллере выполняются опрос датчиков, работа с контактами, ограничение длительности действия, физическая кнопка и заранее согласованный режим потери связи. Сеть может задержаться, но кнопка не должна ждать сетевой mutex. Локальная защита имеет приоритет перед командой сервера.

Станция хранит состав комнаты, роли пользователей, автоматизации и историю решений. Она объединяет наблюдения, выбирает действие и следит за выполнением. Linux предоставляет процессы, память, драйверы и сеть; собственная платформа Koobique отвечает за смысл физической системы, а не заменяет ядро Linux.

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

Возможности вместо жёстких классов#

Устройство описывается набором функциональных каналов. Один узел может иметь temperature, illuminance, button и relay; другой — только occupancy. Для каждого канала нужны тип величины, единица, диапазон, доступные команды, частота или режим обновления, качество данных и версия описания.

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

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

Слои состояния системы#

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

Приоритеты и конфликтующие решения#

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

Ручное действие создаёт ManualOverride на исполнительном узле. В E0 режим сохраняется до явного действия «Вернуть автоматику»; обычное правило его не снимает. Временный lease с видимым сроком можно добавить в E1 после отдельного определения часов и поведения при перезапуске. Для будущей опасной нагрузки локальное ограничение максимального времени включения задаётся независимо от ручного режима. Для лампы рабочего стола потеря датчика сама по себе не отменяет явно включённый свет.

Один процесс ядра, несколько изолированных служб#

Предлагается модульный Rust-монолит для реестра, состояний, политик и исполнения. Голосовой вывод, распознавание речи и потенциально нестабильные адаптеры работают отдельными процессами. Они получают ограниченные ресурсы и не владеют выходами напрямую.

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

Когда система растёт#

Следующие десять устройств добавляются через тот же реестр и протокол. Следующая комната добавляет область действия правил. Второй пользователь — отдельную идентичность и права. Второй хаб не должен автоматически становиться равноправным управляющим тем же реле: сначала требуется протокол передачи полномочий, иначе два восстановленных из копии сервера начнут бороться за выход.

Для первых экземпляров выбираем одну активную станцию на инсталляцию. Резервная копия предназначена для восстановления, а не для создания параллельного хозяина. Управляющий epoch и привязка к владельцу позволяют устройству отвергать старый контроллер после переноса.

Проверка архитектуры до корпуса#

На ПК запустить ядро и симулятор Actuator. Отключить клиент: правило продолжает работать. Остановить голосовой worker: ручные команды работают. Оборвать соединение с узлом: результат команды становится неизвестным, а не ложно успешным. Вернуть старый snapshot: он не становится свежим измерением.

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

Три архитектуры и осознанный выбор#

Самый короткий путь — отправлять все показания и команды пользователя в языковую модель, а ответ превращать в вызов устройства. Такой прототип впечатляет гибкостью, но связывает физическое действие с качеством текста, полнотой контекста и временем ответа. Отказ одного большого компонента становится отказом всей автоматизации.

Противоположный путь — конечные автоматы и жёсткие правила. Он хорош там, где ситуация исчерпывается несколькими состояниями. Для первого реле это необходимая основа. Но каждый новый тип помещения и исключение постепенно увеличивают число правил; понимание произвольной речи и адаптация к неизвестной лампе не появляются сами.

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

Рассмотреть схему

Что означает «операционная система»#

Linux остаётся операционной системой вычислителя: загружает драйверы, распределяет память, запускает процессы. Koobique Core / физическая платформа — предлагаемое имя прикладной системной среды над Linux. Она распределяет доступ к физическим объектам, времени измерений, моделям и исполнительным устройствам. Это смысловой аналог ОС для физических процессов, а не заявление о написании собственного планировщика CPU.

В обычной ОС файл имеет имя и права. В Koobique физический объект имеет тип величины, расположение, источники наблюдения, допустимые воздействия и условия доверия. Потребность «освещение рабочего места» связывается не с произвольным реле, а с конкретным светильником и проверенным влиянием на выбранную плоскость измерения.

Пять разных документов о реальности#

Каждая запись получает собственный тип, происхождение и срок применимости. Оценка может ссылаться на наблюдения, прогноз — на модель и начальное состояние, действие — на разрешение. Преобразование между типами выполняется явно. Нельзя записать предсказанную температуру в канал настоящего датчика.

Контуры с разной скоростью#

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

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

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

Компоненты системы и области версионирования#

Сравнивать две голые ревизии недостаточно. Выход «39» из другой загрузки не продолжает прежнюю последовательность «38». Переименование лампы не меняет её физический канал; перенос датчика меняет размещение; смена хаба меняет доверие. В интерфейсе эти детали скрыты за понятными последствиями, но в журнале они сохраняются.

Процессор выбирают по результатам испытания совместной нагрузки. Маркировка «готов к AI» сама по себе не подтверждает пригодность для этого режима.

GPIO — программно управляемый цифровой вывод

Для температуры и реле не требуется мощная машина. Для локальной речи, акустической обработки, многопользовательского интерфейса и экспериментов с моделями ресурсов нужно больше. Покупать ускоритель до выбора модели рискованно: рекламное число TOPS не отвечает на вопрос, поддерживается ли нужный оператор, формат квантования или runtime.

Рассмотреть схему

H0. Имеющийся мощный ПК#

Это лучший первый стенд программной архитектуры. Linux можно установить на отдельный накопитель или использовать отдельную среду разработки; доступ к USB, аудио и Wi-Fi должен быть реальным, а не только эмуляцией. Виртуальная машина полезна для серверной логики, но её сетевые и аудиозадержки нельзя выдавать за характеристики будущего хаба.

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

H1. Готовый мини-ПК x86#

Плюсы: готовое питание, охлаждение, корпус, доступный SSD, привычная Linux-среда. Это короткий путь к автономной станции. Недостатки: нестандартная плата, ограниченный BIOS, сложное обслуживание отдельных узлов и часто непредсказуемая замена Wi-Fi-модуля между партиями.

Для подбора достаточно начать с класса современного 6–8-ядерного мобильного x86-процессора, 32 ГБ RAM и NVMe, но эти цифры — проектный ориентир, не доказанный минимум. Перед покупкой важнее получить точное имя CPU, PCI ID радио, возможность загрузки Linux, сведения о RAM и настройку восстановления питания. Модель с 16 ГБ тоже может оказаться достаточной после измерений.

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

H2. Mini-ITX — основа разборного куба#

Это наиболее прозрачный путь для самостоятельной механики. Плата, процессор, память, SSD, блок питания и вентиляторы выбираются независимо. За эту свободу приходится платить проектированием креплений, кабельных зазоров, радио и питания.

Документированный ориентир — Ryzen 7 8700G: 8 ядер, 16 потоков, номинальный TDP 65 Вт, встроенная графика и AM5. Его паспорт не является паспортом всей станции: потребление системы, шум, длительная частота и скорость конкретной speech-модели ещё измеряются. Пример платы — ASRock B650I Lightning WiFi; список поддерживаемых CPU и требуемый BIOS проверяются отдельно от старого PDF-руководства. [1][2][3]

Для первых экспериментов разумны 2 × 16 ГБ DDR5 без разгона и SSD 1 ТБ. Переход на 64 ГБ полезен, если реальные модели или наборы данных не помещаются; покупать память «на всякий случай» вместо проверки голоса не нужно. Встроенная графика не гарантирует ускорение любого ML-runtime. CPU-режим должен оставаться работоспособным базовым путём.

H3. Raspberry Pi 5#

Pi 5 даёт компактную ARM-плату, GPIO и большую экосистему. Она подходит для локального управления, измерений и проверки небольших голосовых моделей. Документация описывает питание 5 В и особенности допустимого тока USB, а также PCIe-подключение периферии; накопитель и охлаждение нужно выбирать как согласованный комплект. [8][9]

Недостаток — меньший запас для тяжёлой речи и свободного диалога. Модель, которая комфортно работает на мощном ПК, может оказаться неприемлемой на Pi. Для базы предпочтительнее SSD, а не бесконтрольная запись телеметрии на microSD. Официальные механические файлы полезны для корпуса, но также должны соответствовать ревизии платы. [88]

H4. Jetson и другие платы с ускорителем#

Jetson Orin Nano Super интересен, когда выбранный вычислительный путь действительно использует поддерживаемый NVIDIA стек. Тогда компактная GPU-платформа может быть удобнее дискретной видеокарты в кубе. Ограничения — общий объём памяти, конкретная версия системного образа, совместимость моделей и зависимость от набора драйверов производителя. [10]

Другие ARM-платы с NPU сравниваются по тому же правилу: нужен работающий пример нашей модели, а не абстрактный тест. Проверяется преобразование модели, поддержка операций, лицензия, восстановление после ошибки и параллельная работа с аудио. Закрытый драйвер — эксплуатационная зависимость, даже если сам Koobique написан на Rust.

H5. Небольшой хаб и отдельный вычислительный worker#

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

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

Четыре профиля вычислений#

Это функциональные профили Koobique, не сертифицированные классы производительности. Конкретные RAM, VRAM и мощность выбираются после фиксированного набора моделей и тестов. Наличие NPU в описании компьютера не подтверждает поддержку нужных операторов.

Память модели: простой нижний ориентир#

Если модель имеет $N$ параметров по $b$ бит, только веса занимают примерно $Nb/8$ байт. Условные 3 млрд параметров по 4 бита — 1,5 ГБ до метаданных квантования, активаций, кэшей, рабочих буферов и среды исполнения. Нельзя по этой формуле обещать, что вся модель поместится в устройство с 2 ГБ памяти.

Для потокового звука, нескольких сессий и GPU дополняем бюджет измеренными пиками. Время первого запуска и прогретого выполнения фиксируем отдельно. Диск может быть быстрым, но подгрузка модели всё равно создаёт задержку; частое переключение нескольких крупных моделей сравниваем с постоянной загрузкой одного небольшого сервиса.

Рассмотреть схему

Механика куба остаётся актуальной#

AI добавляет к корпусу новые тепловые режимы: простой, постоянную обработку речи, короткий пик и длительное обучение. Их проверяют отдельно на выбранной плате и конструкции, разобранной в главах 5–9. Одна цифра TDP не заменяет испытания собранного куба.

Микрофон и измеритель температуры выполняют разные задачи. Микрофон может находиться в акустически выбранной части корпуса; комнатный термосенсор не должен измерять тёплый выхлоп. Радиоантенны сохраняют отдельные требования к металлическому корпусу.

Увеличение мощности может потребовать другой блок питания, воздушный канал или отдельный вычислительный модуль. Но покупать весь комплект «на будущую универсальную модель» до проверки архитектуры не требуется.

Небольшой хаб или единый мощный куб#

Единый компьютер проще в настройке и не зависит от второго устройства, но объединяет тепло, шум и конкуренцию за ресурсы. Хаб плюс worker позволяет исследовать тяжёлые модели на имеющемся ПК, но требует защищённого локального протокола задач и корректной деградации. Несколько станций увеличивают покрытие, но создают проблему единственного владельца исполнительного ресурса.

Для первых экземпляров предлагается сначала хаб/логический core и worker на одном ПК с разными процессами. Затем core переносится в выбранный куб; граница уже проверена. Монтаж устройств и пользовательский сценарий от этого не меняются.

Работоспособность сборки определяется стыками: сокет, BIOS, память, охлаждение, питание, драйвер и механика.

У двух деталей может быть один подходящий разъём и всё же не быть совместимости. CPU помещается в сокет, но не поддерживается текущим BIOS. Wi-Fi-карта физически подходит в M.2, но требует отсутствующего интерфейса. SSD получает питание, но перегревается под соседним радиатором. Поэтому ведомость компонентов должна содержать не только названия, но и основание совместимости.

Опорная сборка H2#

Паспорт NH-U9S и руководства платы нужны именно для геометрической проверки, а не для обещания универсальной совместимости. У рассмотренной платы руководство указывает допустимую нагрузку до 2 А / 24 Вт для перечисленных CPU/WP и chassis/WP headers; переносить это число на другую плату нельзя. [3][5]

У SF750 большой запас мощности относительно планируемой конфигурации без дискретной GPU. Это пример документированного SFX-формата, а не требование покупать 750 Вт. Выбор меньшего БП определяется реальной конфигурацией, качеством и доступностью разъёмов; экономия на номинале не должна приводить к сомнительному источнику питания. [7]

Как распределить память#

Вместо требования «ядро обязано занимать 64 МБ» задаём отдельные бюджеты. Rust-core имеет ограниченные очереди и контролируемый кэш. База ограничивает объём выборок. Speech-worker получает собственный предел памяти. Ускоритель, если он использует общую RAM, учитывается как конкурент остальных процессов, а не как бесплатный ресурс.

Пример планирования для 32 ГБ: ОС и службы получают несколько гигабайт резерва; собственное ядро и БД — отдельный измеряемый бюджет; основная часть остаётся моделям и файловому кэшу. Это не статическое разбиение памяти и не гарантия конкретной модели. Политика должна выдерживать пиковое переподключение узлов одновременно с запуском STT и резервным копированием.

Вытеснение голосового worker лучше, чем вытеснение единственного процесса управления. Но корректнее не доводить систему до OOM: ограничить число одновременных inference-запросов, отклонять лишние с понятным ответом и заранее загрузить часто используемую небольшую модель.

CPU, GPU и NPU: какой тест нужен#

Для каждого backend сохраняются имя модели, хеш весов, формат квантования, runtime, число потоков, входное аудио, время первого ответа, длительность полного распознавания и пиковая память. Проверяется русский и английский корпус команд, а не только английская демонстрационная фраза.

Современные проекты вывода предлагают разные ускорители. Например, whisper.cpp документирует несколько CPU/GPU/NPU-путей, но перечень в README не доказывает, что конкретная плата и версия драйвера подходят нашему профилю. Именно поэтому аппаратный выбор привязан к воспроизводимому прогону. [61]

Проверки при получении комплектующих#

Плата фотографируется с маркировкой ревизии и разъёмов. Записываются версия UEFI, серийный номер SSD и идентификаторы радио. Выполняется загрузка Linux с последующей проверкой сети, USB-аудио, температуры и восстановления после обычного выключения. Затем запускаются нагрузка CPU и диска, несколько последовательных перезапусков и копирование большого файла с проверкой хеша.

Не следует начинать с разгона, undervolt или отключения защит ядра ради красивой задержки. Сначала нужен воспроизводимый штатный режим. Изменение лимитов питания выполняется по одному параметру и сопровождается повторным тепловым и функциональным испытанием. Аппаратные уязвимости и их mitigations являются отдельным фактором безопасности; их нельзя молча выключать в «оптимизированном образе». [87]

Карточка совместимости#

Для каждой пары «плата—CPU», «плата—RAM», «плата—Wi-Fi», «CPU—кулер», «плата— корпус» сохранить ссылку, ревизию, проверенный факт и результат стенда. Если ячейка основана только на предположении продавца, статус остаётся «проверить», даже когда остальные детали уже куплены.

Дополнительные устройства хранения и питания#

Имеющийся внешний SSD полезен для резервных копий, аудиокорпуса и переноса образов. Для постоянной системной БД внутренний накопитель уменьшает риск случайного отсоединения. USB-адаптеры NVMe отличаются контроллерами, охлаждением и поведением при сбое — внешний диск не становится ненадёжным по определению, но требует собственного теста.

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

Ресурсный бюджет сервера#

Бюджет станции состоит из рабочего набора Core, БД, сетевых буферов, ОС, модели речи и временных пиков. Для голоса полезно сравнивать не только размер файла весов, но и максимальную RAM/VRAM, время загрузки, real-time factor и задержку первой пригодной гипотезы.

Если десятисекундный фрагмент обрабатывается за четыре секунды, RTF = 0,4. Это не означает ответ через 0,4 секунды: добавляются окончание фразы, очередь, разрешение намерения и исполнение. Если система одновременно записывает историю и обновляет модель, повторяют тот же тест под этой нагрузкой.

Рабочий набор собственного ядра измеряется отдельно от файлового кэша Linux. Результат хранит версии BIOS, ядра, драйвера, runtime, модели и способ квантования. Без этого сравнение Ryzen, Pi и Jetson не воспроизводится.

Файл модели, рабочая память и задержка — разные величины#

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

Четыре вентилятора и три разъёма#

В руководстве B650I Lightning WiFi указаны два CPU/WP и один CHA/WP — всего три разъёма. Три корпусных вентилятора плюс кулер нельзя считать четырьмя независимо наблюдаемыми каналами. Разветвитель обычно возвращает только один тахосигнал. Варианты: уменьшить число вентиляторов, принять групповое управление с явно неполной диагностикой или поставить документированный контроллер с отдельными таховходами. Проверяются ток каждого порта и суммарный пусковой ток. [3]

Модель Wi-Fi-чипа определяем по PCI/USB ID и реально загруженному драйверу, а не по ссылке на Intel в книге. Для встроенной графики также проверяется конкретный backend модели; наличие Radeon не является обещанием поддержки ROCm. Перед выбором H2 нужно сравнить CPU, Vulkan и доступные официально поддерживаемые ускорители на одном наборе задач.

Практический результат должен звучать как проверенное условие: «эта конфигурация обрабатывает такой набор команд при такой нагрузке». Из размера файла или рекламного числа операций в секунду такой вывод не следует. Поддержка ускорителя в runtime также не означает, что все операции выбранной модели выполняются на нём; это проверяется профилем исполнения. [144]

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

Для самостоятельной сборки удобнее разборная рама, чем цельный сложный корпус. У неё понятные базовые плоскости, заменяемые панели и возможность исправить одну деталь, не печатая всё заново. Опорный вариант Koobique — куб на профиле 2020 с металлическим поддоном платы, съёмной передней фильтрующей кассетой и радиопрозрачной зоной для антенн.

Рассмотреть схему

Параметрическая система координат#

Примем наружную грань рамы 320 мм, профиль 20 × 20 мм. Внутренний чистый размер между профилями — 280 мм. Ось X направлена вправо, Y — от передней панели к задней, Z — вверх. Начало координат находится на наружном переднем левом нижнем углу рамы. Внешние панели толщиной 2 мм увеличат габарит примерно до 324 мм; ножки и антенны учитываются отдельно.

Для конкретной схемы стыковки можно использовать четыре поперечины длиной 320 мм и восемь отрезков 280 мм. Полноразмерные элементы идут вдоль X на передней и задней гранях верхнего и нижнего квадратов; боковые горизонтальные и четыре стойки вставляются между ними. Эта ведомость не подходит автоматически для других уголков, скрытых соединителей или профиля с иной геометрией.

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

Реальная укладка Mini-ITX#

Плата Mini-ITX имеет собственную монтажную систему координат. Её задние I/O сначала совмещают с фактической плоскостью I/O shield; от неё откладывают глубину 170 мм. Прежний условный прямоугольник Y = 130…300 нельзя использовать как монтажную базу при задней панели Y = 320: он создаёт около 20 мм колодца. X, Z, стойки и вырез утверждаются только по конкретной плате и штекерам.

Процессорный кулер высотой 125 мм над верхней плоскостью CPU оставляет запас до крыши только после учёта высоты сокета и платы. Его координаты определяются фактическим сокетом, а не центром материнской платы. Область вокруг RAM, VRM и крепёжной рамки проверяется в 3D и затем физически. Файлы размеров производителей полезнее усреднённого «кубика процессора». [3][5]

SFX можно исследовать в нижнем отсеке как объём порядка 125 × 100 × 63,5 мм, но его вентилятор должен иметь отдельный незагороженный вход по чертежу модели. Положение Z = 30…94 при поддоне Z ≈ 105 оставляет лишь около 11 мм над БП и не утверждается как пригодное. Предпочтительный макет: собственный вход БП снизу/сбоку и независимый выход назад; ориентация и зазор подтверждаются до резки. Перед модульными разъёмами резервируется отдельный объём для штекеров, выхода и допустимого изгиба родных кабелей. Габарит корпуса SFX без этого объёма не задаёт монтажную оболочку; её проверяют по выбранной модели и макету жгута.

Рассмотреть схему

Расположение вентиляторов#

Два 120-мм вентилятора с центрами X = 160, Z = 90 и 230 геометрически помещаются на раме, но нижний проём Z = 30…150 пересекает поддон около Z = 105. Эти координаты сохраняются как эскиз фасада, не готовый воздушный тракт. В рабочем макете поддон получает проверенный канал/вырез либо нижний вентилятор переносится. Доли потока по одной площади рассчитать нельзя: нужны сопротивления обеих ветвей и измерение. [4]

Задний вентилятор предлагается поставить в верхней зоне, например с центром X = 160, Z = 235 мм. Его нижняя кромка не должна перекрывать I/O shield. Это проверяется по фактической высоте платы и выступам штекеров. Если места нет, не следует сдвигать плату вслепую: возможны верхняя вытяжка, боковой 120/140-мм вентилятор или увеличение корпуса.

Доступ, который стоит заложить сразу#

Фильтр извлекается снаружи без снятия материнской платы. Кнопка питания и отдельная кнопка сопряжения различаются на ощупь. Сервисный USB и индикатор диагностики доступны сзади либо под небольшим лючком. Крепёж панели имеет удержание или хранится в подписи на детали; выпадение винта на работающую плату недопустимо.

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

Альтернативы корпуса#

Компактная оболочка для мини-ПК проще: собственная рама несёт готовую машину, USB-модуль и фильтр. Штатный кулер не переделывается, но добавленная оболочка проходит отдельный тепловой тест.

Цельный печатный корпус оправдан для Pi или небольшого хаба. Большой куб выгоднее разбить на угловые стойки, панели и кассеты. Это снижает риск деформации длинной печати и позволяет заменить одну функциональную часть.

Куб с GPU — другая компоновка. Длину видеокарты, питание и радиус кабелей нельзя считать уже учтёнными в 320-мм варианте. Для неё создаётся отдельная конфигурация CAD, например с увеличенной гранью, а не незаметное расширение ведомости того же корпуса.

До заказа металла#

Из картона или дешёвой печати собрать полноразмерные объёмы платы, БП, кулера и вентиляторов. Добавить реальные кабели. Проверить вынимание фильтра, SSD и платы. Только после этого выпускать панели в металл. Такое испытание быстрее исправляет компоновку, чем окончательная фрезеровка.

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

Для рамы 320 мм и наружной панели 2 мм используется учебный контур 324 × 324 мм. Координаты этой панели локальные: начало в её нижнем левом углу. Центры двух вентиляторов относительно панели — (162; 92) и (162; 232) мм. Смещение на 2 мм относительно рамы учитывает наружный размер панели.

Рассмотреть схему

Для межосевого квадрата 105 мм получаются восемь отверстий вентилятора: X = 109,5 и 214,5 мм; нижние Z = 39,5 и 144,5 мм; верхние Z = 179,5 и 284,5 мм. Диаметр 4,5 мм показан только как пример проходного отверстия под выбранную схему M4. Самонарезающий винт вентилятора, резиновое крепление и резьбовая вставка требуют другой детали соединения. [4]

Круглые проёмы диаметром 116 мм — исходная геометрия для примерки. Они не являются обязательным паспортным размером любого 120-мм вентилятора. Проверяются сечение входа, доступ к винтам, решётка, виброразвязка и отсутствие контакта лопасти при деформации. Защитная решётка и фильтр остаются отдельными элементами, их нельзя забыть при оценке сопротивления.

Крепления к раме можно расположить по центрам лицевых пазов, около 12 и 312 мм от края панели в принятой системе. Реальная геометрия T-гаек, уголков и торцевых соединений определяет окончательные отверстия. Панель предварительно накладывается на собранный каркас и проверяется без усилия.

Допуски и сборочные зазоры#

Предположим, рама по одному размеру получилась 320,0 ±0,3 мм, а паз кассеты напечатан с отклонением ±0,4 мм. Если назначить нулевой номинальный зазор, худшее сочетание даёт натяг до 0,7 мм. Это арифметический пример, не гарантированная точность конкретного производства.

Для скользящей кассеты сначала печатают короткую пробу с несколькими зазорами и проверяют её после охлаждения и отделки. Выбранный зазор зависит от длины направляющей, материала, ориентации слоёв, покрытия и ожидаемой температуры. Универсальная фраза «добавить 0,2 мм» не заменяет такой купон.

Один размер не должен одновременно базировать деталь по всем осям через несколько жёстких креплений. Дополнительные крепления могут иметь продолговатые отверстия, позволяющие компенсацию и не требующие изгиба панели. Базы обозначаются на чертеже: откуда отсчитывается отверстие и какая грань действительно задаёт положение.

Для гибки металлической панели учитываются радиус, толщина и нейтральный слой. Развёртку получают из подтверждённых параметров исполнителя или пробного гиба. Отдельная плоская панель на профиле проще для первого куба именно потому, что убирает эту неопределённость. [13]

Компоновочный выпуск после примерки#

Сохранённый DXF фасада — шаблон рамы и вентиляторов, не разрешение изготавливать весь корпус. В рабочий выпуск входят четыре независимых подтверждения: доступ штекеров к I/O; сечение воздушных каналов после установки поддона; вход и выхлоп БП; траектория извлечения фильтра и SSD. Ни одно из них нельзя заменить красивым общим видом.

Условия работы каждой детали определяют выбор материала. Внешний вид образца дополняет проверку температуры, нагрузки и способа изготовления.

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

Рассмотреть схему

Металлический вариант#

Алюминиевые панели порядка 1,5–2 мм являются стартовым ориентиром для небольшого разборного корпуса, но жёсткость зависит от размера пролёта, перфорации и отбортовок. Тонкая плоская стенка с крупными отверстиями может звенеть. Загиб края или отдельная рамка часто эффективнее простого увеличения толщины. Стальной лист позволяет уменьшить толщину при иной массе и технологии обработки; он также требует защиты кромок и покрытия.

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

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

FDM: PETG, ASA и более требовательные материалы#

PETG удобен для кассет, кабельных держателей и первых панелей. ASA интересен для деталей, где нужны большая температурная устойчивость и устойчивость к внешней среде, но сложнее в печати. Руководства Prusa отдельно описывают режимы и ограничения обоих материалов; конкретная марка и ориентация печати остаются важными. [11][12][89]

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

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

Фотополимерная печать#

SLA/MSLA подходит для точной кнопки, микрофонного держателя, оптической рамки и небольших сложных деталей. Для большой силовой рамы она не является автоматически лучшим выбором: важны ударная прочность, старение, постотверждение и стоимость. Высокотемпературная смола может иметь впечатляющий HDT после заданного цикла обработки, но это не универсальная длительная рабочая температура изделия. [77]

Неполностью отверждённые детали не устанавливают рядом с датчиком влажности или в аудиоканал. Порядок промывки и отверждения выполняется по паспорту смолы. Сенсорные и оптические отверстия не заполняются лаком ради косметики.

Крепления и вибрации#

Для панели удобен метрический крепёж с резьбовыми вставками или гайками, которые можно заменить. Саморез в пластик допускается в небольшом числе обслуживаний, но это должно быть сознательное решение. Термовставка нуждается в достаточной толщине стенки; универсальное «отверстие под M3» без модели вставки не является чертежом.

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

Фильтр как обслуживаемая деталь#

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

Кассета должна иметь ручку, направление установки и возможность очистки без попадания пыли на плату. Магнитное удержание допустимо для панели, если оно не заменяет механическую фиксацию тяжёлого узла. Не следует заявлять класс очистки воздуха всего изделия по характеристике одного фильтрующего листа.

Тестовый купон вместо угадывания допусков#

До большой печати изготовить маленький образец с несколькими посадками под выбранную вставку, винт и защёлку. Измерить штангенциркулем, собрать и разобрать десять раз. Рабочие размеры перенести в CAD как параметры конкретного принтера, материала и ориентации.

Что можно отправить исполнителю#

После примерки — плоские панели с базами, размерами, материалом, толщиной, обработкой кромок, допусками и указанием покрытия. Для печати — модель, ориентация, материал, критичные размеры и контрольный купон. Для PCB — проверенные Gerber, drill, stackup и комплект схемы/спецификации. Иллюстрации этой книги не заменяют ни один из этих пакетов автоматически.

Распиновки, электрические ограничения и проектные размеры проверяются по фактическим деталям. Заготовка панели помогает начать примерку, но не является испытанным производственным чертежом. Уточнение программной архитектуры не меняет этого статуса.

Металл и пластик: не назначать класс безопасности по названию#

PETG, ASA, смола и фильтрующий поролон не получают единый класс UL 94 по названию материала. Он относится к конкретной марке, толщине и образцу; печать меняет геометрию и дефекты. Для горячих и силовых зон опорный вариант — металл либо материал с документацией на нужные условия. Фильтр держим вдали от горячего радиатора и не оставляем свободно свисающим. [174]

Если внутри куба установлен сетевой БП класса I, защитное соединение доступных металлических частей проектируется отдельно от сигнальной земли. Анодирование, краска и случайный контакт через винты не являются проверенным PE-соединением. Точки соединения, шайбы, проводники, затяжка и метод измерения вносятся в карту; численный предел задаётся применимым стандартом и выбранной конструкцией, а не универсальным советом «0,1 Ом мультиметром». Для E0 с внешними закрытыми адаптерами сеть внутрь самодельного корпуса не вводим.

Два вентилятора на приток и один на вытяжку — исходная топология, а не доказательство достаточного охлаждения.

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

Что переносит воздушный поток#

Для грубой оценки используется тепловой баланс:

Q = P / (ρ · cₚ · ΔT)

Здесь Q — объёмный расход в м³/с, P — тепло, передаваемое воздуху, ρ — плотность воздуха, cₚ — его удельная теплоёмкость, ΔT — нагрев проходящего воздуха. При условных P = 120 Вт, ρ = 1,2 кг/м³, cₚ = 1005 Дж/(кг·К), ΔT = 10 К получается Q ≈ 0,00995 м³/с, то есть 35,8 м³/ч или около 21,1 CFM.

Это идеальный баланс потока, а не готовый номинал вентилятора. Он не учитывает неравномерность распределения, сопротивление фильтра, локальные застойные зоны и тепловое сопротивление между кристаллом и воздухом. Температура CPU зависит не только от выходного воздуха: важны контакт, радиатор, паста, монтаж и мощность кристалла.

Рабочая точка вентилятора#

Паспортный свободный расход измеряется почти без сопротивления, максимальное давление — почти без расхода. В корпусе одновременно не получаются оба максимума. Реальный режим находится на пересечении кривой вентилятора и сопротивления системы. Загрязнение фильтра сдвигает это пересечение в сторону меньшего расхода. [4] [75]

Рассмотреть схему

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

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

Схема Koobique 320#

Передние 120-мм вентиляторы подают воздух через общую кассету. Верхний поток направляется к CPU-кулеру; нижний обдувает плату, накопитель и зону поддона. Верхняя задняя вытяжка выводит нагретый воздух, не засасывая его обратно к переднему фильтру. БП получает свой предусмотренный производителем воздух и не превращается в единственный вытяжной канал всего куба.

Рассмотреть схему

Воздуховод не должен полностью отрезать VRM или SSD ради красивой струи на CPU. Кожух вокруг кулера полезен лишь после сравнения температур остальных узлов. Размещение блока питания снизу требует доступа к его входу; нижний фильтр и ножки не должны перекрываться столом.

Обычный и reverse-blade вентилятор#

Обратная геометрия лопастей позволяет получить другое направление потока относительно видимой стороны рамки. Это удобно в прозрачных корпусах, где хотят видеть одну декоративную сторону. Она не делает вентилятор автоматически реверсивным по команде и не улучшает охлаждение сама по себе. У Lian Li такие модели выделены отдельными изделиями. [76]

Для Koobique можно использовать три обычных вентилятора, ориентируя их по стрелке потока на рамке. Переполюсовывать 12-вольтовое питание ради смены направления нельзя. Если выбран reverse-blade, он рассматривается как другая модель со своей кривой, током, кабелем и посадкой.

Профиль управления#

На первом стенде предпочтительны штатные fan headers платы и UEFI-профиль, который работает даже при остановке Rust-core. Нижняя граница оборотов выбирается выше устойчивого запуска конкретного вентилятора. Температуру управления сглаживают, но перегрев должен иметь быстрый обход сглаживания.

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

Как испытать охлаждение#

Сначала измеряется комнатная температура и режим без корпуса, затем тот же набор нагрузки в корпусе. Одновременно записываются CPU, SSD, доступные датчики платы, обороты и температура входного/выходного воздуха. После выхода на установившийся режим выполняются распознавание речи, запись данных и сетевые команды. Тест только максимальной CPU-нагрузки не показывает акустическую пригодность голоса. Воздушные датчики располагаются в воспроизводимых точках: на входе, в зоне платы и после CPU-кулера. Положение, расстояние от горячих поверхностей и способ крепления записываются, чтобы повторный опыт сравнивал те же участки потока.

Затем проверяется уменьшенная проницаемость фильтра безопасной контролируемой вставкой, без распыления пыли и без полного перекрытия БП. Учитываются накопленный нагрев и восстановление. Нельзя останавливать крыльчатку пальцем или оставлять заблокированный вентилятор без контроля.

Критерий принятия корпуса#

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

Тепловой пример#

Пусть суммарное тепло в основном отсеке принято равным 120 Вт, разрешённый рост температуры воздуха — 10 K. При условных плотности 1,2 кг/м³ и теплоёмкости 1005 Дж/(кг·K):

Q = P / (ρ · cₚ · ΔT) Q = 120 / (1,2 × 1005 × 10) ≈ 0,00995 м³/с Q ≈ 35,8 м³/ч ≈ 21,1 CFM

Это баланс воздуха в идеализированном отсеке, а не паспортный выбор вентилятора. Он не учитывает локальные горячие зоны, рециркуляцию, фильтр, утечки и отдельное тепловое сопротивление CPU-кулера. Реальный расход находится на пересечении характеристик вентиляторов и тракта. Тестируется вся собранная система, не только сумма свободных CFM.

Если входной воздух уже тёплый, тот же перепад не гарантирует допустимую температуру SSD или VRM. Отдельно фиксируются температура помещения, температуры узлов, мощность нагрузки и обороты. Сравнение «до/после фильтра» без одинаковой нагрузки и окружающей температуры вводит в заблуждение.

Тепловой допуск — для конкретных деталей#

Порог 85 °C для любого CPU и 70 °C для любого NVMe не универсален. В карте фиксируются паспортные рабочие пределы конкретных моделей, положение датчика и выбранный запас. Начальная цель: не менее 10 K до паспортного ограничения, отсутствие throttling в требуемой нагрузке и ΔT выходящего воздуха не выше 15 K. Это инженерные цели, а не нормы безопасности. В испытании нужны 2 часа нагрузки после теплового установления при измеренной комнатной температуре; затем тот же опыт с загрязнённым фильтром в согласованном состоянии.

Два притока и одна вытяжка сами по себе не доказывают избыточное давление. Корпус испытывают вместе с решётками, фильтром, поддоном и кабелями. Временно сравнивают точки температуры и перепада давления; оценка «60% потока в нижнем отсеке» по рисунку не используется. При остановке вентилятора проверяют весь переходный процесс и завершение нагрузки, не только сообщение тахометра.

Управляющий GPIO передаёт информацию. Ток двигателя идёт по отдельному силовому пути.

У типичного четырёхпроводного PC-вентилятора есть питание, земля, тахометрический выход и PWM-вход. У трёхпроводного скорость обычно меняется напряжением питания; у четырёхпроводного питание остаётся постоянным, а скорость задаётся отдельным сигналом. Цвета кабелей нельзя считать универсальной распиновкой.

Рассмотреть схему

Электрический интерфейс#

В документации Noctua для PWM-моделей описаны целевая частота около 25 кГц, отдельный тахометрический выход и ограничения входов. Внутри одного семейства встречаются вентиляторы на 5, 12 и 24 В — одинаковое число проводов не означает одинаковое питание. [6]

Самый безопасный первый путь — использовать разъёмы материнской платы и её режим PWM. Если хочется собственный контроллер на MCU, PWM формируется через открытый сток/коллектор с общей сигнальной землёй, а электрические уровни сверяются с выбранной моделью. Не следует подключать вход, подтянутый внутри вентилятора к неизвестному уровню, непосредственно к незащищённому GPIO.

Тахометрический сигнал у рассматриваемых моделей имеет открытый коллектор и обычно два импульса за оборот. Для измерительного интервала Δt, числа импульсов N и коэффициента p импульсов/оборот скорость равна RPM = 60 · N / (p · Δt). При p = 2 и 40 импульсах за секунду получается 1200 об/мин. Коэффициент берётся из документации, а не зашивается глобально для всех моделей. [6]

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

Разветвители и пусковой ток#

Токи вентиляторов складываются. Если три условных двигателя потребляют по 0,15 А в установившемся режиме, сумма составляет 0,45 А; при выборе header дополнительно учитывается запуск и запас. Эта арифметика не заменяет паспорт каждого вентилятора. Питание от отдельного хаба может разгрузить плату, но хаб тоже должен иметь документированные пределы.

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

Значение PWM = 0 не обязательно означает полную остановку, а отсутствие PWM не у всех изделий вызывает одинаковое поведение. Прошивка должна опираться на испытанную таблицу запуска, остановки и восстановления. После загрузки сначала включается безопасный режим вентиляции, затем разрешается тяжёлая вычислительная нагрузка.

Шум — не только число оборотов#

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

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

Подготовка к микрофонному модулю#

Для первого этапа микрофон Fifine располагается отдельно от куба. Он создаёт эталонный путь захвата. Затем можно сравнивать выносной USB-массив и встроенную микрофонную «корону» в пластиковой верхней зоне.

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

Совместный тест голоса и вентиляции#

Записать одни и те же русские и английские команды с фиксированных расстояний: тихий режим, длительная нагрузка CPU, воспроизведение ответа и работа вентилятора на повышенной скорости. Сравнить ошибки намерений, а не только субъективную приятность записи. По возможности сохранять эталонный текст и хеш аудиофайла.

Тахометр не объединяется так же, как питание#

PWM-выход MCU управляет входом вентилятора через открытый сток; выход 3,3 В нельзя напрямую соединять с непроверенной внутренней подтяжкой 5 В. Тахолинию подтягивают к допустимому для приёмника уровню, обычно 3,3 В для MCU, но не к 12 В. Несколько таховыходов не замыкают вместе. Готовый разветвитель должен явно указывать, какой вентилятор измеряется; отдельная диагностика требует отдельных входов. [6]

Стабильное питание и надёжные контакты нужны до отладки прошивки. Просадки напряжения и ошибки разъёмов устраняются в электрической части.

Первый Koobique использует готовые закрытые источники питания: штатный БП вычислителя, USB-питание отладочных плат и отдельный 12-вольтовый адаптер низковольтной нагрузки. Это позволяет изучить управление реле, не проектируя одновременно сетевой преобразователь и защиту от поражения током.

Разделение силовых цепей#

ATX и EPS питают материнскую плату и CPU. SATA или штатные периферийные разъёмы используются только по назначению. Четырёхпроводные вентиляторы подключаются к рассчитанным fan headers или проверенному хабу. USB-плата получает разрешённый входной уровень, а её локальный стабилизатор формирует питание микроконтроллера.

Модульные кабели БП не взаимозаменяемы по одному внешнему сходству разъёма. CPU/EPS и PCIe также нельзя смешивать. В первом экземпляре применяются кабели из комплекта конкретного БП; удлинители и переходники добавляются только после проверки распиновки и допустимого тока.

Рассмотреть схему

Питание ESP32-C6#

Руководство DevKitC-1 различает USB-питание и питание через контакты 5V или 3V3. Эти способы нельзя произвольно объединять. В документации также описана перемычка для измерения тока модуля; её поведение отличается от измерения потребления всей отладочной платы с LED и USB-мостом. [14]

Плата с установленным Wi-Fi при передаче потребляет ток импульсами. Измерение мультиметром усредняет эти события, поэтому просадку у питания MCU полезно смотреть осциллографом. Симптомы недостаточного питания — перезапуски при установлении связи, ошибки TLS под нагрузкой и нестабильные датчики — легко ошибочно принять за программную проблему.

Отдельно учитывается падение напряжения кабеля. Для условного двухпроводного участка с суммарным сопротивлением 0,4 Ω и током 0,5 А потеря составляет 0,2 В, а нагрев — 0,1 Вт. Этот пример не задаёт допустимый кабель: фактическое сопротивление включает провода, контакты и переходники.

Защита 12-вольтовой нагрузки#

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

Первый светильник удобно ограничить мощностью порядка 6 Вт при 12 В — около 0,5 А в установившемся режиме. Это проектный пример, не обязательная модель покупки. Нагрузка должна быть рассчитана на прямое питание выбранным адаптером; голые мощные светодиоды без драйвера сюда не относятся.

Сигнальная земля узла и земля драйвера катушки обычно объединяются. Сухие контакты реле могут переключать отдельную цепь лампы без соединения её минуса с MCU. Если добавляется неразвязанный измеритель тока или напряжения, топология земли меняется и должна быть показана на схеме, а не появляться случайно через USB-анализатор.

Жгут как инженерная деталь#

Каждый кабель имеет обозначение, оба конца и назначение контактов. Например, W-S01: Sense J1 → SHT45, сигналы 3V3/GND/SDA/SCL. Цвет помогает монтажу, но не заменяет таблицу. Разъёмы выбираются с ключом или явной механической защитой от переворота.

Для прототипа Dupont допустим на столе, но постоянный экземпляр лучше перевести на фиксируемые разъёмы, паяную макетную плату или PCB-носитель. Клемма должна соответствовать сечению провода; многопроволочную жилу обрабатывают способом, предусмотренным клеммой. Лужёный конец под винтом не стоит считать универсально надёжным соединением из-за деформации припоя со временем.

Силовые провода не натягивают через острые кромки. Разгрузка натяжения располагается до платы. Отверстие в металле получает втулку или иной защитный элемент. Провод вентилятора фиксируется так, чтобы при снятии панели он не попал в крыльчатку.

Металл, земля и защитный проводник#

Защитное соединение корпуса и сигнальная GND — разные задачи. Если в изделии есть сетевой БП класса I, доступные металлические части и его монтаж должны соответствовать требованиям защитного заземления и инструкции производителя. При полностью внешнем изолированном источнике низкого напряжения схема иная. Нельзя заменять анализ безопасности универсальной перемычкой «весь металл на GND платы».

Для первого экземпляра сетевой ввод оставляют в штатном закрытом БП либо полностью снаружи. Собственный IEC-ввод, выключатель сети и внутренние сетевые соединения требуют отдельного квалифицированного проектирования. Их отсутствие не мешает ни кубической форме, ни качеству программной платформы.

Первое включение узла#

Проверить отсутствие короткого замыкания при снятом питании. Отдельно проверить напряжение адаптера. Включить узел без нагрузки, затем с ограниченной низковольтной нагрузкой. Измерить ток и температуру соединений. В журнал записать источник, кабель, ревизию платы и поведение при перезапуске.

Падение напряжения в жгуте#

Для учебного расчёта примем медный двухпроводный путь длиной 1 м до нагрузки и 1 м обратно, сечением 0,5 мм², удельным сопротивлением 0,0175 Ом·мм²/м при опорных условиях. Это приблизительная исходная величина; реальный провод и нагрев проверяются измерением.

Rпетли = ρ · 2L / S ≈ 0,0175 × 2 / 0,5 = 0,07 Ом При 2 А: ΔV ≈ 0,14 В; Pпровода ≈ 0,28 Вт

К этому добавляются разъёмы, контакт реле, предохранитель и клеммы. Для 12-вольтовой лампы небольшой провал может быть допустим, а для короткого пика Wi-Fi на слабой 3,3-вольтовой шине — вызвать reset. Поэтому измеряется минимум напряжения у потребителя во время нагрузки, не только выход адаптера мультиметром в покое.

Номинал предохранителя выбирается по проводу, пусковому току, нагрузке и времятоковой характеристике. Он не получается автоматически из среднего тока лампы и не предназначен для защиты GPIO.

Независимость от станции начинается с питания#

Actuator питается не от USB Hub, а от собственного закрытого источника 5 В. Катушка документированного 5-вольтового модуля подключается к его VIN 5 В, не к 3,3 В DevKit. Sense и Presence также получают независимое питание, если заявлена работа при выключенном Hub. Для отладки через ПК допускается временная связь, но она отмечается как зависимость стенда. Одновременные источники на разъёмах DevKit не объединяют без проверки схемы платы и обратного питания.

Для E0-L6 предлагаем лампу 12 В DC до 6 Вт, провод от 0,5 мм² и F1-кандидат 1 А с DC-рейтингом не ниже 32 В рядом с плюсом источника. Это не утверждённая защитная координация: до подключения фиксируются точная лампа, DC-адаптер, предельный и пусковой ток, время-токовая кривая F1 и отключение источника при КЗ. Если адаптер ограничивает ток ниже срабатывания F1, предохранитель не считается гарантированно разрывающим КЗ — проверяется собственная защита источника. MR16 и надпись «12 В» не доказывают постоянное напряжение.

Физическое отключение питания нагрузки остаётся доступным независимо от MCU. Кнопка на GPIO не размыкает сварившийся контакт реле. Стенд ограничен световой нагрузкой, не переносится на инструмент, нагреватель или замок. Переход к сетевой нагрузке потребует отдельного электрического проекта, готовых закрытых аппаратов и компетентной проверки.

Основной путь пользователя — обычная домашняя Wi-Fi-сеть. Отдельная сеть хаба остаётся сервисным или будущим специализированным вариантом.

Станция подключается к роутеру как клиент. Телефон остаётся в привычной сети. Узлы первого комплекта подключаются к доступной сети 2,4 ГГц, а станция может работать в другом диапазоне, если роутер допускает локальное взаимодействие между ними. Облачный DNS и интернет не участвуют в передаче команд внутри этой сети.

Радио на Linux#

Покупать Wi-Fi-модуль нужно по чипу и драйверу, а не по надписи «Wi-Fi 6». Linux iwlwifi документирует поддерживаемые устройства и ограничения режимов, включая различия client/AP. Наличие хорошего клиентского режима не гарантирует полноценную точку доступа на любом диапазоне. [38]

Для первой станции достаточно надёжного Wi-Fi-клиента и Bluetooth для дальнейшего сопряжения. Второй независимый радиомодуль имеет смысл, если потребуется собственная сеть устройств без зависимости от домашнего роутера. Он не должен появляться как скрытое обязательное условие приложения.

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

Рассмотреть схему

Антенны устройств#

ESP32-C6-WROOM-1 имеет печатную антенну, вариант WROOM-1U — разъём внешней. В готовом узле соблюдаются рекомендации по свободной зоне около антенны, земле и размещению металла. Плата, прекрасно работающая без корпуса, может потерять связь после установки батареи или винта перед антенной. [14][81]

Для первого Sense предпочтителен пластиковый корпус с вынесенной к краю антенной. Металлические декоративные элементы рядом с радио добавляются после базового измерения. Кабель датчика также может изменить электромагнитную обстановку, особенно если он длинный и идёт вдоль антенны.

Обнаружение и идентичность#

Локальное обнаружение должно быть удобным, но не определять доверие. Приложение может использовать Bonjour/mDNS, адрес из QR или уже известный локальный endpoint. После обнаружения оно проверяет закреплённую идентичность станции. IP и имя — адреса, а не доказательство владельца.

Если multicast заблокирован, приложение должно уметь подключиться по известному IP или найти станцию через ограниченный механизм восстановления. Полное сканирование всей локальной сети не следует делать постоянной фоновой функцией. На iOS доступ к локальной сети требует предусмотренного разрешения и корректного объяснения пользователю. [57]

Что может сломать локальную связь#

WPA-защита сети не заменяет аутентификацию протокола. Гость, имеющий пароль Wi-Fi, не должен получать право управлять реле. С другой стороны, TLS не исправляет слабый радиосигнал и роутер, который запрещает обмен между клиентами.

Политика переподключения#

Потеряв сеть, узел сохраняет локальную функцию и постепенно увеличивает интервал попыток с небольшим случайным разбросом. Одновременный старт десятков узлов не должен создавать синхронную лавину TLS-handshake. После подключения узел передаёт boot_id, последнюю версию состояния и актуальные наблюдения; исторические записи идут отдельно.

Постоянная доступность устройства не равна постоянной высокой частоте heartbeat. Интервал определяется допустимым временем обнаружения потери связи и энергопотреблением. Для стационарного Actuator он короче, для будущего спящего датчика — связан с расписанием пробуждения.

Как проверять радио#

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

Для кабинета полезны три точки: рядом со станцией, обычное рабочее место и худшее предполагаемое место датчика. Те же точки повторяются с закрытым корпусом, работающими вентиляторами и активным USB/SSD. Электромагнитные помехи от собственной конструкции должны выявляться до изготовления красивых панелей.

Wi-Fi остаётся основным режимом#

Ethernet удобен как эталон для диагностики, но не подменяет согласованный пользовательский режим: Hub и узлы должны пройти приёмку через обычный Wi-Fi. Металлический куб получает наружные антенны либо проверенное радиопрозрачное окно. Сравниваются задержки и отказы с открытыми и закрытыми панелями; RSSI около −70 дБм — только диагностический ориентир, не доказательство пригодности.

Для постоянно питаемого Actuator в E0 выбирается WIFI_PS_NONE; экономию модема проверяют позднее как другую конфигурацию. На Linux фиксируется фактическая политика power-save адаптера. Результат зависит от AP, DTIM, диапазона и драйвера, поэтому не обещаем универсальную прибавку «100–300 мс». [178]

H0 запускается на Linux с доступной локальной сетью. WSL2, Docker Desktop и виртуальная машина допускаются лишь после отдельной проверки входящих соединений, multicast и проброса USB/BLE; NAT может скрыть проблему под видом неисправного устройства. Смена пароля Wi-Fi открывает физически подтверждённый сетевой provisioning без сброса владельца. Резерв питания только Hub не сохраняет Wi-Fi, если обесточен AP.

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

Для первых трёх узлов выбирается ESP32-C6-DevKitC-1. Это не обещание, что весь ассортимент Koobique останется на одном MCU. Отладочная плата удобна наличием питания, USB, загрузчика и готового радиомодуля. У варианта N8 документированы 8 МБ flash и отсутствие PSRAM; это важно при одновременной работе BLE, TLS и обновления. [14]

Рассмотреть схему

Роли одинаковой платы#

На Sense используются I²C-датчики. На Presence — цифровой вход PIR и UART радара. На Actuator — выход управления реле и физическая кнопка. Общая прошивочная инфраструктура обеспечивает сеть, идентичность, обновление и диагностику, но список драйверов и периферии задаётся профилем сборки.

Исполнитель не должен принимать конфигурацию, которая случайно назначает реле на загрузочный strapping pin. Карта контактов имеет аппаратную версию и проверяется при сборке. Изменение GPIO — изменение описания платы, а не пользовательский параметр обычной автоматизации.

Предлагаемая карта контактов#

Таблица основана на опубликованной распиновке DevKitC-1; конкретная ревизия и совместимые клоны должны быть сверены. GPIO8 занят RGB LED, GPIO9 связан с загрузочным режимом, GPIO12/13 используются USB, GPIO16/17 — UART-мостом. GPIO4/5, 8/9 и 15 относятся к strapping-функциям и не выбираются произвольно для исполнительного выхода. [14]

GPIO6/7 связаны также с внешним JTAG. При выбранной I²C-карте для отладки используется подходящий USB Serial/JTAG путь, а не одновременное подключение внешнего JTAG к тем же линиям. Конфликты периферии обнаруживаются в описании платы до разводки.

Периферийный контракт#

У каждого драйвера есть init, sample, состояние ошибки, ограничение времени и процедура восстановления. Он не блокирует общую систему бесконечным ожиданием байта. Ошибка I²C передаётся как ошибка канала, а не заменяется нулём градусов. После восстановления первый достоверный результат отмечается как новый.

Для UART-периферии нужен ограниченный буфер, проверка длины и контроль кадра, если он предусмотрен производителем. Неизвестный байт не должен смещать весь поток навсегда. Протокол радара считается внешним недоверенным входом, даже когда модуль физически припаян к плате.

Питание и отключаемые домены#

Для стационарного узла простота важнее микроампер сна. Отдельные выключаемые домены полезны как способ восстановить зависший датчик, но добавляют MOSFET/ключ, пусковой ток и риск питания через сигнальные линии. Нельзя отключить VDD сенсора и оставить SDA подтянутой к активной шине, не проверив допустимые режимы его входов.

Для будущего батарейного устройства отладочная плата может оказаться неподходящей из-за LED, USB-моста и стабилизатора. Тогда выбирается MCU и питание по энергетическому бюджету, а не копируется весь Sense. Общими остаются семантика сообщений и драйверные интерфейсы, но транспорт может стать BLE с пакетной синхронизацией.

Что положить на стол#

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

Проверка каждой платы отдельно#

Записать модель и ревизию, прочитать идентификатор, прошить минимальный диагностический образ, проверить USB, Wi-Fi и свободную память. Затем подключать по одному модулю. Один общий жгут со всеми неизвестными устройствами усложняет поиск ошибки в несколько раз.

Перед первой подачей питания#

В ведомости фиксируется точный DevKitC-1-N8 и ревизия либо схема выбранного аналога. USB-Serial-JTAG относится к разъёму, соединённому с USB самого C6; второй порт может вести к USB-UART. Названия «USB-C» и «ESP32-C6» не определяют разводку. Strapping-пины, уровни и питание сверяются по документации именно приобретённой платы.

Первый аппаратный риск — не средний ток датчиков, а просадка питания во время радиопередачи и включения реле. Проверяют напряжение на плате и причину reset при одновременной нагрузке. Большой конденсатор не заменяет достаточный источник, короткие силовые провода и отделение катушки от сенсорной шины.

После установки в корпус температура чувствительного элемента зависит от всей сборки. Точность измерения температуры комнаты проверяется отдельно от паспортной точности микросхемы.

Для первого Sense подходит готовый модуль SHT45. Он одновременно даёт температуру и влажность, а влажность полезна для понимания поведения сенсора и будущих сценариев. Альтернатива — температурный TMP117, когда нужен специализированный термоканал. Более доступный SHT31/SHT4x другого класса может быть достаточен, если его погрешность укладывается в цель опыта; подмена модели должна быть отражена в калибровке и метаданных. [15][78]

Микросхема и breakout — разные изделия#

У голого SHT45 допустимое питание отличается от удобного входа готовой платы со стабилизатором и дополнительными компонентами. Для рассматриваемого Adafruit-модуля описаны VIN, логические уровни и подтяжки I²C. Подключение VIN к 3,3 В удобно согласует уровни с ESP32, но конкретный неизвестный модуль с маркетплейса требует собственной проверки схемы. [15][16]

Сначала читаются маркировка и разводка платы, затем выбирается напряжение. Наличие надписи «5V compatible» не означает, что любой контакт GPIO можно соединять с 5 В. Такой подход особенно важен для дешёвых breakout, внешне похожих на оригинал, но содержащих другой стабилизатор или отсутствующий level shifter.

Где поставить датчик#

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

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

Рассмотреть схему

Период измерений и тепловая инерция#

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

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

У сенсоров с нагревателем показания во время его работы не должны использоваться как обычная температура комнаты. В наблюдении ставится флаг режима, а система знает период восстановления. Возможности нагрева и рекомендованное обращение проверяются в документах SHT4x. [15]

Калибровка первого экземпляра#

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

Для простого диапазона можно начать со смещения Tcorrected = Traw + b, но его применимость ограничена проверенными условиями. Если нужна линейная коррекция, коэффициенты определяются несколькими точками, а остаточная ошибка показывается отдельно. Автоматически подгонять датчик под ожидаемый комфорт нельзя: это скроет реальные события.

Оценка неопределённости складывается не только из паспортной точности: важны опорный прибор, самонагрев, градиент воздуха, задержка и округление. Число «23,437 °C» не полезнее «23,4 °C», если неопределённость значительно больше тысячной доли.

Сценарии температуры без опасного управления#

В первом кабинете температура вызывает уведомление или включает низковольтный испытательный вентилятор. Это позволяет изучить обратную связь без автоматического управления обогревателем. Если вентилятор просто перемешивает воздух, он не обязан снижать среднюю температуру помещения: ощущение человека и тепловой баланс — разные величины.

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

Эксперимент с самонагревом#

Снять ряд показаний при выключенном и активно передающем Wi-Fi, не меняя внешнего положения узла. Повторить с открытым и закрытым корпусом. Если смещение связано с режимом платы, исправлять размещение и тепловую конструкцию, а не только добавлять постоянную поправку в код.

Преобразование АЦП и реакция на воздух — разные времена#

SHT4x описывает режимы преобразования, CRC и время готовности. Для высокоточного чтения драйвер использует предельное время из актуального даташита; учебная программная граница ожидания 10 мс не выдаётся за точное время физического интегрирования. Температурная реакция корпуса сенсора на воздух медленнее преобразования. В Observation записывается интервал, который действительно ограничивает драйвер, и режим получения данных. [157]

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

Люксометр видит свет в своей точке. Чтобы управлять комнатой, нужно понимать, откуда этот свет пришёл.

VEML7700 подходит для первого оптического канала: готовый модуль легко подключить к I²C, а усиление и время интегрирования позволяют исследовать разные уровни света. OPT3001 — альтернативный вариант с другой внутренней организацией и драйвером. Выбор между ними делается по диапазону, спектральной характеристике, доступности модуля и поведению при насыщении, а не по одному числу разрядности. [17] [18][19]

Подключение и адреса#

В выбранной паре VEML7700 использует семибитный адрес 0x10, SHT4x — 0x44. Они могут находиться на одной шине. Формат адреса важен: некоторые библиотеки ожидают семибитное значение, другие примеры показывают уже сдвинутый байт с битом чтения/записи. Передача 0x20 вместо 0x10 в неподходящий API даст отсутствие ответа, а не неисправность датчика. [17][16]

Рассмотреть схему

SDA и SCL имеют открытый сток: высокий уровень формируется подтяжкой. Слишком большое сопротивление делает фронт медленным; слишком маленькое увеличивает ток в состоянии логического нуля. Общая ёмкость состоит из выводов, проводов, разъёмов и входов анализатора. Поэтому правило «всегда ставить 4,7 кΩ» недостаточно.

Для порогов 30% и 70% напряжения питания спецификация I²C даёт зависимость tᵣ = 0,8473 · Rₚ · Cᵦ. Минимальное сопротивление ограничивается допустимым током стягивания и уровнем VOL. [26]

При Cᵦ = 100 пФ и Rₚ = 4,7 кΩ: tᵣ ≈ 398 нс. При той же ёмкости и Rₚ = 2,2 кΩ: tᵣ ≈ 186 нс.

Первое значение укладывается в типичный предел Standard-mode 100 кГц, но не в предел 300 нс для Fast-mode. Второе быстрее, однако ток и допустимые уровни проверяются для всех участников. Две подтяжки по 10 кΩ, соединённые параллельно, дают 5 кΩ. Добавление третьего модуля снова меняет эквивалентное сопротивление. [26]

Рассмотреть схему

Для первого стенда предпочтительны короткие провода и 100 кГц. Длина порядка 10– 20 см — удобное исходное ограничение макета, а не физический предел стандарта. Длинный кабель через комнату лучше обслуживать отдельным узлом или подходящим дифференциальным интерфейсом, чем пытаться сделать I²C универсальной полевой сетью.

Усиление, интегрирование и насыщение#

Датчик накапливает сигнал за интервал. Увеличение времени интегрирования повышает чувствительность к слабому свету, но снижает скорость обновления и раньше приводит к насыщению при ярком освещении. Автодиапазон меняет настройку, затем ждёт корректного нового измерения; нельзя применять новый коэффициент к результату, накопленному со старым режимом. VEML7700 имеет документированные gain и integration time. [17]

Значение у верхней границы ADC сопровождается флагом насыщения. Оно не превращается в «очень точно измеренные 65535». В переходном режиме после смены настройки публикация может быть временно задержана или помечена. Время измерения относится к интервалу интегрирования, а не только к моменту чтения регистра.

Оптика корпуса#

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

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

Свет, который система включила сама#

Простое правило «ниже 80 лк — включить, выше 120 лк — выключить» часто образует цикл: лампа включилась, датчик увидел 500 лк, правило выключило лампу, снова стало темно. Один гистерезис не решает проблему, если собственная лампа меняет измерение сильнее ширины гистерезиса.

В E0 с PIR-only включение использует допустимое событие движения и освещённость до включения; автоматический OFF по отсутствию движения не разрешён. Выключение после подтверждённого ухода с выдержкой относится к отдельно квалифицированному профилю E1. Для выключения при достаточном дневном свете требуется отдельный дневной канал или модель собственного вклада светильника с проверкой применимости. Яркость от включённой лампы сама по себе не является основанием для выключения.

Рассмотреть схему

Проверка канала#

Проводятся опыты: затемнение, обычный рабочий свет, дневной свет, направленная лампа, закрытый корпус, смена gain. В каждом сохраняются raw, настройки, рассчитанные lux и флаги. Мерцание источника и длительность интегрирования могут влиять на разброс; среднее число не описывает качество мерцания или безопасность освещения.

Полезный результат главы#

Получить таблицу «сырое значение → настройки → lux → качество», устойчивое чтение двух датчиков на одной шине и осциллограмму фронтов. Затем проверить, что собственное включение лампы не приводит к бесконечному ON/OFF.

Коррекция света должна быть воспроизводимой#

В примечании Vishay 84323 описаны gain, integration time и коррекция нелинейности. Нельзя применять один коэффициент для всех диапазонов или полином дважды — в драйвере и Core. Сохраняются raw counts, gain, IT, признак насыщения и версия преобразования. При смене диапазона первый непригодный результат исключается. Для gain 1/4 и 1/8 документ приводит полином; в рабочем профиле порог и коэффициенты берутся из закреплённой редакции и проверяются на контрольных точках. [106]

Интегрирование 100 мс удобно для первого сетевого освещения: оно усредняет несколько периодов типичной пульсации, но не устраняет любой PWM-драйвер и не создаёт точной синхронизации с сетью. 25 мс и 50 мс не следует объявлять универсальной защитой от фликера. При сильной пульсации сравниваются несколько IT на одной лампе и сохраняется разброс.

Два набора подтяжек по 10 кОм дают около 5 кОм; добавление ещё одной пары вслепую меняет нагрузку на выходы. Проверяют итоговое сопротивление и фронты собранной шины, а не только перечень модулей. [158]

Движение, присутствие и личность — разные задачи. Первый Koobique решает только первые две.

PIR обнаруживает изменения теплового излучения в своей зоне, поэтому хорошо подходит для входа и движения. Неподвижный человек может перестать давать события. Радар способен обнаруживать другую динамику, но также реагировать на вентилятор, шторы, соседнее помещение или собственные особенности установки. Ни один из этих сигналов не следует превращать в абсолютную истину без проверки. [20][22]

Рассмотреть схему

Три варианта узла Presence#

PIR-only — минимальный стенд обнаружения движения: он допускает включение по событию входа, но не вывод «человек ушёл». В первом профиле автоматическое выключение по одному молчанию PIR запрещено. Таймер коридора можно добавить как отдельную явно выбранную политику, а не назвать измерением отсутствия.

PIR + радар — предпочтительный исследовательский комплект. PIR помогает быстрому событию входа, радар поддерживает оценку присутствия во время спокойной работы. Параметры дальности, чувствительности и периода выдачи регулируются на основании журнала ошибок.

Дополнительный контекст — геркон двери, кнопка, состояние рабочего компьютера или явно включённый режим работы. Эти каналы помогают, но не должны скрыто собирать личные данные. Активность телефона и RSSI не считаются доказательством нахождения конкретного человека в комнате.

Выбор готового радара#

SEN0395 — пример модуля с опубликованной документацией и интерфейсом. Его полезность для первого проекта — в доступном протоколе и понятной интеграции, а не в гарантии отсутствия ложных срабатываний. Перед подключением сверяются питание, допустимые уровни UART, назначение выводов и режим данных конкретной ревизии. Не каждый модуль, питающийся от 5 В, выдаёт безопасный для ESP32 логический уровень. [22][23]

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

Размещение в комнате#

PIR направляется через предполагаемую траекторию движения, а не только вдоль неё. Радар не ориентируется на вращающийся вентилятор или движущуюся штору. Металлические детали корпуса и стены влияют на поле; пластиковая крышка также проверяется. Сенсор присутствия не обязан находиться в одном корпусе со станцией.

Как собирать данные для настройки#

Нужны размеченные периоды: пустая комната, вход, сидение без движения, работа за компьютером, движения за стеной, работа вентилятора, открытое окно, уход. Разметка может выполняться кнопкой в приложении: «сейчас пусто» / «сейчас я здесь». Записываются настройки радара и версия алгоритма.

Основные метрики — пропущенное присутствие, ложное присутствие, время включения после входа и время выключения после ухода. Средняя точность по всем секундам может вводить в заблуждение, если комната большую часть времени пуста. Отдельно считается нежелательное выключение света при человеке.

Модель состояний#

Для первого экземпляра достаточно явного автомата: UNKNOWN, EMPTY, CANDIDATE, OCCUPIED и VACATING. UNKNOWN означает отсутствие пригодной свежей информации. CANDIDATE — краткий период проверки сигнала. VACATING — отсутствие новых свидетельств, но ещё не подтверждённый уход.

Рассмотреть схему

До калибровки вероятностной модели используем категорию уверенности и перечень свидетельств: «радар активен; PIR сработал 12 секунд назад; данные свежие». Число вроде «вероятность 0,93» требует размеченных записей и проверки калибровки; без них точная цифра создаёт необоснованное доверие.

Выдержки и дребезг#

Короткие импульсы объединяются локально, если это соответствует характеристикам сенсора. Станция отдельно хранит время последнего валидного события. Пропавшее сообщение не обнуляет занятость немедленно. История, досланная после восстановления связи, не должна продлевать текущее присутствие как новое событие.

Для проверенного комплекта PIR + радар можно исследовать быстрое подтверждение входа и задержку ухода. Для PIR-only правило выключения не включается. Порог 120 секунд в примерах ниже относится к гипотезе проверяемого профиля, а не к паспортной возможности PIR. При UNKNOWN автоматизация не делает вид, что комната пуста.

Проверка, важнее любого демо#

Для Presence-qualified сесть неподвижно на 30 минут, затем оставить пустую комнату с вентилятором. Самопроизвольное OFF при человеке или неспособность подтвердить уход означают, что допуск профиля не получен. PIR-only в этом опыте не обязан доказать пустоту; его критерий — не выключать свет по одному отсутствию движений.

Два допуска вместо одного слова presence#

Автомат качества действует поверх всех состояний: из EMPTY, CANDIDATE, OCCUPIED и VACATING потеря требуемого наблюдения ведёт в UNKNOWN. После восстановления снова проверяются свидетельства: положительное ведёт к CANDIDATE/OCCUPIED, а EMPTY возможно только при допущенном профиле отсутствия. CANDIDATE возвращается в EMPTY при опровергнутом входе лишь там, где отсутствие наблюдаемо.

В E0 отсутствие данных не гасит свет автоматически. Через 5 минут UNKNOWN выводится уведомление «датчик недоступен; свет под ручным управлением». Это предел безмолвного ожидания, не предел включённого света. Автоматический тайм-аут отключения — отдельная настройка с предупреждением; по умолчанию он выключен. Так неисправный PIR не превращается в ложное доказательство пустой комнаты.

Выбранный PIR в паспорте имеет модель, время прогрева, retrigger, длину импульса и мёртвое время. До окончания прогрева канал не объявляется пригодным. Проверяют неподвижную работу 30 минут, пустое помещение с вентилятором, затенение обзора и радиопередачу рядом. Таймер 120 секунд не исправляет фундаментальную ненаблюдаемость PIR-only.

Качество события и смена размещения#

Событие движения должно быть связано с тем размещением и режимом сенсора, в которых оно возникло. Смена descriptor без перезапуска не делает старое событие новым. До заморозки профиля Event нужно определить передачу descriptor_revision, placement_revision и mode_id либо однозначную границу sample_seq для каждого описания. Динамическое здоровье канала требует отдельного статуса с временем и причиной: WARMING, VALID или INVALID. Живой сетевой Ping сам по себе не доказывает исправность PIR. Это открытое требование контракта, а не утверждение о реализованном сообщении NodeHealth.

Проектирование выхода начинается с нагрузки, допустимых состояний и отказов. Из этих условий выводится контракт команды, включая ограничения на применение `toggle()`.

Первый Actuator переключает готовую 12-вольтовую лампу. На столе используются ESP32-C6, готовый релейный модуль с документированным управляющим входом и отдельный источник нагрузки. После проверки можно заменить модуль собственной схемой драйвера или MOSFET-ключом — это разные решения с разными свойствами.

Реле или полупроводник#

Маркировка тока контактов для AC не переносится автоматически на DC. Светодиодный драйвер может иметь пусковой ток значительно выше установившегося. Поэтому выбранный модуль проверяется по типу нагрузки, а не по самой крупной цифре на корпусе.

Готовый релейный модуль#

STEMMA Non-Latching Mini Relay — пример документированного модуля с входом управления, питанием и контактами. Он позволяет проверить архитектуру без немедленного монтажа транзистора и защитного диода. У неизвестной платы с надписью «opto isolated» нужно изучить реальные связи земли и перемычки: наличие оптопары ещё не гарантирует гальваническую развязку всей сборки. [24][25]

Рассмотреть схему

COM соединяется с защищённым плюсом источника 12 В DC, NO — с плюсом лампы, минус лампы — с минусом источника. NC не используется. В E0 допускается только документированный активный HIGH-модуль, совместимый с 3,3 В. Неизвестный 5-вольтовый active-LOW-модуль запрещён до проверки схемы: его подтяжка может подать 5 В на GPIO, а уровень 3,3 В не гарантирует выключение.

Собственный драйвер катушки#

Для малой 5-вольтовой катушки можно исследовать низкобоковой N-MOSFET. Исток соединён с GND, сток — с нижним выводом катушки, верхний вывод — с +5 В. Диод параллельно катушке установлен катодом к плюсу. Резистор затвора ограничивает резкие токи переключения; pull-down удерживает выключение при неопределённом GPIO.

Рассмотреть схему

AO3400A интересен тем, что его паспорт нормирует сопротивление открытого канала и при VGS = 2,5 В: это существенно полезнее для 3,3-вольтового MCU, чем одно пороговое напряжение VGS(th). Порог означает начало проводимости при малом токе, а не гарантированное открывание силового ключа. [80]

При условном токе катушки 80 мА и сопротивлении канала 0,048 Ω проводниковые потери составляют около 0,00031 Вт. Этот расчёт показывает, что для такой катушки тепловая проблема ключа мала; он не разрешает применять тот же корпус к многоамперной нагрузке. Сопротивление растёт с температурой, а импульсные режимы и плата влияют на допустимый ток.

Обычный обратный диод замедляет спад тока катушки. Если требуется быстрое отпускание, исследуют ограничение выброса TVS/стабилитроном и проверяют допустимое напряжение ключа. Это изменение влияет на механику контактов и не вводится «для ускорения» без измерения.

Ток как обратная связь#

INA226 измеряет ток через шунт; диапазон его шунтового входа составляет около ±81,92 мВ. При 0,1 Ом и 0,5 А получаются 50 мВ и 25 мВт. При 2 А — уже 200 мВ: АЦП насыщен, даже если резистор выдерживает 0,4 Вт. Для учебного диапазона до 2 А шунт 0,02 Ом даёт 40 мВ и 0,08 Вт; номинальная мощность, допуск, температурный коэффициент и импульсный запас выбираются отдельно. Крупный пусковой ток может выйти за измерительный диапазон. [156]

Измерительные линии шунта прокладываются отдельно от силового падения на дорожках, когда создаётся собственная плата. Калибровка выполняется с известной нагрузкой. Нулевой ток при команде ON вызывает «действие не подтверждено», но ненулевой ток ещё не гарантирует свет на столе.

Кнопка, старт и отключение связи#

GPIO переводится в безопасное состояние до подключения к сети. Физическая кнопка обрабатывается локально с подавлением дребезга; её действие отправляется станции как событие и новая версия состояния. Сервер не имеет права незаметно отменять нажатие сразу после переподключения сохранённым ранее состоянием.

В профиле E0 при потере только Wi-Fi исправная прошивка сохраняет выход и локальное управление. При reset или потере питания обычное небистабильное реле может отпустить. После загрузки E0 начинает с OFF и BOOT_INHIBIT: автоматическое восстановление ON запрещено до явного освобождения режима. Это не обещание непрерывного света во время reset. Для такой гарантии нужен другой аппаратный профиль и отдельное испытание.

Приёмка Actuator#

Проверить включение и выключение, перезапуск MCU, потерю Wi-Fi, повтор одинакового command_id, удержание кнопки, обрыв нагрузки и восстановление питания. Осциллографом или анализатором убедиться, что на старте нет короткого нежелательного импульса управления.

Контракт выхода E0#

gpio_hold_en — возможная оптимизация конкретного reset-профиля, не гарантия на все сбросы и потерю питания. Её не включаем как условие безопасности E0. Нужны осциллограмма, reset reason и проверка ранней загрузки/освобождения hold. Бистабильное реле или отдельный аппаратный latch меняют отказную модель и требуют обратной связи по контакту. [153]

Ручной режим живёт на исполнительном узле#

Короткое нажатие физической кнопки меняет выход и включает MANUAL_HOLD без автоматического истечения в E0. В приложении явное «выключить вручную» продлевает намерение даже при уже OFF. Состояние ManualOverride содержит режим, значение, источник, manual_revision и правило освобождения. Повторный автоматический план после нового snapshot также отклоняется, пока режим действует.

Освобождение выполняется отдельным действием «Вернуть автоматику» либо назначенной длинной кнопкой, отличной от provisioning/reset. Оно меняет manual_revision, но само не исполняет старый ON: Core строит новое решение на свежих данных. При перезапуске MCU E0 использует BOOT_INHIBIT; при ошибке сохранения ручного режима автоматизация остаётся запрещённой. Защитное аппаратное отключение имеет более высокий приоритет, чем любой ручной режим.

Для E1 временный ручной режим можно добавить с видимым сроком: «свет выключен до 19:00, затем автоматика вернётся». При неизвестном времени или перезапуске временный запрет не снимается молча. Истечение во время UNKNOWN не создаёт действие: сначала нужны свежие входы. Режим E0 без таймера выбран ради однозначности, не потому, что временные режимы запрещены архитектурой.

Эти карты превращают функциональные схемы в проверяемые соединения. Неизвестная ревизия модуля сначала идентифицируется, а уже затем включается.

Карта S-01. Узел Sense#

Опорная сборка: ESP32-C6-DevKitC-1, готовые модули SHT45 и VEML7700, короткая I²C-шина. Для неё достаточно одного USB-источника питания платы и её вывода 3V3 для маломощных датчиков, если измеренный суммарный ток укладывается в возможности регулятора. Номинальное питание голого сенсора и допустимый VIN breakout — разные характеристики. На этапе унификации оба выбранных модуля подключаются к 3,3 В. [14][16][18]

Вместо цветового описания «синий провод к синему» жгут получает номера W-S01…W-S05. На обоих концах подписываются сигнал и устройство. Метка на проводе важнее цвета: после замены кабеля электрический смысл должен сохраниться.

Сначала включается только плата. Затем присоединяется один датчик и проверяется его штатная операция чтения, а не только ACK адреса. После второго модуля повторно измеряется напряжение и фронт SCL. Устройства I²C иногда отвечают, но выдают неверные данные из-за питания, режима измерения или неправильного пересчёта регистра.

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

Карта P-01. Присутствие без радара#

Первый вариант Presence использует PIR с документированным цифровым выходом, совместимым с 3,3-вольтовым входом MCU. Само питание PIR при этом может отличаться: оно выбирается по паспорту модуля. Надпись «PIR 5 В» не доказывает, что его выход обязательно равен 5 В либо безопасен для C6. Для рассматриваемого в учебном источнике модуля выход описан отдельно от питания. [20][21]

Вход может требовать подтяжки или её отключения в зависимости от типа выхода. При неизвестной схеме модуля сначала измеряется сигнал, затем выбирается согласование. Делитель не является универсальной заменой проверки: для open-collector, двунаправленной шины и высокоскоростного сигнала решения различаются.

Проверка PIR содержит прогрев после включения, движение поперёк зон, неподвижного человека и пустую комнату. Наличие импульса подтверждает движение в поле датчика, а не принадлежность человека определённой комнате и не его личность.

Карта P-02. Добавление радара#

Радар SEN0395 — один из вариантов, а не обязательный модуль всей платформы. Его питание, логические уровни, UART-команды и временные режимы читаются по документации конкретной ревизии. Дешёвый модуль с похожим внешним видом не считается электрически и программно взаимозаменяемым. [22][23]

MCU RX, GPIO20/J3-8, принимает TX радара. MCU TX, GPIO21/J3-7, идёт к RX радара. Названия TX и RX относятся к стороне, на которой написаны. Общая земля соединяется, если нет штатной гальванической развязки. Периферия RS-232 с отрицательными напряжениями или RS-485 с дифференциальными линиями сюда напрямую не подключается.

Сначала UART проверяется отдельно от сетевой прошивки: версия, одна команда, один ответ, обработка частичного кадра. Далее добавляются неверная длина, обрыв потока и перезагрузка радара. Только после этого измерения участвуют в состоянии Occupied.

PIR и радар лучше установить на разъёмных кронштейнах. Это позволяет менять направление без переделки электронного узла. В конечном корпусе нельзя перекрывать радар металлом, а PIR — произвольной прозрачной пластмассой: оптический тракт PIR определяется его линзой и рабочим диапазоном, а не видимой прозрачностью материала. [20][22]

Карта A-01. Реле и лампа 12 В#

Первый исполнитель — документированный готовый релейный модуль с драйвером катушки, входом управления, совместимым с C6, и подходящим DC-рейтингом контактов. VIN, GND и SIG подключаются по схеме этого модуля. GPIO10/J1-10 служит сигналом, но не питает катушку. Конкретный STEMMA-модуль рассмотрен как опорный пример, не как единственно доступный товар. [24][25]

Сухие контакты реле не требуют объединения минуса 12-вольтового адаптера с GND контроллера. Но добавление измерителя тока, неразвязанного датчика напряжения или другого интерфейса может создать такое соединение. Тогда схему доменов пересматривают; нельзя продолжать называть тракт развязанным только из-за наличия реле.

При холодном старте выход удерживается в OFF аппаратной подтяжкой и правильной полярностью драйвера. Нельзя сначала переключить GPIO в выход с случайным значением, а потом рассчитывать, что задача сети успеет его исправить. Активный LOW модуль требует противоположной логики удержания; такую замену фиксируют как другую аппаратную конфигурацию.

Кнопка вызывает ту же предметную команду set или локальную явно определённую операцию, а не запись в GPIO параллельно с сетевым обработчиком. У выхода один владелец состояния. Для светового стенда ручная команда может создавать временное переопределение автоматики. Для будущего опасного привода аппаратный STOP проектируется отдельно и не заменяется кнопкой, которую опрашивает задача MCU.

Приёмка проводки#

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

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

Первая подача питания#

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

Не объединять две исправные сборки вслепую#

До объединения запишите, откуда питается каждый модуль и где проходит общий провод сигнала. USB от ПК, отдельный адаптер и внешняя нагрузка могут образовать несколько путей тока. В готовой схеме должен быть один понятный путь для каждой цепи; решение об общей земле принимается по интерфейсу, а не по цвету провода.

После добавления следующего узла повторите прежние проверки. Например, с работающим радио и реле снова измерьте минимальное питание сенсора и проверьте обмен I²C. Так обнаруживается не только ошибка нового провода, но и влияние новой нагрузки на уже работавшую часть.

Что делает монтажную карту исполнимой#

Перед электрической сборкой из вариантов выбирается один экземпляр BOM: фото маркировок и ревизий, напряжения каждого VIN, полярность IN, адаптер и нагрузка, держатель/F1, сечение провода, точные клеммы. Неопределённая строка «подать допустимое питание» считается открытым полем карты. Она не закрывается предположением о похожем товаре с маркетплейса.

Для S/P/A-карт добавляется проверка обратного питания через USB, GPIO, I²C и UART: измеряется отключённая шина при работающем соседнем модуле. Две логические схемы с общим GND не делают все режимы подачи питания безопасными. Особое внимание — USB от ПК одновременно с отдельным адаптером Actuator. В рабочем Actuator закрытый источник 5 В подаёт питание через выбранный штатный вход платы и согласованный жгут к драйверу реле; питание нагрузки 12 В проходит своей цепью. Конкретный вход, возвратный провод и допустимый ток фиксируются по схеме ревизии DevKit и модуля до включения. USB Hub не служит штатным источником Actuator. Сервисный USB подключается только после выбора проверенного способа исключить объединение источников: поддержанная платой развязка или документированное отключение одной питающей ветви. Произвольное удаление VBUS не обещает работоспособного USB-обмена. Приёмка проверяет кнопку с выключенным Hub и каждое разрешённое сочетание источников.

Задача первой собственной PCB — сократить ненадёжные соединения. Сложность отладочной платы переносится в неё только при подтверждённой необходимости.

Разумная первая плата Koobique — носитель готового MCU-модуля или DevKit, разъёмы сенсоров, питание, кнопка и тестовые точки. Не нужно одновременно разводить RF, USB высокой сложности, собственный DC/DC и релейный исполнитель, если ещё не проверен базовый сценарий. Разделение Sense и силового узла помогает локализовать помехи и ошибки.

Рассмотреть схему

Три уровня самостоятельности#

На первом уровне используются готовые модули и паяная монтажная плата. На втором — собственный носитель с фиксированными разъёмами и известной распиновкой. На третьем — модуль ESP32-C6-WROOM-1 / MINI-1 на своей плате с питанием и программированием. Переход на голый SoC имеет смысл только при понятной причине: ограничения размеров, питания или количества экземпляров.

Модуль сохраняет уже выполненную RF-часть, но требует соблюдения правил размещения антенны и питания. Документ Espressif содержит рекомендации для ESP32-C6 по слоям, земле, антенне и периферии; он важнее фотографии похожего устройства. [81]

Схема раньше дорожек#

Сначала составляются схема и таблица сетей: имя сигнала, напряжение, направление, безопасное состояние и разъём. Затем назначаются footprint по точному компоненту. Совпадение названия корпуса не гарантирует совпадение нумерации выводов. Каждый новый footprint проверяется по datasheet и пробной распечатке 1:1.

ERC находит часть ошибок схемы, DRC — часть ошибок платы. Ни одна проверка не знает, что разъём на фотографии продавца установлен зеркально или что датчик нагревается соседним стабилизатором. KiCad включает связанный процесс схема → плата → проверка → производственные файлы; учебник выбранной версии полезен для первого прохода. [27]

Два или четыре слоя#

Простой носитель с короткой I²C и готовым модулем можно исследовать на двух слоях. При плотной цифровой разводке и необходимости устойчивой опорной земли четыре слоя часто дают более предсказуемую конструкцию. Это не правило «четыре всегда лучше»: важны реальный stackup производителя, расстояния между слоями и непрерывность возвратного пути.

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

Рассмотреть схему

Питание и развязка#

Развязывающие конденсаторы ставятся близко к соответствующим выводам с коротким возвратом, а не группируются в свободном углу платы. Источник питания выбирается по пиковому току и переходной характеристике. Широкая дорожка не устраняет индуктивность длинного пути; измерять нужно напряжение у потребителя.

Силовой ток реле или лампы не пропускают через тонкий общий участок, по которому возвращается чувствительное измерение. USB, UART и GPIO на внешних разъёмах требуют оценки электростатики и ошибок подключения. Защитный элемент выбирается по напряжению, ёмкости и энергии, а не по одному слову TVS.

Тестовые точки и ремонт#

На плате доступны GND, вход питания, 3V3, reset, boot и диагностический UART/USB. Точки подписаны так, чтобы к ним можно было подключиться уже в корпусе. Силовой узел имеет возможность безопасно отключить нагрузку для прошивки. У реле и разъёмов оставляется место для паяльника и вынимания штекера.

Для первых плат полезны крупные пассивные компоненты и доступная пайка. Мелкий корпус ради эстетики повышает риск ошибки и не делает единичный экземпляр качественнее. Предусмотренные нулевые резисторы/перемычки могут облегчить измерение тока и изоляцию неисправного домена.

Где заказать из Тулы#

Местный подрядчик необязателен. Резонит публикует услугу изготовления опытных плат и варианты доставки; Электроконнект — изготовление единичных прототипов. Это подтверждённые каналы для запроса расчёта, а не обещание конкретной цены, сроков или доступности монтажа для нашего заказа. Доставку в Тулу, минимальный заказ, работу с физлицом и монтаж уточняют перед оплатой. [28][29][30]

Для расчёта нужны Gerber/Excellon, размеры, число слоёв, толщина, медь, покрытие и требования. Для монтажа дополнительно нужны BOM, pick-and-place, сборочный чертёж, полярности и перечень допустимых замен. Gerber-only не содержит всех данных о том, что должно быть установлено.

Минимальный выпуск E0#

Заказать сначала малый набор носителей, а не все будущие устройства. Собрать одну плату, проверить питание без MCU, затем с MCU, потом с датчиками. Сохранить фотографии, напряжения, потребление и список доработок. Вторую плату собирать по исправленной инструкции, чтобы проверить воспроизводимость.

Язык снижает часть рисков памяти, но не отменяет аппаратные ограничения и проверку всего стека.

У ESP есть два принципиальных Rust-пути. Первый использует ESP-IDF через Rust-обвязки и получает сетевой стек, RTOS и сервисы SDK. Второй строится на esp-hal без стандартной библиотеки и даёт больше контроля над памятью и исполнением. Для Koobique важно не выбрать «самый чистый Rust», а получить проверяемое устройство с безопасной сетью, обновлением и локальным выходом.

ESP-IDF или no_std#

Репозиторий Rust-обвязок ESP-IDF прямо описывает ограничения сопровождения сообщества и возможное отставание; официальный esp-hal имеет другую модель развития. The Rust on ESP Book предупреждает об изменениях нестабильных API. Это не причина отказаться от Rust, а причина фиксировать toolchain и испытывать выбранную комбинацию. [31][32][33]

Для первого Wi-Fi-профиля предлагаем Rust + ESP-IDF с проверенной версией SDK. Ветка no_std выполняет тот же контракт устройства, но не должна задерживать сборку основного стенда. Общие типы сообщений и тестовые векторы не зависят от конкретной RTOS.

Память — измерять в худший момент#

Пик может возникнуть не при обычной телеметрии, а во время BLE-сопряжения, TLS-handshake и OTA. Заранее освобождённая BLE-память после настройки полезна, если BLE больше не требуется. Внутренние лимиты сообщений должны быть значительно меньше всей доступной RAM; буфер «на всякий случай 64 КБ» в каждом слое быстро исчерпывает MCU.

Mbed TLS в актуальной ESP-IDF имеет профили конфигурации; минимальный preset может не включать TLS 1.3, хотя другая конфигурация его поддерживает. Поэтому профиль Koobique фиксирует разрешённую версию и проверяет реальный handshake с Rustls, а не полагается на название SDK. [34]

Нужны измерения свободной памяти, крупнейшего свободного блока, пиков стека и отказов выделения. Успешный запуск один раз не доказывает отсутствие фрагментации после тысячи переподключений.

Задачи и приоритеты#

Локальный владелец выхода обрабатывает короткие события кнопки и команды. Опрос датчика имеет ограничение времени. Сетевая задача занимается соединением и передачей. Обновление выполняется отдельным режимом с согласованным безопасным состоянием. Тяжёлое форматирование логов и запись flash не происходят в обработчике прерывания.

Рассмотреть схему

ISR фиксирует минимальные данные и передаёт событие. volatile не заменяет атомарность и синхронизацию. Общий изменяемый доступ к периферии ограничивается одним владельцем или явно синхронизированным интерфейсом. Блокировка, удерживаемая во время сетевого ожидания, может остановить кнопку — это недопустимая граница ответственности.

Ошибки как часть интерфейса#

Драйвер возвращает различимые ошибки: нет ответа, неверный CRC, превышен диапазон, устаревшие данные, периферия не инициализирована. В зависимости от причины выполняется повтор, переинициализация шины или перевод канала в недоступный режим. Бесконечный retry без задержки способен перегрузить шину и журнал.

Watchdog должен проверять продвижение задач, а не просто обслуживаться из отдельного живого таймера. Если управление выходом зависло, но таймер продолжает «кормить собаку», защита не выполняет задачу. После reset сохраняется причина, насколько это поддерживается аппаратурой; она передаётся станции для диагностики.

Flash и обновление#

Разделы для конфигурации, двух образов и служебных данных определяются после измерения размера прошивки. Запись каждого измерения во flash не допускается по умолчанию. Частые счётчики хранятся в RAM или агрегируются; критичная идентичность и параметры имеют отдельную политику записи.

Secure Boot и защита flash исследуются на отладочных устройствах с пониманием необратимых настроек. Производственные eFuse нельзя прожигать до проверки восстановления и хранения ключей. Отладочный доступ удобен на стенде, но для постоянно используемого устройства является частью модели угроз. [35][36]

Gate прошивки#

Узел должен пережить многократные Wi-Fi-обрывы, отказ датчика, переполнение входного сообщения, повтор команды и перезапуск во время обмена. Физическая кнопка и безопасный выход проверяются не только при исправной сети. Версии Rust, ESP-IDF, зависимостей и sdkconfig сохраняются вместе с результатами.

Отладочная плата и защищённый прибор — два режима#

NVS-шифрование не следует считать автоматическим следствием Flash Encryption. Выбранная схема и ключи фиксируются отдельно. Конфиденциальность flash также не доказывает защиту от возврата старого корректно зашифрованного образа: если в модели угроз есть физический rollback, потребуется отдельная защита состояния владения. Для E0 этот класс атак не объявляется решённым. [150][151]

Ключ и boot_id генерируются на самом MCU при выполненных условиях аппаратной энтропии. В ESP-IDF качество RNG зависит от включённых источников; вызов esp_fill_random сразу после старта приложения сам по себе не доказывает достаточную случайность. Случайный boot_id — часть защиты от старой команды, поэтому тест генерации идентичности входит в обязательный опыт. [152]

Первый технологический опыт — одна зафиксированная связка#

До остальной прошивки проверяется один C6: выбранные Rust toolchain, esp-idf-sys/hal/svc, SDK и sdkconfig; BLE с уникальным provisioning-секретом; TLS 1.3 с Core; одна команда; кнопка под нагрузкой; прерванное OTA. Измеряют min-free heap, largest-free-block, стеки, размер подписанного образа, паузы flash и задержку кнопки. Эти версии пока не названы «проверенными» — карточка заполняется только выводами реальной сборки.

Одновременность режимов ограничена: provisioning и OTA не работают вместе; не более одного bulk-сеанса; после onboarding BLE освобождается, если профиль это позволяет. Неудача опыта сначала приводит к пересмотру конкурентности и SDK, а не к выводу, что любой Rust-путь слишком тяжёлый.

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

Koobique OS — продуктовая платформа поверх Linux. Linux управляет процессами, памятью, накопителями, радио и аудио. Rust-core интерпретирует физические данные и оркестрирует устройства. Такое разделение сохраняет контроль над системой, не требуя переписать USB, Wi-Fi и планировщик.

Системная основа#

Для первого x86-экземпляра предлагается стабильный Debian без графического рабочего стола и с фиксированным набором пакетов. Это облегчает диагностику, обновление драйверов и работу с инструментами. Для более управляемого образа позже сравниваются Buildroot и готовая A/B-инфраструктура. Малый размер образа полезен, но не должен стоить потери воспроизводимого восстановления. [37][90]

Необходимые службы: менеджер сети, SSH, синхронизация времени при наличии источника, журнал, Koobique-core, ограниченный привилегированный helper, аудиослужба и опциональные inference-workers. Нет обязательного Node.js, браузера, Kubernetes или Redis. Контейнеры могут использоваться для сборки и испытаний; их наличие на самой станции — отдельное решение.

Последовательность загрузки#

Рассмотреть схему

UEFI и загрузчик передают управление ядру. Драйверы поднимают накопитель и сеть. Системные службы запускают Core после доступности обязательных ресурсов. Core читает конфигурацию, отмечает восстановленные наблюдения как потенциально устаревшие, открывает API и ждёт свежего состояния узлов.

Готовность разбивается на уровни: процесс жив; конфигурация читается; локальный API доступен; сеть работает; конкретный узел синхронизирован. Один зелёный индикатор «всё хорошо» скрывает слишком много. Приложение должно объяснять, что именно ещё не готово.

Драйверы и идентификация оборудования#

Wi-Fi проверяется по PCI/USB ID и версии firmware. Аудио — по реально доступным каналам, частотам и поведению USB. Датчики CPU/платы — по драйверу hwmon и смыслу каждого показания. Например, k10temp документирует температурные каналы AMD; это не даёт права трактовать любое число hwmon как температуру воздуха. [38][39][40]

На ARM важны Device Tree и точная аппаратная ревизия. Неверное описание контакта или периферии может выглядеть как ошибка пользовательской программы. На типичной x86-платформе многие устройства описываются иначе; копировать инструкции настройки GPIO с Pi на Mini-ITX нельзя. [74]

Стабильные имена устройств формируются через udev по свойствам, а не по случайному /dev/ttyUSB0. Два подключённых ESP-модуля могут поменяться номерами после перезагрузки. Ошибка идентификации здесь опаснее отсутствия соединения: программа может отправить команду не тому исполнительному узлу.

Изоляция процессов#

Core работает без root. Доступ к USB, Bluetooth и аудио выдаётся конкретным сервисам. Привилегированный helper принимает узкий набор структурированных запросов: применить сетевой профиль, переключить образ, собрать диагностические сведения. Он не исполняет произвольную строку shell из приложения.

systemd/cgroup позволяют ограничить память, CPU и другие ресурсы служб. Speech-worker получает меньший приоритет доступности, чем управление. Но ограничения не должны быть настолько жёсткими, чтобы постоянно вызывать перезапуски и новую загрузку модели. Нужен запас и ограничение очереди запросов. [41]

Время, журнал и диск#

Относительные таймеры используют монотонные часы. Календарные расписания — часовую зону и явно обработанные скачки времени. После включения без интернета RTC помогает восстановить приблизительное время, но его точность проверяется. Истечение сертификатов не решается отключением всей проверки доверия.

Журнал имеет лимит объёма, ротацию и маскирование секретов. Пароль Wi-Fi, токен восстановления и аудиозапись не должны попадать в общий debug-log. При заполнении диска система сокращает диагностические данные раньше, чем теряет возможность сохранить критическую конфигурацию. Для этого требуется запас места и отдельные пороги.

Оптимизация без слепых отключений#

Сначала профилируется штатная система. Проверяются CPU governor, задержка пробуждения, нагрузка IRQ, запись диска и влияние аудио. Затем меняется один параметр и повторяется полный тест. Отключение защиты памяти, TLS-проверки или mitigations ради микросекунд не считается допустимой оптимизацией качества.

Системная приёмка#

После холодной загрузки проверить сеть, время, БД, USB-идентичности и локальный API. Остановить каждый необязательный worker и убедиться, что Core остаётся доступным. Проверить возвращение питания, свободное место, журнал причины сбоя и локальный SSH без внешнего сервиса.

Служба должна загрузиться даже без роутера#

Core стартует с локальным хранилищем и диагностикой без ожидания network-online.target. Появление адреса и смена сети обрабатываются как события. Для systemd выбираются Type=notify, WatchdogSec и ограниченные перезапуски; уведомление watchdog выдаётся только при продвижении критических задач. Слепой таймер, живущий отдельно от зависшего исполнителя, не подтверждает здоровье службы. [160][161]

В карте установки: Restore on AC Power Loss в UEFI/BIOS, политика сна H0, журнальные квоты, права на /data, nftables, SSH по ключам и отдельная сервисная учётная запись. Доступ к отладке не означает постоянную публикацию SSH на внешнем интерфейсе. Сначала проверяются локальный запуск и восстановление, затем удалённый путь.

Качество ядра определяется тем, можно ли объяснить каждую команду и ограничить последствия каждого входа.

ABI — двоичный договор между скомпилированными компонентами · IPC — обмен между процессами

В центре Koobique находится один процесс с несколькими явными подсистемами: реестр, наблюдения, оценки состояния, политики, исполнитель команд, адаптеры и хранилище. Внешний API и собственный протокол не должны обходить общий путь проверки прав и ограничений. Голос, приложение и локальная автоматизация создают разные источники намерений, но не три независимых механизма включения реле.

Рассмотреть схему

Предлагаемые crates#

koobique-domain содержит идентификаторы, величины, состояния команд и проверки инвариантов. koobique-wire — кодирование, лимиты и тестовые векторы протокола. Оба по возможности не зависят от Linux и могут иметь no_std-профиль для устройств.

koobique-core реализует реестр, очереди и исполнитель. koobique-storage — транзакции и запросы. koobique-api — мобильный и диагностический интерфейс. koobique-adapter- * — конкретные способы связи. koobique-sim — виртуальные датчики и устройства. Отдельные executables отвечают за privileged-helper, speech-worker и CLI.

Структура не должна порождать десятки пустых библиотек: модуль выделяется, когда у него есть собственный контракт или зависимость. Главное — направление зависимостей. Физическая модель не должна знать о конкретной SQL-таблице или библиотеке BLE.

Владение состоянием#

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

Глобальный Mutex<HashMap<...>>, удерживаемый при записи в БД или сетевом ожидании, создаёт скрытую сериализацию всей системы. Tokio отдельно описывает риски удержания блокировок и блокирующих операций в асинхронном исполнении. Это основание для коротких критических секций и явных очередей, а не для запрета всех mutex. [45][82]

Ограниченные очереди#

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

Предлагаемые классы: управление и safety-события; актуальное состояние; обычная история; диагностика и большие передачи. Нельзя позволить экспорту графиков занять все буферы и задержать выключение. Однако чрезмерный приоритет одной очереди может голодать остальные, поэтому нужен ограниченный квант обработки и метрика возраста события.

Детерминированная логика#

Чистая функция решения получает snapshot состояния, версию правил и время из внедрённого источника, затем возвращает намерения и объяснение. Она не читает часы и сеть из произвольных мест. Это позволяет воспроизводить ситуацию по журналу и сравнивать новую версию алгоритма без отправки реальных команд.

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

Наблюдаемость и диагностика#

У каждой команды есть trace ID и источник: приложение, правило, кнопка, голос. Журнал связывает её с использованными наблюдениями, версией политики и ответом устройства. Метрики включают возраст данных, глубину очереди, время ожидания записи, число переподключений и неизвестные результаты.

Логи не являются единственным источником истины. Состояние команды хранится структурированно; текстовый лог помогает человеку. Не следует реконструировать текущую конфигурацию из случайных строк info! после перезапуска.

Где Rust не обязан быть единственным языком#

SQLite, драйверы Linux и зрелые inference-библиотеки могут быть реализованы на других языках. Это не нарушает цель собственного Rust-ядра. Через FFI нужно ограничить время жизни буферов, потоки, отмену и обработку ошибок. Более рискованный ML-runtime лучше изолировать процессом, чем пытаться доказать его безопасность одной обёрткой unsafe.

Rustls предоставляет готовую TLS-реализацию и выбор криптографических провайдеров. Axum удобен для HTTP-API и диагностического интерфейса; использование их не превращает Koobique в готовую чужую платформу. [46][47]

Первый benchmark ядра#

Симулятор подаёт события с управляемой частотой, задержками и сбоями. Одновременно выполняются команды и экспорт истории. Измеряются p50/p95/p99, максимальный возраст события и память. Сначала исправляются неограниченные очереди и блокировки, а уже потом обсуждаются lock-free и низкоуровневые оптимизации.

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

Что находится в одном ядре#

Предлагаем модульный Rust-процесс с явными границами: реестр объектов и возможностей; приём и проверка наблюдений; актуальное состояние; оценщики; планировщик процессов; арбитр полномочий; исполнитель; журнал и API. Это логические модули, не обязательные сетевые микросервисы.

Общий код контрактов отделён от Linux, Tokio и базы. В нём находятся типы, версии, единицы, пределы сообщений и преобразования. На устройстве используются только подходящие по памяти части. Семантически значимые поля не передаются как неограниченные строки без схемы. Внутри Rust можно использовать размерностно-типизированные величины, например подход uom. [107] Это снижает риск смешения единиц в коде, но не исправляет неверный внешний дескриптор: данные проверяются на границе.

Рассмотреть схему

Очереди и давление нагрузки#

Для каждого источника ограничиваем размер сообщения, частоту и память очереди. Команды и подтверждения не стоят за многомегабайтным аудиофрагментом. Потеря телеметрии фиксируется; потеря критического управляющего события не маскируется таким же механизмом сброса.

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

Одно устройство имеет последовательный поток исполнения команд. Разные независимые ресурсы могут обрабатываться параллельно. Не нужен глобальный mutex вокруг всего «мира», но и повсеместный lock-free не является автоматическим выигрышем. Длительное удержание блокировки и блокирующий код внутри асинхронной задачи способны задерживать другие задачи; это прямо разбирается в документации Tokio. [82]

Два разных срока#

Deadline вычисления определяет, когда результат модели ещё полезен. Срок команды — до какого момента разрешено физическое действие. Завершившийся позже deadline прогноз отправляется в диагностику, не в исполнение. Актуальность проверяется по монотонному времени станции и текущей эпохе управления.

Отмена Rust future не гарантирует остановку уже запущенного синхронного native-инференса. Поэтому тяжёлые модели выполняются в отдельном worker-процессе с ограниченным IPC. При зависании процесс можно завершить; состояние ядра и локальное управление остаются целыми.

Отмена ожидания не останавливает физический мир#

У тайм-аута есть точный предел действия. Tokio может прекратить ожидание future, но длительное вычисление, которое не возвращает управление планировщику, способно превысить заданное время. Уже начавшую работу функцию в spawn_blocking нельзя остановить вызовом abort. Поэтому этот механизм не является аварийным выключателем инференса. [142][143]

В нашей архитектуре запрос к вычислительному помощнику получает ID, снимок состояния и дедлайн. Поздний ответ помечается как непригодный к исполнению. При зависании отдельный процесс можно перезапустить; само право на действие при этом не передаётся ни этому процессу, ни его ответу. Устройство отдельно ограничивает свой выход.

Пример: модель начала распознавать команду, человек нажал OFF, а распознавание закончилось позже. Отмена запроса полезна для ресурсов, но правильность обеспечивает другое: старая эпоха и версия состояния не проходят проверку исполнителя. Даже если поздний ответ дошёл, он не отменяет кнопку.

Выбор ML-runtime#

Наш собственный производственный код остаётся на Rust. Это не означает, что Linux, драйвер GPU или все математические ядра также написаны на Rust. Безопасность FFI, совместимость ABI и происхождение native-библиотек проверяются отдельно.

Изоляция ресурсов#

Linux cgroups v2 позволяет ограничивать и учитывать ресурсы процессов, включая CPU, память и I/O. [132] Это полезный механизм отделения worker от ядра, но не доказательство жёсткого реального времени и не универсальный контроль каждой GPU-операции.

При нехватке памяти первой ограничивается история/инференс по заданной политике, а не исчезает способность обработать кнопку. Для критических физических реакций сохраняется локальный путь устройства. Резерв вычислителя проверяем совместной нагрузкой, а не суммой красивых паспортных цифр.

Начальная конструкция: один Rust-core, отдельный AI-worker, отдельный узкий сервис привилегированных операций и существующие системные службы Linux. Дробление на большее число процессов оправдывается измерением или анализом отказов.

Границы процессов и устройств#

Внутри Core остаются протокольные адаптеры без привилегированного доступа. Работа с USB/BT вынесена в device-agent; так устраняется двойное описание одной границы. Если конкретный E0 не использует BLE на Hub, этот процесс просто не запускается.

Критические задачи Rust регистрируются у супервизора: результат JoinHandle нельзя игнорировать. Для E0 предлагается fail-stop Core при потере владельца команд и перезапуск systemd; выбор panic=abort либо контролируемого unwind фиксируется сборкой и тестом. Синхронная SQLite работает на выделенном потоке; длительное вычисление не попадает в сетевой executor. [162]

Протокол описывает смысл, пределы и восстановление. Двоичная упаковка — только один из его слоёв.

KQIP — Koobique Interface Protocol, собственный прикладной язык Koobique. Текущий проектный профиль — E0 поверх кадра 0.2; совместимых реализаций пока нет. Для первого узла выбираются TCP, TLS 1.3 и ограниченный CBOR. Прежний 27-байтовый Hello 0.1 оставлен в главе 22 только как учебный разбор, не как рабочий handshake.

Почему не собственный UDP сразу#

TCP снимает с первой реализации часть задач доставки и контроля потока. Это не означает его оптимальность для каждого будущего носимого датчика. BLE, QUIC или UDP-профиль могут появиться позднее при конкретной необходимости. Прикладные идентификаторы, команды, ошибки и синхронизация должны переноситься между транспортами без изменения смысла.

TLS обеспечивает защищённый канал; права доступа и допустимость команды проверяются отдельно. CBOR удобен компактным представлением и возможностью ограниченной реализации. minicbor поддерживает сценарии без стандартной библиотеки. Использование этих механизмов не отменяет собственную спецификацию. [47][48] [49][50]

Кадр 0.2 и профиль E0#

Рассмотреть схему

Многобайтовые числа заголовка передаются в network byte order. Тело не является memcpy Rust-структуры: выравнивание, endian и enum representation не входят в переносимый контракт. Ключи CBOR имеют закреплённые номера и смысл.

В исправленном проектном профиле E0 / KQIP 0.2, revision R3-draft тело ограничено 4096 байтами, вложенность — 8 уровнями, строка — 128 байтами UTF-8, byte string — 1024 байтами, массив — 256 элементами, карта — 32 полями; конкретное поле может иметь меньший предел. Запрещены повторные ключи, indefinite-length, теги, floats, NaN и Infinity. Измерения используют нормализованную целую мантиссу и десятичный показатель. Канонические значения находятся в contracts/registry.json; таблицы и схемы генерируются из него. Bulk/OTA при необходимости использует отдельный ограниченный канал: приоритет очереди не обгоняет байты, уже переданные TCP. [48]

Сообщения и совместимость#

Канонический набор KQIP 0.2: Hello, Ready, Describe, Snapshot, Observation, Event, Command, CommandResult, StatusQuery, Resync, Ping, Pong, TelemetryAck и Error. Имена HelloAck, CommandStatusQuery, SyncRequest и SyncReply не являются дополнительными типами этого профиля. Успешный TLS ещё не разрешает команды: проверяются связанная с ключом идентичность, роль и установка, профиль, дескриптор, snapshot и пригодная оценка часов. Полная машина соединения и её интероперабельность остаются отдельной приёмкой.

В спецификации нужны примеры корректных байтов, заведомо неправильные пакеты и ожидаемые ошибки. Один набор golden vectors проверяет реализации KQIP на Core и MCU и любую дополнительную сторону, если она явно получает роль участника этого протокола. Мобильный клиент по умолчанию обращается к отдельному Client API. Версия устройства, версии capability и версия кадра — отдельные величины.

Идентификаторы и повторы#

Узел имеет постоянный ID, каждая загрузка — boot_id, каждое наблюдение — номер последовательности. Команда имеет 128-битный command_id, выбранный инициатором и сохраняемый при повторе. Session_seq не заменяет command_id: после переподключения прикладной смысл команды остаётся прежним.

set(on) удобнее toggle, но одной идемпотентности значения недостаточно. Между двумя доставками пользователь мог нажать OFF. Повтор прежнего ID тогда возвращает сохранённый результат без нового действия; при отсутствии записи срабатывает защита от старого execution_seq. Для дозирования, шага мотора и других необратимых операций E0 не выдаёт допуска. Повтор toggle инвертировал бы уже изменённый выход, тогда как SET задаёт требуемое значение явно. Сбой между физическим эффектом и записью результата всё равно оставляет неопределённость: гарантия exactly-once для физического мира не заявляется.

Когда команда считается принятой#

Рассмотреть схему

ACCEPTED означает транзакционную запись намерения в Core. DISPATCHED — попытку передачи, не доставку. RECEIVED относится к получению MCU, APPLIED — к историческому результату операции. Текущее состояние хранится отдельным Snapshot. VERIFIED допустимо лишь как состояние отдельного EffectEvidence; оно не делает исторический ON текущим после более нового OFF. UNKNOWN означает недостаток знания и может уточняться позднее.

Первое получение после not_after_device_us не разрешает действие. Повтор уже выполненной команды возвращает исторический результат, даже если срок нового исполнения истёк: таймер не стирает прошлое. StatusQuery только читает историю и не может снова включить выход. По окончании срока новая попытка — новый ID, новое решение и подтверждённый пользовательский смысл, а не скрытое продление старого намерения.

Порядок, snapshots и большие потоки#

Snapshot содержит boot_id, controller_fence, output_revision, manual_revision, выход и ручной режим. Старый ACK не обновляет плитку. История с меткой backfill не становится живым триггером. OTA использует отдельный bulk-канал; его пауза при управляющей нагрузке не заменяет испытания конкуренции за радио и CPU. Для профиля с OTA образ передаётся ограниченными фрагментами с проверяемыми offset, длиной и принадлежностью одному подписанному образу. Размер фрагмента ограничивается до выделения буфера; бесконечный CBOR-массив или всё содержимое образа в одном сообщении не допускаются. Чанки и восстановление передачи остаются отдельной приёмкой E1.

TCP гарантирует порядок байтов в одном соединении, но не создаёт общий порядок между разными устройствами. Станция не должна делать вывод, что датчик A измерил раньше B только потому, что его пакет первым попал в сокет.

Безопасная обработка#

Длины проверяются до выделения буфера. Handshake ограничен по времени и числу параллельных попыток. Неизвестный peer не получает бесконечный ресурс парсера. CBOR-парсер проверяется fuzz-тестами; журнал не печатает неограниченную строку из пакета.

TLS 0-RTT для управляющих действий в первом профиле отключается из-за риска повторного воспроизведения. Дополнительный CRC не является заменой аутентификации. Перед изменением версии сохраняются тесты старого поведения и правила отказа от несовместимого соединения. [50]

Реестр E0 и жизненный цикл соединения#

TLS → Hello в обе стороны → проверка роли/версии/лимитов → Ready → запрос Snapshot/Describe → синхронизация → ACTIVE. Command до ACTIVE отклоняется. После смены boot или descriptor Core снимает допуск автоматизации до повторной проверки. Несовместимость 0.1 и 0.2 не маскируется minor-обновлением: обе стороны E0 обязаны явно поддерживать 0.2.

session_seq — порядковый номер кадра в одном направлении одной TLS-сессии. На reconnect начинается с 1; он обнаруживает ошибку потока, а не служит защитой от повторного физического действия. Для связи ответов используется command_id либо поле reply_to. Magic KQB1 оставлен как историческая сигнатура; цифра не объявляется номером текущего профиля.

Строгий CBOR без ловушек сравнения#

E0 принимает только детерминированное кодирование: кратчайшие целые, упорядоченные числовые ключи, конечные длины контейнеров. Повтор ключа, float любого размера, NaN/Infinity, теги, indefinite-length и неизвестный ключ 1…127 отклоняются. Поля 128…255 могут быть только документированными некритичными расширениями; права, сроки, версии и запреты нельзя поместить туда. Новое обязательное поле требует нового профиля. Подписанные билеты COSE имеют отдельную схему контейнера и не отменяют ограничения обычного сообщения. [48][149]

Общие пределы: тело 4096 байт, вложенность 8, map до 32 элементов, array до 256 элементов, строка до 128 байт, bstr до 1024 байт, если тип не задаёт меньший предел. ID — ровно 16 байт; counters — uint64 с проверкой переполнения. Длины и типы проверяются до резервирования памяти. Декодер не должен принимать true как целое 1 или выбирать «последнее» значение повторного ключа.

Два канала и ограниченные очереди#

В E0 управление и небольшая текущая телеметрия используют основное TLS/TCP-соединение. OTA и длинная история — отдельное TLS-соединение с той же проверенной идентичностью и ограничением скорости. Приоритет в очереди не позволяет обогнать байты, уже переданные одному TCP-потоку. Разделение соединений также не отменяет конкуренции за Wi-Fi, flash и CPU; обновление не проходит допуск без измерений задержки кнопки и команд под нагрузкой.

Начальные сетевые лимиты: handshake до 5 с, до 4 незавершённых handshake на Hub суммарно для E0, один управляющий и один bulk-сеанс на узел, Ping раз в 10 с и разрыв после трёх отсутствующих ответов. Это проектные значения с возможностью измеренного изменения. TCP_USER_TIMEOUT применяется только там, где его поддерживает стек. Потеря heartbeat сообщает о канале, но не доказывает пустоту комнаты.

TelemetryAck содержит boot_id, channel_id, durable_through_seq и credit. Курсор продвигается только по непрерывно сохранённому диапазону либо после явно записанного Gap. «Получено в RAM» и «сохранено» не смешиваются. Узел не освобождает надёжный буфер по подтверждению только сетевого приёма. Backfill остаётся историей даже при только что установленном соединении.

Почему собственный протокол — осознанная стоимость#

CoAP + OSCORE/EDHOC, Matter и MQTT-профили остаются альтернативами транспорта и интеграции. SenML подходит для обмена простыми сенсорными величинами. KQIP выбран ради собственного учебного проекта и единого договора исполнения, не потому, что доказан быстрее готовых протоколов. При экспорте в SenML нельзя терять boot, интервал, калибровку и размещение: невыразимые поля идут в сопроводительные метаданные. [169][170][168]

Здесь собран текущий проектный E0 и отмечены учебные эскизы. Проверенные байты не означают проверенный TLS, MCU или приложение.

Наблюдение в читаемом представлении#

Ниже приведён диагностический JSON с числовыми ключами закреплённого профиля KQIP 0.2. В JSON ключи записаны строками, а бинарные ID — шестнадцатеричным текстом; на проводе это целочисленные ключи CBOR и byte strings. Соответствие ключей типам и полям задаёт contracts/generated/SPEC_RU.md. JSON служит представлением пакета для чтения, а не альтернативным форматом передачи. UUID, идентификатор загрузки и последовательность не взаимозаменяемы.

{
  "1": "11111111111111111111111111111111",
  "2": 1,
  "3": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "4": 1042,
  "5": 120000000,
  "6": 120010000,
  "7": 234,
  "8": -1,
  "9": 1,
  "10": 0,
  "11": 0,
  "12": 3,
  "13": 2,
  "14": 1,
  "15": 0
}

В Observation ключи 1 и 3 обозначают ID узла и загрузки: каждый показан 32 шестнадцатеричными знаками, то есть 16 байтами. Ключ 2 выбирает канал 1, который descriptor определяет как sensor_temperature. Ключи 7 и 8 задают мантиссу 234 и показатель −1; ключ 9 выбирает единицу 1 — degC. Поэтому измерение равно 23,4 °C. Десятичная пара нормализуется: лишний ноль в мантиссе удаляется, пока показатель можно увеличить в разрешённом диапазоне; ноль имеет показатель 0. На проводе float и NaN в E0 не используются. Остальные обязательные поля, включая delivery_kind, расшифрованы в сгенерированной спецификации профиля.

sample_start_us и sample_end_us задают ограничивающий интервал получения отсчёта в шкале boot_id. Для SHT45 здесь 10 мс — консервативная граница от команды до чтения, а не паспортное интегрирование 15 мс. Сам датчик реагирует на изменение температуры значительно медленнее длительности преобразования. Эти два времени хранятся и используются по-разному. [157]

Одна запись на трёх уровнях#

Возьмём температуру 23,4 °C. На плате драйвер знает режим преобразования, локальное время и статус сенсора. Кодек передаёт эти сведения вместе с идентификаторами и числом. На станции запись дополняется временем приёма, оценкой преобразования часов, зарегистрированным размещением и ссылкой на калибровку. Часть метаданных может храниться в дескрипторе с устойчивой версией, а не повторяться в каждом коротком пакете.

Это разделение экономит сеть без потери смысла. Но оно требует правила: сервер не подставляет нынешнюю ревизию размещения в старую запись, если та была измерена в другом месте. Неизвестная ревизия остаётся неизвестной или требует повторного запроса описания. Сокращение пакета не даёт права придумать отсутствующую метаинформацию.

Capability и команда#

Описание канала сообщает тип данных, единицу, операции, пределы и способ подтверждения. relay.switch принимает boolean; датчик lux не становится записываемым только потому, что имеет поле value. Ограничения в описании проверяются также на устройстве: клиентская валидация приложения не является защитой.

{
  "1": "7c8b7b8e73104f21842a5d70a9b4b10a",
  "2": "22222222222222222222222222222222",
  "3": 1,
  "4": "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
  "5": 4,
  "6": 19,
  "7": 38,
  "8": 7,
  "9": 6969000,
  "10": 1,
  "11": true,
  "12": 0
}

В E0 предусловия обязательны: boot_id исполнителя, controller_fence, output_revision и manual_revision. Отсутствующее поле не разрешает безусловную установку. Сначала проверяются действующая авторизация и привязка к boot/fence. Для уже известного command_id в этой области кэш результата проверяется до сравнения изменяемых ревизий: совпадающее тело возвращает прежний результат без GPIO. Иначе потерянный ACK превратил бы успешный повтор в ложный конфликт. Новая команда проходит все текущие предусловия.

Срок нового исполнения фиксируется один раз. Core сохраняет своё время истечения в текущей загрузке и консервативно переводит его в not_after_device_us по интервальной оценке часов. Это поле не увеличивается при повторе. MCU проверяет собственные часы непосредственно перед изменением GPIO; он не запускает новый полный TTL с момента получения.

Исторический малый вектор 0.1: только устройство кадра#

Для объяснения длины сохранён прежний искусственный Hello 0.1: тип 0x0001 и тело {1: 1}, то есть a1 01 01. Эти 27 байт полезны как задача на декодирование; профиль E0 их отвергает по версии. Рабочие поля Hello и новые эталоны определены ниже и в комплекте protocol_r2. [48]

4b 51 42 31  00 01  00 01  00 00  00 18
00 00 00 03  00 00 00 00 00 00 00 01
a1 01 01

Первые четыре байта — ASCII KQB1. Далее идут major=0, minor=1, тип=1, flags=0, header_len=24, body_len=3, session_seq=1. Итого 27 байт прикладного кадра, не считая TLS/TCP/IP. При реальной передаче заголовок может прийти частями; один read не обязан вернуть целое сообщение.

Golden vectors сохраняются как независимые файлы: входные байты, ожидаемая структура и ожидаемая ошибка. Для несовместимой major-версии, повторяющегося ключа и слишком большого body_len должны существовать отрицательные примеры. Криптографический handshake не подменяется этим тестом: он проверяется отдельно.

Реестр ошибок#

Человекочитаемое сообщение не служит машинным кодом. Локализация русского и английского текста не должна ломать обработку ошибок. Диагностические детали не раскрывают секреты, существование чужих устройств или произвольные внутренние пути.

Планировщик узла и бюджет памяти#

При выборе ESP-IDF или no_std фиксируются реальные области памяти: сеть и криптография, стеки задач, очереди, драйверные буферы, OTA и запас на одновременные операции. Максимальный размер прикладного кадра 4096 байт не означает, что TLS-соединению нужно всего 4096 байт RAM.

Как учебный расчёт можно выделить очередь из 32 нормализованных событий по 96 байт: это 3072 байта полезных записей, ещё без служебных полей контейнера. Очередь 16 команд по 128 байт даёт 2048 байт. Размеры должны проверяться фактическим типом и сборкой. Общая RAM определяется пиковым сценарием BLE onboarding + Wi-Fi + TLS, а не спокойным измерением температуры.

При переполнении некритичной телеметрии допустимы объединение последнего значения и явный счётчик пропусков. Команда не теряется молча: RESOURCE_LIMIT возвращается до действия либо запрос помещается в надёжную очередь с заданным пределом. BUSY не является отдельным кодом исправленного реестра. События кнопки имеют защищённый бюджет очереди, чтобы поток UART радара их не вытеснил.

Временная дисциплина#

Сроки на Linux привязаны к CLOCK_BOOTTIME и host_boot_id. Rust Instant либо таймер Tokio не подменяют этот договор автоматически. После resume Core закрывает прежние рабочие сессии и пересогласует время; после reboot краткоживущий outbox не переисполняется. История фактически отправленных команд остаётся UNKNOWN до свидетельства, а не объявляется «никогда не выполненной». [145]

Clock sync полезен, но не делает разные часы одинаковыми. У записи сохраняется погрешность преобразования; при её росте уменьшается уверенность в порядке событий. Для первой проверки задержки используется полный RTT на одном клиенте. Физическое включение можно дополнительно измерить фотодатчиком и логическим анализатором с общей временной базой.

Совместимость трёх реализаций#

Общий Rust-кодек через UniFFI уменьшает риск расхождения приложения и ядра, но не заменяет независимый тест. MCU может использовать другую среду, ограничения памяти и транспортный стек. Kotlin/Swift glue должен сохранять бинарные данные, cancellation и срок жизни объектов без двойного освобождения и незавершённых подписок. [55]

Для каждого релиза собирается матрица: старое приложение — новый Core; новый Core — старая прошивка; повторное сопряжение после обновления; откат; неизвестная capability. Контракт обещает конкретный диапазон совместимости, а не абстрактное «всё со всем».

Расширенная логическая запись наблюдения включает интервал измерения, неопределённость времени, происхождение, размещение и калибровку. Краткий JSON в этой главе показывает транспортный эскиз, а не все поля такого паспорта. Оценка и прогноз имеют отдельные типы и не записываются в канал настоящего измерения.

Одинаковое намерение — одни и те же байты#

Команда неизменяема целиком, включая not_after_device_us. В повторах меняются только кадр и session_seq. execution_seq монотонно растёт на канал внутри (controller key, controller_fence, boot_id); Core допускает не больше одной новой команды в ожидании на канал. Пропуск числа допустим, повторное применение старого числа — нет. После восстановления Core сначала читает high-water исполнителя.

Проверки шага 5 и изменение выхода выполняет один владелец канала. Между «проверил ручной режим» и «включил GPIO» не вклинивается событие кнопки. Если кнопка уже принята, команда должна увидеть новую manual_revision. Если команда успела первой, следующая кнопка законно изменит выход; поздний ACK не отменит её.

Кэш E0 хранит 64 последних завершённых результата на канал в RAM. Живое исполнение не вытесняется. После вытеснения high-water остаётся до конца boot, поэтому исчезновение записи не превращает старое действие в новое. При переполнении ресурса новый запрос получает RESOURCE_LIMIT до действия. После reset новая boot-привязка запрещает все прежние команды; сохранность эффекта между GPIO и записью результата не обещается. Core сохраняет неизменяемую связь исходного request/intent ID с execution_seq; гарантия ID_CONFLICT по известному ID не означает бесконечного MCU-кэша.

История: A включила свет, её ответ потерян; человек нажал OFF; пришёл повтор A. Узел находит A и возвращает прежний APPLIED с прежней ревизией. Текущее состояние остаётся OFF. Если A уже вытеснена, повтор получает RESULT_EVICTED, также без действия. Это сильнее простого совета «используйте set вместо toggle».

Снять ручной режим — отдельная операция RELEASE_MANUAL (код 2, argument=null), а не скрытое следствие следующего автоматического SET. Она разрешена только для явного действия авторизованного пользователя, проходит те же проверки boot, fence, версий и срока и увеличивает manual_revision. Сам уровень выхода не меняется. Обычный SET имеет код 1 и булев аргумент; локальная кнопка обрабатывается вне сетевого протокола. Позиция длинного нажатия «вернуть автоматику» должна отличаться от сброса и сопряжения.

Время доставки нельзя начинать заново при получении#

Обозначим C — BOOTTIME станции, D — часы MCU в текущей загрузке, θ = D − C. Станция отправляет пробу в c1; MCU принимает в d2 и отвечает в d3; ответ приходит в c4. При неотрицательных задержках и ограниченном дрейфе смещение на время пробы лежит между d3 − c4 и d2 − c1. Половина RTT не используется как доказанная задержка в одну сторону. Границы расширяются на ошибки отметок и доказанный дрейф с момента пробы. [165]

θ_min = d3 − c4 − ε
θ_max = d2 − c1 + ε
not_after_device = core_deadline + θ_min − drift_margin

Пример в миллисекундах: c1=1000, d2=5008, d3=5009, c4=1020. До дополнительных ошибок θ лежит в [3989; 4008]. Для core_deadline=3000 и общего запаса 20 мс срок MCU выбирается 6969. Пакет, впервые дошедший после этого числа, не включает GPIO. Арифметика выполняется в широком знаковом типе; отрицательный срок, переполнение и недостаточный бюджет означают отказ, а не оборачивание uint64.

В первом опыте ширина допустимого интервала часов — не более 50 мс, возраст пробы — не более 30 с; это цели квалификации. Бюджет ошибки включает дрейф MCU, ошибку timestamp и допустимую частотную коррекцию часов станции. CLOCK_BOOTTIME учитывает suspend, но не является RAW-шкалой без коррекции частоты. При неизвестной границе срочная команда не допускается. Actuator E0 не спит; suspend/resume, смена источника часов и boot инвалидируют привязку. Непосредственно до GPIO проверяется now_device < not_after_device. [145]

Четыре вида сроков#

UNKNOWN описывает недостаток знания об отправленном действии. StatusQuery может уточнить его позже; это не команда повторить действие. CANCELLED гарантируется только до передачи исполнителю. После DISPATCHED запрос отмены не обещает отменить уже состоявшийся физический эффект. При переключении телефона с Wi-Fi на мобильную сеть приложение сначала спрашивает статус прежнего ID.

Рассмотреть схему

Передать пароль Wi-Fi и назначить владельца — две разные операции. Удобство не должно стирать эту границу.

Мобильное приложение снимает важное ограничение браузера: оно может использовать платформенные BLE-интерфейсы и хранить закреплённую идентичность станции. Поэтому Koobique не требуется публичный сертификат только ради обычного локального управления. Но первая передача доверия всё равно должна быть физически подтверждена и защищена.

Лабораторный E0: сначала надёжный базовый путь#

Первую станцию на имеющемся ПК или Mini-ITX допустимо настроить через локальную консоль либо доверенное USB-подключение. Она получает Wi-Fi-профиль, создаёт собственный ключ и показывает QR с идентификатором, отпечатком и одноразовым билетом владельца. Телефон считывает его непосредственно с доверенного экрана или распечатки, полученной при локальной настройке.

Это честный путь первого самостоятельно собранного экземпляра. Он не выдаётся за окончательный пользовательский onboarding и не требует постоянного Ethernet. Основное приложение после настройки работает в обычной Wi-Fi-сети.

Устройства: BLE + готовый защищённый provisioning#

Для ESP32 можно использовать ESP-IDF Unified Provisioning с Security 2. Документация описывает SRP6a и AES-GCM, уникальные данные владения и готовые Android/iOS-инструменты. BLE сохраняет соединение с телефоном во время присоединения к Wi-Fi. Security 0 и режим без доказательства владения не выбираются для обычной настройки Koobique. [70]

Рассмотреть схему

Приложение передаёт SSID, пароль, ожидаемую идентичность станции и короткоживущий билет присоединения. Узел подключается к сети, устанавливает защищённый канал со станцией и подтверждает билет. Только после этого он считается принадлежащим инсталляции. Успешный DHCP сам по себе не означает успешное сопряжение.

Рабочие сертификаты или ключи отличаются от секрета первого владения. QR на корпусе не становится бессрочным административным паролем. Повторное открытие режима требует физического действия и видимого индикатора.

Как сделать такую же настройку Linux-станции#

На Linux нет автоматического эквивалента ESP-IDF provisioning только от установки BlueZ. Есть три пути. Первый — локальный USB/консоль для E0. Второй — отдельный ESP-сопроцессор настройки на внутреннем USB, использующий уже испытанный provisioning и передающий структурированные данные привилегированному helper. Третий — собственный Linux BLE-сервис с проверенным стандартным протоколом установления защищённой сессии.

Сопроцессор сокращает часть программного риска, но добавляет доверенный компонент и свою прошивку. Его нельзя считать простым «проводком»: он видит сетевые секреты и должен быть связан с идентичностью хоста. Собственный BLE-сервис уменьшает детали, но требует отдельного аудита handshake, replay-защиты и мобильной совместимости. GATT API BlueZ — транспортный инструмент, а не готовая модель безопасности. [42]

Путь к удобному E1#

Для E0 остаётся локальный доверенный bootstrap. Для E1 выбирается один BLE-путь после отдельного стенда Android/iOS. Временный SoftAP допустим как явно обозначенный резерв настройки, но не как обязательная сеть для повседневного управления.

Атомарность сопряжения#

Процесс имеет состояния DISCOVERED, AUTHENTICATED, NETWORK_READY, CLAIM_PENDING и OWNED. До OWNED команда управления запрещена. Билет имеет срок, nonce и ограниченное число попыток. Если питание исчезло после выдачи ключа, стороны при возвращении сверяют состояние, а не создают две записи устройства.

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

Несколько пользователей#

Владелец приглашает другого пользователя подписанным ограниченным приглашением: комнаты, возможности, цель, срок, nonce и привязка к получателю. Использование и отзыв фиксируются устойчиво; повтор того же завершения возвращает прежний результат, а другой ключ не присваивает приглашение. Это отдельный Client API договор, который ещё требует реализации и отрицательных тестов. Разрешение включать свет не предоставляет SSH, обновление прошивок или чтение личных данных.

Потерянный пользовательский session credential отзывается на Core: закрываются сессии и подписки, отменяются ещё не отправленные запросы. Если телефон также владеет owner-authority key для переноса Hub, требуется отдельный отзыв этого полномочия на каждом MCU. Обычный отзыв клиента не завершает обновление списка доверенных owner-подписантов. Узел, ещё не подтвердивший новый список, остаётся PENDING; прямое управление устройством, если появится, также требует собственного договора прав.

Смена роутера и восстановление#

Пользователь должен иметь способ передать новый Wi-Fi-профиль локально без перепривязки всей комнаты. Это операция сетевой конфигурации, не смена владельца. Физическая кнопка станции открывает ограниченный режим восстановления; индикатор и приложение показывают, что сейчас разрешено.

Нельзя делать «factory reset» единственным ответом на ошибочный пароль: он уничтожает контекст и превращает обслуживаемую систему в набор одноразовых устройств. Полный сброс требует длительного подтверждения и ясно различается с обычным перезапуском.

Ключ создаётся там, где будет использоваться#

Рабочая приватная пара узла генерируется на MCU при проверенной энтропии; наружу передаётся публичный ключ или запрос на удостоверение. Станция не рассылает всем платам заранее созданные секретные ключи. Provisioning использует уникальный случайный PoP/verifier; примерные общие значения SDK не копируются в изделия. Для E0 предлагаем не менее 128 бит случайного секрета подключения с QR-представлением.

Билет присоединения связывает installation_id, purpose, node_id, публичный ключ узла, challenge, права и срок/условия завершения. Его нельзя использовать для другой установки или переслать другому ключу как универсальную ссылку. Формат подписанного объекта опирается на COSE_Sign1; собственный формат шифрования не разрабатывается. [149]

Сопряжение с незавершённым финалом#

После физического окна и проверки доказательств узел сохраняет CLAIM_PENDING с хешем билета и transaction_id. Повтор того же завершения возвращает тот же результат; другой билет не подменяет pending-состояние. OWNED показывается после устойчивой записи и подтверждения обеих сторон. Если ответ потерян, приложение сверяет транзакцию. Оно не предлагает factory reset как первый способ исправить любой тайм-аут.

Factory reset требует отдельного физического действия, стирает рабочую привязку и сетевые секреты согласно профилю, но не превращает запись старого Hub в подтверждение нового владельца. У старой станции остаётся «узел сброшен/недоступен» до подтверждённого удаления. Смена пароля Wi-Fi открывает узкое окно повторной настройки сети без автоматического снятия владельца и ручного режима.

Защита строится как согласованная цепочка от физической кнопки до обновления. TLS защищает один из её участков; полномочия и переходы доверия проверяются во всём контуре.

В Koobique есть несколько активов: полномочия владельца, идентичность станции, ключи устройств, история присутствия, голосовые данные, возможность включить нагрузку и канал обновления. Угрозы тоже различаются: сосед в Wi-Fi, украденный телефон, вредоносный пакет, подменённый relay, старый backup и физический доступ к отладочному разъёму.

Модель доверия#

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

Первый личный комплект может создавать ключи при доверенной локальной настройке. Важно не копировать один приватный ключ во все прошивки. Уникальная идентичность и процедуру отзыва нужно сделать сразу — исправлять это после развёртывания гораздо сложнее.

TLS в локальном приложении#

Приложение получает доверие к станции через QR/физически подтверждённую настройку. Затем проверяет закреплённый ключ или локальную цепочку доверия, ожидаемую идентичность и параметры сессии. Локальное имя, например стабильное имя станции в .local, может использоваться как ожидаемый SAN/SNI независимо от способа обнаружения IP.

Глобальный trustAll запрещён. Для публичной PKI не отключаются имя, цепочка и календарная валидность. Собственный локальный pin-профиль ниже является отдельной моделью доверия, проверяющей конкретный ключ и подпись handshake; он не реализуется общим флагом «игнорировать ошибки сертификата». Ротация и отзыв закреплённых ключей входят в жизненный цикл установки. [167][148]

Что делать с неверным временем#

Календарная дата и измерение длительности решаются раздельно. У ESP32-C6 есть RTC-таймер и высокоточный таймер, но не готовое доверенное календарное время после полного отключения. В офлайн-профиле первая аутентификация опирается на заранее проверенную идентичность ключа; после неё станция передаёт оценку UTC и качества. Часы не создают доверие к незнакомой станции. [146]

Решение — отдельный ограниченный режим восстановления, открываемый физическим действием и подтверждаемый уже закреплённой идентичностью либо новым доверенным bootstrap. В нём можно восстановить время и обновить локальные сертификаты. Это не обычный управляющий API с отключённой проверкой. Бессрочную автономность нельзя строить на незаметном принятии любого истёкшего сертификата.

Минимальные полномочия#

Датчик публикует только свои каналы и не может выполнять команды на другом устройстве. Speech-worker может предложить намерение, но не менять пользователей. Приложение гостя управляет разрешённой комнатой, но не экспортирует ключи. Privileged-helper принимает ограниченные операции от конкретного локального клиента.

Сетевые лимиты нужны до аутентификации: число handshake, размер сообщения, длительность операции, скорость ошибок. Иначе корректный TLS не защитит от исчерпания памяти. Парсер любого внешнего файла обновления, QR и диагностического импорта также считается недоверенной границей.

Загрузка и обновление#

Secure Boot и проверка образа уменьшают риск незаметной замены системного ПО. dm-verity может проверять целостность блочного образа, но доверие к корневому хешу должно происходить из проверенной загрузочной цепочки. Шифрование диска решает другую задачу — доступ к данным при извлечении накопителя. [92]

Для личного проекта полезен режим собственных ключей владельца. Переход в developer mode должен быть физически подтверждён и иметь понятные последствия для секретов. Нельзя одновременно обещать свободную замену любой прошивки и защиту секретов от такой прошивки без отдельной аппаратной модели.

Старые копии и два контроллера#

При восстановлении станции нельзя просто запустить копию базы рядом с исходной. Устройство должно знать актуальный controller_fence или иной fencing-токен. После официального переноса старый контроллер отвергается. Если такой механизм ещё не реализован, процедура восстановления обязана сначала изолировать старую станцию.

Сохранённый backup может содержать уже отозванные полномочия. Поэтому восстановление включает сверку и ротацию, а не слепое доверие всему архиву. Ключ восстановления хранится отдельно и не отправляется в техподдержку.

Проверки безопасности до постоянной эксплуатации#

Подменить endpoint, использовать чужой ключ, повторить старый билет, отправить слишком большой кадр, восстановить старую конфигурацию и проверить отзыв телефона. Отдельно проверить, что диагностический архив не содержит приватных ключей и Wi-Fi-паролей.

Файл весов — программный артефакт. Показания датчика — недоверенный вход. История присутствия — личная информация даже без камеры.

Подлинность не равна правильности#

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

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

Модель как поставляемый пакет#

Манифест содержит хеш, версию, архитектуру, входные и выходные типы, нормализацию, ограничения памяти, backend, происхождение, лицензию и результаты допуска. Обновляется весь комплект, а не только веса. Прежний токенизатор или порядок признаков способен изменить смысл корректного нового файла.

Для безопасной доставки полезны роли, метаданные и проверки обновлений TUF. [84] Они помогают защищать цепочку поставки, но не доказывают качество модели. Safetensors предназначен для безопасной сериализации тензоров без произвольного pickle-кода; это не защита от всех ошибок загрузчика, огромных размеров и небезопасных native-операторов. [138]

Рассмотреть схему

Сandbox для расширений#

Если появятся пользовательские алгоритмы, можно исследовать WebAssembly с явным набором импортируемых возможностей и лимитами. Wasmtime описывает изоляцию памяти и модель доступа как часть своей безопасности. [133] Но произвольный host-call снова расширяет доверенную базу: модуль, которому разрешили командовать реле напрямую, обходит архитектуру независимо от формата байткода.

Для первой версии не нужен публичный магазин плагинов. Встроенные алгоритмы и ограниченный AI-worker проще проверить. Чужой модуль допускаем только к чтению объявленных данных и выдаче предложений.

Приватность производных данных#

Из редких событий света и присутствия можно получить распорядок; embedding голосового эпизода также может содержать чувствительную информацию. Поэтому «мы не храним исходный звук» не является полной политикой приватности.

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

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

Сеть и администрирование#

Локальное сопряжение, пользовательский удалённый канал и SSH имеют разные полномочия. Для первого экземпляра отдельный VPN-контур и защищённая прикладная сессия остаются прозрачным вариантом. Тяжёлое обучение может работать на существующем ПК, но остановка этого вычислительного помощника не останавливает локальную платформу.

На станции нет обязательного облачного AI-вызова. Для внешнего исследования Jev или другого API данные готовятся отдельно и передаются только с разрешения. Удалённый доступ не обещается при полном отсутствии доступного канала связи.

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

Два профиля TLS: публичный и локально закреплённый#

Обычное публичное HTTPS продолжает проверять цепочку, имя, срок сертификата и подпись handshake. Для первого офлайн-соединения собственных узлов E0 выбирает другой, явно выделенный договор: закреплённый публичный ключ конкретной стороны, проверенный через физический bootstrap. X.509 здесь служит контейнером ключа; календарный срок не является источником доверия. Нельзя переносить этот verifier на произвольные сайты или неизвестных peers. [167][148]

Локальная проверка обязана сравнить полный разрешённый SPKI/его криптографический отпечаток, доказательство владения ключом в TLS 1.3, назначение ключа и текущую привязку установки. Проверка подписи handshake не отключается. Механизм raw public key стандартизован RFC 7250, но его готовая поддержка на обеих наших сторонах ещё не установлена. Для E0 нужен отрицательный опыт с чужим ключом, подменённым контейнером и неверной подписью; до него pin-профиль остаётся проектным, а не «готовой безопасной библиотекой». [147]

После аутентификации Core передаёт оценку календарного времени с качеством; это не делает её точной автоматически. Внешний NTS — дополнительный источник, не условие работы лампы. При неизвестном UTC обычное TUF-обновление и календарные приглашения не обходят срок. Аварийный recovery — отдельная физически подтверждаемая процедура с ограниченной целью, не глобальный переключатель trustAll. [166][84] Core долговечно хранит последнее подтверждённое доверенное время как нижнюю границу, вместе с происхождением и качеством оценки. Откат системных часов или старого backup не должен незаметно уменьшать эту границу. Она не доказывает точное текущее UTC и не заменяет оценку неопределённости; формат передачи времени и политика восстановления требуют отдельного контракта и отрицательных испытаний.

Владение отдельно от работающей станции#

Полномочие владельца для редких подписей переноса отделяется от рабочего session credential телефона. Предусмотрен независимый offline recovery key; перед постоянной эксплуатацией проверяется восстановление без исходного телефона. Эти ключи не являются копиями неэкспортируемого Secure Enclave. Аппаратная защита Keystore/StrongBox зависит от конкретного устройства и настройки. Набор доверенных owner/recovery keys, его поколение и правила замены — отдельный контракт; биометрия и голос сами по себе не передают роль владельца. [177][71]

Перенос на новый Hub подписывает действующее owner-authority полномочие. Назначение связывает purpose, installation_id, node_id, свежий challenge, previous_fence, next_fence=previous+1 и новый controller key. MCU проверяет подписанта по текущему устойчивому owner/recovery-набору, сохраняет целое назначение атомарно и затем отвечает. Обновление этого набора отдельно определяет авторизацию, защиту от rollback и случай последнего утраченного ключа; controller_fence не отзывает owner-подписанта. Формат OwnerSetUpdate, транспорт TrustTransfer и отрицательные TLS/COSE-проверки остаются открытым gate, а не реализованной функцией.

Перенос завершён по каждому устройству отдельно. Offline-узел остаётся PENDING; нельзя подписать «весь дом перенесён», если часть устройств ещё доверяет старой станции. Для этих узлов сначала изолируют старый Hub и выполняют подтверждённое переназначение при возвращении связи. Отказ питания в середине записи должен оставить либо целую старую, либо целую новую привязку, но не пустой режим без владельца.

Обычный backup содержит данные и публичные назначения, но не копию активного controller private key. На новом Hub ключ создаётся заново; восстановление начинается пассивно. Если платформа реально поддерживает TPM/sealing, это отдельный проверяемый способ защиты ключа. E0 без защиты физического доступа не обещает сопротивление клонированию всей flash/диска злоумышленником.

Отзыв телефона — больше, чем удалить запись#

После commit отзыва рабочего клиента Core закрывает сессии и подписки, отменяет неотправленные действия и приглашения и повторяет ACL-проверку перед dispatch. Для owner-authority отзыва необходимо обновить доверие каждого MCU и получить подтверждение; до этого отзыв соответствующего узла не завершён. Уже отправленное действие нельзя гарантированно отменить по оборванной сети: действует исходный срок. TLS resumption, если будет разрешён, обязан учитывать текущее поколение авторизации; его отключение в E0 допустимо для уменьшения объёма квалификации.

После восстановления старого backup пользовательские сессии и разрешения не оживают автоматически: выдаётся новое поколение авторизации, требуется подтверждение владельца и повторное подключение телефонов. Старая подписанная ссылка также не становится новой. Изменение политики доверия должно переживать OTA-rollback; иначе возврат старой прошивки одновременно возвратит отозванный ключ.

Рассмотреть схему

Внешняя сеть переносит защищённый поток. Решение о доступе остаётся на станции.

За пределами дома у телефона нет прямого локального маршрута к хабу. Дом может находиться за CGNAT, а входящие соединения — быть запрещены. Поэтому первая реализуемая схема строится на исходящих соединениях и небольшом сервере-посреднике под контролем владельца. Этот сервер не хранит модель комнаты и не исполняет автоматизации.

Три архитектуры удалённого пути#

WireGuard использует стандартную для него модель ключей и защищённого туннеля. Persistent keepalive может помочь сохранению NAT-состояния, но не гарантирует прохождение блокировок. Его частота выбирается с учётом мобильной батареи и сетевой среды. [59][72]

Рассмотреть схему

Первый работающий удалённый экземпляр#

Для E0 предлагается штатный WireGuard-клиент на телефоне и станции, VPS владельца и маршрут только к хабу/нужным адресам. Это не окончательный бесшовный UX, но работающая проверяемая основа. Внутри туннеля сохраняется защищённая прикладная сессия Koobique, чтобы VPN-сервер не становился единственным основанием доверия.

Приложение выбирает локальный endpoint дома и VPN-endpoint вне дома, проверяя один и тот же ключ станции. Переход не создаёт новую команду при повторе: сохраняется прежний command_id. Локальный доступ не отправляется через удалённый VPS только потому, что тот доступен.

Интеграция VPN внутрь KMP-приложения — отдельная платформенная задача с разрешениями и жизненным циклом ОС. На iOS её нельзя считать обычным сокетом без дополнительных возможностей приложения. Для E1 сравнивается встроенный туннель и relay без системного VPN; результат требует реального мобильного стенда.

Что должен делать будущий relay#

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

Relay на TCP/443 не является «неблокируемым протоколом». Белые списки, блокировка IP, обрыв связи и политика сети могут остановить удалённый путь. Это ограничение честно отражается в приложении; локальные функции не зависят от попыток восстановления внешнего канала.

SSH как отдельный административный контур#

SSH включён для владельца, но не публикуется в интернет автоматически. Вход по ключам, отдельная учётная запись, запрет общего пароля и прямого root-входа. OpenSSH позволяет настроить эти ограничения и дополнительные параметры сеанса. [60]

Право управлять светом не равно праву открыть shell. Техподдержка получает временный доступ по конкретному ключу, с явным разрешением владельца. Не нужен общий сервисный ключ всей группы проектов или скрытый постоянный reverse tunnel.

Команда обновления по SSH вызывает штатную проверяемую процедуру, а не произвольную замену бинарника в работающей системе. Диагностический пакет маскирует ключи, Wi-Fi-пароли и персональные данные. Временный доступ можно отозвать независимо от мобильных пользователей.

Восстановление без внешней инфраструктуры#

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

Приёмка удалённого пути#

Проверить телефон в мобильной сети, смену Wi-Fi на LTE/5G, временную потерю VPS, смену адреса дома и повтор команды во время переключения. Убедиться, что VPS не может выдать себя за станцию и что обычный пользователь не получает SSH.

Туннель не отменяет авторизацию приложения#

WireGuard-пир на VPS не получает право обращаться ко всем службам Hub. На wg-интерфейсе firewall разрешает только нужный порт приложения; SSH — отдельное явное разрешение и собственные ключи. Между приложением и Hub сохраняется проверка конечной идентичности и пользовательских полномочий. Компрометация ретранслятора не должна превращаться в административную локальную сеть.

Headscale/DERP — вариант уменьшить собственный код транспортной инфраструктуры; он сравнивается с простым WireGuard для личного E0 и встроенным relay для E1. Ни один вариант не гарантирует удалённый доступ при недоступности всех разрешённых внешних каналов. Локальная работа остаётся независимой. В мобильном опыте проверяются sleep, смена Wi-Fi/LTE, отзыв и незавершённая команда. [175]

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

Измеряемая величина и вопрос пользователя#

Пользователь спрашивает: «Мне достаточно света?» Датчик выдаёт освещённость в своей точке и ориентации. Между этими формулировками стоят расположение рабочего места, тень от монитора, направленность светильника и выбранный человеком уровень комфорта. В первой версии цель должна звучать уже: «поддерживать согласованный диапазон освещённости на выбранном участке стола».

Метрология различает измеряемую величину, результат измерения и неопределённость. Для Koobique это означает: число без описания условий недостаточно для решения. В качестве базового языка используем понятия VIM и GUM, не превращая каждый домашний датчик в лабораторный прибор. [100]

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

Наблюдаемость: можно ли вообще различить ситуации#

Представим две комнаты с одинаковыми тремя показаниями: 23 °C, 180 лк и отсутствие события PIR. В одной комнате никого нет, в другой человек неподвижно читает. При таком наборе данных однозначный вывод о присутствии невозможен. Более сложный классификатор может использовать статистическое предположение, но не устранит эту неоднозначность.

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

Рассмотреть схему

Пространство — часть данных#

Для светового датчика фиксируем плоскость и ориентацию; для температуры — место и способ вентиляции корпуса; для радара — направление, конфигурацию зоны и возможные движущиеся помехи. Перестановка датчика создаёт новую ревизию размещения. Она может обесценить калибровку влияния лампы, но не обязана менять криптографическую идентичность платы.

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

Качество не означает максимальное число датчиков#

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

Для первого кабинета используем Sense и Presence, разобранные в главах 11–16. Температуру и свет измеряем вне корпуса станции. Сначала наблюдаем их поведение при включении лампы, работе вентиляторов, закрытии шторы и неподвижном сидении. Только затем решаем, нужен ли ещё один канал.

Сбор информации начинается с механики датчика, его питания и момента измерения. Хранилище получает результат уже сформированного измерительного тракта.

Три способа построить сеть#

Удалённые микроконтроллерные узлы. Предпочтительный путь кабинета: ESP32-C6 рядом с датчиками, локальные I²C/UART-соединения, Wi-Fi до станции. Станция получает уже типизированные измерения и диагностические флаги. Размещение измерителя не зависит от места куба; короткие периферийные провода легче исследовать. Электрические соединения показаны в монтажных картах главы 16.

Прямое подключение к Linux. USB-измеритель или плата с поддерживаемым драйвером подключается к станции. Это удобно для микрофона и лабораторного стенда. Для температурных и других преобразователей Linux предоставляет подсистему Industrial I/O: каналы, буферы и триггеры. Поддержка конкретного устройства проверяется отдельно. [105] Перенос медленного опроса в приложение не заменяет аппаратный момент выборки.

Проводные распределённые узлы. В мастерской можно добавить RS-485 или CAN через подходящие трансиверы. Это не новый смысловой протокол: KQIP может получить отдельный транспортный профиль. Электрические длины, терминация, изоляция и защита потребуют собственных схем. Не проводим I²C по всему помещению только потому, что на коротком столе он заработал.

Рассмотреть схему

Техническое задание на канал#

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

Пример для освещения: запуск преобразования, ожидание указанного времени интеграции, чтение результата, проверка переполнения диапазона, привязка к интервалу измерения и публикация. «Получено в 12:00:01» не означает «свет измерен мгновенно в 12:00:01». Изменение времени интеграции меняет свойства канала и должно сопровождать данные.

Для температуры комнаты низкая частота часто является разумным начальным предположением, но один режим нельзя заранее назначать всем корпусам. Сначала измеряем реакцию на перемещение и влияние собственного нагрева. Выбранные SHT45 и VEML7700 подробно разобраны в главах 12–13; параметры проверяем по фактически приобретённым модулям. [15][106]

Аналоговый вход: где появляется настоящая инженерная работа#

Если новый датчик выдаёт напряжение, тракт включает входную защиту, согласование диапазона, фильтр, аналого-цифровой преобразователь и калибровку. Номинальная разрядность ADC не равна числу точных битов полезного измерения. Для ESP32-C6 официальная документация отдельно описывает одиночный и непрерывный режимы, ослабление входа и калибровку. [141]

Не строим измеритель сетевого напряжения прямым делителем на макетной плате. Для первого проекта используем безопасные низковольтные источники и готовые изолированные измерительные решения там, где они необходимы. Опорное напряжение, входное сопротивление и допустимое напряжение определяются даташитом конкретной ревизии, а не общим правилом «ADC принимает 3,3 В».

Буфер, который сообщает о собственных потерях#

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

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

Питание и включение как режим измерения#

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

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

Достоверность источника и достоверность величины#

У аутентифицированного датчика всё ещё может быть закрыт корпус, застрять АЦП или смениться размещение. Поэтому health канала, качество отсчёта и пригодность к задаче — разные признаки. Подтверждённый heartbeat не поднимает capability движения до доказательства отсутствия человека. Счётчик Gap не скрывается последней удачной записью.

Сборщик ограничивает диапазон, скорость событий, размер очереди и допустимую частоту смены режима. Расчётные поля создаются отдельной производной записью с версией алгоритма. Повторные сообщения сравниваются по (device_id, channel_id, boot_id, sample_seq); один такой ключ с другим значением означает конфликт, а не правило «последний победил».

Физическая платформа начинается с того, что не теряет смысл измерения при передаче, хранении и повторной обработке.

Число 23,4 без единицы, места и времени почти бесполезно. Оно может означать температуру воздуха, температуру платы, старое значение после reboot или результат активного нагрева датчика. В Koobique наблюдение является полноценной записью с происхождением и качеством, а не парой name/value.

Рассмотреть схему

Минимальная схема наблюдения#

Единицы лучше нормализовать в доменной модели, сохраняя исходное представление для диагностики. Нельзя смешивать °C и абсолютную температуру без явного преобразования, lux и raw ADC, проценты яркости и электрическую мощность. Проверка диапазона не должна молча обрезать невозможное значение до допустимого: иногда это признак неисправности.

Два времени и интервал#

На устройстве измеряются монотонный счётчик и boot_id. На станции — время получения и собственные монотонные часы. Календарное UTC полезно для истории, но не является единственной основой порядка. Если часы датчика неизвестны, это отражается как неопределённость, а не маскируется временем получения.

Для lux время относится к интервалу интегрирования. Для температуры — к моменту получения результата после измерительной операции. Для события кнопки важен фронт, а не момент отправки пакета. Эти различия особенно заметны при синхронизации нескольких сенсоров.

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

Свежесть зависит от процесса#

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

Истёкший TTL меняет качество наблюдения. Значение можно продолжать показывать как последнее известное, но с возрастом. В автоматизацию оно попадает только по разрешённой политике. «Нет свежей температуры» не означает 0 °C, а «нет пакетов радара» не означает пустую комнату.

Обработка пропусков и выбросов#

Не все выбросы ошибочны: резкое освещение фонариком — реальное событие. Для диагностики сохраняются raw и причина фильтрации. Обычный график может показывать сглаженный ряд, но алгоритм не должен незаметно терять физические скачки, важные для сценария.

Пропуск не всегда интерполируется. Для визуализации короткого пропуска температуры линейная линия допустима с отметкой; для команды реле интерполяция между OFF и ON бессмысленна. У агрегата хранятся число образцов, минимум, максимум, среднее и доля валидных данных.

Происхождение решения#

Оценка «человек присутствует» ссылается на использованные наблюдения и версию алгоритма. Решение «включить свет» ссылается на оценку, lux, политику и состояние ManualOverride. Это создаёт цепочку объяснения: пользователь видит не просто «автоматизация сработала», а причину.

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

Приватность физического мира#

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

Администратор хоста технически имеет более широкие возможности, чем пользователь приложения. Если в будущем потребуется защита личных данных от владельца станции, понадобится отдельное шифрование и перераспределение вычислений; обычный ACL внутри Core не решает эту задачу.

Проверка качества данных#

Искусственно передать старый timestamp, повтор sequence, новое boot_id, насыщенное lux и heater-флаг. Проверить, что график, автоматизация и журнал различают эти случаи и не превращают их в одинаковое «валидное число».

Запись измерения сохраняет значение и то, что было известно системе в момент решения. Это позволяет проверить действие по доступным тогда основаниям.

Минимум, который нельзя выбросить ради компактности#

Предлагаем логический объект Observation: идентичность канала, объект наблюдения, величина и единица, значение или явный статус отсутствия, номер последовательности и перезапуска, время/интервал измерения, время получения станцией, качество, ревизия размещения и калибровки. На проводе постоянные поля можно вынести в согласованный дескриптор канала.

Разделение сенсора, наблюдаемого свойства и физического объекта имеет готовый словарь в SOSA/SSN. [101] Мы используем эти идеи для совместимого смысла, но не обязуем микроконтроллер передавать RDF или длинные URI в каждом пакете. Обозначения свойств и действий из WoT Thing Description полезны для внешнего описания устройства; они не заменяют модель его воздействия на среду. [102]

Четыре времени вместо одной даты#

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

Метки относятся к конкретному boot_id и режиму тактирования. Для кратких сроков Linux используется CLOCK_BOOTTIME, учитывающий suspend; произвольный Rust Instant или CLOCK_MONOTONIC не считается эквивалентом без проверки реализации. После resume/reboot краткоживущие предложения инвалидируются, если их актуальность не доказана. UTC служит истории и календарным правилам, но не оживляет старый outbox. [145]

Рассмотреть схему

Расчётный бюджет часов: при начальной границе 10 мс и доказанной для данного режима относительной ошибке 20 ppm за 30 с добавится 0,6 мс. Это только арифметический пример. Он не назначает точность внутреннему RTC RC-генератору C6 и не переносится в light/deep sleep. Рабочий профиль измеряет дрейф, температуру и смену источника; неопределённая граница означает запрет срочного действия, а не нулевую ошибку. [146]

Поздние записи и окончательность#

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

Храним decision_snapshot_id: идентификатор снимка состояния и версий моделей. Он позволяет воспроизвести логику на доступной тогда информации. Исторический пересчёт создаёт новую оценку со ссылкой на старую, а не стирает основание первоначального действия.

Свежесть зависит от действия#

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

KQIP связывает значение с согласованным контрактом наблюдения. Метаданные версионируются. Если старое устройство не передаёт сведения, необходимые для конкретного управления, область разрешённой автоматизации сужается.

Разобранный путь одного наблюдения#

Пусть Sense начинает измерение на отметке своих часов 120,000 с и заканчивает на 120,015 с. Запись получает boot_id и номер 1042. Станция принимает её позже. Она сохраняет исходный интервал и отдельно свою оценку того, как он соотносится с локальной шкалой времени. Числа в этом примере иллюстрируют договор, а не паспорт длительности любого режима SHT45.

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

Один словарь полей на узле и в журнале#

Нормативные имена E0: channel_id, sample_seq, sample_start_us, sample_end_us, boot_id, status, flags, descriptor_revision, placement_revision. Единственный status — VALID, INVALID или WARMING; независимые flags уточняют heater, saturation, delayed и другие зарегистрированные условия. Флаг не делает INVALID пригодным. Старые имена из учебных файлов преобразуются явным адаптером версии, а не принимаются как скрытые синонимы.

Временная метка получения сервером не подставляется вместо интервала измерения. Для старого буфера после reboot неизвестное соответствие UTC остаётся неизвестным. Порядок внутри boot можно сохранить даже без даты; порядок между разными устройствами и загрузками требует свидетельств. Алгоритм привязки шкал и сроков описан в главе 22.

Что считать свидетельством света после команды#

Машинное условие пригодности: совпадают канал, placement_revision, профиль лампы и калибровка; качество допустимо; нижняя граница начала измерения позже верхней границы момента действия плюс проверенное время установления; внутри интервала не было другого воздействия, меняющего тракт. Если интервал пересекает переключение, отсчёт не подтверждает установившийся эффект.

Даже пригодный рост lux может быть вызван солнцем или другой лампой. EffectEvidence хранит альтернативные объяснения и силу свидетельства. Если датчик тока не установлен, UI пишет «контроль тока не предусмотрен», а не ждёт его вечно. Историческое VERIFIED относится к конкретному эпизоду; состояние комнаты спустя минуту оценивается заново.

Свидетельство эффекта как проверяемая запись#

Для эпизода исполнения сохраняются command_id, сообщённый момент действия с границей ошибки времени, требуемое время установления и используемые наблюдения. Свидетельство также указывает channel_id, ревизии размещения и калибровки, профиль нагрузки и известные вмешательства. Эти поля позволяют проверить, относится ли измерение к данному действию. Если часть сведений неизвестна, запись сохраняет этот предел вместо автоматического VERIFIED.

Причинный вывод сильнее совпадения во времени. Лампа могла включиться одновременно с открытием шторы; тогда рост lux совместим с несколькими объяснениями. Для проверки предполагаемого вклада полезен разрешённый чередующийся опыт OFF/ON с контролем фоновых изменений и остановкой по ручному действию. Полученный коэффициент действует только для испытанных размещения, сенсора и светильника. Электрическую исправность нельзя окончательно вывести из одного оптического наблюдения.

Фильтр подавляет выбранные колебания сигнала и одновременно добавляет задержку. Его параметры определяют по времени физического процесса и по тому, для какого решения используются данные.

Частоты измерения, передачи и решения#

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

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

Три фильтра и их цена#

Для последнего варианта удобно задавать постоянную времени $\tau$, а не произвольную долю предыдущего значения:

$$\hat y_k=\alpha_k y_k+(1-\alpha_k)\hat y_{k-1},\qquad \alpha_k=1-e^{-\Delta t_k/\tau}.$$

Здесь $y_k$ — новое измерение, $\Delta t_k$ — прошедшее время. При нерегулярных пакетах такой коэффициент лучше выражает физический смысл фильтра. Однако большой пробел не превращает новое измерение в знание всей пропущенной траектории.

Расчётный пример: сглаживание света. При $\tau=2$ с и шаге $\Delta t=0{,}2$ с получаем $\alpha\approx0{,}095$. После ступенчатого изменения идеальная модель фильтра достигает примерно 63% нового уровня за 2 с. Это может быть приемлемо для графика, но слишком медленно для подтверждения включения лампы. Поэтому график и проверка действия используют разные представления одного исходного сигнала.

Рассмотреть схему

Признаки для моделей#

Для присутствия полезны длительность отсутствия движения, число событий в окне, качество связи, согласованность источников и признак ручного взаимодействия. Необходимо знать, какие из признаков наблюдаемы в момент решения. «Через минуту человек нажал кнопку» нельзя использовать при обучении модели, которая должна решить сейчас.

Нормализация, единицы, маски пропусков и границы окон — часть версии модели. Если тренировочный конвейер использовал секунды, а устройство передало миллисекунды, корректная нейросеть получит физически другой вход. Проверяем преобразования на постоянных тестовых примерах до сравнения качества AI.

Калибровка и дрейф#

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

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

Инициализация фильтра — тоже часть алгоритма#

EMA начинается с первого допустимого значения либо с явно заданной начальной оценки. При большом пропуске применяется политика reset или расчёт коэффициента по реальному Δt; нельзя молча выполнить один обычный шаг как после регулярной выборки. После смены калибровки, gain или размещения фильтр не смешивает несовместимые шкалы.

Перед уменьшением частоты нужен фильтр против наложения частот, согласованный с наблюдаемым процессом. Но программная фильтрация не восстанавливает уже потерянные сенсором быстрые колебания. Для расчёта светового эффекта учитывается групповая задержка фильтра и интервал физического измерения; красивый сглаженный график не обязательно лучший вход быстрого решения. [106]

Уверенность модели, погрешность измерителя и право управлять реле — три разные сущности. Их нельзя свести к одному числу от нуля до единицы.

Как выглядит честная оценка#

Предлагаемый объект Estimate содержит оцениваемую величину или состояние, значение/распределение, вид неопределённости, использованные наблюдения, модель, срок применимости и условия. Если вероятностная модель ещё не откалибрована, интерфейс может показывать «есть свидетельства присутствия», а не точные 97,4%.

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

Пример бюджета температуры#

Предположим независимые стандартные неопределённости: калибровка 0,12 °C, повторяемость 0,03 °C, влияние корпуса 0,25 °C и размещения 0,50 °C. В упрощённой линейной модели:

$$u_c=\sqrt{0{,}12^2+0{,}03^2+0{,}25^2+0{,}50^2}\approx0{,}57\,°\mathrm C.$$

В реальном бюджете нужно учитывать чувствительности и корреляции; основа такого расчёта — GUM. [100] Значение $2u_c\approx1{,}15$ °C нельзя без предпосылок объявить точным 95-процентным интервалом. Вывод примера другой: дорогой сенсор внутри неправильно размещённого корпуса не исправляет доминирующий источник ошибки.

Рассмотреть схему

Объединение присутствия#

Можно начать с автомата: присутствие подтверждено, присутствие вероятно, пусто подтверждено для данного сценария, неизвестно. Переходы зависят от событий, таймеров и здоровья каналов. Это понятный эталон для будущего вероятностного фильтра.

В байесовском варианте обновляется вероятность скрытого состояния. Учебный пример: до сигнала вероятность присутствия равна 0,6; вероятность положительного сигнала радара при присутствии — 0,9, при отсутствии — 0,2. Тогда

$$P(\text{есть}\mid +)=\frac{0{,}9\cdot0{,}6}{0{,}9\cdot0{,}6+0{,}2\cdot0{,}4}\approx0{,}87.$$

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

Почему десять свидетельств иногда равны одному#

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

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

Проверка вероятностей#

Если среди эпизодов с прогнозом 0,8 событие происходит примерно в 80% случаев, это один из признаков калибровки. Это не гарантирует качество на новой комнате и не означает одинаковую цену всех ошибок. Методы калибровки нейросетей и температурное масштабирование описаны в исследовании Guo и соавторов. [128]

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

Погрешность и калибровка#

Показания двух датчиков 23,4 и 23,7 °C не определяют, какой из них прав. Для оценки смещения нужна опора с известной погрешностью, стабильная среда и достаточная выдержка. Корпус и положение входят в измерительную систему наряду с микросхемой. [15][78]

Пусть только для расчётного примера независимые стандартные неопределённости трёх вкладов равны 0,10, 0,08 и 0,05 °C. Тогда корень суммы квадратов равен примерно 0,137 °C. Складывать таким способом паспортные максимумы без распределений и предположения независимости некорректно. А общий систематический нагрев на 1 °C не исчезнет от усреднения тысячи отсчётов.

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

Почему уверенность не должна расти от одинаковых кадров#

Если человек один раз пошевелился, двадцать почти одинаковых кадров радара не являются двадцатью независимыми свидетельствами. Повторное умножение одной likelihood быстро даёт ложную уверенность. Для E0 используется проверяемый конечный автомат, а для вероятностного кандидата — модель переходов состояния и наблюдений, например HMM с предсказанием перед каждым обновлением.

Корреляцию PIR, радара и движения изображения нельзя исправить произвольным коэффициентом доверия «по вкусу». Допускается исследовать совместную модель либо явно ослабленную likelihood, но параметр оценивается на независимых эпизодах. При неизвестной зависимости система сообщает недостаточность оснований. Логи и метрики программы называем эксплуатационной наблюдаемостью; способность различить физические состояния — наблюдаемостью процесса.

Неопределённость меняет допустимый вывод#

Пороговая политика должна указывать, какое свидетельство ей достаточно: одно показание, интервал с заданным смыслом или откалиброванная вероятность. Эти варианты не взаимозаменяемы. Например, условные 300 лк с допустимой ошибкой ±40 лк не доказывают выполнение требования «не ниже 280 лк»: нижняя граница равна 260 лк. Это арифметический пример проверки условия, а не паспортная погрешность выбранного датчика.

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

Модель мира полезна, если умеет ответить: «Что изменится после моего действия, насколько я этому доверяю и где прогноз перестанет работать?»

Состав и назначение модели мира#

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

Явная модель нужна для прав, единиц, объяснений и переноса. Обучаемая нужна там, где точная зависимость заранее неизвестна. Нейросетевой вектор не должен быть единственным местом, где хранится факт «это реле управляет настольной лампой».

В Brick уже существует семантическое описание оборудования, пространств и отношений здания. [103] Мы можем использовать совместимый экспорт и словарь отношений, но не обязаны запускать отдельную графовую СУБД для первого кабинета. Небольшой типизированный граф в памяти с постоянным хранением достаточно выразителен для начального стенда.

Рассмотреть схему

Прогноз без действия и прогноз после действия#

Пусть $x_t$ — скрытое состояние комнаты, $a_t$ — действие, $d_t$ — внешние воздействия, $y_t$ — измерение. Общая заготовка:

$$x_{t+1}=f(x_t,a_t,d_t)+w_t,\qquad y_t=h(x_t)+v_t.$$

$f$ описывает изменение мира, $h$ — то, как мы его видим; $w_t$ и $v_t$ отражают неполноту модели и ошибки наблюдения. Формула не требует нейросети. Для лампы достаточно простого вклада в освещённость; для сложного узла часть $f$ можно обучить.

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

Причинная ловушка#

Вечером человек одновременно включает лампу и закрывает дверь. Наблюдательная модель может связать закрытие двери с ростом освещённости. Чтобы отделить зависимости, нужен монтажный смысл, физическое ограничение и безопасные измерения при изменении одного воздействия. Корреляция может помогать прогнозу, но не выдаёт разрешение управлять чужим устройством ради желаемого результата.

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

Область применимости#

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

Выход за область — не обязательно авария. Координация возвращается к более простому правилу, а модель продолжает наблюдать в теневом режиме. Для высокорискового процесса реакция может быть строже и определяется отдельно.

Конфликт двух моделей#

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

Модель мира хранит версии связей, динамику и область применимости прогноза. Для работы нужны явные объекты, действия и границы знания; пространственное изображение комнаты может служить дополнительным способом их изучения.

Модель объекта — не список названий#

Светильник связан с физическим каналом, комнатой, группами, обратной связью и допустимыми действиями. «Подсветка» и «освещение» могут обозначать разные наборы. Имя — только пользовательский псевдоним; источник истины — ID и текущая версия графа. Перенос между комнатами инвалидирует старые разрешения и модели, где размещение существенно.

Физическое измерение иногда зависит от действия мгновенно: y = h(x, a), а не только h(x). Для света это прямой вклад собственной лампы; для температуры основной эффект может быть медленным. Такой прямой канал нужно указать в паспорте, иначе оценщик ошибочно объяснит включение лампы изменением внешнего состояния.

Точка датчика и цель рабочего места#

Измеряемое место и объект цели задаются раздельно. Если цель относится к рабочей плоскости, сенсор устанавливают в выбранной точке этой плоскости либо проверяют отдельное преобразование от сенсора к целевой зоне. Показание у монитора нельзя без проверки объявить освещённостью всего стола. В паспорте процесса сохраняются target_location_id, ориентация и размещение сенсора, способ сопоставления и область применимости; названия этих полей здесь задают семантику, а не новый бинарный профиль KQIP.

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

Пакет процесса переносит цель вместе с моделью, ограничениями и способом проверки результата. Список устройств и текст запроса дополняют этот контракт, но сами по себе не определяют поведение в новой комнате.

Предлагаемый формат Process Package#

Назовём переносимое описание пакетом процесса. Это собственный контракт Koobique, пока не стандарт и не готовая библиотека. Его читаемая часть объясняет смысл; машинная часть содержит типизированные поля, допустимые значения и ссылки на артефакты. Ниже — состав, который нужен уже для освещения.

Связывание с реальной комнатой#

Установщик пакета ищет подходящие возможности, но не связывает их автоматически по похожим названиям. Пользователь указывает физический объект и подтверждает нагрузку; тест определяет наблюдаемый эффект. Если лампа умеет только включаться и выключаться, параметр «яркость 37%» не становится доступным действием.

Рассмотреть схему

У пакета есть два результата проверки: структурная совместимость и эксплуатационный допуск. Первая означает, что типы и интерфейсы сходятся. Второй — что выбранная сборка проверена для данного сценария. Нельзя заменить второй результат успешной проверкой JSON Schema.

Жизненный цикл#

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

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

Ресурс «влияние на среду»#

Две программы могут одновременно хотеть управлять одним реле. Поэтому пакет запрашивает право на действие через арбитр. Приоритет определяется политикой пользователя и устройством, а не тем, какая модель прислала более высокий confidence.

У одной цели тоже могут быть несколько исполнителей. Освещение комнаты и экрана конфликтуют с экономией энергии; вентиляция конфликтует с шумом. Пакет объявляет целевые величины и цену компромисса, а жёсткие ограничения остаются отдельно. Человек должен понимать, что оптимизируется, а не обнаруживать это по неожиданному поведению системы.

Как добавлять новые алгоритмы#

В первой версии пакет — декларативные данные и ссылка на встроенный Rust-алгоритм. Затем можно допустить изолированный вычислительный модуль. Ему выдаются только объявленные входы, бюджет и интерфейс предложений. Доступ к сокетам устройств или файловой системе станции не возникает из самого факта установки.

Пример переноса в другую комнату#

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

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

Пакет процесса в первом экземпляре#

В E0 пакет — статическая проверяемая конфигурация и имя встроенного Rust-автомата. Не требуются магазин модулей, произвольный планировщик, граф распределённого исполнения или нейросеть. При этом сохраняются цель, входы, ограничения, условия допуска и проверка результата; они нужны и для одной лампы, чтобы следующий экземпляр не зависел от памяти автора.

Для PIR-only пакет не может заявить requires=presence_boolean и получить право автоматического ухода. Он требует конкретный observability_profile и запись допуска на выбранное размещение. При замене радара, перемещении сенсора или восстановлении старого пакета прежний допуск не возобновляется автоматически. Это проверяется до выдачи исполнительных полномочий.

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

От фразы к проверяемой цели#

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

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

Замкнутый набор вариантов#

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

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

Рассмотреть схему

Ожидаемые потери#

В простом варианте выбираем действие, минимизирующее ожидаемую потерю:

$$a^*=\arg\min_{a\in A_{\mathrm{allowed}}}\sum_s P(s\mid o)\,L(a,s).$$

$s$ — возможное состояние, $o$ — наблюдения, $L$ — согласованная цена результата. Если выключить свет при человеке гораздо хуже, чем ненадолго оставить его в пустой комнате, порог выключения должен быть строже порога включения. Это не универсальная моральная шкала, а настройка конкретного безопасного сценария.

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

Неполный и невозможный план#

Когда данные недостаточны, система может выбрать измерение или вопрос. Когда цель физически недостижима доступными устройствами, она должна сказать об этом. Например, одна включённая лампа даёт слишком мало света: многократная отправка ON не исправляет её мощность.

Если пользователь просит включить две лампы, операция не обязана быть физически атомарной. План хранит результат каждой команды. При частичном успехе интерфейс сообщает, что сработало и что осталось неизвестным. Компенсация — отдельное действие, не обещание отката физического времени.

Предложение должно быть объяснимым без рассказа модели#

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

Пример объяснения «Включил основную лампу: рабочее место считается занятым, измерено 160 лк, для этого профиля выбран минимум 280 лк. Ручной запрет не активен. Реле подтвердило включение; датчик показал рост света. Точное достижение цели будет проверено следующим измерением».

Варианты «измерить», «уточнить», «подождать» и «невозможно» — полноценные решения. Их отсутствие заставляет даже хорошую модель выбирать действие, которому не хватает оснований.

Два вида ограничений на одном примере#

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

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

Один порог стоимости не создаёт гистерезис#

Если сравнивать только ожидаемый ущерб от ON и OFF в одном независимом шаге, обычно получится один порог вероятности, а не два. Гистерезис появляется из памяти состояния, стоимости переключения или явно заданных ограничений dwell. В модели указываем цену недостаточного света за единицу времени, цену лишнего включения за единицу времени и отдельную цену перехода. Иначе частота пересчёта незаметно меняет смысл предпочтений.

Жёсткие права и пределы безопасности отсекают недопустимые действия до сравнения полезности. Неизвестное состояние не обязано вести к оптимистичному выбору: доступны «оставить», «спросить» и «измерить». Команда из общего микрофона не получает приоритет владельца из-за высокого confidence.

Для Koobique понимание физического процесса выражается в проверяемой модели с указанной областью применимости. Прогноз за её пределами требует дополнительных оснований и ограничений.

Koobique должен уметь связывать измерения и действия. Для этого не нужна сразу цифровая копия всего здания. Нужны небольшие модели: вклад светильника в lux, тепловая инерция комнаты, оценка присутствия, ограничение длительности включения и проверка обратной связи.

Четыре уровня интеллекта#

Первый уровень — пороговые правила с гистерезисом и выдержкой. Второй — явные автоматы состояний. Третий — оценивание параметров простых физических моделей. Четвёртый — планирование с несколькими целями и ограничениями. Языковая модель может помогать объяснению и формированию предложения, но не заменяет ни единицы, ни ограничения выхода.

Для первого кабинета достаточно первых двух уровней и нескольких исследовательских моделей третьего. Это не тупиковая архитектура: данные и версии моделей уже подготовлены к усложнению.

Свет как сумма вкладов#

Простая модель: E = Eday + k₁·u₁ + k₂·u₂ + ε, где E — lux в точке датчика, Eday — дневной вклад, u — состояние или уровень светильника, k — его измеренный вклад, ε — ошибка. Коэффициент зависит от позиции, отражений и настройки источника.

Для реле u равно 0 или 1. Для диммируемой нагрузки зависимость часто нелинейна, поэтому k·u является лишь приближением в проверенном диапазоне. Перестановка монитора или сенсора меняет модель. Если оценка дневного света ненадёжна, автоматизация должна сохранять безопасное понятное поведение, а не слепо вычитать старый коэффициент.

Температура как система с инерцией#

Рассмотреть схему

Уравнение C·dT/dt = P − H·(T − Tb) связывает эффективную теплоёмкость C, тепловую связь H, граничную температуру Tb и суммарный тепловой вход P. Tb может описывать коридор, соседние зоны и наружную среду через выбранную модель, а не обязательно уличный датчик. По пассивной записи при неизвестном P нельзя раздельно определить все C, H и P: это ограничение наблюдаемого эксперимента, а не недостаток оптимизатора. C представляет эффективную теплоёмкость всей выбранной зоны, включая вовлечённые в процесс массы, а не только находящийся в ней воздух. Открытое окно меняет воздухообмен и параметры модели; прежняя идентификация должна пройти проверку применимости в новых условиях.

Для постоянных параметров характерное время равно τ = C/H. Если условно C = 300 кДж/К и H = 100 Вт/К, τ = 3000 с, то есть 50 минут. Это вычислительный пример, не измеренные свойства кабинета. Он объясняет, почему опрос 100 раз в секунду не делает тепловое управление быстрее.

Дискретизация должна учитывать шаг. Грубый шаг может исказить динамику; чрезмерно малый добавит вычисления без новой информации. Для модели первого порядка при постоянных входах удобен точный экспоненциальный переход, а не только явный Euler.

Фильтр и задержка#

Экспоненциальное сглаживание yₙ = αxₙ + (1−α)yₙ₋₁ уменьшает разброс, но создаёт запаздывание. При нерегулярных данных α лучше связывать с реальным Δt и выбранной постоянной времени, а не считать одинаковым для любого интервала. Слишком медленный фильтр может скрыть быстрый отказ.

Фильтрация и safety-проверка разделяются. Невозможная температура или пропавший сенсор должны вызывать диагностическое состояние независимо от гладкой линии на графике. Raw остаётся доступным для исследования.

Гистерезис, выдержка и ручной режим#

Для релейного управления задаются два порога и минимальное время включения/выключения. Это уменьшает частое переключение при шуме. Но для освещения гистерезис не заменяет модель собственного влияния лампы, а для температуры не заменяет независимое ограничение нагревателя. Помимо гистерезиса отдельного правила нужен общий предел переходов выбранного реле и нагрузки, действующий для всех новых команд. Числа и место последнего guard у владельца GPIO фиксируются в аппаратном профиле по данным деталей и испытанию. Для лабораторного ограничения в Core явно указывается эта доверительная граница. Ручной OFF учебной лампы не задерживается симметричным cooldown; ограничение следующего ON сохраняет исходный deadline и ручные ревизии. Пока профиль не выбран и guard не проверен, предел физических переключений остаётся открытым условием постоянной эксплуатации.

ManualOverride блокирует обычную автоматику до явного освобождения в E0; временный lease — отдельное расширение E1. Освобождение ведёт к пересчёту по свежим данным, а не к исполнению очереди старых действий. Арбитр выбирает одно намерение, но локальные ограничения MCU сохраняют силу.

PID и более сложное управление#

PID имеет смысл для непрерывного регулируемого исполнительного механизма и измеряемой динамики. Для механического реле потребуются ограничения частоты, а для нагревателя — отдельная безопасность. Антиwindup нужен, когда интегральная часть продолжает расти при насыщенном выходе. Производную обычно фильтруют из-за чувствительности к шуму.

Первый световой сценарий проверяется конечным автоматом. PID можно отдельно исследовать с безопасной низковольтной нагрузкой и симулятором, если задача требует регулирования. Материалы MIT по обратной связи объясняют устойчивость, переходный процесс и цену задержки. [69]

Контроль и предложение — разные режимы#

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

Эксперимент физической модели#

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

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

Лестница сложности#

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

Оценщик состояния объединяет модель изменения и измерения. Фильтр Калмана полезен при соответствующих линейных предпосылках; нелинейные варианты требуют большего внимания к модели и распределениям. Для присутствия часто удобнее дискретная скрытая модель или конечный автомат, чем формально сложный непрерывный фильтр.

Регулятор с прогнозом, MPC, сравнивает несколько будущих последовательностей действий на горизонте, выполняет только первый шаг и пересчитывает план после нового наблюдения. Приближённая модель и ограничения важнее названия алгоритма. Практические материалы по идентификации и робастному управлению дают основу для такого подхода. [110] [111]

Рассмотреть схему

Пример целевой функции#

Для диммируемого низковольтного светильника можно предложить:

$$J=\sum_{k=1}^{H}\left[ w_L\,\max(0,L_{\min}-\hat L_k)^2+w_E E_k+w_\Delta(a_k-a_{k-1})^2 \right].$$

Здесь первое слагаемое штрафует недостаток света, второе — энергию, третье — резкие изменения. Единицы и масштабы нормируем явно: нельзя складывать люксы и ватты с произвольными коэффициентами и затем называть результат объективным комфортом. Жёсткие ограничения на диапазон, перегрев и права не заменяем штрафами.

Для бинарного реле $a_k\in\{0,1\}$ задача меняется. На коротком горизонте можно перебрать небольшой набор допустимых последовательностей с минимальным временем включения/выключения. При большом горизонте нужны другие методы, включая смешанно-целочисленную оптимизацию. OSQP решает выпуклые квадратичные задачи с вещественными переменными; бинарное реле нельзя просто выдать за поддерживаемую целочисленную переменную. [113]

Когда MPC избыточен#

Если лампа имеет одно состояние ON и стабильный вклад в свет, автомат с моделью фона, гистерезисом и паузой между переключениями может быть проще и не хуже. Мы обязаны сравнивать AI не с заведомо сломанным правилом, а с таким разумным эталоном.

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

Робастность и ограничения#

Робастный подход рассматривает диапазон возможной ошибки модели; вероятностный — допускает описанную вероятность нарушения при определённых предпосылках. Эти предпосылки требуют проверки. Слишком широкая неопределённость может сделать задачу неразрешимой; правильный ответ тогда — отказ от плана, а не скрытое ослабление ограничений.

Control Barrier Functions позволяют формулировать условия сохранения безопасного множества в рамках заданной динамики и доступного управления. Это серьёзный математический инструмент, но не универсальная защита от неправильной модели, задержки сети или залипшего контакта. [114] Для первого кабинета независимые ограничения и локальная безопасная логика важнее формальной терминологии.

Практическая траектория#

Сначала реализуем читаемый эталон в симуляторе. Затем идентифицируем небольшую модель по разрешённому эксперименту. Проверяем прогноз на отложенных эпизодах. Только после этого сравниваем MPC, гибридную модель и более сложную политику. Для исследования доступны do-mpc и OSQP; их наличие не означает, что Python становится обязательной средой на станции. [112] [113]

Какие параметры температуры действительно можно узнать#

Если одновременно умножить C, H и неизвестный P на одно положительное число, уравнение даст ту же температурную траекторию. Поэтому из пассивной записи можно исследовать τ=C/H и равновесный сдвиг P/H, но не приписывать каждому параметру единственное физическое значение. Известный тепловой вход или дополнительные измерения меняют постановку; ради этого первый стенд не подключается к опасному нагревателю.

T_next = Tb + P/H + (T_now − Tb − P/H) · exp(−Δt/τ)
τ = C/H     (постоянные P, H и Tb на шаге)

Это точная дискретизация выбранной однозонной модели, не точная модель любой комнаты. Пример C=300 кДж/К и H=100 Вт/К сохраняет учебный смысл, но не выдаётся за идентифицированную теплоёмкость кабинета. Если наблюдаются быстрый воздушный и медленный строительный режимы, сравниваем 2R2C или другую модель на независимых эпизодах и штрафуем лишнюю сложность.

Прогноз и исполнитель должны совпадать по возможностям#

Для реле с двумя состояниями непрерывное решение 0,37 не исполняется как «37%». Варианты — дискретное планирование или временное пропорционирование с минимальным временем ON/OFF и проверенным ресурсом контактов; для света часто лучше хороший автомат. PID и MPC не снимают необходимость аппаратного ограничения опасной нагрузки.

В целевой функции освещения учитываем присутствие, допустимый верхний световой предел и стоимость переключений. Квадрат положительной части дефицита для QP-солвера записывается через дополнительную неотрицательную переменную с ограничением, а не передаётся как произвольная нелинейная функция. Терминальная стоимость/ограничения выбираются под задачу; учебная сумма на горизонте сама не доказывает устойчивость.

Теневой режим не измеряет неслучившийся свет#

Без вмешательства можно честно измерить время вычисления, расхождение с действующей политикой, нарушение правил допуска и совпадение с разметкой намерения. Время ON, комфорт и энергия альтернативной политики — контрфактические величины. Для них требуется модель среды с оговорённой ошибкой либо разрешённый эксперимент/A/B. Replay не создаёт настоящих последствий другой команды.

Jev и JEPA — разные технологии. Для Koobique интересна идея маленьких типизированных решений; конкретная модель оценивается по автономности и нашим тестам.

Что подтверждено источниками#

TypeSafe представила Jev как модель семейства System One: вместо свободного текста она выдаёт типизированные решения. Основные формы — выбор из вариантов, оценка по шкале и двоичное суждение. Код приложения задаёт вопрос и допустимый ответ, а затем определяет дальнейший ход работы. [115]

На дату проверки, 15 октября 2026 года, официальная страница моделей различает версии и псевдонимы. В выпуске от 14 октября 2026 года объявлена Jev 1.14.0; изображения, увеличенный контекст и тип Box описаны как экспериментальные возможности. Поэтому было бы неверно считать семейство безусловно только текстовым. Для инженерного решения нужно фиксировать конкретную версию и профиль, а не ссылаться на постоянно меняющийся latest. [116] [120]

В изученных публичных материалах подтверждён доступ через API. Проверенного способа скачать веса и установить Jev автономно на Koobique не найдено. Это не утверждение о невозможности отдельной договорённости с поставщиком; это отсутствие подтверждения для обязательной локальной основы проекта. [116]

Что можно заимствовать без зависимости от сервиса#

Полезный паттерн — задать несколько коротких смысловых вопросов к одному снимку: тип запроса, помещение, группа света, действие, необходимость уточнения. В smart-home demo TypeSafe показывает параллельную оценку таких вопросов, после которой код отбрасывает нерелевантные ответы. [119]

В Koobique аналогичный контракт может выполнять локальный классификатор, embedding-модель с проверенными примерами, небольшая генеративная модель со строгим выводом или комбинация. Это собственный сервис типизированных решений, а не обещание воспроизвести качество Jev без её обучения.

Рассмотреть схему

Почему confidence не равен безопасности#

В опубликованной формуле TypeSafe для Choice с $n\ge 2$ вариантами:

$$c=\frac{p_{\max}-1/n}{1-1/n}.$$

При вероятностях $(0{,}6;0{,}3;0{,}1)$ и $(0{,}6;0{,}2;0{,}2)$ значение одинаково: $c=0{,}4$. Формула описывает отрыв максимума от равномерного выбора, а не вероятность того, что реле физически безопасно включить. Документация отдельно объясняет различие confidence и исходных вероятностей. [117]

Наше решение: даже максимальный score не отменяет ручной запрет, просроченный снимок или неопределённую нагрузку. Порог выбора настраивается по собственным эпизодам и последствиям ошибок. Арифметику, сравнение времени и проверку единиц выполняет код.

Указанные разработчиком слабые места#

Для Jev 1.13 опубликованы проблемы с числовой точностью, датами, косвенными формулировками, лишним контекстом и влиянием порядка вариантов. Также отмечена восприимчивость к намеренно направляющему содержимому. [118] Эти сведения не доказывают, что последующая версия ведёт себя точно так же; они задают необходимые классы наших тестов.

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

Место Jev в проекте#

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

Jev остаётся необязательным исследовательским кандидатом, пока автономное размещение не подтверждено. Для локального Koobique полезен строгий контракт типизированного решения; физическое исполнение сохраняется на собственной стороне.

Правильные части могут образовать неправильное целое#

Пусть модель независимо выбирает комнату «кабинет» и группу «подсветка кухни». Каждое маргинальное решение имеет высокий confidence, но пара недопустима. Поэтому типизированный ответ проверяется целиком по текущему графу объектов и правам. Лучше выбирать из заранее построенных допустимых кортежей; варианты NONE и NEEDS_CLARIFICATION обязательны.

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

Jev не является обязательной зависимостью E0/E1. Объявление 1.14 от 14 октября 2026 года уточняет возможности поставщика; ограничения опубликованного 1.13 не выдаются за установленные ошибки 1.14. Автономное размещение и применимость к нашему железу не подтверждены. При недоступности сервиса локальный типизированный интерпретатор и управление продолжают работать. [120]

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

JEPA: предсказывать представление#

В Joint-Embedding Predictive Architecture модель учится предсказывать внутреннее представление скрытой части данных по доступному контексту, а не обязательно восстанавливать каждый пиксель. V-JEPA 2 исследует понимание видео и действие-условное планирование в робототехнических задачах. Это не готовый контроллер комнатных реле. [121]

V-JEPA 2.1, опубликованная в марте 2026 года, развивает плотные пространственно-временные представления изображений и видео. Авторы описывают изменения функции обучения, самосупервизии и токенизации. [122] В официальном репозитории доступны код и модели; требования и лицензии необходимо проверять для выбранного checkpoint отдельно. [123]

Рассмотреть схему

Для первого Koobique камера не нужна. Загружать крупную видеомодель ради температуры и люксов — неподходящая исходная архитектура. Исследовательская альтернатива — небольшой энкодер временных окон наших сенсоров с масками пропусков и известными действиями. Это новая работа по обучению и проверке, а не автоматическая совместимость с весами V-JEPA.

Dreamer, TD-MPC2 и PETS#

DreamerV3 обучает модель среды и политику, используя предсказанные траектории. [124] TD-MPC2 сочетает латентную динамику и планирование для непрерывного управления. [125] PETS исследует вероятностные ансамбли динамики и планирование с учётом неопределённости. [126]

Для Koobique из этих направлений полезны действие-условная динамика, оценка расхождения моделей и разделение обучения/исполнения. Но их опубликованные результаты не измеряют безопасность нашего кабинета, работу с неизвестной нагрузкой или перенос из трёх домашних датчиков. Реальное обучение методом проб и ошибок на физических реле не становится приемлемым только потому, что политика успешно тренировалась в симуляторе.

Модели временных рядов#

Chronos-2 — пример предобученного вероятностного прогнозирования с несколькими рядами и ковариатами. [127] Такой подход можно проверить для прогноза температуры или фонового света. Он не доказывает причинное влияние команды: хороший прогноз при старом поведении пользователя может ошибаться после нового режима управления.

Первый эталон здесь — последнее значение, суточный профиль при достаточной истории и простая физическая модель. Большая модель имеет смысл, если на отложенных эпизодах улучшает нужный показатель с приемлемыми памятью и задержкой.

Активный вывод и ценность информации#

Active inference объединяет предпочтительные исходы и стремление получить информацию в одной вероятностной постановке. Исследования связывают её с байесовским выбором эксперимента и ожидаемой полезностью. [130] При этом вычислительная сложность и задание предпочтений — реальные инженерные вопросы, которым посвящены отдельные работы. [131]

Мы заимствуем практический принцип: иногда лучше сначала измерить, чем действовать. Для первого кабинета достаточно явного расчёта ценности дополнительного наблюдения; не нужно объявлять весь runtime реализацией свободной энергии.

Сравнение по роли в Koobique#

Базовый AI-профиль: локальное понимание намерений, оценка присутствия и небольшая гибридная модель динамики. JEPA и обучение политики — отдельная исследовательская ветка с более высоким порогом доказательств.

Чему должен научить опыт с JEPA#

В JEPA-подобных семействах предсказание представлений требует защиты от вырожденного решения, когда всё кодируется одинаково. В изучаемых реализациях используются конкретные target/online-энкодеры, stop-gradient, усреднение параметров и другие ограничения; точную комбинацию берём из выбранной работы и кода, не считаем четыре буквы универсальным алгоритмом.

Для нескольких медленных комнатных каналов первым соперником служат ручные признаки, линейная модель и небольшой временной предиктор. Допуск исследования — улучшение на независимых сценах с учётом ресурсов, качества данных и ошибки физического решения. Linear probe, прогноз скрытого канала и перенос размещения полезны как разные проверки, но ни одна отдельно не доказывает безопасное управление. [121][122][123]

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

Что сохранять рядом с измерением#

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

Разделяем сырые данные, производные признаки, метки человека и псевдометки модели. Последние полезны для экспериментов, но не становятся независимой истиной. Модель, обученная проверять саму себя по собственным ответам, может демонстрировать высокое согласие и повторять ту же ошибку.

Для происхождения данных полезен словарь PROV: сущность, действие преобразования, ответственный участник и связь производности. [104] В первой версии достаточно компактных идентификаторов и ссылок в локальном журнале; обязательная тяжёлая онтологическая инфраструктура не нужна.

Рассмотреть схему

Разметка без непосильной работы#

Для кабинета начинаем с эпизодов: вход, неподвижное чтение, уход, пустая комната с вентилятором, смена света, потеря датчика. Приложение позволяет отметить начало и конец и исправить метку позже. Пользователь не должен размечать каждую секунду вручную.

Отдельно храним точность времени метки. Нажатие «я ушёл» может случиться через несколько секунд после выхода. Эту границу нельзя превращать в ложную точную истину при оценке задержки обнаружения.

Разделение данных без утечки#

Случайное распределение соседних секунд по train и test создаёт иллюзию обобщения. Разделяем по целым эпизодам и дням; для проверки переноса — по расположению датчиков или комнате. После выбора порогов оставляем нетронутый итоговый набор. Иначе тест постепенно превращается в часть обучения.

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

Гибридная модель как первый кандидат#

Для света задаём $L=D+G\,u+\epsilon$: фон $D$, вклад лампы $G$, состояние $u$. Неизвестный $G$ оцениваем разрешённым экспериментом. Нейросеть, если понадобится, предсказывает остаток или изменения фона, а не всю физику с нуля. Модель должна иметь возможность признать, что перестановка лампы разрушила прежнюю связь.

Для температуры задаём приближённую структуру накопления и теплообмена, а затем оцениваем коэффициенты. Если данных недостаточно для раздельного определения параметров, храним их неопределённость или используем более простое эффективное описание. Увеличение числа параметров не добавляет информации в датчики. Основы такой постановки рассматриваются в материалах по идентификации систем. [111]

Обновление модели — смена поведения#

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

Переход к ограниченному управлению требует согласия и узкого набора действий. Плохая модель откатывается независимо от прошивки устройства. Базовый автомат и ручное управление остаются доступны. Автоматическое обучение в фоне допускается как вычисление кандидата, но не как скрытая выдача ему полномочий.

Что replay не доказывает Можно повторно проверить логику на прежних наблюдениях. Нельзя достоверно узнать физический результат действия, которого тогда не было, просто подставив его в запись. Для контрфактической оценки нужна проверенная модель среды или безопасный новый эксперимент. Иначе «сравнение политик» использует вымышленный исход.

Что сравниваем перед допуском модели#

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

Отчёт сравнения хранит не одну оценку accuracy, а последствия: время ненужного света, время недостаточного освещения, число переключений, пропущенные ручные приоритеты, задержку и расход памяти. Эпизоды с новой расстановкой или другим фоном выделяются отдельно. Когда новая модель не даёт полезного выигрыша, правильное решение — оставить эталон.

Воспроизвести решение и воспроизвести нейросеть — разные задачи#

Аудиторское воспроизведение использует сохранённый decision_snapshot: только сведения, доступные исходному решению, версии конфигурации и политик, хеши моделей, seed и события таймеров. При полном повторе потока сохраняют порядок поступления и допуска данных, привязанный к загрузке и виртуальным часам; время физического события хранится отдельно. Сортировка по времени события, источнику и последовательности подходит для ретроспективного пересчёта истории, но не переносит позднее наблюдение в знания прошлого решения. Текущие часы и новый descriptor не подменяют исторические. Для целочисленного автомата E0 проверяется совпадение нормализованного журнала решений.

Побайтное равенство нейросетевого вывода на ARM и x86 не обещается без специального детерминированного backend. Есть отдельные уровни проверки: сохранённый вывод модели воспроизводит аудит; повторный inference проходит заданные допуски; физический результат требует экспериментальной среды. Несовпадение чисел в допустимых пределах не должно менять разрешение опасного действия на границе без дополнительного анализа.

Данные делятся по времени и эпизодам: обучение на прошлом, настройка на следующем участке, тест на ещё более позднем. Между окнами оставляют интервал, закрывающий перекрытие входов и целевого горизонта. Нельзя случайно распределять соседние секунды одной истории между train и test. Если планируется off-policy оценивание, необходимы известная политика выбора и вероятности действий; их нельзя восстановить задним числом из одного результата.

Разделить наблюдаемый результат и альтернативную политику#

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

Сравнение света начинается с трёх явно заданных вариантов: простого порога как диагностического примера, сильного автомата, который уже учитывает собственный вклад лампы, и нового кандидата. В каждом прогоне одинаковы внешние условия, ограничения переключений и ручные воздействия. Результаты разделяют по времени недостаточного света, числу переключений, времени ON, ложным действиям и отказам от решения; один выигранный показатель не скрывает ухудшение остальных.

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

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

Измерение как действие#

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

Простой расчёт: $V_{\mathrm{info}}$ — ожидаемое уменьшение потери после нового наблюдения; $C$ — стоимость его получения. Измерение рассматривается, если $V_{\mathrm{info}}>C$ и оно разрешено. Это проектная упрощённая постановка, а не полная реализация active inference. Связь выбора информации и действия имеет отдельную исследовательскую основу. [130]

Рассмотреть схему

Три безопасных примера#

Сомнение в присутствии. PIR давно молчит, радар даёт пограничный сигнал. Можно временно получить более подробное окно радара, если модуль поддерживает такой режим и он проверен, либо спросить пользователя. Нельзя молча включить микрофон или камеру, на которые не выдавалось разрешение.

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

Подозрение на дрейф. Два температурных канала начинают расходиться. Вместо немедленной поправки одного по другому проводим согласованный сравнительный эпизод и проверяем размещение. Оба датчика могут одновременно ошибаться из-за общей причины.

Самокалибровка — только в разрешённом эксперименте#

Для низковольтной лампы можно предложить короткую последовательность OFF/ON с ограниченным числом переключений. Пользователь подтверждает, что это допустимо сейчас. Эксперимент фиксирует фон, выдерживает паузу, наблюдает эффект и прекращается при изменении условий или ручном вмешательстве.

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

Предел обучения «из любопытства»#

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

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

Аппаратные последствия#

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

Ценность нового измерения — ожидаемое улучшение решения#

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

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

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

Модель формирует предложение, которое проходит независимую проверку. Устройство применяет собственные ограничения, а результат действия сопоставляется с физическими наблюдениями.

Три уровня допуска#

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

Рассмотреть схему

Контракт предложения#

Предлагаем объект ActionProposal: уникальный ID, объект и действие, аргументы, инициатор, версия прав, снимок состояния, срок действия, предусловия и ожидаемый эффект. Он не содержит секретов устройства и не может указать произвольный сетевой адрес вместо зарегистрированного ресурса.

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

Гонка между планом и кнопкой#

В 10:00:00 модель предлагает ON. В 10:00:01 человек нажимает OFF. В 10:00:02 план готов к отправке. Если проверить ручной режим только до вычисления, старый план отменит волю пользователя.

Разводим три независимых величины: controller_fence связывает назначение станции с её ключом; output_revision меняется при установке выхода; manual_revision меняется при ручном намерении, даже если электрический уровень не изменился. Все локальные версии дополнены boot_id. Ручной режим — отдельное состояние, а не только число. Сверка новой версии после связи не даёт автоматизации права отменить действующий ручной запрет.

Доставка, повтор и неизвестный исход#

Используем семантику KQIP из глав 21–22: ID команды, дедупликация, срок действия, подтверждения и отдельный результат. Команда «установить ON» легче переносит повтор, чем «переключить». Но идемпотентность значения не делает любой физический процесс безрисковым: повторная подача питания может иметь особенности конкретной нагрузки.

Если подтверждение потеряно, исход может быть неизвестным. Сначала читаем состояние и проверяем наблюдения. Для неидемпотентной операции автоматический повтор запрещается или требует специальной процедуры. Нельзя объявить её невыполненной только из-за тайм-аута связи.

Пять записей о намерении и результате#

Ток лампы помогает обнаружить обрыв, но не заменяет световой контроль. Рост света может быть вызван окном; при неоднозначности результат «эффект совместим с ожиданием» честнее абсолютного утверждения причинности.

Независимость защиты#

Проверка ограничений не спрашивает ту же модель, правильно ли она решила. В E0 это небольшой Rust-модуль Core; его независимость логическая, не аппаратная: panic или OOM могут остановить весь процесс. Последний локальный рубеж — прошивка с собственным владельцем выхода; физическое снятие питания остаётся отдельным средством. Для опасных нагрузок потребуются независимые схемы и профиль риска, отсутствующие у учебной лампы. Модуль проверки остаётся малым и тестируется отдельно от предсказателя; для решения ему не требуется завершение GPU-задачи или AI-worker. Это требование к реализации не устраняет общие отказы процесса: проверяется поведение при зависании worker, исчерпании ресурсов и остановке Core.

Последствия ошибочного предложения ограничиваются проверяемыми условиями исполнения. Для каждого действия указаны ресурс, владелец, срок, пределы и способ наблюдения результата.

Ни распознавание речи, ни модель мира не получают прямой доступ к GPIO, SSH или ключам. Между предложением и выходом стоит независимый исполнитель с повторной проверкой условий. После команды отдельно фиксируются подтверждение выхода и достижение физической цели.

Разные счётчики защищают от разных устареваний#

ID команды отвечает на вопрос «это тот же запрос или новый?». Версия выхода — «менялось ли состояние после снимка?». Controller fence — «это ещё действующий хозяин инсталляции?». Локальная ревизия ручного действия — «не нажал ли человек кнопку после плана?». Эти поля связаны, но один общий счётчик не обязан надёжно заменять все четыре.

Конкретное двоичное представление следует закрепить в спецификации. На устройстве проверяется та часть предусловий, которая доступна локально; на станции — права, контекст и план. Во время разрыва связи кнопка меняет локальную ревизию. После соединения сначала согласуется текущее состояние, а не отправляется накопленная очередь старых желаний.

Приоритеты и атомарная граница действия#

Guard внутри Core уменьшает доверие к модели, но разделяет с Core память и отказ процесса. Поэтому инструкции узла не сводятся к «сервер уже проверил». MCU проверяет собственные boot, revision, срок и режим непосредственно в владельце выхода. Граница доверия остаётся: авторизованный, но скомпрометированный Core может лгать о пользовательской причине. E0 не заявляет защиту от всех действий такого контроллера; для более опасного применения нужны отдельные локальные полномочия и независимое оборудование.

Внешний настенный выключатель либо снятие питания лампы фиксируются как возможное вмешательство. APPLIED GPIO при отсутствии света не становится ложным успехом. Система не должна бесконечно щёлкать реле, пытаясь «исправить» физически разорванную цепь: лимит повторных попыток и уведомление входят в профиль.

Модель не выдаёт себе допуск#

Исполнитель получает не только предлагаемое действие, но и ссылку на исходный снимок, версию модели и область, для которой проверено её поведение. Core выводит права из своей текущей записи владельца и пакета процесса; поля ответа worker не создают эти права. Затем проверяются свежесть, состояние ручного режима, действительность привязки модели к размещению и допустимость воздействия. На MCU повторяются boot, fence, срок, ревизии и локальные ограничения.

У допуска есть область: конкретный объект, набор действий, диапазон, версия и условия измерения. Замена весов, калибровки, нормализации или размещения может вывести исполнение за эту область. До повторной проверки сохраняется согласованный базовый режим либо остановка автоматических действий по политике нагрузки. Ручная кнопка и независимая аппаратная защита не ждут, пока модель объяснит результат.

Отдельная приёмочная история связывает все уровни: worker получает снимок, человек нажимает OFF, затем приходит позднее предложение. Сохраняется исходная привязка запроса; обновление snapshot не превращает старый ответ в новое намерение. Исполнитель отказывает по изменённым условиям, фиксирует причину и сохраняет текущий выход. Это уже предусмотренный архитектурой принцип, который нужно подтвердить реализацией каждого клиентского пути, включая голос.

Быстрая запись полезна только тогда, когда понятно, что система может потерять при сбое.

outbox, сохранённая очередь ещё не завершённой отправки

В первом Koobique хранятся четыре разных класса данных: конфигурация и ключевые привязки; журнал принятых команд; текущие наблюдения; длительная история. У них разные требования к сохранности. Не нужно делать каждое измерение температуры таким же дорогим, как смену владельца, но нельзя терять принятую команду и продолжать показывать пользователю успех.

SQLite как исходный выбор#

SQLite подходит для одной станции, если архитектура учитывает одного писателя и локальный накопитель. WAL позволяет чтению и записи сосуществовать, но требует управления checkpoint и длительными читателями. Активная база не размещается на SMB/NFS только ради удобной резервной копии. В 2026 году исправлена ошибка WAL-reset; сборка должна содержать исправленную версию или подтверждённый backport. [51]

Это сознательный выбор зрелого SQL-хранилища, а не отказ от Rust. redb остаётся альтернативой для транзакционного key-value слоя, если его модель лучше подходит данным и прошла такие же проверки. Сравнение включает запросы, резервирование, миграции, память и поведение при отключении питания, а не только язык реализации. [53]

Транзакция принятия и outbox#

Рассмотреть схему

В одной транзакции сохраняются command_id, источник, неизменяемые параметры, условия исполнения, минимальные основания и outbox. Только после успешного commit выдаётся ACCEPTED. В живой загрузке Core допускает повтор того же тела и ID до исходного срока. Перед первой записью пакета в сокет долговечно фиксируется DeliveryAttempt. После reboot/resume отсутствие такой отметки позволяет назвать запрос неотправленным/EXPIRED; отметка без результата означает возможно исполненную команду и требует UNKNOWN/сверки. Старый outbox не становится новым намерением. Приёмка включает сбои до и после commit отметки, до и после write и между GPIO и ACK.

Если сеть получила пакет, но станция упала до записи результата, при восстановлении проводится сверка. Физический эффект нельзя откатить транзакцией SQLite. Поэтому важны идемпотентность, история результатов на устройстве и состояние UNKNOWN.

Режим синхронизации#

Для критичного журнала требуется режим, соответствующий обещанной сохранности при потере питания. В WAL выбор FULL/NORMAL меняет момент синхронизации и допустимую потерю последних транзакций. Эти настройки задаются осознанно для конкретного соединения/хранилища и проверяются; нельзя просто скопировать «быстрые PRAGMA» из случайного примера. [93]

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

Объём данных#

Условные 100 событий в секунду по 200 байт дают 1,728 ГБ в сутки до индексов и служебных расходов. Для кабинета такая частота обычно избыточна, но расчёт показывает опасность бесконтрольного логирования. 10 событий в секунду уменьшают исходный объём в десять раз, однако политика хранения всё равно нужна.

Raw-история сохраняется ограниченный срок, затем строятся агрегаты по минутам/часам. Агрегат содержит минимум, максимум, среднее, число валидных образцов и долю пропусков. Только среднее скрывает короткие, но важные изменения.

Аудио хранится отдельно и по умолчанию не архивируется постоянно. Модели, резервные копии и диагностические пакеты имеют собственные каталоги и квоты. Заполненный диск должен сначала отключить необязательный сбор данных, а не сломать конфигурацию и обновление.

Резервная копия#

Для работающей SQLite применяется согласованный Backup API или эквивалентная процедура, а не копирование одного файла без WAL. Копия включает описание версии, конфигурацию, ключи в защищённом виде и необходимые данные адаптеров. Проверка чтения архива не равна проверке восстановления всей инсталляции. [52]

Ключи восстановления должны быть доступны владельцу отдельно от единственного хаба. Но резервная копия не предназначена для одновременного запуска двух управляющих станций. После переноса меняется controller_fence, а старая копия не получает автоматически действующие полномочия.

Миграции#

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

Испытание, без которого БД не принята#

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

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

Три режима данных#

Актуальный снимок нужен для быстрых решений. Он находится в памяти, содержит свежесть и ссылки на исходные записи. После перезапуска восстановленное значение не объявляется свежим без проверки.

Журнал решений и конфигурации сохраняет права, связи объектов, версии, команды и их результаты. Для обещания «надёжно принято» нужна соответствующая транзакционная запись. Нельзя считать ответ успешным до шага, сохранность которого обещана пользователю.

История измерений допускает агрегирование и ограниченные потери согласно профилю. Аудио, видео и большие диагностические потоки имеют отдельную политику и по умолчанию не записываются постоянно.

Рассмотреть схему

Выбор хранения для первого экземпляра#

Для конфигурации и журнала исходным кандидатом остаётся SQLite с ограниченным писателем и явной политикой синхронизации. WAL поддерживает параллельное чтение и запись, но не отменяет требования к файловой системе и согласованному резервированию. [51] Альтернативу на Rust, например выбранное встроенное key-value хранилище, сравниваем по реальным транзакциям и восстановлению, а не по языку реализации.

Большие записи можно вынести в последовательные чанки с индексом. MCAP задаёт контейнер для каналов и сообщений с временными метками; он полезен как кандидат формата записи/повтора. [108] Arrow подходит для столбцового обмена пакетами данных в аналитике. [109] Ни тот ни другой не обязателен для каждого маленького KQIP-сообщения.

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

Сколько стоит «сохранять всё»#

Четыре аудиоканала по 16 000 отсчётов/с и 16 бит дают $4\cdot16\,000\cdot2=128\,000$ байт/с — около 11,06 ГБ за сутки без служебных расходов. Сто событий в секунду по 200 байт — 1,728 ГБ за сутки. Это расчётные объёмы в десятичных единицах, не показатели компрессии.

Храним краткое кольцевое окно только при необходимости, задаём сроки удаления и резерв под критический журнал. Заполненный диск не должен приводить к бесконечному повтору команды. У пользователя есть отдельные переключатели для хранения аудио, диагностических данных и участия в обучении.

Совместимость KQIP#

Новые логические сущности не требуют ломать транспорт. Предлагаем согласование поддерживаемых дескрипторов наблюдений и результатов. Канал может объявить единицу, шкалу времени, параметры измерения и ограничения; отдельные сообщения ссылаются на него компактно.

Неизвестный тип не превращается в ближайший знакомый. Неизвестное критическое поле отклоняет действие; необязательную диагностику можно пропустить только по явному правилу. Логическая запись и бинарное кодирование версионируются раздельно: расширенный паспорт наблюдения не меняет молча профиль KQIP 0.2; малый вектор 0.1 оставлен историческим примером. Новая редакция кодека требует согласованных тестовых векторов.

Дубли, порядки и перезапуск#

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

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

Быстрое состояние, долговечный журнал и большой архив имеют разные требования. Их разделение — логическое; оно не обязывает покупать сервер СУБД или разворачивать микросервисы.

Нет места на диске — нет обещания ACCEPTED#

Бюджет диска включает критическую БД, WAL и checkpoint, экспорт, временное обновление, две версии моделей и резервную копию. Начальный резерв для E0 выбирается как большее из 1 ГиБ и удвоенного максимального текущего служебного файла; это порог остановки тяжёлых задач, не универсальная гарантия. Перед commit всё равно обрабатываются ENOSPC, I/O и fsync-ошибки. Неподтверждённая запись не выдаёт ACCEPTED.

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

Минимальные основания решения сохраняются в той же критической транзакции: использованные значения и интервалы, статусы, версии, активные ограничения и ссылки на полный raw. Удаление телеметрии тогда не уничтожает смысл команды. Исчезнувшая по retention подробная запись отмечается «истёк срок хранения», а не «повреждение». Записи журнала неизменяемы; версия схемы и upcaster дают новое представление, не переписывая прошлое.

Ресурс накопителя считаем по записи, а не по JSON#

Если ради 200 байт отдельно записать страницу 4 КиБ в WAL, а затем ещё раз при checkpoint, теоретический пример даёт примерно 40-кратное отношение. Это не измеренный коэффициент SQLite на нашей схеме и не полный NAND write amplification. Индексы, batch, checkpoint, файловая система и контроллер меняют результат. Проверяем host writes, объём WAL, реальную частоту commit и доступную телеметрию SSD; сравниваем с ресурсом конкретного накопителя. [51]

Непрерывное аудио по умолчанию не сохраняется. Для диагностики — ограниченный RAM-буфер и явное согласие на эпизод. Транскрипты и производные признаки имеют отдельные сроки хранения. Лицензия весов, голосов TTS и runtime записывается в манифест; язык реализации сам по себе не решает эти ограничения.

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

KMP позволяет разделять общую логику между Android и iOS, сохраняя платформенные интеграции там, где они действительно различаются. В Koobique общими могут быть доменные состояния, сценарии подключения, обработка команд и представление данных. BLE, защищённое хранилище, разрешения, аудио и жизненный цикл требуют платформенных адаптеров. [54]

Общий код и Rust#

Общий Rust-код полезен для контрактов и проверок, но стандартный UniFFI генерирует Kotlin/JVM и Swift, а не готовый commonMain KMP. Кандидаты: expect/actual над этими двумя границами или Gobley с KMP-привязками. До выбора нужен небольшой опыт на Android и iPhone: cancellation, callbacks, многопоточность, память и доставка ошибок. Слой FFI не должен открывать внутренние указатели Core. [155][154]

Альтернативный путь — отдельный Kotlin-кодек по той же спецификации и golden vectors. Он уменьшает FFI, но создаёт две реализации. Выбор делается после небольшого proof-of-concept: подключение, одно сообщение, отмена соединения и обновление библиотеки на обеих платформах. Не стоит включать всю Rust-сеть в приложение только ради сокращения ста строк Kotlin.

Рассмотреть схему

Главный экран и поведение команды#

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

Карточка температуры показывает возраст данных; карточка присутствия умеет UNKNOWN. Недоступное устройство не исчезает из списка и не выглядит выключенным. История решения доступна через действие «почему»: использованные условия, источник и фактический результат.

Подключение без лабиринта настроек#

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

Разрешения запрашиваются в момент понятной необходимости. Android имеет отдельные требования к Bluetooth-разрешениям, а iOS — к доступу в локальную сеть. Приложение должно объяснять, что оно ищет локальные устройства, а не требовать всё при первом запуске. [56][57]

Хранение ключей#

Android Keystore и Apple Keychain дают платформенные механизмы хранения секретов. Их доступность и ограничения используются через адаптеры, а не заменяются файлом с ключом в обычных preferences. Экспорт резервного ключа владельца — отдельная операция с явным предупреждением, не часть стандартного диагностического пакета. [71][97]

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

Фоновый режим#

Нельзя рассчитывать, что приложение постоянно держит BLE, микрофон и сетевой сокет в фоне одинаково на Android и iOS. Android документирует специальные способы фоновой BLE-работы; другие функции имеют собственный жизненный цикл. Поэтому автоматизации живут на станции, а не в мобильном фоне. [83]

Push через внешние службы может быть удобным дополнением, но не основанием безопасности. При отсутствии интернета локальная карточка состояния работает, а внешнее push-уведомление может задержаться. Уведомление об опасном процессе не заменяет локальную защиту оборудования.

Работа с голосом на телефоне#

На первом этапе используется кнопка записи. Аудио передаётся в станцию по защищённой сессии и обрабатывается локально. Это даёт RU/EN-команды без немедленной интеграции микрофонов в куб. Альтернатива — локальное распознавание на телефоне, если выбранный runtime и политика платформы позволяют полностью офлайн-режим.

Приложение показывает распознанный объект и при необходимости уточнение. Различие «свет» / «подсветка» разрешается через модель комнаты. Нельзя молча выполнить случайное ближайшее имя только потому, что STT дал похожую строку.

Сборка и установка личного приложения#

Android-экземпляр должен иметь воспроизводимую подписанную сборку и сохранённый ключ обновления. На iOS заранее проверяются Xcode, provisioning и ограничения выбранного типа аккаунта. Сам факт наличия MacBook не означает бессрочную установку любой development-сборки; текущие условия проверяются по документации Apple. [58]

Приёмка UX#

Дать второму человеку подключить тестовый узел без устной подсказки. Преднамеренно ввести неверный пароль, отказать в разрешении и прервать процесс. Успех — не только подключение, но и понятный способ продолжить без сброса всей инсталляции.

Мобильное приложение связывает состояние переключателя с целью пользователя, неопределённостью и пределами разрешённой автоматизации.

Что видит пользователь#

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

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

Рассмотреть схему

RU/EN и неоднозначность#

«Включи свет», «включи освещение» и “turn on the lights” могут соответствовать одному намерению. «Подсветка» может быть отдельным физическим объектом. Поэтому словарь синонимов связывается с возможностями и пространствами установки, а не глобально заменяет каждое слово «свет» на ID первого реле.

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

Локальный тракт речи#

Последовательность сохраняется: захват, определение речевого участка, распознавание, интерпретация, проверка прав, исполнение и ответ. На первом этапе телефон предоставляет микрофон, а станция или существующий ПК выполняет выбранные локальные модели. Встроенный голосовой модуль куба добавляется после испытания акустики и вычислительной нагрузки; аппаратные варианты разобраны в главах 41–42.

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

Что считать успехом голоса#

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

Отдельные наборы: русский, английский, смешанная речь, шум вентиляторов, похожие имена, отрицания и составные запросы. Текст из телевизора или воспроизведённой записи не становится командой владельца только потому, что распознаётся уверенно. Риск голосового запуска и методы подтверждения задаются по классу действия.

Обучение пользовательскому смыслу#

Человек может назвать настольную лампу «моя подсветка». Система сохраняет явный локальный псевдоним после подтверждения. Повторяющееся исправление может породить предложение обновить словарь. Не меняем автоматически нагрузку, права и глобальный смысл команд для остальных пользователей.

Приложение связывает человеческую цель с физическим объектом. AI помогает понять речь; авторизация, неоднозначность и проверка результата остаются видимыми и управляемыми.

Обнаружение без подмены доверия#

Сервис объявляется как _koobique._tcp; TXT содержит только ID установки, поддерживаемый профиль и подсказку идентичности. Отпечаток из mDNS не является доверенным pin: любой сосед может объявить похожую запись. Android использует NsdManager, iOS — Bonjour/NWBrowser с необходимыми разрешениями Local Network и списком сервисов. Отказ разрешения показывается отдельно от отсутствия Hub. MulticastLock не назначается всем сборкам автоматически: необходимость зависит от того, используется системное NSD или собственные multicast-сокеты. [159][57]

Один элемент управления показывает текущий snapshot, рядом — выполнение конкретной команды. Поздний APPLIED(A) обновляет историю A, но не заменяет более новый OFF. При UNKNOWN текст объясняет действие: «не удалось подтвердить; проверить состояние», а не «включено». После истечения запроса новая попытка требует текущих условий и нового ID.

В приложении предусмотрены VoiceOver/TalkBack, масштабирование текста и обозначения состояния не только цветом. «Ручной режим» сопровождается ответом, когда вернётся автоматика. Для E0: «до команды “вернуть автоматику”». Технические boot/fence/lease раскрываются только в диагностике, не перегружают основной экран.

Общий микрофон телефона в первом опыте передаёт аудио на локальный speech-worker Hub. Системное распознавание iOS/Android не считается автоматически офлайн; использование Apple Speech требует проверки supportsOnDeviceRecognition и requiresOnDeviceRecognition для конкретного языка. При отсутствии локального режима нет скрытого перехода в облако. [176]

Намерение приложения и команда устройству#

Приложение отправляет пользовательское намерение в Core. Ядро проверяет права, разрешает объект, фиксирует основания и создаёт одну или несколько команд KQIP для узлов. Поэтому пользовательский запрос и попытка исполнения имеют разные идентичности и историю. API приложения должен описывать их связь, чтение snapshot и обновлений, отзыв сессии, ошибки и восстановление подписки. Перенос KQIP в телефон сам по себе этих операций не определяет; до реализации клиента нужен отдельный проверяемый контракт.

Для команды «включи свет» важнее правильно выбрать объект, чем сгенерировать длинный красивый ответ.

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

Рассмотреть схему

Кандидаты распознавания#

Эти проекты предоставляют разные реализации и модели. Для русского нельзя случайно выбрать англоязычную.en-модель и затем оценивать весь подход как неработающий. Скорость зависит от весов, квантования, CPU/GPU и длины аудио; готовые репозитории служат основой эксперимента, а не обещанием конкретной задержки. [61] [62][73][99]

VAD и конец фразы#

VAD определяет, есть ли речь, а не смысл команды. Silero VAD — один из доступных кандидатов. Он помогает не отправлять в STT непрерывную тишину и шум, но может обрезать тихое начало или конец. Нужен небольшой pre-roll и согласованная задержка завершения. [63]

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

Намерение и объект#

После текста формируется структура: действие, объект, помещение, параметры и контекст. Слова «включи свет» и «включи освещение» могут указывать на основной светильник. «Включи подсветку» указывает на другой capability или сцену, если она существует. Если в комнате две подсветки, требуется уточнение.

Рассмотреть схему

Для первого экземпляра полезен ограниченный intent-parser со словарём синонимов, именами устройств и шаблонами параметров. Он проще тестируется и не требует большой LLM. Контекст включает выбранную комнату, источник микрофона и текущий диалог уточнения. Предположение о комнате не должно быть скрытым.

Где уместна языковая модель#

LLM может преобразовать разнообразную фразу в ограниченную структуру или объяснить причину действия. Ей передаётся только разрешённый каталог объектов и операций. Выход валидируется по схеме, правам, диапазонам и актуальному состоянию. Никакого shell, SQL или прямого GPIO из сгенерированного текста.

llama.cpp и Candle — варианты локального вывода, но наличие такого runtime не создаёт безопасный агент само по себе. Для команды с побочным эффектом особенно важно отделить предложение от исполнения. [66][73]

Ответ и озвучивание#

Короткий ответ сообщает результат: «Основной свет включён» после подтверждения; «Команда отправлена, подтверждение не пришло» при неопределённости. Не следует всегда говорить «готово» сразу после приёма звука. Для простых случаев достаточно заранее подготовленных фраз; локальный TTS добавляет гибкость.

Piper — кандидат синтеза, при этом лицензия программы и конкретных голосов проверяется отдельно. Первые RU/EN-ответы можно сделать текстовыми, чтобы не смешивать ошибки распознавания и акустическое эхо динамика. [65]

Корпус команд для проверки#

Набор включает разные голоса, темп, расстояния, шум, отрицания и похожие имена: «не включай свет», «выключи подсветку», «включи свет в коридоре», «set the desk light to…», «turn off the backlight». Отдельно записываются обычный разговор и телевизор/ музыка, которые не должны запускать действия.

Главные показатели: доля правильно выбранных действий и объектов, ложные исполнения, запросы уточнения и время до результата. WER текста полезен, но не равен безопасности: одна ошибка в слове «не» опаснее нескольких ошибок в необязательной части фразы.

Мощность и конкуренция#

Speech-worker имеет ограничение числа запросов. Устройство сначала возвращает короткое подтверждение захвата, затем результат. Большая модель не должна задерживать выключение реле или блокировать БД. При перегрузке голос может перейти на меньшую модель или сообщить о временной недоступности; уже работающие правила сохраняются.

Первое сравнение моделей#

На имеющемся ПК записать не менее нескольких десятков RU/EN-команд и негативных примеров. Прогнать два размера Whisper либо Whisper и Vosk/sherpa. Сохранить точность намерений, задержку после конца речи и память. Только после этого выбирать постоянный вычислитель для голоса.

Сравнивать на собственной тишине и собственных словах#

К Whisper добавлены GigaAM и Vosk как кандидаты, а не готовые победители. Грамматически ограниченное распознавание может быть удобно для малого набора команд; возможность менять словарь зависит от модели. Русский и английский проверяются отдельными наборами и смешанными названиями. Лицензия конкретных весов и доступный backend подтверждаются до включения в пакет. [163][164]

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

Свободный LLM-парсер не входит в E0. Для E1 небольшой локальный кандидат может использовать constrained decoding, но синтаксически правильный JSON всё равно проходит совместную семантическую проверку. Бюджет вычисления измеряется на выбранном Hub; обещание «модель 1–4B всегда отвечает за 300 мс» не принимается без стенда.

Акустическая система проектируется вместе с корпусом и вентиляцией. Для неё заранее предусматриваются размещение, объём и условия распространения звука.

Первый тракт — телефон или имеющийся Fifine. Он позволяет отделить качество модели от неизвестной геометрии микрофонов. Следующий шаг — выносной USB-массив с документированными режимами. Только после этого стоит переносить микрофоны в куб.

Один микрофон, массив или спутник#

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

reSpeaker — пример семейства готовых модулей, где важно выбрать точную модель и режимы USB. Нельзя покупать произвольную плату с таким названием и ожидать одинаковый набор каналов, AEC и firmware. [67]

Захват и формат#

Для многих speech-моделей удобен моно PCM 16 кГц, 16 бит: это 32 КБ/с без служебных данных. Десятисекундная фраза занимает около 320 КБ. Если устройство захватывает 48 кГц, выполняется одно качественное преобразование частоты, а не несколько каскадов в разных службах.

Параметры захвата фиксируются: частота, формат, каналы, gain, AGC, обработка устройства и программы. Иначе сравнение двух моделей может на самом деле сравнивать два разных аудиотракта. ALSA предоставляет низкоуровневый путь, а более высокий аудиосервер может упростить маршрутизацию; выбор проверяется по задержке и восстановлению USB. [40]

Эхо и опорный сигнал#

Рассмотреть схему

Когда станция отвечает через динамик, часть звука возвращается в микрофоны. Эхокомпенсации нужна синхронизированная опора того, что действительно воспроизводится. Разные устройства USB могут иметь разные часы и задержки; алгоритм должен учитывать дрейф, иначе компенсация ухудшается со временем.

Во время одновременной речи человека и динамика нужен режим double-talk. Простой запрет слушать во время ответа облегчает первую версию, но мешает перебиванию. Это допустимый явно описанный этап, а не скрытый дефект.

Механика микрофонов#

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

Динамик имеет собственную камеру или контролируемое акустическое оформление. Просто прикрутить его к общей стенке куба — значит передать вибрацию корпусу и микрофонам. Мощность динамика не компенсирует плохое расположение; для коротких ответов часто достаточно умеренной громкости и хорошей разборчивости.

Wake word#

Постоянное ожидание слова активации — отдельный процесс с небольшим ресурсом. После него запускается основной тракт. openWakeWord предоставляет готовую инфраструктуру, но готовые модели и языковые возможности проверяются отдельно; русское слово «Кубик» не считается поддержанным только потому, что проект умеет wake word. [64]

До обучения собственного слова активации первый куб использует кнопку push-to-talk. Затем собирается корпус положительных и отрицательных записей с согласием участников. Нельзя оценивать модель только по голосу автора, сказанному рядом с микрофоном.

Голос не является надёжной аутентификацией#

Запись, динамик или похожий голос могут воспроизвести команду. Для света это один уровень риска, для замка или опасного оборудования — другой. Более чувствительные операции требуют подтверждения в приложении или физического действия. Распознавание говорящего, если оно появится, не должно автоматически считаться достаточной защитой.

Инженерная карта аудио#

Интеграция в корпус#

Сначала нужен рабочий голосовой тракт вне куба. Встроенная версия принимается только после сравнения с этим эталоном. До этого корпус резервирует место, питание и USB, но не фиксирует окончательное число микрофонов и отверстий.

Что акустическая обработка не защищает#

AEC использует опорный сигнал собственного динамика и не обязан подавлять команды из телевизора или чужую запись. Для общего микрофона нужен отдельный ограниченный субъект «комната», не автоматическая идентификация владельца по голосу. Изменение доступа, SSH, перенос ключей и обновления голосом комнаты не разрешаются.

В аппаратном профиле микрофона предусматриваются физическое mute и индикатор, связанный с реальным отключением тракта, а не только с нарисованной иконкой. Точка отключения выбирается по модулю: питание MEMS, цифровой тракт или иной проверенный механизм. После mute тестируется отсутствие пригодного аудиопотока; внешний USB-микрофон требует своей документированной процедуры.

Для стенда речи задаём условия, а не универсальную цифру качества: расстояния 1 и 3 м, три оборотных режима вентилятора, измеренный шум, пять согласившихся дикторов при возможности. SNR, ERLE и AOP полезны как диагностические величины с определённой методикой. Их паспортное значение не заменяет долю правильных действий на RU/EN. Слово активации выбирается после сравнения нескольких кандидатов; короткое «Кубик» не считается уже утверждённым.

Качество обновления проверяется при сбоях питания, связи и запуска. Успешная установка в штатных условиях составляет только часть этой проверки.

В Koobique обновляются системный образ, Rust-приложения, прошивки MCU, модели речи и мобильное приложение. У них разные зависимости и способы отката. Один общий номер «версия системы 1.0» не описывает совместимость всех компонентов.

Воспроизводимая сборка#

Для собственного кода фиксируются commit, toolchain, Cargo.lock, конфигурация функций и внешние SDK. Для моделей — источник, лицензия, хеш весов, квантование и runtime. Для плат — аппаратная ревизия и таблица контактов. Сборка, использующая latest из нескольких независимых проектов, плохо подходит для поиска регрессии.

Cargo vendor позволяет сохранить зависимости локально и подготовить более воспроизводимый офлайн-процесс. Однако этого недостаточно для всех системных библиотек и инструментов ESP-IDF: они также входят в манифест окружения. [94]

Обновление станции#

Первый разработческий стенд может обновлять приложение штатным пакетом с проверкой подписи и возможностью отката. Для самостоятельного appliance-профиля предпочтителен A/B-образ: новый раздел записывается отдельно, проверяется и загружается пробно. Выбранная инфраструктура должна учитывать загрузчик, данные и подтверждение успешной работы. [91]

Рассмотреть схему

Проверка здоровья включает не только факт запуска процесса: доступны конфигурация, БД, локальный API, сеть и критические системные ресурсы. Отсутствие одного спящего датчика не обязательно означает неудачный образ, поэтому health gate формулируется по классам зависимостей.

Обновление устройства#

Устройство проверяет подпись, аппаратную совместимость и целевой раздел. При пробной загрузке выполняет самопроверку и подтверждает образ только после минимального функционирования. ESP-IDF описывает OTA и rollback; конкретная таблица разделов и правила принятия являются частью прошивки Koobique. [36]

Перед обновлением Actuator переводится в режим обслуживания. Для лампы E0 установлен OFF; после reset или OTA-reboot действует BOOT_INHIBIT до явного освобождения. Сохранение уровня при потере только Wi-Fi не распространяется на reboot. Для будущей опасной нагрузки нужен отдельный профиль. Во время обновления приложение показывает ограниченную доступность и не ставит обычные команды в бесконечную очередь.

Подпись, хеш и ротация#

Хеш обнаруживает изменение относительно известного значения, но не отвечает, кто разрешил образ. Подпись и политика доверенных ключей решают авторизацию выпуска. Для метаданных, разделения ролей и ротации полезна модель TUF, но её внедрение должно учитывать автономную работу и восстановление доверенного времени. [84]

Откат после неудачного обновления и запрет возврата к уязвимой версии — разные требования. Нельзя включить anti-rollback так, что единственный рабочий старый образ навсегда заблокирован ещё до подтверждения нового. Нужна согласованная последовательность принятия.

Модели как исполняемые зависимости#

Новая speech-модель может изменить смысл распознанной фразы без изменения Rust-core. Поэтому она проходит тот же корпус команд и негативных примеров. Хранится предыдущая принятая модель, а установка не удаляет её до проверки. Большой файл не должен заполнять диск так, что сломается журнал управления.

Формат модели также является входом сложного runtime. Используются доверенные источники, хеши и изоляция процесса. Модель не получает автоматически доступ к сети, ключам и файловой системе пользователя.

Локальная доставка#

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

Полный offline-набор для первого экземпляра включает образ ОС, toolchain или инструкцию его воспроизводимого получения, зависимости, прошивки, модели, мобильную сборку и документацию. Нельзя назвать систему полностью автономной для восстановления, если единственный загрузчик скачивается с недоступного сайта во время аварии.

Матрица обновления#

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

Два слота без rollback — ещё не отказоустойчивое OTA#

В ESP-IDF требуется явно зафиксировать CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE и процедуру пробной загрузки. Приложение подтверждает пригодный образ через esp_ota_mark_app_valid_cancel_rollback только после self-test. Наличие ota_0 и ota_1 не включает механизм само по себе. В тест входят потеря питания при записи, невалидный образ, зависание пробной версии и возврат. [36]

Self-test E0: корректная привязка и чтение конфигурации, безопасный выход OFF, работа кнопки, запуск критических задач и совместимость данных. Интернет не требуется; бесконечное ожидание роутера не должно сделать каждое обновление неисправным. До reboot Actuator согласованно переводится в обслуживание; длительность недоступности кнопки показывается и измеряется.

Rollback и anti-rollback согласуются до записи необратимых параметров. Нельзя повысить нижнюю разрешённую security version так, что предыдущий единственный исправный образ перестанет загружаться до подтверждения нового. Данные владения, fencing и отзыва не должны возвращаться вместе с A/B-разделом. Если старая прошивка не умеет читать новую схему доверия, её возврат не объявляется пригодным.

Для автономного Hub выбран кандидат RAUC с интеграцией конкретного загрузчика, boot counting, health gate и отдельным /data. На H0 пока достаточно версионированного пакета приложения и отката в контролируемой среде; это не имитация готового A/B всей ОС. Сравнение SWUpdate/OSTree остаётся альтернативой, если выбранная плата не укладывается в исходный путь. [171]

Новая версия работает только с проверенной матрицей Core × MCU × app × schema × wire. Совместимость N/N−1 — цель испытаний, не обещание по номеру. Core N и N−1 могут оба поддерживать KQIP 0.2; старый учебный Hello0.1 не обязан поддерживаться. Обновление идёт через один узел-кандидат, наблюдение и затем остальные. Чанки bulk имеют offset, длину и контроль целого подписанного образа; resume относится к тому же хешу. При будущей несовместимой смене wire нужны negotiation/dual-profile стратегия и проверка поэтапного обновления без ослабления доверия.

В CI фиксируются toolchain/lockfiles/SDK, проверяются cargo-audit, cargo-deny, происхождение пакетов и SBOM. Положительный результат этих инструментов означает отсутствие найденных известных проблем по их базе, а не доказательство отсутствия уязвимостей. Изменение runtime модели также проходит проверку поведения. [172][173]

Ниже задан конкретный световой сценарий и его проектный профиль для первых испытаний. Пороговые значения подлежат проверке в выбранной комнате и не объявляются универсальными настройками комфорта.

Условия опыта#

В комнате установлены Sense, Presence и Actuator. Лампа 12 В изображает основной свет. Телефон имеет роль обычного пользователя. Температура пока только измеряется и объясняется; никакой обогреватель не включается автоматически. Все задержки и пороги ниже — стартовые параметры стенда, которые корректируются после наблюдений.

Sense выдаёт освещённость раз в секунду и температуру раз в несколько секунд. Presence публикует признаки движения и состояние доступности. MCU знает момент своего измерения; сервер знает время приёма и предел актуальности. Пропущенный пакет не превращается автоматически в отсутствие человека.

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

Хронология#

Рассмотреть схему

До входа. Последний достоверный lux равен 42, присутствие Empty, реле OFF. Это не одно «состояние комнаты», а согласованный набор наблюдений с собственной свежестью.

Человек входит. Новый признак запускает Candidate. Затем подтверждается Occupied. Правило проверяет актуальность lux, отсутствие ручного запрета и права автоматизации на основной свет. Оно создаёт команду set(true) с отдельным ID и причиной: «вход в тёмную комнату».

Станция принимает команду. Журнал и outbox фиксируются транзакционно. Приложение показывает «выполняется», а не рисует безусловный успех. Устройство сверяет срок, полномочия контроллера и политику выхода, включает драйвер и сообщает новую версию состояния.

Lux растёт. Например, до 420 лк. Правило не выключает лампу только потому, что стало светло: это ожидаемый эффект собственного действия. Подтверждение можно усилить измерением тока, но рост света от солнца не является надёжным доказательством исправности именно лампы.

Человек вручную выключает свет. Появляется ручное переопределение. Пока оно действует, повторная темнота не должна немедленно включать лампу. Смена владельца состояния видна в журнале и интерфейсе.

В профиле Presence-qualified человек уходит, и VACATING ждёт проверяемое время с учётом новых признаков. Выключение допустимо только после свидетельства ухода и при отсутствии ручного запрета. В PIR-only этого перехода к автоматическому OFF нет. При потере обязательного датчика получается UNKNOWN с уведомлением; отключение по предельному таймеру возможно лишь как заранее согласованная отдельная политика.

Формальная таблица решения#

Решение лучше реализовать как чистую функцию входного состояния и политики, которая выдаёт намерение и объяснение. Исполнение, запись на диск и сеть выполняются отдельно. Так один и тот же журнал можно воспроизвести в симуляторе и убедиться, что новая версия правил не изменила поведение неожиданно.

Две комнаты и два светильника#

При добавлении коридора устройства не получают имена, которые одновременно служат постоянными ID. Физический device_id остаётся неизменным; расположение, человеческие названия и группы меняются отдельно. Основной свет кабинета и подсветка монитора получают разные capabilities и разные alias-наборы.

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

Групповая сцена не атомарна физически. Если одна лампа недоступна, результат содержит успех первой и неопределённость второй. Компенсирующее выключение первой не всегда желаемо: стратегия частичного исполнения задаётся самой сценой.

Проверка температуры как процесса#

Даже без отопительного исполнительного узла можно изучать динамику: открыть дверь, включить вычислительную нагрузку, переместить датчик и сравнить изменения. При этом нельзя смешивать эксперимент по нагреву комнаты с экспериментом по самонагреву измерителя.

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

Небольшой вентилятор внутри комнаты главным образом перемешивает воздух. Он не считается управляемой вентиляцией наружным воздухом. Будущая функция «проветрить» потребует отдельного физического исполнительного механизма и ограничений, а не переименования обычного вентилятора.

Набор испытательных историй#

Записать вход в темноте; вход при дневном свете; неподвижную работу; ручной OFF; уход и быстрый возврат; пропавший датчик; поздний пакет; смену имени светильника; частичный отказ сцены. Прогнать каждую историю через старую и новую версию правил. Расхождение должно объясняться конкретным изменением политики.

Разобранный световой сценарий показывает, как собственное воздействие лампы меняет вход датчика. Модель этого воздействия позволяет проверить поведение контура до добавления нейросети.

Два примера — два разных договора#

Для E0 используются вход в темноту ниже условных 120 лк, ручной режим до явного освобождения и срок нового исполнения до 2 с при пригодной синхронизации. Подтверждение входа 1–2 с и выдержка ухода 120 с — отдельный профиль Presence-qualified. Временный ручной режим 30 минут остаётся возможностью E1 и не является настройкой E0. Числа — цели учебного опыта, не норматив освещения.

Следующий опыт специально использует другие значения: внешний свет 150 лк, вклад лампы около 420 лк, пороги 280/340 лк и минимальную паузу 30 с. Он нужен, чтобы увидеть ошибку обратной связи и сравнить два алгоритма. Его 600 секунд существуют в симуляторе, а не в журнале испытанной станции.

Состав и условия опыта#

Сохраняем первый комплект: вынесенный сенсор света и температуры, узел присутствия, реле с безопасной низковольтной лампой, станция и KMP-приложение. Никаких новых аппаратных закупок ради AI на этом этапе не требуется; исследование можно выполнять на имеющемся ПК.

Пользователь связывает реле с основным светом, а не с абстрактной «розеткой». Приложение показывает размещение датчика и назначение рабочей зоны. Ручная кнопка имеет приоритет. Автоматическая настройка вклада лампы разрешена только в отдельном режиме эксперимента.

Диагностический опыт: лампа влияет на свой датчик#

В комнате 150 лк от внешнего света; лампа добавляет примерно 420 лк в измеряемой точке. Учебное правило включает ниже 280 лк и выключает выше 340 лк. После включения датчик видит около 570 лк, правило выключает свет, затем снова видит 150 лк. Гистерезис сам по себе не устраняет эту обратную связь. Минимальная пауза лишь замедляет повторение.

Правильная модель различает фон и вклад собственного действия:

$$\hat D_t=L_t-\hat G\,u_t.$$

$u_t$ — фактически подтверждённое состояние лампы, а не только желание сервера. Неизвестный выход делает вычитание ненадёжным; оценщик должен это отразить.

Воспроизводимая симуляция#

В архиве находится simulation/room_replay.py. Это исследовательский скрипт на стандартной библиотеке Python, не часть реализации Koobique. Он моделирует 600 секунд, постоянное присутствие, растущий фон с одним затемнением, шум и две политики. Минимальная пауза между переключениями — 30 с в обоих случаях. Измерение предшествует команде; её эффект появляется в следующем отсчёте.

Это результаты синтетического опыта при заданной модели, а не обещанные показатели оборудования. Вторая политика держит лампу дольше и расходует больше энергии в этой модели. Она лучше выполняет заданную световую цель, но не «побеждает по всем метрикам».

Рассмотреть схему

Что происходит при ошибке модели#

Скрипт также меняет оценку вклада лампы. При истинных 420 лк и предположении 320 лк результат ухудшается: 4 переключения и 44 секунды ниже цели. При предположении 470 лк лампа остаётся включённой 599 секунд. Это показывает необходимость проверки коэффициента и учёта неопределённости, а не превосходство любой «модельной» логики.

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

Реальная последовательность проверки#

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

Состояния реле и света не должны сливаться в один зелёный индикатор. Возможны: «команда принята», «выход ON», «световой эффект не подтверждён», «цель достигнута». Если датчик закрыт, повторный ON не является лечением.

Присутствие и ручной режим#

Во время неподвижного чтения отсутствие PIR-событий не должно само по себе запускать выключение. Потеря радара переводит оценку к недостаточным данным. Для нашей учебной лампы согласуем удержание освещения и уведомление; для другого класса нагрузки политика может быть иной.

После ручного OFF пакет освещения получает временное или постоянное ограничение согласно выбору пользователя. Модель предпочтений может предложить изменить профиль, но не снимает ручной запрет автоматически. «Человек часто выключает эту лампу» — основание для вопроса, не для переписывания прав.

Контрольная история ручного OFF#

Состояние до действия: boot B, output_revision 38, manual_revision 7. A с execution_seq 19 включает лампу; ответ теряется. Кнопка выключает её, увеличивает ревизии и включает MANUAL_HOLD. Повтор A возвращает её прошлый результат без GPIO. Новый автоматический B даже с актуальными числами отвергается ручным режимом. Только явное освобождение разрешает пересчитать решение. Именно эта история проверяет пользовательское обещание, которое не покрывается одним сравнением версии.

Числа симуляции 12 → 2 переключения и 167 → 1 секунды дефицита сохранены как учебный опыт. Время ON выросло с 180 до 446 с, примерно в 2,48 раза. При постоянной мощности это рост энергии лампы, а не доказанная экономия. Следующее сравнение проводится против разумного автомата на одинаковых независимых эпизодах, с учётом энергии Hub, ручных исправлений и неопределённости коэффициента.

Расширение проверяет границы модели. Оно не должно автоматически усложнять первый кабинет.

Koobique проектируется так, чтобы новый физический процесс добавлял собственные наблюдения, модель и ограничения, а не требовал переписывать приложение и протокол. Но универсальность не означает одинаковый MCU, транспорт или режим отказа для всего.

Рассмотреть схему

Кабинет: несколько световых групп#

Основной свет, подсветка монитора и рабочая лампа имеют разные имена и роли. Сцена «работа» может включать два канала, но её результат бывает частичным. Приложение показывает, какой канал не подтвердился, а не скрывает это за общим успехом.

Диммирование добавляет диапазон, нелинейность яркости и возможное мерцание. Механическое реле не подходит для PWM. Для низковольтной ленты используется рассчитанный полупроводниковый ключ или готовый драйвер; световой коэффициент измеряется по уровням, а не считается линейным по умолчанию.

Коридор и ночной режим#

Здесь важнее быстрое включение и предсказуемый путь человека. Длительный анализ присутствия может быть лишним. Ночной профиль ограничивает яркость, а ручной режим доступен физически. Выключение при потере датчика не должно внезапно оставлять проход в темноте.

Такой сценарий показывает, почему общими являются механизм policy и capability, но не конкретные таймеры. Модель кабинета с длительным сидением нельзя без изменений перенести на проходную зону.

Мастерская и измерение нагрузки#

Можно наблюдать ток, температуру корпуса оборудования и состояние розетки через безопасные готовые измерительные устройства. Но автоматический запуск инструмента — новый класс риска. Локальная аварийная остановка и аппаратные блокировки не заменяются приложением или speech-моделью.

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

CO₂ и вентиляция#

Добавление SCD41 или другого документированного CO₂-сенсора расширяет модель микроклимата. Он измеряет другую физическую величину, чем температура или условный VOC-индекс. Поддержка калибровки, режимов и размещения изучается отдельно; приложение не должно переименовывать разные показатели в один абстрактный «качество воздуха». [96]

Вентиляционное управление требует знать, что именно делает исполнитель: перемешивает воздух внутри или обеспечивает воздухообмен. Вентилятор на столе не уменьшает CO₂ так же, как приточно-вытяжная система. Это пример полезного физического понимания, которое должно быть явным в модели.

Теплица, протечка и полив#

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

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

Батарейный и носимый узел#

Для носимого устройства BLE может быть рациональнее Wi-Fi. Узел хранит события локально, использует boot_id и sequence, передаёт историю пакетами и не исполняет старые действия как текущие. Телефон становится возможным шлюзом вне дома, но его фоновые ограничения учитываются.

Энергетический бюджет считается по состояниям. При условных 20 мА в течение 2 секунд каждые 60 секунд и 0,02 мА в остальное время средний ток около 0,69 мА. Идеальный ресурс аккумулятора 500 мА·ч — около 30 суток, но потери преобразования, саморазряд, пики и полезная ёмкость уменьшают результат. Это расчётная иллюстрация, не прогноз для ESP32-DevKit.

Проводные устройства#

Для длинного кабеля внутри мастерской можно рассматривать RS-485 или CAN с подходящими трансиверами, топологией и защитой. UART — логический интерфейс MCU, а не синоним RS-485. Собственная семантика Koobique может переноситься через такой адаптер, но нужны адресация, арбитраж/доставка и соответствующий профиль ошибок.

Проводная шина не становится безопасной из-за отсутствия Wi-Fi. Физический доступ, ошибки адресации, ground loop и индустриальные помехи создают другие риски. Изоляция и терминация выбираются по конкретной линии.

Интеграции с внешними платформами#

MQTT, Matter, Home Assistant, OPC UA или ROS-подобные окружения могут подключаться через адаптеры, когда появится реальная задача. Внутренние данные не должны потерять качество, время и права при переводе. Команда из сторонней системы проходит тот же арбитр, а не отдельный обходной путь.

Правило расширения#

Каждая новая возможность обязана ответить на пять вопросов: что измеряется; какой исполнитель доступен; как проверяется результат; что происходит при потере связи; какие ограничения нельзя нарушать. Если ответы отсутствуют, интеграция ещё не готова к постоянной работе.

Масштабируется язык наблюдений и действий. Законы процесса, датчики и допустимый риск не переносятся автоматически.

Температура: сначала динамика, потом регулирование#

Для одной условной тепловой зоны можно начать с модели

$$C\frac{dT}{dt}=\frac{T_{\mathrm{out}}-T}{R}+Q_{\mathrm{int}}+\eta P a.$$

$C$ — эффективная теплоёмкость, $R$ — тепловое сопротивление, $Q_{\mathrm{int}}$ — внутреннее выделение тепла, $Pa$ — управляемый источник. Это приближение, не полная модель кабинета. Без независимых наблюдений некоторые параметры могут быть неразличимы.

Для текущего стенда нет основания считать комнатный вентилятор гарантированным охладителем воздуха: он может менять перемешивание и ощущения, не отводя тепло за пределы помещения. Чтобы модель обещала снижение температуры, нужна реальная связь с теплоотводом или воздухообменом. Вентиляторы самого куба обслуживают вычислитель и не должны становиться «климатическим исполнительным устройством» по сходству названия.

Рассмотреть схему

Присутствие в нескольких зонах#

Следующий сценарий — рабочий стол и проход. Он требует модели пространства: один сигнал не всегда позволяет определить, где находится человек. Можно использовать дополнительные датчики или ограничить обещание системы до общего присутствия. Камера — отдельный сознательный выбор, а не обязательное условие интеллектуальности.

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

Мастерская и наблюдение за оборудованием#

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

Если появляются опасные движущиеся части, критический контур не переносится в Wi-Fi-сервер. Нужны локальные межблокировки, подходящее оборудование и отдельная инженерная оценка. Koobique может собирать данные и давать рекомендации, не выдавая себя за сертифицированную систему безопасности.

Носимые узлы#

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

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

Мультиинсталляция#

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

Модель можно переносить как начальное предположение, но она снова проходит проверку на новом месте. Свежесть, единицы, типы и журнал переносятся хорошо. Коэффициент светильника и профиль присутствия — лишь кандидаты до подтверждения.

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

Расширение определяется риском физического действия#

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

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

Тесты делятся на расчётные, программные, аппаратные и сквозные. Модель подтверждает поведение на заданных предположениях. Unit-тест проверяет функцию. HIL соединяет реальное устройство и управляемый сценарий. Только совместное испытание показывает, что питание, радио, протокол, Core и физический выход работают вместе.

Рассмотреть схему

Измерение задержек#

На клиенте фиксируются начало команды и получение результата по одним монотонным часам. Это даёт полный RTT. На станции отдельно измеряются очередь, проверка, транзакция и передача. На устройстве — время до изменения выхода. Внешний логический анализатор может наблюдать диагностические GPIO обеих сторон, если они доступны в одном безопасном стенде.

Рассмотреть схему

Не следует выдавать RTT за одностороннюю задержку или измерять только быстрые успешные команды. В отчёт входят ошибки, тайм-ауты, p50/p95/p99 и худшие случаи. Выборка должна включать старт, длительную работу, массовое переподключение и конкурентные задачи.

Предлагаемые цели, а не полученные результаты#

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

Матрица отказов#

Для сетевого стенда Linux netem позволяет вводить задержки, потери, дублирование и изменение порядка там, где это применимо к тестируемому пути. Он не заменяет реальный радиоэфир, но делает часть отказов воспроизводимой. [85]

Парсеры, конкурентность и свойства#

Для KQIP нужны fuzz-тесты на длины, вложенность, неизвестные поля и повреждённые кадры. Cargo-fuzz помогает запускать такие испытания. Для небольших конкурентных примитивов Loom позволяет исследовать разные варианты выполнения. Эти инструменты находят классы ошибок, но не являются сертификатом отсутствия уязвимостей. [95][86]

Проверяются последовательности, а не только одиночный set: известный ID не меняет выход после ручного вмешательства; срок запрещает новое действие, но не чтение истории; старый snapshot не заменяет новый; UNKNOWN не равен EMPTY; автоматизация не нарушает ManualOverride. Каждый успешный counterexample превращается в постоянный регрессионный тест.

Электрические измерения#

Сначала измеряются питание и сигналы, затем сетевое поведение. Для реле проверяются стартовый импульс, ток катушки, выброс на ключе и контактная операция. Для I²C — уровни, фронты и ошибки при подключении второго сенсора. Для UART — правильная скорость, framing и реакция на неполный кадр.

Для датчиков сохраняются raw и опорные условия. Для вентиляции — температура комнаты и реальные обороты. Тест с грязным фильтром не должен создавать опасную пылевую среду; используется контролируемое изменение сопротивления под наблюдением.

Реальные пользователи и эксплуатация#

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

Минимальный пакет результата#

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

Полезность управления оценивается по результату в комнате. Качество текста и точность модели измеряются отдельно и связываются с физическим результатом через испытание всего контура.

Три сравнения#

Сначала проверяем отдельный компонент: ошибку температуры, распознавание фразы, качество оценки присутствия. Затем проверяем контур: достижение цели, задержку, число переключений, соблюдение ручного режима. Наконец — эксплуатацию: восстановление, потерю канала, ресурсный пик и перенос размещения.

Для каждого AI-кандидата есть разумный не-AI эталон. Если классификатор выигрывает среднюю точность, но чаще гасит свет при неподвижном человеке, он не проходит допуск по выбранной цене ошибки. Низкая ошибка одношагового прогноза также не гарантирует хорошую длинную траекторию — это различие существенно для идентификации моделей управления. [111]

Матрица обязательных эпизодов#

Рассмотреть схему

Вероятности и покрытие#

Вероятностный прогноз оцениваем и по точности, и по покрытию интервалов. Не проверяем только средний показатель по смеси лёгких и трудных режимов. Отдельно смотрим на перенос, пропуски и смену датчика.

Адаптивные conformal-методы исследуют поддержание покрытия при изменении распределения. [129] Их статистический смысл зависит от постановки и не является гарантией безопасности каждого отдельного физического действия. Для опасного последствия недостаточно поместить рядом с моделью слово «калиброванная».

Ноль ошибок — не нулевой риск#

При условии независимых одинаково распределённых испытаний и нуле ошибок в $n$ попытках односторонняя 95-процентная верхняя граница вероятности ошибки равна $1-0{,}05^{1/n}$. Для $n=300$ это около 0,99%. Это расчётная иллюстрация: соседние секунды одной записи не дают 300 независимых эпизодов.

Поэтому фиксируем объём и разнообразие тестов, а не только красивый процент. Для проекта на раннем этапе важнее открытое описание ещё не испытанных режимов, чем псевдоточная оценка «надёжность 99,999%».

Инструменты испытания#

Начальный симулятор света работает без тяжёлых зависимостей. Для дальнейших тепловых процессов можно изучить FMI для обмена моделями и BOPTEST для сопоставления контроллеров на моделях зданий. [139] [140] Перенос такой симуляции в свой кабинет требует сопоставления измерений и параметров.

Property-based тесты проверяют инварианты контрактов; fuzzing — парсеры и границы ресурсов; повтор журналов — последовательности отказов. Аппаратный стенд добавляет питание, электрические уровни и физическую нагрузку. Назначение этих уровней различается: успешный fuzzing не подтверждает, что реле подключено правильно.

Перед допуском модели проверяют цену ошибок, отказ от решения и устойчивость замкнутого контура. Средний результат benchmark дополняет эти проверки, но не определяет допуск самостоятельно.

Результат, который можно повторить#

К каждому испытанию прикладываются конфигурация, версии, исходные данные, последовательность действий и критерий успеха. Для оборудования добавляются ревизии плат, схема соединений и условия среды; для моделей — хеш артефакта, разбиение эпизодов и способ исполнения.

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

Измерительные границы и стартовые цели#

p99 на тысяче попыток опирается примерно на десять крайних случаев и требует интервала неопределённости, а не только красивой цифры. Ошибки, отмены и тайм-ауты входят в знаменатель. Если не было ни одного ложного действия на 500 независимых негативах, верхняя односторонняя 95% граница всё ещё около 0,6%. Коррелированные записи уменьшают информативность числа опытов.

Точность температуры сравнивается с эталоном известной неопределённости в нескольких установившихся точках; цель ±0,3 °C относится только к согласованному измерению при достаточном эталоне, не к любой точке комнаты. Присутствие проверяется неподвижным сидением 30 минут, помехами и потерей каналов. Для PIR-only ожидаемый результат — отсутствие необоснованного OFF.

Регрессии, без которых E0 не получает исполнительный допуск#

Обязательны: A/потеря ACK/кнопка/повтор; тот же ID с другим телом; повтор после вытеснения кэша; reboot между GPIO и результатом; первая доставка после срока; suspend H0 на 10 минут; UTC ±1 год; новый план при MANUAL_HOLD; поздний ACK после OFF; старый backup после переноса; отзыв при открытой сессии; диск заполнен; AI-worker завис; радар пропал. Каждый опыт сохраняет трассу и итоговое состояние, а не только PASS.

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

Первый заказ должен позволить пройти сквозной низковольтный сценарий на имеющемся ПК. Большой куб, GPU, массив микрофонов и собственные платы не нужны в одной первой корзине. Это не экономия на качестве: последовательная покупка уменьшает число одновременно неизвестных компонентов.

Заказ A — измерительный и исполнительный стенд#

Документация базовых плат и модулей приведена в источниках; внешний вид карточки магазина не заменяет её. Неизвестный модуль с той же микросхемой может иметь иную схему питания и распиновку. [14][16][18][22][25][79]

Заказ B — самостоятельный вычислитель#

Для H1 покупается один мини-ПК после проверки Linux и голоса. Для H2 заказываются Mini-ITX-плата, совместимый CPU, RAM, SSD, кулер и штатный БП. Одновременно покупать H1, Pi и Jetson не требуется: сравнение сначала выполняется по документам и доступным измерениям, затем выбирается одна основа.

Заказ C — механика#

Для рамы 320 мм по описанной стыковке: 4 профиля по 320 мм и 8 по 280 мм, соответствующие соединители, крепёж, ножки и отдельные панели. Длина уже нарезанного профиля проверяется штангенциркулем/угольником; ошибка одного элемента влияет на весь корпус.

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

Заказ D — голос и собственная PCB#

Для голоса сначала используются телефон и Fifine. После сравнения моделей выбирается выносной массив или встроенный модуль. Динамик, усилитель и акустическая камера приобретаются как согласованный комплект, а не просто по максимальной мощности.

Собственная PCB заказывается после успешного паяного прототипа. Для первой партии достаточно нескольких носителей и одной версии схемы. Доставка плат из другого города обычно практичнее, чем ограничивать поиск только Тулой; конкретные услуги подтверждаются у подрядчика. [28][29][30]

Карточка покупки#

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

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

Что можно не покупать сейчас#

Дискретную GPU, собственный RF-модуль на голом чипе, большой микрофонный массив, сетевое реле на 230 В и сложную многослойную плату. Ни одна из этих позиций не нужна, чтобы доказать первый полноценный сценарий Koobique.

До заказа: инвентаризация, затем один точный комплект#

У автора уже есть инструменты, ПК, телефоны и микрофон. Поэтому «заказ 0» — проверка доступности лабораторного БП с ограничением тока, мультиметра, осциллографа/логического анализатора, ESD-защиты и безопасного отключения питания; отсутствующее покупается, имеющееся не дублируется без причины.

Для каждого выбранного модуля сохраняются производитель, точный артикул, ревизия, фото, datasheet, схема breakout и проверенный продавец. Маркетплейс показывает товар, но не доказывает идентичность платы. Запасная C6 нужна до необратимых опытов eFuse; повторяемая сборка E2 потребует дополнительных сенсоров и проверки замен. Бюджеты ревьюеров без актуальной ведомости не выдаются за цену Koobique.

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

Первый экземпляр E0 — открытый лабораторный стенд. E1 — самостоятельная станция в корпусе с теми же логическими контрактами. E2 — повторяемая сборка по документации, выполненная без памяти автора о «секретном проводке». Это не массовое производство, а последовательное снижение инженерной неопределённости.

Этап 0. Подготовка среды#

Создать репозиторий документации, каталог аппаратных ревизий и единый журнал измерений. На имеющемся ПК поднять Linux-окружение, Rust toolchain и симулятор устройств. До подключения реального реле должны работать ID команды, журнал результата и сценарий потери соединения.

Результат этапа — воспроизводимый запуск и сохранённый манифест. Если сборка работает только из незадокументированной домашней директории, переходить к изготовлению корпуса рано.

Этап 1. Один датчик#

Проверить ESP32 без периферии, затем один SHT-модуль. Снять питание, прозвонить, проверить напряжения, прочитать ID/результат и только потом добавить второй сенсор. Для VEML7700 проверить raw и настройки gain/integration, а не сразу график в приложении.

Результат — корректные наблюдения с единицами, возрастом и флагами. Сбой сенсора должен быть виден как сбой, не как нулевое значение. Фотография проводов и таблица соединений сохраняются.

Этап 2. Один исполнитель#

Сначала релейный модуль без нагрузки, затем 12-вольтовая лампа через предохранитель. Проверить кнопку и стартовый уровень. Подключить протокол, повтор команды и потерю подтверждения. Только после этого вводить автоматическое управление.

Результат — set(on/off) с известным состоянием при перезапуске и без опасного импульса. Измеритель тока добавляется как независимое расширение, чтобы можно было сравнить поведение до и после него.

Этап 3. Presence и замкнутый световой сценарий#

В E0 подключить PIR и проверить включение при темноте, состояние UNKNOWN и ручной ManualOverride до явного освобождения. По отсутствию движения автоматический OFF запрещён. Проверить, что собственная лампа не вызывает самопереключение, а следующий вход не снимает ручной запрет. Для расширения E1 добавить радар, собрать размеченные эпизоды и отдельно допустить Presence-qualified: только этот профиль может выключать свет после подтверждённого ухода.

Результат — работающий кабинет на имеющемся ПК. Интернет отключается на время проверки. Это первый полноценный экземпляр экосистемы, даже если корпус станции ещё не изготовлен.

Этап 4. Мобильное управление и подключение#

Для пользовательского управления определить Client API Core и минимальные экраны: инсталляции, добавление, комната, узел, намерение и результат, диагностика. Доверенный локальный bootstrap нужен первому стенду; BLE-onboarding и целевой KMP-клиент Android/iOS развиваются в E1. До их допуска выполнить проверки на реальных телефонах, включая отказ разрешений, прерывание и смену сети. Выбранный интерфейс E0 должен быть прямо указан в манифесте стенда.

Результат — пользователь управляет системой из обычной домашней сети и понимает состояние ошибки. Точный визуальный стиль приложения разрабатывается отдельно по правилам KMP-проекта.

Этап 5. Голос и выбор вычислителя#

Записать RU/EN-корпус и сравнить модели на ПК. Проверить намерения, отрицания и неоднозначные имена. Измерить память и задержку под одновременной нагрузкой Core. По результатам выбрать H1/H2/H3/H4.

Результат — аппаратный выбор с измерительным основанием. Отдельный хаб устанавливается открыто на столе и повторяет прежние тесты до переноса в корпус.

Этап 6. Самостоятельная станция E1 и выбранный корпус#

Для H2 собрать раму, габаритный макет и поддон; установить штатное питание, плату, кулер и вентиляторы. Сначала проверить открытый стенд, затем панели и фильтр. Антенны и микрофон должны оставаться доступными для перенастройки. При выборе готового H1 испытать его в штатном корпусе; изготовление куба в этом случае является отдельной веткой проекта.

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

Этап 7. Обновление и удалённый доступ#

Проверить локальную установку подписанного пакета, отказ подписи и откат. Настроить первый WireGuard-путь и отдельный SSH. Отключить VPS и убедиться, что кабинет остаётся управляемым локально.

Результат — станция обслуживается без разборки, а владелец имеет план восстановления без внешнего сайта. Ключи и backup не хранятся только на одном устройстве.

Этап 8. Второй экземпляр E2#

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

Что является началом изготовления#

Разметка и сверление выполняются по согласованной аппаратной ревизии, а не по иллюстрации из книги. Атлас даёт исходные размеры и расчёты; комплект рабочего выпуска дополняется фактическими CAD, распиновками купленных модулей и результатами стенда.

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

Исследовательская ветка: от наблюдения к допуску модели#

Рассмотреть схему

Что зафиксировать до программирования#

Нужны схемы логических объектов, контракт наблюдения, контракт предложения, таблица ошибок, семантика времени и список инвариантов. В архиве приложены примеры JSON и проверяемая учебная схема; они не объявлены окончательной бинарной спецификацией KQIP.

Для первой модели фиксируем условия сбора, разделение эпизодов и эталон сравнения. Аппаратуру собираем по монтажным картам главы 16 и процедуре первого включения. Исследование модели не требует перепаять рабочий узел ради нового программного названия.

Что сознательно не включать в первый runtime#

Первый runtime сохраняет ограниченный набор полномочий. Обязательный видеопоток, автономный online-RL на исполнительных устройствах, универсальное выполнение shell-команд, распределённый консенсус хабов, обучаемое отключение защит и магазин произвольных плагинов в него не входят. Каждое из этих расширений требует отдельной задачи и проверки риска после базового сценария.

Не требуется и собственное ядро Linux. Собственная часть проекта — физические контракты, модель мира, управление процессами и исполнение. Разработка драйвера оправдана реальным устройством без подходящей поддержки, а не желанием назвать весь стек авторским.

Пять исследовательских гипотез#

Переносимость. Пакет света связывается со второй комнатой без изменения ядра; измеряем число ручных операций и время настройки.

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

Полезное самоизмерение. Активный запрос данных сокращает неопределённые решения при ограниченной дополнительной энергии и трафике.

Независимость от AI. Отказ worker не нарушает сроков базового цикла и не теряет ручное управление.

Понятность. Пользователь по карточке решения верно объясняет, что известно и что ещё не подтверждено. Это отдельная проверка интерфейса, не эстетическая оценка.

Первое практическое занятие#

Не покупать GPU. Запустить прилагаемую симуляцию, изучить CSV и изменить вклад лампы. Затем подготовить сборку сенсорного и релейного узла по монтажным картам главы 16, без опасной нагрузки. Первое программное действие — записать полноценное наблюдение и показать его свежесть. Первое физическое действие — безопасно включить лампу вручную и проверить, какие каналы действительно меняются.

Готовность первого экземпляра подтверждает воспроизводимый цикл наблюдения, решения, ограничения и проверки. На этой основе можно оценить пользу следующего AI-расширения.

Начинаем с измерительного и исполнительного стенда, фиксируем контракты, собираем собственные эпизоды и проверяем эталон. Новая AI-модель получает место в системе только после такого сравнения; красивое название не даёт ей права на физическое действие.

Первый маршрут с условиями остановки#

Одновременно ведётся одна рискованная аппаратная ветка и одна связанная программная проверка; новые ML-эксперименты не блокируют завершение E0. Трудоёмкость фиксируется по фактическим опытам и пересматривается после этапа 1. Из количества глав нельзя вывести достоверные сроки одного автора. Учебная ценность широкого проекта сохраняется, но условия первого успеха остаются узкими.

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

Здесь система рассматривается с позиций аппаратуры, системного ПО, безопасности, акустики, интерфейса и эксплуатации. Выводы описывают инженерную позицию проекта и открытые проверки. Агентное ревью помогает сопоставлять аргументы; лабораторные и аппаратные испытания требуют самостоятельных результатов.

Конфликт 1. Вычислитель и механика#

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

Решение: H0 на имеющемся ПК, затем измерительный выбор автономной основы. Mini-ITX сохраняется как прозрачная конструкция куба, мини-ПК — как быстрый альтернативный экземпляр. Конкретная модель CPU не считается окончательной до RU/ EN-бенчмарка.

Инженерное следствие: размеры корпуса выделены в параметрическую компоновку; реальные сокет, I/O и кабели вынесены в обязательные проверки. Ведомость профиля привязана к явной схеме стыковки.

Незакрытый риск: собственный металлический корпус ещё не проверен физически. Условие перехода — полноразмерный макет, проверка доступа и тепловой стенд.

Конфликт 2. Воздух, пыль и голос#

Выбор состоит в следующем: три вентилятора дают простой запас охлаждения, но усложняют акустику. Reverse-blade соответствует визуальной идее, но не является технической необходимостью.

Решение: двухприточная/одновытяжная схема остаётся исходной, а количество и обороты подтверждаются измерением. CPU сохраняет отдельный кулер. Микрофон сначала выносной; reverse-blade — опция конкретной модели.

Инженерное следствие: нужны рабочая точка вентилятора, оценка сопротивления фильтра, отдельный тракт БП и проверка голоса при длительной нагрузке. Предположение «два на вход автоматически дают положительное давление» не принимается.

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

Конфликт 3. Электроника и физические данные#

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

Решение: Sense и Presence отдельные. У температуры и lux допускаются разные точки даже внутри одной логической комнаты. Первый исполнитель низковольтный и имеет физическую кнопку.

Инженерное следствие: необходимы карта GPIO, расчёт I²C, различие микросхемы и готового модуля, проверка самовозбуждения света и несколько уровней подтверждения действия.

Условие перехода: повторяемые измерения, отсутствие стартового импульса реле и проверка присутствия при неподвижном человеке.

Конфликт 4. ПО, протокол и доверие#

Выбор состоит в следующем: полностью Rust-стек против зрелых компонентов с C/FFI; универсальный собственный транспорт против малого проверяемого профиля.

Решение: собственная предметная логика и протокол на Rust, но Linux, TLS, SQL и ML-runtime не переписываются ради языковой чистоты. Первый KQIP — TCP/TLS 1.3 и ограниченный CBOR. Сопряжение устройств опирается на готовый защищённый механизм, Linux-bootstrap выделен отдельно.

Инженерное следствие: ACCEPTED отделяется от APPLIED; используются outbox, controller_fence, ограничения парсера и проверка реальной TLS-конфигурации ESP-IDF. Восстановление времени не использует trustAll.

Условие перехода: interop Core/MCU/KMP, повторы, fuzz, отзыв и незавершённое сопряжение.

Конфликт 5. Интеграция в обычную жизнь#

Выбор состоит в следующем: максимально автономная собственная Wi-Fi-сеть против удобства пользователя и одного радиомодуля. Полностью бесшовный удалённый доступ против прозрачной первой реализации.

Решение: домашний Wi-Fi — основной путь, Ethernet дополнительный. Отдельная сеть устройств возможна позже без переключения телефона. E0 remote использует WireGuard; встроенный relay/VPN проходит отдельный мобильный gate.

Инженерное следствие: проверяются изоляция клиентов роутером, смена сети, разрешения iOS/Android и раздельные полномочия пользователя и SSH. Удалённая доступность не объявляется гарантированной при любых блокировках.

Условие перехода: второй человек подключает узел, восстанавливает сеть и понимает неопределённый результат команды.

Конфликт 6. Восстановление и повторная сборка#

Выбор состоит в следующем: быстрое обновление вручную против воспроизводимого состояния; простое копирование диска против риска двух контроллеров.

Решение: подпись и штатная процедура установки, A/B для appliance-профиля, совместимые миграции, восстановление с изоляцией старой станции и ротацией полномочий.

Инженерное следствие: backup включает состояние доверия; модель речи рассматривается как версия поведения; изготовление E2 проверяет полноту инструкции, а не только успех автора.

Условие перехода: прерванное обновление, старый архив, заполнение диска и второй экземпляр без скрытых ручных правок.

Принятые решения и условия проверки#

Зафиксированы архитектурные границы, основной сетевой путь, низковольтный первый исполнитель, схема собственного протокола, форма наблюдения и маршрут сборки. Открыты точная compute-конфигурация, окончательная CAD-компоновка, Linux BLE-onboarding E1, встроенный аудиомодуль и численные эксплуатационные показатели. Это конкретные инженерные задачи с проверками, а не скрытые обещания готовности.

Проверим ту же систему со стороны измерений, статистики и управления. Эти вопросы дополняют конструктивные компромиссы: даже исправное железо может принять неверное решение из хороших на вид данных.

1. Измерительная инженерия#

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

Контракт содержит объект, интервал измерения, ревизию размещения, качество, калибровку и явные пробелы. Комнатные сенсоры отделены от корпуса станции. Влияние лампы определяется на конкретной плоскости. Проверка — эпизоды с переносом и внешними помехами.

2. Модели и статистика#

Возражение. Успешный прогноз ошибочно принимается за причинное понимание; соседние отсчёты создают утечку теста; confidence путается с безопасностью.

Разделены наблюдение, оценка, прогноз и действие. Введены эпизодные разбиения, журнал воздействия и проверка области применимости. Jev и JEPA разведены по роли. Перестановка вариантов, новые условия и цена ошибок вошли в тесты.

3. Управление и физическое исполнение#

Возражение. Мягкий штраф может позволить нежелательное действие; старый план перезапишет ручную кнопку; подтверждение прошивки выдаётся за достижение цели.

Раздельные ограничения, ручной режим с собственной ревизией, повторная проверка предусловий и несколько видов результата ограничивают исполнение. Бинарному реле нельзя приписывать возможности непрерывного регулятора. Состояние «исход неизвестен» остаётся частью API.

4. Rust, безопасность и ресурсы#

Возражение. Один асинхронный процесс может зависнуть на native-инференсе; файл модели меняет поведение без смены кода; Rust ошибочно воспринимается как полная защита всех зависимостей.

AI-worker вынесен из быстрого пути. У артефакта есть полный манифест и отдельный допуск. Ограничены IPC, память и предложения. Критические права и секреты не попадают в модель. Cgroups рассматривается как средство управления ресурсами, не доказательство hard real-time.

5. Сквозной сценарий и критика «революционности»#

Возражение. Архитектура может остаться набором громких названий без преимущества перед автоматом. Добавление Jev создаст внешнюю зависимость, а новая камера — лишнюю приватную телеметрию.

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

6. Совместимость и редакционное ревью#

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

Связываем объяснение с проверкой: что измерить, какой результат ожидать, когда остановиться. Схемы различают физические соединения и логические связи; числа симуляции не выдаются за измерения оборудования. Размерные, электрические и программные примеры читаются вместе с их исходными условиями.

Оставшиеся вопросы для стенда Реальные задержки и тепловой режим; качество присутствия в кабинете; допустимые пороги и паузы; эффективность локальной RU/EN-модели; совместимость выбранного ML-backend; точность часов; устойчивость восстановленного управления. Эти пункты не закрываются редактурой документа или аналитическим ревью.

Реестр рисков первого экземпляра#

Это не статистика отказов, а начальная инженерная оценка. Вероятность и влияние: 1 — низкие, 2 — средние, 3 — высокие; произведение служит только порядком работы. Владелец всех действий сейчас — автор проекта в указанной роли. «Проектно решён» не равно «проверен на стенде». Полный реестр, связи с замечаниями и картами находятся в review_r2/risk_register.csv.

Профиль DEV допускает физическую отладку и не защищает секреты от владельца лабораторной платы. APPLIANCE требует отдельной квалификации защиты. Личные эксперименты, передача сборки для совместного теста и выпуск на рынок — разные основания ответственности; книга не является сертификатом электрической, радио- или коммерческой пригодности.

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

Каждая карточка испытания связывает конфигурацию, наблюдение и решение о следующем шаге. Заполненные результаты позволяют воспроизвести проверку и оценить готовность системы.

Единая шапка протокола#

Для любой проверки записываются ID сборки, дата, версии железа и прошивки, схема подключения, используемый источник питания, температура помещения, измерительные приборы и исходное состояние. Итог — PASS, FAIL или INCONCLUSIVE с приложенными данными. «Не удалось воспроизвести» не превращается в PASS.

M-01 · Механика и обслуживание#

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

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

E-01 · Электрика и холодный старт#

Без исполнительной нагрузки выполнить серию включений, reset MCU, входа в загрузчик и потери Wi-Fi. Осциллографом или логическим анализатором наблюдать линию управления; отдельно контролировать фактическое состояние контакта безопасным способом. Отсутствие видимого вспыхивания лампы не доказывает отсутствия короткого импульса.

Затем подключить лампу 12 В, измерить ток, напряжение у узла и нагрев соединений при длительной работе. Проверить ручную кнопку без сервера. Фиксировать не только успешные циклы, но и min/max напряжения и причины reset.

N-01 · Сеть и доверие#

Проверить обычный домашний Wi-Fi, перезапуск роутера, другой адрес DHCP, гостевую сеть с изоляцией и неверный пароль. Приложение должно различать отсутствие сети, отсутствие станции и отказ аутентификации. После замены роутера не теряются ни владелец, ни идентичность устройств.

Отдельно проверить публичный PKI-профиль с неверным сроком, локальный pin-профиль с чужим ключом и неверной подписью, отозванного пользователя и старт без UTC. Проверка trustAll считается провалом. Недоступность VPS не должна останавливать локальный контур. Срок сертификата в pin-профиле не тестируется как скрытая универсальная настройка TLS.

F-01 · Физическая логика#

Использовать истории главы 44. В каждой сохранять исходные наблюдения, вычисленное состояние, активную политику, причину команды и её результат. Проверить, что запоздавшая история не превращается в живой вход, Unknown не равен Empty, а собственная лампа не создаёт цикл ON/OFF.

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

V-01 · Голос RU/EN#

Корпус фраз содержит разные формулировки, отрицания, названия похожих объектов и фоновые разговоры. Для каждого примера есть ожидаемое намерение, объект либо необходимость уточнения. Примеры: «включи основной свет», «освещение включи», «не включай подсветку», «turn on the desk light», «turn off the backlight».

Проверяются выносной микрофон, телефон, несколько расстояний и разные обороты вентиляторов. Отдельно фиксируются неверное действие, неверный объект, отказ распознавания и задержка. Случай, когда текст распознан неточно, но намерение верно, отличается от грамматически красивого текста с опасным действием.

R-01 · Обновление и восстановление#

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

Данные, которыми нельзя рисковать, предварительно выносятся из стенда. Отключение питания выполняется контролируемо, без вскрытия сетевого БП. Тест считается завершённым только после повторной работы физического сценария, а не после появления приглашения SSH.

Краткий словарь#

Что считать первым законченным экземпляром#

Станция и устройства запускаются по сохранённой конфигурации, приложение подключается без переключения повседневной Wi-Fi-сети, световой сценарий работает без интернета, ручная кнопка сохраняет смысл при отказе сервера, а обновление и восстановление не требуют угадывать скрытые действия автора.

Следующий экземпляр повторяется по зафиксированным файлам и монтажным картам. При этом реальные номера деталей, размеры, замеры и результаты заменяют проектные предположения. Именно эта замена, а не увеличение числа страниц документа, превращает исследование в инженерно проверенную систему.

Индекс проверок#

Референсный тест Python в комплекте проверяет выбранную семантику модели, а не реальную сеть, TLS или прошивку. PASS переносится на реализацию только после воспроизведения тех же историй на Core/MCU. Неисполненные аппаратные карты остаются OPEN. Так зелёный тест документа не становится ложным разрешением на постоянную эксплуатацию.

Дополнения к единому словарю#

Учебный материал полезен, когда после него можно объяснить или проверить конкретную часть Koobique.

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

Электрические цепи и измерения#

MIT 6.002, Circuits and Electronics помогает разобраться в законах цепей, транзисторах, динамике и измерении. Практическое упражнение: рассчитать ток лампы, потери в проводе и шунте, затем измерить их. Объяснить, почему порог MOSFET не равен гарантированному открыванию. [68][80]

NXP UM10204 нужен для понимания открытого стока, адресации и временны́ х параметров I²C. Упражнение: найти подтяжки на двух breakout, рассчитать эквивалентное сопротивление и сравнить фронт с осциллограммой. [26]

Datasheets SHT45, VEML7700, INA226 учат отличать диапазон, точность, разрешение и условия измерения. Упражнение: составить одностраничную карточку каждого сенсора с питанием, адресом, задержкой и флагами ошибки. [15][17][79]

Конструкция и материалы#

FreeCAD — основа параметрической модели. Упражнение: сделать раму с параметром внешней грани, затем изменить 320 на 340 мм и проверить, какие размеры должны измениться автоматически, а какие остаются привязаны к реальной плате. [13]

Документация вентиляторов и Prusa помогает отделить геометрию, электрический интерфейс и свойства печати. Упражнение: изготовить купон вставок и кассету фильтра, измерить посадку и сравнить открытый/закрытый корпус. [4][6][11][12]

Механические файлы производителей нужны для посадок. Упражнение: импортировать реальный габарит платы, добавить объёмы штекеров и траекторию извлечения фильтра. Красивый вид модели не считается проверкой обслуживаемости. [3][88]

PCB и embedded Rust#

KiCad Getting Started показывает полный путь от схемы к производственным файлам. Упражнение: маленький носитель датчика с разъёмом, подтяжками, тестовыми точками и собственным footprint, сверенным по чертежу. Перед заказом распечатать 1:1. [27]

The Embedded Rust Book объясняет периферию, владение, прерывания и no_std. The Rust on ESP Book связывает эти идеи с конкретными ESP-инструментами. Упражнение: драйвер сенсора с тайм-аутом и ошибками, затем имитация отсутствующего устройства. [44][31]

ESP-IDF OTA / Secure Boot / Provisioning изучаются до записи необратимых защитных настроек. Упражнение: прервать обновление тестовой платы и восстановиться по документированной процедуре. [35][36][70]

Rust-сервер и протокол#

The Rust Programming Language и Tokio Tutorial дают основу владения и асинхронности. Упражнение: ограниченная очередь событий с измерением возраста и политики переполнения. Объяснить, почему async не делает блокирующую операцию неблокирующей. [43][45][82]

RFC 8949 и документация Rustls нужны для wire-профиля. Упражнение: закодировать один Observation, сравнить байты на хосте и MCU, затем отклонить пакет с повторяющимся ключом и чрезмерной длиной. [48][47]

Rust Fuzz Book и Loom помогают проверять парсеры и небольшие конкурентные участки. Упражнение: сформулировать свойство, которое должно сохраняться при любом порядке событий, прежде чем писать тест. [95][86]

Физические модели и данные#

MIT 6.302, Feedback Systems объясняет обратную связь, устойчивость и динамику. Упражнение: смоделировать комнату первого порядка, добавить задержку датчика и увидеть влияние шага и усиления. Начинать на симуляторе, не на реальном нагревателе. [69]

SQLite WAL / Backup нужны для сохранности, а не только запросов. Упражнение: команда с outbox в одной транзакции, аварийная остановка и продолжение с тем же ID. [51][52][93]

KMP и голос#

Kotlin Multiplatform, UniFFI и платформенные разрешения помогают построить границы приложения. Упражнение: подключиться к локальному тестовому API на Android и iOS, отозвать разрешение и показать пользователю понятный путь восстановления. [54][55][56][57]

whisper.cpp, sherpa-onnx и Vosk изучаются сравнением одного аудиокорпуса. Упражнение: измерить не только текстовую ошибку, но и ошибку объекта, ложное выполнение и задержку после конца фразы. [61][62][99]

Silero, openWakeWord и документация массива изучаются после эталонного микрофона. Упражнение: шум вентилятора, собственный ответ динамика и обычная речь без команды не должны вызывать действие. [63][64][67]

Как вести инженерный дневник#

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

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

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

Маршрут A. Измерить и не обмануть себя#

Изучить: вводный GUM и VIM, SOSA/SSN, Industrial I/O, документацию ADC выбранного микроконтроллера. [100] [101] [105] [141]

Сделать: паспорт одного канала; записать 15 минут наблюдений с пропуском питания; построить бюджет неопределённости без смешения стандартной ошибки и предельного допуска. Отдельно объяснить, что случится после перестановки сенсора.

Маршрут B. Построить малую модель#

Изучить: MIT System Identification и Robust/Stochastic Control; затем do-mpc и OSQP только в объёме своей задачи. [111] [110] [112] [113]

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

Маршрут C. Понять AI без смешения задач#

Изучить: формы решений Jev и опубликованные ограничения; статьи V-JEPA 2/2.1; для дальнейшего исследования — DreamerV3, TD-MPC2, PETS. [115] [118] [121] [122] [124] [125] [126]

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

Маршрут D. Проверить вероятность и перенос#

Изучить: Guo и соавторы о калибровке, адаптивном конформном прогнозировании, работы об информационно-ориентированном выборе действий. [128] [129] [130] [131]

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

Маршрут E. Встроить модель в систему#

Изучить: Tokio и блокирующие операции, cgroups v2, выбранный Rust ML-runtime, TUF и формат тензорных артефактов. [82] [132] [73] [134] [135] [136] [84] [138]

Сделать: описать контракт worker и полный манифест модели; задать лимит памяти; воспроизвести отказ worker, не меняя состояния лампы. Фактическая разработка следует отдельному этапу после согласования контрактов.

Короткий словарь#

Полные названия материалов и ссылки приведены в едином списке источников. Этот маршрут дополняет практические задания по электронике, механике, Linux, KMP и протоколу: сначала воспроизводится небольшой опыт, затем читается документация к тому механизму, который в нём встретился.

Учебный маршрут для закрытия рисков, а не только чтения#

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

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