РЕКЛАМА НА ФОРУМХАУС Тут еще такое дело. Если чисто оценивать надежность системы по доступности функционала, то да, децентрализованное решение выглядит интереснее, так как с выходом узлов из строя, будет накрываться только часть функциональности, которая, связана с этим узлом (хотя и здесь надо очень грамотно все делать - например ставить вачдоги на все узлы, которые шлют информацию данному узлу. Если все сделать по-грязному, можно наломать дров столько, что будет падать все вместе). Хотя в самом критичном случае - если накрывается реле освещения - то потеря 100% функциональности, как ни крути. Если же делать все централизованно, то выход из строя сервера сценариев = потеря всей функциональности одновременно. Но на практике все совсем не так плохо с централизованными системами, а точнее кое что во многом лучше. Все потому, что так называемая Single Point of Failure в централизованных системах легко локализуема - то есть мы четко можем оценить, какой компонент приводит к 100% ному отказу системы, а на какой нам начхать. И в итоге, мы можем сфокусировать наши усилия в нужном русле, чтобы повысить надежность именно этого компонента, часто путем дублирования, а не парясь над каждым из ста модулей. Применяя данную практику к УД при централизованной системе четко видно несколько SPOF. Но все они имеют дешевые методы повышения надежности! Вот они: - Wi-fi - отрубается роутер, накрывается УД. ОК - ставим второй роутер, только другой марки, создаем резервную точку доступа, Wi-Fi сеть и настраиваем ESPшки, или что там у нас так, чтобы если первичный Wi-Fi потерялся, они автоматом цеплялись к резервному. Готово. SPOF убрали. - Гейтвей или MQTT брокер - опять же легко дублируется. Резервный брокер, на другой физической платформе. Пока главный рассылает и принимает сообщения, резервный его мониторит. Как только главный накрывается, все узлы перецепляются к резервному и начинают работать через него. - Сервер сценариев. Тупо ставим второй OpenHAB на физически другом Распберри (или я бы опять же поднял бы его на другой платформе - Synology NAS, или Intel) и конфигурируем их так, чтобы если первый не отвечает, второй начинает выполнять все сценарии. Один в один. - Доступ в интернет - тут резервных способов решения полно, начиная от GSM каналов и заканчивая SMS обменом. А больше-то SPOF нету. И, вложивши всего пару сотен бакинских в железо, я получаю аппаратное дублирование всех критических узлов, которые сделают централизованную систему гораздо надежней децентрализованной. Мало того - получаем hot-swap - то есть я могу вообще без потери функциональности произвести замену вышедшего из строя задублированного узла или обновить его прошивку, или поиграться с сценариями в нужный момент вернуть все обратно. То есть жильцы не заметят дискомфорта вообще. Поэтому в индустрии и особенно в ответственных системах все делается централизованно и дублируется, несмотря на "интеллектуальные" датчики и актуаторы. Это я точно подтвердить могу.
@lingvo, согласен! равзе что по распбери в выключатель и кластер делать тогда и децентрализаци и резервирование. Альтрернативные прошивки роутеров сейчас очень функциональны и на них можно реализовать резервирование наверняка. У меня так и будет - OH стоять на nas домашнем. а насчет нужно ли резервирование - время покажет. Роутер года 4 дома работает не перегружаясь (разве что эл-во пропадает). БП поставил только на него сразу хороший - и никаких проблем. На работе у меня железки как правило если и умирают то блоки питания. Есть железки по 20 лет молотят и только замена бп..главное поменьше дешевых разъемов в системе.
@lingvo, все это хорошо и возможно правильно. С правильным подходом. Когда проект (со знанием и опытом), ремонт, провода... В общем когда с нуля. А когда все сделано, половина при этом забыто или не додумано... Короче: начал потихоньку переводить на esp свою квартиру (что уж на столе экспериментировать). Начал с аквариума. Есть там такое устройство называется протока по одному шлангу. Задача - долить чуток воды, слить чуток, долить, слить... Старый контроллер на MSP430 был тупой - сливал, доливал без пауз. Поэтому и поменять решил на ESP№1, что бы параметры контролировать/устанавливать. Далее. В выходные буквально за час сварганил устройство на ESP№2, которое будет включать нагреватель (холодно) или вентиляторы в крышке аквариума (когда жарко). (кстати оцените кол-во строчек в примере souliss e05_Thermostat. И ведь это уже с управлякой на смартфоне) ESP№1 достаточно ответственная - можно же и соседей затопить если по каким то причинам включится на только долить (хоть и маловероятно, хотя. надо проверить как собачка работает). А не повесить ли мне тогда на ESP№2 доп датчик уровня воды, который будет следить за ESP№1 ? А еще бы этому ESP№1 неплохо бы сообщать когда шибко много воды подливает и в результате температура падает, поскольку нагреватель не справляется (дно акваримума иногда полагается "пылесосить" - до трети объема сливается) И что? Вешать эту логику на OH? Да когда еще руки до этого дойдут и ОН в боевой режим готов будет встать... Сейчас думаю очередную esp поставить в совмещенный санузел. Управление вентилятором по датчику влажности/температуры, светом по датчику движения и (пока) по NTP. (нет случайно мыслей какие датчики нужно повесить что бы определить что жена душ принимает? именно душ и именно жена) ... В общем рано или поздно обрастет квартирка железками. Ну а по ходу уже и поймем какая логика работы нужна, какие косяки вылезут. Перепрошить по wifi не проблема, как и завернуть все или не все на ОН.
Оценил, только вот сама функция Logic_Thermostat (ANALOGDAQ), ака Souliss_Logic_T31 занимает не одну сотню строк кода. А без нее термостат работать не будет.
@lingvo, комментировать не буду: Вашу точка зрения понятна, моя - не суть. Вольно не вольно, ушли от названия темы ОН. Да и последние страницы - соображем по сути на троих. Мало кому интересно. Посему тук ка минимум есть ЛС - будет желание можно и там обсудить/поспорить
@lingvo, насчет строк кода не важно если оно отлажено и ресурсов хватает и потом во что этот код компилируется. @Алексей122, как определить что душ и что именно жена? - снять звуковой фон и создать уникальный звуковой профиль всех обитателей дома (шучу). Можно в скайпе группку создать если есть желание. мой скайп pistoletov (с миньонами на картинке)
Добрый день. Алексей122, Тема очень интересная для меня, и я думаю не только для меня). Если Вас не затруднит не уходите в ЛС. Проста я в этом деле навичёк и что-то путное посоветовать пока не могу. Почитав про Souliss (на английском трудновато читать) возник один глупый вопрос: Souliss - это самостоятельная система на подобие OpenHaba или "прослойка" между Arduino и OpenHab?
@DenLiss, souliss это скорее прослойка. Это фреймворк, который позволяет на базе arduino, esp8266 создавать сеть интернета вещей. В сети могут быть разные устройства, физические среды передачи вот соулисс как раз и позволяет делать такую сеть с логикой работы и управлением с андроид-приложения. Openhab это уже linux-приложение которое может собирать данные от устройств (или программ) различных производителей и делать вещи более высокого уровня - хранение значений в базе данных, отображение графиков различных, выполнение сложных сценариев в общем это сервер умного дома. Souliss это то что прошиваем в esp Или arduino -) Надеюсь смог объяснить.
Прослойка - это скорее MQTT, который собирает данные для логики опенхаба. в соулисс сами устройства заменяют MQTT (легко задать кто издатель, кто подписчик, и на что подписывается). Там же в устройствах прописывается логика. Собственно по большому счету для соулисс опен хаб нужен только для расширения функционала. Соулисс, кстати, тоже может вести бд и рисовать графики. С некоторыми ограничениями конечно же.
@Алексей122, mqtt это просто прикладной протокол такой же как и любимый в промышленности modbus, такой же и как http или ftp 4. Souliss же обеспечивает более низкую работу с пакетами на 3-м уровнем Osi. Ну бд для ардуино даж не слышал - это совсем не легковесные задачи. Объем бд может и мегабайты быть а это уже объем данных не ардуиновские. Если об Андроиде речь то он должен быть постоянно включенным в сети быть. Souliss круче - он живет в OSI ниже уровнем чем MQTT он обеспечивает маршрутизацию пакетов данных между разными устройствами.
Пример проекта для умного дома на souliss и openhab https://github.com/ribico/gr-home-automation по проводам, на готовых модулях...
@Алексей122, спасибо. Souliss в отличии от wi-fi.iot прекрасен своей документацией. Ну про возможности вообще молчу. wi-fi iot хорош что бы за вечер понять что такое esp8266 и ее возможности для управления умным домом не изучая программирование
@Артем_Тихонович, каждый выбирает то что ему удобнее. wi-fi iot мне не подошел из за своей ущербности - ограниченная функциональность и отсутствие самодостаточности. Souliss то же не идеал - свои ограничения и глюки (славо богу что пока не принципиальные). А программирование все равно изучать. Если не не одно, так другое (веб, скрипты и пр.)
А что за глюки у Souliss? Iot - ущербный и документация кривая но для быстрого старта - например проверить работает ли esp на живом функционале - вполне себе решение. Концепция соулиса мне пока очень нравится изучаю его помаленьку. Немного своеобразный подход у них. Я на iot датчики температуры сделал быстро - и openhabom графики снимаю насколько эффективно отапливать камином-)
пока мелочи (а может руки кривые). В родном клиенте в термостате температура округляется до целых (в ОН все ОК) и не работает у меня SHIFT_50ms (https://github.com/souliss/souliss/wiki/SoulissAPI)