volomoto

Та ні, взимку буде споживатись будинком. Основна перевага AC-coupled системи в тому, що вона підключається загальної АС шини і відповідно генерація сонця доступна всім споживачам на ній.

Є насправді багато, але щось порекомендувати не можу, бо якогось дослідження не робив. Точно openevse.com/index.html може, бо це опес сорс система, але можна купити кіт. go-e.com/en/ вміє, але дорого. Wallbox вміє, але треба йти через їхній хмарний апі. Всі нові зарядки мають гранулярне керування струмом зарядом, бо всі хочуть застрибнути на поїзд заряду надлишком сонця. Правда питання наскільки відкритий апі. Єдиний нюанс, що там завжди є якийсь мінімальний струм заряду типу 5-8А.

Отут людина зробила щось дуже схоже: Правда там керування по потужності акумулятора, бо мережа відключена, але ніщо не заважає керувати по потужності, яка відбирається з мережі.

EVSE каже машині про максимальний струм АС, яка та може брати з мережі, і в хороших зарядках цю величину можна змінювати динамічно. Якщо сонце дає 500Вт, то треба виставити макс. струм АС 2А і тоді машина більше не візьме. Лімітер каже інвертору, що треба видавати не більше потужності, ніж споживає навантаження, бо інакше почнеться експорт в мережу. А якщо буде достатньо навантаження, то інвертор буде видавати все, що зможе. Якщо ж навантаження більше, ніж сонця, то буде імпортувати з мережі. Алгоритм такий: Потрохи (наприклад з кроком 1А) нарощуємо макс. струм АС і дивимося чи нема імпорту з мережі. Якщо сонця достатньо, то інвертор буде збільшувати генерацію синхронно з тим, як ми дозволяємо машині заряджатись із більшою потужністю. Як тільки генерація вийде на свій максимум в даних момент, то збільшення потужності заряду приведе до збільшення імпорту з мережі. Тоді залежно від вибраного гістерезису або зупиняємо сетпойнт макс. АС струму там, де він зараз є, або відкочуємося на крок назад. Чекаємо трохи і дивимось знову на споживання з мережі. Якщо воно збільшилось, значить треба ще зменшити струм заряду. Якщо споживання стало майже нульовим, то значить спрацьовує лімітер інвертора і потенційно є запас по генерації і можна знову збільшувати струм заряду.

Ну це трохи перебір, бо для того конектора достатньо будь-чого, що створює зусилля в центральній точці.

В мене флюкс тільки вдома для Home Assistant і запити переважно такого плану, але метрик на дашборді максимум два десятки, тому не помічаю якогось сповільнення. Але я часто люблю експериментувати з всякою аналітикою, де багато мапінгу, агрегацій і пайвотів і тоді воно дійсно повільніше працює, але мені пофігу, бо ті кілька секунд погоди не робить. Ну і я один користувач, а на сервері 8 ядер.

Тобто ви встановлюєте системи клієнтам і не знаєте альтернатив? Дуже дивно. А взагалі мене не цікавить що там можна ставити клієнтам, бо я не інсталятор. Я будую розумний будинок сам для себе, тому відкритість системи є основною вимогою, а простий пропріетарний плк, переоцінений як мінімум в два рази, явно цю вимогу не задовольняє.

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

Я також використовую, але ті що 45А. Дуже добре зроблені, але вимагають специфічного інструменту для обжиму.

