Posts on Малая автоматизация

Отвяжи свой термостат. Свой — на ESP32 и без облака

Wed, 11 Nov 2026 00:00:00 +0000

Умный термостат у большинства производителей — это не устройство, а абонемент: железо ты купил один раз, а доступ к облаку, расписанию и приложению продают помесячно. Смена цены, отключение сервиса, обновление, которое ломает интеграцию — и термостат, который работал пять лет, превращается в кирпич с дисплеем.

Функция, которая нужна по сути, простая: держать температуру и дать мне ей управлять. Ничего больше.

Что нужно по сути

ESP32 — контроллер с Wi-Fi. Реле — чтобы включать и выключать нагрузку. Датчик температуры — чтобы знать, что происходит. Всё.

Никаких подписок, никаких облаков, никаких производителей. Устройство работает, пока работает локальная сеть и есть питание.

Почему «свой» — это не про экономию

Про подписку можно возразить: «дешёвые термостаты с облаком и так стоят 2-3 тысячи». И да, сам железный корпус стоит недорого.

Но дело не в цене устройства, а в том, что ты перестаёшь зависеть от чужого решения:

Сервис закрыли или перенёс — у тебя дома не отключилось отопление
Приложение перестало поддерживать твой телефон или ОС — устройство не потеряло функций
Владелец сервиса решил, что твои данные нужны ему больше, чем тебе — у тебя их вообще не было
Через 5 лет захотел добавить датчик — и не можешь, потому что прошивка закрыта

Vendor-lock — это не абстрактная проблема. Это когда ты не можешь починить вещь в своём доме, потому что дом зависит не от дома, а от чужого сервера.

Честная часть: почему это не так просто

Свой термостат — это не «купил ESP32 и всё работает». Реальность такая:

Железо — самая простая часть. Модуль ESP32 стоит как пара пачек чая, реле и датчик температуры — ещё меньше. Собрать на макетке — вечер.

Сложнее — логика и безопасность. Термостат управляет нагрузкой, а нагрузка бывает опасной. Газовый котёл, тёплый пол, водяной насос — здесь ошибка в логике или в заземлении бьёт по кошельку или по безопасности. Поэтому граница между «следить» и «вмешиваться» проходит по принципу: мониторинг — безопасно, управление — только после отдельной проработки.

Плюс отсутствие поддержки. Своё устройство — это твоя ответственность. Если через год оно перестанет работать, чинить будешь ты, а не сервис поддержки с бесплатными обновлениями.

И последнее: гайд по калибровке, подбор датчика под конкретную задачу — это отдельная работа. Готового красивого приложения не будет. Будет веб-страница или дашборд, или вообще только вебхук в систему уведомлений.

Что на самом деле даёт «свой» термостат

Не «дешевле». А именно:

Предсказуемость. Устройство работает по правилам, которые ты видишь и можешь изменить.
Отсутствие подписки как обязательного условия. Базовые функции не перестают работать, потому что кто-то закрыл SaaS.
Интеграция с тем, что уже есть. Тот же ESP32, тот же Gotify-канал уведомлений, та же вики с логом. Это часть общей системы, а не отдельный брендированный прибор из чужой экосистемы.

Итог

Термостат — это не сложная вещь. Это «включить-выключить» плюс «знать, что происходит». Вся сложность, которую добавляют производители, — это облако, подписка, приложение и экосистема вокруг простой задачи.

Вопрос только в том, готов ли ты взять эту простоту на себя.

А у вас термостат с подпиской или свой? И что вас в нём бесит больше — цена, приложение или зависимость от чужого сервера?

20 источников уведомлений. Один Gotify вместо двадцати Telegram-ботов

Tue, 10 Nov 2026 00:00:00 +0000

Двадцать отдельных Telegram-ботов — это двадцать мест, где нужно искать уведомление, и двадцать точек, где интеграция может сломаться. Gotify превращает это в один центр: каждый источник шлёт в один и тот же адрес, а ты читаешь всё в одном приложении.

Проблема

Каждый новый источник уведомлений — это новый бот и новый канал в телефоне. Деплой — один канал, дедлайны из Obsidian — второй, алерты с серверов — третий, домашние датчики — четвёртый. Источников становится двадцать, и к каждому отдельному уведомлению надо возвращаться отдельно.

Это не «20 уведомлений». Это 20 мест для тревоги. Телефон превращается в ленту, где важное событие тонет между «сборка прошла» и «напоминание из заметки». Цена каждого нового источника растёт не линейно, а потому что добавляется ещё одно место, где нужно проверять.

Решение

Один self-hosted Gotify. Любой источник — деплой, дедлайн из Obsidian, алерт, скрипт — шлёт в один и тот же endpoint. Ты подписан на один канал и видишь всё в одном приложении.

