Архив рубрики: Системное администрирование

Home Assistant, уведомления и логика автоматизаций

Еще один баг, на этот раз со стороны Home Assistant. В последнее время решил хоть для чего-то начать использовать купленный на Али пару лет назад планшет Cubot TAB 20. Накатил туда Android-приложение Home Assistant, поставил его вместо ланчера (удобно, кстати, сделали – такой себе kiosk-mode из коробки), стоит теперь постоянно включенный. Для нескольких существующих автоматизаций решил сделать уведомления – пусть планшет подает звук, если кто-то звонит в ворота или если закончилась стирка. И поначалу вроде даже работало, но…

Сегодня заметил, что логика “звонка в ворота” сломана. Стоит сказать, что у меня на звонок стоит уведомление в джаббер, а дальше идет минутная пауза – т.е., не важно, как часто гость жмет кнопку, сообщения я буду получать лишь раз в минуту. Сейчас между сообщением в jabber и паузой добавилось еще уведомление на планшет. И – пауза перестала работать. При этом у меня на планшете нет никаких уведомлений, зато сообщения в джаббер могут идти как угодно часто. При попытке запуска уведомления на планшет вручную (в редакторе автоматизации) ничего не происходит. В другом случае (в уведомлении про стирку) получил сообщение, что устройство не подключено к локальному пуш-сервису (или как-то так). Так или иначе, проблема с одним “блоком” в автоматизации приводила к ее “вылету” и до паузы дело просто не доходило – появлялась возможность повторного запуска процесса целиком.

HA у меня не самый новый – 2024-го года, может в более свежем что-то и пофиксили, но проверить пока не могу.

esphome 2025.10.0 ломает связь с HA

Не было печали – апдейтов накачали.

Поставил свежий esphome – при прошивке девайсов (в моем случае на базе esp8266) при подключении к Home Assistant получаем

[D][api:160]: Accept 192.168.1.111
[D][api.connection:1383]: Home Assistant (192.168.1.111) connected
[W][api.connection:1880]: Home Assistant (192.168.1.111): Reading failed CONNECTION_CLOSED errno=11

Даже если удалить / добавить девайс со стороны HA – не помогает. Сам девайс видится (передобавить его можно), но при этом список объектов не передается. При этом в веб-интерфейсе устройства все в порядке.

Решается откатом на прошлую версию и прошивкой девайса с этой версии:

pip install esphome==2025.9.3

Со стороны HA ничего менять и передобавлять не надо.

Продолжаем наблюдение.

lm-sensors и Asrock A520M-ITX/ac

В последние несколько дней навожу порядки на “большом” домашнем сервере:

  • Обновил domU с сервером статистики. На самом деле – раскатал новую систему и мигрировал данные, так как пришлось бы последовательно апгрейдить Debian 9 -> Debian 13. Реально, но в чистовой установке будет меньше мусора, да и Nagios за это время сменил мажорную версию и простого апдейта не получилось бы.
  • После чего подобавлял кое-где munin-node и мониторинг хостов в Nagios’е: наконец-то убрал заглушку “return-ok” в мониторинге хоста и теперь карта красиво подсвечивает неработающие “ветки”, а также получаю меньше писем, если отвалился корневой узел.

Глаз зацепился в том числе и за подсвеченный красным раздел sensors в munin’е. Честно говоря, никогда не обращал внимания на ALERT’ы в выводе sensors, что-то показывает – и ладно.

Во-первых, поисключал явно нерабочее. Помогла эта ссылка. Дальше – больше: в ряде сенсоров (прежде всего – напряжения) были не прописаны минимальные и максимальные значения (либо было что-то неадекватное) – например, даже при корректном значении измерителя линии 3.3В в минимальных и максимальных значениях стоял ноль и датчик выдавал ALERT. В итоге чуть расширил свой кастомный конфиг для lm-sensors/etc/sensors.d/local.conf. В целом, синтаксис оказался достаточно простым: описываем секцию, обозначая чип или маской, или точным именем, дальше описываем то, что хотим сделать с опциями отдельных сенсоров, которые можно посмотреть по sensors -u.

/etc/sensors.d/local.conf

# https://superuser.com/questions/1828051/how-to-exclude-sensors-from-output
chip "nct6792-*"
        ignore  temp1
        ignore  temp4
        ignore  temp5
        ignore  temp6
        ignore  temp8
        ignore  temp9
        ignore  temp10
        ignore  in1
        ignore  in4
        ignore  in5
        ignore  in14

        set temp3_max 75
        set temp3_max_hyst 70


# +/- 5% для линий, которые на 3,3В
        set in2_min 3.3 * 0.95
        set in2_max 3.3 * 1.05
        set in3_min 3.3 * 0.95
        set in3_max 3.3 * 1.05
        set in7_min 3.3 * 0.95
        set in7_max 3.3 * 1.05
        set in8_min 3.3 * 0.95
        set in8_max 3.3 * 1.05

# Что-то непонятное. Задал диапазон или 0-1В, или 1-2В.
        set in9_min 1
        set in9_max 2
        set in12_min 1
        set in12_max 2
        set in13_min 1
        set in13_max 2
        set in10_min 0
        set in10_max 1
        set in11_min 0
        set in11_max 1
        set in6_min 0
        set in6_max 1


# Пара SSD. Адрес может смениться, если менять слоты
chip "nvme-pci-0b00"
        ignore  temp3
        set temp1_min 0

