https://habr.com/ru/post/486368/- Python
- Параллельное программирование
- Программирование микроконтроллеров
- DIY или Сделай сам
Преамбула
Применение интернета вещей в сельской местности гораздо шире, чем домашняя автоматизация, хотя это, конечно, вопрос терминологии – что под этим понимать. Тем не менее я задумал концепцию Умной Усадьбы как проект разумной автоматизации процессов, происходящих на объектах, расположенных на территории своей усадьбы, причем, подчас на приличном расстоянии от места, где нахожусь в тот или иной момент, но при этом хочется, как минимум, быть в достаточной степени уверенным в том, что происходит на этих объектах не выйдет за границы дозволенного, что я могу, при необходимости, оперативно получить представление о ситуации на усадьбе в целом и на каждом контролируемом объекте в частности, а так же, при необходимости, вмешаться в происходящие процессы не несясь, сломя голову, к тому объекту, который вызвал мою озабоченность, потому что я в этот момент занят чем-то важным, или просто – банально холодно и лень выходить из дома.
Вместе с тем воплощение этой концепции позволит мне глубже изучить применение микроконтроллеров с использованием возможностей MicroPython, который мне просто нравится своей иллюзией легкости по сравнению с С++, на котором я в прошлых жизнях героически выполнял проекты разной сложности, а так же реализовать алгоритмы, до которых либо не доходили руки, либо они еще не были воплощены в библиотеках на языках высокого уровня. Это, собственно, и определило мой интерес именно к собственной реализации, не прибегая к широко распространенным решениям начиная от известных производителей того же Xiaomy до специализированных приложений типа EspHome или фреймворков. Хотя я не исключаю, что, пробежав по большому и тернистому кругу собственной разработки, набив шишки и мозоли, изрядно ощипанный но, конечно, не побежденный, я выдохну, потрачу свои кровные на красиво упакованные и оформленные устройства иностранного и русского производства уже по совсем рыночной цене и реализую накопленный опыт в уже существующих облачных и не очень монстрах типа MiHime, Domoticz, IFTT или еще чего-нибудь.
Резюмируя — мне захотелось получить удовольствие от изобретения велосипеда, когда для этого появилось, наконец, время до летней страды, когда уже не толко делать, но и думать некогда, занимаясь обслуживанием своей усадьбы. Я написал это с целью самому точно понять – чего я хочу, а тек же с тем, чтобы заранее дать себе право не отвечать на комментарии, в которых могут предлагаться уже существующие и очевидно, более исчерпывающие решения. Хотя алгоритмы решения той или иной задачи, связанной с реализацией задуманного, очень даже приветствуются.
Общий подход
Процессы, происходящие на объектах, управляются программируемыми контроллерами, которые целесообразно разрабатывать для решения локальных задач, объединяя их в последствии в иерархию, при необходимости, путем образования беспроводных соединений. Локальные задачи решаются там, где возможно обеспечить проводное соединение или короткие радио-соединения с датчиками и исполнительными устройствами, применяя простейшие протоколы для обмена информацией. Пространственное решение состоит в том, что максимальная нагрузка по принятию решений ложится на контроллер, управляющий листьями ориентированного графа в виде датчиков и устройств, который, при этом, имеет возможность направить сводную информацию в упакованном виде затребовавшему такую информацию узлу этого беспроводного графа. В интернете на телефоне или ином устройстве мне достаточно видеть пустой экран, означающий, что все работает в штатном режиме, но возможность запросить детализацию и, в экстренном случае вмешаться в действия конечного контроллера мне должна принадлежать по праву Создателя этого пространства. Вопросы безопасности и защиты от внешнего влияния пока откладываю на потом.
Сам контроллер уже может обладать более мощными каналами связи и использовать более продвинутые протоколы типа MQTT или ZigBee для организации устойчивого графа mesh-сети с последующим выходом в интернет.
В настоящий момент концепция ограничивается логикой работы программируемого контроллера с учетом возможности его включения в рой, или, иными словами, в связанную беспроводными соединениями группу. Областью применения контроллера является объект, подлежащий контролю и управлению, далеко не полный перечень которых привожу ниже:
- Теплица – температура, освещение, влажность почвы и воздуха
- Огород – полив, влажность почвы
- Инкубатор – температура, влажность, поворота лотка, звук
- Брудер — температура, влажность и освещение
- Курятник – температура, освещение
- Улей – температура, влажность, вес и звук (роение)
- Комната – температура, влажность, освещение и качество воздуха
- Теплый пол – температура носителя общая и по контурам, циркуляция
- Солнечный коллектор – температура и давления носителя, циркуляция
- Котел – температура и давление носителя, циркуляция
- Тепловой аккумулятор – температура носителя, циркуляция
- Котельная – управление источниками (носителями тепла) и потребителями (ГВС, отопление)
- Метеостанция – классика жанра
- Периметр усадьбы — видеоконтроль
Для описания, исследования и решения поставленной задачи разработан метаязык, позволяющий лаконично описать драйвера устройств, используемые в качестве источников и потребителей, задержки, связанные с обработкой информации, каналы связи, по которым эта информация проходит, расписание и таймеры для формирования цикличности действий, переменные, в которых помещается информация, существенная для контроля и управления процессами, происходящими на объекте.
В этой части метаязык позволяет в читабельной форме представить описание проекта, что будет полезно для формирования документации а так же перечня аппаратных устройств и логики, выраженной в печатных платах, на которых или к которым эти аппаратные устройства должны быть подключены.
Во второй части метаязык представляет примитивы, с помощью которых происходит управление процессами и которые используются при инициализации и последующем анализе состояния процессов, управляемых контроллером. При наличии достаточных ресурсов применяемых микроконтроллеров эту часть можно реализовать в виде интерпретатора, на вход которого подаются текстовые файлы, описывающие инициализацию драйверов, каналов связи, переменных и собственно сценарий, описывающий логику работы контроллера и не требующих изменения пошивки в случае уточнения сценария.
Как идею назовешь – так она и поплывет, поэтому Smart Manor – Умная Усадьба, место рождения идеи – Алтай, впрочем, Автоматизация тоже подходит хоть и является своего рода тавтологией в этом контексте определению Умная и, конечно, с помощью чего – с помощью программируемого Контроллера. Сложив заглавные буквы и смешав английские и русские слова, получилось –
~SMAK~, ну а Мета Язык Системного Описания, соответственно,
~МЯСО~. Вот такая кулинарная концепция вышла – применение
~SMAK~ используя
~МЯСО~. Кстати, примитивный беспроводной протокол для взаимодействия контроллера и устройств, не наделенных заранее собственными протоколами, я именовал
~JuJu~.
Аппаратная реализация задумана с использованием возможностей ESP8266 и Arduino с RF24+ или другими, более современными, но не менее дешевыми — для датчиков и исполнительных устройств – реле, клапанов, переключателей и тп, если их не получится подключить непосредственно по каким-либо причинам, логику самого контроллера постараться разместить на ESP32, а если не получится – на STM32. Цель – минимизировать расходы на железо. Допускаю применение аппаратной реализации ряда процессов типа терморегуляторов с выставлением гистерезиса или приборов определения качества воздуха, но так как я не электронщик, то разработка схемы с применением конденсаторов, сопротивлений и транзисторов для меня дело мучительное и это определяет разумный баланс между аппаратной и программной реализацией, а так же желанием непосредственного участия, либо хотя бы созерцания происходящего в контроллере.
Программная реализация основана на синтаксисе метаязыка
~МЯСО~, библиотеке asyncio и связанных с ней алгоритмов, общей логике
~SMAK~, описанной ниже. Задача управления процессами, происходящим на объекте, направлена на поддержание определенных условий эксплуатации, а так же для восстановления этих условий в случае возникновения отклонений, при чем при более сильном отклонении возможно применение более энергичных действий, а так же реакцию на аварийные ситуации.
В дальнейшем по тексту будет применяться следующая терминология:
Источники ( Source ) – сенсоры, входящие каналы связи
Потребители ( Consumer ) – исполнительные устройства, исходящие каналы связи
Взаимодействие Источников и Потребителей описывается в Сценарии путем анализа значений, полученных от источников; состояния таймеров и потребителей; значений переменных; расписания, на основании чего выдаются управляющие команды потребителям.
Регистр источников используется для хранения самых свежих данных, полученных в результате опроса источников, каждый из которых может опрашиваться со своей периодичностью. После обновления данных хотя бы одного из источников запускается блок анализа для уточнения режимов работы потребителей.
Регистр потребителей используются для разделения программных и физических данных с целью реализации механизма приоритетной логики исполнения сценария, заключающейся в том, что в процессе анализа условий, описанных в сценарии, могут быть выданы противоречивые команды к одному и тому же устройству и окончательной командой будет считаться та, которая зафиксирована последней по сценарию. Таким образом, формируя очередность проверок условий в сценарии работы устройств можно сформировать их приоритет. Физически команды будут исполнены только после окончания работы блока анализа.
Опрос источников и исполнение команд потребителями происходит в асинхронном режиме, то есть их драйвера передают управление планировщику системы в ожидании момента опроса или команды, а так же в случае инерционности срабатывания, во время которого источник или потребитель находится в занятом состоянии и тогда последующие запросы ставятся в очередь.
В зависимости от типа устройства драйвер может использовать более одного информационного канала, например, датчик температуры и влажности DHT использует 2 канала для передачи температуры и влажности, а устройства DS18B20, подключенные к общей шине для контроля коллектора теплого пола — еще больше, либо комплексный сервопривод, управляющий одновременно несколькими моторами или клапанами.
Характеристики драйвера включают в себя набор запросов и команд, специфичных для устройства, время задержки их исполнения, а так же тип связи, по которому передается сигнал, который может быть аппаратным (1Wire, I2C, SPI, UART и т.п.) так и беспроводным (WiFi, RF-радио, BT и т.п.), что дополняет методы передачи запросов и команд. Кроме того в драйвере предусмотрены режими самодиагностики при его загрузке, действий при его отключении и диагностики непредвиденных состояний во время штатной работы в асинхронном режиме. Драйвер может запускать несколько асинхронных задач, например, если потребуется обратная связь о состоянии устройства.
Из блока анализа можно доступиться к регистрам источников, потребителей, таймеров и переменных, к системным константам а так же расписанию. В идеале блок анализа видится как интерпретатор простого языка описания сценария, представляемый текстовым файлом, но в первых версиях, при написании сценария в коде прошивки, я буду придерживаться основным примитивам этого языка для наработки более лаконичного его представления. В настоящее время язык описания сценария используется для моделирования работы объектов ( инкубатора, брудера, курятника, пасеки, теплицы, огорода, котельной, гостиничного номера), определения необходимого количества устройств и их характеристик, что уже оказалось весьма полезным.
Далее в планах — публикация уже наработанного и созидаемого:
- ~SMAK~ — описание общих алгоритмов функционирования
- ~SMAK~ — описание метаязыка ~MЯСО~
- ~SMAK~ — описание протокола ~JuJu~
- ~SMAK~ — описание требований к созданию драйверов устройств в ~SMAK~
- ~SMAK~ – практика применения