Arduino, ESP8266 Lua, Raspberry Pi 2 && OpenHab. Умный дом: азы управления.

a gde nado napisat nastroiki wifi shtob podkluchil esp na mayom routere

 

Вернитесь на 12-ю страницу и внимательно изучите пост ИгоряК:

 

Всем привет. На выходных дошли таки руки поиграть в современные прошивки для ESP. Ну что, сказать, за последние полтора года дело сдвинулось с мертвой точки. Залил прошивку с известного конструктора, все заработало с полпинка и уже двое суток без малейших намеков на ребут из-за недостатка памяти. может потому что не стал поднимать http-сервер (на прежней версии моего термостата он был), может и прошивка стала лучше, но теперь heap ниже 25 кВ не проседает (этого нынче достаточно?). После окончания отладки и дописывания недостающих функций обещаюсь выложить, мож кому пригодится, там есть интересные идеи, кмк .
Появился вопрос по openHab - кто-то пользовал Setpoint (в sitemap) со связыванием с item типа Number и дальнейшим биндингом на mqtt topic? Типа на нем руками выставляем желаемую температуру термостата, а openhab уже публикует установленное значение в определенный топик mqtt, который "слушает" ESP. Связывание "в лоб" не сработало, беглый гуглинг показал что во-первых, значение Setpoint надо инициализировать или восстанавливать из Persistence при запуске, и дальше с помощью rule транслировать в топик. Кто подскажет, в правильном направлении я пошел, или есть более прямые пути (без rule)? Биндинги типа switch и number работают, правда number только на прием апдейтов из mqtt. Вариант с термостатированием внутри openhab видел, мне не нравится, хочется сделать в ESP. Благо опыт какой никакой есть.

 

Все что у меня есть на эту тему - описано здесь.

 

Спасибо, Игорь, это что надо! Помню, где-то у Вас и видел, но что на первой странице треда, как то не подумал.

 

У Вас Dacha_Kotel_Getting в sitemap и в items имеет разные label, причем, насколько можно судить по приведенным скриншотам, openhab использует label из sitemap, а label в items игнорируется, я так понимаю?
И еще, может плохо смотрел, Вы его при старте не иницализируете и в persistеnce не храните, он у Вас заполняется из { mqtt="<[mosquitto:/myhome/dacha/kotel/get:state:default]" } ?
т.е, например, при старте openhab в очереди mosquitto уже лежит какое-то значение (видимо, периодически транслируемое в этом топике) и оно "влетает" в item после старта mqtt - листенера? Если так, то элегантно..

 

Я Вас очень прошу самостоятельно повторить все что там сделано и разобраться как это работает.

Это так. С одной стороны, я эту систему тестировал две недели, иначе бы не публиковал здесь. Тестировал с обычной лампочкой (как обогреватель) и DS18b20. С другой - у меня на отоплении котел Valliant и его родная система управления. Нет смысла вмешиваться в их работу. Так что все приведенное - пример. Но проверенный и работающий.

 

Это было не замечание с моей стороны, если Вы восприняли это так. Ваш вариант вполне рабочий даже если управлять реальным котлом. Единственное чего он может не отработать (значение целевой температуры будет потеряно) так это одновременное пропадание питания на всех узлах системы (если нет резервирования, "но это же не наши методы"). Я планирую использовать персистентность my.openhab, что видимо, тоже не панацея, но посмотрим как будет работать. Есть еще идея прописать алгоритмы "умного" автономного восстановления работоспособности всей системы после аварийного завершения, т.е. с анализом длительности простоя, предыдущего "изветсного" состояния системы, текущей температуры внутри и снаружи (а не замерзла ли система), присутствия на объекте человека вообще и меня лично как "адмнистратора". В общем, планы, планы...

 

А вообще проектирование полноавтономных систем тема невероятно сложная и интересная.

 

Устройство пишет целевую температуру в отдельный файл. При старте проверяет его. Внимательнее. Повторите - увидите. Основная часть - прибор, а не OpenHab - это правило.

