Разработка умных устройств на примере контроллера теплого пола на ESP8266

Хочу поделиться своим опытом разработки умного устройства. В этой публикации я опишу аппаратное (кратко) и программное (более подробно) обеспечение.

Контроллер предназначен анализировать показания датчиков (проводных и беспроводных) и поддерживать заданную (с учетом расписания, в т.ч. по дням недели) температуру в каждой отдельной зоне, путем включения/выключения котла и управления петлями водяного теплого пола с помощью термоголовок на коллекторе.

Аппаратное обеспечение


В качестве контроллера был выбран ESP8266 (WeMos D1 mini), как т.к. имеет WiFi на борту. Вместо ESP8266 может быть использован любой другой контроллер или микрокомпьютер – общие идеи останутся неизменными, главное чтобы на выбранной системе можно было бы развернуть WEB-сервер с поддержкой WEB-сокетов. В проекте так же были использованы:

  • RTC: DS3231 – надо же определять день недели и текущее время. Проект задумывался как автономное устройство, способное работать без интернета, поэтому NTP не подходит.
  • Беспроводные датчики температуры: NoName, 433МГц, от китайской метеостанции – готовое решение, работают от батареек. Что еще надо? А надо чтобы период передачи данных был не фиксированный. Проблема в том, что период передачи 35 секунд и не много плавает. И бывают ситуации, когда сигналы двух датчиков накладываются. В этом случае один или два датчика выпадают из системы на некоторое время. Проблему можно решить, используя похожие датчики, в которых переключение каналов так же изменяет период передачи данных.
  • Приемник 433МГц: Rxb6 – по обзорам в интернетах и личному опыту не плохой приемник.
  • Проводные датчики температуры: DS18B20 – очень удобны тем, что не требуется заранее знать количество датчиков.
  • Мастер шины 1Wire: DS2482-100 – протокол 1Wire очень чувствителен к таймингам, поэтому все реализации программного мастера шины используют delay, что очень не хорошо для многозадачности. Используя эту микросхему, можно использовать преимущества шины 1Wire и избавиться от ее недостатков за счет трансляции 1Wire <-> i2c. Протокол i2c имеет линию синхронизации, за счет чего не критичен к таймингам и часто в контроллерах реализован аппаратно.
  • Сторожевой таймер: TPL5000DGST – для данного проекта не столь важен непрерывный аптайм, однако доступность очень важна. В ESP8266 есть встроенный сторожевой таймер. Но как показала практика, иногда все же бывают ситуации, когда он не справляется и система зависает. Внешний аппаратный сторожевой таймер призван бороться с нештатными ситуациями. Сконфигурирован на задержку в 64сек. Присоединен к ноге TX – при работе система постоянно пишет в Serial отладочную информацию и отсутствие активности более одной минуты свидетельствует о зависании системы.
  • Расширитель портов: 74HC595 – использование этого расширителя требует 4х ног контроллера – три на передачу состояния и одну для того, чтобы при подаче питания реле не щелкали. В следующий раз буду использовать PCF8574 – шина i2c все равно используются, т.е. дополнительных ног MCU не требуется и при подаче питания выходы в 1 установлены.
  • Релейный модуль: NoName, 8-ми канальный, 5В – сказать нечего, кроме того, что включение реле происходит по низкому уровню на входах модуля. Твердотельные реле в данном проекте использовать недопустимо, т.к. коммутация контактов котла должна выполняться сухим контактом – в общем случае я не знаю напряжение и постоянный или переменный ток на контактах.

Операционная система


Операционная система – все то ПО, которое обеспечивает работоспособность прикладной программы. Операционная система так же является прослойкой между железом и прикладной программой, предоставляя высокоуровневый интерфейс доступа к аппаратным ресурсам. В случае ESP компонентами операционной системы можно считать:

Файловая система


В проекте используется SPIFFS, тут вроде все понятно, это самый простой путь. Для простого доступа к файлам на устройстве извне, я использую библиотеку nailbuster/esp8266FTPServer.

