Инновации и разработки в IoT: от трендов к практической реализации на платформе HI

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

COURSE-16-M06-L02 — Инновации и разработки в IoT: от трендов к практической реализации на платформе HI

Введение: Трансформация трендов в инженерные задачи

Интернет вещей (IoT) — это не статичная концепция, а динамично развивающаяся отрасль. Новые технологии, такие как периферийные вычисления (Edge AI), протоколы связи нового поколения и методы обеспечения целостности данных, постоянно меняют ландшафт автоматизации. Для инженера важно не просто знать об этих трендах, но и понимать, как их можно применить на практике, используя доступные инструменты.

Данный урок переводит высокоуровневые инновации на язык конкретных инженерных решений, реализуемых на контроллере платформы HI. Мы рассмотрим, как глобальные тенденции трансформируются в практические сценарии, потоки Node-RED и схемы подключения, которые вы будете создавать на реальных объектах.

1. Интеллектуальные сенсоры и Edge AI: Логика на периферии

Тренд: Сенсоры становятся «умнее», используя встроенные алгоритмы искусственного интеллекта (AI) и машинного обучения (ML) для предварительной обработки данных. Это называется периферийными вычислениями или Edge AI. Практическая реализация на платформе HI: Контроллер HI является мощным Edge-устройством. Его 4-ядерный процессор и среда Node-RED позволяют реализовывать сложную логику непосредственно «на борту», не отправляя сырые данные в облако. Это повышает скорость реакции системы, снижает трафик и обеспечивает работу даже при потере связи с интернетом. Пример: Сценарий «Умный датчик присутствия» (SCN-PRESENCE-007)

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

Задача: Включать основной свет в офисе, только если в течение 10 секунд сработали два разных датчика движения, и выключать, если в течение 5 минут не было ни одного срабатывания.

Flow Diagram (ASCII):

(Датчик 1) --+                                +--> [Function: "Умная логика"] --+--> (Управление светом DALI)
             |--> [Trigger: 10 sec] --(send)-->|                                |
(Датчик 2) --+                                +--> [Status: "Зона активна"]      +--> (Сброс таймера выключения)

Реализация в Node-RED:

1. Входы: Два узла `rpi gpio in`, подключенные к универсальным входам контроллера, куда физически подключены датчики движения («сухой контакт»).

2. Фильтрация: Каждый вход соединен с узлом `Trigger`. Узел настроен так, чтобы отправлять сообщение `1` при первом срабатывании, но не отправлять последующие в течение 10 секунд.

3. Агрегация и логика (Паттерн FSM): Узел `Function` реализует конечный автомат. Он использует `flow context` для хранения состояний датчиков.

* При получении сигнала от первого датчика, он запускает таймер.

* Если в течение 10 секунд приходит сигнал от второго датчика, он меняет состояние зоны на `flow.zone_occupied = true` и отправляет команду на включение света.

* Если таймер истекает без второго сигнала, событие считается ложным.

4. Визуализация (Паттерн Visual Status): Узел `Function` обновляет свой статус: `node.status({fill:"green", shape:"dot", text:"Зона занята"});` или `node.status({fill:"grey", shape:"ring", text:"Ожидание"});`.

5. Исполнение: Команда отправляется на субпоток управления светом по шине DALI (`FLOW-CTRL-DALI-002`).

Контракт сообщения (на выходе из `Function`):

{ "payload": { "command": "ON", "brightness": 80, "zone": "office-main" }, "topic": "commands/light/set" }

2. Отказоустойчивость связи (5G/LTE): Резервный канал

Тренд: Сети 5G и LTE обеспечивают высокоскоростной и надежный канал связи, что критично для удаленного мониторинга и управления. Практическая реализация на платформе HI: Для инженера это в первую очередь означает резервирование. Опциональный GSM-модуль в контроллере HI — это не просто способ выхода в интернет, а стратегический элемент отказоустойчивости. Если основной канал (Ethernet/Wi-Fi) пропадает, система должна автоматически переключиться на резервный и уведомить об этом. Пример: Сценарий «Автоматическое переключение на резервный канал» (SCN-CONNECTIVITY-FAILOVER-001)

