Barnex.Розумний координатор енергії

Deye у Home Assistant: чому датчики «unavailable» і як це виправити

Deye: режими, помилки, локальний доступ

Оновлено:

Схема: Home Assistant, Wi-Fi логер і інвертор Deye; зв'язок із логером обірваний. Чек-лист причин: IP, один клієнт, порт 8899 або 502, серійник логера

Датчики Deye у Home Assistant стають unavailable або unknown, коли інтеграція ha-solarman не може отримати відповідь від Wi-Fi логера. Інвертор при цьому зазвичай працює нормально. Причина майже завжди в зв'язку між Home Assistant і логером: змінилась IP, логер зайнятий іншим клієнтом, вказано не той порт чи серійник, або логер завис. Нижче порядок перевірки від найпростішого до складного.

Стан на 18.10.2026. Стаття про діагностику читання. Записувати регістри інвертора тут не потрібно, а це ризиковано: див. застереження в статті про Modbus.

Що перевірено, а що ні. Причини зібрані з документації ha-solarman, його issue на GitHub (#500, #706, #720) та документації Home Assistant. Автор не відтворював усі ці випадки на власному обладнанні. Де це лише повідомлення користувачів, так і написано. Інтерфейси логерів залежать від прошивки.

Що означають «unavailable» та «unknown»?

unavailable означає, що Home Assistant не може отримати значення (інтеграція втратила зв'язок або не змогла прочитати дані). unknown означає, що сутність існує, але значення ще не отримано, наприклад одразу після запуску. Для діагностики важливо інше: чи недоступні всі датчики Deye одночасно, чи лише частина.

Що бачите Імовірна причина
Усі датчики пристрою unavailable одразу Немає зв'язку з логером: IP, порт, мережа, логер завис
Недоступні лише деякі датчики Профіль (lookup file) не для вашої моделі або валідація значень у профілі
Датчики гаснуть на кілька секунд і повертаються Таймаути й перепідключення, див. розділ про обриви
unavailable вранці, після reload інтеграції все гаразд Відомий випадок після «сну» інвертора, див. нижче

Чому ha-solarman втрачає зв'язок з логером?

Типові причини, від найімовірніших до рідкісніших:

  1. Змінилась IP логера. Роутер видав нову адресу, а в інтеграції лишилась стара. Рішення: DHCP-резервація (постійна адреса) для логера в роутері.
  2. Логер зайнятий іншим клієнтом. Логери зазвичай обслуговують одне підключення одночасно (наша стаття про керування Deye через Modbus радить на час скрипта зупиняти інтеграцію). Мейнтейнер ha-solarman в issue #500 теж радив запускати лише один екземпляр інтеграції на логер, бо кілька можуть перевантажити його запитами. Якщо паралельно працюють ваш скрипт, друга копія інтеграції, Node-RED, MQTT-міст чи інша програма, відповіді губляться.
  3. Не той порт. На старих логерах (наприклад LSW3) Solarman V5 працює на порту 8899. На новій прошивці (1.7.x) користувачі повідомляють лише Modbus TCP на порту 502, а 8899 закритий. Докладно: як повернути локальний доступ через Modbus TCP.
  4. Серійник інвертора замість серійника логера. У формі потрібен Device serial number логера. Цю помилку легко зробити при першому налаштуванні й при перенастроюванні інтеграції.
  5. Слабкий Wi-Fi або завислий логер. У issue #720 кілька користувачів пишуть, що логер переставав відповідати на ping, хоч лишався в мережі. Вони називають перенесення точки доступу ближче та фіксований канал Wi-Fi (з 11 на 6 в одному повідомленні) тим, що допомогло. Це спостереження користувачів, а не підтверджена причина.
  6. Прошивка логера. В issue #500 мейнтейнер вважав причиною несправну прошивку логера, і кілька людей пишуть, що оновлення (наприклад, до LSW3_32U_5406_1.0B) прибрало обриви. Прошивку, за їхніми словами, оновлює підтримка Solarman або Deye, а не користувач.
  7. Профіль (lookup file) не для вашої моделі. Якщо профіль не збігається з регістрами інвертора, частина датчиків віддає порожні або недійсні значення. У документації ha-solarman зазначено, що перенастроювання з неправильним профілем може зіпсувати значення й історію.

Як діагностувати послідовно?

Йдіть зверху вниз і зупиняйтесь на першому кроці, що не проходить.

Крок 1. Чи відповідає логер на ping?

ping -c 5 192.168.1.44

Підставте IP логера. Немає відповіді: проблема в мережі або логер завис. Знайдіть його в списку DHCP-клієнтів роутера: можливо, IP змінилась. Якщо ping проходить лише іноді, дивіться на сигнал Wi-Fi.

Крок 2. Чи відкритий порт?

nc -vz 192.168.1.44 8899
nc -vz 192.168.1.44 502

або nmap -p 502,8899 192.168.1.44. Очікуємо, що відкритий один із двох. Якщо відкритий лише 502, вводьте в інтеграції порт 502. Якщо закриті обидва, а ping є, див. статтю про Modbus TCP: можливо, на логері не ввімкнено Link2 з Modbus TCP.

Крок 3. Звільніть логер від інших клієнтів

Закрийте застосунок Solarman Smart на телефоні та вимкніть усі інші скрипти й інтеграції, що опитують цей логер. Тимчасово вимкніть інтеграцію ha-solarman у Home Assistant (Settings, Devices & services, меню інтеграції, Disable). Зачекайте хвилину-дві.

Про хмару: хмарне з'єднання логера з Solarman/Deye Cloud зазвичай працює паралельно з локальним, і мейнтейнер у #500 сам тримав його ввімкненим. Тому вимикати хмару не обов'язково, але в #720 він пропонував це як тест стабільності.

Крок 4. Прочитайте регістр одним рядком

Це перевірка без Home Assistant: якщо вона працює, проблема в налаштуваннях інтеграції, якщо ні, у логері чи мережі. Для порту 8899:

python3 -m venv venv && ./venv/bin/pip install pysolarmanv5
./venv/bin/python -c "from pysolarmanv5 import PySolarmanV5 as P; print(P('192.168.1.44', 1234567890, port=8899, mb_slave_id=1).read_holding_registers(210, 1))"

Підставте IP і серійник логера. Регістр 210 (макс. струм заряду) ми читали у своєму експерименті на однофазному Deye; на вашій моделі адреса може бути іншою, але перевірка зв'язку працюватиме з будь-яким існуючим регістром. Це лише читання. Для порту 502 підійде звичайний клієнт Modbus TCP, pysolarmanv5 розрахований на порт 8899.

Типові результати:

Результат Що це означає
Повертається число Зв'язок є. Дивіться на інтервал, профіль і конфлікти клієнтів
incorrect data logger serial number Вказано серійник інвертора або з помилкою
Таймаут Логер зайнятий, завис або порт не той
Connection refused Порт закритий: спробуйте 502 і перегляньте Link2

Крок 5. Логи Home Assistant

Settings, System, Logs, пошук за solarman. Корисні рядки з issue #500 і #720:

  • Timeout fetching Inverter data означає, що логер не відповів вчасно.
  • Connection closed. Will try to restart the connection, потім Successful reconnection! Data expected. Will retry the last request означає, що інтеграція сама перепідключилась.
  • SEQ_MISMATCH і Peer not responding. Closing connection свідчать про розсинхрон відповідей, що в #500 пов'язували з поведінкою логера та прошивкою.

Для детальнішого логу ввімкніть debug лише на час діагностики (logger: у configuration.yaml, рівень debug для custom_components.solarman), потім вимкніть.

Крок 6. Перевірте налаштування інтеграції

Settings, Devices & services, Solarman, Reconfigure: IP, серійник логера, порт і профіль. Не додавайте один логер двома інтеграціями. Після змін перезавантажте запис інтеграції.

Як зменшити кількість «unavailable»?

  1. Постійна IP. DHCP-резервація за MAC-адресою логера. У #500 користувач написав, що фіксована IP зменшила обриви.
  2. Один клієнт. Тільки ha-solarman опитує логер. Скрипти та інші системи запускайте, коли інтеграція зупинена.
  3. Не занадто частий опит. За документацією, типовий інтервал 5 секунд, а оновлення іноді розтягуються до ~20 секунд, коли логер не відповідає; інтервал налаштовується навіть для окремих сенсорів, а профіль має параметр update_interval (типово 60 с). Автор інтеграції застерігає, що довгий таймаут там не випадковий, і зменшення таймауту створює проблеми. Тому не «виправляйте» таймаут, а краще збільште інтервал опитування для рідко змінних датчиків.
  4. Сигнал Wi-Fi. Логер ближче до точки доступу або фіксований канал, як радили користувачі в #720.
  5. Прошивка логера. Якщо логер часто завмирає, а Wi-Fi гаразд, запитайте у підтримки про оновлення (як у статті про Modbus TCP).
  6. Реакція на «сон» інвертора. Якщо після ночі датчики лишаються недоступними, поки ви не перезавантажите інтеграцію, це описано в #706 для трифазного Deye. Причина там не підтверджена; користувач запропонував обхід: автоматизацію, що перезавантажує запис інтеграції, коли сенсор стану пристрою змінюється з unavailable, або оновлення до новішого коду інтеграції, як радив один із учасників.

Шаблонний датчик з availability

Щоб панелі та автоматизації не бачили «0» чи unknown під час обриву, обгорніть датчик шаблоном з availability. Документація Home Assistant: якщо шаблон повертає false, сутність стає unavailable, а без availability вона вважається доступною завжди.

template:
  - sensor:
      - name: "Deye потужність мережі (безпечна)"
        unique_id: deye_grid_power_safe
        unit_of_measurement: "W"
        device_class: power
        availability: "{{ states('sensor.deye_grid_power') | is_number }}"
        state: "{{ states('sensor.deye_grid_power') | float }}"

Замініть sensor.deye_grid_power на назву вашого сенсора. Користувач у #720 писав, що під час обриву датчики показували 0: автоматизації, які реагують на «нуль», тоді хибно спрацьовують. Тому в автоматизаціях для керування навантаженням (наприклад, бойлером у Home Assistant) перевіряйте доступність датчика, а не тільки значення.

Чи можуть Barnex і Home Assistant заважати одне одному?

Можуть, якщо обидва опитують один логер. Barnex читає інвертор локально, через Wi-Fi логер або Modbus TCP, і ніколи не записує в нього. Але читання теж займає з'єднання: якщо логер зазвичай обслуговує одне підключення одночасно, два клієнти можуть витісняти одне одного. Barnex тримає одне постійне з'єднання з логером; у нашому захопленні трафіку логер розсилав відповіді всім підключеним клієнтам, і при другому опитувачі 15–25 % запитів лишалися без відповіді. Тому тримайте одного «читача» на логер.

Практично: не підключайте два опитувальники до одного логера «на всяк випадок», а розкажіть, що саме вам потрібно в Home Assistant. Які налаштування Barnex на що впливають, див. у довіднику налаштувань.

Коли краще перейти на інший спосіб?

  • Логер вічно завмирає, а підтримка не допомагає: читайте інвертор напряму по RS485 через окремий перехідник (див. таблицю в статті про Modbus TCP). Це прибирає логер із ланцюга, але потребує доступу до порту інвертора.
  • Потрібні два клієнти одночасно: Modbus-шлюз (ESP32 або Waveshare RS485-Ethernet) з MQTT чи Modbus TCP, який обслуговує кількох споживачів. У README ha-solarman Waveshare RS485-to-Ethernet і ESP-мости названі підтримуваними.
  • Лише моніторинг: якщо Home Assistant вам не потрібен, іноді простіше хмарний застосунок.

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

Коротко

  • unavailable у Solarman майже завжди означає втрату зв'язку HA з логером, а не поломку інвертора.
  • Перевіряйте по порядку: ping, відкритий порт (8899 чи 502), серійник логера, відсутність інших клієнтів, логи, налаштування інтеграції.
  • Постійна IP, один клієнт на логер і стабільний Wi-Fi прибирають більшість обривів; частину випадків, за повідомленнями користувачів, лікує оновлення прошивки логера.
  • Не зменшуйте таймаут і не опитуйте занадто часто; обгортайте критичні датчики шаблоном з availability.
  • Не відкривайте Modbus TCP в інтернет.

Читайте також

Хочете, щоб бойлер грівся від надлишку СЕС без ручних автоматизацій? Замовити Barnex.

Джерела

Читайте також