Главная → Академия → COURSE-16: Основы Интернета Вещей и практическое применение → Анализ и проектирование базовых IoT-сценариев

Анализ и проектирование базовых IoT-сценариев

Урок 8 · COURSE-16: Основы Интернета Вещей и практическое применение · theory

COURSE-16-M03-LAB02 — Анализ и проектирование базовых IoT-сценариев

Введение

Данная лабораторная работа является практическим заданием для оценки базовых знаний, полученных в Модуле 3 «Работа с данными в IoT». Цель работы — проверить ваше умение применять теоретические концепции на практике, используя стандарты и подходы, принятые в Академии HI. Вы должны продемонстрировать навыки проектирования потоков данных, применения паттернов Node-RED и декомпозиции задач автоматизации на примере контроллера HI.

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

Предварительные требования

Необходимое окружение

---

Задание 1. Формирование контракта сообщения для сенсоров

Контекст: На объекте установлены три типа датчиков, подключенных к универсальным входам (UI) и шинам данных контроллера HI. Ваша задача — определить стандартный формат сообщения (`msg.payload`), который будет использоваться для передачи их показаний в систему по протоколу MQTT, следуя паттерну «Контракт сообщения». Задача: Для каждого типа сенсора из таблицы ниже создайте корректный JSON-объект `msg.payload`, соответствующий стандарту Академии HI.

| Тип сенсора | Пример ID источника (`source`) | Назначение |

| :--- | :--- | :--- |

| Датчик температуры | `temp-sens-room-01` | Измерение температуры воздуха |

| Датчик влажности | `hum-sens-room-01` | Измерение относительной влажности |

| Датчик освещенности | `light-sens-outdoor-main` | Измерение уровня освещенности |

Формат ответа: Предоставьте три блока кода с JSON-объектами для каждого сенсора. Используйте реалистичные значения и единицы измерения. Временную метку `ts` можно оставить в виде `1678886400000`. Критерии оценки:

---

Задание 2. Анализ состояния устройств по данным Node-RED

Контекст: В интерфейсе Node-RED вы наблюдаете за потоком, который опрашивает три Modbus-устройства. Узлы `Modbus-Getter` отображают свой статус, как показано в таблице, в соответствии с паттерном «Визуальный статус». Задача: Заполните таблицу, описав предполагаемый статус каждого устройства и наиболее вероятную техническую причину такого состояния.

| Визуальный статус узла в Node-RED | Устройство | Статус (опишите словами) | Вероятная причина |

| :--- | :--- | :--- | :--- |

| `fill:"green", shape:"dot", text:"OK: 22.5 °C"` | Устройство 1 (Датчик температуры) | | |

| `fill:"red", shape:"ring", text:"Error: Timeout"` | Устройство 2 (Счетчик электроэнергии) | | |

| `fill:"yellow", shape:"ring", text:"Connecting..."` | Устройство 3 (Релейный модуль) | | |

Формат ответа: Скопируйте таблицу и заполните пустые ячейки.

💡 Совет: Вспомните паттерн «Визуальный статус» и жизненный цикл узлов, работающих с внешним оборудованием. Ошибка `Timeout` часто связана с физическими проблемами.

Критерии оценки:

---

Задание 3. Проектирование архитектуры потока данных

Контекст: Классическое определение Интернета вещей гласит: «Интернет вещей (IoT) — это концепция, согласно которой физические объекты могут взаимодействовать друг с другом и передавать данные через сеть». Задача: Заполните пропуски в приведенной ниже ASCII-схеме, которая иллюстрирует это определение на примере экосистемы HI. Вместо пропусков `[ _______ ]` подставьте названия протоколов, интерфейсов или компонентов системы. 
// Схема потока данных от датчика до облачного сервиса


(SENS:Temp:DS18B20) <---[ 1-Wire ]--- [CTRL:HI-Core] ---[ _______ ]---> (MQTT Broker) ---[ _______ ]---> [Cloud Platform]


      |                                     |


      |                                     |

  <---[ _______ ]--- [CTRL:HI-Core]
Формат ответа: Перерисуйте ASCII-схему, заполнив все три пропуска. Критерии оценки:

---

Задание 4. Проектирование потока Node-RED для сценария «Я пришел домой»