Не, нормально. Просто нет времени разжевывать.

 

Это ошибка . Управление обязано быть автономным. Поэтому, кстати, и нет инициализации OpenHab - он просто подхватывает целевую температуру от устройства.

 

А вот это поддерживаю 100%. Openhab - рисовать картинки и не мешать дому работать
Просто проработав много лет в современной (надеюсь ) телеком индустрии подсознательно стремлюсь к концепции ''distributed redundancy', распределенной избыточности что-ли...

 

Мало нас таких. Основная концепция "умного дома" - Ардуино Мега о 54 ногах/реле, управляемая через интернет со странички с кнопками. Бэээээ.....

 

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

Понятно - значит я не один про отказоустойчивость заморачиваюсь, коллега. Кстати стоимость железяк такова, что не сложно сделать и дублирование основных систем.

Ну это всегда так, чтобы понять как правильно что-то спроектировать, опыт нужен.

 

А почему тогда souliss никто не рассматривает? Биндинг для опенхаба есть. Опенхаб только картинки рисует. Вся логика в приборах/узлах. Если нужно данные от одного узла другому передать - опенхаб не используется. Накроется любой из узлов или опенхаб - на работоспособность остального никак не повлияет. Никаких плясок с rule. У меня к слову по сути лишь одно правило - отображать в удобоваримом виде время контроллеров/таймеров . Нужно логику изменить - не так уж и долго по воздуху прошивку обновить. Да, есть недоработки (биндинг например не на все что хочется) - но они обходятся (правда порой через одно место).

 

Дык... Вы же не создали тему и не разложили все по полочкам...
А если серьезно, то основа здесь модули ESP8266, а не Ардуино. Ардуино - вспомогательные устройства в этом проекте.

 

Для созданий тем и раскладывания по полочкам пока не дорос.
Я пока просто подбираю для своего будущего дома решение - тестирую проекты, попутно кусочками автоматизирую квартирку - так, что бы в боевом режиме а не на столе поработало.
Предполагаю, что большинство то же выбирает не первое попавшееся решение. Соотвественно если какое то решение не выбрано - то есть причина. Собственно этой причиной и поинтересовался. Правда как то не предполагал что это может быть кол-во полочек.

Про основу не очень понял. У меня уже под 20 шт ESP в сетке. Хотя для соулисс все равно - ESP, дуины по RS485, дуина с езернет шилдом или NRF24.

 

Я не представляю точно что такое соулис. Мне вполне хватает возможностей NodeMCU на ESP8266 и том способе связи, который я использую с Ардуино.
Я полагаю так, чем в более специализированные вещи ты уходишь, тем сильнее зависимость и меньше места для маневра.
Очень уважаю Ваш выбор, поэтому, пожалуйста расскажите о нем в своей теме. Так будет правильно.

 

Расскажу чему сам был свидетель. Был на конференции - вопрос из зала ,"а когда будет поддержка windows phone". Ответ был такой -" мы конечно уважаем фирму, но пока данный продукт не будет иметь 20% рынка, то поддержки для этих устройств не будет. Конференция была 4 года назад, поддержки нет до сих пор.
В моем понимании нужно использовать, только продукт имеющий историю. Завтра разработчикам соулис надоест продолжать проект и куда Вы пойдете потом с ним ?
В основе же наших систем автоматизации лежит MQTT, а это уже стандарт автоматизации. Чтобы не произошло с частью, главное останется, и чем больше Вы будете использовать таких стандартов тем надежнее ваше проектирование.

 

А зачем мне куда то идти? Если сделал - работает и есть не просит.
В крайнем случае на тот же MQTT перешить всегда можно - железо же не меняется. Я просто почему про соулисс спросил - да потому что вроде тут куча стронников "распределенной избыточности" или как там правильнее сказать... в общем надежности сети. А соулисс, с моей точки зрения, как раз этой задачке лучше всего соотвествует (peer-to-peer, event based...) ... Ответ на свой вопрос я кажется между строк увидел - так что вопрос снимается...