Настройка источника сводится к одной строке: URL приложения плюс токен. Не надо нигде регистрировать бота, нигде просить токен у Telegram, нигде разбираться, как этот конкретный бот называет свои кнопки.

Что это даёт по сути

Главный эффект — не «ещё один бот», а разделение источника и канала доставки.

Источник не знает, куда ты читаешь. Он просто умеет отправить сообщение по HTTP. А канал доставки — отдельный слой, который можно переключить целиком, не трогая ни один источник.

Это и есть то, что превращает набор интеграций в систему. Двадцать отправляющих точек, одна точка приёма. Если завтра захочется другой клиент — меняется приёмник, а не все источники.

Честная часть

Gotify не решает задачу «как настроить 20 источников». Он решает задачу «куда они все шлют».

Второе после первого раза становится дешёвым. Первое — всегда самое дорогое. Настройка каждого нового источника требует разобраться, как именно этот источник умеет отправлять уведомления, и это отдельная работа на каждый источник.

И ещё: self-hosted значит, что сервис живёт на твоём железе. Его нужно обслуживать — обновлять, следить за диском, поднимать после перезагрузки. Это ещё одно дело, которое «работает без меня» ровно до первого раза, когда контейнер не поднялся. Gotify не отменяет DevOps — он просто складывает всё в одно место.

Связка с остальным

Уведомления — не отдельная сущность, а часть общей системы: вики, трекер, домашние датчики. Один канал доставки на всё.

Когда источники перестают быть отдельными ботами, появляется место, где видно их все сразу. А когда видно все сразу, можно начать ими управлять.

Итог

Двадцать ботов → один Gotify. Сколько у тебя источников, которые шлют уведомления? Напиши в комментариях — интересно, кто дошёл до этого раньше.

Portfolio Performance удалён. Теперь трекер мой, и я решаю, как считать

Fri, 06 Nov 2026 00:00:00 +0000

Portfolio Performance я ставил, импортировал в него сделки и бросил. Две причины, и обе технические: он плохо работает с российскими брокерами, а свою логику в него выразить нельзя — только подстраиваться под чужую модель.

Где ломается готовое решение

Дело не в том, что инструмент плохой. Он закрывает задачу «посчитать портфель». Моя задача звучит иначе: посчитать портфель по моим правилам, с моими формулами и моими российскими брокерами. Разница в этом предложении — и она дороже, чем кажется.

Вот цепочка, которая в итоге выкинула готовый продукт:

ZenMoney не умеет учитывать акции и облигации с переоценкой. Там удобно считать расходы и доходы, но бумаги живут по другим правилам.
Tinkoff не отдаёт CSV. Данные по сделкам и ценам доступны только через API.
Универсальный импортёр в такой схеме упирается в оба ограничения сразу.

Дальше вариантов два: подстраивать задачу под инструмент или написать свой код под задачу. Я выбрал второе, потому что подстройка обходится дороже — и в скорости, и в том, что результат всё равно пришлось бы пересчитывать руками.

Три источника, у каждого своя роль

Прежде чем писать код, я разделил ответственность. Это важнее, чем сам код.

Инструмент	Что делает
ZenMoney	расходы, доходы, бюджеты, цели
Свой трекер (Python → markdown)	портфель, доли, ребаланс, формулы
Tinkoff API	источник правды по сделкам и ценам

Ни один инструмент тут не делает всё. ZenMoney остаётся источником транзакций по деньгам, Tinkoff — источником правды по бумагам, а мой скрипт занимается только тем, что между ними: считает доли по правилам и раскладывает результат в markdown.

Третье — ключевое. Скрипт не хранит состояние. Он читает API, считает и кладёт результат в вики обычной markdown-страницей. Рядом лежат политика, цели и решения, на основе которых всё это посчитано. Отчёт и его основание живут в одном месте.

Что формулы умеют, а чужой инструмент — нет

У меня есть инвестиционный план, и в нём доли считаются по формуле, а не заданы числами:

резервный_фонд = 10%
генерация_фонд = 5%
акций_роста_фонд = 10%
индексный_фонд = 0%

дивидендный_фонд = 100 − резервный − генерация − акций_роста − индексный
 = 75%

ядро_дивидендного = (100 − возраст) × доля_дивидендного / 100

Последняя строка — то, ради чего всё затевалось. Доля дивидендного фонда зависит от возраста: ядро пересчитывается каждый год, и внутри ядра активная и пассивная части делятся пополам.

Универсальный трекер про такое не знает. Он умеет показывать структуру портфеля, но не умеет взять мою формулу и применить её к моим же данным. Правила отбора фондов (ограничение на долю одного актива, требуемую доходность относительно ключевой ставки, распределение ядра по типам облигаций) живут в плане, и в чужой интерфейс это не влезает.

До и после

Пока трекер был в разработке, сверка портфеля выглядела так:

4 шага по 5 минут, около 15 минут в неделю
вклады обновлялись вручную
акции и облигации не сверялись вообще — нечем было

Сейчас:

4 шага по 1–2 минуты, около 5 минут в неделю
скрипт запускается, читает данные брокера и пишет markdown
отклонение долей от плана считается само
если отклонение больше 5% — приходит алерт в задачник по ребалансу

Разница в минутах — не главное. Главное, что акции перестали быть слепой зоной. Полгода я знал, что по акциям и облигациям не сверяюсь, и это молчало до момента, когда перекос стал бы дорогим.

Отдельно: в трекер встроена синхронизация налогов, купонов и дивидендов с ZenMoney. Операции появляются в учёте сами, вручную их вносить не нужно. Весь этот кусок я собрал за один день — задача была конечной и проверяемой, и это единственное, что уберегло её от бесконечной полировки.

Почему всё это стоит в вики, а не в приложении

Отдельное приложение для учёта портфеля — это ещё один инструмент, который требует внимания. У него свой интерфейс, свои обновления, свои поломки и своя логика, которую надо сверять с логикой в плане.

Markdown-страница в базе знаний работает иначе. Данные приезжают скриптом, отчёт лежит рядом с политикой и целями, и в тот же файл я пишу записи из дневника. Ничего не нужно открывать, обновлять и синхронизировать — оно просто лежит и читается.

Минус честно: это не интерфейс для повседневного использования. Это отчёт, который смотришь раз в неделю. Мне этого хватает, потому что рутина всё равно уходит в фон, а не в глаза.

Вывод

Разница между «решить задачу» и «решить мою задачу» стоила мне одного готового инструмента и пары дней работы. Если ваш инструмент закрывает 90% задачи, это повод им пользоваться. Если оставшиеся 10% — это вся суть, дешевле написать своё, чем подстраиваться.

Код трекера открытый. Правила, по которым он считает, лежат рядом с ним же.

Мониторинг газового котла на ESP32: как узнать, что он работает, когда тебя нет дома

Thu, 05 Nov 2026 00:00:00 +0000

Когда зимой уезжаешь в отпуск или на дачу, остаётся тревожный вопрос: газовый котёл сейчас работает или нет? Даже если система включена, ты не получаешь подтверждения, что отопление действительно поддерживается, а поломку или сбой узнаёшь только по возвращении. Для частного дома нужен простой локальный мониторинг, который сообщит об изменении состояния котла и не зависит от облачного сервиса.

Что измеряем и как уведомляем

Схема состоит из ESP32, датчика давления и реле. Датчик давления позволяет связать состояние газового котла с измеряемой величиной, а ESP32 анализирует показания и формирует событие. Реле служит элементом управления или сигнализации: с его помощью можно переключать исполнительное устройство, которое сообщит о сбросе.

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

Для алерта пока не выбран канал доставки: Telegram заблокирован, а варианты email и push ещё не определены. Канал доставки следует выбрать до сборки, иначе устройство сможет обнаружить событие локально, но ты не получишь уведомление во время отъезда.

Порог и логика уведомлений

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

Рабочий диапазон: давление находится в пределах, при которых котёл считается работающим нормально.
Ниже рабочего диапазона: состояние котла изменилось, и требуется уведомление.
Выше рабочего диапазона: также нужно уведомление, если выбранный датчик позволяет достоверно фиксировать такие значения.
Ошибка датчика: обрыв, отсутствие показаний или другая некорректная величина не должна выглядеть как штатная работа котла. Вместо этого событие нужно маркировать как неисправность самого канала измерения.

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

Выбор датчика и подключение

Конкретная модель датчика давления пока не выбрана — это первое, что нужно сделать перед покупкой компонентов и составлением wiring. Вместе с моделью уточни диапазон измерения, тип выходного сигнала, требуемое питание и допустимое разрешение. От этих данных зависит, можно ли подключить датчик непосредственно к ESP32 или потребуется преобразование сигнала.

Также нужно проверить, как именно датчик получает давление от контура котла. Не стоит устанавливать его методом проб: способ врезки, расположение и конструктивная совместимость должны соответствовать выбранному устройству и схеме котла.

Для реле также нужны конкретные параметры: ток катушки, напряжение питания и тип нагрузки. Если реле только переключает цепь индикации или другого исполнительного устройства, схема должна явно показывать этот отдельный контур и защиту выводов ESP32.

Программный каркас ESP32

Ниже показан программный каркас локального мониторинга. Он читает аналоговый сигнал датчика, сравнивает его с заданным диапазоном и управляет реле. Поскольку модель датчика и порог ещё не выбраны, значение PRESSURE_MIN, PRESSURE_MAX, пин датчика, пин реле и напряжение питания перед использованием нужно заменить на проверенные.

// ESP32: локальный мониторинг давления газового котла.

#include <Arduino.h>

