Как я сенсорную сеть изобретал ч.4
Сделал макет тестового стенда для изучения энергопотребления. Схема, в общем-то, простейшая: есть устройство, которое изображает из себя автономный узел и всеми силами пытается прожить на аккумуляторе, подзаряжая его солнечной панелью и исполняя различные программные кульбиты вроде ухода в различные режимы сна, жонглированием периферией, радиоканалом и даже физическим отключением частей схемы. Между всем этим делом оно (прошивка) собирает информацию о параметрах электропитания и отправляет эти данные на второй узел, используя mesh Burelom. Второй узел находится на стационарном питании и работает в режиме шлюза. Зацеплен на Wi-Fi роутер и шлет телеметрию от первого узла на сервер. Там она агрегируется и выводится через UI для анализа.
Паразитные токи
Про макет я сказал не просто к слову, а потому что прототипы на девкитах и энергосбережение — это взаимоисключающие понятия. Причина в том, что на этих платах либо используются очень бюджетная периферия, либо они обвешены компонентами, которые не нужны в реализуемой задаче. К примеру, на девкитах ESP32 присутствуют оба их вида. Стабилизатор AMS1117 (и ему подобные) имеет ток собственного потребления 5–10 мА, USB-концентратор CH334 и RGB-светодиод WS2812B — по 1 мА. Каждый индикаторный светодиод — по 5–10 мА. Когда у вас помимо девкита ESP32 на пинборде еще GPS, StepUp, MPTT, INA, это всё накидывает нехилый оверхед на токопотребление, превращая устройство в печку. Текущий стенд в рабочем режиме имеет расход 200 мА/ч. Совершенно безумная цифра для автономного устройства. С одним АКБ 18650 жить ему дай бог сутки, и никакая 5 Вт солнечная панель и софт с режимами сна не выведут его на стабильный режим долговременной работы. Поэтому следующим этапом будет перенос всего этого зоопарка на свою плату, с выкидыванием всего ненужного и подбором правильных компонентов. В общем-то вот именно такую производительность имеют модули Мештастик T-Beam. Я помню, что после жонглирования всеми возможными параметрами прошивки мне удалось достичь ресурса модуля в 30 часов. И это очевидный предел без значительных аппаратных и программных оптимизаций, достижение коих и ставлю себе в задачи. Далее идет в некотором смысле отчет о проделанной работе, как и в прошлых статьях, инженерная графомания, фотографии пинбордов на предметах мебели и ссылки на код.
Узел 1
К железяке было прикручено:
Трехканальный инвалид INA3221 для измерения тока/напряжения (простите, по-другому не могу назвать это поделие).
MPTT контроллер CC3791
Солнечная панель 6v 5w с алика
Почему INA3221 — инвалид. Сам по себе чип — это отличный инструмент для измерения тока/напряжения в промежуточных точках устройства. Ситуация, когда такой измеритель ставится в разрыв произвольного провода, называется hi-end измеритель. Авторы же модуля решили почему-то, что это излишний функционал, и перемкнули все CH- линии на землю, таким образом ограничив модуль применением только в конечных точках (точка стока тока) устройства. Т. е. из отличного hi-end измерителя сделали кропнутый low-end. Пришлось его грубо доработать напильником. Как это сделать в деталях, я расскажу в отдельной статье.
MPTT-контроллер нужен для зарядки Li-Ion аккумуляторов прямиком от солнечной панели. Каналы INA были установлены в разрыв между солнечной панелью и MPTT, между MPTT и АКБ и между АКБ и устройством. Таким образом, устройство стало осведомлено о том, какой ток/напряжение дает солнечная панель, сколько от этого дела уходит на зарядку и сколько потребляет устройство в целом + уровень зарядки АКБ. Итоговое изделие имеет следующий вид:
Программно в нем был реализован простейший PowerManager, который читает INA3221 и преобразует полученные данные в удобочитаемый формат. Дальше они пакуются в proto-объект и выкидываются в меш-сеть к узлу 2.
Узел 2
Аппаратных изменений не приобрел. Программно для него был реализован MQTT-шлюз, реализующий контракт трейта Gateway меш-сети Burelom. Таким образом, всё, что приходит на этот узел, впихивается в соответствующий source-топик брокера. Сделать этот шлюз оказалось не самой простой задачей. Дело в том, что no_std-окружение Rust довольно ощутимо отстает по развитию от std. И если на std по запросу mqtt - крейты валятся как из рога изобилия, то вот для no_std их можно пересчитать по пальцам, да и, как оказалось, в удовлетворительном состоянии находится только один — rust-mqtt. Специально пилящийся для embedded применения. Все остальные либо как-то забагованы, либо реализуются только самый базовый функционал. Удивили клиенты, которые не умеют проводить даже basic-аутентификацию, зачем вообще такое позиционировать как законченную библиотеку? С rust-mqtt тоже, конечно, пришлось знатно повозиться из-за его супер-агностицизма к железу, у него не реализован внутренний цикл обработки mqtt-пакетов. В общем, логично, откуда автор знает, на какой системе это всё будет работать. Пришлось всё это дело написать, и заработало оно далеко не с первого раза. Но как результат, сейчас телеметрия стабильно уходит на сервер.
Второй интересный момент заключался с ESP-NOW. Я до этого уже упоминал, что этот протокол может работать параллельно с Wi-Fi. И вот сейчас открылась новая подробность о том, что, поскольку Wi-Fi ядро ESP32 не умеет мультиканальность, esp_now должен быть локнут на тот же канал, что и станция. А станция локается всегда на канал роутера, который может быть любым, если он жестко не залочен на самом роутере. Т. е. получается интересная картинка, что esp_now узла 2 знает, на каком канале ей сидеть, а узел 1 — нет. При этом канал этот может оказаться совершенно произвольным. Пришлось залочить канал на домашнем роутере, дабы вся сеть не рассыпалась просто оттого, что роутер решил, что ему комфортнее живется на другом канале.
Бекенд
Очень не хотелось тащить в телеметрию PostgreSQL просто по идеологическим соображениям. Но поднимать какой-нибудь Infux для того, чтобы просто поиграть с данными, тоже абсурд. Решил помучить дипсик на тему того, что вообще сейчас в индустрии СУБД для временных рядов. Выяснилось, там прямо золотой век, начиная от распределенного отечественно Clickhouse до локальных микрорешений вроде Chronix. Пораскинув мозгами, пришел к выводу взять tsink, который в зависимости от настроек может прикидываться от локальной файловой tsdb до серверного решения, умеющего в кластерную репликацию. Пока взял его локальную версию, работать с ним, конечно, одно удовольствие.
Фронтенд
Тут всё обычно для Rust экосистемы: мультиоконный Eframe и Tokio. Собственно, скриншот этого UI в шапке поста.
Что дальше?
Я хочу закончить это микрокобесие с пинбордами и перейти на сквозное прототипирование на печатных платах. Девкиты и макетки сильно ускорили процесс начальной разработки, но далее я считаю их потенциал исчерпанным.
Буду пробовать выполнять программные оптимизации, экспериментировать с режимами сна и работы с периферией.
