Создаём IoT устройство способное к глобальному масштабированию

• статью переделать в как я решил свою личную проблему мб и вам поможет

Пролог

Я увлекаюсь IoT уже более 7 лет, собрал множество устройств и программ для них: от gps логера для велосипеда и счётчика Гейгера с передачей данных, до делительных головок и муфельной печи с wifi управлением. Достаточно стандартный набор diy интузиаста.

В основном это устройства на платформах esp8266, esp32 и arduino. У всех этих подделок разный срок работы и судьба. Некоторые проработали 15 минут и сгорели, другие продержались до сегодняшнего дня, третие окислились на пол пути или вовсе утонули. Все эти устрйства были далеки от парадигм программирования, версионирования и масштабирования - они жёстко кодировали свои настройки. Нельзя себе представить ситуацию, в которой другой человек может использовать эти проекты себе во благо.

Посдовательность моего пути в IoT выглядела примерно так:

1. Получил понимание работы с микроконтроллерами в Arduino IDE
2. Дорос до VS Code в сочетании с Platformio
3. Примерно в то же время понял что без Git для контроля версий - никуда
4. Перешёл на Micropython для ускорения разработки

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

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

Также стоит отметить, что почти все репозитории для IoT используются другими пользователями, только с целью раздербанить их на составляющие и использовать эти маленькие кусочки в своём коде. Это связано с двумя аспектами:

1. Все настройки захардкожены
2. Одно устройство имеет очень большую зону ответственности

Разработчиков IoT можно в целом разделить на три лагеря:

1. Новички - уже умеет писать рабочие программы, которые выполняют свои задачи
2. Энтузиаст - использует git, умеет пользоваться поиском github, может решить почти любую задачу, но библиотеку по даташиту на датчик ещё не напишет или напишет, но убъёт на это месяц
3. Профи - серьёзные ребята, напишут вам библиотеку на любой датчик по даташиту или просто из головы, они умеют предоставить гарантии по работе своих программ, в основном они либо работают в сфере IoT и в опенсорс выкладывают библиотеки, которыми активно пользуются новички и энтузиасты или создают исключительно устройства для продажи

Схема проста, новички учатся на примерах репозиториев от энтузиастов, а профи пишут библиотеки для новичков и энтузиастов

Что можно предпринять, чтобы ускорить прогресc IoT индустрии с открытым кодом?

Как мне кажется энтузиастам не хватает ПО, которое бы позволяло организовывать их устройства, в единые управляемые системы, по аналогии как делают на серьёзных производствах с контроллерами промышленного уровня Siemens, Mitsubishi и тд. В промышленном мире очень серьёзные гарантии исполнения, дублирование оборудования и системы отката процессов. Обычно такие системы имеют тяжёлые самописные или глубоко интегрированные SKADA системы, они стоят на производствах, атомных реакторах и почти на любом серьёзном заводе, где важен настоящий realtime, чтобы соответствовать уровню надёжности системы обычно работа идёт в 3 смены персонала с запасной сменой.

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

Есть много популярных сервисов, заменяющих собой абстрацию SKADA систем для этузиастов: Blynk, Home Assistant, ThingSpeak, Cayenne и тд - наверняка есть аналоги в Yandex, Google, Aws облаках. Из минусов, что большинство из них платные и рассчитаны в основном на готовые устройства от крупных компаний, но при этом у них есть поддержка самописных устройств. Но как мне кажется не достаточная в текущих реалиях.

Есть ряд вполне осязаемых вещей, которые хочется видеть:

1. CI/CD - хочется иметь набор абстракций в который помещается ссылка на репозиторий gitlab или github, переменные окружения и в итоге можно скачать готовый, персонифицированный архив с устройством
2. Автоматические обновления - OTA существует, но обычно это самописный модуль, который вечно не работает
3. Полная автономность - ставим инстанс себе в локльную сеть и пользуемся
4. Федеративный поиск - чтобы отдельные инстансы видели друг друга и имели общие списки используемых репозиториев (приватных тут конечно же не будет). По сути это поиск репозиториев github + gitlab + ... в одном месте
5. Удобная абстракция для Input Output в pub sub модели - эта надстройка очень хорошо подходит именно для IoT, и позволяет выстроить стойные модели доступов, и как следствие взаимдействие между устройствами без участия бекенда, только устройство - брокер - устройстов, бекенд только как система авторизации и аутентификации. Устройствам конечно нужно хранить схемы подписок, но это не критично
6. Конвейеры данных - зачем мне хранение значений уличного датчика тепературы каждые 10 секунд ? Мне они не нужны, а вам? Давайте агрегировать за час или два. Ивентовые события то же хочется фильтровать, а некоторым значениям с датчиков было бы хорошо линейно изменить размерность

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

Вывод по прологу:

1. Автор Энтузиаст
2. Энтузиасту в лице автора мало функционала в готовых решениях

Очень кстати оказалось, что я +- middle python разработчик с некоторым багажом за спиной, я тянул всякое: CRM комбайны, нагруженные вещи и даже немного web3. А что мне как разработчику стоит написать хотябы MVP своих хотелок ?

Пишем Pepeunit от идеи до 1.0.0 за 2 года в одиночку (почти)

В начале сентября 2023 я начал анализировать, что выступает тайм киллером в моём IoT хобби, и очень быстро пришёл к осознанию вещей описанных в прологе. Eсли заглянуть в репозиторий с документацией на проект и посмотреть на коммиты в ридми, сразу станет понятно, что в 2023 году я был слабым разработчиком, хотя уже писал crud на работе и делал вещи из базовых навыков бэкенд разработчика на python.

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

Путь предстоял тернистый, благодаря опыту в разработке для меня было вполне очевидным, что написать без корректно сформированных концепций в формате тз, большой пэт невозможно. И почти до конца марта 2024 я писал тз не приступая к реализации. Тз к этому моменту представляло из себя файлик где были +- расписаны сущности и что я хочу от проекта. Пришлось также прокачивать свои навыки в программировании, прочитал Fluent Python и как окажется в будущем понял эту мудрую книгу на 15%.

Постепенно примерно к началу лета 2024, я написал бекенд с базовой реализацией почти всех самых основных функций. Но так как я был не самый лучший программист, количество багов локнуло разработку на 100%. Хотя в проекте было разделение на слои, это не сильно спасало ситуацию.

Что же делать ? Я пришёл к выводу что нужно делать рефатор. Рефактор основательный и желательно с тестами, чтобы закрепить успех. Проверив пирамиду тестирования, было обнаружено два подходящих слоя, модульные и интеграционные. Модульные очень быстро отпали, т.к. большинство багов было с внешними сервисами. Остались интеграционные, пошерстив интернет был сделан вывод что все их делают атомарными, но мне это не совсем подходило, т.к. мне нужно эмулировать внешние IoT устройства. Так появились они - инкрементальные интеграционные тесты. Покрыв все методы на сервисном слое абстркцим, было выявлено столько багов, что тестировщик, если бы это было на работе перестал бы со мной здороваться. Приятным бонусом было очень лёгкое обновление зависимостей проекта, меняй что хочешь. Проект стал в 100 раз более живучим.

Всё лето 2024 я наращивал объём бизнес логики и подошёл к моменту, когда пора создать фронтенд. У меня была основная идея: графовое отображение + модалки для крудов. Выбор пал на библиотеку ForceGraph, и предстояло сделать выбор Vue или React. Я выбрал React, только потому, что из коробки React выдавал больше fps в ForceGraph.

Позже мне конечно сказали, что можно было использовать ванильную библиотеку и получить такой же fps c Vue. Но я во фронтенде понимал не очень много и единственное, что меня спасло это llm. Без них я бы потратил пару лет на написание и изучение фронтенда. Качество получившегося фронтенда, по моему бекендерскому мнению точно на 3+. Он далёк от индустривальных стандартов во многих аспектах, но он не совсем убогий и его можно дорабатывать, а это самое главное.

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

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

