Один день в кабинете

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

Условия опыта#

В комнате установлены 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, ручных исправлений и неопределённости коэффициента.