chip "nvme-pci-0c00"
        set temp1_min 0
        set temp2_max 100
        set temp2_min 0
        set temp3_max 100
        set temp3_min 0

[свернуть]

В тех сенсорах, в которых что-то показывалось, но непонятно, к чему оно относится (если они вообще подключены на плате) – просто задал широкий диапазон значений, чтобы не ругалось.

Еще одна полезная команда – sensors -s от рута, чтобы применить изменения в конфиге.

ping и код завершения процесса

Давно уже использую в скрипте, рулящем маршрутами на несколько ISP, проверку доступности канала через ping несколькими пакетами на 8.8.8.8. Основной канал частенько переподключался без видимых на то причин. При этом пускал отдельно свой ping – там потерь пакетов вообще не было. Дошли руки подебажить. Если из 5 проверочных пингов пролазят только 2 – то ping -q отдает false. При 3 нормально. Вероятно, граница проходит по половине заданного числа попыток. В man’е вроде ничего на этот счет.

Переделал логику; теперь канал считается мертвым при полной потере пакетов на интерфейсе. Пока полет нормальный.

Косяк парсинга у apt-mirror

А может и не совсем косяк, но надо быть внимательнее.

Решил миррорить на NAS’е некоторые зеркала для Debian. В какой-то момент закинул в mirror.list строки вида

deb https://deb.debian.org/debian/ trixie main contrib non-free # Debian 13

При запуске утилита ломанулась качать вообще все – как для других архитектур, так и html’ки; каталог skel раздулся совсем уж неприлично. Не сразу нашел, что виной символ # – тот не обрабатывался как комментарий, а как какой-то wildcard. Убрал “хвосты” – все наладилось.

Разобрал Packard Bell 3500 и вторая жизнь для Cubieboard-2

…а также Armbian, OpenMediaVault и все-все-все.

Не сторонник пускать работающее устройство на разборку, но, блин…

Уже весьма давно приобрел “NAS за 10$” – Packard Bell NetStore 3500, о чем когда-то писал еще на Juick. Какое-то время он у меня служил в штатном виде, с каким-то старым HDD на 3.5 дюйма – складывал на него бэкапы, под что даже написал в свое время скрипт (см. внизу). Из программных интерфейсов на NAS’е – только FTP и SMB; пользовался только FTP, как идеологически более верным, да и скорость он подразумевал бОльшую. Правда, скорость эта была даже в таком варианте на уровне 3,5 МБ/сек, но для заливки бэкапов раз в сутки хватало.

Читать далее Разобрал Packard Bell 3500 и вторая жизнь для Cubieboard-2

Дешевый хостинг в US

Попалось на ЛОРе: https://my.racknerd.com/cart.php?a=add&pid=879&aff=4692 (реф). Навигация не особо внятная, но вроде нашел, как на него выйти: my account – cart – слева разделы. Или там же, Store – BF2024.

https://my.racknerd.com/index.php?rp=/store/black-friday-2024

В общем, VPS за 11$ в год – вполне интересно.

ETS, PTS – пара тестовых jabber’ов с хостингом дома

После “Апдейтов и фиксов на домашнем сервере” решил, с одной стороны, альтернативно подойти к оставшейся со времен переезда на VPS копии ejabberd’а – а там у меня еще ejabberd 2.x и Debian 7, который я использовал для написания и отладки RSS-транспорта и других проектов (фактически, тут от сервера требовалось просто его наличие, чтобы к нему подключался транспорт. Ну и держать какой-то тестовый аккаунт, где со всем этим работать). С другой стороны, раз уж развивать эту тему, то иметь и тестовый сервер на базе Prosody, так как купленная с год назад виртуалка и домен mychat.name для написания руководства на JabberWorld уже закончились, а пощупать Prosody все же иногда полезно. А там может и Snikket под боком иметь…

Так вот. Развернуть очередную пару виртуалок несложно, ресурсов на обновленном сервере хватает под все. Но делать – так делать: захотелось нормально выпустить имеющиеся серверы в мир с доступом к ним снаружи и нормальным общением между собой. Одна незадача. Даже две: внешнего адреса дома у меня нет (а IPv6 все так же не предоставляется), а внешний адрес VPS’ки уже занят “боевым” сервером, обслуживающим JabberWorld и остальные домены.

И вот решил попробовать разрулить целиком все через SRV-записи. В том числе телефонию!

TL;DR: да, все удалось! Софт вполне корректно работает через SRV, в том числе есть связь с jabber.ru, где на данный момент работает ejabberd 3.x (а ему уже больше 10 лет!).

Читать далее ETS, PTS – пара тестовых jabber’ов с хостингом дома

Nextcloud, завис апдейт до 30-й версии

Сабж. Обновлялся с 29-какой-то-там, в итоге повисло на “копирование файлов”. По кнопке “повторить обновление” ничего не происходило, в логах ругань на то, что я теперь не авторизован. Показало какой-то код, который (из консоли) должен был дать ключи для авторизации, но от ключей тоже толку не было. Веб-админка недоступна – “Сервер в процессе обновления”. Решилось выполнением команды обновления из консоли:

php updater/updater.phar

Апдейты и фиксы на домашнем сервере

Весь день занимался доработками / фиксами вокруг темы домашнего сервера и хостинга – конспектирую, пока не забылось.

Читать далее Апдейты и фиксы на домашнем сервере