Система распределения процессорного времени


Это одна из основных функций операционной системы и ESP не станет исключением. За параллельное выполнение различных потоков алгоритма отвечает глобальный объект (синглтон) Timers. Класс достаточно простой и предоставляет следующий функционал:

  • Периодическое выполнение функции, с заданным интервалом. Пример инициализации таймера:

    Timers.add(doLoop, 6000, F("OneWireSensorsClass::doLoop")); // третий параметр – отладочная информация
  • Однократное выполнение функции через указанный промежуток времени. Например так выполняется отложенное сканирование WiFi сетей:

    Timers.once([]() { WiFi.scanNetworks(true);}, 1);

Таким образом функция loop выглядит подобным образом:

void loop(void) {
	ESP.wdtFeed();

	Timers.doLoop();

	CPULoadInfo.doLoop();
}

На практике функция loop содержит еще несколько строк, о них будет рассказано ниже.
Листинг класса Timers приложен.

Учет процессорного времени


Сервисная функция, не имеющая практического применения. Тем не менее она есть. Реализуется сингтоном CPULoadInfo. При инициализации объекта, выполняется замер количества итераций пустого цикла за небольшой промежуток времени:

void CPULoadInfoClass::init() {
	uint32_t currTime = millis();
	// определяем максимальное число циклов в 1сек
	while ((millis() - currTime) < 10) {
		delay(0);
		MaxLoopsInSecond++;
	}
	MaxLoopsInSecond *= 100;
}

Затем, считаем количество вызовов процедуры loop в секунду, считаем загрузку процессора в процентах и сохраняем данные в буфер:

void CPULoadInfoClass::doLoop() {
	static uint32_t prevTime = 0;
	uint32_t currTime = millis();
	LoopsInSecond++;
	if ((currTime - prevTime) > 1000) {
		memmove(CPULoadPercentHistory, &CPULoadPercentHistory[1], sizeof(CPULoadPercentHistory) - 1);

		int8_t load = ((MaxLoopsInSecond - LoopsInSecond) * 100) / MaxLoopsInSecond;
		CPULoadPercentHistory[sizeof(CPULoadPercentHistory) - 1] = load;

		prevTime = currTime;
		LoopsInSecond = 0;
	}
}

Использование этого подхода позволяет получить так же использование процессора каждым отдельным потоком (если соединить эту подсистему с классом Timers), но как я уже сказал – практического применения этому я не вижу.

Система ввода-вывода


Для общения с пользователем используется UART-USB и WEB интерфейс. Про UART думаю подробно рассказывать не требуется. Единственно на что стоит обратить внимание – для удобства и совместимости с не ESP реализована функция serialEvent():

void loop(void) {
	// …
	if (Serial.available())
		serialEvent();
	// …
}

С WEB интерфейсом все гораздо интереснее. Посвятим ему отдельный раздел.

WEB интерфейс


В случае с умными устройствами, по моему мнению, WEB интерфейс самое удобное для пользователя решение.

Использование экрана, подключенного к устройству, я считаю устаревшей практикой – невозможно при использовании небольшого экрана и ограниченного набора кнопок создать простой, удобный, красивый интерфейс.

Использование специфических программ для управления устройством – накладывает ограничения на пользователя, добавляет необходимость разработки и поддержки этих программ, а также требует от разработчика заботиться о доставке этих программ на терминальные устройства пользователя. По-хорошему, приложение должно быть опубликовано в магазинах приложений Google, Apple, Windows, а также доступно в репозиториях Linux в виде deb и rpm пакетов – в противном случае, для какой-то части аудитории может быть затруднен доступ к интерфейсу устройства.

Доступ к WEB интерфейсу устройства доступен с любой операционной системы – Linux, Windows, Android, MacOS, на десктопе, ноутбуке, планшете, смартфоне – лишь бы был браузер. Конечно разработчику WEB интерфейса необходимо учитывать особенности различных устройств, но это в основном касается размера и разрешения. Доступ к WEB интерфейсу умного устройства в доме/квартире/на даче легко обеспечивается извне через интернет – сейчас сложно представить дом/квартиру, в которых есть умные устройства и нет роутера и интернета, а в роутере такой доступ настраивается в несколько кликов (тем, кто совсем не в теме, помогут ключевые слова – «проброска портов» и «динамический DNS»). В случае дачи доступ можно обеспечить с помощью 3G роутера.

Для реализации WEB интерфейса необходим WEB сервер. Я использую библиотеку me-no-dev/ESPAsyncWebServer. Эта библиотека обеспечивает следующий функционал:

  • Отдачу статического контента, в т.ч. с поддержкой сжатия gzip. Поддерживаются виртуальные каталоги, с возможностью указания главного файла (который обычно index.htm) для каждого каталога.
  • Назначение callback функций на различные URL с учетом типа запроса (GET, POST, …)
  • Поддержка WEB сокетов на том же порту (это имеет значение при проброске портов).
  • BASIC авторизацию. Причем авторизация устанавливается индивидуально для каждого URL. Это важно, т.к. например Google Chrome при создании ярлыка страницы на главном экране, запрашивает иконку и файла манифеста и не передает данные авторизации. Поэтому часть файлов помещены в виртуальный каталог и для этого каталога авторизация отключена.

HTTP сервисы операционной системы


В текущем проекте все настройки операционной системы выполняются с помощью HTTP сервисов. HTTP сервис – это небольшой независимый функционал получения/изменения данных, доступный по HTTP. Далее рассмотрим список этих сервисов.

HELP


Реализацию любого списка команд я считаю правильным начать с реализации команды HELP. Ниже блок инициализации WEB сервера:

void HTTPserverClass::init()
{
	//SERVER INIT
	help_info.concat(F("/'doc_hame.ext': load file from server. Allow methods: HTTP_GET\n"));
	AsyncStaticWebHandler& handler = server.serveStatic("na/", SPIFFS, "na/");
	serveStaticHandlerNA = &handler; // виртуальный каталог в котором Нет Авторизации
	server.serveStatic("/", SPIFFS, "/"); // все остальные файлы
	
	//info
	// перед реализацией сервиса сформируем его описание
	help_info.concat(F("/info: get system info. Allow methods: HTTP_GET\n"));
	server.on("/info", HTTP_GET, handleInfo);
	
	…
	
	server.on("/help", HTTP_GET, [](AsyncWebServerRequest *request) { request->send(200, ContentTypesStrings[ContentTypes::text_plain], help_info.c_str()); });

	// устанавливаем параметры авторизации
	setAuthentication(ConfigStore.getAdminName(), ConfigStore.getAdminPassword());
	
	DefaultHeaders::Instance().addHeader("Access-Control-Allow-Origin", "*"); // разрешает кросс-доменные запросы

	// запускаем сервер
	server.begin();

	// макросы отладочной информации будут приложены отдельно
	DEBUG_PRINT(F("HTTP server started"));

}

Зачем нужна справочная система, рассказывать думаю не стоит. Некоторые разработчик откладывают реализацию справочной системы на потом, но этот «потом» как правило не наступает. Гораздо проще ее реализовать в начале проекта и при развитии проекта дополнять.
В моем проекте список возможных сервисов выводится так же и при ошибке 404 – страница не найдена. На данный момент реализованы следующие сервисы:

http://tc-demo.vehs.ru/help