Можу і навіть діаграму намалював, бо так легше пояснювати: Мережевий Інвертор нічого не знає про зарядну станію, а зарядна станція – про інвертор. Інвертор налаштовується на нульовий експорт в мережу і для цього треба встановити трансформатори струму після лічильника енергокомпанії. Дуже добре якщо інвертор має інтеграція з розумник будинком, як на картинці. Якщо ж не має, то прийдеться поставити ще додатковий технічний лічильник, з якого можна вичитувати поточну потужність мережі (імпорт та експорт). Основна суть, що алгоритм ватроутінгу має постійно знати Grid Power. Зарядка, точніше банальна EVSE, підключається стандартно і головне щоб вона була підключена після СТ лімітера. Також зарядка має підтримувати інтеграцію із розумним будинком, щоб можна було керувати струмом заряду. А далі пишете простий zero-export-mininum-import алгоритм на оупен хабі (думою тут не буде проблем, бо інфи по цьому є багато), який буде ступінчасто керувати струмом зарядки машини. Плюсів в тої системи є багато: 1. Сонце буде використовуватись не тільки для машини, а й для будь-якого навантаження будинку. 2. Якщо поставити трохи розумніший інвертор, то він може надлишок зберігати в акумулятор. Той же Деє з коробки вміє працювати в AC-coupled системі, головне в правильному місці поставити його СТ або смарт лічильник. І не треба ніякої додаткової силової проводки. 3. Дешево. Головним мінусом є те, що воно не зможе працювати без мережі.

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

Бо банально дорого на ту функціональність.

Якщо у вас 3 фази, то є одна хитрість: робите 1-0-2 на кожну фазу окремо і ту фазу, від якої живляться мозги котла, перекидаєте на грід, а всі інші – на лоад.

Це у вас ТН постійно гріє до високої температури, а тоді стоять насосно-змішувальні вузли?

Бо ті, що раніше були жваві в цій темі, перейшли на теплові насоси і їм пофіг що там Шмигаль сказав

Одного кабеля достатньо, бо перемикач 1-0-2 може стояти в щитку.

Непередбачуваність була тільки в сприйнятті, бо без хорошої бази у функціональному програмуванні воно виглядає дико. Але якщо посидіти до почервоніння очей, то штука дуже гнучка. Я написав дуже багато аналітичних запитів, які на InfluxQL було б дуже важко зробити і надзвичайно важко відлагодити.

Якщо не готові інвестувати багато часу у вивчення Flux, то не рекомендую.

Якщо у вас InfluxDB2, тобто той, що працює на Flux, то можна йти наступним шляхом: import "date" from(bucket: "home_assistant") |>range(start: date.sub(d: 24h, from: v.timeRangeStart), stop: v.timeRangeStop) |> filter(fn: (r) => r["entity_id"] == "yambms_yambms_requested_charge_voltage") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: v.windowPeriod, fn: last, createEmpty: true) |> fill(usePrevious: true) |> range(start: v.timeRangeStart, stop: v.timeRangeStop) Тобто дивимось на 24 год в минуле, заповнюємо всі місця, де нема значень, попереднім значенням, а тоді обрізаємо до вибраного періоду.

Перейшов на YamBMS (github.com/Sleeper85/esphome-yambms) і воно таке прикольне, бо: 1) підтримує комбінацію шунтів та бмс. 2) має алгоритми резету на 100% здорової бмс. 3) динамічне керування струмом та напругою заряду, щоб дати коміркам час відбалансуватись. 4) open source. 5) інтеграція з Home Assistant. 6) все обладнання коштує 15 баксів. Цікаво дивитись як розподіляється струм заряду в часі і зокрема один стрінг спочатку відстає, але вкінці наздоганяє: Комірки при цьому сидять дуже кучно і загальний час балансування дуже малий: І дашборди в ХА прикольні:

Ви порушили закон збереження енергії?

Я цього не зміг побороти простим способом, бо в тому періоді часу, який заданий селектором, просто нема даних і логічно, що нічо не буде відображатись. Графана не має такої функції, щоб отримувати останнє відоме значення із-за меж вибраного діапазону, тому єдиний вихід – це писати кастомні запити, які це роблять, але то гєморно.

Якщо там є якийсь шаблон, бо якому та інтеграція називає сутності, то можна використати entity_globs: influxdb: include: domains: - alarm_control_panel - light entity_globs: - sensor.*_occupancy

Я смайлик забув поставити

Парадоксально, але факт: температура панелі під навантаженням є нижчою, ніж без навантаження.