SunEnergyXT 500

Адаптер sunenergyxt500 для ioBroker

Интеграция и управление собственным потреблением для гибридных систем хранения энергии SunEnergyXT 500 / 500 PRO с переменным током (производитель: SunEnergyXT ) через локальный HTTP API устройства — облачная учетная запись не требуется. Один экземпляр управляет до тремя головками (хранилищами).

Язык / Sprache

• Английский (по умолчанию)
• немецкий

Функции

• Управляет от одной до трех голов в одном экземпляре, каждая в своем поддереве. heads.<n>.* плюс объединенный total.* агрегаты.
• Опрашивает локальный API (GET /read) и отображает все стабильные поля в состояниях: уровень заряда батареи, мощность батареи/сети/нагрузки/солнечной батареи, ток/напряжение для каждого MPPT, ежедневные счетчики энергии, уровень заряда батареи, информация об устройстве/прошивке и состояние счетчика.
• Поля управления, доступные для записи (POST /write (подтверждено повторным прочтением), соответствует панели управления официальной интеграции, за исключением полей, которые в документации API помечены как зарезервированные : заданное значение сетки. GS ограничение выходной мощности инвертора IS, пределы SoC SI /SA /SO режим самопотребления MM конфигурация счетчика MD часовой пояс TZ, перезапуск RT, максимальная выходная мощность сетки MG, то LFB /LPS /PM переключатели и локальный режим LM (⚠️LM=1 блокирует управление облаком/приложениями до перезагрузки). Гистерезис SoC SI1 /SA1 (задокументировано производителем как допускающее запись, по умолчанию 5% для каждого параметра, допустимый диапазон 0…100 %) сохраняют свои установленные heads.<n>.battery.* идентификаторы, чтобы существующие записи оставались нетронутыми. Поля, которые в документации API по-прежнему помечены как зарезервированные (например, PT) доступны только для чтения.
• Два переключаемых режима управления : контроллер самопотребления на стороне адаптера (запись). GS из любого состояния счетчика ioBroker, с прямой связью + P, с сторожевым таймером/безопасным режимом, который распределяет одну заданную точку сети между всеми датчиками , или саморегулирование устройства (привязывает поддерживаемый счетчик к единому хранилищу и позволяет устройству управлять собой) — плюс режим выключения для чистого мониторинга.
• Кнопка «Проверить все головки» в административной панели проверяет доступность каждой настроенной головки (модель + SoC) перед сохранением.
• Индикатор подключения (info.connection) плюс info.lastUpdate и на душу населения online /lastError.
• Полный, неизмененный вариант. /read Реакция каждой головы сохраняется в heads.<n>.info.rawResponse (JSON), поэтому любое поле, которое адаптер не сопоставляет с выделенным состоянием, все равно можно прочитать оттуда.

Как работает этот адаптер

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

Режим B — Адаптер-контроллер (рекомендуется по умолчанию, работает с любым счетчиком, 1–3 головки). ioBroker считывает текущую мощность сети из любого состояния, на которое вы его направите . gridPowerStateId) и адаптер записывает заданное значение сетки GS (прямая связь + коррекция P, с сторожевым таймером). В качестве счетчика может использоваться любой компонент, поддерживаемый ioBroker — Shelly, Tasmota, адаптер для интеллектуальных счетчиков/Modbus — включая счетчики, которые хранилище не может считывать самостоятельно . Вы предоставляете одно состояние, содержащее чистую мощность сети в ваттах . >0 = рисовать, <0 = подача электроэнергии; включить инвертирование знака источника , если он инвертирован; для кВт / расщепленного импорта-экспорта / пофазных счетчиков сначала вычислить чистое значение сети в небольшом состоянии ioBroker). При наличии более чем одного электроусилителя контроллер вычисляет одну общую заданную точку и распределяет ее между подключенными электроусилителями — поровну, с ограничением выходной мощности каждого электроусилителя, подключенного к сети. MG) при разрядке и при достижении предела заряда при зарядке, а также при пропуске головки, которая заполнена (во время зарядки) или пуста (во время разрядки); ее доля перераспределяется между остальными. Адаптер принуждает MM=0 на каждой головке, чтобы устройства выполняли GS При этом счетчик остается полностью работоспособным в ioBroker.

Режим A — Саморегулирование устройства (поддерживаемые счетчики, только с одной головкой). Адаптер привязывает поддерживаемый счетчик к памяти (MM=1 +MD) и позволяет устройству регулировать себя самостоятельно — собственное потребление производителя, которое может реагировать быстрее, чем внешний контур. Этот режим доступен только с одним счетчиком ; при конфигурации с двумя или тремя счетчиками его нельзя выбрать — используйте вместо этого контроллер адаптера. Поддерживаются только четыре типа счетчиков (EcoTracker, Shelly 3EM, Shelly Pro 3EM, Tasmota), и счетчик должен быть доступен для хранилища в локальной сети. Адаптер не записывает данные. GS В этом режиме используется простое mDNS/HTTP-опрос, поэтому счетчик остается работоспособным в ioBroker — в отличие от настроек счетчика в приложении производителя, которое может перенастроить счетчик и удалить его из ioBroker; этот адаптер выполняет прямую привязку и избегает этого.

Выключено (по умолчанию, только мониторинг). Адаптер никогда не записывает данные. MM /MD /GS; это только опрос. Вы по-прежнему можете отдавать команды. control.* штаты вручную.