/'doc_hame.ext': load file from server. Allow methods: HTTP_GET
/info: get system info. Allow methods: HTTP_GET
/time: get time as string (eg: 20140527T123456). Allow methods: HTTP_GET
/uptime: get uptime as string (eg: 123D123456). Allow methods: HTTP_GET
/rtc: set RTC time. Allow methods: HTTP_GET, HTTP_POST
/list ? [dir=...] & [format=json]: get file list as text or json. Allow methods: HTTP_GET
/edit: edit files. Allow methods: HTTP_GET, HTTP_PUT, HTTP_DELETE, HTTP_POST
/wifi: edit wifi settings. Allow methods: HTTP_GET, HTTP_POST
/wifi-scan ? [format=json]: get wifi list as text or json. Allow methods: HTTP_GET
/wifi-info ? [format=json]: get wifi info as text or json. Allow methods: HTTP_GET
/ap: edit soft ap settings. Allow methods: HTTP_GET, HTTP_POST
/user: edit user settings. Allow methods: HTTP_GET, HTTP_POST
/user-info ? [format=json]: get user info as text or json. Allow methods: HTTP_GET
/update: update flash. Allow methods: HTTP_GET, HTTP_POST
/restart: restart system. Allow methods: HTTP_GET, HTTP_POST
/ws: web socket url. Allow methods: HTTP_GET
/help: list allow URLs. Allow methods: HTTP_GET

Как видно, в списке сервисов отсутствуют какие-либо прикладные сервисы. Все HTTP сервисы относятся к операционной системе. Каждый сервис выполняет одну небольшую задачу. При этом если сервис требует ввода каких-либо данных, то по запросу GET возвращает минималистичную форму ввода:

#ifdef USE_RTC_CLOCK
	help_info.concat(F("/rtc: set RTC time. Allow methods: HTTP_GET, HTTP_POST\n"));
	const char* urlNTP = "/rtc";
	server.on(urlNTP, HTTP_GET, [](AsyncWebServerRequest *request) { DEBUG_PRINT(F("/rtc")); request->send(200, ContentTypesStrings[ContentTypes::text_html], String(F("<head><title>RTC time</title></head><body><form method=\"post\" action=\"rtc\"><input name=\"newtime\" length=\"15\" placeholder=\"yyyyMMddThhmmss\"><button type=\"submit\">set</button></form></body></html>"))); });
	server.on(urlNTP, HTTP_POST, handleSetRTC_time);
#endif // USE_RTC_CLOCK



В последствии этот сервис используется в более симпатичном интерфейсе:



Прикладное ПО


Наконец подошли к тому, ради чего система создавалась. А именно – к реализации прикладной задачи.

Любая прикладная программа должна получать исходные данные, обрабатывать их и выдавать результат. Так же, возможно, система должна сообщать текущее состояние.

Исходными данными для контроллера теплого пола являются:

  • Данные датчиков – система не привязана к конкретным датчикам. Для каждого датчика формируется уникальный идентификатор. Для радио-датчиков их идентификатор дополняется до 16 бит нулями, для датчиков 1Wire на основании их внутреннего идентификатора вычисляется CRC16 и используется в качестве идентификатора датчика. Таким образом, все датчики имеют идентификаторы длиной 2 байта.
  • Данные о зонах отопления – число зон не фиксировано, максимальное количество ограничено используемым модулем реле. С учетом этого ограничения так же разрабатывался WEB интерфейс.
  • Целевая температура и расписание – я постарался сделать максимально гибкие настройки, можно создать несколько схем отопления и можно даже на каждую зону назначить свою схему настроек.

Таким образом есть некоторое количество настроек, которые надо как-то задавать, и есть некоторое количество параметров, которые система сообщает как текущее состояние.
Для общения контроллера с внешним миром я реализовал командный интерпретатор, который позволил реализовать как управление контроллером, так и получать данные о состоянии. Команды передаются контроллеру в человекочитаемом виде, и могут передаваться через UART или WEB сокет (при желании можно реализовать поддержку других протоколов, например telnet).
Строка команд начинается со знака '#' и оканчивается нулевым символом либо символом перевода строки. Все команды состоят из имени команды и операнда, разделенных двоеточием. Для некоторых команд операнд не обязателен, в этом случае двоеточие и операнд не указываются. Команды в строке разделяются запятой. Например:

#ZonesInfo:1,SensorsInfo

И конечно же список команд начинается с команды Help, которая выводит список всех допустимых команд (передаваемые команды для удобства восприятия начинаются со знака '>' вместо '#'):

