Конфигурация 1-Wire интерфейса в системе

Урок 3 · Датчики и входы: нормализация сигналов · 30 мин · theory

Секция 1: Активация интерфейса 1-Wire на контроллере HI

Прежде чем система сможет взаимодействовать с датчиками по шине 1-Wire, необходимо активировать соответствующий аппаратный интерфейс на уровне операционной системы контроллера. В платформе HI, работающей под управлением Debian Linux, эта задача решается путем конфигурации загрузчика и активации специализированного модуля ядра.

> ⚠️ Внимание: Всегда создавайте резервную копию конфигурационных файлов перед внесением изменений. Ошибка в файле `/boot/config.txt` может привести к невозможности загрузки контроллера. Используйте команду `sudo cp /boot/config.txt /boot/config.txt.bak` для создания резервной копии.

Обзор аппаратной реализации

Интерфейс 1-Wire на контроллере HI реализован программно с использованием одного из универсальных портов ввода-вывода (GPIO - General-Purpose Input/Output). По умолчанию для шины 1-Wire зарезервирован контакт GPIO4. Физически этот порт может быть выведен на отдельную клемму на плате контроллера или быть частью универсального входного блока. Как мы уже обсуждали в уроке по схемам подключения, к этой единственной клемме (и клеммам питания и земли) подключаются все датчики на шине.

Для того чтобы операционная система "поняла", что GPIO4 должен работать не как обычный дискретный вход, а как мастер шины 1-Wire, используется специальный модуль ядра `w1-gpio`. Этот модуль предоставляет драйвер, который управляет протоколом 1-Wire на низком уровне.

Проверка статуса модуля ядра

Перед внесением изменений полезно проверить, не загружен ли модуль уже. Это можно сделать через командную строку Linux, подключившись к контроллеру по SSH.

lsmod | grep w1

Если команда не выводит ничего, значит, модули `w1_gpio` (для управления GPIO) и `wire` (основной фреймворк 1-Wire) не загружены. Если они уже в списке, интерфейс, скорее всего, активен.

Конфигурация загрузчика

Основной шаг активации — это редактирование файла конфигурации загрузчика `/boot/config.txt`. Этот файл содержит директивы, которые система считывает на самом раннем этапе загрузки для настройки аппаратных интерфейсов. Нам необходимо добавить оверлей (Device Tree Overlay), который сообщает ядру о необходимости загрузить модуль `w1-gpio` и привязать его к GPIO4.

Откройте файл для редактирования с правами суперпользователя:

sudo nano /boot/config.txt

Перейдите в конец файла и добавьте следующую строку:

# Активация интерфейса 1-Wire на GPIO4 dtoverlay=w1-gpio

Иногда может потребоваться указать конкретный пин, хотя `w1-gpio` по умолчанию использует GPIO4. Если документация на вашу версию контроллера требует явного указания, строка будет выглядеть так: `dtoverlay=w1-gpio,gpiopin=4`.

Сохраните изменения (в редакторе `nano` это `Ctrl+O`, `Enter`) и закройте редактор (`Ctrl+X`).

Перезагрузка и верификация

Чтобы изменения в `/boot/config.txt` вступили в силу, контроллер необходимо перезагрузить.

sudo reboot

После перезагрузки контроллера снова подключитесь по SSH и выполните проверочные шаги:

Проверьте системный журнал на предмет сообщений о загрузке модуля.

    dmesg | grep w1-gpio

Успешный результат будет выглядеть примерно так:

[ 3.141592] w1-gpio onewire@0: bus_master-0: Family 0 for 00.3c0000000000.1c is not registered.

Это сообщение информирует, что драйвер успешно инициализировал мастер шины.

Проверьте, загрузились ли модули ядра повторно.

    lsmod | grep w1

Теперь вывод должен содержать как минимум `w1_gpio` и `wire`. Часто также автоматически подгружается модуль `w1_therm` для работы с датчиками температуры.

Проверьте наличие интерфейса в файловой системе `/sys`. Это самый надежный способ. Если интерфейс активен, в системе появится специальная директория.

ls /sys/bus/w1/devices/

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

Если все три проверки прошли успешно, контроллер готов к поиску и опросу устройств на шине 1-Wire.

---

Секция 2: Поиск и идентификация датчиков в Linux

После активации интерфейса на уровне ОС следующим шагом является обнаружение физически подключенных к шине датчиков. В Linux это делается не с помощью специализированных утилит, а через взаимодействие со специальной виртуальной файловой системой sysfs, которая монтируется в директорию `/sys`.

> 💡 Подсказка: Для удобства можно создать псевдонимы (aliases) в `~/.bashrc` для часто используемых команд, например, `alias 1w_list="ls /sys/bus/w1/devices/28-*"`. Это позволит быстро получать список всех датчиков температуры.

Структура файловой системы sysfs для 1-Wire

Ядро Linux представляет все устройства в системе в виде файлов и директорий. Для шины 1-Wire корневой точкой является `/sys/bus/w1/devices`. Давайте рассмотрим ее содержимое.

ls -l /sys/bus/w1/devices/

Вывод будет выглядеть примерно так:

total 0
lrwxrwxrwx 1 root root 0 мар 15 10:00 28-01203b1c2d3e -> ../../../devices/w1_bus_master1/28-01203b1c2d3e
lrwxrwxrwx 1 root root 0 мар 15 10:00 28-01203c4a5f6e -> ../../../devices/w1_bus_master1/28-01203c4a5f6e
lrwxrwxrwx 1 root root 0 мар 15 10:00 w1_bus_master1 -> ../../../devices/w1_bus_master1

📋 Ключевые понятия:

`w1_bus_master1`: Это директория, представляющая сам мастер шины, который мы активировали.
`28-xxxxxxxxxxxx`: Это директории, каждая из которых представляет одно обнаруженное на шине устройство. `28` — это код семейства для датчиков температуры DS18B20. `xxxxxxxxxxxx` — это уникальный 64-битный адрес устройства (ROM-код), который "зашит" в каждый датчик на заводе. Как мы помним из основ протокола, именно эти уникальные адреса позволяют работать с множеством устройств на одной двухпроводной шине.

Таким образом, чтобы получить список всех подключенных датчиков температуры, достаточно выполнить команду:

ls /sys/bus/w1/devices/28-*

Результат этой команды — это полный путь к директории каждого датчика.

Чтение необработанных данных из датчика

Внутри директории каждого датчика (например, `/sys/bus/w1/devices/28-01203b1c2d3e`) находится несколько файлов, предоставляющих информацию об устройстве. Ключевым для нас является файл `w1_slave`. Чтение из этого файла инициирует процесс измерения температуры и возвращает результат.

Давайте прочитаем данные с одного из датчиков:

cat /sys/bus/w1/devices/28-01203b1c2d3e/w1_slave

Содержимое этого файла всегда имеет строго определенный формат и состоит из двух строк:

a1 01 4b 46 7f ff 0c 10 33 : crc=33 YES
a1 01 4b 46 7f ff 0c 10 33 t=26062

Разберем этот вывод:

Первая строка: `a1 01 ... 33 : crc=33 YES`

* `a1 01 ... 33`: Это 9 байт данных, считанных из памяти датчика (scratchpad).

* `crc=33`: Это значение контрольной суммы (CRC), вычисленное ядром на основе полученных данных.

* `YES`: Самый важный флаг. Он означает, что вычисленная контрольная сумма совпала с той, что передал датчик. Это подтверждает целостность сигнала и достоверность данных. Если здесь будет `NO`, данные считаются некорректными и их нельзя использовать.

Вторая строка: `a1 01 ... 33 t=26062`

* Первая часть дублирует данные из первой строки.

* `t=26062`: Это и есть необработанное (raw) значение температуры. Это не градусы Цельсия. Для получения реального значения это число нужно разделить на 1000. В данном случае `26062 / 1000 = 26.062 °C`.

Этот простой механизм — чтение текстового файла — является низкоуровневым, но чрезвычайно надежным способом получения данных с датчиков 1-Wire в среде Linux. На следующих этапах мы автоматизируем этот процесс в Node-RED.

---

Секция 3: Получение данных в среде Node-RED

Теперь, когда мы умеем получать данные с датчиков через командную строку, наша задача — перенести эту логику в среду Node-RED для автоматического периодического опроса.

> 🔗 Связанный материал: Основы работы с узлом 'Exec', включая обработку кодов возврата и тайм-аутов, подробно рассмотрены в уроке COURSE-02-M03-L04 'Взаимодействие с ОС'.

Существует два основных подхода к интеграции с 1-Wire в Node-RED:

Использование специализированных узлов: Существуют готовые узлы в палитре, например, `node-red-contrib-ds18b20-sensor` или аналогичные. Они упрощают настройку, предоставляя графический интерфейс для выбора датчика. Однако они добавляют внешнюю зависимость в проект и могут быть менее гибкими.

Использование универсального узла `Exec`: Этот узел позволяет выполнить любую команду в операционной системе контроллера и получить ее вывод. Этот подход является более универсальным, не требует установки дополнительных модулей Node-RED и дает полный контроль над процессом. Мы сосредоточимся именно на нем, так как он соответствует методологии построения надежных систем с минимумом зависимостей.

Настройка потока для опроса

Создадим простой поток, который будет каждые 30 секунд опрашивать один датчик и выводить результат в панель отладки.

ASCII-схема потока:

[Inject: 30s] ---> [Exec: cat w1_slave] ---> [Debug: Raw output]

Шаги по настройке:

Добавьте узел `Inject` на рабочее поле.

* Payload: `timestamp` (по умолчанию).

* Topic: оставьте пустым.

* Repeat: установите `interval` и задайте значение `30` секунд. Это будет наш триггер для опроса.

Добавьте узел `Exec`. Это ядро нашего механизма опроса.

* Command: в это поле нужно вставить команду `cat` с полным путем к файлу `w1_slave` вашего датчика. Например:

cat /sys/bus/w1/devices/28-01203b1c2d3e/w1_slave

Замените `28-01203b1c2d3e` на реальный ID вашего датчика, полученный в предыдущей секции.

* Append: оставьте эту опцию пустой.

* Timeout: установите значение `5` секунд. Это важно: если по какой-то причине команда "зависнет", узел `Exec` прервет ее выполнение через 5 секунд и выдаст ошибку, предотвращая блокировку потока.

* Name: задайте осмысленное имя, например, "Опрос датчика в гостиной".

Добавьте узел `Debug` и соедините его с первым выходом узла `Exec`.

* Output: установите `complete msg object`, чтобы видеть всю структуру сообщения.

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

Анализ объекта `msg`

Теперь, если вы перейдете на вкладку `Debug` (отладка), вы увидите, что каждые 30 секунд появляется новый объект `msg`. Его структура будет примерно такой:

{
    "payload": "a1 01 4b 46 7f ff 0c 10 33 : crc=33 YES\na1 01 4b 46 7f ff 0c 10 33 t=26062\n",
    "rc": {
        "code": 0,
        "message": ""
    },
    "_msgid": "a1b2c3d4.e5f6g7"
}

Рассмотрим ключевые поля:

`msg.payload` (string): Это стандартный вывод (stdout) выполненной нами команды. Он содержит те самые две строки из файла `w1_slave`, включая символы переноса строки `\n`.
`msg.rc` (object): Этот объект содержит информацию о коде возврата команды.

* `code: 0`: Код `0` в Linux традиционно означает успешное выполнение команды. Если бы файл не был найден, код был бы `1` или другим ненулевым значением. Анализ этого кода — важный элемент обработки ошибок.

Мы успешно автоматизировали получение необработанных данных. Следующий шаг — извлечь из этой строки полезную информацию (температуру) и привести ее к удобному для работы виду.

---

Секция 4: Парсинг и нормализация данных

Получив сырую строку от датчика, мы должны преобразовать ее в структурированные и понятные данные. Этот процесс называется парсингом (синтаксическим анализом) и нормализацией (приведением к стандартному формату). Для этой задачи в Node-RED идеально подходит узел `Function`, позволяющий писать произвольный код на JavaScript.

> ⚠️ Внимание: Крайне важно всегда проверять результат CRC (наличие 'YES' в первой строке). Использование значения при неудачной проверке может привести к неверным данным в системе автоматизации, что может повлечь за собой некорректную работу климатических систем или ложные тревоги.

Алгоритм и реализация в узле `Function`

Наш поток теперь будет выглядеть так: `Inject -> Exec -> Function -> Debug`. Вся логика будет сосредоточена в узле `Function`.

Алгоритм парсинга:

Принять `msg.payload` в виде строки от узла `Exec`.

Проверить, что строка содержит подстроку `"YES"`. Если нет — прекратить обработку и выдать ошибку.

Найти позицию подстроки `"t="`.

Взять все символы после `"t="`.

Преобразовать полученную строку в число.

Разделить число на 1000, чтобы получить градусы Цельсия.

Поместить результат в `msg.payload`.

Обновить статус узла для визуальной диагностики.

Код для узла `Function`:

// Получаем сырой вывод из msg.payload
const raw_data = msg.payload;