В обоих режимах управления адаптер **обладает MM ** При каждом опросе проверяется мнение каждого руководителя. MM В зависимости от выбранного режима, система повторно подтверждает его (с предупреждением), если что-то другое изменило его — таким образом, случайное подключение счетчика или внешний скрипт не смогут незаметно отключить управление. Примечание: головной модуль выполняет только записанный запрос. GS когда MM=0; с ограниченным размером (MM=1 оно саморегулируется и игнорирует GS.

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

Локальный режим (LM=1) требуется. Каждое устройство предоставляет доступ только к своему локальному HTTP API (/read //write) когда локальный режим включен — при его выключении, /read Не возвращает никаких данных (подтверждено на протестированной прошивке). Включение локального режима также отключает удаленное управление через облако/приложение; следовательно, мобильное приложение производителя больше не может управлять устройством.

Требования

• От одного до трех SunEnergyXT 500 (PK=1 800 Вт) или 500 PRO (PK=2 Насадки мощностью 2400 Вт, доступные в локальной сети (совместимость с разными моделями также допустима).
• Локальный режим (LM=1 Эта функция включена на каждом устройстве — она необходима для передачи значений через локальный HTTP API (см. раздел « Как работает этот адаптер »). Это также отключает удаленное управление из облака/приложения.
• В зависимости от режима управления требуется счётчик: для режима B (контроллер адаптера) — любой счётчик, для которого доступна информация о мощности сети в качестве состояния ioBroker ; для режима A (саморегулирование устройства, одноканальный) — один из четырёх поддерживаемых счётчиков (EcoTracker, Shelly 3EM, Shelly Pro 3EM, Tasmota), доступных из хранилища в локальной сети. В выключенном режиме не требуется.

Установка

1. В административной панели ioBroker откройте раздел «Адаптеры» , найдите sunenergyxt500 и установите его.
2. После установки экземпляра sunenergyxt500.0 Создан. Откройте его настройки и введите IP-адрес/имя хоста Головы 1 (добавьте Голову 2/Голову 3, если у вас больше голов). Оставьте режим управления в положении «Выкл.» для чистого мониторинга.
3. Сохранить и закрыть — адаптер начнет опрос и заполнит дерево объектов в подкаталоге. sunenergyxt500.0.heads.* (и total.*).

Конфигурация

Связь

• IP-адрес/имя хоста головки 1 (обязательно) и головки 2/3 (необязательно) — локальные адреса ваших головок хранения, каждая с необязательной меткой. Одним экземпляром можно управлять до тремя головками. Размещайте несколько головок на разных фазах (за это отвечает оператор); адаптер регулирует суммарную мощность сети. Один и тот же адрес нельзя ввести дважды.
• Проверка всех головок — программа проверяет каждую настроенную головку и сообщает модель + SoC (или об ошибке), чтобы вы могли проверить адреса перед сохранением.
• Интервал опроса (с) — как часто запрашивается каждая головная станция. /read (по умолчанию 5 с).
• Время ожидания запроса (мс) — время ожидания HTTP-запроса (по умолчанию 8000 мс).
• Восстановление настроек после перезагрузки головки (по умолчанию включено) — см. раздел «Настройки после перезагрузки головки» ниже.

Управление — выберите режим управления :

Выкл. (по умолчанию) — только мониторинг; адаптер никогда не записывает данные. MM /MD /GS.

Контроллер адаптера (режим B) — поля:

• Состояние источника электроэнергии из сети — иностранное государство, владеющее электроэнергией из сети вашего дома, поступающей на счётчик. Условные обозначения: >0 = рисование сетки, <0 = подача электроэнергии. Включите функцию «Инвертировать знак источника», если ваш счетчик использует противоположную систему обозначений.
• Адаптивное управление (по умолчанию включено): регулирует мощность в трех проверенных производителем режимах — небольшие отклонения плавно (каждые 7 с, шаг 20 Вт), средние — каждые 2,5 с (120 Вт), большие шаги нагрузки — немедленно (450 Вт), с фиксированной мертвой зоной сетки 5 Вт. Обратите внимание, что сверху применяется мертвая зона записи для каждой головки (по умолчанию 10 Вт): коррекция меньшего размера не записывается, если общее заданное значение не изменено как минимум на столько же, поэтому на практике отклонения ниже примерно 10 Вт остаются без изменений. Отключите адаптивное управление, чтобы настроить контроллер вручную с помощью полей усиления / мертвой зоны / интервала записи / ограничения шага (они появятся только тогда).
• Целевая мощность сети (Вт, по умолчанию 0): 0 = нулевая подача электроэнергии в сеть; положительные значения обеспечивают небольшое преднамеренное потребление электроэнергии из сети (подача электроэнергии в сеть никогда не осуществляется), отрицательные значения — небольшую преднамеренную подачу электроэнергии в сеть — используется та же система знаков, что и для состояния источника. >0 = ничья).
• Уровень разряда контроллера (%, по умолчанию 0 = выключено): контроллер прекращает разрядку головки, как только ее самый пустой блок достигает этого значения, в то время как собственный уровень разряда головки (SI) остается ниже. В этом случае головка никогда не достигает собственного порога разряда, после чего прошивка 1.1.5 может зависнуть и отказаться от зарядки, пока головка не будет отключена от сети. Измерение производится на самом разряженном аккумуляторе, поскольку аккумуляторы головки могут расходиться; разрядка возобновляется после того, как заряд увеличится за счет гистерезиса головки. SI1 Только в режиме контроллера.
• Максимальная регулировка за одну коррекцию (Вт, по умолчанию 500, 0 = неограниченно): ограничивает диапазон изменения заданного значения за один шаг управления, поэтому высокое усиление не может привести к перерегулированию при скачках показаний прибора.
• Усиление (по умолчанию 0,3), Мертвая зона (Вт), Минимальный интервал записи (мс), Мертвая зона записи для каждой головки (Вт — минимальное изменение заданного значения головки перед ее перезаписью, чтобы избежать помех при разделении потока). Максимальная мощность каждой головки определяется устройством автоматически (800 Вт для 500, 2400 Вт для 500 PRO), поэтому смешанные конфигурации работают без дополнительной настройки.
• Время установления показаний счетчика (мс) (по умолчанию 0) — показания, снятые до последней записи заданного значения, всегда отбрасываются, поскольку они все еще описывают состояние до этого. Сохраняйте значение 0 для счетчиков, значение которых следует за физическим изменением немедленно; немного увеличьте его выше задержки измеренного содержимого для счетчиков, которые публикуют новые метки времени, когда значение все еще отстает.
• Также можно регулировать предельный уровень инвертора (IS) (по умолчанию отключен) — в дополнение к GS Контроллер устанавливает максимальную выходную мощность инвертора: разрядную часть GS Кроме того, потребление нагрузки на порту нагрузки ограничивается текущей мощностью фотоэлектрической системы после того, как головка достигнет минимального уровня разряда. Это полезно только при подключении нагрузки к порту нагрузки ; без нее это просто увеличивает количество операций записи. В режиме аварийного отключения и при выключении адаптера ограничение возвращается к максимальному значению головки в порядке наилучших усилий (в пределах бюджета отключения и только для головок, которые отвечают). Полное завершение процесса не может этого сделать — см. ограничения ниже.
• Предупреждение сторожевого таймера / аварийный режим (s) — если источник данных в сети устаревает, контроллер регистрирует предупреждение и в конечном итоге принудительно запускает GS=0 на каждом доступном разъеме (безопасный нейтральный) до восстановления работы источника. Телеметрия сторожевого таймера доступна под controller.*.

Контроллер работает от последнего заданного значения, а не от нового считывания данных с устройства. Опрашиваемая мощность сети (GP) действует как коррекция: если устройство явно не следует заданному значению более 10 секунд (внутреннее ограничение, вызванное SoC или температурой), сообщаемое значение принимается в качестве новой базовой величины для прямой связи — защита от перенасыщения без дополнительного считывания за цикл. Оно также сравнивает GS Каждое устройство дублирует заданные параметры и выдает предупреждение при их расхождении — это означает, что записывается второй путь управления (приложение поставщика или другая автоматизация). GS Также. Запись на разные головки происходит одновременно, поэтому в течение цикла одна медленная головка не задерживает другие. В следующем цикле по-прежнему ожидается ответ от самой медленной головки, поэтому для регулируемой записи используется более короткий срок (2,5 с), чем настроенный тайм-аут запроса.

Саморегулирование устройства (режим A, только для одной головки ) — области:

• Тип счетчика — EcoTracker / Shelly 3EM / Shelly Pro 3EM / Tasmota.
• Серийный номер / IP-адрес счетчика — серийный номер для Shelly/Tasmota (определяется через mDNS) или IP-адрес локальной сети для EcoTracker (напрямую). Для Tasmota используйте префикс серийного номера без последних 4 символов и установите клавишу питания в соответствии с подтипом вашего энергомонитора.

Адаптер соединяет счетчик (MM=1 +MD) и устройство саморегулируется; адаптер не записывает GS. Привязанный счетчик остается доступным для использования в ioBroker. Этот режим скрывается/блокируется после настройки второго или третьего блока.

Безопасность: В выключенном режиме адаптер доступен только для чтения — он только опрашивает устройство. /read и никогда не пишет, если вы не дадите команду. control.* состояние. В режиме управления адаптер **обеспечивает MM ** на каждой головке для этого режима и повторно активирует его при внешнем изменении; не запускайте второй раз. GS одновременно с писателем (ваш собственный сценарий или сценарий устройства) MM (с другим измерительным прибором), иначе они будут драться из-за батареи.

Контроль поведения, точности и ограничений

Что ожидать: Контроллер поддерживает мощность сети в диапазоне ±10–20 Вт вокруг нуля и корректирует скачки нагрузки — в зависимости от настроек — в течение ~1–3 секунд, но не более ~30 секунд . Постоянное, точное значение 0,0 Вт по замыслу разработчиков недостижимо — ни с одним контроллером на этом оборудовании:

• Точность и уровень шума измерителя: сам внешний измерительный прибор измеряет с погрешностью и уровнем шума в несколько ватт — регулирование ниже этого значения бессмысленно. GS Уставка имеет разрешение 1 Вт, поэтому точность установки не является пределом.
• Задержка в цепочке измерений: измеритель → состояние ioBroker → контроллер →/write → устройство плавно нарастает. Между этапом нагружения и его коррекцией неизбежно проходит ~1–3 секунды.
• Динамика нагрузки: Компрессор или чайник переключаются за миллисекунды — после этого реагирует каждый контроллер. Кратковременные скачки мощности на ваших графиках — это нормально и энергетически бессмысленно (ватт-секунды).
• Контроллер регулирует мощность в соответствии с заданным целевым значением мощности сети (по умолчанию 0) и симметрично колеблется вокруг него — короткие, небольшие моменты подачи электроэнергии в сеть являются частью нулевой подачи электроэнергии. Если подача электроэнергии в сеть никогда не требуется, установите целевое значение на небольшое преднамеренное потребление (например, +10 Вт).

Как работают настройки:

Адаптивное управление (по умолчанию) автоматически выбирает темп для каждого уровня. Для ручного режима доступны два проверенных профиля: «Расслабленный » (по умолчанию — спокойная работа, минимальное количество операций записи на устройство, диапазон ±20–30 Вт) и «Точный» (усиление 0,8–1,0 · мертвая зона 0 · интервал 1000 мс · мертвая зона записи 0 — диапазон ±10–20 Вт, стабилизация за 1–3 с). В течение суток оба профиля дают практически одинаковый энергетический баланс — разница заключается в визуальном оформлении графика, а не в стоимости.

Правила оформления вывесок

• GP (энергия из сети): >0 = подача, <0 = рисовать — в противоположность метру Шелли (api.GP ≈ −shelly.gridPower).
• BP (питание от батареи): >0 = зарядка, <0 = разрядка.
• GS (заданное значение сетки): >0 = подача/выгрузка, <0 = зарядка от сети (разрешение 1 Вт). Ограничение несимметрично для стандартного зарядного устройства 500: оно может подавать до 800 Вт, но при этом потреблять до 2400 Вт, потому что MG ограничивает только вывод.

Дерево объектов

Каждая голова получает собственное поддерево под собой.** heads.<n>.* ** (n = 1…3), плюс объединенные** total.* ** агрегаты и уровень адаптера controller.* /info.* Внутри головного узла состояния группируются в тематические каналы; лист каждого идентификатора объекта представляет собой код поля API устройства (идентификатор сущности из официального справочника полей), а двуязычное имя объекта описывает его — таким образом, дерево соответствует документированным полям устройства в соотношении 1:1.

Элементы управления, доступные для записи (heads.<n>.control.*)

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

Совет: в административной панели ioBroker вы также можете отфильтровать список объектов по флагу «доступен для записи» , чтобы найти все элементы управления сразу.

device.PK получено из DevType на прошивке, которая больше не отправляет отчеты PK. SI1 /SA1 доступны для записи (гистерезис SoC, по умолчанию 5%); поля по-прежнему помечены как зарезервированные (PT) доступны только для чтения. Поля, от которых отказался производитель (UP) или которые являются артефактами, существующими только в документе (WT, BN) не отображаются; все не отображенные элементы по-прежнему доступны в heads.<n>.info.rawResponse.

Настройки после перезагрузки головки

Прошивка 1.1.5 (сообщается как ES 1.1.15) не сохраняет значения, записанные через локальный API: после перезагрузки устройство возвращается со старым сохраненным набором данных, а также автоматически переключается на этот набор данных ночью (наблюдалось в 03:00, без перезагрузки). При включенном локальном режиме приложение производителя также не может их изменить, поэтому настройка, сделанная через этот адаптер, будет незаметно переключаться на старый набор данных и оставаться в исходном состоянии.

Таким образом, адаптер запоминает заданные вами параметры. SI, SA, SO, SI1, SA1, IS, MG и переключатели LFB, LPS, PM - в heads.<n>.info.desiredSettings и записывает значение снова всякий раз, когда головной узел сообщает о другом значении (регистрируется на уровне информации). Головной узел, который постоянно отклоняет значение, повторяет попытку медленнее и после трех попыток сообщается как предупреждение. GS, MM и MD обрабатываются в режиме управления. RT является триггером, LM никогда не принуждается, и TZ опущено, потому что в голове может прозвучать другое слово, нежели было написано.

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

Поля ручного управления счетчиком/режимом (MM/MD)

MM /MD Это показатели собственного потребления, измеряемые самим устройством. При выборе режима управления адаптер управляет ими автоматически (режим A устанавливает MM=1 +MD на одной головке; режим B принуждения MM=0 на каждой голове), и его защита подтверждает соответствие режима. MM на следующем опросе — поэтому любые изменения, внесенные вручную в режиме управления, носят временный характер.

Исходные поля остаются доступными для записи при использовании экспертами/вручную (например, в выключенном режиме). Они соответствуют официальной схеме подключения: поворот MM также очищает MD и писательство MD включает MM (непустое значение) или отключает его (пустое значение). MD JSON-форматы для четырех поддерживаемых счетчиков находятся в локальной справочной информации API устройства; в режиме саморегулирования устройства адаптер формирует их автоматически на основе типа счетчика и серийного номера/IP-адреса.

Ограничения

• До трех головок на один экземпляр. Работа с одной головкой проверена на реальном оборудовании, а работа с двумя головками подтверждена тестировщиком; разделение на три головки охватывается модульными тестами, но не тестировалось на реальном оборудовании — отзывы от пользователей с многоголовочными системами приветствуются. Саморегулирование устройства доступно только для одной головки.
• Электростанции должны быть подключены к разным фазам (ответственность оператора). Адаптер регулирует суммарную мощность сети, а не мощность каждой фазы отдельно.
• Балансировка каждого блока осуществляется собственной системой управления батареей (BMS) каждой головки — адаптер управляет только общей мощностью головки и считывает показания. battery.SC (Итого) для контроля; не управляет отдельными упаковками.
• Ежедневные счетчики энергии (PD /GD1 /GD2 /LD) — это необработанные Вт·ч , а не кВт·ч. PD требуется прошивка модуля управления ES 1.1.14 (продается под названием "1.1.4" — публичная нумерация отличается от внутренней) ES Более старые версии прошивки просто опускают это поле, и состояние остается пустым.
• Ежедневные счетчики обнуляются устройством при перезагрузке, поэтому обновление прошивки в середине дня возвращает их к нулю.
• MD и TZ Вступают в силу немедленно, но нет гарантии, что устройство отобразит их в точности — подтвердите по эффекту, а не по повторному отображению.
• В случае полного сбоя хоста ioBroker, последняя заданная точка продолжает работать. У датчиков нет собственного таймаута для установки заданной точки: что бы это ни было. GS Последний записанный файл продолжает выполняться до тех пор, пока ограничение SoC не остановит его. Обрабатываются обычные остановки, перезапуски или изменения режима — адаптер нейтрализует записи и, если это не удается, запоминает их. info.gsOwned) и завершает работу при следующем запуске. Отключение электроэнергии или прерванный процесс таким образом не могут быть защищены.
• Входы фотоэлектрических модулей не тестировались с оборудованием (эталонная установка работает без фотоэлектрических модулей, поэтому...). PV1–4 всегда равны 0). Интеграция и контроллер не зависят от типа фотоэлектрической системы и являются полными, но могут возникать особые ситуации, связанные с прошивкой фотоэлектрической системы (например, полная зарядка батареи + избыток энергии от фотоэлектрической системы, поля ИБП/байпаса). FP /UG) не проверены — отзывы приветствуются. Ток и напряжение для каждого MPPT считываются с точностью до десятых и масштабируются на 0,1, что соответствует собственному интегрированию производителя; если в реальной установке фотоэлектрической системы они показывают отклонение в десять раз, то именно там следует искать ошибку.

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

• ** info.connection пребывание false / Нет данных:** сначала убедитесь, что используется локальный режим (LM=1 Функция включена на устройстве — без нее локальный API не возвращает никаких значений. Затем убедитесь, что она включена. http://<device-ip>/read доступен с хоста ioBroker (проверьте с помощью браузера или curl). На человека, heads.<n>.info.online и heads.<n>.info.lastError Укажите, какой из них не сработал.
• Ничего не контролируется: проверьте режим управления — «Выкл.» никогда не записывает данные. В контроллере адаптера установите допустимое состояние источника питания от сети ; в разделе «Саморегулирование устройства» установите поддерживаемый тип счетчика и серийный номер/IP-адрес .
• Устройство игнорирует GS Батарея не реагирует: головка только выполняет записанный код. GS когда MM=0 В режиме контроллера адаптера это обеспечивается автоматически; если вы напишете GS Вручную убедитесь, что ни один счетчик не привязан (MM=0). С ограничением по метру (MM=1 Устройство саморегулируется и игнорирует GS.
• Контроллер работает слишком медленно / никогда не достигает точно 0: см. Поведение управления, точность и ограничения — измерительная цепочка добавляет задержку примерно в 1–3 секунды, а сам измеритель имеет конечную точность, поэтому физическим оптимумом является диапазон ±10–20 Вт вокруг целевого значения. Для максимально быстрой реакции используйте профиль «Точность» (усиление 0,8–1,0, мертвая зона 0, минимальный интервал записи 1000 мс); чтобы никогда не подавать сигнал на вход, установите мощность целевой сети на небольшое положительное значение.
• Временные метки состояний выглядят устаревшими / флаг качества 32: адаптер записывает состояние только тогда, когда изменяется его значение (стандартная практика — это защищает базу данных состояний от миллионов одинаковых записей). Поэтому временная метка состояния показывает последнее изменение значения, а не последний опрос. Проверьте актуальность данных с помощью info.lastUpdate (обновляется после каждого успешного опроса) и heads.<n>.info.online Качество 32 («замена исходного значения») сохраняется только в тех состояниях, в которых устройство никогда не выдает значения (например, SoC модулей расширения, которые не установлены); после каждого запуска адаптера все выданные значения записываются один раз, поэтому их метки времени как минимум такие же актуальные, как и при запуске.
• Накопитель вообще ничего не делает — он не заряжается и не разряжается: в режиме контроллера адаптер переключает собственную регулировку устройства. MM) выключено, поэтому, если его собственный контур никогда не срабатывает, ничего не регулирует. Читать controller.gridPower: оно остается пустым, если в контроллер не поступило ни одного значения (проверьте идентификатор состояния и убедитесь, что источник записан с использованием ack=true — Непризнанные ценности игнорируются намеренно; controller.status идет к failsafe (и в журнале указано состояние). Если отображается положительное значение, хотя дом действительно получает питание, то правило знаков инвертируется — включение питания от сети инвертируется . Если же значение отрицательное и controller.totalTarget Если значение тоже отрицательное, контроллер запрашивает зарядку, а устройство отказывается: проверьте. heads.<n>.device.ST (2 = бег) и heads.<n>.battery.ON.
• Два контроллера борются за батарею: используйте только один. Адаптер это контролирует. MM Для выбранного режима — отключите все внешние устройства. GS скрипт (или собственный скрипт устройства) MM (с другим измерительным прибором) перед использованием режима управления.
• Некоторые штаты остаются пустыми (0 /""): устройство возвращает только те поля, которые фактически предоставляет его прошивка/топология (например, дополнительные пакеты). SC2 –SC5 или только при возникновении ошибки (или при использовании битовых масок ошибок). Полный необработанный ответ всегда доступен в heads.<n>.info.rawResponse.
• После обновления с одноголовочной версии дерево выглядит неправильно: структура дерева объектов была изменена следующим образом: heads.<n>.* В версии 0.2.0 адаптер автоматически удаляет устаревшие объекты при запуске; если что-то осталось, удаляет старые объекты (или повторно добавляет экземпляр).
• Устройства периодически отключаются / происходит таймаут пинга: модуль Wi-Fi устройства работает слабо, а при установке нескольких устройств друг на друга металлический корпус оказывается прямо над антенной. Проверено. heads.<n>.device.network.WR (Уровень сигнала в дБ) — ниже −75 дБ связь становится ненадежной. Разделите установленные блоки и увеличьте интервал опроса до 10–15 с (качество управления практически не страдает: контроллер реагирует на источник питания сети, а не на этот опрос). Чтобы исключить адаптер, остановите экземпляр и пингуйте головной блок в течение нескольких минут — если обрывы связи продолжаются, причина не в опросе. Сам адаптер отправляет один пинг. /read для каждого источника и с заданным интервалом, задействует несколько источников поочередно, закрывает каждое соединение после использования и автоматически отключается после неудачных опросов.

Changelog

0.3.4 (2026-09-28)

• (Creekhail) New: a discharge floor kept by the controller itself. Firmware 1.1.5 can lock up at the moment a head cuts off discharging at its own floor (SI): the status LED turns red, the grid LED blinks, and the head refuses to charge — even from its own PV inputs — until it is disconnected from the grid; a restart over the API does not reliably clear it. The problem occurs with floors of 5, 10 and 30 % and without this adapter as well. With the new option the controller stops asking a head to discharge once its emptiest pack reaches the set value, above the head's own floor, so the head never reaches the point where it locks up. Measured on the emptiest pack because the packs of a head drift apart. Off by default; controller mode only.
• (Creekhail) Shorter help texts in the instance settings. Each field now shows one short line; the full explanation appears when you hover over the field, and a link under it opens the matching section of this README, so the details are reachable on a phone or tablet as well. The introductions above the sections are shortened too.

0.3.3 (2026-09-27)

• (Creekhail) Settings survive a head restart again. Firmware 1.1.5 does not keep values written through the local API: after a restart the head comes back with an older stored set, and with local mode on nothing else can change them. Found on a 500 PRO when a discharge floor raised to 10 % was back at 5 % after a restart; a test showed the same for the off-grid floor and the self-consumption mode. The head also falls back to that older set on its own at night, without a restart: at 03:00 it switched self-consumption mode off while running, which in device self-regulation would have ended the regulation for the rest of the night. The adapter now remembers the settings you make through it (SoC limits and hysteresis, inverter and grid output limits, the load-port switches) in heads.<n>.info.desiredSettings and writes them again when the head reports something else. On by default, with an option to turn it off; values set before this version are not known to the adapter, so set them once again. Firmware that keeps its settings sees no extra writes.

0.3.2 (2026-09-25)

• (Creekhail) Fixed: after a short head restart the controller could stop writing altogether. A head that reboots comes back with GS=0, and if it answers again before three polls have failed, it never leaves the control loop. The controller still believed its last setpoint was in place, and as long as its target held still — steady surplus, or a head refusing charge with the anti-windup pulling it back to the same step — nothing counted as due, so the storage sat idle in full sun until the load changed or the instance was restarted. A GS echo that differs from the commanded value now marks the head for a resend, whether a restart or a second writer caused it. The foreign value is still never adopted; the controller puts its own back. A zero echo is logged as a probable restart rather than blamed on a second controller.

0.3.1 (2026-09-21)

• (Creekhail) Fixed a blocker in 0.3.0: the instance configuration could not be saved. Heads 2 and 3 were marked invalid whatever was in them — including the empty fields a single-head installation leaves — and because those fields refuse to save while invalid, the whole settings page was stuck. The cause was a validator expression that ioBroker admin evaluated as a statement instead of a condition; it now returns its result explicitly. 0.2.10 was not affected.

0.3.0 (2026-09-21)

• (Creekhail) The heads' own SoC hysteresis is respected. A head that has reached its discharge floor (SI) does not accept power again until its charge has risen by SI1 above it, and the same applies at the top with SA/SA1. Without that, the controller kept commanding a head that was refusing — a stream of writes every few seconds, a setpoint that never took effect, and the other heads carrying a share that was silently missing. The share of a head that is held back is redistributed across the ones that can take it. The block is tracked from the reported charge alone, so it is set when a head reaches a limit and lifted when its charge leaves the band, whether or not the controller happens to be asking for power at that moment. A head whose charge is already inside a band when the adapter starts is assumed to be held there until it leaves it: from outside there is no way to tell whether the device has released it, and waiting costs a few percent of one battery while guessing wrong costs a continuous stream of writes the device ignores.
• (Creekhail) Fixed: a head with a lowered feed-in limit is no longer throttled when charging or supplying its own load. MG caps what a head puts into the grid; it says nothing about what it may draw or what its inverter may produce for the load port — the device takes up to 2400 W in either of those regardless. Using MG for all three left a 500, or a PRO whose owner had capped feed-in at 800 W, charging at a third of its rate with the surplus going to the grid, and unable to cover a load larger than its export cap.
• (Creekhail) A setpoint left on a head is not forgotten across a restart. A head has no setpoint timeout of its own: whatever GS was written last keeps being executed until something says otherwise, so a crash or a power cut could leave one charging or discharging at full power with nothing watching it. The adapter records that it has set one (info.gsOwned) before the first write goes out, neutralises the heads on the next start, and only clears the record once every head has confirmed — retrying from each head's own poll until it does.
• (Creekhail) Optional: the controller can steer the inverter limit (IS) alongside the grid setpoint — the discharge part of GS plus whatever the load port draws, capped to the PV power once the head has reached its discharge floor. Off by default; it is only useful with a load wired to the load port. It has its own write dead band, and the limit is handed back to the device maximum on failsafe and shutdown, so a stopped controller never leaves the inverter throttled.
• (Creekhail) New option "meter settling time" for meters that publish a fresh timestamp while the value still lags behind the physical change. Readings taken before the last setpoint write were already discarded — they describe the state before it — and this extends that window. A source whose clock runs behind this host no longer freezes the loop either: regulation falls back to one correction per 30 s and the log says why.
• (Creekhail) Field names and ranges checked against the manufacturer's own Home Assistant integration. Every field it exposes is covered here, with the same meaning and unit; the only deliberate differences are the daily energy counters (raw Wh as the API delivers them, where the integration converts to kWh) and the SoC limits SI/SA/SO, which stay at 1…100 % because the API calls its narrower figures recommended values, not device limits. The SoC hysteresis SI1/SA1 now accepts 0…100 % as it does there — a cap of 50 % here had been refusing settings the device accepts.
• (Creekhail) Manual writes to the control states are range-checked. A typo in a script (GS=99999, SI=150) no longer reaches the hardware. The ranges follow the device: IS is 1…2400 W on both models, while the two grid-tied output fields (GS, MG) drop to 800 W on a standard 500 as soon as a poll reports the model, just as the manufacturer's own integration does. What a head draws and what its inverter may produce stay at 2400 W on both.
• (Creekhail) Two states renamed for accuracy — the object ids are unchanged, so history and existing scripts keep working. control.IS was called "Max. grid feed-in / inverter output limit", which conflated the two limits the device keeps apart: it is the inverter output limit, while MG caps the grid feed-in. total.maxPower was "Total available power", but it sums MG and therefore says what the plant may put out, not what it may take in — now "Total grid-tied output limit".
• (Creekhail) All 57 Tasmota / BitShake meter subtypes are selectable. Thirteen were missing — every one of them a subtype whose power key is a term (power_in - power_out, (Pp - Pm) * 1000) rather than a plain field name, so meters like Siemens, eHZ, Metcom or AS1440 could not be configured for device self-regulation at all. The device evaluates the term itself; the adapter passes it through. Meter model names are also shown untranslated again in every language — the machine translation had turned Q3A into "Pytanie 3A" and eBZ into a chemical, so the entry a user was looking for was not findable.
• (Creekhail) controller.status reports one thing at a time: failsafe whenever anything is in failsafe, warn while a warning stands, ok otherwise. A head that answers but delivers no usable SoC data is neutralised and reported instead of being regulated on placeholder limits, and if no head is regulatable at all the controller goes to failsafe rather than looking healthy.
• (Creekhail) Fixed: selecting device self-regulation with more than one head no longer clears a meter binding. That combination is refused and the adapter falls back to monitoring — but it used to release the binding on the way, switching off the device's own regulation without anything taking over.
• (Creekhail) Heads are addressed the way you typed them, but compared normalised: 192.168.1.5, 192.168.1.5/ and http://192.168.1.5 are recognised as one device.
• (Creekhail) Robustness: an HTTP response that errors or closes mid-body can no longer leave a request hanging forever; a control cycle that throws is logged instead of taking the adapter down; requests to one head are serialised and stop at shutdown.

0.2.10 (2026-08-03)

• (Creekhail) Gentler on the heads' Wi-Fi: with two or three heads the adapter no longer polls them all in the same instant — each head now runs its own cycle, staggered by up to 1 s. After a failed poll that head is backed off (doubling up to 60 s) instead of being polled at full rate, which only added to the congestion that made it drop out. The other heads keep their own rhythm either way.
• (Creekhail) Every HTTP connection is closed after use (Connection: close, a dedicated connection pool per head). Node's default keeps a socket open for 5 s, which at a 5 s poll means permanently — a slot the head's ESP32 cannot reclaim if the close is lost on a weak link. Reads and writes to the same head are now serialized as well, so a control write no longer opens a second parallel connection while a poll is running, and all sockets are closed on unload.
• (Creekhail) The request timeout now covers the whole request instead of only the phase after a socket was assigned.
• (Creekhail) Admin: the poll interval carries a help text recommending 10–15 s for two or more heads or a weak Wi-Fi signal; new troubleshooting entry for sporadic head drop-outs.

0.2.9 (2026-08-02)

• (Creekhail) The controller now publishes what it actually sees: controller.gridPower is the house grid power the way the loop understands it (after the inverted option, >0 = draw) and is updated for every accepted value — even while the dead band suppresses any write, so "no value arrives" and "values arrive but nothing happens" are finally distinguishable. controller.totalTarget shows the total setpoint before it is split across the heads; a negative value means the controller wants to charge, so a storage that stays idle anyway is a device-side problem.
• (Creekhail) Fixed a silent standstill: if the configured grid-power source never delivered a single value (wrong state id, or a state written with ack=false), the controller sat at GS=0 forever without any warning — while control mode had already switched the device's own regulation (MM) off. Nothing regulated at all, and the status still read ok. The watchdog now escalates to failsafe after the configured failsafe time and logs the state id together with what to check.
• (Creekhail) A grid-power source that is written with ack=false is still ignored (an unacknowledged value must not drive the battery), but the adapter now warns once, names the state and points at both remedies instead of dropping every value silently.
• (Creekhail) Renamed total.gridPower to "Storage grid-port power, total" — it sums the storages' grid ports and was too easily mistaken for the house connection. The object id is unchanged, so history and existing scripts keep working.

0.2.8 (2026-07-29)

• (Creekhail) Support for control module firmware ES 1.1.14 (marketed by the manufacturer as "1.1.4"): the reinstated field PD is now exposed as heads.<n>.pv.PD — today's PV generation energy in raw Wh. Verified against a 500 PRO before and after the update: no field was removed and no control value was reset, so older firmware keeps working unchanged — the state simply stays empty where the device does not deliver PD.
• (Creekhail) Documentation: noted that the device's public firmware numbering differs from the internal one reported in ES (public 1.1.4 = internal 1.1.14) — feature availability is therefore detected by field presence, never by comparing version strings; and that the daily counters (PD/GD1/GD2/LD) are reset by the device on reboot, so a firmware update mid-day drops them to 0.

0.2.7 (2026-07-05)

• (Creekhail) New adaptive control (enabled by default): the controller regulates in three manufacturer-proven tiers — small deviations gently (every 7 s, 20 W steps), medium ones every 2.5 s (120 W), large load steps immediately (450 W), with a fixed 5 W dead band. Disable the new checkbox to keep tuning gain, dead band, write interval and step limit manually. Existing installations are switched to adaptive by this update (uncheck to return to your manual tuning).
• (Creekhail) Admin: help texts for gain, dead band and min. write interval; requires admin >= 7.8.23; CHANGELOG_OLD.md added and the Dependabot auto-merge workflow aligned with the canonical template (iobroker-bot).

0.2.6 (2026-07-04)

• (Creekhail) Controller: new target grid power (deliberate small draw or feed-in — e.g. +10 W to never feed in; the manufacturer's HA blueprint offers the same option) and a maximum adjustment per correction step (default 500 W) that allows a high gain without overshoot on meter spikes.
• (Creekhail) Documentation: corrected the setpoint-granularity statement — the device accepts GS with 1 W resolution (previously documented as 10 W steps); the practical accuracy limits are measurement-chain latency and meter noise.

0.2.5 (2026-07-02)

• (Creekhail) Review follow-up: added the manufacturer/product link to the README, and the controller now only accepts acknowledged grid-power values (ack=true) from the configured meter state (a manually written test value can no longer drive the battery).

0.2.4 (2026-07-02)

• (Creekhail) State names are now provided in all ioBroker languages: English and German stay hand-written, the other languages are machine-translated (generated file, merged at object creation; existing installations are updated in place).

0.2.3 (2026-07-02)

• (Creekhail) Object-tree compliance for the repository review:
  • The heads container is now a folder so the hierarchy follows the required device→channel→state order.
  • The switch states control.MM / LM / LFB / LPS / PM are now real booleans (previously 0/1 numbers) — adjust scripts that read or write them; the device still receives 0/1.
  • Corrected roles: GS/IS/MG use level, ups.UO uses value.
  • Object definitions are merged onto existing objects on start, so role/type/name updates reach existing installations (user settings like history configs are preserved).

0.2.2 (2026-07-02)

• (Creekhail) Repository-checker compliance: complete admin translations in all languages (including the validator messages), release notes translated into all languages, removed an unknown jsonConfig property from the test button and use the adapter-managed timer during unload.

0.2.1 (2026-07-01)

• (Creekhail) Controller robustness and hardening:
  • Config values of 0 are respected (gain / dead bands) instead of silently becoming defaults.
  • A failing GS write on one head no longer aborts the setpoints of the other heads.
  • Anti-windup: when a device visibly limits internally (SoC/temperature), the controller adopts the reported grid power as its feed-forward base.
  • GS is neutralized to 0 on all reachable heads when the controller stops (adapter stop/restart or leaving controller mode), so no head keeps executing a stale setpoint unwatched.
  • Heads are polled in parallel (one unreachable head no longer stretches the poll cycle); fewer state-DB reads per poll.
  • The startup object cleanup only touches adapter-managed subtrees; user-created states in the namespace survive.
  • Missing MG falls back to the model's power limit (500 → 800 W) instead of assuming a PRO; device responses are size-capped.
  • Manual GS writes are rejected (with a warning) while the controller is active; failsafe no longer retries offline heads every tick.
  • New unit tests for the controller (regulation, dead bands, throttling, failsafe, anti-windup).

0.2.0 (2026-06-30)

• (Creekhail) Multi-head support: manage up to three SunEnergyXT heads in one instance. The adapter controller now computes one grid setpoint and splits it across all online heads (equal split, gated by each head's SoC headroom, with per-head power caps and overflow redistribution). New per-head object tree heads.<n>.* and combined total.* aggregates; a "Test all heads" connectivity button; device self-regulation is restricted to a single head. The object tree was restructured — existing single-head instances should be re-created (delete the old objects / re-add the instance).

0.1.1 (2026-06-29)

• (Creekhail) Released via npm trusted publishing (provenance) and a package metadata fix.

0.1.0 (2026-06-28)

• (Creekhail) Initial release: local-API polling to states; writable control fields; two switchable control modes — an adapter-side self-consumption controller (any ioBroker meter state, feed-forward + P, with watchdog/failsafe) and device self-regulation (binds a supported meter: EcoTracker / Shelly 3EM / Shelly Pro 3EM / Tasmota); plus a monitoring-only mode, with an MM-mode guard.

License

MIT License

Copyright (c) 2026 Marcus Bortel (Creekhail) marcus@bortel.de

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.