Задача: Постоянно проверять доступность интернета через основной канал. В случае сбоя, активировать GSM-модуль и отправить критическое уведомление через MQTT по резервному каналу.

Flow Diagram (ASCII):

[Inject: 1 min] -> [Exec: ping 8.8.8.8] --+-- (RC=0, OK) ----> [Status: "WAN: OK"]
                                         |
                                         +-- (RC!=0, Fail) -> [Function: "Активация GSM"] -> [Exec: pppd call gsm] -> [MQTT Out: "CRITICAL: WAN Fail"]

Реализация в Node-RED:

1. Проверка: Узел `Inject` раз в минуту запускает узел `Exec`, который выполняет команду `ping -c 1 8.8.8.8`.

2. Обработка ошибок (Паттерн Error Handling): Узел `Exec` имеет три выхода. Выход 1 (успех, код возврата 0) ведет к узлу `Status`, который устанавливает статус `WAN: OK`. Выходы 2 и 3 (ошибка) ведут к логике переключения.

3. Логика переключения: Узел `Function` формирует сообщение для администратора и инициирует запуск GSM-соединения.

4. Активация GSM: Следующий узел `Exec` выполняет системную команду Debian для запуска PPP-сессии через GSM-модем (например, `pppd call gsm-provider`).

5. Уведомление: После активации резервного канала узел `mqtt out` отправляет сообщение в специальный топик `system/alerts/connectivity` с payload:

{ "value": "WAN_FAILOVER_ACTIVE", "source": "HI-Controller-SN12345", "ts": 1678886400000, "meta": { "channel": "GSM" } }

3. Целостность данных (Блокчейн): Практика создания Audit Log

Тренд: Технология блокчейн обеспечивает неизменность и прозрачность данных. Для большинства задач IoT полноценный блокчейн избыточен, но его ключевой принцип — связанная цепочка хешей — крайне полезен. Практическая реализация на платформе HI: Мы можем реализовать легковесный аналог для создания защищенного от подделки журнала событий (Audit Log) с использованием встроенной базы данных MySQL. Каждая новая запись будет криптографически связана с предыдущей. Пример: Защищенный журнал доступа (FLOW-AUDIT-LOG-001)

Задача: Каждое событие (открытие двери, снятие с охраны) записывать в таблицу `audit_log` в MySQL. Каждая запись должна содержать хеш, рассчитанный на основе данных текущей записи и хеша предыдущей записи.

Структура таблицы `audit_log` в MySQL:

    CREATE TABLE audit_log (
        id INT AUTO_INCREMENT PRIMARY KEY,
        ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
        event_source VARCHAR(255),
        event_type VARCHAR(255),
        event_data JSON,
        previous_hash VARCHAR(64),
        current_hash VARCHAR(64)
    );

Flow Diagram (ASCII):

[MQTT In: "events/#"] -> [Function: "Создать запись и хеш"] -> [mysql] -> [Status: "Запись добавлена"]

Реализация в Node-RED:

1. Сбор событий: Узел `mqtt in` подписывается на все топики событий `events/#`.

2. Логика хеширования (Паттерн "Контракт сообщения"): Узел `Function` выполняет основную работу.

        // 1. Получаем хеш последней записи из БД (через доп. запрос или flow context)
        const lastHash = flow.get("last_audit_hash") || "0000000000000000000000000000000000000000000000000000000000000000";

        // 2. Формируем данные для хеширования
        const entryData = {
            ts: new Date().toISOString(),
            source: msg.topic,
            data: msg.payload
        };
        const dataToHash = JSON.stringify(entryData) + lastHash;

        // 3. Вычисляем новый хеш (требуется node-red-contrib-crypto-js)
        // В данном примере используем псевдо-хеш для простоты
        const currentHash = "hash(" + dataToHash.substring(0, 20) + ")"; // В реальности здесь будет crypto.createHash('sha256')...

        // 4. Формируем SQL-запрос
        msg.topic = `INSERT INTO audit_log (event_source, event_type, event_data, previous_hash, current_hash) VALUES (?, ?, ?, ?, ?)`;
        msg.payload = [
            entryData.source,
            entryData.data.event_type || 'generic',
            JSON.stringify(entryData.data),
            lastHash,
            currentHash
        ];

        // 5. Сохраняем новый хеш для следующей итерации
        flow.set("last_audit_hash", currentHash);

        return msg;

3. Запись в БД: Узел `mysql` выполняет SQL-запрос, сформированный на предыдущем шаге.

4. Обработка ошибок: Узел `Catch` отлавливает ошибки записи в БД и отправляет уведомление.

4. Интеграция систем (Умные города): Сценарии взаимодействия

Тренд: «Умные города» интегрируют разрозненные системы (освещение, транспорт, безопасность) для эффективного управления. Практическая реализация на платформе HI: На уровне объекта (офис, гостиница, коттедж) этот тренд проявляется в интеграции подсистем, работающих по разным протоколам. Контроллер HI выступает в роли центрального шлюза, который «понимает» Modbus, DALI, CAN, MQTT и позволяет им работать вместе. Пример: Сценарий «Единый климат и свет» (FLOW-INTEG-HVAC-LIGHT-001)

Задача: В переговорной комнате при активации проектора (управляемого по RS-485) автоматически приглушать свет (DALI) до 30% и переводить систему вентиляции (Modbus) в усиленный режим.

Flow Diagram (ASCII):

[MQTT In: "projector/set=ON"] -> [Subflow: "Сценарий Презентация"] --+--> [DALI Out: "dim 30%"]
                                                                    |
                                                                    +--> [Modbus Write: "set fan speed high"]

Реализация в Node-RED:

1. Триггер: Узел `mqtt in` получает команду о включении проектора.

2. Переиспользуемый компонент (Паттерн Subflow): Создается субпоток `Сценарий Презентация`. Это позволяет использовать его и в других ситуациях (например, по нажатию кнопки на стене).

3. Логика внутри субпотока:

* Вход: Принимает команду активации.

* Выход 1 (DALI): Формирует сообщение для узла `dali-out` с командой установки яркости для группы светильников переговорной.

* Выход 2 (Modbus): Формирует сообщение для узла `modbus-write` для записи нового значения в регистр скорости вентилятора в контроллере HVAC.

* Контракты сообщений: Субпоток на своих выходах генерирует сообщения, строго соответствующие требованиям узлов `dali-out` и `modbus-write`.

5. Взаимодействие с внешними сервисами (Носимые устройства)

Тренд: Носимые устройства (фитнес-трекеры, умные часы) собирают персональные данные и могут взаимодействовать с другими системами через облачные платформы. Практическая реализация на платформе HI: Контроллер не может напрямую подключиться к умным часам, но он может получать от них сигналы через облачные сервисы-посредники (например, IFTTT, Zapier) с помощью веб-хуков (Webhooks). Пример: Сценарий «Тревожная кнопка» (SCN-SAFETY-014)

Задача: Пожилой человек носит умные часы с функцией "тревожной кнопки". При нажатии часы отправляют сигнал в облачный сервис, который, в свою очередь, вызывает веб-хук на контроллере HI. Контроллер должен активировать световую и звуковую сигнализацию и отправить SMS родственникам через GSM-модуль.

Flow Diagram (ASCII):

[HTTP In: "/webhook/panic-button"] -> [Function: "Валидация и логика"] --+--> [GPIO Out: Сирена]
                                                                         |
                                                                         +--> [DALI Out: Мигать светом]
                                                                         |
                                                                         +--> [Exec: "Отправить SMS"]

Реализация в Node-RED:

1. Точка входа: Узел `http in` настраивается на метод `POST` и URL `/webhook/panic-button/a1b2c3d4` (где `a1b2c3d4` — секретный токен для безопасности). Он создает веб-сервер, ожидающий входящих запросов.

