#ДомашняПанель

За вихідні (насправді, ранок неділі) навайбкодив собі домашню панель, як і збирався цього тижня. “Навайбкодив” в цьому разі значить — не писав код самостійно. Та навіть майже не перевіряв його. Чесно, на більше немає часу, а панель потрібна — зокрема, щоб розуміти, чи електрика йде з мережі або з резерву.

Отже, який в мене зараз підхід. Спочатку я десь параграфом пояснюю, що я взагалі хочу. Здійснюю невеличкий мозковий шторм. Та в кінці пишу - “зроби мені plan.md”. Агент генерує дуже довгий та детальний план, в якому, зокрема, будуть можливі питання або рішення. Відповідаю на них. Для того виділяю питання у файлі, надсилаю в чат, та коментую. Агент заміняє питання на відповіді.

Зрештою план доповнюється всілякими подробицями — які API використовувати, які вимоги до надійності, як робити UI тощо. Як план буде мене задовольняти — відкриваю новий чат та кажу “роби за plan.md”. Воно робить з першого разу вже дуже непогано.

Ну, а потім сиджу та послідовно покращую те, що бачу. Це для мене дуже нагадує роботу в парі: я кажу, що робити, а LLM робить. На кожну нову тему створюю новий чат.

В цьому проєкті відкрив пару нових для себе режимів роботи з агентом. В одній з інтеграцій для HomeAssistant був критичний для мене баг. Пощастило, що вже є PR з виправленням. Тож кидаю агенту адресу того PRу та кажу - “застосуй його до мого HomeAssistant!” Агент зміг підʼєднатися за SSH до машини з HA, знайти відповідні файли та застосувати зміни. І це суто вбудованими можливостями Cursor, без всяких MCP.

Другий випадок схожий: ця панель розгортується на локальну машину, де стоїть сервер Lighttpd. Я в ньому не знаюся зовсім. Тож доручив агенту згенерувати скрипт, а потім ще й розібратися, чому скрипт не працює. Він також за SSH зміг виявити, що в мого Lighttpd вимкнений mod_rewrite та увімкнути. А я дивлюся та розумію: я б тільки на цю проблему вбив вечір.

А ще ця панель і вебсокетами користується, і відновлює звʼязок після відключення, і має маленьку сторінку налаштувань. У проєктах-хобі, завдяки ШІ мрії здійснюються, та я цьому не припиняю радіти.

Взимку я писав про свою домашню панель - проєкт, який дійсно спростив життя сімʼї!

Зокрема, на панелі можна побачити стан заряду домашньої батареї. Показати його складніше, ніж здається.

В батареї немає “відсотку заряду”, якщо це не батарея з компʼютерної гри.

(Принаймні в хімічної батареї. Бо, наприклад у гравітаційної батареї відсоток є! Але я відвернувся.)

Отже. Якщо на побутовому рівні, то в хімічній батареї заряд накопичується зміною хімічного складу тої батареї, а вимірюється він — і тут ви можете мене гарно виправити — напругою. Тобто по напрузі на батареї система може зробити здогадку про те, який в ній лишився заряд.

Але і це ще не все. Бо хімічні батареї втрачають місткість — зношуються, так би мовити. Як дізнатися, наскільки? В контролера батареї є певні здогадки, виходячи з того, наскільки (до якої напруги) батарею можна зарядити.

Контролер батареї повідомляє нам два числа: поточний заряд в ампер-годинах, та максимальний заряд в ампер-годинах. Здавалося б, ну хоч тут починається арифметика: ділимо поточний на максимальний.

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

Як тоді показати, що батарея заряджена? Брехати. Оцінювати наближено.

if (charge > 0.99*charge_max) charge_percent = 100

Так і недозаряд, і перезаряд будуть приховані. Причому така проблема не тільки для 100% зʼявиться. От, наприклад, айфони мають режим зарядки до 80%. Думаєте, там система математично чесні 80% обчислює? Я впевнений, що ні!

В продовження теми про домашню панель: як я використав інтеграцію Yasno Outages від пана Дениса Довганя для спрощення життя.

Інформація щодо наявності світла приходить з двох джерел. Для де-факто є датчик потоку від Shelly, який скаже, що на вході з мережі точно є напруга. А для де-юре - Yasno Outages; ця інтеграція повідомляє час поточного відключення та заживлення. Всі дані приходять до мене з Home Assistant.

Далі залишається подружити їх в такій формі, щоб було зрозуміло користувачу.

Індикатор “світло є/нема” береться, звісно, з наявності споживання з мережі. Там довелося лише ігнорувати маленькі значення потоку, бо час від часу датчик знімав якісь 5W навіть коли мережа була мертвою. (Може, хтось може мені це пояснити?) На практиці навіть в холостому режимі квартира споживає більше.

Розклад береться з Yasno. Тут все прозоро.

Складність прихована в рядку з “ще”, тобто у відліку часу, що лишився. Бо знаємо, що графік та реальність часто розбігаються. Тому час “ще” обирається відповідно до наявного стану: якщо світло є, то до наступного запланованого відключення; нема — до наступного заживлення. Інколи то дає дивні значення (як-от якщо світло є, а мали б відключити, то покаже “ще 10 год” - тобто проскочить заплановане відключення взагалі.)

Можна ще багато це покращувати, але не хотілося б.