Мини-Runbook: Шаг 1-2 (Питание и Сеть)

Урок 1 · Основы умного дома · 30 мин · theory

id: COURSE-01-M08-L01
title: "Мини-Runbook: Шаг 1-2 (Питание и Сеть)"
level: foundation
tags: ["runbook", "диагностика", "питание", "сеть", "troubleshooting", "ping", "ethernet"]
prerequisites: ["COURSE-01-M08-L00"]
version: 1.0.0
status: published

## Введение в Runbook: стандартизация диагностики Этот урок является практическим руководством, которое формализует шаги по поиску и устранению неисправностей на объекте. Он продолжает методологию, изложенную в предыдущем занятии, и переводит теорию в конкретный, пошаговый алгоритм действий. > 🔗 Связанный материал: Этот урок является практическим применением методологии, изложенной в предыдущем занятии `COURSE-01-M08: Системный подход к диагностике`. Рекомендуем ознакомиться с ним перед продолжением. > 📋 Ключевые понятия: > * Runbook (Операционная инструкция): Это строго регламентированный набор процедур для решения стандартных или предсказуемых проблем. В контексте инженера автоматизации, runbook — это ваш лучший друг на объекте, позволяющий не паниковать, а методично и последовательно локализовать неисправность. > * Домен неисправности: Логическая область системы, в которой может находиться проблема. Разделение системы на домены (Питание, Сеть, Шины данных, Логика) является ключевым для быстрой изоляции сбоев. Цель нашего мини-ранбука — быстро проверить фундаментальные уровни системы, на которых строится вся дальнейшая работа. Более 80% проблем на объектах вызваны либо отсутствием, либо нестабильностью питания или сетевого подключения. Игнорирование этих базовых проверок и попытка сразу "залезть в код" или "проверить настройки MQTT" — это путь к потере времени и неверным выводам. В этом уроке мы детально разберем первые два, самых важных шага этого процесса: Шаг 1: Диагностика питания. Проверка всей цепи от вводного автомата в щите до клемм конечного устройства. Шаг 2: Диагностика сети. Проверка физического и канального/сетевого уровней подключения по Ethernet. Успешное прохождение этих двух шагов дает уверенность, что контроллер и периферийные устройства "живы" и способны общаться друг с другом. Только после этого имеет смысл переходить к анализу протоколов и логики сценариев. Важность последовательности невозможно переоценить: она экономит часы работы на объекте и формирует профессиональный подход к диагностике. --- Шаг 1: Диагностика питания — от щита до устройства Любая сложная логика бессильна, если на устройство не подается стабильное электропитание. Этот шаг направлен на верификацию всей силовой цепи. > ⚠️ Внимание: Работы с напряжением 230В сопряжены с риском для жизни. Они должны проводиться только квалифицированным персоналом с обязательным снятием напряжения и соблюдением всех мер электробезопасности. При любых сомнениях обратитесь к квалифицированному электрику. Инструментарий: Мультиметр (с режимами измерения ACV - переменного напряжения, и DCV - постоянного напряжения) Индикаторная отвертка Методика проверки (от источника к потребителю): Проверка в электрощите (230В AC): * Визуальный осмотр: Убедитесь, что все автоматические выключатели (АВ) и устройства защитного отключения (УЗО), отвечающие за питание оборудования автоматизации, находятся во включенном положении. * Проверка наличия фазы: С помощью индикаторной отвертки проверьте наличие фазного напряжения на выходе соответствующего автомата. * Замер напряжения: С помощью мультиметра в режиме ACV измерьте напряжение между фазой (L) и нулем (N) на выходе автомата. Оно должно быть в пределах 220-240В. Проверка блока питания (БП): * Большинство контроллеров и модулей питаются от постоянного тока низкого напряжения (12В или 24В). * Вход БП: Убедитесь, что на входные клеммы БП (`L`, `N`) приходит напряжение 230В AC. * Выход БП: Переключите мультиметр в режим DCV. Измерьте напряжение на выходных клеммах БП (`+V`, `-V` или `GND`). Оно должно соответствовать номиналу блока (например, 24.0-24.5В для 24-вольтового БП). Значительное отклонение (например, 19В вместо 24В) указывает на неисправность БП или его перегрузку. Проверка на клеммах конечного устройства: * Это ключевой этап, который часто пропускают. Напряжение может быть на выходе БП, но не доходить до самого устройства из-за обрыва кабеля или плохого контакта. * Замер напряжения на входе: С помощью мультиметра в режиме DCV измерьте напряжение непосредственно на клеммах питания контроллера (например, `Vin` и `GND`). Это напряжение должно быть очень близко к напряжению на выходе блока питания. Существенное падение напряжения (более 0.5-1В) может указывать на слишком длинный или тонкий кабель, либо на плохой обжим или затяжку контактов в клеммных колодках. Типичные точки отказа: Сработавшее УЗО или АВ: Часто указывает на короткое замыкание в линии или неисправность подключенного устройства. Неисправный блок питания: Не выдает напряжение, либо напряжение сильно "просажено" под нагрузкой. Плохой контакт: Ослабленные винты в клеммниках, окисленные контакты, некачественный обжим наконечников. --- Шаг 2: Проверка сетевого подключения (Ethernet) После того как мы убедились в стабильном питании, следующий шаг — проверка сетевой связности. Для нашего контроллера это критически важно, так как большинство взаимодействий (с MQTT-брокером, панелями управления, IP-шлюзами) происходит по сети Ethernet. Методика разделена на два уровня диагностики: 1. Диагностика физического уровня (L1): "Правило светодиодов" Это самый быстрый и простой способ проверки. На каждом Ethernet-порту (как на контроллере, так и на коммутаторе/роутере) есть два светодиодных индикатора: Link (Связь): Обычно горит постоянным зеленым светом. Если этот индикатор горит, значит, на физическом уровне установлено соединение с другим устройством. Если он не горит — проверяйте кабель (целостность, правильность обжима, достаточна ли длина), а также исправность портов на обоих устройствах. Activity (Активность): Обычно мигает желтым или оранжевым цветом. Мигание означает, что по данному соединению идет передача данных. Постоянное горение или отсутствие активности при работающей системе может указывать на проблемы. Процедура: Визуально осмотрите Ethernet-порт контроллера. Индикатор `Link` должен гореть. Визуально осмотрите соответствующий порт на коммутаторе/роутере, к которому подключен контроллер. Индикатор `Link` также должен гореть. Если `Link` не горит нигде: попробуйте переключить кабель в другой порт коммутатора. Если не помогло — замените патч-корд. 2. Диагностика сетевого уровня (L3): Базовые Linux-утилиты Если физическое соединение установлено (индикаторы `Link` горят), необходимо проверить, получает ли устройство IP-адрес и доступно ли оно в сети. Для этого нужно подключиться к консоли контроллера (через SSH или отладочный порт). Команда `ip a` (или `ip address show`) Эта команда показывает информацию обо всех сетевых интерфейсах в системе. Что делать: 1. Зайдите на контроллер по SSH. 2. Выполните команду `ip a`. 3. Найдите в выводе ваш Ethernet-интерфейс (обычно `eth0`).

