Идеи на будущее¶

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

Присутствие машины по локальному датчику вместо GPS¶

Проблема. GPS регулярно «теряет» стоящую машину: координаты уплывают на пару сотен метров, и трекер сообщает not_home, хотя машина никуда не уезжала. Сейчас это лечится двумя способами — идущий ток подтверждает присутствие для уже начатой сессии, а старт перепроверяется на каждом пересчёте всю сессию. Но остаётся окно, когда обоих механизмов мало: если трекер врёт непрерывно с самого начала окна, зарядка так и не начнётся.

Идея. Положить в машину дешёвый Zigbee-датчик (например, температуры) и считать машину дома, пока датчик виден Zigbee-сети: её радиус как раз совпадает с «машина стоит у дома». В отличие от GPS такой признак не плавает — устройство либо на связи, либо нет.

Как это может выглядеть. Новый необязательный вход «Датчик присутствия машины» (binary_sensor или любая сущность с last_seen), который участвует в проверке зоны наравне с трекером: машина считается дома, если её видит трекер или локальный датчик. Логика уже подготовлена — есть переменная physically_present, к которой такой источник добавляется естественно.

Что надо продумать до реализации. - Как отличить «датчик пропал, потому что машина уехала» от «датчик пропал, потому что села батарейка». Вероятно, по возрасту последнего сообщения: свежее молчание — уехала, застарелое — сдох датчик. - Zigbee-сеть может добивать до соседнего двора, и тогда признак начнёт врать в другую сторону. Проверяется только на месте. - Батарейка в датчике садится за месяцы, и отказ будет тихим. Нужен собственный контроль свежести, иначе появится новый источник тихих сюрпризов.

Автоопределение недобора тока станцией¶

Проблема. Станция систематически отдаёт меньше запрошенного. По двум реальным ночам величина измерена точно и оказалась постоянной в амперах, а не в процентах:

Уставка	Факт	Разрыв
16 А	14.69 А	1.31 А
19 А	17.66 А	1.33 А

Разброс по всем пересчётам — сотые доли. Это не потери в проводах (росли бы с током) и не предел машины (она брала 17.66 А), а смещение самой станции. В долях разрыв тем заметнее, чем меньше ток: 8% при 16 А, но 22% при 6 А.

Замеры третьей и четвёртой ночей подтвердили это на более широком диапазоне (только установившийся режим, возраст уставки больше паузы между командами):

Уставка	11 А	13 А	18 А	22 А	25 А	28 А
Недодача	1.09	1.35	1.54	1.43	1.42	1.33
В долях	9.9%	10.4%	8.5%	6.5%	5.7%	4.7%

То есть форма компенсации не совпадает с формой дефекта: множитель в 10% точен около 13 А, но вдвое перебирает на 28 А и недобирает на малых токах. Это осознанный размен (см. ниже), а не недосмотр.

Величина измеряется и показывается (недодача_а в diag, строка в журнале), а компенсация с версии 1.4.0 задаётся вручную — параметром «Запас по току», множителем к расчёту.

Идея. Измерять разрыв автоматически, накапливать за прошлые сессии и подставлять поправку самому, без участия человека.

Почему не сделано автоматически. Три причины.

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

Вторая — устойчивость: если ток ограничивает не станция, а машина (сел бортовой зарядник, мороз, балансировка в конце заряда), автоматическая компенсация даёт положительную обратную связь. Расчёт показывает разгон 12 → 17 → 20.7 → 21.9 А при машине, берущей ровно 10 — до потолка, без единого лишнего ампера в батарее. Ручной запас этой петли не создаёт: он постоянен и не зависит от факта.

Третья выяснилась на третьей ночи — измерению нельзя доверять напрямую. Сенсор тока станции обновляется с задержкой: он стоял на 11.669 А целых семь минут, пока мощность росла 2592 → 5683 Вт (реальный ток по P/U доходил до 25.6 А). Автоматика, подставляющая измеренную «недодачу» в расчёт, приняла бы эти 16 А за истину. Сейчас величина считается только на установившемся режиме, но для автоподстройки этого мало.

Работоспособный вариант должен компенсировать не ток, а энергию, причём до превращения её в ток, и иметь собственное хранилище (input_number, который пользователю пришлось бы заводить руками). Через КПД задача не решается: доля непостоянна — 92% при 16 А, 78% при 6 А, 95% при 28 А.

Учёт кривой заряда на последних процентах¶

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

Что показали измерения. На реальной машине (Voyah Dream) излома на 80% нет вовсе. Скорость держалась ровно 6.00 %/час семь часов подряд, с 55% до 97%, без единого отклонения. Замедление началось только на 97%:

Участок	Скорость
55 → 97%	6.00 %/час
97 → 99%	4.00 %/час
99 → 100%	ток упал 14.7 → 9.6 А, ~30 минут

