Базовая диагностика и конфигурирование IoT-системы

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

COURSE-16-M02-LAB01 — Базовая диагностика и конфигурирование IoT-системы

Введение

Данная лабораторная работа является практическим заданием для проверки базовых знаний, полученных в Модуле 2 «Технологии и протоколы». Вам предстоит выступить в роли младшего инженера по автоматизации, которому необходимо провести первичный аудит и диагностику системы «Умный офис» на базе контроллера HI.

Сценарий: На объекте завершен первичный монтаж оборудования. Система запущена, и данные с датчиков поступают на контроллер. Ваша задача — подключиться к интерфейсу Node-RED контроллера, проанализировать поступающие данные, проверить базовую логику и подготовить краткий отчет для старшего инженера.

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

Завершен Модуль 1 «Введение в IoT» и Модуль 2 «Технологии и протоколы».
Наличие доступа к веб-интерфейсу Node-RED на учебном стенде или виртуальной машине.
Понимание базовых принципов работы узлов `Inject`, `Debug`, `Function` и `mqtt in`.
Знание стандарта «Контракт сообщения» Академии HI.
Установленная палитра `node-red-contrib-modbus` в Node-RED.

Оборудование и окружение

Контроллер HI (виртуализированный) с доступом по сети (IP-адрес будет предоставлен).
Предустановленный поток Node-RED: `FLOW-FOUNDATION-AUDIT-001`.
Эмулированные устройства:

* Два датчика температуры (DS18B20), подключенные к универсальным входам `UI-01` и `UI-02`.

* Умный термостат, управляемый по MQTT.

* Умная лампочка, управляемая по MQTT.

* Умная камера, отправляющая статус по MQTT.

* Эмулированный Modbus-счетчик электроэнергии (Slave ID 1, Input Register 0, значение в Wh).

---

Задание

Выполните следующие задачи, документируя свои ответы и выводы.

Задача 1: Идентификация устройств в системе

Проанализируйте предоставленный поток `FLOW-FOUNDATION-AUDIT-001` в Node-RED. В потоке присутствуют узлы `mqtt in`, которые принимают данные от различных устройств. Сопоставьте топики MQTT с их функциональным назначением в системе.

Заполните таблицу:

| MQTT Топик | Идентификатор устройства | Функция в системе |

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

| `telemetry/office/thermostat/status` | `THERMO-01` | Статус термостата (например, текущая температура, режим работы) |

| `telemetry/office/camera-hall/status` | `CAM-HALL-01` | Статус камеры (например, онлайн/офлайн, обнаружение движения) |

| `telemetry/office/light-main/state` | `LIGHT-MAIN-01` | Текущее состояние основного освещения (вкл/выкл) |

📋 Чеклист выполнения:

Открыт поток `FLOW-FOUNDATION-AUDIT-001`.
Найдены все узлы `mqtt in`.
Проанализированы их топики.
Таблица заполнена корректно.

Задача 2: Анализ телеметрии с датчиков

Активируйте узлы `Debug`, подключенные к выходам эмуляторов датчиков `Датчик 1 (UI-01)` и `Датчик 2 (UI-02)`. В течение 2-3 минут наблюдайте за поступающими сообщениями в панели отладки. Каждое сообщение соответствует стандарту «Контракт сообщения».

Пример контракта сообщения от датчика:

{
    "value": 22.5,
    "source": "28-01234567abcd",
    "ts": 1678886400000,
    "unit": "°C"
}

Проанализировав полученные данные, заполните следующую отчетную таблицу.

| Датчик | Среднее значение (°C) | Максимальное значение (°C) |

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

| Датчик 1 (UI-01) | Заполнить после наблюдения | Заполнить после наблюдения |

| Датчик 2 (UI-02) | Заполнить после наблюдения | Заполнить после наблюдения |

💡 Совет: Для определения среднего и максимального значения можно использовать узел `Function` с сохранением значений в `flow context` или просто визуально оценить данные в `Debug` панели.

