Arduino.ru

В моем коде точно ошибки нет :-). Объясню что может происходить и что на что влияет.

Все зависит от сетевого сетапа с MQTT - помимо внешнего MQTT сервера, есть еще и промежуточной сетевой слой в виде TCP/IP, DNS и прочего.  В случае потери связи с миром  - происходит следующая бяка.   Если на контроллере прописан адрес MQTT сервера в виде имени хоста - MQTT клиент будет делать ресолвинг имени в IP адрес, отправляя сначала запрос DNS серверу роутера, тот будет пытаться разресолвить имя - но ответит с ошибкой только после тайм-аута TCPIP (+ все сетевые задержки).  Это обычно много больше 5 секунд  и как только MQTT reconnect() возвращается с ошибкой - то 5 секундная задержка уже "съедена" и мы опять идем делать reconnect() не давая времени поработать потоку кода который обслуживает работу с котлом - отсюда и потеря связи с котлом. Увеличение таймаута больше 5 секунд тоже бессмысленно (у TCPIP там порядка 30 секунд) - все равно этого уже много того что бы мешать потоку с OpenTherm обработкой.

Поэтому у  меня очень простой сетап - и оно специально так сделано. локальный MQTT сервер со статически прописаным адресом, в настройках OpenTherm контролера я тоже пишу IP адрес MQTT сервера, а не имя - это предотвращает запрос к DNS серверу и если MQTT сервер не доступен - MQTT reconnect отваливается тут же, без всяких тайм-аутов и все работает идеально даже если MQTT сервер сдох.

OldNavi, воспользовался Вашим советом писать IP адрес MQTT сервера, спасибо. Но проблему разрешил по другому, т.к. использую библиотеку ESP8266HTTPClient.h, то грех было не воспользоваться пингом сайта из примера к библиотеке, тем самым, на время потери связи с внешним миром, блокирую цикл MQTT. 

Использование IP адреса для внешнего брокера, который не свой - бывает тоже чревато. Вдруг владелец брокера перетащит его на другой IP адрес, просто изменив запись в DNS ? Да и как-то вообще, может я и параноик, но давать возможность управления котлом каким то левым чувакам - точно не буду. Технологически доступ к своему оборудованию извне, я предпочитаю делать совсем другим способом.

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

Всё же, у себя решил отказаться от MQTT reconnect в его классическом виде и то же пингую, но IP адрес MQTT сервера.

MQTT сервер может жить, а сам сервис нет, более правильно PINGREQ слать серверу и ждать ответ несколько секунд.

у меня затык может быть был из-за сложности сети, в цепочке три роутера вайфай за NAT

если в мире TCP/IP ничего не изменилось, то 5 )))

Всё же, не нравится мне работа с библиотекой PubSubClient... Попробую перейти на AsyncMqttClient. На GitHub лежит, на мой взгляд, универсальная библиотека, в которую вошли и AsyncMqttClient, и ESPAsyncTCP, и ESPAsyncWebServer, и много ещё чего... Библиотека работает с web конфигуратором, удобно https://github.com/homieiot/homie-esp8266. Пока разбираюсь... OpenTherm ещё не подключал. WEB сервер с датчиком поднял, MQTT уже поднят. В общем, увлекательно :).

Ну, что... Первые впечатления от AsyncMqttClient вполне хорошие:

00:06:53.121 -> Uptime = 0 d 00:00:30
00:06:54.118 -> Uptime = 0 d 00:00:31
00:06:55.105 -> Uptime = 0 d 00:00:32
00:06:55.291 -> Connecting to MQTT...
00:06:56.108 -> Uptime = 0 d 00:00:33
00:06:57.082 -> Uptime = 0 d 00:00:34
00:06:58.109 -> Температура = 20.28 °C
00:06:58.109 -> Ping - false
00:06:58.109 -> Uptime = 0 d 00:00:35
00:06:59.096 -> Uptime = 0 d 00:00:36
00:07:00.081 -> Uptime = 0 d 00:00:37
00:07:01.112 -> Uptime = 0 d 00:00:38
00:07:02.096 -> Uptime = 0 d 00:00:39
00:07:03.081 -> Температура = 20.28 °C
00:07:03.081 -> Ping - false
00:07:03.081 -> Uptime = 0 d 00:00:40
00:07:04.112 -> Uptime = 0 d 00:00:41
00:07:04.428 -> ** Disconnected from the broker ** 0WiFi: 1Uptime = 0 d 00:00:42
00:07:06.086 -> Uptime = 0 d 00:00:43
00:07:07.104 -> Uptime = 0 d 00:00:44
00:07:08.102 -> Пишем в EEPROM
00:07:08.102 -> temp = 20.34
00:07:08.102 -> Температура = 20.34 °C
00:07:08.102 -> Ping - false
00:07:08.102 -> Uptime = 0 d 00:00:45
00:07:09.125 -> Uptime = 0 d 00:00:46
00:07:09.415 -> Connecting to MQTT...
00:07:09.588 -> ** Connected to the broker **
00:07:09.588 -> Session present: 
00:07:09.588 -> 1
00:07:09.588 -> Subscribing: 
00:07:09.588 -> ds/termometr/set
00:07:09.588 -> {"sensor":"termometr","ds_temp":20.34,"set_zero":0.09}
00:07:09.658 -> ** Subscribe acknowledged **
00:07:09.658 ->   packetId: 1
00:07:09.658 ->   qos: 1
00:07:09.705 -> ** Published acknowledged **  packetId: 2
00:07:09.705 -> 
00:07:10.124 -> Uptime = 0 d 00:00:47
00:07:11.111 -> Uptime = 0 d 00:00:48
00:07:12.121 -> Uptime = 0 d 00:00:49
00:07:13.076 -> Пишем в EEPROM
00:07:13.076 -> temp = 20.28
00:07:13.111 -> Температура = 20.28 °C
00:07:13.111 -> Ping - true

Uptime не тормозит при попытке зацепиться к серверу. Пока проверял на беспроводном датчике. При тех же самых условиях PubSubClient вешал весь процесс на не позволительно долгое время...

а через пару тройку суток непрерывной работы будет так же хорошо функционировать без единого зависания?

Посмотрю... Пока работает.

andycat, можете сами проверить, лежит тут https://yadi.sk/d/Qcu-3S7WqdUTHg

Serial подключен (115200). Прошивка термометра на DS18B20, использую библиотеки:

#include <FS.h>
#include <ESP8266WebServer.h>
#include <ESP8266mDNS.h>
#include <ESP8266WiFi.h>
#include <ESP8266HTTPUpdateServer.h>
#include <WiFiClient.h>
#include <WiFiManager.h>
#include <DallasTemperature.h>
#include <ArduinoJson.h>
#include <Ticker.h>
#include <AsyncMqttClient.h>

#include "Eprom.h"
#include "index.h"
#include "log.h" 
#include "donate.h"

#define ONE_WIRE_BUS 14                      // D5 DS18B20
#define TEMPERATURE_PRECISION 12 

p.s. Заменил библиотеку клиента и в термостате, нет тормозов! Склоняюсь к тому, чтобы всю прошивку на асинхронные библиотеки перевести.

не, спасибо, предпочитаю с MQTT без библиотек общаться.

рад за вас что работает!

Единственный недостаток AsyncMqttClient - весит много, но совсем не портит основного процесса. С PubSubClient так же удалось получить относительно бесперебойную работу путём редактирования самой библиотеки, теперь буду проверять временем какой прошивке отдать предпочтение, главное, чтобы процесс OpenTherm не портили... Ещё один плюсик в пользу AsyncMqttClient, IoT MQTT Panel на смартфоне мгновенно читает нужные топики, с PubSubClient это происходит с задержкой.

Добрый день.

Подскажите пожалуйста почему может не работать команда

ot.setBoilerTemperature(set_temperature);

котел Bosch 6000 никак не реагирует, чтение данных при этом происходит корректно.

Есть какой то дебаг/лог при использовании  библиотеки #include <OpenTherm.h>?

Куда копать? Спасибо!

Забили всю тему непонятным кодом, который и читать то никто не будет...

 RET, проверил свою прошивку на двух котлах Bosch GAZ 6000. ГВС полностью управляется.

Не поделитесь вашей логикой доработки PubSubClient для улучшения стабильности работы?

Да, я уже тоже разобрался. Там так же как и с отоплением, надо на самом котле установить температуру ГВС на максимум, а потом уже через OT выставлять что нужно, тогда работает как положено.

Некоторые котлы, всё же, не принимают. Не понимаю почему, хотя и имеют соответствующий атрибут в true.

В итоге, я полностью исключил её из проекта!

Использую AsyncMqttClient

Это я уже понял. Я хотел бы понять, какие доработки PubSubClient вы сделали для улучшения стабильности ее работы?

На вскидку, игрался с таймаутом socket и интервалом keepalive, а так, даже сравнить не смогу. Снёс я её...