>help
Help
SetZonesCount
Zone
SetName
SetSensor
...
LoadCfg
SaveCfg
#Cmd:Help,CmdRes:Ok

Особенностью реализации командного интерпретатора является то, что информация о результате выполнения команды выдается так же в виде команды или набора команд:

>help
…
#Cmd:Help,CmdRes:Ok

>zone:123
#Cmd:Zone,Value:123,CmdRes:Error,Error:Zone 123 not in range 1-5

>SchemasInfo
#SchemasCount:2
#Schema:1,Name:Основная,DOWs:0b0000000
#Schema:2,Name:Гараж,DOWs:0b0000000
#Cmd:SchemasInfo,CmdRes:Ok

На стороне WEB клиента так же реализован командный интерпретатор, который принимает эти команды и преобразует их в графический вид. Например:

>zonesInfo:3
#Zone:3,Name:Спальня,Sensor:0x5680,Schema:1,DeltaT:-20
#Cmd:ZonesInfo,CmdRes:Ok

WEB интерфейс передал запрос контроллеру о зоне номер 3, и получил в ответ название зоны, идентификатор датчика, привязанного к зоне, идентификатор схемы, назначенной зоне и коррекцию температуры для зоны. Командный интерпретатор не понимает дробных чисел, поэтому температура передается в десятых долях градуса, т.е. 12.3 градуса это 123 десятых долей.

Ключевой особенностью является то, что на любую команду, вне зависимости от способа ввода команды, контроллер отвечает сразу всем клиентам. Это позволяет отображать изменение состояния сразу во всех сеансах WEB интерфейса. Т.к. основной транспорт обмена между контроллером и WEB интерфейсом это WEB сокеты, то контроллер может передавать данные без запроса, например когда приходят новые данные от датчиков:

#sensor:0x5A20,type:w433th,battery:1,button_tx:0,channel:0,temperature:228,humidity:34,uptime_label:130308243,time_label:20180521T235126

Или о том например, что данные зоны необходимо актуализировать:

#Zone:2,TargetTemp:220,CurrentTemp:228,Error:Ok

WEB интерфейс контроллера построен на использовании текстовых команд. На одной из закладок интерфейса имеется терминал, с помощью которого можно вводить команды в текстовом виде. Так же эта закладка, в целях отладки, позволяет узнать какие команды отправляет и получает WEB интерфейс при различных действиях пользователя.

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

Заключение


Использование подобного подхода, а именно:

  • Разделение ПО на операционную систему и прикладную программу
  • Реализация настроек операционной системы в виде минималистичных HTTP сервисов
  • Отделение логики системы от представления данных
  • Использование человекочитаемых протоколов обмена данными

позволяет создавать решения, которые понятны как пользователям, так и разработчикам. Подобные решения легко модифицировать. На базе подобных решений легко строить новые устройства, с совершенно другой логикой, но которые будут работать на тех же принципах. Можно создавать линейки устройств, с однотипным интерфейсом:



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

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

Кому интересна данная тема – пишите, может я в чем-то не прав, а может быть какие-то детали имеет смысл описать более подробно.

