@OldNavi, спасибо за пояснения работы вашего кода. На мой взгляд такая (псевдо)многопоточность это конечно вариант, но я пошел другим путем. Запросы из скетча отправляются последовательно в заданной логике в асинхронном режиме при наличии готовности шины, а вызов метода для процессинга вынесен в основной цикл скетча. Получение и разбор ответа скетчем также происходит через responseCallback. Таким образом скетч тратит сремя только на отправку запроса (около 35 мс), а все остальное время ожидания и приема ответа (около 150 мс до получения ответа + 100 мс паузы до готовности к отправке след.запроса) полностью используется скетчем.
Моя система пока находится в режиме тестирования и отладки. Вроде все работает, запросы-ответы проходят без ошибок. Вот только не могу понять почему-то не проходит установка температуры (CH setpoint и DHW setpoint)? Нужно ли для этого отправлять запрос MasterType/MasterVersion? Подскажите, из каких соображений вы отправляете код 0x013F?
Почему-то мой котел Buderus U072 не отвечает на многие запросы, описанные в документации OpenTherm v2.2, например, не выдает CH water pressure (18), DHW flow rate (19), Дату (20-22), Return water temperature (28), Burner starts (116), CH pump starts (117), Burner operation hours(120), CH pump operation hours (121).
Заметил еще одну интересную вещь. На запрос статуса (0), выдает Slave status 0x80, т.е. бит 7 = 1, но в документации нет инфромации о назначении данного флага. Может у кого есть инфо на эту тему?
#139 смотри, производители кладут болт на полную поддержку спецификации, довольствуемся тем, что есть.
Спасибо за ссылку. В принципе я уже понял, что придется довольствоваться тем, что есть. Кстати, у меня на запрос Number of TSPs (10) выдает SUCCESS и данные 0x00, т.е. Number of transparent-slave-parameter
supported by the slave device = 0. Такое бывает )))
по поводу мастер/слейв - у меня код OldNavi тоже не заработал, сделал как у tsv_33 в #102 - всё подключилось и начало принимать установку температуры
В приведенном коде после запроса/установки статусов котла сразу делается установка температуры СО, после которой еще делается установка мастер-кода MemberID = 0x0004 и потом уже установка температуры ГВС и запрос текущих температур контуров СО и ГВС.
У меня все тоже самое, только мастер-MemberID устанавливается в соответствии с Slave-MemberID (в моем случае 0x08), как у @OldNavi, а установка температуры почему-то не происходит, хотя котел возвращает SUCCESS.
Заметил еще одну интересную вещь. На запрос статуса (0), выдает Slave status 0x80, т.е. бит 7 = 1, но в документации нет инфромации о назначении данного флага. Может у кого есть инфо на эту тему?
Попробовал задавать другой мастер-код MemberID = 0x04, результат тот же, установку температуры не принимает. Боюсь этот флаг в статусе котла неспроста...
И еще там же IDs, которые отсутствуют в документации OpenTherm:
ID110: Electricity producer hours
ID111: Electricity production
ID112: Cumulativ Electricity production
ID113: Number of un-successful burner starts
ID114: Number of times flame signal was too low
Я так понимаю это для случая газового электрогенератора, но причем тут мой Buderus?
Кажется я понял причину почему мой котел не принимает установку температуры СО. Запрос max CH water setpoint (57) выдает 40 град, т.е. выше не поставишь. При этом на попытку записать ему другое значение просто не отвечает. Теперь пытаюсь понять в чем может быть засада...
С установкой max CH water setpoint разобрался, была ошибка в коде. Установку более высокого значения котел принял, но установка текущего CH setpoint по-прежнему не проходит. Запрос котел принимает, отвечает WRITE_ACK, но значение не изменяет. Может кто подскажет куда копать?
С установкой max CH water setpoint разобрался, была ошибка в коде. Установку более высокого значения котел принял, но установка текущего CH setpoint по-прежнему не проходит. Запрос котел принимает, отвечает WRITE_ACK, но значение не изменяет. Может кто подскажет куда копать?
У меня на Bosch 6000 максимальную температуру подачи можно только с панели задать. После этого уже работает по заданной через OT во всём диапозоне своих возможностей.
@RET, спасибо за ваш комментарий, который натолкнул меня на мысль, что в моем случае управление по OpenTherm также может зависеть от ручного управления. Именно так и оказалось, что удаленная установка температуры подачи зависит от ручной установки. После того, как я вручную установил температуру подачи выше, котел начал принимать удаленную установку, но в пределах ручной установки. Вот так бывает. Хотя в документации об этом конечно же ничего не сказано.
OldNavi, как ведёт себя ваш контроллер при отсутствии связи с инетом, с mqtt в частности? Не блокируется процесс основных циклов функцией reconnect? Встроенный веб сервер запускается?
MD поддерживает отправку значений, это у меня реализовано для реле управления.
Но когда пытаюсь установить значение для любого из параметров, получаемых от ОТ контроллера, они не уходят на контроллер, а спустя 5 секунд перезаписываются в моих значениях на MD.
Может кто использует MD в своих целях, подскажет что я делаю не так?
Правильно ли я понимаю, что любой из параметров который мне нужно задать я пишу в MQTT opentherm/cmnd топик сообщение в виде json c атрибутом нужного мне параметра?
MQTT конечно хорошо, но, я не зря задал вопрос уважаемому OldNavi про поведение его прошивки при отсутствии связи с Интернетом. Может быть для каких иных целей это пустяк, с которым можно смириться, но не с газовым оборудованием... Полагаю, функцию reconnect автору лучше переписать, т.к. она, всё же, блокирует процесс основных циклов в отсутствии связи. Когда почти пол дня у меня не было связи по причине обрыва оптики, то как раз и столкнулся с такой малоприятной проблемой. В своем проекте я переписал аналогичную часть кода, стало возможным контролировать и управлять работой контроллером локально с веб сервера.
itf1, leonzone, вы используете код OldNavi, если не трудно, проверьте работу контроллера при отсутствии связи с Интернетом.
Режим работы регулятора = ПИД
Статус = оффлайн
Горелка включена = 0
Температура котла = 0.00
Температура ГВС = 0.00
Температура на улице = 0.00
Температура в доме = 20.00
Установка котла = 0.00
Установка ГВС = 50.00
Установка Котла при регуляторах = 0.00
Отопление разрешено = 0
ГВС разрешено = 0
Охлаждение разрешено = 0
Контур отопления вкл = 0
Контур ГВС вкл = 1
Контур Охлаждения вкл = 0
Компенсация внешней температуры = да
Компенсация комнатной температуры = да
Сервис требуется = нет
----------- Конфигурация ---------------
Границы установок контура отопления = от 0 до 0
Границы установок контура ГВС = от 0 до 0
ГВС встроен = 0
Тип управления = Модуляция
ГВС = проточная
Наклон эквитермической кривой = 1.50
----------- Статусы ---------------
Ошибка котла = 0
Код ошибки = E0
Сервис требуется = нет
Удаленный сброс разрешен = нет
Ошибка низкого давления воды = нет
Ошибка по газу/огню = нет
Ошибка по тяге воздуха = нет
Перегрев теплоносителя = нет
Я хочу задать температуру к примеру 21 градус, которая должна поддерживаться в помещении, но не могу понять - в какой из параметров я это должен указать.
Заранее прошу прощения, т.к. только разбираюсь в этом устройстве.
не совсем понимаю что вы хотите проверить? у меня всё управление только через MQTT, который локально, мне наличие интернета - без разницы абсолютно.
а если сдохнет малина с тем самым MQTT, то я просто пойду и включу котел руками - без нее всё равно управлять бессмысленно, ибо температуру в квартире/на улице я всё равно с нее получаю
и в чём собственно паника про "газовое оборудование"? мы ж не напрямую горелкой с модуляцией управляем, а так, "просим".
Ну у меня mqtt сервер локальный на малинке стоит, там же где установлен HA. И все это оборудование включая роутер запитано от UPS котла. Поэтому MQTT у меня не пропадет. Но в случае ухода в реконнект по MQTT - сам котел видит что мастер пропал и продолжает работу по ручным установкам - т.е. котел не встанет, поэтому не считал эту проблему проблемой как таковой.
PS: Если кто хочет переписать - добро пожаловать - сделайте пул-реквест с изменениями и я смерджу в ветку.
Это все статус страница - если что то хотите поменять через веб-сервер - то надо делать POST запрос, ровно с таким же json-payload как и в MQTT - по url управления http://server-address/command
В данный момент работаю на котлом IMMERGAS MINI EOLO.В документации написано что он работает с собственным протоколом IMG_BUS.Подключил модуль,температура ГВС управляется,режим СО отключается-включается.Температуру считываю.Подтверждение на изменение температуры CO подтверждается со стороны котла,но не изменяется.MaxCHwatersetpoint установлен на 80 градусов.Вопрос может показаться глупым,быть может есть у кого то мнения по этому поводу?
OldNavi, решил попробовать как работает JSON, естественно на вашем проекте. Как бы всё понятно, данные на брокер прилетают (работаю с внешним CloudMQTT), да и с брокера, уставки, то же, но не перезаписываются!!! Да, еще, кажись, ошибку в коде нашёл. Как раз пытал и пытаю уставку ГВС, переменная dhw_temp_set. В коде:
OldNavi, решил попробовать как работает JSON, естественно на вашем проекте. Как бы всё понятно, данные на брокер прилетают (работаю с внешним CloudMQTT), да и с брокера, уставки, то же, но не перезаписываются!!!
Тут вот не понял, в чем вопрос - что значит не перезаписываются ?
Да, здесь у меня очепятка при копировании получилась,
Я про нее знаю, однако так получилось, что переделывать не стал - поскольку входящий json (то что мы шлем в топик opentern/cmd) совсем не одно и тоже, что мы получаем от контроллера в топик openterm/state. Технически, для единообразия надо бы поправить - но мне тогда надо скрипты в HomeAssistant править, пока идет отопительный сезон - у меня правило не трогать то, что работает :-)
золотое правило! я тут недавно решил проверить получит ли HA ошибку, первое что пришло в голову - перекрыть газ. вроде же безобидная процедура? HA отработал как надо, но...
котёл свалился в "замените электронную плату драйвер газового клапана" и всё тут, на сбросы/перезапуски/отключения питания/любые танцы с бубном никак не отзывался. погуглил, реально с платами такое бывает, цена 12к. шок о_О
короче каким то чудом со 100500й попытки через часа полтора ошибка сбросилась и котёл завёлся. с тех пор ну его в баню трогать, пусть греет до лета)))
Это я уже понял. Я сейчас с другой проблемой столкнулся, поднял в контроллер ESP8266HTTPClient, дабы парсить с другого ESP в json формате температуру (нет пока локального mqtt). Есть другой сервер, но он проводной, отдаёт в сеть, то же в json, с него парсится на ура, но с esp источника контроллер уходит почти сразу в ребут, но данные успевает принять.
А это к кому вопрос ? Если - мой проект - то смотри ветку platformio в моем коде на гитхабе. Там в platformio.ini все библиотеки расписаны - да и вообще, собирать через platformio гораздо удобнее, только надо освоить либо командную строку - либо использовать VSCode и plugin PlatformIO - гораздо лучше ардуино IDE.
В новой прошивке 16.04 на главный экран добавил вывод давления в контуре отопления (только для котлов где это реализовано). Немного модифицировал веб интерфейс, применил переключатели. В прошивку встроил функцию "комфорт". Всё, что касается подробностей по существу темы лежит здесь: https://yadi.sk/d/Qcu-3S7WqdUTHg
p.s. OldNavi, как и раньше, наблюдал проблемы обмена данными девайса с котлом при разрыве связи с mqtt и не важно локальным или внешним. Какой бы надёжной связь не была, но бывает всякое... Ручные уставки в случае ухода в реконнект по mqtt то же не плохо, но не приятно. Пробовал вашу прошивку, вроде подходы в реализации проекта разные, да и nonblocking поднят, но результат практически тот же :(.
Полагаю, на такой случай, нужно полностью блокировать (временно до устранения) процесс работы с mqtt, в ручном режиме отключал процесс, проблем с обменом данными не было. Теперь надо, как то автоматизировать...
@OldNavi, спасибо за пояснения работы вашего кода. На мой взгляд такая (псевдо)многопоточность это конечно вариант, но я пошел другим путем. Запросы из скетча отправляются последовательно в заданной логике в асинхронном режиме при наличии готовности шины, а вызов метода для процессинга вынесен в основной цикл скетча. Получение и разбор ответа скетчем также происходит через responseCallback. Таким образом скетч тратит сремя только на отправку запроса (около 35 мс), а все остальное время ожидания и приема ответа (около 150 мс до получения ответа + 100 мс паузы до готовности к отправке след.запроса) полностью используется скетчем.
Моя система пока находится в режиме тестирования и отладки. Вроде все работает, запросы-ответы проходят без ошибок. Вот только не могу понять почему-то не проходит установка температуры (CH setpoint и DHW setpoint)? Нужно ли для этого отправлять запрос MasterType/MasterVersion? Подскажите, из каких соображений вы отправляете код 0x013F?
Почему-то мой котел Buderus U072 не отвечает на многие запросы, описанные в документации OpenTherm v2.2, например, не выдает CH water pressure (18), DHW flow rate (19), Дату (20-22), Return water temperature (28), Burner starts (116), CH pump starts (117), Burner operation hours(120), CH pump operation hours (121).
Заметил еще одну интересную вещь. На запрос статуса (0), выдает Slave status 0x80, т.е. бит 7 = 1, но в документации нет инфромации о назначении данного флага. Может у кого есть инфо на эту тему?
#139 смотри, производители кладут болт на полную поддержку спецификации, довольствуемся тем, что есть.
по поводу мастер/слейв - у меня код OldNavi тоже не заработал, сделал как у tsv_33 в #102 - всё подключилось и начало принимать установку температуры
#139 смотри, производители кладут болт на полную поддержку спецификации, довольствуемся тем, что есть.
Спасибо за ссылку. В принципе я уже понял, что придется довольствоваться тем, что есть. Кстати, у меня на запрос Number of TSPs (10) выдает SUCCESS и данные 0x00, т.е. Number of transparent-slave-parameter
supported by the slave device = 0. Такое бывает )))
по поводу мастер/слейв - у меня код OldNavi тоже не заработал, сделал как у tsv_33 в #102 - всё подключилось и начало принимать установку температуры
В приведенном коде после запроса/установки статусов котла сразу делается установка температуры СО, после которой еще делается установка мастер-кода MemberID = 0x0004 и потом уже установка температуры ГВС и запрос текущих температур контуров СО и ГВС.
У меня все тоже самое, только мастер-MemberID устанавливается в соответствии с Slave-MemberID (в моем случае 0x08), как у @OldNavi, а установка температуры почему-то не происходит, хотя котел возвращает SUCCESS.
Заметил еще одну интересную вещь. На запрос статуса (0), выдает Slave status 0x80, т.е. бит 7 = 1, но в документации нет инфромации о назначении данного флага. Может у кого есть инфо на эту тему?
Попробовал задавать другой мастер-код MemberID = 0x04, результат тот же, установку температуры не принимает. Боюсь этот флаг в статусе котла неспроста...
Нашел вот здесь - https://www.opentherm.eu/request-details/?post_ids=1833 пишут ID0:LB7: Slave Status: Electricity production )))
И еще там же IDs, которые отсутствуют в документации OpenTherm:
ID110: Electricity producer hours
ID111: Electricity production
ID112: Cumulativ Electricity production
ID113: Number of un-successful burner starts
ID114: Number of times flame signal was too low
Я так понимаю это для случая газового электрогенератора, но причем тут мой Buderus?
Кажется я понял причину почему мой котел не принимает установку температуры СО. Запрос max CH water setpoint (57) выдает 40 град, т.е. выше не поставишь. При этом на попытку записать ему другое значение просто не отвечает. Теперь пытаюсь понять в чем может быть засада...
С установкой max CH water setpoint разобрался, была ошибка в коде. Установку более высокого значения котел принял, но установка текущего CH setpoint по-прежнему не проходит. Запрос котел принимает, отвечает WRITE_ACK, но значение не изменяет. Может кто подскажет куда копать?
С установкой max CH water setpoint разобрался, была ошибка в коде. Установку более высокого значения котел принял, но установка текущего CH setpoint по-прежнему не проходит. Запрос котел принимает, отвечает WRITE_ACK, но значение не изменяет. Может кто подскажет куда копать?
У меня на Bosch 6000 максимальную температуру подачи можно только с панели задать. После этого уже работает по заданной через OT во всём диапозоне своих возможностей.
@RET, спасибо за ваш комментарий, который натолкнул меня на мысль, что в моем случае управление по OpenTherm также может зависеть от ручного управления. Именно так и оказалось, что удаленная установка температуры подачи зависит от ручной установки. После того, как я вручную установил температуру подачи выше, котел начал принимать удаленную установку, но в пределах ручной установки. Вот так бывает. Хотя в документации об этом конечно же ничего не сказано.
Подскажите пожалуйста функцию сброса ошибок котла.
Подскажите пожалуйста функцию сброса ошибок котла.
Только ручками, при личной оценке неисправности, ибо опасно это, дистанционно...
OldNavi, как ведёт себя ваш контроллер при отсутствии связи с инетом, с mqtt в частности? Не блокируется процесс основных циклов функцией reconnect? Встроенный веб сервер запускается?
Добрый день.
Залил скетч, но пока не подключал к котлу. Данные по MQTT уходят на сервер - использую MajorDomo...
По умолчанию температура отопления = 0, а ГВС=50... Не могу понять, как отправлять значения установки на устройство...
itf1, полагаю с клиента MQTT...
MD поддерживает отправку значений, это у меня реализовано для реле управления.
Но когда пытаюсь установить значение для любого из параметров, получаемых от ОТ контроллера, они не уходят на контроллер, а спустя 5 секунд перезаписываются в моих значениях на MD.
Может кто использует MD в своих целях, подскажет что я делаю не так?
записываешь в opentherm/status? а надо в opentherm/cmnd - #223
Спасибо!!!! В точку, все получилось.
Правильно ли я понимаю, что любой из параметров который мне нужно задать я пишу в MQTT opentherm/cmnd топик сообщение в виде json c атрибутом нужного мне параметра?
MQTT конечно хорошо, но, я не зря задал вопрос уважаемому OldNavi про поведение его прошивки при отсутствии связи с Интернетом. Может быть для каких иных целей это пустяк, с которым можно смириться, но не с газовым оборудованием... Полагаю, функцию reconnect автору лучше переписать, т.к. она, всё же, блокирует процесс основных циклов в отсутствии связи. Когда почти пол дня у меня не было связи по причине обрыва оптики, то как раз и столкнулся с такой малоприятной проблемой. В своем проекте я переписал аналогичную часть кода, стало возможным контролировать и управлять работой контроллером локально с веб сервера.
itf1, leonzone, вы используете код OldNavi, если не трудно, проверьте работу контроллера при отсутствии связи с Интернетом.
WEB сервер не отвечает, если нет связи с MQTT.
Заметил сразу, т.к. изначально не задавал параметры MQTT сервера, но как только задал - WEB сервер стал отвечать и выдавать параметры.
И еще, я не совсем понимаю логику работы кода...
Вот что мне выдает WEB сервер:
Я хочу задать температуру к примеру 21 градус, которая должна поддерживаться в помещении, но не могу понять - в какой из параметров я это должен указать.
Заранее прошу прощения, т.к. только разбираюсь в этом устройстве.
К библиотеке PubSubClient.h есть пример mqtt_reconnect_nonblocking адаптируйте его для функции reconnect и проверьте.
не совсем понимаю что вы хотите проверить? у меня всё управление только через MQTT, который локально, мне наличие интернета - без разницы абсолютно.
а если сдохнет малина с тем самым MQTT, то я просто пойду и включу котел руками - без нее всё равно управлять бессмысленно, ибо температуру в квартире/на улице я всё равно с нее получаю
и в чём собственно паника про "газовое оборудование"? мы ж не напрямую горелкой с модуляцией управляем, а так, "просим".
Ну у меня mqtt сервер локальный на малинке стоит, там же где установлен HA. И все это оборудование включая роутер запитано от UPS котла. Поэтому MQTT у меня не пропадет. Но в случае ухода в реконнект по MQTT - сам котел видит что мастер пропал и продолжает работу по ручным установкам - т.е. котел не встанет, поэтому не считал эту проблему проблемой как таковой.
PS: Если кто хочет переписать - добро пожаловать - сделайте пул-реквест с изменениями и я смерджу в ветку.
Это все статус страница - если что то хотите поменять через веб-сервер - то надо делать POST запрос, ровно с таким же json-payload как и в MQTT - по url управления http://server-address/command
Собственно добавил non-blocking reconnect для MQTT - проверяйте если кому надо.
В данный момент работаю на котлом IMMERGAS MINI EOLO.В документации написано что он работает с собственным протоколом IMG_BUS.Подключил модуль,температура ГВС управляется,режим СО отключается-включается.Температуру считываю.Подтверждение на изменение температуры CO подтверждается со стороны котла,но не изменяется.MaxCHwatersetpoint установлен на 80 градусов.Вопрос может показаться глупым,быть может есть у кого то мнения по этому поводу?
OldNavi, решил попробовать как работает JSON, естественно на вашем проекте. Как бы всё понятно, данные на брокер прилетают (работаю с внешним CloudMQTT), да и с брокера, уставки, то же, но не перезаписываются!!! Да, еще, кажись, ошибку в коде нашёл. Как раз пытал и пытаю уставку ГВС, переменная dhw_temp_set. В коде:
if (json.containsKey("dhw_temp")) { vars.dhw_temp_set.value = json["dhw_temp"] | 50.0; needWrite = true; }а обрабатываете dhw_temp, хотя в
всё верно, а для dhw_temp
Куда копнуть?
OldNavi, решил попробовать как работает JSON, естественно на вашем проекте. Как бы всё понятно, данные на брокер прилетают (работаю с внешним CloudMQTT), да и с брокера, уставки, то же, но не перезаписываются!!!
Тут вот не понял, в чем вопрос - что значит не перезаписываются ?
Да, здесь у меня очепятка при копировании получилась,
if(json.containsKey("dhw_temp"))2{3vars.dhw_temp_set.value = json["dhw_temp"] | 50.0;4needWrite =true;5}Я про нее знаю, однако так получилось, что переделывать не стал - поскольку входящий json (то что мы шлем в топик opentern/cmd) совсем не одно и тоже, что мы получаем от контроллера в топик openterm/state. Технически, для единообразия надо бы поправить - но мне тогда надо скрипты в HomeAssistant править, пока идет отопительный сезон - у меня правило не трогать то, что работает :-)
золотое правило! я тут недавно решил проверить получит ли HA ошибку, первое что пришло в голову - перекрыть газ. вроде же безобидная процедура? HA отработал как надо, но...
котёл свалился в "замените электронную плату драйвер газового клапана" и всё тут, на сбросы/перезапуски/отключения питания/любые танцы с бубном никак не отзывался. погуглил, реально с платами такое бывает, цена 12к. шок о_О
короче каким то чудом со 100500й попытки через часа полтора ошибка сбросилась и котёл завёлся. с тех пор ну его в баню трогать, пусть греет до лета)))
Тут вот не понял, в чем вопрос - что значит не перезаписываются ?
Клиентом отсылаю новую уставку в контроллер, но она не меняется, остаются начальные данные, те что изначально залиты в память.
золотое правило! ... первое что пришло в голову - перекрыть газ. вроде же безобидная процедура? HA отработал как надо, но...
Я датчик тяги дергаю, легко всё восстанавливается.
Точно в тот ли топик отправляете ? Хотя пофиг, на топик - скорее всего json payload неправильный, если можно покажите пример что шлете.
Поставил по умолчанию dhw_temp_set = 52.
Новое значение (51) шлю:
Received messages
DEBUG.println("MQTT received = " + strPayload);В мониторе принтов вижу что новое значение MQTT received = 51 в контроллер прилетает и на этом всё...
Хех, мы же общаемся при помощи json - соотвественно в топик надо слать сам json, т.е
отправить в openterm/cmnd следующий payload (json со всеми скобочками и кавычками, а не просто одно значение)
{ "dhw_temp": 52 }Вроде инструкцией клиента пользовался... json так json отправил весь со всеми скобочками и кавычками и о... чудо. Спасибо, буду изучать дальше.:-)
json хорош тем, что можно поменять много параметров сразу, перечислив их всех в json
{ "dhw_temp": 52, "heater_temp": 40 }и так далее
Это я уже понял. Я сейчас с другой проблемой столкнулся, поднял в контроллер ESP8266HTTPClient, дабы парсить с другого ESP в json формате температуру (нет пока локального mqtt). Есть другой сервер, но он проводной, отдаёт в сеть, то же в json, с него парсится на ура, но с esp источника контроллер уходит почти сразу в ребут, но данные успевает принять.
И это великолепно) я обновляю всегда сразу все параметры, одной автоматизацией в HA, удобно
У меня тоже такие проблемы частенько были, мне кажется из-за записи в EEPROM - вырезал и стало ок
У меня тоже такие проблемы частенько были, мне кажется из-за записи в EEPROM - вырезал и стало ок
С другого то источника, не esp работает...
Полагаю wifi вешается.
Для Ардуино IDE есть прекрасный плагин - Arduino Exception Decoder - очень помогает понять из-за чего падает железка. https://github.com/me-no-dev/EspExceptionDecoder
Спасибо. Про плагин знаю и пользуюсь. Только то, что выдает esp даже он декодировать не может, такая вот печалька :-(
Всем доброго дня!
Подскажите пожалуйста, чтобы собрать проект какие библиотеки необходимы?
Не могли бы написать полный список библиотек?
Спасибо
А это к кому вопрос ? Если - мой проект - то смотри ветку platformio в моем коде на гитхабе. Там в platformio.ini все библиотеки расписаны - да и вообще, собирать через platformio гораздо удобнее, только надо освоить либо командную строку - либо использовать VSCode и plugin PlatformIO - гораздо лучше ардуино IDE.
Огромное спасибо!
Не заметил ветку платформио )))
всё собралось. Еще раз большое спасибо.
Еще подскажите пожалуйста, будет ли это работать с таким шилдом? http://ihormelnyk.com/opentherm_adapter
Будет, у меня уж точно работает.
Обновил Core Version ESP8266 до 2.7.1 и библиотеки проекта, которые обновились. Приятно удивило, получил прирост свободной памяти.
Кстати, в библиотеку OpenTherm внесены изменения, пока не разбирался, в basic requests по ходу добавлены ещё 4 ID.
В новой прошивке 16.04 на главный экран добавил вывод давления в контуре отопления (только для котлов где это реализовано). Немного модифицировал веб интерфейс, применил переключатели. В прошивку встроил функцию "комфорт". Всё, что касается подробностей по существу темы лежит здесь: https://yadi.sk/d/Qcu-3S7WqdUTHg
p.s. OldNavi, как и раньше, наблюдал проблемы обмена данными девайса с котлом при разрыве связи с mqtt и не важно локальным или внешним. Какой бы надёжной связь не была, но бывает всякое... Ручные уставки в случае ухода в реконнект по mqtt то же не плохо, но не приятно. Пробовал вашу прошивку, вроде подходы в реализации проекта разные, да и nonblocking поднят, но результат практически тот же :(.
Полагаю, на такой случай, нужно полностью блокировать (временно до устранения) процесс работы с mqtt, в ручном режиме отключал процесс, проблем с обменом данными не было. Теперь надо, как то автоматизировать...