Делюсь опытом Моя "основа" для умного дома на Lua

[e5004c]

На самом деле ничего умного нет, это только начало, сейчас к сожалению нет времени доделывать, умеет работать с ограниченным количеством датчиков (bmp085, bmp180, ds18b20, dht, датчиками влажности почвы и освещенности которые имеют аналоговый выход) и реле и отправлять и принимать данные по MQTT. В коде нет комментариев, но могу подсказать если надо, да и просто неплохо иметь примеры кода.
1. После прошивки ESPшка стартует в режиме AP и позволяет через веб интерфейс указать минимальный набор данных для подключения к WiFi и MQTT
2. После сохранения конфига перезагружается, подключается к сети и MQTT брокеру, пытается определить наличие датчиков (умеет bmp и dht, не идеально но работает), поднимает telnet, представляется в mDns
3. Начинает отсылать данные на брокер

Умеет еще много всяких штук, но к сожалению ничего пока не документировано. Если будет интерес напишу документацию.
Память съедает почти всю, видимо это проблема моей реализации, буду благодарен за советы.
Прошивку под нее надо собрать через онлайн билд со всеми нужными модулями, сейчас точно не помню какими, если будет интерес напишу)

Ссылка на гит: GitHub - sfrangulov/nodemcu2 at develop

 

[sevic]

Отличная задумка и красивая реализация Но если советы принимаются, я бы (код посмотрел бегло, может это и реализовано, но я не заметил):
- добавить функционал термостата/светостата/чего-то стата, котрый будет работать на основе данных локальных датчиков или данных, транслируемых в определенном MQTT - топике (об этом чуть ниже). Для термостата можно использовать данные с d18b20 или dht или из топика, который будет задан по MQTT или вычитан из конфига. Для светостата - данные с adc или также из задаваемого топика. Это позволит достаточно легко реализовать очень интересные сценарии с распределенными датчиками и исполнителями, причем "сборку" этой конструкции можно делать "на лету", .т.е отправляя участникам сети команды какую логику активировать для какого gpio и откуда брать- куда слать данные (в виде топиков). Я попробовал у себя, очень понравилось. Например, на участке в двух разных местах установлены комплекты из ESP + реле на gpio и на одном из них (назовем его node A) есть фоторезистор на входе ADC, и на обоих датчики движения в "местной" зоне. Поверх этого всего хозяйства сидит openhab, который постоянно слушает топик, в котором node A транслирует (раз в 2 минуты) уровень освещения в %. Если уровень освещения снижается ниже заданного порога(т.е. на улице стемнело) openhab дает по MQTT команду обoим нодам "слушать" топики друг друга, в которых транслируется инфа о срабаывании датчиков движения и актвировать локальные датчики движения . Таким образом, при срабатывании любого из датчиков движения в темное время суток обе ноды включают свет в "своих" зонах (зоны расположены на противоположных концах садовой дорожки и это имеет смысл). Утром (т..е освещенность увеличилась) open hab шлет тпа stop topic listen и еще deactivate local motion sensor. Приблизительно тоже самое происходит в доме (там тоже есть две ESP в разных местах), но в отношении температуры - openhab натренирован указывать ESP из какого топика брать температуру для термостата управления котлом, и это все ради того, что если начинает топиться камин, данные ESP, расположенной в комнате с камином перестают слушаться, котел начинает термостатироваться по данным температуры с другого этажа (где может быть очень даже и не жарко). Пояснение сумбурное, сорри, но возможность создавать логические автоматы с указанием топиков откуда брать текущие значения контроллируемого параметра или куда транслировать данные с локального датчика очень даже было бы неплохо. Когда закончу отладку, выложу и свой код, но он не такой красивый как у Вас...

 

[sevic]

Хочу в итоге добиться картины, когда все esp будут на одном общем конфиге и логика работы системы в целом будет задаваться трансляцией соотв. конфигурационных сообщений каждой из esp нод. Чтобы не программировать их отдельно и под строго "индвидуальные" задачи

 

[e5004c]

Спасибо за советы, логику я постарался вынести из нод, что конечно лишает их автономности, без сервера начинается "разброд")
Логику в самих нодах держать процесс трудоемкий, мало у нее ресурсов, да и без брокера они не взаимодействуют между собой. Обдумывал я сделать процесс децентрализованным, но так или иначе нужно, чтобы какая-то нода выступала контроллером/координатором. А так у меня есть полноценный автономный сервер из старого, но мощного, ноутбука где крутится брокер и вся логика. Брокер Mosquitto, а логика на Node-RED, советую присмотреться к этой штуке, она же может и веб интерфейс строить и графики рисовать. В качестве клиента использую смартфон на android и MQTT Dash мне хватает, автору огромное спасибо, развивает программу.

PS По поводу Node-RED, штука очень удобная, программирования минимум, все наглядно. Как пример к ноуту подключен ИБП от котла. В NR нарисовал workflow который раз в 2 недели запускает самотестирование ИБП, чтобы батареи подольше жили, сигнализирует если пропало напряжение в сети и прогнозирует сколько проживет без питания котел, т.к. от дома я работаю давольно далеко, если что буду предупрежден. Или workflow которое агригирует данные с разных нод и отправляет на narodmon.ru раз в 10 минут. Вариантов использования миллион.

 

[sevic]

