К электронике я был неравнодушен ещё со школьных лет, всегда тщательно разбирая нерабочую технику и часами выпаивая детали до полной очистки платы от них. К сожалению, из-за отсутствия у меня радиолюбительской литературы, эти электронные эксперименты нельзя было назвать успешными: работало сразу обычно самое простое, но совершенно бесполезное в быту, а что-то посложнее уже капризничало с последующей закономерной смертью проекта.
Появление в старших классах китайского аналогового, а позже и цифрового мультиметра можно было бы назвать огромным технологическим скачком. Но после долгой череды неудачных экспериментов, побоев током, взорвавшихся деталей от неправильного их использования, да и просто отсутствия доступа к нужным электронным компонентам, интерес к этой области постепенно угасал. Да и в жизнь плотно вошёл компьютер, который требовал всё больше и больше времени, блокируя любые другие направления.
Электроника же, в отличие от компьютера, завязывается на элементную базу, как и на множество самых разных инструментов, обойтись чем-то одним уже не выйдет. Детская любознательность, интерес к открытию нового с бессистемным изучением всего подряд заменился прагматизмом и тщательным планированием личного времени. Рост числа различных навыков рождает необходимость в распределении времени между ними, создавая классическую проблему масштабирования: затраты времени на новое сокращают время на старое. В таких жёстких условиях электроника также должна себя оправдывать и приносить пользу, а желательно много пользы. И здесь появляется проблема.
В качестве полезного результата можно получить уникальные электронные устройства, удешевление в части самих устройств или их ремонта. С другой стороны, что-то уникальное требуется редко, да и его часто можно заменить комбинацией ближайших аналогов. На рынке множество дешёвых устройств, которые за пределами гарантийных сроков ломаются примерно как и "качественные" брендовые. Починка во многих случаях себя не оправдывает из-за постоянного усложнения и повышения степени интеграции, стоимости модулей, снятия их с производства, общего снижения надёжности и характеристик из-за старения. Да и производитель обычно ремонту всячески препятствует и затрудняет его всеми силами.
Надёжность элементной базы - это тот ещё рандом, сложное устройство отказом подведёт в самый неподходящий момент. Оно требует много времени на наладку, тестирование и долгий путь к успеху, шансы которого обратно пропорциональны сложности. Много усилий будет уходить на поиск, выбор, покупку, изучение, тестирование деталей и модулей, что мало связано с предметными задачами проектов, тратя время впустую. Кроме того, у требовательных к питанию, более сложных устройств появляется один из самых высоких рисков - пожаро и электробезопасность. Отсюда практическая сторона электронных проектов меня интересует мало, но есть и другая сторона, более интересная и ценная.
Классическое софтостроение само по себе нестабильно, в нём огромное количество багов и проблем, но электронные устройства и embedded ещё нестабильнее и проблемнее: результат часто сложно переделать, цена ошибки выше, количество факторов, которые нужно учитывать при проектировании - больше, а любой грубый просчёт катастрофичен. Анализ и работа с такими проектами выглядит повышением уровня сложности, ибо теперь нужно не только программировать, но и собирать программируемое.
Отсюда мой интерес и цель - это, конечно же, эволюция и улучшение существующих айтишных навыков в т.ч. аналитических, как и архитектурных, да и всех остальных тоже, что делает потери времени оправданными.
В итоге интерес к электронике стал постепенно возрождаться, но, в сравнении со школьными годами, творческий интерес заменился прагматичным. Хотя, конечно же, какая-то творческая составляющая тоже должна быть из-за сильного влияния её на результат, а без результата любое изучение чего-либо не имеет особого смысла. Из-за недостатка времени я очень долго тянул с экспериментами, но такое затягивание бесконечным быть не может. И этот первый пост в 2023 году знаменует старт более серьёзных практических экспериментов для обучения и закрепления теории на практике. Но с этими экспериментами есть одна проблема.
Сама по себе электроника, как любая область знаний - очень и очень объёмна, что вступает в конфликт с небольшим ресурсом времени на неё и вспомогательной обучающей ролью выше. С уменьшением степени абстракции над железом техника специализируется, как и повышаются затраты времени на получение результата. Для поддержания знаний нужна постоянная практика, которая для DIY-устройств носит периодический и ограниченный характер. Аналоговая схемотехника и примитивная цифровая требуют также более точного, более сложного, а местами очень специализированного оборудования и софта, без которого можно вполне обойтись.
Кроме того, в самодельничестве невыгодны специализированные устройства. Классическая философия UNIX требует однозадачности программ, да и многие известные архитектурные паттерны пересекаются с разделением ответственности (High Cohesion в GRASP, Single responsibility в SOLID и т.д). Но на практике возникнет проблема сопровождения большого зоопарка устройств.
Синхронизация кодовых баз, обновления, улучшения, фикс регрессионных багов из-за изменений, тестирование и прочее обслуживание в одиночной разработке затруднено, а потери времени на всё это должны быть максимально сокращены. Хотя именно для электроники здесь появляются плюсы, например, устройства могут служить друг другу донорами запчастей, но это не компенсирует всех проблем.
Другая проблема в ограничениях функционала, для роста которого необходим рост абстракций с упрощением и ускорением разработки. Здесь ровно такая же проблема, как я описывал в самом начале: простое в быту бесполезно, оно либо может быть заменено существующими аналогами в т.ч. их комбинацией, либо вообще не нужно в силу своего упрощения, а любые потери времени на него себя не оправдывают.
Тесно связаны с этой проблемой и ошибки в функциональных и нефункциональных требованиях, когда результат выглядит полезным, но при дальнейшей работе вскрывается его неудобство, бесполезность, да и вообще мёртворожденный концепт. И это разочарование усилится потерянным временем. На ранних этапах жизненного цикла обычно всегда есть ошибки и промахи по требованиям, что требует постоянных переделок, а они могут быть очень проблематичны.
Учитывая все эти и многие другие проблемы, есть смысл ограничить эксперименты определённым уровнем абстракции устройств от железа, ибо промышленные цели и самодельнические очень сильно расходятся, а используемые инструменты и платы не могут быть одинаковыми.
Для этой цели можно разделить условные модули, платы, устройства на несколько групп по разнообразию решаемых задач обработке данных. Какая-то подходящая классификация мне пока не попадалась, так что может выйти что-нибудь наивное:
- Персональные компьютеры: стационарные и мобильные, планшеты, мобайл с GPIO через USB-TTL или сеть.
- Одноплатники (SBC): Raspberry Pi, Orange Pi, Banana Pi и похожие.
- Отладочные платы и платформы для сети IoT.
С другой стороны, круг решаемых задач также сокращается. Например, wearable electronics (носимая электроника) имеет очень жёсткие ограничения, что намекает на очень специализированные платы и модули, с большой долей ручного управления железом.
С другой стороны, техника постоянно усложняется, бурный рост IoT в ближайшие годы потребует и более быстрой, упрощённой и безопасной разработки. Это рождает шанс попасть в период смены технологического стека, что обнулит все предыдущие навыки, большая часть которых станет бесполезной. Аналогии и опыт из-за сильного различия между стеками перенести будет почти невозможно, как и невозможно будет догнать по знаниям и квалификации тех, кто не имел потерь времени на легаси. Это один из самых известных айтишных рисков, что также влияет на мой выбор целей для экспериментов, как и уровней их абстракции.
В случае отказа какого-либо устройства более низкого уровня, его функцию может взять на себя предыдущий. Так, если в системе умного дома отказывает модуль маршрутизации информации от датчиков, то через GPIO или сеть их можно быстро подключить к одноплатникам или десктопу в обход неработающего узла, имея много маневров для повышения надежности, отказоустойчивости, да и прочих нефункциональных требований.
Продвинутое железо позволяет использовать самые разные языки в т.ч. прикладные, что сильно ускоряет, облегчает разработку и сопровождение кода, сокращая потери времени, как и пересекается с самыми разными айтишными навыками, способствуя их прокачке. Хотя его достаточно обидно сжечь по неопытности, в зависимости от устройства могут быть проблемы с питанием и автономной работой, теплоотводом, ограничениями GPIO и т.п. Но это не самая большая проблема.
Если эти устройства хорошо работают в роли обработки данных, то использование их для каких-то специализированных односложных задач, например, проброса информации от датчиков выглядит очень проблемным, что усложняет построение сети IoT.
Можно, конечно, обмазаться одноплатниками, но масштабироваться это всё будет намного хуже чем более примитивные платформы, а в зависимости от задач и вообще не будет. Правило "каждой задаче - свой инструмент" никто не отменял. А ещё с повышением уровней абстракции может уменьшаться обучающая полезность проектов, ибо соединение между собой полностью готовых и настроенных модулей может вообще не требовать ни знаний в электронике, ни программирования как такового.
Отсюда очень сложно обойтись только лишь персональным компьютером или одноплатниками. С другой стороны, в этом наивном списке явно виден слишком большой скачок от одноплатников к отладочным платам, подразумевающий какой-то класс устройств между ними, но подходящего кандидата я пока не встречал.
На рынке также есть много продвинутой техники, допускающей программирование, но чем устройство сложнее и функциональнее, тем больше оно требует времени на изучение нюансов. Эти навыки получаются специализированными и запросто могут обнуляться при смене бренда или типа устройств на другие. Из-за этих рисков я пока не выделял их в отдельный интересующий меня класс, хотя что-то вполне можно использовать, конечно же. Например, если устройство завязывается на свободный код, какой-то активно поддерживаемый сообществом репозиторий или библиотеку, то рисков становится меньше.
Получается, что начинать электронные эксперименты выгоднее с десктопа, мобайла и одноплатников, поскольку они наиболее близки к классическому IT, универсальны и экономят время. Однако тут появляется высокий риск уничтожения устройства по неопытности, что намекает на обучение наоборот - с низких уровней и выше, где платы дешевле, как и неудачные эксперименты с ними. Учитывая потребность в большом количестве примеров и туториалов, первый претендент здесь - это инфраструктура ESP8266 и ESP32.
Мой айтишный стереотип и отношение к легаси заставили всё-таки остановиться на ESP32, как продолжение линейки ESP8266, предполагая, что производитель понизит свой интерес и приоритет времени на поддержку хотя и огромного количества, но с каждым годом стареющих морально плат. Хотя эти предположения, конечно же, ничем не обоснованы.
Плат на ESP32 очень много всяких разных, но тут нужна высокая доля сходства с обучающими материалами. Пробные запросы в гугл выявили завязку части туториалов на ESP32 WROOM DevKit.
На всякий случай предварительно поинтересовался проблемами с драйвером CH340 на моей версии линуксового ядра и они обнаружились, поэтому искал плату именно с CP2102.
Нельзя сказать, что плата модная, молодёжная, но зато популярная, а популярность должна уменьшать сложность решения проблем (теоретически). Относительно высокое потребление, бесполезность для меня Bluetooth, небольшое количество пинов не самая большая проблема, есть кое-что более трагичное.
Наибольшая проблема для меня здесь - это С\С++ тулчейн, тратить время на который мне невыгодно от слова совсем, ибо я использую другой системный стек, полностью покрывающий все мои задачи. При трате времени на любой другой язык в силу альтернативных издержек уменьшится время на уже используемые, что нанесёт им большой вред. Можно немного подождать их архитектуру в основной ветке LLVM, но на данный момент есть следующие варианты:
- Смириться. IoT платформа имеет множество ограничений и по мере усложнения логики будет всё больше проблем. А что-то простое можно писать дубово-процедурно и не выходить за рамки того же С. Уменьшение функционала и упрощение сократит и затраты времени (опять-таки, теоретически).
- Собрать LDC под Xtensa через их форк LLVM, получив там D. Вернее, betterC с биндами на их sdk, что не радует какими-то значительными преимуществами, оправдывающими усложнение обновления и сопровождения, интеграцию с C++ и т.п. сложности для самых первых экспериментов.
- Сделать то же самое с более современными языками ради их обучающего потенциала, например, с Zig, но выглядит это примерно как и п.2. с бонусом проблем портирования кода с си и плюсов из-за сильного различия в синтаксисе. Да и нестабильность самого компилятора потребует миллионов пересборок.
- Взять что-то вроде линейки ESP32-C3, что на RISC-V. Но на данном этапе для меня ценны туториалы и примеры, использовать которые скорее всего станет значительно тяжелее. Судя по материалам в сети это версия позиционируется как замена ESP8266 и порезана по функционалу. А ESP32-P4 родился буквально на днях.
Что касается NodeMCU, то изначально я рассматривал его, как и Espruino. Но если для обычного программирования повышение уровня абстракции упрощает кодинг, то здесь может сработать наоборот: лишние слои вносят побочные эффекты и проблемы, бороться с которыми на голом железе намного тяжелее. JTAG отладчиком я ещё не обзавёлся, ибо в процессе экспериментов мои интересы к железу могут запросто поменяться.
После серии экспериментов с IDE я остановился на PlatformIO. Здесь рождаются муки выбора: ограничиться нативным ESP-IDF, либо же его версией с Arduino. С одной стороны, ардуиновские библиотеки вносят побочные эффекты и скрывают часть реализации, с другой - скетч обладает более высокой кроссплатформенностью между разными платами, да и должен облегчать (теоретически) адаптацию кода из туториалов. Да и саму FreeRTOS я пока недостаточно понимаю и знаю. Поскольку апи esp-idf можно свободно дёргать и так, то ардуиновский вариант пока победил. Инструменты для экспериментов выбраны, остаётся подумать над проектом.
При поиске идеи сразу вспоминается пословица: любой проект на Arduino рано или поздно становится метеостанцией, что наверное частично применимо и к ESP. Метеостанция - это классический и очень интересный DIY-проект из-за связи с разными естественными науками, но пока я к нему не готов.
Альтернативным вариантом выглядит другой популярный класс проектов - охранные сигнализации, тесно связанные с анализом рисков, что хорошо укладывается в формат исследовательской статьи и блога. Конечно, результат такого обучающе-тренировочного проекта будет совершенно бесполезным, но таковы законы любого обучения, ибо для выхода в сложные проекты нужны время и практика.
Большая часть достоинств и проблем проекта упирается в его сердце - ESP. Концептуально, из-за встроенной беспроводной сети, такой проект выглядит как мобильный модуль, оповещающий о нарушении защищаемого периметра как самостоятельно, так и транслирующий информацию с датчиков куда-то ещё. Из-за ограничений железа, сложности тестирования и отладки, какую-либо сложную логику выстроить тут проблематично, архитектура должна быть максимально простой и дубовой.
Бегло пробежимся по требованиям. Наверное главное функциональное требование, сложное для плат этого класса - не тупить. Сигнализация требует исключения ложных срабатываний, как не срабатывания в нужный момент, последствия могут быть катастрофическими.
Но надёжность самой платы очень трудно предсказать, а в сети огромное количество случаев умирания плат по неизвестным причинам. Следовательно, рождается другое требование: своевременное определение отказа, что намекает на "маяк" - периодический импульс активности. Однако в случае сигнализации злоумышленник может подделать маяк и эмитировать нормальную работу устройства в т.ч. взломав домашнюю сеть.
Отсюда неплохо бы добавить видеонаблюдение, которое тоже можно подделать, но немного сложнее. Оно же используется в различных сигнализациях и для исключения ложного срабатывания, когда система записывает короткий ролик, который просматривает оператор и делает заключение о вызове спецслужб.
Из доступных нагуглились модули камер OV7670, 7675 и похожие. Подключение нелёгкое, через SPI с проводной лапшой, успехи по отзывам противоречивые, но потенциально оно может работать. Но я не уверен, что такое железо вытянет эту камеру для передачи более-менее качественных изображений через сеть, а вот риски сжечь плату повышаются. Поэтому для целей эксперимента я обойдусь без изображений и видео, хотя это и сильно ударяет по требованиям.
Для этой цели лучше выглядит ESP32 CAM и аналоги, конечно же. Ну или какая-то промышленная Wi-Fi камера. Проблемы слепоты устройства снижаются при работе сигнализации в сети IoT, тогда какой-то другой модуль с камерой отвечает за видеонаблюдение. Всё это подтверждает список устройств выше: IoT-платформы хорошо работают как однозадачные модули.
С другой стороны, отсутствие видео хотя и создаёт риск, но все ещё позволяет охранять периметр, но модуль может быть как внутри охраняемой зоны, так и вне её. Последний вариант требует охраны и самого модуля, что намекает на расположение одного или нескольких датчиков как можно ближе к корпусу устройства, а желательно рядом с ним, охраняя и его тоже. Это повышает мобильность модуля, его можно взять куда-то с собой, а потом легко подключить обратно.
Однако сам модуль может располагаться в разных местах, что требует охраны больших площадей и намекает на дистанционные датчики движения. Из простых был найден пироэлектрический инфракрасный датчик HC-SR501. Его можно переделать под 3.3В, но это создаёт проблемы в будущей быстрой замене, как и возможном дублировании датчика ещё одним, который тоже нужно будет перепаивать. Выглядит так себе перспектива, проще обойтись без переделок. С другой стороны, появляется шанс что-нибудь перепутать, запустив 5В на пины ESP, что приведёт его к смерти.
После паруминутной калибровки при обнаружении движения датчик формирует на выходе импульс высокого уровня, настраиваемый по времени. Этот импульс можно направить не на ESP, а куда-нибудь ещё в т.ч. изолировав датчик для его тестирования.
Датчик вполне самодостаточен для простых устройств, а учитывая наличие стабилизатора и универсален. Кроме того, на нём даже есть места для апдейтов в виде фоторезистора для работы в темноте, как и терморезистора для исключения ложных срабатываний от скачков температур.
В случае поломки платы с ESP, датчик всё ещё позволяет использовать модуль с другой системой оповещения, такое переключение неплохо бы сделать максимально удобным и быстрым. С другой стороны, это увеличит количество лапши из проводов, а учитывая дальнейшее масштабирование и увеличение числа датчиков, выглядит бесполезным т.к. изоляция каждого отдельного датчика осложнится, как и замена их на другой с иной логикой работы.
Сам по себе пьезоэлектрический датчик склонен к ложным срабатываниям, как и плох в роли датчика присутствия, не замечая очень медленные движения или неподвижного человека. Теоретически, его наверное можно обойти специальным экраном, устройством и т.п. хаками, так что без дополнения чем-то другим он выглядит рискованно. Ещё в сети пишут, что ресурс его подстроечников (как вариант, сам процесс изменения настроек) очень ограничен, но тут не проверял.
Основным недостатком выглядит сложность мониторинга его работоспособности. Отвал контакта данных изменит уровень входа у ESP с подтягивающими резисторами, а вот отсутствие питания или срабатывания проверять уже сложнее. Ну и сам по себе такой датчик система относительно сложная и не всегда нужная.
Подстраховкой ему нужен дубовый вариант - несколько герконов. По сценарию наихудшего случая злоумышленник знает их расположение, может проникнуть в охраняемую зону каким-то нетривиальным путём, так что полезность герконовой защиты не так высока. Но они позволяют контролировать отдельные части помещения, что может быть необходимым по тем или иным причинам. Кроме того, геркон легко поменять на кнопку, какие-то контакты, что универсально и удобно.
Что касается модуля аутентификации, то его мне проще исключить. В промышленных сигнализациях он необходим из-за большого количества пользователей и ролей, в подобном модуле его отсутствие, во-первых, сильно упростит систему, а во-вторых, позволит лучше её тестировать, а именно - срабатывание датчиков именно в режиме охраны.
Любой режим создаёт множество условий и веток if-ов, тестирование работоспособности в одном режиме может совершенно не влиять на другой. Если тестировать датчики до установки на охрану, то нет гарантии, что они сработают при нарушении периметра. Постоянное тестирование именно режима охраны выглядит более надёжным для этого случая. Исключением может быть наличие старого доброго оповещателя "ревун", постоянное срабатывание которого при снятии с охраны идея сомнительная. С другой стороны, он может включаться с задержкой, достаточной для отключения тревоги или что-то около того.
Кроме того, любые пользовательские действия нужно ограничивать и логировать. Здесь можно вспомнить недавний случай с умными дверями Aiphone GT, которые не имели ограничений попыток ввода кода доступа и не логировали действия, позволяя злоумышленнику не оставлять никаких следов своего присутствия.
В случае его наличия я бы попробовал RFID, как один из самых простых вариантов. iButton с 1Wire торчащим наружу контактом так или иначе даёт доступ к железу. Можно поставить супрессор, например, от статического электричества, какого-то вменяемого порога напряжения, но каким этот порог должен быть, ведь этот контакт находится в руках злоумышленника и там условно может быть любое напряжение. Да и под вопросом влияние на мобильность: в случае использования модуля в неудобных условиях, приспособить куда-то этот контакт сложнее. А если что-то где-то торчит открыто на виду, то его обычно ковыряют, поджигают или ломают изощрёнными способами, защиты от которых не существует.
Другой вариант: управление модулем через сеть. Без собственных велосипедов можно ограничиться, например, мессенджерами с ботом. Задача взлома такой системы уже сводится к взлому сторонних и неплохо защищённых сервисов, что потребует знатных усилий, хотя сама плата, роутер, смартфон и прочие участники этой схемы всё также подвержены взлому.
Основная проблема здесь даже не в защищённости и надёжности сети, а в способе получения управляющих сигналов, что предполагает постоянное соединение с сетью, либо постоянные проверки. Если микроконтроллер находится в режиме энергосбережения, то его нужно разбудить, но для получения сигналов нужна сеть, которая выключена. Для мобильного модуля постоянная работа сети или контроллера сильно понизит универсальность и время жизни от автономного питания. Даже если модуль работает стационарно, то сеть банально может не требоваться в работе, а оповещение происходить сигналами с пинов, включающими какие-то другие устройства. В этом случае бесполезная сеть повышает риск удалённого взлома платы, ибо это всё-таки двери внутрь устройства и домашнюю сеть, да и впустую тратит драгоценные ресурсы микроконтроллера.
Эта проблема сразу вскрывает ключевые архитектурные грабли: последующее добавление режимов энергосбережения. Если изначально устройство было спроектировано только на постоянную активность контроллера, то добавление этого требования приведёт к масштабному рефакторингу и тестированию с нуля. Есть смысл закладывать сон сразу. Даже если эта логика не потребуется, то её полноценный реюз осложнится в системах с энергосбережением, а они распространены.
Поскольку речь зашла об автономии, то нужно упомянуть и о питании. Мобильность проекта предполагает автономное питание, как и своевременное переключение с одного вида питания на другой. Однако потребление у ESP32 достаточно высокое, а мощные аккумуляторы повышают риск пожара, предсказать отказ в платах BMS тоже сложно. Если ставить что-то дублирующее, контролирующее, то законы Мерфи не исключают отказа и там, и там одновременно. Поэтому я пока не определился с автономным источником, а проблемы с питанием и жизнью платы можно условно определить по отсутствующему маяку.
На борту плата имеет стабилизатор AMS1117-3.3 с заявленным током в 0.8А. Самый простой путь - это купить блок или модуль питания, но для обучающего проекта это не принесёт никакой пользы. Импульсный БП собирать тоже сложно, как и анализировать, пришлось поискать что-нибудь среди старого хлама.
В закромах откопался трансформатор от старого аудиомагнитофона на 10В. Поскольку стабилизатор линейный, а плата хочет минимальных 5В, то имеем для максимального тока грубо (10В - 5В)*0.8 = 4Вт рассеиваемой мощности, что в корпусе SOT-223 выглядит нереалистичным. Термическое сопротивление в даташите варьируется от 46° до 90°C/Вт, но маленькая пластиночка на плате выглядит не очень серьёзно. Так что есть смысл на всякий случай взять предельное в 90°, тогда для температуры стабилизатора около 100° (максимальная в 125 выглядит немного высоковатой) при комнатной температуре в 25° мощность не должна превышать: (100 - 25) / 90 = 0.8Вт, причём учитывая очень тёплое лето последние годы, накопление тепла в корпусе модуля и нагрев других элементов в нём это ограничение должно быть ещё более жёстким, да и запас должен быть. На максимальное потребление модуль может выйти банально из-за программной ошибки или по загадочным причинам в т.ч. игнорируя энергосберегающие режимы.
Отсюда питание через пин Vin таким трансформатором выглядит плохой идеей. Один из самых простых способов - использовать линейный стабилизатор, хотя из-за низкого КПД много энергии будет уходить в тепло. Но его отказы анализировать значительно проще, в отличие от импульсных БП, да и в хозяйстве завалялась LM7805. Сам по себе ESP может запросто стать горячей печкой, так что помещать два таких источника тепла в один корпус не хотелось бы, но опять-таки, линейный БП проще. Запас по току здесь получается очень небольшим, учитывая будущее масштабирование и потребности датчиков в отдельном питании, так что более мощные стабилизаторы выглядят тут получше.
При тестировании платы она начала циклично перезагружаться при попытке включения WiFi. Если всё работает с USB и не работает с кастомным БП, то вывод прост: виноват БП. Благодаря простоте конструкции подозрение сразу пало на входной фильтрующий конденсатор и замена его на более высокую ёмкость устранило проблему перезагрузок.
Рассмотрим разные варианты плохих событий, могущих произойти с проектом. Полноценный анализ рисков трудоёмок и очень объёмен, поэтому я буду уделять больше внимания электронной части, акцентируясь лишь на условно значимом.
Основная проблема такого анализа - это сложность вскрытия причинно-следственных связей из-за отсутствия электронного опыта, что сведёт большую часть предположений к наивному угадыванию. В таких условиях наиболее полезные аналитические инструменты вроде того же FMEA использовать затруднительно. Поэтому есть смысл начать с HAZOP, который своими управляющими словами подталкивает к выявлению рисков, позволяя какую-то часть из них выявить без достаточного опыта в предметной области.
Этот анализ хорошо визуализируется таблицами, но с ними есть как проблемы на мобайле, так и неудобство редактирования из Markdown, табличный формат которого достаточно упоротый. Поэтому я буду описывать всё текстом. В общем случае таблица содержала бы столбцы: ключевое слово, отклонения, причины, последствия, действия или что-то в этом роде. Но в текстовом формате её можно упростить, да и часть предположений о причинах и последствиях могут быть либо наивными, либо бесполезными сами по себе. Для воспроизведения отказов самый лучший способ - это реальное тестирование, что требует инструментов и определённых жертв в компонентах, которые будут умирать в процессе. Рассмотрим разные части охранного модуля.
В структуре блока питания (БП) имеем:
Трансформатор - два плавких предохранителя на первичной и вторичной обмотках, диодный мост с конденсатором.
LM7805 с обвязкой - несколько конденсаторов, диодный шунт для защиты от обратного напряжения, как отмечено в даташите, светодиод с резистором для индикации питания.
НЕТ
Нет напряжения в электрической сети из-за аварии в сетях электроснабжения. Тут необходим автономный источник питания. Как отмечал выше, пока с аккумуляторным питанием я не определился из-за его пожаро и взрывоопасности.
Нет контакта вилки трансформатора с розеткой из-за расшатывания или поломки. Здесь уместна периодическая проверка контакта.
БОЛЬШЕ, МЕНЬШЕ
Повышенное или пониженное напряжение в сети из-за аварий, перегрузки в вечернее время, мощных электроприборов и т.п. Необходимо подключение в устройство защиты от перепадов напряжения или защита, например, варисторная.
Сюда же наверное есть смысл отнести и электромагнитные всплески, например, из-за молний, особенно в грозовой летний период. Учитывая модульность блока, он вполне может использоваться где-то на выезде, а сухая гроза наверняка может сделать отказ очень внезапным, а возможно ESP и выдержит. Но пока я не встречал в литературе простого способа защиты, как и упоминаний о поведении платы, ну разве что вот похожее, но это не точно.
Сюда же, возможно, стоит отнести и магнитострикцию трансформатора с гудением и повышением вибрации пластин. Но это достаточно легко обнаруживается по звуку.
ДРУГОЙ
Нарушения формы синусоиды, всяческие отклонения частоты, амплитуды. Защита та же, что и от проблем сети.
ТАКЖЕ
Помехи, гармоники в сетях. Можно вспомнить случай с недостаточной ёмкостью фильтрующего конденсатора. Теоретически, поскольку уровень пульсаций или шума, необходимый для цикличной перезагрузки платы неизвестен, то нельзя исключать, что включение какого-либо прибора в домашней сети легко может создать эту проблему, а ёмкость конденсатора снова окажется недостаточной. Так что дополнительный сетевой фильтр здесь выглядит очень нужной подстраховкой.
Ещё, как вариант, проблема может быть в неспособности электролитического конденсатора хорошо бороться с высокочастотными помехами, что требует параллельного включения какого-нибудь керамического помощника.
ЧАСТЬ
Замыкание первичной или вторичной обмотки трансформатора, возможен пожар.
Должны сработать предохранители, как в устройстве, так и в щитке. Однако время срабатывания может запаздывать, поэтому риск пожара всё-таки сохраняется. Да и если трансформаторный блок будет располагаться в корпусе, то на срабатывание плавкого предохранителя может влиять температура в корпусе, которая тут малопредсказуема из-за двух "печек" - ESP и 7805. Есть смысл изолировать устройство в металлический корпус, однако перекрытие доступа воздуха будет вызывать проблемы с охлаждением. Даже если бы там не было линейного стабилизатора, то мог начать греться ESP по необъяснимым причинам, так что вентиляция должна быть.
Более сложные вариант - регулируемая вентиляция, тогда можно перекрыть доступ воздуха, как один из факторов жизни огня, но реализовать это сложнее.
Также здесь неплохо было бы поставить какой-нибудь датчик огня. Как вариант, тот же популярный ардуиновский на компараторе LM393, но, возможно, есть что-нибудь и получше. Вопрос в том, успеет ли датчик выдать сигнал, а ESP его отправить до того, как огнём будет повреждены провода и модули устройства, но всё-таки какой-то шанс успеть есть.
Особая проблема будет в случае глубокого сна, что потратит драгоценное время на выход из сна и подключение к домашней сети. В случае наличия автономного питания и повреждении огнём одного из источников, может произойти успешное переключение на другой и плата успеет сообщить о беде. В случае же с питанием только от сети шанс здесь выглядит не очень большим, но наверное он всё-таки есть.
Ещё такие датчики могут не реагировать на пламя с отличающейся длиной волны: он хорошо срабатывает на пламя спички или свечи, но может игнорировать пламя, например, горящего газа синего цвета. Поскольку в корпусе много проводов с изоляции, всякой пластмассы, которая может окрасить пламя, то есть некий шанс не срабатывания в начальной стадии. Хотя по мере распространения пламени он так или иначе сработает, но может быть уже поздно, ибо основное требование - это срабатывание как можно раньше.
ЗАМЕНА
Изменение полярности на выходе трансформатора, например, после какого-нибудь ремонта или же неправильного подключения разъёма. Есть смысл установить защитный диод, пытаясь подстраховаться одновременно и от появления переменного тока из трансформатора.
Поскольку диоды могут как пробиваться, так и замыкаться накоротко (промежуточное состояние - повышенное внутреннее сопротивление), то второй случай есть смысл рассмотреть отдельно, например, под ключевым словом ДРУГОЙ.
ДРУГОЙ
На выходе трансформаторного блока появится переменное напряжение через замкнутые диоды. Но защитный диод от изменения полярности должен превратиться в однополупериодный выпрямитель. Сам по себе он содержал бы большое количество пульсаций, но поскольку следом идёт фильтрующий конденсатор, то это напоминает пиковый детектор и диод должен блокировать ток из конденсатора обратно в трансформатор. Его пульсаций, вероятно, всё равно может быть очень много и плата начнёт также перезагружаться как и при проблемах с конденсатором на входе.
Ещё проблема, что если оно всё-таки заработает, то такой отказ достаточно сложно обнаружить. Возможно, есть какой-то способ контроля питания, навроде комплексных датчиков напряжения, тока и мощности навроде INA219 и т.п., но это выглядит недостаточным, что-то вроде катушки Роговского слишком экзотическим. Так что это вопрос пока остаётся открытым.
Следующее звено - LM7805 с обвязкой.
НЕ ИЛИ НЕТ
Отсоединение или плохой контакт с дорожкой платы, как и отказ самой микросхемы. Индикаторный диод должен погаснуть.
Отсоединение или плохой контакт с радиатором, что приведёт к перегреву и срабатыванию защиты (ну, или к смерти стабилизатора). Здесь уместна периодическая проверка креплений.
БОЛЬШЕ
На выходе перенапряжение. С одной стороны, это достаточно опасно, с другой - далее на плате будет стабилизатор, который поимеет проблем с рассеиваемой мощностью, но хотя бы немного должен поработать. Если бы плата контролировала питание датчиком, то возможно отключить какие-то функции либо перейти в энергосберегающий режим в этот момент. Вопрос остаётся в уровне высокого напряжения, который запросто может выйти за верхний предел стабилизатора на ESP-плате. Если был бы импульсный БП, то появление очень высоких напряжений на его выходе было бы наверное более вероятным, намекая всё-таки на дополнительную защиту.
Повышение температуры. Здесь должна сработать защита стабилизатора, но она может по каким-то причинам и не сработать. Особенно пострадают от неё электролиты, так что конденсаторы есть смысл брать на высокие температуры и размещать подальше он горячих точек. Учитывая всё более тёплые летние деньки с разогревом до 35°, возможный источник тепла со стороны ESP, то температуру в корпусе устройства есть смысл всё-таки контролировать.
С продвинутыми датчиками для IoT я ещё не знакомился, но зато в закромах был найден любопытный экземпляр - советский терморезистор ММТ-4 на 100К (в сети пишут, что это при 20°C). Пришлось немного погуглить и перебрать разные варианты уравнения Стейнхарта - Харта для работы термистора в резистивном делителе, пока он более-менее стал показывать правду. Не тестировал на всём диапазоне температур, но показания сходятся с комнатным термометром. Обнаружилось, что ADC2 отказывается работать при включённом WiFi. Ещё в сети ругают АЦП у ESP32, так что искажения вполне могут быть.
Технически, учитывая мобильность модуля температура может быть и пониженной, что может привести к резкому падению ёмкости и росту ESR электролитов, как и отказами в других компонентах.
МЕНЬШЕ
На выходе низкое напряжение. Что может быть, например, из-за нормального падения напряжения у защитного Шоттки на выходе, что может отразиться на ESP, но пока вроде как ему достаточно.
ЧАСТЬ
Плохая стабилизация, например, из-за отсоединении конденсаторов в обвязке. Пишут, что в этом случае микросхема может греться и замыкаться. Эту неисправность может быть сложно обнаружить без контроля за питанием.
ЗАМЕНА
Изменение выходной полярности из-за ремонта или неправильного подключения. Изначально я поставил Шоттки именно для этой цели, но он сработал и для следующей
ДРУГОЙ
Обратное напряжение. Когда я ставил диод для защиты от смены полярности, то ещё не знал, что при питании ESP от USB на его Vin внезапно появляется 5В, которые, конечно же, попадут без диода на БП и на выход LM7805. В даташите микросхемы рекомендовано поставить обратный диод между входом и выходом, так что должен сработать он, а ёмкость выходного конденсатора намного меньше чем на входе. Но, как вариант, контакт диода может отвалиться, что тоже очень сложно обнаружить и надеяться на него тоже такое себе.
Обратное напряжение может быть и другой полярности. На выходе стоит электролитический конденсатор, на которые попадёт 5В обратной полярности. Будет ли достаточно это для выхода из строя или взрыва, даже учитывая большой запас по напряжению, тоже вопрос. Ну и даже без взрыва, теоретически, оно может как-то сократить срок службы самого конденсатора, создавая отложенный во времени отказ.
В БП из деталей остаются обвязочные конденсаторы, да индикаторный диод.
Для конденсаторов может случиться: падение ёмкости, повышение напряжения, повышение температуры, потеря контакта с дорожкой, замыкание или обрыв. Часть проблем сложно обнаружить. Можно подстраховаться запасом на напряжению и температуре, ну и держать конденсаторы подальше от горячих мест.
Есть смысл рассмотреть переходные процессы при зарядке конденсатора большой ёмкости на входе. В начальный момент он должен вести себя как перемычка, что повлияет на предохранитель в трансформаторе, создавая шанс его перегорания, как и закоротит диоды на входе. Но предохранитель там заводской и явно взят с некоторым запасом, а ток, вероятно, ограничивает сам трансформатор. Так что вроде как работает. Если поставить балластный резистор небольшого значения, то у него должна быть очень большая мощность рассеивания, возможно, тут нужен PTC термистор, который, разогреваясь, будет увеличивать сопротивление.
Технически, тоже самое может произойти и с выходным конденсатором, тогда сработает (должна сработать) защита микросхемы от перегрузки, но ёмкость там не очень большая.
Индикаторный светодиод
Как любой резистор, ограничивающий резистор светодиода может быть источником шума, обрываться и закорачиваться, но эти проблемы выглядят не слишком критичными. С другой стороны, здесь может проявляться взаимосвязь событий, что обычно сильно усложняет любой анализ. Закороченный резистор ведёт к перегоранию светодиода, который, в отличие от ламп накаливания, перегорая, тоже закорачивается. Тогда должна сработать защита БП от перегрузки. Единственное, что из-за потенциальных источников тепла резистор логичнее выбирать с более низким ТКС, иначе при разогреве всей конструкции будет сильно прыгать его сопротивление, что в сочетании с дешёвым светодиодом наверное может привести к случайным отказам, как вариант.
НЕ
Обрыв и отсутствие питания на светодиоде. Тогда 7805 может работать вообще без нагрузки, но судя по примерам и отзывам в сети она может. Некоторые DC-DC преобразователи могут начать разогреваться в этом случае, но тут не тестировал.
Что касается его закорачивания, то БП начнёт работать на резистор светодиода, его мощности рассеивания вполне достаточно. Здесь, вероятно, могли бы быть взаимосвязанные события. Как вариант, если бы светодиод потреблял ток побольше, то резистор мог бы быть низкоомным. После закорачивания светодиода на этом малом сопротивлении начнёт рассеиваться большая мощность и он тоже выходит из строя, но для крошечного индикаторного светодиода с очень малым током такой расклад выглядит маловероятным.
Теперь можно перейти и непосредственно к датчикам.
Геркон нормально разомкнутый
НЕТ
Если геркон не будет замыкаться от магнитного поля, то это может создать проблему в случае позднего обнаружения, например, при установке на охрану. Времени на исправление нет, а датчик не работает. Есть смысл либо постоянно контролировать датчик, либо как-то сигнализировать индикаторами о его работе.
БОЛЬШЕ
Сильное магнитное поле из-за близкого расположения магнита позволяет злоумышленнику что-то сделать, не размыкая геркон, например, приоткрыть дверь и просунуть туда руку с магнитом, который уже будет удерживать геркон от срабатывания.
МЕНЬШЕ
Срабатывание из-за изменения позиции магнита и уменьшения магнитного поля, например, из-за люфта двери, окна или подобной конструкции.
ТАКЖЕ
Замыкание в проводке геркона или в месте разъёма датчика, что сделает его вечно-замкнутым. Этот опасный случай намекает на включение тестовой размыкающей кнопки после всех разъёмов, непосредственно в цепь с герконом, ибо после неё может быть замыкание.
ДРУГОЙ
Импульс, дребезг контактов, что повлияет на срабатывание ESP. Может выйти какой-то триггерный эффект, когда от первого срабатывания плата переключается в какое-то состояние, которое отменяет быстрое второе срабатывание или похожий конфликт состояний.
РАНО, ПОЗДНО, ПРЕЖДЕ, ПОСЛЕ
Поскольку такой самодельный бытовой модуль сигнализации не относится к системам жесткого реального времени, то определённые отклонения допустимы. Но они могут увеличиваться из-за, например, выхода из режимов сна и подключения к WiFi, что требует много времени.
Теоретически, информация о причине пробуждения доступна ESP и если злоумышленник снова замкнёт геркон (например, закрыв за собой дверь, что в общем-то логично), то плата всё равно должна сработать, не доверяя текущему состоянию датчиков. Но в логику может проникнуть баг и состояние перезапишется, а плата не поймает разомкнутый геркон.
Датчик инфракрасный
НЕТ
Датчик может не сработать, начиная от особенностей пироэлектрического эффекта и заканчивая загадочными обстоятельствами. Учитывая относительную сложность самого датчика, его тестирование почти ничего не гарантирует, он может отказать в любой момент. Здесь может быть уместным дублирование, но появляется проблема синхронизации между датчиками, как и увеличится потребление и шанс ложных срабатываний, но это выглядит меньшим злом.
В конце концов, датчик наверняка можно обмануть каким-нибудь поглощающим излучение материалом или хитроумных трюком, так что в одиночку он будет защищать только в самых простых случаях.
БОЛЬШЕ
Напряжение на выходе больше 3.3V по каким-то причинам и ESP выгорит. Трудно сказать, насколько высок этот риск, но можно развязать его, например, оптопарой.
Дистанция срабатывания может быть больше чем нужно, что приведёт к постоянным или случайным ложным срабатыванием.
Больше срабатываний может быть также из-за случайного переключения в режим H.
При обслуживании сигнализации датчик будет постоянно срабатывать, мешая отладке, например, из-за одиночного светодиода для состояния всех датчиков. Есть смысл предусмотреть либо выключение такого раздражающего датчика, либо реагирование ESP на него.
МЕНЬШЕ
Напряжение на выходе может быть меньше, такого уровня не хватит для срабатывания или оно будет рандомным. Теоретически, можно подключить датчик к АЦП и определять уровень вручную, но трудно сказать, насколько эта идея хорошая.
БОЛЬШЕ, МЕНЬШЕ
Температура в помещении. Не нашёл каких-то данных о влиянии температуры на сам датчик, кроме разве что её резких скачков. Но учитывая шанс подделки, температурный диапазон его работы может быть и не очень большим, как вариант.
ТАКЖЕ
Ложные срабатывания на скачки температуры, сквозняки и прочее. Насчёт срабатывания датчика на огонь или дым отзывы разнятся, а эксперимент трудоёмок. Это, возможно, полезное свойство, но трудноразличимое с обычным срабатыванием. Невозможность различать разные причины его срабатывания очень сильно уменьшают полезность.
ЗАМЕНА
Сигнал при отсутствии движения, что без видеонаблюдения может создать много проблем и лишнего беспокойства.
ДРУГОЙ
На выходе импульсы с высокой частотой, при превышении некоторого значения которой должны начаться проблемы. ESP, возможно, или не увидит изменения уровня, либо увидит там рандом, либо будет ещё какая беда.
РАНО, ПОЗДНО, ПРЕЖДЕ, ПОСЛЕ
Любые сильные отклонения дают возможность подобраться к модулю и выключить его. С одной стороны, по исчезновению маяка можно судить о проблемах с устройством, с другой - выключение может потребоваться злоумышленнику для какой-нибудь другой цели. Например, в случае подделки ответа устройства исключить посыл сообщений с него.
Ещё из-за наличия в датчике настройки времени импульса можно попытаться завязать код на это время, но наличие разных режимов в самом датчике и отклонения времени создают некоторый шанс багов в этой логике.
Плата с ESP
А вот сам ESP32 из-за сложности своего устройства делает анализ по ключевым словам крайне проблематичным. Со стороны железа риски по большей части сходные: температура, обрыв, замыкание и дребезг контактов, отклонения сигналов по длительности, частоте, амплитуде, крутизне фронтов уровней, отказы во встроенных резисторах пинов, но их намного больше из-за насыщенного функционалом чипа и самой платы. Многие виды отказов очень проблематично обнаружить, как и защититься от них. Возможны конфликты между разными режимами платы, например, прошивка от USB и питание от БП. Добавляются проблемы от радиомодуля, который тоже может работать плохо.
Отсюда есть смысл попробовать другой подход, например, анализ ETA (Event Tree Analysis) из-за возможности использования взаимоисключающих событий, что также снижает требования к пониманию причинно-следственных связей. Но здесь появляется тонкий нюанс между противоречием и противоположностью, которые в обыденности могут запросто маскироваться друг за другом и на эти грабли легко наступить.
Графический способ также не особо удобен, поэтому попробую в текстовой форме. В первую очередь интересует работоспособность платы как таковая.
Плата не включилась.
Эта ветка может начинаться с источника питания: работает и не работает. Работоспособность должен показать светодиод питания, как БП, так и самой ESP-платы. Если БП работает, контакты в порядке и на Vin поступает питание, то проблема в самой плате. Может отказать как стабилизатор с обвязкой, так и более глубокие элементы, тут ничего не поделаешь.
Плата включилась.
Состояние самого модуля неизвестно, что намекает на систему самотестирования и проверку всей периферии, что проблематично. Остаётся протестировать:
- Напряжение и силу тока, если таковой датчик имеется.
- Сигнал с датчика огня.
- Уровень температуры через терморезистор выше. В старых платах с ESP32 был встроенный датчик температуры, но в более новых его убрали.
- Количество свободной памяти.
Полезность такого тестирования из-за ограничений железа и тулчейна крайне низкая, ибо оно покрывает только самые простые случаи. Да и тестирование при первом включении не выявит всех последующих проблем: температура будет расти, а память уменьшаться. Поэтому логично мониторить показатели постоянно, отсылая уведомление ещё и по этой причине.
Неплохо бы получить запись лога в файл на флешку через SPIFFS, чтобы потом либо проверить его на ошибки в процессе тестирования выше, либо просматривать удалённо. Контролировать размер файла достаточно легко, но многократно повышается шанс проблем при потере питания, ибо на флешку постоянно что-то пишется. Там есть функции для её восстановления, но очень упрощённая файловая система выглядит так себе надёжной. Light-sleep флешку вроде как не отключает, но в более глубоком сне наверное появится сложность из-за её включения и выключения, хотя в доках это и не рекомендовано. В эти периоды лог должен сохраняться в память, а затем сбрасываться на файл. Отладка всего этого на таком железе выглядит как создание себе проблем.
Тестирование может закончиться двумя результатами: успешно и неуспешно.
Тестирование неуспешно
Можно подать звуковой сигнал, но появляется проблема в определении причины. К модулю можно подключить какой-нибудь небольшой LCD-дисплей, но тут полезным выглядит REST-апи на условно более безопасном HTTPS сервере. Реализация настроек и вывода информации на дисплей потребует много часов работы и войны с багами из-за ограничений в тамошних графических библиотеках, не решая проблемы связи модуля с другими устройствами.
Сервер у ESP использует библиотеку mbedtls, которая выглядит более-менее популярной, как и положено для инфосека, хотя насчёт возможных уязвимостей я не в курсе. Конечно же, есть много других способов связи с модулем, да и большой количество самых разных библиотек.
Само по себе наличие такого сервера в модуле создаёт много рисков и его работу нужно как-то сигнализировать, я остановился на отдельном светодиоде, хотя можно было бы сэкономить пин и задействовать всего один светодиод для всех режимов модуля. Здесь появляется некий риск, что светодиод погаснет, а сервер останется невыключенным, оставляя потенциальные двери для взлома, что можно проверить, например, пробным подключением клиента после выключения сервера.
Если сервер запустился, то проблема диагностируется через него, если нет, то без JTAG и подключения к компу связи с модулем никакой нет. Технически, провал тестирования и отказ в https-сервере могут быть несвязанными событиями, поэтому какой-то тестовой кнопкой можно отправить результат тестирования на клиент. В этом случае может оказаться полезным и дисплей.
Технически, ESP допускает обновление прошивки без подключения через OTA (Over The Air Updates). Но выглядит этот функционал специализированным, хорошо подходя, например, для заливки отлаженных прошивок. Если изменения и фиксы постоянны, то нужен и последовательный порт, скорость и многочисленные эксперименты, что для USB-кабеля выглядит поудобнее. Ну а если OTA не используется, то можно высвободить место на флешке, удалив неиспользуемый раздел.
Тестирование успешно.
Но оно пройдено только единожды. Логично делать его по таймеру и отсылать результат в обязательном порядке через какой-то промежуток времени, высчитывая дельту по той же памяти, ибо заложенные уровни выявления отклонений могут тоже отказать: их недостаточность, баги, какая-то неочевидная комбинация и т.п.
После включения и тестирования модуль начинает свою основную работу.
Один из простых способов логики охраны - состояния, которые должны сохраняться. Если модуль был в режиме охраны, а потом питания пропало и вновь появилось (его включили), то он также должен перейти в состояние охраны.
Preferences.h показался достаточным для этой цели. Соответственно, рождается шанс бага из-за некорректных переходов, например, из-за дребезга контактов, который вызывает сразу несколько переключений состояния.
Один из недостатков - юзабилити, которое очень не любит режимы из-за частой путаницы в них. Текущее состояние должно быть хорошо различимо индикаторами. Есть некий шанс вообще забыть включить модуль, поэтому может быть какой-то выносной подключаемый светодиод на выходе из периметра, призванный лишний раз напомнить об этом. С другой стороны, можно ограничиться и простыми тексто-знаковыми напоминаниями.
Соответственно, модуль может оказаться по крайней мере в двух корректных состояниях, непосредственно охраны и наблюдения за датчиками без срабатывания оповещений. С другой стороны, какая-то часть датчиков, например, огня, газа и отдельные датчики периметра (входных дверей, как вариант) могут срабатывать в обоих режимах, так что границы между ними размываются, меняется лишь способ оповещения.
При включении модуль должен как-то перейти в одно из состояний.
Состояние модуля неопределённое
Индикаторы не показывают ни один из корректных режимов, могут быть проблемы как с чтением настроек, так и с логикой работой с отказами. Без дисплея можно подстраховаться, например, звуковым сигналом, чтобы понять, прочиталась ли конфигурация на флешке. Если его нет, то переход в какое-то из состояний не был, управление до него не дошло.
Удобными выглядят несколько звуковых сигналов подряд, по количеству и тональности которых можно судить о выполняемой логике. Звук помогает лучше уловить случайную перезагрузку или ошибку, которая запросто может ускользнуть при индикации светодиодом или дисплеем.
Модуль перешёл в наблюдение
В этом состоянии о работе модуля можно судить по индикаторам, которые могут работать и не работать в т.ч. отслеживая работу датчиков. В последнем случае диагностика сложна и как-то подстраховаться тут проблематично.
Как было отмечено выше, часть датчиков может срабатывать в этом режиме, что требует контроля за начальным их состоянием. Однако способ оповещения меняется, использование сети может быть неудобным. Если датчиков немного, то выручит простой светодиод или звук, если много, то дисплей или использование сети выглядит необходимостью. С другой стороны, датчик может отказать позже, поэтому устройство также должно оповещать о поломке. Итого, датчики могут не работать и работать.
Если датчики работают корректно, то нет гарантий, что сработает оповещение на часть из них. Оповещение может быть самое разное, вспомним тот же ревун, включать который каждый раз при перезагрузке или включении устройства невозможно. Протестировать те же герконы без механического размыкания в общем-то тоже невозможно. Остаётся вариант тестовой кнопки, размыкающей цепь того же геркона или подобное тестирование по необходимости.
Если оповещение не срабатывает, то нужно разбираться в причинах, если срабатывает, то тут появляется проблема и в мониторинге самого модуля. В режиме охраны и удалённого контроля для результатов периодического самотестирования можно использовать тот же канал, что и для оповещений. В режиме наблюдения модуль может включить оповещение в случае провала самотестирования, но сложно судить, происходит ли это тестирование вообще как таковое, что очень большая проблема этого режима.
Есть вариант отсылать результаты на какое-нибудь устройство. С таким спамом можно смириться, но отключение сети, которое запросто может быть в этом режиме будет триггерить сохранение событий на флешку, а если его выключить, то они могут быть утеряны. Вот здесь полезность дисплея очень возрастает, ибо он может выводить результаты последнего тестирования, когда как светодиод, звук в этой роли не годятся. Дисплей и настройка возможности отсылки на устройство выглядят более удобным сочетанием.
Рассмотрим другой вариант событий.
Модуль перешёл в охрану
По кнопке либо при чтении сохранённого состояния. Основная задача этого режима - это, конечно же, оповещения. Проще всего использовать мессенджеры, библиотек очень много всяких разных.
Работа датчиков в этом режиме уже не видна, любое изменение состояния должно сопровождаться оповещением. Во многих охранных системах в корпус встраивается микропереключатель, вероятно, где-то защита основана на датчиках Холла, так что оповещение отсылается и при вскрытии корпуса. Но полезность такой защиты очень условна, ибо в худшем сценарии злоумышленник всегда знает внутреннее устройство модуля, такие примитивные системы защиты не выглядят надёжными. С другой стороны, она достаточно проста.
Для оповещений основной риск от миллионов миллиардов проблем сети. Логика оповещений имеет сходство с event-driven application, как одного из видов потоковых систем. Для предотвращения утери событий в них используются всякие техники: RBML с сохранением полученного сообщения, SBML для отправленного и гибридный HML, сохраняющий его дважды, как и подобные. В случае ESP один из самых простых способов - это запись на флешку через файловую систему SPIFFS. При выключении питания и последующим включении можно проверить наличие неотправленных сообщений и отправить их, как и повторять отправку в случае проблем сети.
Здесь появляется частный случай - спам оповещениями из-за программных ошибок, некорректной работы датчиков и самых разных причин. В реакцию на датчики любая порядочная сигнализация закладывает настраиваемый таймаут, но он может по каким-то причинам не сработать или сработать не так. Как вариант, самое слабое звено - это esp-шный таймер, на который опираются все таймауты.
С другой стороны, программное ограничения и проверка событий на идентичность с подсчётом их количества создают шансы потерять важное срабатывание. Если спам не тратит лимиты сервиса, то на устройстве можно использовать поиск среди спама, ибо все события доставляются. А вот гарантировать такую доставку в случае более сложной логики работы с событиями может быть проблематичным.
К сожалению, ветка событий выше не позволяет проследить множество других видов отказов. А любое добавление защиты от отказов добавляет и отказы в самой этой защите, усложняет устройство, повышает шанс что-то замкнуть или соединить не так.
Вспомним, например, крайне популярное явление для embedded - зависание микроконтроллера, что в общем случае требует сторожевого таймера. В ESP их несколько, но судя по материалам в сети срабатывают они с переменным успехом, намекая на внешние схемы контроля. Встречал такие даже на 555-ом таймере, как и на специализированных микросхемах, но пока не определился с выбором.
Есть сложность и с корректным поддержанием соединения. Предположим, что Wi-Fi по каким-то причинам отваливается и переподключение либо не срабатывает, либо ESP считает его подключенным, что на самом деле не так.
В этом случае можно считать количество неудачных отправок или отправленных сигналов маяка, а затем пытаться перезагрузить микроконтроллер при достижении какого-то лимита. Вероятно, можно определять более низкоуровневым апи сам факт наличия домашней сети, исключая проблемы с роутером, но трудно сказать, насколько это апи надёжно.
Однако поскольку охранная логика опирается на состояния, может быть запутанной с различными условиями и багами, то лишняя перезагрузка повышает шанс получить при последующем включении невалидное состояние из-за багов или каких-то других проблем. Хотя в embedded есть подход с периодической перезагрузкой устройства, но высокая сложность IoT-платформы и логики заставляют лишний раз задуматься при её использовании.
Эти и другие нештатные ситуации лучше обрабатываются анализом FTA (Fault tree analysis), но без достаточного опыта работы с ESP и с электроникой как таковой очень сложно адекватно выявлять причинно-следственные связи. Конечно же, никто не отменял и классическое тестирование: граничные значения в классах эквивалентности, таблицы решений, state-transition testing, хорошо укладывающийся в логику работы состояний охраны, как и прочие инструменты, способные выявить проблемы и баги. Но это уже выходит за рамки темы, поэтому завершаем этот наивный эксперимент охранного модуля.
Какие итоги можно подвести. С моей позиции DIY-электронщика работа с ESP32 понравилась, ибо у меня пока нет каких-то специфических задач, в которые можно упереться архитектурой и возможностями платы.
Благодаря популярности почти все проблемы я решал гуглом достаточно быстро, библиотек много, функционала тоже. Качество самих плат варьируется от производителя к производителю, но моя особых проблем не вызвала, хотя выглядит явно подделкой под оригинал. В сети много сетований на самые разные проблемы ESP-шных платформ, но и у других не меньше.
Дальнейшая моя работа с этой платформой сильно зависит от беспроблемного использования других языков в тулчейне, но, судя по всему, всё к этому и идёт. Однако здесь нужно учитывать и конкурентов. Было бы очень хорошо использовать множество разных платформ, каждую под свою задачу, что хорошо согласуется с непреложным законом "каждой задаче - свой инструмент". Но реалии суровы и мне нужно выбрать кого-то одного для работы.
Неплохим аналогом смотрятся новые маломощные платы от Raspberry, а некоторые вроде Raspberry Pi Zero 2 W выглядят как пропущенное звено, которое я искал выше в переходе от отладочных плат к микроконтроллерам. С другой стороны, ESP должен чем-то ответить на такую попытку захвата их рыночной ниши, так что последующие улучшения линейки могут сделать изучение плат Raspberry бессмысленным, а может и наоборот.
Возможно, во время долгого акцента на мощном железе со стороны Raspberry, тулчейн и SDK у Espressif за это время улучшался, что скорее всего создаст значимую разницу между ними по инструментам. Даже если новые платы будут дешевле и лучше по характеристикам, то этого может быть недостаточно: популярность, коммьюнити, наличие библиотек, примеров, проектов и прочие факторы также влияют на преимущества. Нежелание или невозможность развивать тулчейн для новых Raspberry-плат может оставить выгодным ESP в домашнем хозяйстве, даже мирясь с его недостатками.
С другой стороны, платформа ESP долгие годы оставалась монополистом в DIY-электронике, что позволяло на некоторые проблемы закрывать глаза и копить технический долг, ибо в условиях монополии выбора у массового покупателя не было.
Теперь же в условиях конкуренции малейший недостаток будет помогать конкуренту продвигаться на рынке, а в сети достаточно много жалоб на ESP-шные проблемы, начиная от железа и заканчивая тулчейном с фреймворком. По этим проблемам сложно судить об их критичности и влиянии на будущее самого ESP, ибо проблемы есть у всех платформ, но такая мопонолия в прошлом сама по себе создаёт риск вложиться временем в то, что будет улучшено конкурентным аналогом. Всё-таки любой новый продукт может опираться на ошибки предыдущих. С другой стороны, при наивном исправлении этих ошибок можно наделать новых, ещё более проблемных, особенно при последующем усложнении и обрастании функционалом.
Для DIY-разработки критически важен функционал и нашпигованность платы разными возможностями, позволяющими быстро решить задачу несколькими способами, что экономит время и открывает дорогу к сложным проектам. По функционалу ESP догнать здесь сложно, ибо там напихано всего что только можно, да и скорее всего будет напихиваться и дальше.
Но конкурент может использовать преимущества в различных нефункциональных требованиях, например, в надёжности. Ради этого очень важного преимущества можно пожертвовать как функционалом, так и потратить больше времени на разработку и изучение аналога. Однако популярность никто не отменял: в дикой природе обитает много сходных по цене и технически лучших аналогов ESP, но без популярности и большого коммьюнити трудоёмкость разработки на таких платах сводит все преимущества на нет.
Все эти платы достаточно дёшевы в сравнении, например, с тем же STM32 сходных характеристик. С одной стороны, stm-мы почти промышленный стандарт, поддержка различной периферии, менее проблемное использование сторонних системных языков и прочие бонусы. С другой стороны, в домашнем IoT-строении задачи совершенно иные, сильно отличающиеся от промышленных, а вкладывать время ради более редких или периодических кейсов выглядит расточительным. А в условиях сочетания с другими IT-навыками скорее невозможным. Итого, пока я не уверен, что STM32 мне нужен при всей его популярности.
Кроме того, RISC-V, который используется в части плат Espressif выглядит намного более удобным для IoT-рынка с его огромным количеством небольших компаний, часть из которых будут эксплерентами в рыночной конкурентной борьбе. Новые экспериментальные продукты с неопределённой прибылью могут плохо сочетаться с закрытыми архитектурами типа ARM. Также нельзя исключать и вероятное стремление к технологической независимости Китая. Итого, доминирование ARM в промышленности и в мобайле не означает, что рынок IoT, взрывной рост которого ожидается в ближайшие годы будет завязан на эту же архитектуру. Возможное изменение рынков вносит риски для обучения, создавая шанс потратить своё время впустую.
Как видно, не так-то и просто выбрать себе плату для вспомогательных IoT-задач, а при таком выборе запросто может упустить какой-нибудь нюанс. Например, температурный минимум в -20°C в даташитах Raspberry выглядит как-то подозрительно. Придётся немного подождать, почитать, понаблюдать, да подумать.