Удаленное управление котлом Vaillant по шине eBus + CalorMatic 470

[Анатолий Григорович]

Добрий вечір. Підкажіть будь ласка де можна придбати адаптер ebus?

[kentrp]

В 19.11.2022 в 18:44, Анатолий Григорович сказал:

Добрий вечір. Підкажіть будь ласка де можна придбати адаптер ebus?

Ebusd.ue ~50€

[nikita]

в Деніса вже є в наявності

[razzil]

04.02.2022 в 11:02, gvm сказав:

Добрый день, а кто-то уже полноценно подключил ebusd к Protherm Ray? Стандартная конфигурация позволяет читать часть значений, но некоторые недоступны, к примеру у меня ReturnTemp возвращет 0, а так же данные по потребленной энергии PrEnergySumHwc1.
Возможно, есть наработки и может поделиться конфигом к ebusd?

Як ваш досвід з Protherm Ray? Поділіться якщо не складно.

[bs0d]

25.08.2023 в 20:47, razzil сказав:

Як ваш досвід з Protherm Ray? Поділіться якщо не складно.

Котли вайлант/протерм - нормальна збірка, але у плані керування по ebus - шляпа, якщо коротко

Вас щось конкретне цікавить? Маю 12квт рей з більш-менш притомною конфігурацією ebusd/HA під нього

[razzil]

3 години тому, bs0d сказав:

Котли вайлант/протерм - нормальна збірка, але у плані керування по ebus - шляпа, якщо коротко

Вас щось конкретне цікавить? Маю 12квт рей з більш-менш притомною конфігурацією ebusd/HA під нього

От саме керування з HA через ebusd і цікавить.
1) Крім ebus адаптера чи треба ще додатковий пристрій на шині? Бо я займався цим пару років тому, потім закинув і зараз хочу продовжити. Так от тоді данні з адаптера я отримував тільки коли ще був підключений програматор на ebus.

2) Можете поділитися своїм файлом команд для ebusd?

3) Ebusd адаптер підключений до машини з HA, або через esp?

4) в НА оця www.home-assistant.io/integrations/ebusd/ інтеграція використовується, чи щось інше?

Змінено 22 жовтня 2023 користувачем razzil

[bs0d]

2 години тому, razzil сказав:

От саме керування з HA через ebusd і цікавить.
1) Крім ebus адаптера чи треба ще додатковий пристрій на шині? Бо я займався цим пару років тому, потім закинув і зараз хочу продовжити. Так от тоді данні з адаптера я отримував тільки коли ще був підключений програматор на ebus.

2) Можете поділитися своїм файлом команд для ebusd?

3) Ebusd адаптер підключений до машини з HA, або через esp?

4) в НА оця www.home-assistant.io/integrations/ebusd/ інтеграція використовується, чи щось інше?

1. Загалом достатньо лише адаптера (у всякому разі мого, який я у Дениса замовляв, як і більшість людей тут)

2. Приатачив, нижче розпишу що і як

3. Через esp (d1 mini), з ХА комунікує вайфайно

4. github.com/LukasGrebe/ha-addons достатньо лише ebusd адона звідси

 

Щоб скористатися конфігом треба:

- поставити вищевказаний ebusd адон

- розпакувати вміст архіва в /config/ebusd фолдер HA

- накофігурувати ebusd адон хоча б як у мене (див. ebusd_addon_config.txt)

- запустити адон

- йти в Settings -> Devices -> MQTT -> ebusd2 / ebusd2 bai (чи в mqtt-explorer), дивитися шо там прилітає (mqtt брокер та інтеграція мають бути встановлені, гадаю це очевидно)

У мене ентіті виглядають наступним чином:

Прихований текст

 

Дісклеймер: я не користуюся SetModeOverride, для керування котлом, хоча в конфігу ця штука присутня. Мені достатньо перемикачів HcSwitch HwcSwitch, тобто на виході маю звичайний on/off, але без сторонніх реле/датчиків і з мінімальним моніторингом того, що мене цікавить; цим всім хазяйством керую через автоматизації