То есть ошибка линейной модели для этой машины — около 15–20 минут на последнем проценте, что уже покрывается параметром «Резерв времени».

Идея. Нелинейный план: закладывать замедление после порога, который пользователь может настроить под свою машину.

Почему не сделано. Резерв справляется, а выигрыш измерим и невелик. Куда дороже обходились недодача тока (около 40 минут за сессию) и потерянные команды станции — то и другое исправлено в 1.4.0. Точная кривая сильно различается между моделями, а ошибиться в ней хуже, чем не иметь её вовсе.

Раздача мощности между двумя машинами¶

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

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

Учёт тарифа и цен на электричество¶

Идея. Вместо фиксированного окна выбирать самые дешёвые часы по данным тарифного сенсора (Nord Pool, «Мой умный дом» и аналоги).

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

Подавление повторных уведомлений о проблемах с данными¶

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

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

Честный признак «как давно длится проблема» требует памяти между прогонами, а блюпринт её не имеет. Варианты — вспомогательный input_datetime, который пользователю пришлось бы создавать руками, или перенос логики в интеграцию. Пока рекомендуется гасить повторы в самом действии уведомления (одинаковый tag в notify заменяет предыдущее сообщение); это описано в примерах настройки.

Фильтр сенсора «время с последнего выхода на связь»¶

Проблема. Вход «Сенсор времени с последнего выхода машины на связь» отфильтрован по device_class: duration. У Voyah сенсор именно такой (last_ping, единицы s), поэтому сейчас всё работает. Но у части интеграций этот показатель выглядит иначе: Tesla, Renault и другие отдают дату последнего контакта (device_class: timestamp), а некоторые — голое число секунд вообще без класса. У таких пользователей сенсор просто не появится в выпадающем списке, поле останется пустым, и вместе с ним отключится один из трёх механизмов проверки достоверности данных о заряде — молча.

Идея. Снять device_class из фильтра, оставив domain: sensor, либо разрешить оба класса списком [duration, timestamp].

Почему не сделано сейчас. Снятие фильтра — не бесплатное решение: тогда в списке окажутся все сенсоры подряд, и легко выбрать тот, значение которого код не поймёт. Шаблон soc_fresh умеет работать только с числом секунд; у нечислового значения он идёт по ветке not is_number(...) и возвращает true. Проверено на дате 2026-08-02T22:00:00+00:00: soc_fresh=true, soc_problem='none' — данные признаны свежими, хотя машина не выходила на связь трое суток. Это тихая противоположность задуманному, и она хуже пустого поля: пустое поле хотя бы честно отключает проверку.

Что надо сделать вместе с этим. Прежде чем расширять фильтр, шаблон должен уметь оба формата: если значение — число, это секунды; если разбирается как дата, брать разницу с now(). Плюс рантайм-проверка «выбранный сенсор не даёт ни числа, ни даты» с внятной причиной в alarm_reason — иначе неверный выбор останется незаметным ровно так же, как сейчас незаметно пустое поле.

Проверка, что выбран правильный тип сенсора¶

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

Идея. Рантайм-проверки, поднимающие alarm_reason: статус станции — число (is_number(states(...)) при непустом статусе); здоровье батареи ведёт себя как уровень заряда (растёт во время зарядки). Часть защиты уже есть — здоровье вне диапазона 50–130 % игнорируется, а доля вроде 0.98 переводится в проценты.

Что надо продумать. Числовой статус — законный случай (станции с кодами 0/1/2 существуют, и блюпринт их поддерживает), так что проверка должна срабатывать только когда список статусов явно текстовый, а сенсор числовой. Иначе получится ложная тревога у тех, у кого всё настроено верно.

Возраст сущности, переживающий обрыв связи¶

Проблема. Блюпринт измеряет время по last_changed, а тот обновляется и при уходе сущности в unavailable. Секундный обрыв связи со станцией омолаживает выключатель до нуля, и всё, что опирается на его возраст, начинает врать:

Что ломается	Как проявляется
`session_started_in_window`	«Доработать начатое» отваливается, если обрыв случился после конца окна. Проверено на реальной ночи: обрыв в 07:01 при окне до 06:55 отключал дозарядку
`switch_gap_elapsed`	Включение и смена режима блокируются ещё на `command_gap` после каждого обрыва
`no_power_alarm`	Watchdog «включено, но тока нет» отсчитывается заново; при частых обрывах может не сработать вовсе
Запись в журнал	«Сессия длилась N мин» показывает время с последнего обрыва

Идея. Измерять возраст по источнику, устойчивому к недоступности. У состояния есть last_reported, но он обновляется на каждом опросе и потому не годится напрямую. Более честный путь — вспомогательный input_datetime, куда блюпринт записывает момент старта сессии.

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