📋 Чеклист выполнения:

Узлы `Debug` активированы.
Наблюдение за данными проведено в течение 2-3 минут.
Таблица заполнена с учетом наблюдаемых значений.
Данные соответствуют формату контракта сообщения.

Задача 3: Формулировка определения для отчета

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

> Интернет вещей (IoT) — это [Пропуск 1: сеть] физических устройств, которая [Пропуск 2: оснащает] эти устройства датчиками и исполнительными механизмами и [Пропуск 3: позволяет] их для обмена данными и управления через интернет.

📋 Чеклист выполнения:

Все пропуски заполнены корректно согласно терминологии Академии HI.

Задача 4: Применение IoT для потенциального заказчика

Один из потенциальных заказчиков — небольшой медицинский центр. Он заинтересовался возможностями платформы HI. Опираясь на известные вам возможности контроллера (датчики 1-Wire, Modbus, MQTT-оповещения), предложите один конкретный сценарий применения IoT для нужд здравоохранения.

Объем: 50–100 слов.
Ключевые слова для использования: контроллер HI, датчик температуры, MQTT, безопасность, мониторинг.

Пример сценария:

Для медицинского центра контроллер HI может обеспечить мониторинг температурного режима в холодильниках с медикаментами и вакцинами. Используя датчики температуры 1-Wire, подключенные к универсальным входам, система будет непрерывно отслеживать критически важные параметры. При выходе температуры за допустимые пределы, контроллер HI немедленно отправит MQTT-оповещение ответственному персоналу (например, на мобильный телефон или в систему диспетчеризации), обеспечивая безопасность хранения препаратов и предотвращая их порчу. Это гарантирует соблюдение регуляторных требований и сохранность дорогостоящих материалов.

📋 Чеклист выполнения:

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

Задача 5: Расчет нагрузки на канал связи

Представьте, что на объекте планируется установка 10 новых Modbus-счетчиков электроэнергии. Каждый счетчик будет опрашиваться раз в минуту. Размер одного пакета данных (запрос + ответ) составляет примерно 500 байт.

Рассчитайте, какой объем данных (в килобайтах) будет сгенерирован этими 10 датчиками за один час. Является ли такой трафик критичным для резервного GSM-канала с месячным лимитом 500 МБ? Ответ обоснуйте.

Расчет:

Объем данных от одного счетчика за минуту: 500 байт.

Объем данных от одного счетчика за час: 500 байт/мин * 60 мин/час = 30 000 байт/час.

Объем данных от 10 счетчиков за час: 30 000 байт/час * 10 счетчиков = 300 000 байт/час.

Объем данных от 10 счетчиков за час в килобайтах: 300 000 байт / 1024 байт/КБ ≈ 292.97 КБ/час.

Вывод:

За один час 10 Modbus-счетчиков сгенерируют примерно 293 КБ данных.

Оценка критичности для GSM-канала: Месячный лимит GSM-канала: 500 МБ = 500 1024 КБ = 512 000 КБ. Количество часов в месяце: 24 часа/день 30 дней/месяц = 720 часов. Максимальный трафик за месяц при текущей нагрузке: 293 КБ/час 720 часов/месяц ≈ 210 960 КБ/месяц ≈ 206 МБ/месяц.

Такой трафик не является критичным для резервного GSM-канала с лимитом 500 МБ. Объем данных (около 206 МБ в месяц) составляет менее половины доступного лимита. Однако, следует учитывать, что это только данные от Modbus-счетчиков. Дополнительный трафик могут генерировать другие устройства, системные логи, обновления ПО и т.д. Поэтому, хотя текущая нагрузка не критична, при расширении системы необходимо будет пересчитать общий объем трафика.

📋 Чеклист выполнения:

Расчеты выполнены корректно.
Объем данных за час указан в килобайтах.
Оценка критичности для GSM-канала дана и обоснована.
Учтены потенциальные дополнительные источники трафика.