constexpr int SENSOR_PIN = 34; // Аналоговый вход ESP32.
constexpr int RELAY_PIN = 27; // Управляющий вывод реле.
constexpr uint32_t SAMPLE_INTERVAL_MS = 5000;

// Заменить на диапазон, проверенный для выбранной модели датчика
// и условий эксплуатации котла.
constexpr int PRESSURE_MIN = 0;
constexpr int PRESSURE_MAX = 0;

enum class BoilerState {
 Unknown,
 Normal,
 Low,
 High,
 SensorError
};

BoilerState previousState = BoilerState::Unknown;

int readRawPressure() {
 int value = analogRead(SENSOR_PIN);

 if (value < 0 || value > 4095) {
 return -1;
 }

 return value;
}

BoilerState classifyPressure(int value) {
 if (value < 0) {
 return BoilerState::SensorError;
 }

 if (value < PRESSURE_MIN) {
 return BoilerState::Low;
 }

 if (value > PRESSURE_MAX) {
 return BoilerState::High;
 }

 return BoilerState::Normal;
}

void applyRelay(BoilerState state) {
 // Зафиксировать активное состояние реле и схему подключения.
 // Управляющая логика должна быть инвертирована, если используется
 // модуль реле с низкоуровневым включением.
 bool alertActive = (state == BoilerState::Low ||
 state == BoilerState::High ||
 state == BoilerState::SensorError);

 digitalWrite(RELAY_PIN, alertActive ? HIGH : LOW);
}

void setup() {
 Serial.begin(115200);

 pinMode(RELAY_PIN, OUTPUT);
 digitalWrite(RELAY_PIN, LOW);

 // Перед использованием выбор входного канала уточнить
 // по конкретной модели датчика и его выходному сигналу.
 analogReadResolution(12);

 Serial.println("Мониторинг давления котла запущен");
}

void loop() {
 int rawValue = readRawPressure();
 BoilerState currentState = classifyPressure(rawValue);

 if (currentState != previousState) {
 Serial.print("Состояние изменилось: ");
 Serial.print(static_cast<int>(currentState));
 Serial.print(", raw=");
 Serial.println(rawValue);

 // Здесь вызывается выбранный канал уведомлений.
 // Реализовать отправку только для выбранного канала:
 // email, push или другой доступный вариант.

 previousState = currentState;
 }

 applyRelay(currentState);
 delay(SAMPLE_INTERVAL_MS);
}

Логика заложена на переходы между состояниями, а не на оповещение при каждом чтении датчика. Ошибка измерения обрабатывается отдельно и не должна маскироваться под нормальную работу котла. При этом место вызова канала уведомлений остаётся незаполненным: его нужно реализовать после выбора доступного способа доставки.

Что ещё нужно проверить перед использованием

Wiring нельзя считать готовым, пока не указаны конкретные компоненты. После выбора модели нужно записать точное подключение: питание датчика, его выход к пин ESP32, общую землю, питание катушки реле, пин управления реле и цепь нагрузки. Для реле с отдельным источником нельзя подавать ток катушки через вывод ESP32.

Также требуется проверить соответствие параметров датчика и выбранного канала уведомлений исходной задумке. Если датчик или линия связи оборвётся, система должна сообщить об ошибке измерения, а не делать вид, что котёл исправно отапливает дом.

Питание и безопасность

Питание и безопасность здесь нельзя оставить на потом. Из контекента не зафиксированы ток потребления ESP32, ток катушки реле и тип источника питания, поэтому перед сборкой нужно проверить эти параметры по datasheet конкретных компонентов.

Нужно определить, будет ли вся схема питаться от USB, от отдельного блока питания или от комбинации источников. Если реле управляет нагрузкой, которой нельзя давать питание непосредственно с вывода ESP32, ему нужен отдельный источник. При этом общую землю ESP32 и источника реле следует соединить, а выводы микроконтроллера — защитить от обратного напряжения и бросков тока.

Поведение при сбоях и ограничения системы

При пропадании питания логичное поведение — прекратить обновление состояния и отметить отсутствие связи с устройством. Возможность резервного питания, его тип и время автономной работы в контексте не заданы, поэтому их нужно определить отдельно, если мониторинг должен пережить кратковременное отключение сети.

Не стоит подключать цепь управления котла параллельно его штатной автоматике без проверки схемы. Эта сборка задумана как наблюдение и оповещение; допустимость любого воздействия на управляющие цепи котла требует отдельного подтверждения.

Вывод / TL;DR

Локальный мониторинг на ESP32, датчике давления и реле помогает узнать об изменении состояния газового котла, пока тебя нет дома, без зависимости от облака. Перед сборкой нужно выбрать датчик и канал уведомлений, определить рабочий диапазон, зафиксировать проверенную схему питания и отдельно проверить безопасность подключения к контуру котла.