"Логику в самих нодах держать процесс трудоемкий, мало у нее ресурсов, да и без брокера они не взаимодействуют между собой. Обдумывал я сделать процесс децентрализованным, но так или иначе нужно, чтобы какая-то нода выступала контроллером/координатором." - у меня тоже получается двухуровневая архитектура, но в качестве координатора и "окна в мир" я использую openHAB на RPI2. Под ним три ноды ESP8622, которые общаются с хабом и между собой по MQTT. Так оно видимо и останется, но низкоуровневую логику я все же решил реализовать на ESP8266. В основу легли мои предыдущие наработки, а так же я многое взял з Вашей концепции, уж больно красиво у Вас получилось На данный момент реализована логика термостата, автомата управления освещением на основе уровня освещенности, данных о присутствии "обитателей" на объекте и датчиков движения. При этом датчики движения, реле включения освещения или другие участыующие в сценариях элементы могут находится на разных нодах, и софт ноды не обязан об этом париться, получилось что-то типа местного "облака". Т.е. я в конфиге для термостата указываю с какого датчика брать температуру, откуда брать значение целевой температуры и где находится выход управления котлом. Весь (или отдельные его части) конфиг может быть изменен в любой момент времени по одной команде того же OpenHab, что соответсвует понятию "активировать сценарий Х". Таким образом, тот же openHAB реализует только высокоуровневую логику выбора сценария, а сам сценарий (что где мерять и чем и как управлять) реализуют ноды, но OpenHab видит данные, которыми ноды обмениваются в топиках MQTT, и визуализирует для меня любимого все важные параметры - температуру, состояние датчиков, освещения и т.п. И главное - это все уже почти работает, осталось допилить неск. вспомогательных функций и "на объект", т.е. на дачу. Кстати, несмотря на мои опасения, пока (в режиме отладки) проблем с памятью не наблюдается. Код по завеершении проекта конечно, выложу

 

[e5004c]

Проблемы с памятью у меня начинаются где-то с 5 разных датчиков подключенных к одно ноде, это косяк как раз "красивой" архитектуры))) Если датчиков немного, даже если память где-то натекла, нода перегрузится и продолжит трудится дальше. 3 таких ноды стабильно трудятся уже несколько месяцев.

 

[sevic]

Да, похоже я тоже уперся в память. Все работало, пока не приспичило добавить обработку прерываний. Более-менее доступный способ реализовать обработчик прерывания в "полностью конфигурабельной" среде это использовать "замыкание" ("closure"), потому как примитивный интерфейс колбэк функции в NodeMCU не позволяет передать ничего, кроме уровня входа в момент прерывания. Так вот, в принципе с замыканием получилось, но при отработке прерывания нода валится в панику по причине "not enough memory". Горе мне, горе. Наворотил кучу кода, а теперь все выкинуть? Попробую пока менее радикальные методы - выгружать модули после отработки цикла, звать на помощь garbage collector и т.п. Но чую, надо "что-то менять в консерватории" (с) М.Жванецкий. Буду рад за совет как реализовать обработку прерывания, если нет возможности использовать compile time функцию, т.е. ее приходится создавать на лету и назначать обработчиком прерывания

 

[Stas_Is]

Да, похоже я тоже уперся в память. Все работало, пока не приспичило добавить обработку прерываний...

Насколько я понимаю, в NodeMCU зашита именно асинхронная парадигма, то есть "решение проблем по мере их поступления", а Вы хотите заставить с помощью прерываний работать их в синхронном режиме? А зачем? Полюбите коллбэки, они очень удобны!

 

[sevic]

Вы хотите заставить с помощью прерываний работать их в синхронном режиме? А зачем? Полюбите коллбэки, они очень удобны!

Во-первых, очень рад, что тема ожила. Во-вторых, отвечая на Ваш вопрос предложение, скажу, что мне асинхрнная парадигма очень даже по душе, и даже задолго до появления Lua@ESP я так или иначе пытался ее реализовать даже там, где ее отродясь не было. Особенно для встаиваемых т.е. (полу)автонмных систем лучшего и не придумать. Но все равно, синхонное исполнение никто не отменял . Какие-то куски кода исполняем в цикле, какие-то ждут событий и скармливают данные синхронному потоку. Ну и при обработке асинхронного события тоже неплохо бы иметь доступ к данным синхронного потока. В принципе все работает. Мой предыдущий пост был немного о другом. Как неоднократно обсуждалось в разных топиках этого форума так и других, "неаккуратное" использование Closures в реализации NodeMCU приводит к гарантированным утечкам памяти. В данном контексте "неаккуратное" означет обычное, т.е. нужно использовать дополниельные шаги при выходе из Closure, чтобы предотвратить эти утечки. В целом идея описана в "Unofficial MCU FAQ" на английском. Если владеете, погуглите. Хотя, скорее всего Вы это уже читали
Я вот сейчас подумал, и понял, что насчет синхонного потока я погорячиля . Даже он является асинхоннным, поскольку инициируется таймером. Но он в понимании "обычного" программиста выполняяет функции синхронного цикла, т.е. проверяет надо ли обработать очереди, "помигать светодиодиком" и т.п. В общем где-то так...

 

[Stas_Is]

А вот скажите, пожалуйста, как по Вашему мнению, - стоит ли делать ставку вообще на ESP в IoT-системах? Не боитесь их "неоткрытости"? В один прекрасный день кааак грохнется все по команде из центра! Понятно, что цена вне конкуренции, но все же?...

 

[sevic]

Ну тут как карта ляжет.. Вопрос : кому это нужно ? Espressif? Ребята потихоньку имеют свою прибыль и, как мне кажется они бесконечно далеки от какой-то политики. А если и грохнется? Обычно на ESP вешают некритичный функционал по принципу "работает, и то хорошо". Грохнется так грохнется. Но это вряд ли.