В примере [mqtt_esp8266] классического использования библиотеки PubSubClient при потере соединения с MQTT-брокером запускается беспрерывный и бесконечный цикл попыток восстановить коннект, что, естественно, приводит к полной блокировке кода. В другом примере [mqtt_reconnect_nonblocking] использования той же библиотеки попытка восстановить коннект делается уже в основном цикле через заданные промежутки времени (5 сек), что кажется вполне разумным и не приводит к полной блокировке кода.

В примере [FullyFeatured-ESP8266] из библиотеки AsyncMqttClient при потере соединения с MQTT-брокером происходит одна(!!!) попытка восстановить коннект и в случае неудачи на этом все заканчивается. Конечно можно доработать код и делать повторные попытки через какое-то время (те же 5 сек например), но хочется спросить, а в чем тогда собственно разница? Разве что в удобстве работать по событиям, а не по таймеру...

miks69, асинхронная библиотека работает с Ticker(ом). Плохо просмотрели пример:

mqttReconnectTimer.once(2, connectToMqtt);

В примере 2 сек.

mqttReconnectTimer.once(2, connectToMqtt);

А в чем принципиальная разница между тикером и обычным таймером в основном цикле?
И обратите внимание на ключевое слово [once], т.е. однократный запуск )))

А тут нужно уже залезть в библу Ticker(а).

Так я уже залез и посмотрел. Ticker работает на основе программного таймера _ETSTIMER_, т.к. аппаратных таймеров в ESP все равно нету.

Если глянуть в примере к AsyncMqttClient в блоке setup перечислены все функции обратного вызова, они будут автоматически вызываться по необходимости.

Вы совершенно правы, конечно они будут вызываться по соответствующим событиям. Вопрос в другом. Если мы говорим о блокировке работы кода библиотекой PubSubClient, то, как я уже написал, проблема не в библиотеке, а в способе ее использования, а именно вызова функции [reconnect].

При этом существенной разницы между корректным использованием PubSubClient и использованием AcyncMQTTClient я лично не вижу.

Также я обратил внимание на тот факт, что в примере использования библиотеки AcyncMQTTClient вызов реконнекта выполняется разово, т.е. при пропадании связи с брокером более чем на 5-10 сек повторного реконнекта не произойдет. Можете сами проверить и убедиться.

Помимо этого надо также понимать, что AsyncMQTTClient использует библиотеку ESPAsyncTCP, т.е. вам надо весь сетевой обмен перестраивать на работу с этой библиотекой (AsyncWebServer и т.д.).

С библиотекой PubSubClient я распрощался... Всё!

С библиотекой AsyncMqttClient работаю и без ESPAsyncTCP, как ни странно и примеров этому полно... Блокировка меня уже не волнует, ибо её нет. При восстановлении связи ни чего не виснет и дёргать ни чего не надо. Я доволен.

Да, была мысль перейти и на AsyncWebServer, но не стал этим заморачиваться, т.к. цель моя достигнута.

Котел Ferroli bluesense(helix) 

где ОТ1 ОТ2 (PWM) точки подключения ?

заранее спасибо

Обычно такую информацию можно найти в документации.
А кто вам вообще сказал, что данная модель поддерживает управление по протоколу OT?

Судя по документации 72 - это точка подключения комнатного термостата. Можно предположить, что именно это и есть клеммы для внешнего управления котлом.

Или дискретный(72), или ОТ(139), перемычку удалить.

да 72 подключен термостат ком.

на Украине где можно купить готовую плату для ESP8266 ?

Google в помощь )))

это он ?

котел поддерживает Open therm ?

пульт или термостат ?

На схеме, 139 маркировка ОТ. Другого ОТ протокола не существует.

понял ,спасибо всем 

А, что, пульт не может быть термостатом, или контроллером, или климатическим регулятором?

Модуль с ESP8266 сама по себе готовая плата. Вам адаптер нужен ОТ? http://ihormelnyk.com/opentherm_adapter

подскажите ваш софт возможна работа с моим ОТ совместимыми комманды 100% газовыми котлами Ferroli bluesens 422 ?

knt58dualtv, работать то будет, протокол един, если соблюдается. Но вопрос должен быть о другом, какие параметры и возможности ОТ будут доступны конкретной модели. Тут в теме выложена ссылка https://github.com/OldNavi/OpenThermController на прошивку от OldNavi, в ней есть сканер протокольных ID, поймёте какие валидные и оцените возможности своего котла. Моя прошивка и проект OldNavi использует одну библиотеку ОТ (хотя моя модифицированная, но сути не меняет).

OldNavi, компилятор выдаёт ошибку 

class OpenTherm has no member named 'getTemperature'

библиотеку использую https://github.com/ihormelnyk/opentherm_library

    case OpenThermMessageID::Tboiler: