Эта заключительная часть статьи посвященная прошивкам системы. Дописывалась она спустя год "жесткого" использования первого релиза (10.12.2020).

Первую часть можно прочитать тут 

Прошивка центрального микроконтроллера использует активно режим сна (ESP32 Light Sleep) просыпаясь только временами для отправки и приема данных с выносных панелей, датчиков и связи с сервером. Далеко уходить в Deep Sleep первая версия прошивки релизной не умеет. В текущем SDK от Espressif для Arduino есть проблема связанная с тем что подключение к WiFi после просыпания никогда не происходит. в Light Sleep-режиме всё нормально. 

Прошивка термостатов-панелей активно использует режим стендбай mega328.

В прошивке центральной платы используются библиотеки:

  • Rtc (Автор Makuna).
  • DS2482 library for Arduino (Автор Paeae Technologies). Библиотека существенно переработана (и исправлены ошибки) для работы нашими устройствами на шине 1 Wire.
  • Arduino-PID-Library (Автор br3ttb). Существенно переработанная и обьединенная с Autotune этого-же автора.  

В прошивке термопанелей используются библиотеки:

  • U8x8 (Автор Olikraus) для вывода на дисплей. Библиотека "большевата" но зато с довольно разными Китайскими безымянными OLED-дисплеями ведет себя константно одинаково и не требует огромных временных затрат для "подгонки" под очередной вариант дисплея на SSD1306. На других испробованных библиотеках довольно много приходится подгонять руками под каждую пачку новых OLED-дисплеев.
  • SparkFun BME280 (Автор Marshall Taylor @ SparkFun Electronics). Версия библиотеки "доработана" для уменьшения потребляемых ресурсов.
  • OneWireHub (Автор Orgua). Имеются особенности связанные с подгонкой таймингов шины. Нужно калибровать под применяемые Atmega328 смотря на сигналы анализатором логическим. Используется правленная версия где переработан класс OneWireItem.

Компиляция в среде Arduino IDE 1.8.10 дает такие обьемы в 1 релизной версии прошивки:
Sketch uses 16392 bytes (53%) of program storage space. Maximum is 30720 bytes.
Global variables use 891 bytes (43%) of dynamic memory, leaving 1157 bytes for local variables. Maximum is 2048 bytes.

Компиляция в среде Arduino IDE 1.8.13 дает такие обьемы в 2 релизной версии прошивки:
Sketch uses 16884 bytes (54%) of program storage space. Maximum is 30720 bytes.
Global variables use 891 bytes (43%) of dynamic memory, leaving 1157 bytes for local variables. Maximum is 2048 bytes.

 

Термопанели имеют упрощенную систему меню (полные возможности доступны только через WIFI). Из упрощенного меню можно:

  • Посмотреть температуру и влажность в помещении
  • Задать яркость дисплея (0...10).
  • Задать режим работы (ВЫКЛ, Калибровка, Единая температура в сутки,3х временных периодов температур в сутках)
  • Задать\посмотреть offset (сдвиги) температуры измеряемой и влажности в помещении.
  • Задать\посмотреть яркость дисплея
  • Задать\посмотреть адрес устройства в сети 1 Wire.

Переключение между режимами осуществаляется быстрым нажатием на центральную кнопку-регулятор панели. После отсутствия изменений органа управления в течении 10ти секунд панель автоматически выключает дисплей. Имеется защита от "случайного" нажатия на орган управления. Для "включения" экранного меню необходимо удерживать нажатой кнопку в течении 3х секунд.

В случае если включен режим нескольких временных периодов, то температура задаваемая через меню меняет настройку в ТЕКУЩЕМ периоде. Это сделано для облегчения работы с системой.

В меню предусмотрены маленькие пиктограммы-иконки. Подготавливаются они из обычных графических файлов и потом переводятся в одноцветные изображения размером 16х16 пикселей. Дальше в уже в бинарные массивы программой типа LCD Assistant.

При подаче питания панели выдают на экране информацию о версии прошивки и ТЕКУЩЕМУ адресу устройства. Изначально адрес присваиваемый равен 0х31. Диапазон адресов 0х31...0х39. После этого первое что должен сделать "центральный" модуль это выслать ТЕКУЩИЕ настройки режима работы. Мы храним их не локально потому что в этом нет смысла никакого. Локально сохраняются только: коэфициенты коррекции влажности, температуры, наш адрес, настройки яркости. Они нужны что-бы показания взятые в первый раз уже были "верными".

 

Интерфейс веб-управления пока не блещет юзабилити и дизайном. Это что называется "черновое полотенце" параметров которые удаленно можно получить (или задать). Здесь приводится в качестве примера.

undefined

Текущая прошивка расчитана на работу со сторонней точкой доступа (WiFi station) и какой-то внешней системой управления. Т.е. веб-интерфейс предоставляется внешней стороной. Контроллер центральный не имеет встроенного webServer'а.