Важливо: в архіві знаходяться лише файли необхідні для Protherm Ray, решта сміття почищена. Тобто це вже готове рішення і має працювати "з коробки", за умови що адаптер прошитий, отримує сигнал та працює в принципі

Якщо що - маякуйте в телеграм, відправлю контакт в ПМ

ebusd_ha.zip

Змінено 22 жовтня 2023 користувачем bs0d

[Sergiy B.]

22.10.2023 в 15:27, bs0d сказав:

1. Загалом достатньо лише адаптера (у всякому разі мого, який я у Дениса замовляв, як і більшість людей тут)

2. Приатачив, нижче розпишу що і як

3. Через esp (d1 mini), з ХА комунікує вайфайно

4. github.com/LukasGrebe/ha-addons достатньо лише ebusd адона звідси

 

Щоб скористатися конфігом треба:

- поставити вищевказаний ebusd адон

- розпакувати вміст архіва в /config/ebusd фолдер HA

- накофігурувати ebusd адон хоча б як у мене (див. ebusd_addon_config.txt)

- запустити адон

- йти в Settings -> Devices -> MQTT -> ebusd2 / ebusd2 bai (чи в mqtt-explorer), дивитися шо там прилітає (mqtt брокер та інтеграція мають бути встановлені, гадаю це очевидно)

У мене ентіті виглядають наступним чином:

  Показати вміст

 

Дісклеймер: я не користуюся SetModeOverride, для керування котлом, хоча в конфігу ця штука присутня. Мені достатньо перемикачів HcSwitch HwcSwitch, тобто на виході маю звичайний on/off, але без сторонніх реле/датчиків і з мінімальним моніторингом того, що мене цікавить; цим всім хазяйством керую через автоматизації

Важливо: в архіві знаходяться лише файли необхідні для Protherm Ray, решта сміття почищена. Тобто це вже готове рішення і має працювати "з коробки", за умови що адаптер прошитий, отримує сигнал та працює в принципі

Якщо що - маякуйте в телеграм, відправлю контакт в ПМ

ebusd_ha.zip 18 \u041a\u0411 · 44 завантаження

доброго дня хочу уточнити по конфігурації 

в мене адаптер v5 під'єднаний до газового котла протерм 

також на доманшньому сервері крутиться ebusd сервіс з'єднаний по сітці з адаптером 

на тому є сервері крутиться віртуалка з HA "прокинута" в локальну сітку 

коли я запускав аддон github.com/LukasGrebe/ha-addons він хотів конектитись саме до ebusd сервіс а не до адаптера тому я не розумію як обійтись без ebusd сервіса 

також якщо не тяжко підкажіть будь ласка як додати контроли і сенсори у ХА як у вас в скріні бо я тільки почав з хА і якось поки не вкурюю всю концепцію

дякую

[psy]

Здравствуйте, есть ecoTEC plus VU 10CS/1-5 (N-INT2) и погодозависимый термостат sensoHOME VRT 380/2, что бы управлять с телефона по вайфай есть иной выход или только с помощью модуля myVAILLANT Connect VR 940?

[tarick]

Доброго дня.

Підкажіть, чи можна зараз десь придбати адаптер ebus? писав учаснику Denz, але він, здається, не заходив на форум з 22-го року.

[aviator89]

Керування Vaillant (BAI, без кімнатного регулятора) через ebusd + Home Assistant — досвід і кілька знахідок

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

Залізо і топологія

- Одноплатник на Armbian (домашній сервер, все на Docker).
- Котел — Vaillant BAI (atmoTEC/turboTEC-класу, проточний, без бака-накопичувача — важливо для подальшого).
- До шини підключений не USB-адаптер, а eBUS-to-LAN шлюз (TCP, окрема залізка на власній IP в локалці), тому в ebusd вказую --device=ens:свій іп замість звичного /dev/ttyUSB0.
- Кімнатного регулятора (Calormatic/VRT) немає взагалі — керування повністю "мозком" з боку сервера.

ebusd (docker, john30/ebusd:latest)

Робочий рядок запуску (те, що реально стабільно крутиться):

docker run -d --name ebusd --restart unless-stopped --net=host \
  -v /opt/ebusd/config:/etc/ebusd/config \
  john30/ebusd:latest \
  --device=ens:192.168.31.239:9999 \
  --scanconfig \
  --configpath=https://ebus.github.io/ \
  --latency=50000 \
  --pollinterval=5 \
  --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson \
  --mqtttopic=ebusd --mqttclientid=ebusd \
  --mqttchanges --mqttretain \
  --mqttint=/etc/ebusd/config/mqtt-hassio.cfg \
  --mqttverbose --mqttvar=filter-direction=r\|u\|^w \
  --httpport=8889 --enabledefine \
  --accesslevel=install

Ключове: --accesslevel=install — без цього запис (SetMode) на котел мовчки не проходив, хоча читання працювало. Це та поправка, яка нарешті "оживила" запис.

--mqttint=.../mqtt-hassio.cfg дає одразу MQTT autodiscovery в Home Assistant — влітає ~1450+ ентіті без жодної ручної роботи.

Котел на шині коректно ідентифікується:
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=5011;HW=1303", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"

Автоматика: setmode-sync.py (systemd-сервіс, не таймер!)

Спочатку я планував "таймер systemd раз на 60с запускає скрипт", але зрештою прийшов до кращої схеми: один персистентний Python-процес з власним while True циклом і адаптивним інтервалом:
- 2 секунди, поки є активність (горить пальник, або є витрата ГВП, або хоч один тумблер керування увімкнений);
- 60 секунд, коли все в спокої.

Логіка вибору джерела температури подачі (пріоритет зверху вниз):
1. Ручний тумблер — бере значення прямо з input_number повзунка в HA.
2. Passthrough (за замовчуванням) — просто зчитує поточне FlowTempDesired/StorageTempDesired з самого котла й пише те саме значення назад. Це потрібно, бо (як і в темі вже писали) котел "забуває" SetMode десь за кілька хвилин, якщо йому не нагадувати — тож навіть коли нічого змінювати не треба, скрипт все одно підтверджує поточне значення.

Формат payload, який летить у MQTT (ebusd/bai/SetMode/set):
auto;{flowtemp};{hwctemp};{hwctemp};0;0;0;0;0;0;0;0

Раніше в скрипті була ще й погодозалежна крива (формула на основі вуличної температури з Open-Meteo API), схожа на ту, що зустрічав тут silvan (2021) — але в мене виявилась мертвим кодом (тумблер для неї видалили з дашборда, а логіка лишилась), тому нещодавно прибрав.

Юніт (для тих, хто зустрічав такий самий патерн з таймером — не потрібен):
[Unit]
Description=Sync desired boiler heating/DHW setpoints via ebus SetMode
After=docker.service mosquitto.service
Requires=docker.service

[Service]
Type=simple
ExecStart=/usr/bin/python3 /usr/local/bin/setmode-sync.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
Restart=always тут повністю замінює будь-який зовнішній таймер — процес сам себе підтримує.

Знахідка 1 — installer/expert-параметри: не access-level, а, схоже, розбіжність CSV під точну прошивку

Пробував дістатись до FlowsetHwcMax (d.78), PartloadHwcKW (d.77), HwcTempMax (d.20), HcPumpMode, SecondPumpMode, ValveMode (d.70) — усі повертають ERR: invalid position in decode. Спочатку думав, що це через --accesslevel=install — підняв до --accesslevel=* (максимум) і перезапустив контейнер. Результат той самий: котел відповідає тим самим одним нульовим байтом, скільки не піднімай рівень у ebusd.

