Comments 21
У меня основное решение для мониторинга дачи - самописный телеграм бот бегающий на 2 raspberri pi. К одному подсоединены датчки к GPIO, а другому датчики zigbee (проект zigbee2mqtt). В качестве запасного варианта использую готовую sms сигнализацию с аккумулятором. Она всегда сможет измерить температуру батарей и скажет есть ли электричество
Кто-то покупает банальную GSM - сигнализацию с двумя симкартами и свинцовым аккумулятором. Сигналы типа "пожар", "потоп" и "отключение электроэнергии" поступают в телефон пользователя посредством банальных СМС. Вполне себе дачный вариант.
Проблема в том, что этого часто недостаточно. Личный опыт уже есть и суть в том, что нужно существенно больше информации, чтобы понять причины и прогноз. Ну т.е. само по себе отключение электроэнергии - ничего не значит, из-за этого не надо всё бросать и срываться ехать - ведь рано или поздно электричество включат.
А вот когда в связи с этим отключением замёрзнут трубы - это зависит как от динамики изменения внутренней температуры, так и температуры на улице. Причём, скажем на кухне она может меняться совершенно не так, как в ванной (потому что на кухне ввод трубы в дом и там холод проникает быстрее). Ну и т.д. Всё не так просто - на практике оказывается, что ситуации бывают очень странные (типа самопроизвольного срабатывания УЗО один раз за три года из-за грозы!).
Да, но мы же на Хабре. Тут люди любят делать что-то своими руками
Если будет совсем выворачивать от Arduino Studio, то можно поставить в связке VSCode + PlatformIO.
По мне, так это единственный вменяемый вариант работы с ESP32, если дополнительно требуется Arduino Core.
Для встраивания в Home Assistant есть экзотические варианты типа ESPHome (https://esphome.io/) . По опыту советую что-то очень простое делать, иначе замучаешься в YAML-е не правильный отступ искать.
Есть также интересные проекты, вроде языка Toit (https://toit.io/). С дровами вроде порядок. Из особенностей, он как бы ставит на ESP32 свою виртуальную машину и дальше само приложение очень бистро загружается и вполне себе быстро работает. У меня самого пока руки не дошли поиграться с этим.
А для любителей dotnet есть dotnet nano framework (https://www.nanoframework.net/) . Тоже виртуалка, но пишем на CSharp. Также всё неплохо с драйверами и поддержка не только ESP32.
Для встраивания в Home Assistant есть экзотические варианты типа ESPHome (https://esphome.io/) . По опыту советую что-то очень простое делать, иначе замучаешься в YAML-е не правильный отступ искать.
Почему экзотические? Вполне приличный проект, который отлично интегрируется в Home Assistant. Еще плюсом в использовании Home Assistant в том, что можно сделать различные автоматизации.
У самого есть нечто подобное на Home Assistant, который крутится на простеньком мини-пк, который подключен к мини-UPS на 12в.
А еще можно на Zigbee сделать свои датчики например на PTVO.
в Home Assistant есть экзотические варианты типа ESPHome
Очень понравился ESPHome низким порогом входа. Перевел некоторые свои устройства на эту платформу, хотя до этого долго писал свою прошивку для них.
Сложную логику можно вынести на уровень HomeAssistant.
Вместо HA который имеет в 10 раз больше аналитики и esphome которые оттестированы и работают годами без нареканий вы нагородили кучу вермишеле кода, пользуете чьето облако и считаете это решение надежным...
Так мне не нужна аналитика, про которую вы говорите. Я решаю (решил) свою вполне конкретную проблему, в моих конкретных условиях. "Чьё-то облако" я не использую. Решение достаточно надёжное - первая версия непрерывно работала месяца три, текущая около месяца. Нарекания только по тому, о чём я упоминал в статье - это не основной функционал и добавлен просто из любопытства.
Основная сложность в том, что Интернет, увы, так устроен, что просто передать несколько байт между двумя компьютерами, которые к нему подсоединены - гигантская проблема.
На самом деле нет.
Если на вашем "сервере" белый статический IP (т.е. к нему легко достучаться извне), то никакой проблемы тут вообще нет. Можете написать свой TCP-сервер (это несколько десятков строк кода в самос простом случае), можете просто использовать UDP. Вам же не надо огромные объемы там прокачивать. Достаточно коротенькие пакеты - запрос состояния устройства, получение ответа на запрос.
Поверьте, опыт есть - в своей время занимался разработкой системы мониторинга инженерного оборудования зданий. Средняя по размерам диспетчерская - это несколько десятков контроллеров верхнего уровня, на каждом из которых висит 5-30 контроллеров нижнего уровня (и на каждом по несколько десятков конечных устройств разных типов). Каждый контроллер занимается опросом того, что к нему подключено и передает информацию ("сигналы") о событиях тому, к чему подключен он сам. Сигнал - короткая посылка из адреса источника, кода события и (при необходимости) данных о событии. На нижних уровнях работаем по RS-485, контроллер верхнего уровня на диспетчерскую работает по UDP - простой в реализации и легкий протокол.
На диспетчерской работает "микроядро" - сервис куда прилетают сообщения от контроллеров по UDP и у которого есть TCP сервер к которому подключаются интерфейсный клиенты (это уже визуализация того, что происходит в системе). Никаких "браузерных решений", никаких http. Никаких облаков. Визуализацией занимается клиент. Вся коммуникация крайне простая. Если ограничится масштабами одного дома - вообще делать нечего.
Для любителей MQTT есть промышленные LTE роутеры типа той же Teltonika с поддержкой MQTT в режимах subscriber/publisher/bridge (правда, цена не обрадует) - фактически получите собственное "облако". Да еще с возможность посылать смс/e-mail уведомления о событиях разных.
Основная проблема тут - получить белый статический IP.
В условиях деревенского дома проблемы будут другие. Само по себе отключение электричества не беда. У меня в доме (правда, ПМЖ) стоит вот такое
3кВА инвертор (чистый синус) + 2 АКБ по 12В 100Ач (на вход инвертора идет 24В, АКБ последовательно, емкость можно наращивать, подключая нужно количество пар АКБ - 2, 4, 6...) У меня через инвертор запитан насос в скважине (750ВА, работает через гидроаккумулятор т.е. там периодическое кратковременное включение для поддержки давления в ГА), компрессор в ЛОС (60ВА) и розетки в кабинете (ноутбуки, внешние мониторы, роутер, настольная лампа и т.п.) В нормальном режиме (работаем в кабинет, иногда в туалет, руки помять и т.п.) 8-10 часов даже на двух АКБ оно выдерживает легко. Добавить еще пару АКБ и убрать насос и компрессор (только компы) - несколько суток легко выдержит.
Но проблема в том, что при отключении электричества в поселке на длительный срок, может отключиться и питание вышки сотовой связи. И тогда связи не будет. Никакой (если других вышек нет поблизости). И это то, на что вы никак не сможете повлиять. Ну разве что городить канал связи на любительских радиочастотах (но там уже надо категорию, позывной и т.п. если хотите на более-менее дальние расстояния работать).
Если на вашем "сервере" белый статический IP
У меня есть всё, что необходимо. Но это потому, что я в этой сфере работаю и в курсе ситуации.
Фраза же из эпилога относилась к обычным людям, которые в теории могли бы купить подобное устройство (я там специально ведь это подчеркнул). Обычный человек не знает, что такое "сервер", "статический IP" и прочее. Поэтому он будет вынужден к устройству покупать ещё и услугу, надёжность которой от него не зависит. Нельзя просто продавать устройство - необходимо продавать ещё и услугу. В этом суть.
Что касается электричества, я в статье подчеркнул, что важна автономность этого устройства. У меня в доме есть инвертор, AGM аккумуляторы (2 x 200) - они довольно долго обеспечивают 220в. А теперь представьте - допустим, в дом влезает вор. Первое его действие - отключить всё электричество (знаю, о чём говорю - уже сталкивался). Вы никак не спрячете здоровенные аккумуляторы и инвертор (с работающим вентилятором!). А моё устройство просто никто не заметит - оно будет продолжать отсылать информацию если вырубить вообще всё, похожее на электричество. Есть и другие ситуации. Моё решение - оно не просто так, я исходя из реального опыта.
Насчёт питания вышек сотовой связи - за три года в моей деревне (Ленобласть) я фиксировал пропадание сотовой связи один раз, примерно на час. И это не было связано с электричеством (скорее всего, они что-то ремонтировали). Там, насколько я знаю, после разряда аккумулятора включается дизель. На сотовую связь много что завязано - например, работоспособность охраны объектов, поэтому они к этим вопросам очень серьёзно относятся.
Ну я из своего опыта говорю. В первую очередь - мониторинг большого количества разнородных устройств (десятки тысяч), распределенных на очень больших площадях.
Причем, там никаких облаков и вообще внешних серверов не предусматривалось изначально. Поэтому и архитектуру свою и протоколы все сами разрабатывали. Поэтому и говорю - есть IP и номер порта, то гонять сообщения (датаграммы) по сети - вообще не проблема. Чуть сложнее чем Hello World.
Во-вторую - ситуация с пригородах. Вот у нас 3-го мая с.г. накрыло снегом. Местами до 50см выпало. По области - 80тыс человек без электричества (налипание на провода, падение деревьев на провода) в течении 2-3 суток.
Конкретно наш поселок - повезло. Аварий не было. А у коллеги дача неподалеку - 2 дня без электричества и, что характерно, без связи. Вообще какой-либо связи. Ни одна из вышек в округе не работала.
Разобраться всё-таки со стабильным определением срабатывания геркона.
Конденсатор 100 нФ на землю добавьте. Чтобы при этом не залипали контакты геркона - последовательно контактам поставить 100 Ом.
Я в статье не упомянул, но там дело не в залипании именно геркона, так как я отлаживал эту проблему, поставив вместо геркона обычную кнопку. Т.е. проблема устойчиво воспроизводилась без геркона. Вообще, когда я полез гуглить, то был удивлён (как человек, к электронике имеющий лишь косвенное отношение), насколько много людей пытается решить проблему с устойчивым определением срабатывания состояния кнопки ESP'шкой. Речь даже не про дребезг, с этим понятно, а просто определения замкнуто-разомкнуто. Причём, в сравнительно идеальных условиях - типа отсутствия помех по питанию (если питание от батареи).
Там дело в микросекундных импульсных помехах, которые ловятся контроллером и отсутствии аппаратной/программной фильтрации импульсов короче десятков мс. Судя по тексту, написать программную фильтрацию для вас будет сложней чем сделать аппаратную, да и она плохо совместима с прерываниями и сном, поэтому предложил впаять конденсатор и резистор.
Подавление дребезга - это одно. Есть еще программная логика. Когда делали свою систему, у нас даже был отдельный тип устройства - концевик с задержкой. Т.е. "аварией" считался факт непрерывного его пребывания в аварийном состоянии в течении заданного времени.
Правда, это было для другого - РИТО (реле индикации точной остановки) и РКД (реле контроля дверей) в старых советских лифтах (где не было лифтовых контроллеров типа УБДЛ и иже с ними). Там суть в том, что когда лифт на этаже - РИТО замкнуто. Когда едет - оно разомкнуто с кратковременным замыканием при проходе очередного этажа. И то и другое - норма. А вот когда оно непрерывно разомкнуто долго (скажем, дольше 20-30сек) - это плохо - лифт завис между этажами. Это уже авария.
Эта логика у нас на уровне контроллера была реализована (начинали в 90-х с контроллеров на 8080, современные версии были на STM32). Подробностей не знаю - под контроллеры не я писал (я микроядром занимался), но там что-то типа таймера было - обнаружили "аварийное состояние" - запустили таймер, обнаружили норму - сбросили - если состояние аварийное и таймер превысил пороговое значение - формируется сигнал об аварии.
Это все, естественно, уже поверх чисто аппаратных решений типа интегрирующих антиидребезговых цепочек.
Проблему с герконом можно было решить внешним подтягивающим резистором. Внутренние не обеспечивают достаточный ток и на длинный провод ловятся помехи.
Ещё не стоит использовать прерывания, если задействован WiFi - могут быть глюки в обработке прерываний.
Резервный мониторинг послушного дома