РЕКЛАМА НА ФОРУМХАУС Неоспоримое преимущество OpenSource решений над самоделками - огромное сообщество и как результат большое количество поддерживаемых интеграций. Если в НА есть встроенная поддержка MQTT - то и допиливать ничего не надо, пришел топик - сенсор принял значение. Так и с Modbus, прописал что слушать Код: - name: modbus type: serial method: rtu port: /dev/ttyUSB0 baudrate: 19200 stopbits: 1 bytesize: 8 parity: E и читай регистры
Опенсорс - отличная штука, но дело не в опенсорсе. Практика неоднократно показывала, что чем многофункциональнее и интегрированнее некая система - тем она менее надежна и предсказуема в решении конкретных задач. Одна задача - одна утилита, как базовый принцип, по возможности. С ограниченным функционалом, но оттестированная до состояния гвоздя: либо забивается либо гнется. Не взлетает, не плавает, не выпускает колеса и хвост после апдейта - никаких неожиданностей, гвоздь это гвоздь, плюс-минус разный. Если задач много - выполняемые утилиты связываются простыми скриптами, выполняющими задачи в нужном порядке. Собственно, это все лежало в основе UNIX-систем, от которых потом опенсорс и пошел (Линукс тот же). Но есть другой путь: многофункциональные системы. Умеют и то, и другое, и третье. Как именно - никто уже толком не знает, нужно просто вот тут прописать вот такое слово, а там нажать кнопку. Ну или другую кнопку, если не получилось. Но в версии до 123, потому что потом кнопку сломали, и теперь надо по другому. Или на форуме разработчиков спросить. Или самому в коде найти, исправить, а лучше написать обновление с исправлением и выложить в сообщество. Зато теперь иконки поменяли и добавили поддержку мабута-протокола! Это из другого мира пришло - где принято запихать все в одно, и чем многофункциональнее тем лучше. Хотя тоже опенсорс... Мне первый подход ближе, желательно понимать из каких конкретно "гвоздей" оно состоит, где они забиты и как. И если надо добавить своих. DIY
Здесь проблемы другие, и ИМХО сложнее 1 - надо найти/сделать гвоздь, чтобы он не гнулся при забивании 2 - все забивают в разный материал, кто-то, кто в теме и все знает и умеет, в хорошее дерево, а кто-то в пенопласт или бетон по незнанию и неумению - вторых большинство, поэтому они выбирают путь многофункционального станка: там все само работает, пусть и не на 100% желаемых функций и не на 100% времени (на 99% ) и есть у кого спросить, что нажать
Да, где то так и есть ... но всегда есть стабильные сборки в какой-то из последних версий НА поломали modbus, причем напрочь! Ну и что откатился на предыдущую и все. Разговор о том, что когда у тебя несколько датчиков типа ds18b20 или dht22 - то нет проблем прикрутить их к Adruino или ESP, нарисовать страничку веб-сервера и наслаждаться результатами, периодически приговаривая: "смотри как я умею!". Все это пройдено и даже в этом случае не стоит потраченных сил на поиск библиотек и написание скетча, берется Tasmota или ESPHome и ВСЕ! Любые датчики, готовый веб-сервер и прочие плюшки. А если надо свести в кучу ESP, Oregon scientific, Xiaomi, Tuya, Sonoff ... Zigbee, WiFi и 433 Мц ... Самому писать интеграцию пылесоса Xiaomi с картами уборки ... ну Удачи ... если конечно время не жалко
Прекрасный пример "умный дом это круто, но непонятно нафига нужно" Зачем заниматься интеграцией робота-пылесоса с картами уборки, используя некую центральную систему управления? Это робот - вот пусть он сам и работает, по обстановке. Максимум - настроить один раз и забыть. Не умеет так? Значит это не робот, а игрушка с дистанционным управлением. Зачем нужно выводить на страничку несколько датчиков температуры? Достаточно одного - уличного, чтобы человек принял решение как одеваться перед выходом. Остальные - автоматика, причем если управление вентиляторами еще можно пустить через некий сервер, то управление нагревом вообще должно работать автономно и независимо, максимум управления - удаленно выставить пороги аварийного срабатывания в термореле, чтобы оно работало даже если сервер сдох. И вот так оно все. Эту тему уже поднимали не раз - что вообще такое "умный дом"? Правильнее все-таки не "умный", а "smart" - слово ближе к "удобный": автоматизация того что может быть автоматизировано, и удобство управления тем, чем надо управлять. Создание комфорта, экономия энергии или времени. Постоянный контроль состояния и настройка режимов - это и не комфорт и не экономия, это игрушки.
Отлично сказано. Действительно дом должен быть комфортным, и сделан под конкретных людей, под их запросы. И когда проектируешь именно по себя, часто без "паяльника" не обойтись. А температуру на улице проще на термометре смотреть, это удобнее. Правильно кто то здесь писал, "свет в комнате включаем голосом, а запускать и настраивать котел бегаем в валенках в котельную".
Самое интересное, что многие начиная строить "умности" не задумываются что же будет через пять - десять лет, что будет если тот, кто "паял" всё это уедет на долго, или не дай бог уйдет... Да просто забудет. Ведь зачастую проще не ремонтировать, а выбросить и сделать заново, если в каком то месте что то сломалось. По этому, как по мне, строить нужно так, чтобы не переборщить, чтобы с тем, что наделано мог разобраться специалист среднего уровня без привлечения разработчиков. А это в большей степени касается стандартизованых устройств, а не самоделок - самописок.
@Прохожий1, вот это и решается пока что разделением "чем мы управляем" и "что работает само". Если у вас стоит автоматический терморегулятор какой-нибудь - да какая разница как он сделан, он либо работает, либо сломался и его надо выкинуть или заменить. Может к тому времени будет 100500 альтернативных готовых девайсов в соседнем хозмаге. Если та же температура регулируется специальной управляющей программой, работающей на специальном управляющем сервере - с большой вероятностью никто не станет разбираться как оно там было настроено и какая там стандартная программа стояла. Все точно так же полетит в мусорку, и будет заменено на доступный пониманию нового хозяина аналог, например просто на выключатель "вкл./выкл.". Это все - игрушки. Не игрушками оно станет тогда, когда будут общепринятые стандартизированные протоколы взаимодействия (по том же принципу, как RFC описывают протоколы интернета, HTTP, например) и разработчики будут этих протоколов в своей работе придерживаться. И речь сейчас не про низовой уровень типа обмена MQTT или Modbus, а про логический: на запрос XXX вон та коробочка должна рассказать какие команды поддерживает, на запрос YYY выставляем нижний порог срабатывания нагревателя, а на запрос ZZZ включаем свет в комнате на 100%. При этом ZZZ всегда включает свет, и только свет, потому что это команда включения света, а YYY включает нагреватель, и только нагреватель, потому что YYY и ZZZ это совершенно разные команды (хотя технически внутри коробочки они совершенно одинаково включают реле). Но удаленный выключатель света будет отправлять только ZZZ, а терморегулятор будет реагировать только на YYY, и никак не наоборот. И вот этого пока не видно. Есть низкоуровневые стандарты, поверх которых каждый лепит что хочет, есть проприетарные, которые работают только с определенными устройствами, есть какие-то мозговыносящие описания то с побитовой упаковкой данных (Modbus-RTU), то с отправкой каких-то SOAP-запросов в XML с кучей спецификаций (ONVIF), есть программы-мультитулы с поддержкой того, другого и третьего. Это же дикая жесть, это неудобно. Интернету потребовалось 30 лет на то, чтобы остался десяток общераспространенных стандартов, для конкретных задач, и вымерла куча древних, когда-то популярных. Кто помнит Gofer, например, или talk? Вот когда-нибудь и с домашней автоматикой такое должно произойти. И тогда не будет вопроса "что будет если тот, кто "паял" всё это уедет на долго" - какая разница-то, фабричная железяка реагирует на команду или самолепная?
Эта тема ближе к индивидуальным решениям. Вопрос где искать разработчика не стоит. Да и ценовая политика не на последнем месте, а за коммерческий проект платит Заказчик. И когда разрабатываешь проект под узкую специализацию, он получается простой, и быстро исполнимый. Если пытаться сделать его универсальным, то он становиться сложным.
Ну тут просто затронута тема "что потом?". Вот есть решение - стандартизировать какой-то описание, назвать его типа SMART_AUTOMATION, определить в нем, ну например, команды отправляемые поверх MQTT, и придерживаться их. Если любая железка, создаваемая для себя любимого (или покупаемая где-то), будет поддерживать спецификацию, и любой софт-контроллер, написанный по этой спецификации, сумеет ими управлять - то вопрос дальнейшей судьбы снимается. Но сделать международным стандартом собственное домашнее решение непросто, а крупные производители на это никогда не пойдут, потому что зачем им нужно, чтобы любой Вася мог написать свой контроллер? За что тогда брать деньги, за продажу "очень надежных фирменных блоков", таких же точно как на Али? После того как привыкли продавать свои комплексные решения?
Естественно, что свои собственные решения международным стандартом не сделать. Они, как правило, решают проблемы конкретного дома. Производителей контроллеров Вася не интересует, так же как и Васю мало волнует их продукция. Вася за 5000р. соберет то, что у них стоит 50000р., он даже по этой причине будет делать свое, учитывая, что это еще и хобби. Вопрос, "что потом", волнует обычного Заказчика, с того момента как закончится гарантия. А при изготовлении для себя, вопрос не стоит, как правило "потом" (когда случится) "умный дом", -это самая маленькая проблема, по сравнению с тем, "как доехать до дачи". Таким образом реализация идей может быть как с использованием промышленных образцов, так и собственных разработок. И ответ на вопрос, что лучше "умный свет Xiaomi" или "Ардуино+реле" зависит от конкретных условий, а не от утверждения, что "Ардуино обязательно зависнет".
Для приверженцев "сам сделаю, потому что так никто не сделает" Смотреть с 3:40 и получать удовольствие.
Это просто отсутствие мозгов. DIY это другое. И этот человек, где то работает. Но к теме как делать умный дом это не относится.
Пару лет назад был на выставке где один из стендов был стилизован под жилую комнату. Красиво включался и выключался свет, задвигались шторы и одним пультом управлялся телевизор, домашний кинотеатр и сетевое хранилище с фильмами. Голосом включалась кофемашина... Всё это так красиво и так привлекательно было, но до момента, когда спросил о стоимости, техподдержке и совместимости. Тут начались разочарования... Все модули самосборные и собираться должны под каждого конкретного заказчика. Стоимость рассчитывается индивидуально, но очень дорого, так как ручная работа. Совместимости никакой. Закрытый протокол (я так понял что его даже не пытались с чем то совмещать). Платное обслуживание... И самое главное - ни одного реализованного проекта. То есть ребята предлагают провести эксперимент на объекте заказчика за его деньги и без какого то гарантирования результата. Фирме на тот момент было два года. Через год на аналогичной выставке встретил того же менеджера, который красиво рассказывал, но он предлагал автоматику для полива. Спросил о прошлой фирме... Та они попробовали, не получилось... Было несколько объектов, но фирма распалась, а программист и паяльщик уехал куда то. Как думаете, кто "сопровождает" то, что эта фирма наворотила? Мне так кажется, что заказчик попав на серьезные деньги второй раз не захочет умничать в доме. А если основная коммутация предполагалась по радиоканалу, то заказчик будет вынужден полностью переделывать весь ремонт, закладывая проводку под "глупый дом".