Покопав глибше й знайшов конкретнішу причину. У самому bai.308523.inc рівень доступу на читання цих полів взагалі порожній (не обмежений!) — обмежений лише запис (install, який у нас якраз є):
r,,,PartloadHwcKW,d.77 ...          ← читання: рівень не вказано
w,,install,PartloadHwcKW,d.77 ...   ← запис: install
Тобто справа не в access-level. Дістав точний product ID нашого котла з шини:
ebusctl scan 08
→ 08;Vaillant;BAI00;5011;1303;21;21;39;0010026149;3100;005218;N5
Product ID 0010026149, SW=5011, HW=1303. Звірив із vaillant/08.bai.csv — там ~20 умовних правил [Scan_id_product='...']!load,bai.XXXXXXX.inc під конкретні списки product ID. Перевірив повний список ID у правилі, яке реально підхопив наш ebusd (bai.308523.inc):
0010004276, 0010004277, 0010004279-4283, 0010004285-4292,
0010004336-4340, 0010005466-5469, 0010010392-10394, 0010010400,
0020051714-0020051717, 174
Нашого 0010026149 там немає (і в сусідніх правилах теж немає) — котел підхопив цей файл через останнє безумовне правило-заглушку в кінці CSV, а не через справжній збіг. Тобто під нашу точну прошивку в публічному репозиторії конфігурацій просто немає окремого файлу.

Про всяк випадок перевірив і гіпотезу "може, дані з'являються лише під час активного розбору ГВП" — опитував ці поля кожні 4с ~2 хв, поки реально текла гаряча вода (пальник підтверджено горів 18 з 20 замірів). Без змін — та сама помилка незалежно від стану пальника.

Підсумок: найімовірніше пояснення зараз — розбіжність формату повідомлення саме для нашої ревізії заліза/прошивки, а не апаратний захист рівня доступу, як я думав спочатку. Але остаточно підтвердити це можна тільки маючи точний CSV під 0010026149/SW=5011/HW=1303 — якщо у когось є такий, чи є спосіб його дістати/згенерувати — дуже цікаво.

Знахідка 2 — перегрів ГВП при малому потоці (миття рук vs миття посуду)

Реальний кейс: при повному відкритті крана (миття посуду) все нормально, а при слабкому струмені (миття рук) вода раптово стає обпікаючо гарячою, пальник ніби "смикається".

Розібрав по історії Status01.temp (первинний контур):
- фон ~40-44°C у спокої;
- при слабкому потоці стрибок аж до 80.5°C — саме в ту секунду насос перейшов у overrun (пост-охолодження після аварійного вимкнення пальника).
- лічильник TempDiffFailure (спрацювання захисту від різниці температур) = 190 за весь час роботи котла — тобто це хронічно, не разовий збій.

Причина: мінімальна потужність пальника цього котла (немодулюючий/слабко модулюючий) все одно більша, ніж треба для маленького потоку → первинний контур перегрівається швидше, ніж встигає стекти вода → спрацьовує захист → пальник аварійно вимикається-вмикається → "пробка" перегрітої води долітає до крана.

Програмного рішення нема (бо все, що могло б це пом'якшити — PartloadHwcKW, FlowsetHwcMax — з тієї ж installer-категорії, див. вище). Реальне рішення — термостатичний антиопіковий змішувальний клапан (½", під ваш цільовий діапазон температур, наприклад ESBE VTA322 20-43°C) на виході ГВП з котла, до розгалуження по кранах.

Корисні ентіті для тих, хто теж на BAI-серії

- Status01 — комбінований пакет: flow/return/outdoor/hotwater/storage температури + стан насоса (off/on/overrun/hwc) в одному повідомленні.
- HwcImpellorSwitch — датчик протоку ГВП (0/1), зручно для детекції "хтось відкрив кран".
- TempDiffFailure / TempGradientFailure — лічильники спрацювань захисту, добрий індикатор хронічних проблем.
- StorageTemp показує -13.50;cutoff, якщо бака немає фізично — зручний спосіб програмно перевірити тип встановлення (проточний/з баком).

---
Якщо цікаво — можу викласти повний setmode-sync.py без комерційної/особистої частини (шляхи, IP приберу). Питання і критика вітаються, особливо якщо хтось впізнає product ID 0010026149 чи має точний CSV/сервісну документацію під SW=5011/HW=1303.

Змінено 11 липня користувачем aviator89