Arduino.ru

Начал реализовывавть интерфейс в Home Assistant

К тому же уставка TCHset в 0 - абсолютна идентична enableCentralHeating = false. Я хочу отделить мух от котлет в плане управления.  У меня enableCentralHeating выполняет роль переключателся Лето/Зима поскольку у меня Бакси 2-х контурный  - при enableCentralHeating = false работает только контур ГВС и значение TCHset игнорируются.

А какая модель?

SLIM 2.230

В принципе более или менее закончил с ESPшным кодом. С кривыми прийдется отложить проверку до отопительного сезона.  А веб морда будет отдельно от ESP, ибо нефиг загружать ардуинку фигней :-) Для этого и другие девайсы есть.

Понятно. В принципе работу кривых можно оценить по значению "op" и уличной температуры по графикам. Я за основу брал кривые термостата Vaillant. Можно ещё поизвращаться и добавить явно заданную кривую, какую сам состряпаешь. Я добился, таки хорошего быстродействия, веб морда грузится 800 мс.

Ну 800ms на ответ это очень долго.  У  меня среднее время ответа 27-35ms (в зависимости от страницы) - можешь мой код адаптировать - там главное асинхронность.

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

Здравствуйте. Пробовал ваш код ,  все данные на mqtt сервер приходят и веб странмцу ,но когда отключаю котел от сети,  так и продолжают идти последние показания ( например включено отопление) и.т.д  пока не перезагрузишь esp8266 или не включишь котел.  Может я что то не так делаю?

Этот код лишь одна из версий в качестве примера. И надо сказать не удачная. Ссылка уже не работает, убрал. Можете попробовать готовую прошивку https://yadi.sk/d/Qcu-3S7WqdUTHg

Спасибо , а самого кода нет ? я немного переделываю под buderus 24k

andreyasb, вполне рабочий код от OldNavi, только датчик нужно прикрутить и надо сказать шустрее моего. Кстати, я ранее с сенсором DS18B20 дел не имел и всё бы ни чего, да случилось отключение эл. энергии, котёл перешёл на резервное, а вот сенсор термостата стал дурить -127 периодически, естественно котёл ушёл в аварию, а эл.нос газ перекрыл. Проблему пока не решил, но в код добавил функцию антизамерзайки, всё что ниже +5 гр. включается ручное управление котлом, т.е прямая уставка температуры воды котла.

код от OldNavi  не могу скомпилировать  Ошибка компиляции для платы Generic ESP8266 Module. может библиотеки не те. Буду править ваш код. для моих нужд.

Обновите библиотеки. Но с обновлёнными мой код не будет компилироваться.

Нужно core библиотеки 2.5.2 и поправленная версия opentherm library (автор добавил мои исправления) - брать с https://github.com/ihormelnyk/opentherm_library

Generic не подойдет - нужно выбрать платформу ESP8226 (у меня платка WEMOS D1 R2 )

У меня собрался под Generic ESP8266 module,  возможно не подключили все нужные библиотеки (opentherm например).

Вот список библиотек которые должны быть установлены в Ардуино IDE

ArduinoJson       EEPROM_Rotate     ESP8266Scheduler  NTPClient         PubSubClient      WiFiManager       opentherm_library 

Так ведь это же термостат, отключён котёл, не работает и термостат, штатные ОТ термостаты питаются по шине ОТ. Плохо что ESP кушает больше положенного для ОТ, первоначально тоже задумывал питать от котла.

У меня под NodeMCU 1.0...

Те же йаца в другой обертке :-). Проц все равно одинаковый

Вот уж умеют эти железки доставать :-). Наблюдал интересную багу - через какое то время - железяка "пропадала" из сети, при этом MQTT  работал нормально - железяка отвечала на все запросы MQTT.  Долгое и вдумчивое изучение пакетов через tcpdump привело к следующей картине. Железка переставала отвечать на ARP запросы на предмет какой у нее ip адрес и вся сеть была уверена, что интрфейс железяки в down.  При этом на своей стороне железяка считала, что она то в сети и исправно работала с MQTT. Причем ситуация повторялась на любой SDK.  Гугление привело - что такое может быть багой SDK.  Собственно пришил в прошивку костыль - что бы железяка переодически  принудительно отсылала gratuitous ARP пакет бродкастом и проблема ушла.

Добавил следующий код

void forceARP() {
   struct netif *netif = netif_list;
   while (netif)
   {
      etharp_gratuitous(netif);
      netif = netif->next;
   }
}

и шлю его с периодичностью в 10 секунд.

Просто для справки: пишут, что Wiznet тоже не сильно заморачивается на бесперебойной работе своих чипов. W5100 вроде как тоже ARP не бродкастит автоматически (хотя и заявляется, как чип, берущий на себя всю работу с Ethernet сетью) и иногда это вызывает проблемы. Но лично я не сталкивался с этим настолько часто, что мог бы вообще припомнить, где это мешало бы мне в жизни. 

Что поделать - ширпотреб, выпускай - продавай - лепи новый чип...

OldNavi, вы ограничиваете значение переменной op вычислением:

#define __min(a,b) ((a)<(b)?(a):(b))
#define __max(a,b) ((a)>(b)?(a):(b))

float ophi =  100;
float oplo = 0;

op = __max(oplo, __min(ophi, op));

полагаю, так проще:

op = constrain(op, oplo, ophi);

Это не проще - это ровно также :-).  

./cores/esp8266/Arduino.h:#define constrain(amt,low,high) ((amt)<(low)?(low):((amt)>(high)?(high):(amt)))

Я сейчас код рефракторю - делаю отказоустойчивым  - нашел столько интересных багов связанных с железной реализацией  :-). Например у меня ловит иногда периодически наводки на OT шину от включающегося насоса. (3 дня убил прежде чем нашел закономерность ).

ПИД регулятор для котла - видимо не буду использовать этот код.  Либо его надо будет долго и вдумчиво отлаживать - либо ну его нвфиг.  Моменты тепловых инерций котла и дома различаются на порядки и из-за этого интегральная ошибка скачет - мама - не горюй. В итоге даже если температура в доме на градус меньше уставки (а расти она будет ой как не быстро) - ПИД быстро накручивает уставку до 100˚ - а это неприятно, когда у тебя батареи жарят на всю катушку.  Кривые все таки лучше - видимо не зря их производителю больше любят. Надо будет только поиграться с автоматом подстройки наклона кривой.

По хорошему коэффициенты ПИД надо делать настраиваемые, т.е. менять на лету и подбирать под себя.

Вижу это как то так: 

1. Задание периода работы регулятора, через эти промежутки времени вычисляется новое выходное значение; 

2. Задание для самих коэффициентов Кп, Ки, Кд;

3. Задание зоны нечувствительности - отклонение от уставки. При попадании регулируемой величины в эту зону - отклонение считается нулевым;

Интересная публикация по существу: https://apmonitor.com/pdc/index.php/Main/ArduinoControl?fbclid=IwAR0PDyL8w-4uw-mz8yhWNsV1QuQ6yy1loGLWZQLw1O1_gqMxYa1GrD1aWXE

Наводок на шину хватает, у меня ловил от розжига и датчик терял связь при работе от ИБП. В первом случае решил проблему фильтрами ЭМИ, во втором, опросом датчика раз в минуту и записью последнего валидного значения в eeprom, с последующим чтением.

Касательно фильтров -  ферритовой накладки на провод хватило ?  Или нужно RC фильтр прикручивать ?  Я меня тоже от розжига есть ошибки по шине ОТ. Прям таймстампы ошибки  в миллисекунды совпадают с началом розжига.

По быстрому я делал в комплексе, два феррита  на кабель ОТ (кабель начало, кабель конец) два витка, а на питание котла и БП термостата делал ЭМИ фильтр, просто вырезал из плат БП телевизоров. А, по правильному, ловить гармоники и фильтровать... но не факт, что выловленные и отфильтрованные будут бесполезными для других источников, энергосберегающие лампочки, на пример... ЭМИ - бич современности. Кстати, кабель с ферритами и питание термостата от АКБ напрочь решали проблемы.