Механизм этой демотивации прост: находим ошибку в логике на фронтенде, вписываем её в телеграм под номером N, правим её на фронтенде, она тянет бекенд, бекенд тянет архитектуру, архитектура тенят аналитику. В итоге вы меняете клиент на конечных IoT устройствах. Это была одна из 30 задач в телеграм чатике, вы её конечно зачёркиваете как сделаете, но эффект страшный, 1 сделана и 29 осталось, было потрачено 2 недели. Желание после этого делать любую из оставшихся 29 задач почти нулевое.

На работе не придаёшь этому значения, но когда ты в проекте один, сразу всё становится ясно. Если этому механизму разрушения разработчика не помешать, долго протянуть в проекте не получится.

Мне помогло нарезать доску на 6 столбцов: open, thin, work, test, docs, closed. Тут может быть непонятен только think, его смысл прост - это буфер между огромным числом задач в open и тем что реально делается в данный день из work. Вроде простой столбик, но как же он спасает когда выбираешь пул задач для реализации.

Вот наступил новый год, фронтенд и бекенд сшиты, работают, первые 200 сообщений в секунду текут по топикам. Фронтенд о чудо работает, и как казалось на тот момент почти без багов. В голове созревало понимание, что нужно закрепить успех, описав все механики работы системы в документации.

Документация была на проекте уже как год, сначала в формате sphinx и в дальнейшем мигрировала в приложение на основе vitepress. Но содержание всё это время было не закреплением механик проекта, а техническое описание для разгрузки головы разработчика, архитектора и аналитика. Приведение в порядок документации по проекту заняло большую часть января 2025. Сам факт закрепления всех составляющих проекта - выявил большое число багов, архитектурных и аналитических проблем. Баги правились параллельно с написанием докумнетации.

И вот 20 явнавря настал момент когда появилась документация версии 0.0.0, через 13 дней после 0.0.0 фронтенда и бекенда.

Версия 0.0.0 релизовала базовые концепции заложенные в проект, я их предметно оценил на тестовых IoT устройствах.

Далее я разрабатывал уже спринтами произвольной длинны, наращивая возможности проекта и расширяя документацию

К концу января на версии 0.1.0 в проекте уже были серьёзные усовершенстования для работы c IoT устройствами выявленные в процессе написания документации. К 3 февраля в версии 0.2.0 появилось развёртывание через docker compose и по сути проект получил возможность развернуться почти на любой машине. Релиз 0.3.0 от 14 марта привнёс многопоточность и нагрузочные тесты, наконец-то система получила оценку своей производительности, которая скажем честно была плохая ~4000 сообщений в секунду через MQTT и ~400 rps в смешанном тесте через locust для REST и GQL. Релиз 0.4.0 от 28 марта добавил в приложение модульные тесты на систему авторизации и аутэнтификации, также появилась grafana + prometheus для мониторинга. Релиз 0.5.0 от 9 апреля добавил систему логирования с хранением в Clickhouse Релиз 0.6.0 от 27 апреля добавил новый слой схемы: Tg Bot - он не покрывает весь функционал, но базовый просмотр сущностей выглядит вполне неплохо Релиз 0.7.0 от 23 июня был самым тяжёлым за всё время проекта, он вынес самый нагруженный функционал из python приложения в go приложения, добавив в приложение основную из фичей - конвейеры обогащения данных

Выводы по главе:

1. Разработать то что хочешь можно в одиночку, но без советов профильных специалистов обойтись будет очень сложно, консультация в курилке по актуальным решениям бекенда, фронтенда, devops части - это очень сильное подспорье
2. Мидл разработчик на python может склепать и фронтенд и go приложение, правда на 3+
3. Пэт проект такого объёма можно совмещать с основной фулл тайм работой, без ущерба для последней
4. Сложные проекты, ускоряют ваше развитие как разработчика на 300%. Вы реально решаете нетревиальные задачи, которые тяжелее по смысловой нагрузке чем даже самый тяжёлый круд или интеграция на работе
5. Грамотный мендежмент не позвляет выгореть разработчику