bash

# Пример вывода команды ip a

2: eth0: mtu 1500 qdisc mq state UP group default qlen 1000

link/ether dc:a6:32:01:23:45 brd ff:ff:ff:ff:ff:ff

inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic eth0

valid_lft 86239sec preferred_lft 86239sec

inet6 fe80::dea6:32ff:fe01:2345/64 scope link

valid_lft forever preferred_lft forever

На что обратить внимание: * `state UP`: Интерфейс активен. Если `DOWN` — проблема с драйвером или конфигурацией. * `inet 192.168.1.100/24`: Это IP-адрес устройства. Если эта строчка отсутствует, значит, контроллер не получил IP-адрес от DHCP-сервера (роутера). Проверяйте настройки DHCP-сервера. Команда `ping` Это основная утилита для проверки доступности другого устройства (хоста) в сети. Что делать: 1. Проверка шлюза: C контроллера попробуйте "пропинговать" ваш роутер (шлюз по умолчанию, например `ping 192.168.1.1`). Это проверит, работает ли связь внутри локальной сети.

bash

# ping 192.168.1.1

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.852 ms

64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.915 ms

--- 192.168.1.1 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1001ms

        Успешный результат (`0% packet loss`) говорит о том, что связь с роутером есть.

    2.  Проверка внешнего ресурса: Попробуйте "пропинговать" надежный интернет-адрес, например, DNS-сервер Google (`ping 8.8.8.8`). Это проверит, есть ли у контроллера доступ в интернет.
    3.  Проверка с ПК: С вашего компьютера или ноутбука, подключенного к той же сети, попробуйте "пропинговать" IP-адрес контроллера (`ping 192.168.1.100`). Это подтвердит, что контроллер доступен с других устройств в сети.

    Типичные ошибки `ping`:
    *   `Destination Host Unreachable`: Маршрут к хосту неизвестен. Часто означает, что вы находитесь в разных подсетях или проблема с сетевой маской.
    *   `Request timeout`: Ответ от хоста не пришел за отведенное время. Может означать, что хост выключен, заблокирован файрволом, или существуют серьезные проблемы с сетью (потеря пакетов).