Что получилось в итоге: Фиаско. История одной самоделки IoT
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 53

    0
    В ESP8266 есть встроенный сторожевой таймер. Но как показала практика, иногда все же бывают ситуации, когда он не справляется и система зависает.

    У меня часы на esp8266 работают уже больше года. Не виснут.

      +1
      Значит, вы или я что-то делаем не так.
      Если ваши часы зависнут — вряд ли случится что-то плохое.
      А если встанет система отопления, зимой, когда все уехали в отпуск — это большая проблема. Стоимость микросхемы сторожевого таймера (100р) мизерна по сравнению с ущербом при разморозке труб водоснабжения и отопления
        0
        И всё же, когда есть хоть какой-то риск заморозить отопление, лучше применять не воду, а специальный теплоноситель-незамерзайку. Не такие уж большие деньги в сравнении с последствиями аварии.
          +1
          Не во все котлы можно заливать незамерзайку, в некоторые только воду.
          0
          Если ваши часы зависнут — вряд ли случится что-то плохое.

          Ну как не случится, это сильно ударит по моему эго мне это сильно не понравится;) Поэтому хорошо что они не виснут;)
            +1
            ESP лучше рассматривать как канал связи, а алгоритм закладывать так, что бы при потере WI-FI или зависания, Ваш алгоритм оставался в работе, а потеря канала, когда он просто информационный, как пример удаленный доступ, не несет краха системе. Мой опыт такого решения www.youtube.com/channel/UCj4HeZMvSH5H3d_t6iDlQOQ, даже с учетом загруженности ESP, устройство неделю работало без перезагрузок, дальше пришлось отключить. Даже если что-то произойдет, вся логика в ПР200 продолжит работу. Хотя в 2015 делал управление котлом на одной ESP все работало, хотя иногда происходили перезагрузки, но через 5 сек. работа восстанавливалась.
            0
            Действительно, esp8266 — чрезвычайно нестабильная система. Дня не проходит, чтобы какой-нибудь из модулей самопроизвольно не отключился от сети (работают в системе метео-наблюдения). Интересно, как со стабильностью у esp32?
              0
              Как небо и земля. Esp32 очень не стабильная
                0
                То есть совсем всё плохо, если даже хуже, чем esp8266…
                  0
                  Esp8266 стабильная. На ней много уже девайсов в продаже.
                +1

                Не знаю… За 2 года работы системы из 2 модулей на esp8266 (модуль управления котлом с wifi и opentherm и беспроводный термометр) не припомню зависаний.

              +1
              Почему устройство умное?
              По — моему это просто автомат управления системой управления в доме с функциями телесигнализации и телеуправления.
                0
                Согласен, но есть же умные розетки, умные самогонные аппараты…
                  0
                  Устройство умное, потому что говорить, что оно компьютеризировано (после эпохи когда всё было механизировано) стало не модно. Сменилась мода и пропали компьютеризированные дома и авторочки с унитазами, зато много умников стало на свете даже среди самогонных аппаратов.
                    0
                    Кстати, а есть ли какая то другая интерпретация слова «smart»?
                      0
                      Не силён в английском, но вы же понимаете, что слова, в большинстве случаев, не имеют смысла вне контекста? Вот некоторые значения: саднить, страдать, быстрый, резкий, сильный, значительный. Например: smart price — довольно большая цена. На самом деле, не имеет значения, как они придали значение этому выражению, например, так ли уж важно, что спам это ветчина? Если вы хотите передать смысл, просто передайте его подходящими словами родного языка.
                  0
                  Собираетесь ли опубликовать исходники, на том-же ГитХабе, например?
                    0
                    Да, статья интересная, но есть какая-то недосказанность: с одной стороны куча листингов, с другой — нет исходников (что как бы не очень друг с другом согласуется). Sapienti sat, конечно, но всё же…
                      0
                      Я готов делиться опытом, но не продуктами
                      0
                      нет, но если интересные какие-нибудь детали — поделюсь.
                      0
                      Что за операционная система?
                        0
                        У нее нет названия. Я хотел донести, что функции ОС могут иногда исполняться без ОС различными библиотеками
                          0
                          Напишите, пожалуйста, в начале статьи что вы используете Arduino IDE. В метках есть, но всё равно остается подозрение, что это может быть нативный тулчейн.
                          За параллельное выполнение… периодическое выполнение функции, с заданным интервалом.
                          Разве это всё уже не реализовано в SDK и ESP8266 FreeRTOS? ИМХО велосипединг.
                            +1
                            Я не использую Arduino IDE. Я пользуюсь Visual Micro. Arduino SDK — да, использую.

                            Это мой первый проект по реализации устройства DIY IOT. Так что велосипедостроение присутствует — в Arduino SDK есть класс Ticker, c подобным функционалом. Но что удивительно — в примере arduino.ru/tutorials/BlinkWithoutDelay не используется этот класс. А я наверное посмотрел пример, и решил написать свой тикер, не зная что есть готовый.
                              0
                              Тем более напишите, вы же видите сколько вариантов.
                        0
                        Немного вопросов:
                        Насколько я понимаю у вас нет возможности управлять котлом кроме как вкл/откл?
                        Вы контролируете только температуру воздуха по зонах или воздух, сам пол, приток и обратка?
                        Рекомендуемая температура теплого пола около 25°C (в зависимости от типа помещения), это как-то учтено?
                          0
                          Это должно быть учтено при настройке петель, т.е. если врубаете круглосуточный обогрев — то температура поверхности не должна превышать норму, а отключение петли влияет именно на температуру в комнате. Правда не совсем понял зачем весь котёл отключать, разве что для экономии если все контура уже отключены…
                            0
                            Правда не совсем понял зачем весь котёл отключать, разве что для экономии если все контура уже отключены…

                            А куда девать горячую воду, если она не нужна? котел не может работать в холостую
                              0
                              Для этого в систему ставят байпас. У вас как реализован водоотбор на теплые полы? Обычно ставят трёхходовой кран/клапан где третий выход как раз байпас. У меня в параллель к нему стоит ещё один байпас, только он по давлению срабатывает, как раз на случай если все контура одновременно будут перекрыты. Правда у меня котёл ещё и на ГВС работает, так что выключать его не вариант, да и у меня вместе с ТП обычные радиаторы стоят. Хотелось бы чтобы вы описали систему отопления более подробно, тогда логика вашей систему управления станет более ясной, а вообще регулировать температуру теплоносителя в петлях с помощью котла — не есть правильно.
                                0
                                У меня отопление исключительно теплыми полами. Никаких байпасов.
                                Если холодно (хотя бы в одной из комнат) — контроллер включает котел. Петли комнат где тепло — запираются. Везде тепло — все отключаем.

                                ГВС — этот блок управляется самим котлом и не требует вмешательства. Т.е. когда надо, котел переключает трехходовой кран и греет ГВС в бойлере.

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


                                  так как он сработает если вы питание котла отключаете?
                                    0
                                    я не отключаю питание котла. Для моего котла предусмотрено внешнее управление ВКЛ / ВЫКЛ для отопления.
                                      +1
                                      Вот теперь логика ясна :) По тексту подумал что весь котёл отрубается.
                            0
                            Для моего котла предусмотрено внешнее управление только ВКЛ / ВЫКЛ. Но мне большего не требуется. Температура пола определяется температурой воды из котла. Это задается на котле и у меня стоит 40гр.
                            0
                            Используя эту микросхему, можно использовать преимущества шины 1Wire и избавиться от ее недостатков за счет трансляции 1Wire <-> i2c

                            И приобрести недостатки i2c ногодрыга от esp
                              0
                              Какие будут предложения?
                                0
                                Никаких, учитывая что чип esp8266.
                                Если есть выбор — перейти на более «нормальный» чип wifi+mcu (mt/rtl/cc), либо использовать BLE например (который как бы для этого и разрабатывался), но по видимому этот вариант Вам не подойдет.
                                  0
                                  Я бы перешел. ESP8266 мне не нравится — вот сейчас демо-стенд повис. А на нем нет вачдога.
                                  Сейчас думаю на что портировать.
                                  Рассматриваю ESP32, Orange Pi i96, Omega 2.

                                  Посоветуйте…
                                    0
                                    Для начала определитесь что у вас за устройство (slave/master).
                                    Не вижу смысла тащить на slave (какой нить датчик например) даже мини компьютер, те что бы это плохо или хорошо, просто это избыточно. Плюс, все миниплатники подразумевают Linux — опять таки, зачем какой-то розетке все это?
                                    Далее выберите wireless стек, с которым вам хочется/удобно/дешево/доступно работать. BLE/Wifi/zigBi — у всех этих технологий есть свое предназначение, и соответсвенно плюсы/минусы.
                                    Что касаемо именно mcu, это могут быть практически любые MK, которые Вас не стесняют, и достаточно популярны/просты. Не хочу показаться хейтером, но я бы взял ARM-based типа STM, в противовес AVR например или тем же MSP430.
                                    В случае с wireless+mcu, недавно вот заказал BLE nRF52832, так как с esp-стеком бороться уже не было сил. Что касается wifi то есть rtl8710, более дорогие и качественнее серия CC от TI.
                                    По сути — дело вкуса и принципов, esp взлетела только из-за своей цены, по этому, народ и начал на ней клепать все что не попадя
                                      0
                                      Посоветуйте, мне требуется чтобы в системе можно было бы ПРОСТО развернуть WEB-сервер с поддержкой WEB-сокетов.
                                      Ну и естественно WiFi с возможностью создать точку доступа
                                        0
                                        Я Вам выше написал все возможные юзкейсы, rtl8710 и ей подобные, возможно esp32, с последней дело не имел.
                                          0
                                          я на rtl не нашел примера web сервера.
                                          на esp32 — да, есть, рассматриваю этот вариант
                                      0

                                      На омегу даже не смотрите, серьёзно. Столько красноречивого хочется про неё сказать.
                                      Она красивая на картинках и в брошюрах, когда на ней детишки уже готового робота гоняют по полу через веб-IDE.
                                      Когда дело доходит до закономерной сборки OpenWRT с минимально необходимым обвесом и нормальных применений — оказывается что это неюзабельная хрень, у которой даже режимов энергосбережения нет нормальных.
                                      Плюс, ESP — Это совершенно другого класса устройство.
                                      Возможно, стоит иметь небольшой хост, который не будет энергонезависимым и постоянно подключен к розетке и небольшой контроллер с BLE, который подключается к хосту.
                                      Можете посмотреть платы у particle.io (не реклама).

                                        0
                                        дело доходит до закономерной сборки OpenWRT

                                        я не знаток линукса — вроде же в плате уже есть ОС. Что с ней не так? С учетом того, что энергосбережение меня не волнует. Этот проект без розетки имеет мало смысла.
                                          0

                                          Не скажу за всех, но свободного места, которое остаётся от оригинальной прошивки, мне не хватило на установку минимально урезанного питона.
                                          Плюс, для более-менее готового устройства (опять же, за себя говорю) все эти приблуды от омеги не особо нужны (вроде встроенной web ide и всяких модулей к ней).
                                          Если вам достаточно поиграться и что-то просто погонять — то можете смело брать. Но если возникает инженерное вдохновение — на каждом шагу начинают появляться какие-то навязчивые проблемы, которые и на форуме onion никто не сможет помочь разрешить. Можете его почитать, если интересно.

                                0
                                протокол 1Wire очень чувствителен к таймингам, поэтому все реализации программного мастера шины используют delay
                                Есть реализация на uart, есть на protothreads, можно целиком на прерываниях. если DMA есть.
                                  0
                                  А смысл? DS2482 стоит 100р., что гораздо дешевле чем искать глюки в извращенных программных реализациях.
                                    0
                                    Как бы всё давно отловлено, сколько лет прошло… Нет, я не настаиваю, просто категоричность не понравилась.
                                      0
                                      На ESP я подобных решений не нашел. Только какие-то обрывки. На UART — вообще не вариант, он мне самому нужен. Только не говорите, что чип г. — это выше обсуждали.
                                        0
                                        Нормальный чип, хотели мало, но все в одном месте — ну, вот и оно. Код на protothreads с авр на esp достаточно легко адаптируется, правда, примера конкретно с 1-wire я за пару минут не нашёл.
                                  0
                                  Модули esp8266 очень плохо уживаются друг с другом, особенно находясь рядом. Если использовать 1-2 модуля рядом — еще ничего, а больше, будет сплошная боль. Это вещь поиграться на выходные, но не для серьезного применения, увы…
                                    0
                                    А как они друг другу мешают?
                                      0

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

                                    Only users with full accounts can post comments. Log in, please.