// 1. Проверка целостности данных (CRC)
if (!raw_data.includes("YES")) {
    node.status({fill:"red", shape:"dot", text:"CRC error"});
    // Генерируем ошибку, которая может быть поймана узлом Catch
    node.error("CRC check failed for 1-Wire sensor", msg);
    return null; // Прекращаем выполнение потока для этого сообщения
}

// 2. Поиск значения температуры
const temp_index = raw_data.indexOf("t=");
if (temp_index === -1) {
    node.status({fill:"red", shape:"dot", text:"'t=' not found"});
    node.error("Temperature value not found in sensor output", msg);
    return null; // Прекращаем выполнение
}

// 3. Извлечение и преобразование
// Вырезаем строку после 't='
const temp_string = raw_data.substring(temp_index + 2);
// Преобразуем в число с плавающей точкой
const temp_raw = parseFloat(temp_string);

// 4. Нормализация (деление на 1000)
const temperature = temp_raw / 1000;

// 5. Валидация диапазона (дополнительная защита)
if (isNaN(temperature) || temperature < -55 || temperature > 125) {
    node.status({fill:"yellow", shape:"ring", text:"Invalid value: " + temperature});
    node.error("Temperature value is out of valid range: " + temperature, msg);
    return null;
}

// 6. Формирование чистого payload и обновление статуса
msg.payload = temperature;
node.status({fill:"green", shape:"dot", text: temperature.toFixed(2) + " °C"});

// Возвращаем измененное сообщение для дальнейшей обработки
return msg;

После добавления этого кода в узел `Function`, подключите к его выходу узел `Debug` (настроенный на показ `msg.payload`). Теперь в панели отладки вы будете видеть не сырую строку, а чистое числовое значение, например, `26.062`.

Кроме того, под узлом `Function` в редакторе Node-RED будет отображаться его текущий статус: зеленый кружок и значение температуры. Это наглядный пример использования Паттерна "Визуальный статус" для быстрой диагностики.

---

Секция 5: Практический пример: от датчика до MQTT

Объединим все предыдущие шаги в один законченный и полезный сценарий. Наша цель — создать надежный поток, который опрашивает датчик, обрабатывает его показания и публикует их в MQTT-брокере для использования другими системами (например, панелями визуализации, мобильными приложениями или сложными климатическими сценариями).

> 🔗 Связанный материал: Подробные инструкции по настройке MQTT-брокера и принципы формирования топиков описаны в модуле COURSE-06-M02 'Протокол MQTT в системах HI'.

Построение законченного потока

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

`Inject` -> `Exec` -> `Function` -> `RBE` -> `Function (Format JSON)` -> `MQTT Out`

Новые узлы в цепочке:

`RBE` (Report by Exception): Этот узел (также известный как `filter`) блокирует передачу сообщения дальше, если его `payload` не изменился с прошлого раза. Это чрезвычайно полезно, так как температура меняется медленно, и нет смысла отправлять в сеть одно и то же значение каждую минуту, создавая лишний трафик.

* Mode: `block if value hasn't changed`.

`Function (Format JSON)`: Второй узел `Function` мы используем для форматирования данных в соответствии с Паттерном "Контракт сообщения". Вместо простого числа мы будем отправлять в MQTT структурированный JSON-объект.

Настройка потока

Создайте цепочку, как показано выше. Узлы `Inject`, `Exec` и первый `Function` (парсер) настройте так, как было описано в предыдущих секциях.

Настройте узел `RBE`. Большинство настроек по умолчанию подходят. Он будет сравнивать `msg.payload` (наше числовое значение температуры).

Настройте второй узел `Function` с именем "Format JSON". Вставьте в него следующий код:

    // Получаем чистое значение температуры от RBE узла
    const temp_value = msg.payload;

    // Формируем структурированный объект в соответствии с контрактом
    msg.payload = {
        "value": parseFloat(temp_value.toFixed(2)), // Округляем до 2 знаков
        "unit": "C", // Единица измерения
        "source": "28-01203b1c2d3e", // ID датчика для идентификации
        "ts": Date.now() // Временная метка в формате Unix epoch (ms)
    };

    return msg;

Настройте узел `MQTT Out`.

* Server: Выберите или настройте подключение к вашему MQTT-брокеру (например, `localhost:1883`).

* Topic: Укажите осмысленный топик, описывающий источник данных. Например:

hi/office/room101/temperature

* QoS: Установите `1` или `2` для гарантированной доставки.

* Retain: Установите `true`. Это означает, что брокер сохранит последнее сообщение в этом топике, и любой новый клиент, подписавшийся на него, сразу получит актуальное значение температуры, не дожидаясь следующего опроса.