---

Практический пример: отладка недоступного KNX IP-интерфейса

Этот сценарий объединяет оба шага в реальной ситуации.

Симптом: В системе перестали работать все устройства, управляемые по шине KNX. Панели iRidium не могут управлять светом, а Node-RED не получает статусы от KNX-датчиков. KNX IP-интерфейс (шлюз) "не виден".

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

Шаг 1: Проверка питания

Питание самого KNX IP-интерфейса:
    *   Большинство IP-интерфейсов питаются либо от шины KNX, либо по PoE (Power over Ethernet), либо от отдельного блока питания 12/24В.
    *   Определяем тип питания. Если PoE — проверяем, что коммутатор поддерживает PoE и эта функция включена на порту. Если отдельный БП — используем мультиметр для проверки напряжения на выходе БП и на клеммах самого интерфейса, как описано выше.
Питание шины KNX:
    *   Сама шина KNX требует специального блока питания, выдающего стабилизированное напряжение ~30В DC.
    *   Находим в щите блок питания KNX. Мультиметром в режиме DCV проверяем напряжение на его выходных клеммах (обычно помечены как `+` и `-`, `red` и `black`). Напряжение должно быть в диапазоне 29-31В. Если напряжения нет, или оно значительно ниже — БП неисправен или сработала его внутренняя защита от перегрузки/КЗ.

> 💡 Подсказка: На многих KNX-устройствах есть светодиод, который загорается при нажатии на кнопку физической адресации. Это быстрый способ проверить, подается ли напряжение на шину, даже без мультиметра. Если при нажатии на кнопку на любом KNX-устройстве (например, акторе в щите) светодиод загорается, значит, питание на шине есть.

Шаг 2: Проверка сети

Физический уровень:
    *   Осматриваем порт Ethernet на KNX IP-интерфейсе. Горит ли индикатор `Link`?
    *   Осматриваем соответствующий порт на коммутаторе. Горит ли `Link`? Если нет — проблема в кабеле или портах.
Сетевой уровень:
    *   KNX IP-интерфейсы обычно имеют статический IP-адрес (например, `192.168.1.110`).
    *   Подключаемся по SSH к нашему контроллеру Wirenboard.
    *   Выполняем команду `ping 192.168.1.110`.
    *   Если пинг проходит успешно: Сетевая связь между контроллером и шлюзом есть. Проблема, скорее всего, выше — на уровне приложения (неправильный порт, ошибка в конфигурации драйвера `wb-knx` и т.д.).
    *   Если пинг не проходит: Сетевой связности нет. Возможные причины: неправильный IP-адрес/маска на шлюзе или контроллере, шлюз и контроллер в разных VLAN, неисправность IP-интерфейса.

Шаг 2.5: Анализ логов (забегая вперед)

Если шаги 1 и 2 пройдены успешно, можно сделать быстрый взгляд на системные логи контроллера, чтобы найти подсказки. Например, служба, работающая с KNX, может писать ошибки подключения в системный журнал.

bash

# Просмотр последних сообщений в системном логе с фильтрацией по ключевому слову 'knx'

tail -f /var/log/messages | grep wb-knx

Эта команда в реальном времени покажет строки из лога, содержащие `wb-knx`, что может немедленно выявить ошибки вида `connection refused` или `timeout`.

---

Резюме и следующие шаги

В этом уроке мы заложили фундамент системной диагностики, освоив два первых и самых важных шага любого runbook'а: проверку питания и сети.

Ключевые выводы:
Всегда начинайте диагностику "снизу вверх": от физического уровня (электричество, кабели) к логическому.
Используйте простой, но эффективный инструментарий: мультиметр для проверки питания, индикаторы `Link`/`Activity` и команду `ping` для проверки сети.
Методично двигайтесь от источника к потребителю (от щита к устройству), чтобы не пропустить точку отказа.
Документируйте результаты каждого шага. "Питание на БП есть, на контроллере нет" или "Пинг до роутера есть, до IP-камеры нет" — это уже половина диагноза.

Этот подход позволяет быстро отсечь самые распространенные проблемы и сэкономить массу времени на объекте. Только убедившись, что питание и сеть в полном порядке, можно с уверенностью переходить к более сложным уровням.

Что дальше:
В следующем уроке мы продолжим наш мини-ранбук и разберем следующие шаги:
Шаг 3: Диагностика шин данных (Modbus RTU, 1-Wire, DALI)
Шаг 4: Базовый анализ логики (проверка потоков в Node-RED)