2. Валидация и обработка: Узел `function` проверяет тело запроса (JSON) на наличие корректных данных.

        // Пример входящего JSON от облачного сервиса
        // { "deviceId": "watch-123", "alertType": "fall_detection", "token": "secret_token" }

        const expectedToken = "secret_token"; // Хранить в flow context
        if(msg.payload.token !== expectedToken){
            node.warn("Попытка неавторизованного доступа к веб-хуку");
            // Отправляем ответ с ошибкой
            msg.res.sendStatus(401); 
            return null; // Останавливаем поток
        }

        // Логика тревоги
        // ...

        // Отправляем ответ об успешном приеме
        msg.res.sendStatus(200);
        return msg;

3. Исполнение: Сообщение разветвляется на несколько потоков для одновременной активации реле сирены (`gpio out`), отправки команд мигания на светильники DALI и запуска скрипта отправки SMS через GSM-модем (`exec`).

---

Лабораторные работы

COURSE-16-M06-LAB03: Создание отказоустойчивого канала связи с использованием GSM-модуля

Цель: Настроить в Node-RED поток, который отслеживает состояние основного интернет-соединения и, в случае его отказа, автоматически активирует резервный GSM-канал и отправляет уведомление.
Оборудование: Контроллер HI с установленным GSM-модулем и SIM-картой.
Задание:

1. Создать поток, который каждые 30 секунд проверяет доступность внешнего ресурса (например, `ping 1.1.1.1`).

2. При успешном пинге узел `Status` должен отображать зеленый статус "WAN: OK".

3. При неудачном пинге поток должен выполнить системную команду для поднятия GSM-соединения.

4. После поднятия GSM-канала отправить MQTT-сообщение в топик `alerts/system` с payload `{"status": "wan_failover"}`.

5. Узел `Status` должен смениться на желтый "WAN: GSM Failover".

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

* Поток корректно определяет сбой основного канала (можно имитировать, отключив Ethernet-кабель).

* GSM-соединение успешно устанавливается.

* MQTT-сообщение отправлено.

* Статус узла корректно отображает текущее состояние.

COURSE-16-M06-LAB04: Реализация сценария «Интеллектуальный свет» с интеграцией датчика и Modbus-устройства

Цель: Создать интегрированный сценарий, в котором состояние Modbus-устройства влияет на логику управления освещением DALI.
Оборудование: Контроллер HI, датчик «сухого контакта», Modbus-эмулятор (или реальное устройство), DALI-драйвер.
Задание:

1. Настроить опрос Modbus-регистра (Holding Register 40001), который имитирует состояние "Встреча" (`1` - активна, `0` - неактивна).

2. Создать поток, который по срабатыванию датчика «сухого контакта» (имитация входа в комнату) включает свет DALI на 100%.

3. Добавить логику: если регистр "Встреча" имеет значение `1`, то при срабатывании датчика свет должен включаться не на 100%, а на 40%.

4. Использовать `flow context` для хранения текущего состояния Modbus-регистра, чтобы не опрашивать его при каждом срабатывании датчика.

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

* Поток корректно считывает состояние Modbus-регистра.

* Логика управления светом изменяется в зависимости от значения в `flow context`.

* Используются субпотоки для управления DALI и чтения Modbus.

* Соблюдается стандартный контракт сообщений.

---

Квиз модуля: COURSE-16-M06-QUIZ

Что является основной задачей инженера при реализации тренда "Edge AI" на контроллере HI?

a) Установка Python и TensorFlow на контроллер.

b) Перенос всей логики в облако для более мощных вычислений.

c) Создание логики в Node-RED (узлы `Function`, `Trigger`) для обработки данных с датчиков непосредственно на контроллере.

d) Покупка специальных "AI-сенсоров".

В сценарии отказоустойчивости (Failover) с GSM-модулем, какой узел Node-RED лучше всего подходит для периодической проверки связи?

a) `MQTT In`

b) `HTTP In`

c) `Inject` + `Exec` (с командой ping)

d) `Catch`

При создании защищенного журнала событий (Audit Log) по принципу блокчейна, что связывает одну запись с другой?

a) Временная метка (timestamp).

b) ID пользователя.

c) Хеш предыдущей записи, включенный в расчет хеша текущей записи.

d) IP-адрес источника события.

Какой паттерн Node-RED наиболее эффективен для реализации сложной логики с множеством состояний, как в "умном датчике присутствия"?

a) Конечный автомат (Finite State Machine) с использованием `flow context`.