Задача 6: Перспективы развития системы «Умный дом»

Подготовьте для коммерческого предложения раздел «Перспективы развития системы». Опишите, как, по вашему мнению, можно будет расширить функционал умного дома на базе контроллера HI в ближайшие 5-10 лет. Упомяните как минимум два протокола или технологии из стека HI (например, DALI, CAN, LoRaWAN).

Перспективы развития системы «Умный дом» на базе контроллера HI

Система «Умный дом» на базе контроллера HI обладает значительным потенциалом для расширения функционала в ближайшие 5-10 лет, адаптируясь к новым потребностям и технологиям.

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

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

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

Голосовое управление и ИИ-ассистенты: Интеграция с популярными голосовыми помощниками для интуитивного управления функциями дома.

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

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

📋 Чеклист выполнения:

Описаны перспективы развития на 5-10 лет.
Упомянуты как минимум два протокола/технологии из стека HI (LoRaWAN, DALI).
Объем текста соответствует требованиям.
Предложения реалистичны и применимы к контроллеру HI.

Задача 7: Разработка мини-проекта по обработке данных и логированию

Вам необходимо создать новый поток в Node-RED, который будет выполнять следующие функции:

Чтение данных: Периодически (каждые 10 секунд) опрашивать эмулированный Modbus-счетчик электроэнергии (Slave ID 1, Input Register 0).

Валидация и форматирование: Полученные данные должны быть валидированы (например, значение не может быть отрицательным) и преобразованы в стандартный "Контракт сообщения" Академии HI.

* `msg.payload.value`: значение в Wh.

* `msg.payload.unit`: "Wh".

* `msg.payload.source`: "modbus-meter-main".

* `msg.payload.ts`: текущая временная метка.

Логирование: Каждое успешно обработанное сообщение должно быть записано в `audit_log` таблицу в базе данных MySQL.

* Используйте узел `mysql` для записи.

* Структура таблицы `audit_log`: `id INT AUTO_INCREMENT PRIMARY KEY, timestamp DATETIME, source VARCHAR(255), value DECIMAL(10,2), unit VARCHAR(50), message TEXT`.

* Записывайте `timestamp`, `source`, `value`, `unit`. Поле `message` оставьте пустым для успешных операций.

Обработка ошибок: Если Modbus-счетчик не отвечает или данные некорректны, ошибка должна быть перехвачена узлом `Catch`. Сообщение об ошибке должно быть отформатировано и также записано в `audit_log` таблицу, но с указанием `message` (например, "Modbus timeout" или "Invalid value").

Визуальный статус: Узел Modbus-чтения должен отображать свой текущий статус (например, "Reading..." или "Error: Timeout").

Шаги выполнения:

Создайте новую вкладку (flow) в Node-RED. Назовите ее `COURSE-16-M02-LAB01-TASK7`.

Настройте Modbus-Client:

* Добавьте узел `modbus-client` (если его нет).

* Тип: `TCP`.

* IP-адрес: `127.0.0.1` (или IP-адрес вашего контроллера).

* Порт: `502`.

* Название: `Modbus Meter Client`.

Настройте MySQL-Client:

* Добавьте узел `mysql` (если его нет).

* Тип: `MySQL`.

* Хост: `127.0.0.1`.

* Порт: `3306`.

* Пользователь: `root`.

* Пароль: `password` (или тот, что предоставлен).

* База данных: `nodered`.

* Название: `Node-RED DB`.

* Предварительно создайте таблицу `audit_log` в базе данных `nodered`:

        CREATE TABLE IF NOT EXISTS audit_log (
            id INT AUTO_INCREMENT PRIMARY KEY,
            timestamp DATETIME,
            source VARCHAR(255),
            value DECIMAL(10,2),
            unit VARCHAR(50),
            message TEXT
        );

Соберите поток согласно следующей ASCII-схеме:

// COURSE-16-M02-LAB01-TASK7: Modbus Meter Data Processing

[Inject: 10s] --> [Modbus-Getter: Meter] --> [Function: Format/Validate] --> [Function: Log Success] --> [MySQL: Insert Log]
                                   |                                |
                                   +----(Error)---------------------+
                                                                    |
                                                                    v
                                                                 [Catch: All] --> [Function: Log Error] --> [MySQL: Insert Log]

Конфигурация узлов:

`Inject`:

* `Payload`: `timestamp`

* `Repeat`: `interval` every `10` seconds.

* `Name`: `Poll Meter (10s)`

`Modbus-Getter`:

* `Server`: `Modbus Meter Client` (выберите созданный).

* `Name`: `Read Energy Meter`

* `Unit-ID`: `1`

* `FC`: `FC 4: Read Input Registers`

* `Address`: `0`

* `Quantity`: `1`

* Визуальный статус: Убедитесь, что узел отображает статус.

`Function: Format/Validate`:

* Код:

        // Паттерн "Контракт сообщения" и "Обработка ошибок"
        // Входящее сообщение от Modbus-Getter: msg.payload = { data: [value], buffer: ... }

        if (msg.payload && Array.isArray(msg.payload.data) && msg.payload.data.length > 0) {
            let rawValue = msg.payload.data[0];

            // Валидация: значение не может быть отрицательным
            if (rawValue < 0) {
                node.status({fill:"red", shape:"dot", text:"Invalid negative value: " + rawValue});
                node.error("Modbus meter returned negative value: " + rawValue, msg);
                return null; // Отправляем null, чтобы Catch узел перехватил ошибку
            }

            // Формируем исходящее сообщение по контракту
            msg.payload = {
                value: rawValue,
                unit: "Wh",
                source: "modbus-meter-main",
                ts: Date.now()
            };

            node.status({fill:"green", shape:"dot", text:"OK: " + rawValue + " Wh"});
            return msg;
        } else {
            node.status({fill:"red", shape:"dot", text:"No data from Modbus"});
            node.error("Modbus meter returned no data or invalid format", msg);
            return null;
        }

`Function: Log Success`:

* Код:

        // Формируем SQL-запрос для успешного логирования
        // msg.payload = { value: ..., unit: ..., source: ..., ts: ... }

        let timestamp = new Date(msg.payload.ts).toISOString().slice(0, 19).replace('T', ' ');
        msg.topic = `INSERT INTO audit_log (timestamp, source, value, unit, message) VALUES ('${timestamp}', '${msg.payload.source}', ${msg.payload.value}, '${msg.payload.unit}', '');`;
        return msg;

`Catch: All`:

* `Catch messages from`: `all nodes on this flow`.

* `Name`: `Catch All Errors`

`Function: Log Error`:

* Код:

        // Формируем SQL-запрос для логирования ошибки
        // msg.error содержит информацию об ошибке

        let timestamp = new Date().toISOString().slice(0, 19).replace('T', ' ');
        let source = msg.error.source.id || "unknown";
        let errorMessage = msg.error.message || "Unknown error";

        // Экранируем кавычки в сообщении об ошибке для SQL
        errorMessage = errorMessage.replace(/'/g, "''");

        msg.topic = `INSERT INTO audit_log (timestamp, source, value, unit, message) VALUES ('${timestamp}', '${source}', NULL, NULL, '${errorMessage}');`;
        return msg;

`MySQL: Insert Log`:

* `Connection`: `Node-RED DB` (выберите созданный).

* `Name`: `Insert into audit_log`

Проверка:

Разверните поток (`Deploy`).

Откройте панель `Debug` и наблюдайте за сообщениями.

Проверьте таблицу `audit_log` в MySQL (например, через `phpMyAdmin` или консоль) на предмет появления записей об успешных чтениях.

Инициируйте ошибку (например, временно отключите Modbus-Client или измените IP-адрес на неверный) и убедитесь, что ошибки логируются в `audit_log` с соответствующим сообщением.

📋 Чеклист выполнения:

Создана новая вкладка `COURSE-16-M02-LAB01-TASK7`.
Настроены Modbus-Client и MySQL-Client.
Таблица `audit_log` создана в базе данных.
Поток собран согласно ASCII-схеме.
Узел `Inject` настроен на 10-секундный интервал.
Узел `Modbus-Getter` настроен на Modbus-счетчик.
Узел `Function: Format/Validate` корректно валидирует и форматирует данные по контракту.
Узел `Function: Log Success` формирует SQL-запрос для успешных операций.
Узел `Catch: All` перехватывает ошибки.
Узел `Function: Log Error` формирует SQL-запрос для ошибок.
Узел `MySQL: Insert Log` используется для записи в БД.
Узел `Modbus-Getter` отображает визуальный статус.
Проведена проверка логирования успешных операций и ошибок в MySQL.

---

Тест по модулю COURSE-16-M02-QUIZ

Какой протокол используется для связи между контроллером HI и датчиками температуры DS18B20?

a) Modbus TCP

b) MQTT

c) 1-Wire

d) RS-485

Что является основным назначением `msg.topic` в стандарте "Контракт сообщения" Академии HI?

a) Хранение основного значения данных

b) Идентификация источника сообщения

c) Маршрутизация и фильтрация сообщений

d) Указание единицы измерения

Какое из следующих утверждений верно для Modbus RTU по шине RS-485?

a) Использует IP-адреса для идентификации устройств.

b) Требует терминирующих резисторов на концах шины.

c) Передает данные по Ethernet.

d) Каждое устройство может иметь одинаковый Slave ID.

Какой узел Node-RED используется для перехвата ошибок в потоке?

a) `Debug`

b) `Switch`

c) `Catch`

d) `Status`

Если в документации Modbus-устройства указан Holding Register `40005`, какой адрес следует указать в узле `Modbus-Getter` Node-RED?

a) 40005

b) 40004

c) 5

d) 4

Что такое `msg.payload` в Node-RED согласно стандарту "Контракт сообщения"?

a) Произвольная строка

b) Стандартизированный JSON-объект с `value`, `source`, `ts` и `unit`

c) Только числовое значение

d) Имя узла-отправителя

Для чего используется цветовое кодирование проводников в соответствии со стандартами Академии HI?

a) Для красоты

b) Для увеличения стоимости монтажа

c) Для упрощения визуальной идентификации цепей и минимизации ошибок

d) Для защиты от электромагнитных помех

Какой тип данных в Modbus используется для чтения/записи однобитных значений (например, состояние реле)?

a) Input Registers

b) Holding Registers

c) Coils

d) Discrete Inputs

Какое из следующих действий является обязательным при подключении экрана кабеля (Shield) для RS-485?

a) Подключать к GND с обеих сторон кабеля.

b) Подключать к GND только со стороны контроллера.

c) Подключать к +5V для усиления сигнала.

d) Не подключать вообще.

Что является основной целью использования субпотоков (Subflow) в Node-RED?

a) Увеличить сложность потоков.

b) Уменьшить дублирование кода и упростить поддержку.

c) Скрыть логику от других инженеров.

d) Ускорить выполнение потоков.

---

Мини-runbook "Если не работает"

Проблема: Node-RED не может подключиться к Modbus-устройству (ошибки "timeout", "connection refused"). Диагностика и решение:

Проверьте физическое подключение:

* Modbus RTU (RS-485):

* Убедитесь, что провода A и B подключены корректно (A к A, B к B). Попробуйте поменять их местами на контроллере.

* Проверьте наличие терминирующих резисторов 120 Ом на обоих концах шины.

* Убедитесь, что все устройства на шине запитаны.

* Проверьте целостность кабеля.

* Modbus TCP:

* Убедитесь, что IP-адрес и порт в конфигурации `modbus-client` узла Node-RED указаны верно.

* Проверьте сетевое подключение контроллера и Modbus-устройства (пингуется ли устройство?).

* Убедитесь, что нет блокировки портов файрволом на контроллере или в сети.

Проверьте параметры Modbus-связи (для RTU):

Скорость (Baud Rate), четность (Parity), биты данных (Data Bits), стоповые биты (Stop Bits) должны точно* совпадать на контроллере и Modbus-устройстве. Это самая частая причина проблем. Проверьте документацию устройства.

Проверьте Slave ID (Unit ID):

* Убедитесь, что `Unit-ID` в узле `Modbus-Getter` (или `Modbus-Write`) соответствует физическому адресу устройства.

Проверьте карту регистров:

* Убедитесь, что `FC` (Function Code), `Address` и `Quantity` в узле `Modbus-Getter` соответствуют документации устройства. Помните про ошибку "off-by-one" (адрес в Node-RED часто на 1 меньше, чем номер регистра в документации).

Используйте `Debug` и `Status` узлы:

* Подключите `Debug` к выходу `Modbus-Getter` (даже к выходу ошибки) для просмотра сообщений.

* Наблюдайте за статусом `modbus-client` узла в Node-RED. Он покажет "connected" или "error".

Проверьте логи контроллера:

* Иногда полезно посмотреть системные логи контроллера (например, `dmesg` или `journalctl -u nodered`) для выявления проблем с COM-портами или сетевыми интерфейсами.

Изолируйте проблему:

* Если на шине несколько устройств, попробуйте подключить только одно, чтобы исключить конфликты адресов или неисправность другого устройства.

---

Рубрика оценивания лабораторной работы

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

| Задача 1: Идентификация устройств | Таблица заполнена полностью и корректно. | Таблица заполнена, 1-2 незначительные ошибки. | Таблица заполнена частично или с несколькими ошибками. | Задача не выполнена или выполнена неверно. |

| Задача 2: Анализ телеметрии | Таблица заполнена корректными значениями, отражающими наблюдаемые данные. | Таблица заполнена, но есть небольшие неточности в значениях. | Таблица заполнена частично или с существенными ошибками. | Задача не выполнена или выполнена неверно. |

| Задача 3: Определение IoT | Все пропуски заполнены точно и в соответствии со стандартами. | Все пропуски заполнены, но есть небольшие стилистические неточности. | Заполнено 1-2 пропуска, или есть смысловые ошибки. | Задача не выполнена или выполнена неверно. |

| Задача 4: Применение IoT | Сценарий конкретен, использованы все ключевые слова, объем соблюден, обоснование логично. | Сценарий хороший, но не все ключевые слова использованы или объем немного отличается. | Сценарий слишком общий, не все ключевые слова, или обоснование слабое. | Задача не выполнена или выполнена неверно. |

| Задача 5: Расчет нагрузки | Расчеты верны, обоснование критичности полное и логичное. | Расчеты верны, но обоснование неполное или с небольшими неточностями. | Расчеты неверны или обоснование отсутствует/нелогично. | Задача не выполнена или выполнена неверно. |

| Задача 6: Перспективы развития | Описаны 2+ протокола/технологии, объем соблюден, предложения реалистичны и обоснованы. | Описаны 2 протокола/технологии, но обоснование слабое или объем немного отличается. | Описан 1 протокол/технология, или предложения нереалистичны. | Задача не выполнена или выполнена неверно. |

| Задача 7: Мини-проект | Поток полностью соответствует требованиям: чтение, валидация, логирование успеха/ошибок, визуальный статус. Проверка в MySQL подтверждена. | Поток почти полностью соответствует, 1-2 незначительные ошибки (например, в SQL-запросе или валидации). | Поток частично соответствует, есть существенные ошибки в логике или реализации. | Задача не выполнена или выполнена неверно. |