Теперь разверните поток. Если все настроено правильно, контроллер будет опрашивать датчик каждые 30 секунд. Если значение температуры изменилось, оно будет отформатировано в JSON и опубликовано в указанном MQTT-топике. Эти данные теперь доступны для любой системы, которая умеет работать с MQTT, что открывает безграничные возможности для интеграции и автоматизации.

---

Секция 6: Диагностика неисправностей

Несмотря на простоту и надежность протокола 1-Wire, при монтаже и настройке могут возникать проблемы. Умение быстро их диагностировать и устранять — ключевой навык инсталлятора.

> 🔗 Связанный материал: При проблемах с CRC и нестабильным сигналом вернитесь к уроку COURSE-04-M06-L03, где разбирались схемы подключения и топологии шины.

Датчик не определяется в системе

Симптом: Команда `ls /sys/bus/w1/devices/` не показывает директории с префиксом `28-`.
Диагностика и решения:

1. Проверка физического уровня: Это первая и самая частая причина.

* Проверьте надежность подключения проводов (Data, GND, VCC) на клеммах контроллера и датчика.

* Проверьте, подается ли питание на датчик. Если используется "паразитное питание", убедитесь, что VCC датчика соединен с GND. Если внешнее — убедитесь, что на VCC подается 3.3-5V.

* "Прозвоните" кабель мультиметром на предмет обрыва или короткого замыкания.

2. Проверка на уровне ОС:

* Убедитесь, что контроллер был перезагружен после внесения изменений в `/boot/config.txt`.

* Проверьте еще раз содержимое файла `config.txt`. Нет ли в нем опечаток в строке `dtoverlay=w1-gpio`?

* Проверьте вывод `dmesg | grep w1`, нет ли там сообщений об ошибках инициализации.

Ошибки CRC

Симптом: Файл `w1_slave` читается, но первая строка заканчивается на `NO` вместо `YES`. Узел `Function` в Node-RED выдает ошибку "CRC check failed".
Диагностика и решения:

* Электромагнитные помехи (EMI/RFI): Проверьте, не проложен ли кабель шины 1-Wire вплотную к силовым кабелям 230V, люминесцентным лампам или мощным электродвигателям. Используйте экранированный кабель "витая пара", подключив экран к GND только со стороны контроллера.

* Превышение длины шины: Общая длина шины 1-Wire сильно зависит от топологии и качества кабеля. Для "паразитного" питания предел часто составляет 20-30 метров. Для более длинных линий (>15м) крайне рекомендуется использовать схему с внешним питанием (3 провода).

* Неверная топология: Избегайте топологии "звезда" с длинными лучами. Предпочтительна линейная "шинная" топология.

* Плохой контакт: Дребезг контактов в скрутках или на клеммах может вызывать повреждение пакетов данных. Используйте качественные клеммники или пайку.

Некорректные или "плавающие" значения

Симптом: Датчик показывает `-0.062` или `85.0`. Значения температуры резко скачут.
Диагностика и решения:

* Значение `85` °C: Это специальное значение, которое датчик DS18B20 отдает сразу после включения питания, до того как завершен первый цикл измерения. Если вы получаете его постоянно, это может указывать на проблемы с питанием или сброс датчика. Проверьте стабильность напряжения питания.

* Ошибки парсинга: Дважды проверьте код в узле `Function`. Убедитесь, что вы правильно находите `t=`, преобразуете строку в число и делите на 1000.

* Плавающие значения: Могут быть следствием тех же причин, что и ошибки CRC (помехи, плохой контакт). Система может получать поврежденные, но формально верные (с точки зрения CRC) пакеты. Улучшение качества физической линии связи обычно решает эту проблему.

Систематический подход к диагностике, начиная от программного уровня и спускаясь к физическому, позволяет быстро локализовать и устранить большинство проблем с шиной 1-Wire.

Что дальше

В этом уроке мы прошли полный путь от активации аппаратного интерфейса 1-Wire до создания законченного потока для публикации данных с датчиков по MQTT. Вы научились работать с системными файлами Linux, использовать узел `Exec` для взаимодействия с ОС и писать JavaScript-код для парсинга и нормализации данных. В следующем модуле мы перейдем к более сложным промышленным протоколам, начав с изучения Modbus RTU, и научимся подключать к контроллеру HI счетчики электроэнергии, релейные модули и другое профессиональное оборудование.