b) Простое соединение узлов друг за другом.

c) Использование глобальных переменных.

d) Паттерн "Визуальный статус".

Для интеграции системы вентиляции (Modbus) и освещения (DALI) контроллер HI выступает в роли:

a) Только Modbus Master.

b) Только DALI контроллера.

c) Протокольного шлюза, транслирующего команды между разными системами.

d) Облачного сервера.

Как безопасно реализовать прием команд от внешнего облачного сервиса (например, от носимого устройства)?

a) Открыть на роутере порт 1883 для прямого доступа к MQTT-брокеру.

b) Использовать узел `HTTP In` для создания веб-хука с уникальным токеном в URL.

c) Использовать узел `TCP In` на случайном порту.

d) Попросить сервис отправлять команды по email.

Какова основная цель использования субпотоков (Subflows) в Node-RED?

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

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

c) Увеличить безопасность.

d) Обойти ограничения на количество узлов.

В чем преимущество хранения состояния (например, `zone_occupied`) в `flow context` по сравнению с `global context`?

a) `flow context` доступен из любого потока на любой вкладке.

b) `flow context` изолирован в пределах одной вкладки (flow), что предотвращает случайные изменения из других потоков.

c) `flow context` не требует настройки, в отличие от `global context`.

d) `global context` не сохраняется при перезагрузке.

Какой узел Node-RED является ключевым для централизованной обработки ошибок от узлов Modbus, MQTT, HTTP?

a) `Status`

b) `Debug`

c) `Link Out`

d) `Catch`

При проектировании потока для "умного города" (или здания), что является первым шагом?

a) Выбор самого быстрого протокола.

b) Определение всех подсистем для интеграции и разработка единого "контракта сообщений" для взаимодействия.

c) Написание сложного кода в узле `Function`.

d) Физическое подключение всех устройств к контроллеру.

---

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

Проблема: GSM-модем не выходит на связь (в лаборатории LAB03).

1. Проверка SIM-карты: Убедитесь, что SIM-карта активна, на ней положительный баланс и отключен запрос PIN-кода.

2. Проверка антенны: Проверьте, что GSM-антенна надежно подключена к контроллеру.

3. Проверка конфигурации: В Debian-консоли контроллера проверьте файлы конфигурации PPP (в `/etc/ppp/peers/`). Убедитесь, что APN (точка доступа) указана верно для вашего оператора.

4. Диагностика: Выполните команду `pon <имя_соединения> debug dump logfd 2` и проанализируйте лог на предмет ошибок аутентификации или регистрации в сети.

Проблема: Данные от Modbus-устройства не приходят или некорректны (в лаборатории LAB04).

1. Физическое подключение: Проверьте полярность шины RS-485 (A/B) и наличие питания на устройстве. См. стандарт `WIRING-SENS-004`.

2. Параметры шины: Убедитесь, что скорость (Baud Rate), четность (Parity) и Slave ID в узле `modbus-read` точно совпадают с настройками на устройстве.

3. Адрес регистра: Перепроверьте "ошибку на единицу" (off-by-one). Если в документации указан регистр `40001`, в узле нужно указать адрес `0`.

4. Статус узла: Наведите курсор на узел `modbus-read` в Node-RED. Он покажет статус: `active`, `timeout`, `crc error`. Это даст подсказку о характере проблемы.

Проблема: Веб-хук (HTTP In) не срабатывает или выдает ошибку.

1. Доступность контроллера: Убедитесь, что контроллер доступен из сети, откуда приходит запрос. Если сервис внешний, на роутере должен быть настроен проброс портов (Port Forwarding).

2. URL и метод: Проверьте, что URL, метод (`POST`/`GET`) и токен в запросе точно совпадают с настройками узла `HTTP In`.

3. Ответ узла: Убедитесь, что ваш поток отправляет ответ клиенту. Узел `HTTP In` должен быть соединен с узлом `HTTP Response`. Если этого не сделать, клиент получит ошибку таймаута.

4. Брандмауэр: Проверьте, что брандмауэр на контроллере или на сетевом оборудовании не блокирует порт, который слушает узел `HTTP In`.