Протокол обмена данными выбран самым простым - HTTP form POST.

Центральный модуль периодически опрашивает сервер на предмет новых настроек. Он не находится всегда в эфире - экономя как электричество так и не создавая лишний ЭМ-фон. Время опроса задается в секундах. Отправив свои текущие настройки ввиде XML он получает с сервера текущее реальное время , сверяет нужно-ли сихронизировать свои часы по нему (дрифт в +-несколько секунд нас совершенно не напрягает тут) и получив конфигурацию запоминает её на текущий момент. Для сохранения настроек в ПЗУ требуется выдать специальную команду. Это сделано для того что-бы не убивать память впустую.

При изменении каких-либо настроек они с сервера пушатся на настенные панели-модули (через установку флажка синхронизации настроек) при очередном цикле-опросе. При изменении настроек с настенной панели - изменения пушатся уже в обратную сторону, на сервер.

Прошивка "понимает" следующие настройки:

  • TIMESTAMP. время текущее реальное на сервере.
  • SSID. Имя точки доступа WiFi.
  • PASSWD. Пароль от точки доступа WiFi.
  • CONINT. Интервал соединения с сервером и синхронизации настроек.
  • TXPWR. Мощность передатчика WiFi. 0-11 возможные значения.
  • SCANBUS. флажковый параметр. Заставляет инициировать принудительное сканирование шины OneWire.
  • CONFSAVE. флажковый параметр. Принудительно сохраняет _текущие_ настройки все в ПЗУ.
  • REBOOT. флажковый параметр. Перезагружает центральную плату.
  • H[1...4]MODE. Режим работы канала Y. 0=Выключено, 1=PID-калибрация коэф., 2=Единая температура в течении 24 суток, 3=3 временных интервала с отдельными температурами в течении суток.
  • H[1...4]T[1...3]S. Время начала временного промежутка X для канала Y. Число секунд в текущих сутках.
  • H[1...4]T[1...3]E. Время окончания временного промежутка X для канала Y. Число секунд в текущих сутках.
  • H[1...4]TEMP. Температура целевая для работы канала Y в режиме единой температуры в сутках.
  • H[1...4]T[1...3]TEMP. Температура целевая для работы канала Y в режиме временного промежутка X. 
  • H[1...4]CPADDR. Адрес панели настенного термостата канала Y.
  • H[1...4]TSADDR. Адрес термосенсора для канала Y.
  • H[1...4]TOFFSET. Коррекция температуры для настенного термостата канала Y.
  • H[1...4]HOFFSET. Коррекция влажности для настенного термостата канала Y.
  • H[1...4]KP,H[1...4]KI,H[1...4]KD. Коэффциенты работы петли PID канала Y.

После каждого сеанса расчитывается время насколько можно "заснуть" и модуль погружается в сон с сохранением состояния PINов.

После просыпания модуля идет проверка не пора-ли прокрутить цикл опроса датчиков, панелей настенных и PID. Сейчас он жестко задан в 20секунд. Т.е. каждые ~20 секунд времени происходит PID-петля прогон и получение показаний. Сначала идет запрос показаний, потом выдается команда на подготовку сьема следующих (эта команда "кладет" в сон настенные панели), и уже потом крутится PID-петля. Фактические замеры показывают что время держится не совсем жестко в 20секунд. Присутствует несущественный для нас дрифт в +-400мс. Это вполне допустимо для нас т.к. мы управляем высокоинерционной системой. 

Время опроса и прокрутки петли выбрано 20 секунд исторически (дефайн RUNCYCLE_FREQ). По-хорошему его можно чуточку увеличить но не больше минуты. Период работы или не работы клапана выбран через переменную VALVE_PWM_CYCLES. в текущем виде это 2 минуты (120сек). Потому что время, требующееся "аналоговому" сильфону для выполнения открытия либо закрытия равняется именно этим 120секундам.

Каждый аппаратный канал управляющий клапаном (1...4) можно "связать" с произвольным термостатом (используя параметр CPADDR) без физической перекоммутации проводов подходящих к плате.

Поскольку это софтовая реализация слэйва шины OneWire то мы ограничены в таймингах очень сильно настенных модулей.

OneWireHub используемая библиотека довольно надежна, но всё-равно поскольку она не на прерываниях построена то существуют очень редкие "пропуски" команд когда МК не находится в процедуре обработки сигналов с шины. Для подавления этой проблемы мы и выбираем интервал опроса центральным модулем в пределах минуты. И кроме этого в случае ошибки он повторяет команду выдаваемую неответившему модулю. Идеалом было-бы переписать библиотеку на использование прерывания. Аппаратно плата так и разведена для того что-бы это было возможно.

На этом наверное всё что хотелось описать. Если есть исправления\дополнения welcome to GitHub как говорится! Исходники проекта, чертежи печатных плат, схемы и 3Д-модели корпусов.