Человек выключил.
Что дальше?
Проверьте ручной приоритет, устаревшую команду и перезапуск в учебной модели E0.
Выход выключен
Визуализация логического выхода. Физическое включение лампы здесь не измеряется.
Движение может включить свет. В этой модели освещённость ниже порога.
Команда задержалась в сети
Подготовьте автоматическое включение, затем выключите вручную и доставьте старую команду.
Модель готова к проверке.
Молчание датчика
не равно пустой комнате.
PIR замечает движение. Он не доказывает, что человек ушёл, и не различает отсутствие от неподвижной работы за столом. В E0 выключение остаётся ручным, а HOLD снимается явным разрешением.
После перезапуска выход выключен и действует отдельный BOOT_INHIBIT. Это другой источник ограничения, а не новое ручное намерение. Для временного запрета «до следующего входа» нужен квалифицированный профиль присутствия E1.
Прочитать о присутствииОт наблюдения
к проверенному эффекту.
Наблюдение
Датчик сообщает значение, время и условия измерения. Источник, калибровка и размещение остаются рядом с числом.
Identity / Trust · учебная последовательность
Отозвать доступ — дождаться подтверждения
Сессия приложения и право владельца назначать Core — разные полномочия. Здесь показан сценарий, в котором требуется отозвать оба. Остановка одного не подтверждает отзыв другого.
Client API
Доверие узлов · отдельный договор
Этап 1 из 5
Одна установка, разные уровни доступа
Телефон обращается к Client API Core со своей пользовательской сессией. Узлы отдельно доверяют назначенному контроллеру и набору owner/recovery-подписантов. В этом сценарии телефон также содержит отдельное owner-полномочие. Оно не возникает автоматически из права управлять светом.
Отзыв ещё не начат. Номер controller_fence не заменяет поколение owner-доверия.
Client API
Доверие узлов · отдельный договор
Этап 2 из 5
Сессия закрыта; доверие узлов прежнее
После commit отзыва Core закрывает сессию и подписки Client API, отменяет неотправленные действия и проверяет текущие права перед dispatch. Уже отправленная команда не отменяется задним числом. Отдельный owner-ключ всё ещё требует собственного отзыва на каждом узле.
Отзыв клиентской сессии завершён на Core. Отзыв owner-полномочия этим не завершён.
Client API
Доверие узлов · отдельный договор
Этап 3 из 5
Новое намерение отзыва ещё не стало доверием узлов
Отдельное изменение owner-доверия должно быть разрешено действующим owner/recovery-путём. Предположим, такое решение принято: целевой набор больше не допускает старого подписанта. Узел Б недоступен; запись цели в Core не меняет его устойчивое доверие. Узел А ещё не подтвердил применение.
PENDING описывает незавершённый отзыв. Он не доказывает, что узел выключен или не исполнил прошлую команду.
Client API
Доверие узлов · отдельный договор
Этап 4 из 5
Подтверждение относится к конкретному узлу
Узел А должен проверить полномочие на обновление, атомарно сохранить целый новый набор доверия и подтвердить применённую ревизию. Здесь предполагается, что эти условия выполнены для А. Узел Б всё ещё хранит старое доверие; факт доставки или подтверждение соседа не закрывают его PENDING.
Требуемый runtime-тест: А отклоняет новое назначение от старого owner-ключа даже со свежим challenge. В этой иллюстрации криптография не выполняется.
Client API
Доверие узлов · отдельный договор
Этап 5 из 5
Закрыть отзыв можно по свидетельствам применения
После восстановления связи узел Б проходит тот же договор проверки и устойчивого применения. Только подтверждение целевой ревизии от каждого узла позволяет отметить отзыв этого owner-полномочия завершённым в выбранной установке. Остальные сессии, результаты команд и физические состояния ведутся отдельно.
Завершён именно отзыв authority. UNKNOWN результата команды остаётся неизвестным исходом, а не OFF; прошлое действие не отменено подтверждением доверия.
Учебная последовательность. Ревизии 7 и 8 условны и не являются новыми полями KQIP. Формат OwnerSetUpdate, транспорт доставки и правила авторизации обновления доверия остаются открытым контрактом.