Ну у меня термостат питается от Малинки  по USB (очень удобно вывод на сериальный порт ESPшки сразу смотреть) а малинка 3B+ питается от правильного блока питания (не простой для мобильника, а нормальный 5V 5A - брал тут https://ru.aliexpress.com/item/32952305390.html?spm=a2g0s.9042311.0.0.601833edKkSwVu ). А малинка еще та привиредина по питанию - ей чуть что не так, он сразу троттлинг процессора делает.  Думаю попробую с 2-мя кольцами и кабель укорочу (сейчас порядка 4 метров от котла). А так переделанный код вполне толерантен к наводкам теперь - ну не получилось послать/прочитать один раз - во следующем цикле все равно данные пропихнет.

Поставил катушки на провод - помогло, но несильно.  Видимо надо сокращать трассу.

Может помочь надёжное заземление котла (провод в кабеле питания ничто!). Режим Антилегионелла будете делать?

C  заземлением там все ок.  Видимо трассу ОТ надо переделать - она идет в одном коробе с питающей линией.  Антилегионеллу делать пока не планировал - к меня ГВС стоит на 50 градусах и когда котел раскачивается на ГВС бывает что сам бойлер прогревается до 60.  Тем более у меня там 50 литров всего.

Понятно, у меня бак водогрея 150 л. комбинированный с ТЭНами. 4 года работал с средней температурой 63 гр. Этим летом разобрал для осмотра, надо сказать, что накипи, такой зацементированной, нет (вода средней жёсткости), в виде хлопьев, но 2 кг. На трубе рециркуляции ГВС магнитная обработка. Вот и думаю, а стоит ли заморачиваться этой Антилегионеллой, хотя функцию сделал.

К одному из термостатов ОТ прочитал следующее: "...Требования к кабелю, соединяещему 2 устройства OpenTherm® довольно просты: это обычный 2-х жильный провод, не обязательно витой (хотя в редких специфических случаях при большом уровне внешних помех может потребоваться и применение коаксиального кабеля), имеющий длину не более 50м и общее сопротивление не более чем 2х5 Ом..."

Попробуем и коаксиал.

Добавил, таки, в свою прошивку 3 изменяемых параметра ПИД регулятору: Kc, tauI, tauD. Теперь "тонко" подстроить можно.

OldNavi, как у вас ведёт себя уличный датчик? У меня "прыжки" какие то... Синяя линия.

Там датчик хоть и не самый точный (разрешение 0,5 градуса) - но в принципе работает нормально, показывает температуру верно - со вторым контрольным уличным на основе DS18B20 - идут ноздря в ноздрю.  Есть на графике флуктуации в переделах +-0,5˚ - но это нормально.  Прыжки в несколько градусов = это как то странно - может установлен неправильно ? (Нужно на что бы был не на солнце, подальше от выхлопов всяких и желательно защищен от ветра и осадков). Может ветер был какой или дождь на датчик попадал ?

С расположением датчика всё нормально, в одной коробке их 2 этот NTC котла и SHT21, показания идентичны но у NTC вот такая флуктуация, походу за точность и флуктуацию отвечает автоматика котла, АЦП такой. Можно смириться. Но, возможно, длина трассы к датчику влияет ~20м, провод сечением 0,75. Можно кинуть до кучи DS18B20, в прошивке предусмотрел.

У меня он собственно от управления отключен - я не разрешаю котлу его использовать, а считаю сам в прошивке

      unsigned long localRequest = ot.buildSetBoilerStatusRequest(vars.enableCentralHeating.value & recirculation, vars.enableHotWater.value, vars.enableCooling.value, vars.enableOutsideTemperatureCompensation.value, vars.enableCentralHeating2.value);

У меня внутренняя компенсация внешней температуры от котла практически всегда выключена (я ее включаю - только когда у меня уставка котла "прямая" - т.е. без учета внутренних температурных датчиков).  Соответственно - брать внешнюю температуру можно с любого датчика, думаю вариант с DS18B20 вовсе не плох.

Добрый день. Собрал по схеме так же самодельный OT контроллер для управления котлом Bosch GAZ 6000. Сейчас занимаюсь до делкой прошивки "по себя".
Большинство идей по коду позаимствовал из этой ветки, в целом всё работает, кроме задания температуры ГВС по MQTT. По выводу Serial.println в ф-и callback вижу, что новое значение прилетает, но вот температура похоже не меняется.
Вывод установленной температуры ГВС через getDHWSPTemp() и передача в MQTT через publish_DHWSPtemp() отдает всегда одно и тоже значение в 42 градуса. На котле индикация установленной температуры ГВС тоже не меняется и стоит вообще на 35 градусов.
То есть пока даже не понятно, то ли заданная температура не передается в котел, то ли получаемая с котла информация не корректна.

Может подскажите где стоит искать ошибку в коде:

// установка  температуры ГВС.
float setDHWTemp(float spdhw) {
 unsigned long request56 = ot.buildRequest(OpenThermRequestType::WRITE, OpenThermMessageID::TdhwSet, ot.temperatureToData(spdhw));
 return ot.getTemperature(ot.sendRequest(request56));
}

// получение установленной температуры ГВС.
float getDHWSPTemp() {
 unsigned long request56 = ot.buildRequest(OpenThermRequestType::READ, OpenThermMessageID::TdhwSet, 0);
 unsigned long respons56 = ot.sendRequest(request56);
 uint16_t dataValue56 = respons56 & 0xFFFF;
 float result56 = dataValue56 / 256;
 return result56;
}

// публикация в MQTT установленной температуры ГВС.
void publish_DHWSPtemp() {
 Serial.println("MQTT, DHW SP Temperature, °C = " + String(getDHWSPTemp()));
 String(getDHWSPTemp(), 0).toCharArray(buf, 50);
 client.publish("ESPClimat1/SPDHW_Temp_debug", buf);
 }

// получение установленной температуры ГВС из MQTT
void callback(char* topic, byte* payload, unsigned int length) {
 payload[length] = '\0';
 String strTopic = String(topic);
 String strPayload = String((char*)payload);
 if (strTopic == "ESPClimat1/DHW_SP") {
  spdhw = strPayload.toFloat();
  Serial.println("MQTT,topic spdhw = " + String(spdhw));
 }

// подписка и отправка данный на/из MQTT
publish_DHWSPtemp();
client.subscribe("ESPClimat1/DHW_SP");

Причин может быть миллион.  Не знаю как у Бошей - но у Бакси, пока не пошлешь правильную последовательность сообщений по версиям - ОпенТерм будет находится исключительно в режиме монитора - т.е. читать значения можно будет - писать фиг.  Ищите документацию на котел - че там можно сделать.   Так же посмотрите код ответа на setDHWTemp - че он там пишет

Да, нули он пишет...полагаю. Знакомо! К сожалению, проверять есть возможность только на своём Бакси и правильно написал OldNavi про последовательность сообщений, с Бакси, как то разобрались. Здесь в теме есть ещё один пользователь, VOVA_iS и с такой же проблемой, но котёл у него Корестар (Феролли). Ну не хочет он (котёл) отвечать, игнорит запрос на уставку ГВС. Так, что, только копать дальше... Ужасно интересно решение этой проблемы.  

Возможно не случайно в протоколе 56-й выделен как Remote parameter 1 

Нашел на ютубе видео  по управлению родными бошевскими OT термостатами, и там как раз говорится, установка ГВС работает только для котлов подключенных к бойлеру косвенного нагрева. А у меня обычный двух-контурный котел. Так, что похоже в пролете с этой настройкой.

А кстати как можно получить ответ бойлера на setDHWTemp, что нужно передать в Serial?

Согласно протокола ОТ - тебе ответ приходит и на запрос setDHWTemp... только ты его сразу оборачиваешь в  вызов ot.getTemperature() выкидывая все флаги состоояния (а тебя должен интересовать статус ответ и что там DATA_INVALID или еще что. А вообще нужно прочесть все конфигурационные флаги и параметры и посмотреть что тебе бойлер отвечает - (есть ли у него ГВС, какие пределы уставки ГВС. какой тип - проточный/накопительный ) и т.д.  Смотри мой код - там все есть. Ну и почитай спецификацию ОТ протокола.

Ну а если ГВС не регулируется - не велика потеря - у меня оно стоит константой на 48˚ -  главное уставка по отоплению работает то ?

RET, похоже вы докопались до истины, тем самым можно прекратить стенания по проблеме, которой, как оказывается, нет. Это, всего лишь, конструктивная особенность системы.

Регулировка CH через PID регулятор по данным с термодачика заработала сразу, пока правда только в тестовом режиме. На выходных будет похолодание, как раз посмотрю как отработает в реальных условиях.

По ГВС конечно жалко, но в целом, верно, не велика потеря. Остальные параметры кстати получаю исправно, статус горелки, модуляция, текущая температура ГВС. Единственное, при старте горелки, кратковременно теряется связь котлом (на 1-2 секунды) похоже или помеха от розжига или так же особенности Bosch'а.

А кто и что Вас интересует?

Здравствуйте. Интересует покупка готовой платы в сборе