Шаблон для котла Evan Forward

Добрый день

Разработал шаблон для электрического котла Evan Forward.

https://www.evan.ru/products/bytovye_elektricheskie_kotly/evan-forward/

Котёл поддерживает и OpenTherm и Modbus, но Modbus интереснее и требует дополнительной платы в котроллере.

Проверно с WB 8.5.
Запуcтилось и работает на 57600N82 c добавлением "delay_ms" : 100.

Адрес и скорость Modbus настраиваются непосредственно на панели управления котлом.

Чётность - N, бит данных - 8, стоп-бит - 1 - эти параметры вшиты и не настраиваются.

Регистры датчика давления в шаблоне отключены от опроса, так как по сообщению производителя Датчик давления добавили на последней версии платы, но ее в серию не выпускали и не будем (скорее всего).

Регистры четвёртого термометра в шаблоне отключены от опроса, так как по сообщению производителя они тоже для последней версии платы .

В регистре 40014 доступно максимальное количество ступеней мощности - зависит от модели котла.

Шаблон написан в предположении что их шесть (модели 9 КВт и больше). Если у вас их три, то исправьте параметр max регистра 40004.

Шаблон устройства:

evan-forward.json (19.8 KB)

Виджет с основными параметрами:

evan-forward-widget.json (2.2 KB)

Есть другие модели котлов Evan c Modbus (например Practic), но там карта регистов отличается, хотя местами и похожа.

Добрый день.
Прямо отлично что делитесь!
Работает устойчиво, без ошибок?
А, кстати, если (внезапно) отключить шину от котла - он продолжает работать по последней уставке? Никаких ошибок не выдает?

Кто работает устойчиво - котёл или модбас котла ? :))))

Модбас работает устойчиво с "delay_ms" : 100

Шину отрывать не пытался, но если любопытно - попробую в пятницу.

Видя как там приделан модбас - он на плате человеческого интерфейса на которой собственно дисплей и крутилка выбора и то что эта плата коротким езернетом соединена собственно с платой управления - преподложу что ничего не слетит.

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

Да, это ж один из кейсов безопасной эксплуатации “что будет при отказе компонента”.

тогда в пятницу

вопрос - как связать лимит max одного региста с величиной в другом

в котле есть регистр “количество ступеней мощности” - там 3 или 6

и есть настройка “использовать максимально ступеней мощности” для ограничения в работе

как бы их связать без скриптов ?

conditions не подходят если не заводить два раза один регистр с разными кодами что бы в одном написать max=3, а в другом max=6, но это не правильно.

Ну, почему ж. Можно, и выбирать для “чтения” при настройке только один.

мммм не улавливаю

можно пример ?

В регистре 40014 максимальное количество ступеней мощности (read-only).

Для регистра 40004 (read-write - это настройка) надо ограничить max величиной из 40014. Для упрощения можно считать что там только 3 или 6.

В шаблоне описать дважды этот регистр, например

      {
        "id": "set_max_power_steps3",
        "name": "Set Max Power Steps",
        "reg_type": "holding",
        "address": 40004,
        "group": "general",
        "type": "range",
        "min": 1,
        "max": 3,
        "enabled": false
      },
      {
        "id": "set_max_power_steps6",
        "name": "Set Max Power Steps",
        "reg_type": "holding",
        "address": 40004,
        "group": "general",
        "type": "range",
        "min": 1,
        "max": 6,
        "enabled": true
      },

и при настройке включать (выбирать для опроса).

и получаем у него разные id - set_max_power_steps3 и set_max_power_step6

что если просто для вижета, то и ладно

а если завязываться дальше в скриптах (типа днём ограничивать, а по ночному тарифу отжигать по полной), то получается ой-ой

ну или писать в скрипте в оба id - какой-то да сработает, но это плохая практика

Всё хорошо, выдёргивание модбаса на ходу и втыкание обратно на настройки не влияет.