Контекст: Одним из самых популярных сценариев в умном доме является «Я пришел домой». Он автоматически активирует различные системы при возвращении владельца. Задача: Спроектируйте поток Node-RED для реализации этого сценария. Условия:
  • Триггер (событие): Сценарий запускается при одновременном выполнении двух условий в течение 1 минуты:

    • * Открытие входной двери (сигнал с геркона на универсальном входе `UI-05`).

    * Появление смартфона владельца в локальной Wi-Fi сети (определяется по пингу IP-адреса `192.168.1.100`).

  • Действия:

    • * Включить свет в прихожей (реле `RL-01`).

    * Отправить команду на Modbus-термостат (Slave ID=15) для установки уставки температуры 22°C (запись значения `220` в Holding Register `40001`).

    Требуемый результат:
  • Нарисуйте ASCII-схему потока Node-RED. Используйте узлы `Inject`, `Ping`, `rpi gpio in`, `Function`, `Modbus-Write`, `rpi gpio out`.
  • Опишите логику ключевого узла `Function`, который анализирует триггеры и принимает решение о запуске сценария.
  • Опишите контракты сообщений для команд управления светом и термостатом.
    • Критерии оценки:

    ---

    Задание 5. Реализация паттерна «Обработка ошибок»

    Контекст: В системе используется поток для опроса счетчика электроэнергии по Modbus. Необходимо гарантировать, что любая ошибка связи (например, `Timeout`) будет перехвачена, стандартизирована и подготовлена для записи в системный журнал. Задача: Спроектируйте фрагмент потока Node-RED, который реализует паттерн «Обработка ошибок». Условия:
  • Используйте узел `Catch`, настроенный на перехват ошибок от узла `Modbus-Read`.
  • Ошибка должна быть обработана в узле `Function` и преобразована в JSON-объект следующего формата для последующей записи в MySQL:

    •     {
    

            "level": "error",
    

            "message": "Modbus communication failure",
    

            "details": "Error: Timed out",
    

            "source_node_id": "...",
    

            "source_node_name": "...",
    

            "ts": 1678886400000
    

        }

    Требуемый результат:
  • Нарисуйте ASCII-схему потока, включающую `Modbus-Read`, `Catch` и `Function`.
  • Напишите код для узла `Function`, который формирует указанный JSON-объект из данных, предоставляемых узлом `Catch` (объект `msg.error`).
    • Критерии оценки:

    ---

    Задание 6. Проектирование переиспользуемого компонента (Subflow)

    Контекст: Логика валидации и форматирования показаний датчика температуры повторяется в нескольких потоках. Чтобы следовать принципу DRY (Don't Repeat Yourself), эту логику необходимо вынести в субпоток (Subflow). Задача: Спроектируйте субпоток `Validate & Format Temperature`. Условия:
  • Вход: Субпоток принимает на вход `msg` с сырым значением температуры в `msg.payload` (например, `25.1`).
  • Логика:

    • * Проверяет, что значение является числом и находится в допустимом диапазоне от -55 до +125 °C.

    * Если валидация пройдена, формирует на первом выходе `msg` с `payload` в формате «Контракта сообщения» (см. Задание 1).

    * Если валидация не пройдена, формирует на втором выходе `msg` с информацией об ошибке.

  • Переменные окружения: Субпоток должен использовать переменную окружения `SENSOR_ID` для подстановки в поле `source` в исходящем сообщении.
    • Требуемый результат:
  • Опишите свойства субпотока: количество входов/выходов, переменные окружения.
  • Нарисуйте ASCII-схему внутренней логики субпотока (например, с узлами `Switch` и `Change` или одним `Function`).
  • Напишите код для узла `Function` (если используется), который реализует логику валидации и ветвления.
    • Критерии оценки:

    ---

    Задание 7. Проектирование конечного автомата (FSM) для управления климатом

    Контекст: Необходимо спроектировать логику управления кондиционером, который может работать в нескольких режимах. Использование паттерна «Конечный автомат» (FSM) позволяет избежать путаницы и создать надежную систему. Задача: Спроектируйте FSM для управления климатом. Условия:
  • Состояния: `Off`, `Cooling`, `Heating`.
  • Переменные:

    • * `flow.climate_state` — текущее состояние (хранится в контексте потока).

    * `flow.setpoint` — уставка температуры (например, 22°C).

    * `msg.payload.value` — текущая температура от датчика.

  • Правила переходов:

    • * Из `Off` в `Cooling`, если `температура > уставка + 1`.

    * Из `Off` в `Heating`, если `температура < уставка - 1`.

    * Из `Cooling` в `Off`, если `температура < уставка`.

    * Из `Heating` в `Off`, если `температура > уставка`.

    Требуемый результат:
  • Нарисуйте диаграмму состояний, показывающую состояния и условия переходов между ними.
  • Нарисуйте ASCII-схему потока Node-RED, который реализует этот FSM. Используйте узел `Switch` для проверки текущего состояния `flow.climate_state` и последующие узлы для проверки условий перехода.
  • Опишите, как узел `Change` используется для изменения состояния (например, `set flow.climate_state to "Cooling"`).
    • Критерии оценки:

    ---

    Формат сдачи работы

    Подготовьте один документ в формате Markdown (`.md`), содержащий последовательные ответы на все семь заданий. Для каждого задания предоставьте требуемые артефакты: блоки кода, таблицы, ASCII-схемы.

    Рубрика оценивания

    | Задание | Макс. баллов | Ключевые критерии |

    | :--- | :--- | :--- |

    | Задание 1 | 12 | Соответствие JSON-объектов стандарту «Контракт сообщения». |

    | Задание 2 | 12 | Корректная интерпретация статусов и техническая логика причин. |

    | Задание 3 | 9 | Правильное заполнение архитектурной схемы компонентами стека HI. |

    | Задание 4 | 12 | Логичность потока, корректность логики принятия решения. |

    | Задание 5 | 12 | Правильное применение паттерна «Обработка ошибок», корректность кода. |

    | Задание 6 | 12 | Корректное проектирование субпотока, реализация валидации. |

    | Задание 7 | 12 | Полнота диаграммы состояний, правильная реализация FSM в Node-RED. |

    | Итого | 81 | |

    📋 Мини-runbook «Если не получается»