РЕКЛАМА НА ФОРУМХАУС Чуть Выше я ответил на такой же Ваш вопрос. Предложил спрашивать, если интересно. Вы промолчали и вот снова о том же... Могу предположить только два варианта - либо у Вас склероз, либо Вас зацепила правда. К тому же мой последний монолог относился не к вопросу о том как делать сейчас, а скорее о ситуации на рынке подобных систем и что ждать дальше. Это больше актуально не для тех, у кого стоит вопрос что делать при ремонте его дома, а для тех, кто на этом хочет заработать. Ну как бы он не совсем лох, вообще-то он из Форса (если Вы в теме, то в курсе) вышел и лично знает многих, кто уже не один десяток лет окучивает заказчиков по Ораклу. Именно поэтому мне и было удивительно наблюдать столь забавное перерождение
За совет спасибо. Я и не зацикливаюсь. Про корпоративные решения в облвсти IT я вам тоже много что рассказать могу, потому как больше 20 лет варюсь в этой области, и наши корпоративные клиенты - они из больших импортных компаний. Но это не для данного форума. Что же касается "ну нет там ничего сложного", то давно было сказано "каждая сложная проблема имеет простое, легкое для понимания неправильное решение". Домашние системы IT и управления - они имеют другой акцент, если сравнивать их с корпоративными. Типы нагрузок там другие, но они есть, и не маленькие. Первую домашнюю сеть с 10G сегментом я поставил лет 5 назад. В офисах мало кто 4k стримминговые сервисы использует, и многозонную музыку. Много IP видеокамер тоже редко бывает. А в частных инсталляциях они десятками ставятся, и FullHD, и 5-6Mpix. Да и системы управления по сути работают в real time. Так что есть своя специфика.
Это в первом приближении и исключительно для людей в начале понимания пути решения. Потом, как ни странно - сразу это уходит в область чрезмерного усложнения. Особенно с помощью разного рода консалтеров при вендорах, дальше определяется платежеспособность клиента и вырабатывается решение, укладывающееся в бюджет... я прекрасно знаю всю эту кухню, поскольку и сам имел опыт работы в интеграторах. Хотели сказать с 10G ядром? Я с трудом представляю сетку с 10G access портами Но даже если и так - даже если это огромная вилла, где одновременно используется десяток точек под 4к видео, куча HD видеокамер для видеонаблюдения... не срастается как-то такая необходимость. Ну пусть 30мбит/4к поток + 5мбит/камеру - получим максимум при сотне камер 800мбит, то есть гигабита хватит. И это при условии "узкого горла", на самом деле все еще проще - мультикаст для видео обеспечит снижение трафика, не надо будет формировать поток отдельно для каждого клиента при просмотре одного и того же потока, а для камер - так они вообще в других каналах пойдут, при этом 1G коммутатор в ядре (даже самый дешевый) вполне все это пропустит с приличным запасом. Я уж не говорю, что мои исходные данные для жилья вообще из области фантастики. Ну а вообще, 10G интересно разве что очень крупным клиентам и провайдерам. Для мелких интересно использование 10G разве что для подключения дисковых массивов к серверам как недорогая альтернатива fiber channel. Так что я предполагаю что тут как раз и был тот самый случай - клиент платежеспособный, почему бы и не "впарить"? Ну или расскажите что за такой мегатрафик в жилом доме приключился? Да, с realtime есть специфика, но тут не гигабитами надо брать, а industrial ethernet (например ethercat), но и это для дома совершенно неактуально, ну нет тут ничего, что требовало бы низких и стабильных задержек как в случае ряда промышленных задач.
Мне кажется направление "Умный дом" на данном этапе имеет свою специфику. На самом деле остро вопрос автоматизации не стоит. Это пока всегда(!) излишества, который хозяин хочет видеть. И как правили это либо богатые люди для которых это модно стильно молодежно, но при этом они не разбираются в предмете. Либо "кулибины" которые прочитав статьи из интернета собирают свои поделки и которым это просто интересно. Рынок предлагает решения и для тех и для других.
Я и спрашиваю. Вы показали только всякие графики и GUI, ничего не рассказав о принципах построения свой системы и о кабелях для нее. Вам непонятен мой вопрос? Объясняю - если спросить @asakharov или @Mycraft о принципе построения системы на KNX - они с легкостью в двух словах обьяснят, как и что там соединено. Спросите меня о Z-Wave - тоже пожалуйста. Ну так расскажите в двух словах о принципах построения своей системы - какая топология, как проложен кабель, как соединены модули, какой протокол, где крутятся сценарии автоматизации и как они программируются, как вы управляете освещением, есть ли у вас диммеры или RGB контроллеры, как организовано управление отоплением, шторами, кондиционером. Вы ошибаетесь и со многими это уже сыграло злую шутку. Типовая задача в УД - управление освещением, требует задержку на уровне 200-300мс максимум. Иначе управление становится некомфортным и начинаются щелканья выключателями. И многи простые протоколы связи, типа Modbus, могут обеспечить такие задержки только при минимальном интервале опроса и максимальной скорости, что создает приличную нагрузку на контроллер и сеть.
@XAPuTOH, вы совершенно правы, автоматизация - это не кусочек хлеба, без которого не прожить. Автоматизация, как и кино с телевидением, как и музыка - это дополнительные "бантики", улучшающие и украшающие жизнь.
Вот и я о том же - вы не очень хорошо представляете, какие задачи могут решаться в домашних системах. Вдаваться в подробности построения такой сети - это не для данного форума. Если интересно - вот технические детали.
У Ethernet есть пара милых особенностей: - потребление. Enc28j60 150mA peak 300mA и это на 10 MBit. Esp8266 300mA peak 1000mA. - WiFi решения несколько нестабильны по качеству связи, достаточно одного планшета с ютубом. - у точек доступа из SOHO сегмента начинаются проблемы при числе клиентов больше 10. Wi-Fi Alliance обещает выкатить для этих целей subGhz решение, но пока тишина. Подгадила. Вот только не "вендорам". Отсутствие стандартизации формата передаваемых данных означает, что под каждое подключение нужен собственный парсер. Нет способа сообщить об ошибках в приходящих данных, выставить 200% - всё норм. Что означает топик "ВхПнСрк" - спрашивайте у разработчика. У пользователя нет прав на такой subscribe - а в ответ тишина.
Полностью согласен и сам пришел ровно к тем же выводам. При этом, глядя на то, что происходит на рынке подобного оборудования, что появляются разные IoT девайсы с WiFi, вроде лампочек или "умных" холодильников и пылесосов, ожидаю следующего шага - стандартизации. Пока каждый производитель лепит свой интерфейс и приложение, интеграция которого в единую систему вызывает некоторые сложности. При этом достаточно сделать следующий шаг - поддержку mqtt и предоставление описания протокола для устройства - и пользователю станет легко и просто все это собирать воедино... Так Вы не спрашивали об этом, а я не телепат. Все построено на проводах, за исключением нескольких устройств с WiFi (кондиционер и несколько датчиков на ESP). В качестве ядра - ioBroker. За ним - интерфейс и бОльшая часть скриптов управления. Часть оборудования подключена к нему напрямую через modbus (как TCP, так и RTU), есть контроллер WB5, подключенный к ioBroker через MQTT. К WB5 также подключено несколько устройств modbus (RTU), на нем же выполняется и часть скриптов. Такая схема возникла исторически, WB5 прекрасный контроллер и многое умеет, но интерфейс там никакой, да и производительность его невысокая (по крайней мере для моих задач). Свет - светодиоды, управление Uniel. RGB нет за ненадобностью, только диммирование. Управление - есть входы на самом Uniel, к ним подключены кнопки выключателей (поэтому даже если сдохнет центральный контроллер - свет работать будет) + управление им через RS-485 для сценариев (выключить все, включение сигнализации, приход в квартиру и тп). Шторы - а что там сложного? Дискретное управление, либо открыты, либо закрыты. Промежуточного положения нет, да и не надо мне. Отопление - только часть управления климатом, есть датчики температуры, влажности, CO2, VOC, PM - по ним и происходит включение-выключение управляющих элементов - термоголовок на батареях, вентиляторов и теплых полов. Там все довольно хитро в логике работы - делалось под себя и под разные события. Например, проветривание балкона... Я там курю. Если окно закрыто (холодно зимой, на окне датчик), датчик VOC дает показания повышения уровня CO - включается клапан и открывает поддув из общей системы приточки для продува балкона. Кондиционер включен через WiFi в единый интерфейс ioBroker, частично управляется скриптами (например при уходе выключается сам), но в общую систему управления климатом не включен. Пока не придумал логической схемы как это сделать. Слишком много "если" для кондиционера, да и используется он эпизодически. А уж реализовать сие в скриптах - не проблема. Осталось не реализованным управление подогревом воздуха в приточке. Железо все стоит, надо реализовать программно ПИД регулятор для плавного управления нагревателем по датчику температуры в приточке и уставке требуемой температуры на выходе. Дискретно управлять не получится - инертность низкая. Буду этим заниматься когда холода придут, сейчас это затруднительно. Кроме всего этого - сигнализация с разными датчиками и и электрозамком, водоснабжение - счетчики, протечки, краны, система промыва фильтров, контроль состояния фильтра обратного осмоса. Система бесперебойного питания также контролируется централизованно. Это Вы ошибаетесь, тут не вопрос real time. Совершенно без разницы, сработает сие через 50 мс или через 200, лишь бы не через секунду. Modbus вполне у меня справляется. Да, с минимальным опросом, но на скорости 9600. Как я уже говорил, в основном свет управляется напрямую через входы самого контроллера Uniel, но есть и всякая мелочевка - вроде ночника, он управляется дискретно через вход modbus - проблем не испытываю. Кроме того, для сценарием этот Uniel сам управляется через RS-485 (9600, там хоть и не modbus, но очень похоже) - тоже проблем с задержками нет. Хотя есть некоторые проблемы совместимости этого протокола с WB5. Ну а Z-wave - сильно на любителя - дорого и бестолково. Применение ограничено тем, что заложил производитель. Гибкости никакой. Ну и управление по радио - я к этому отношусь скептически. Если есть еще вопросы или необходимость что-либо подробно прояснить - спрашивайте.
Глянул. Вопрос снят. Но задача, согласитесь, специфическая для дома. При этом есть сомнение, что сие изделие даже с 6 дисками в рейде (особенно в RAID5) обеспечит более пары гигабит (и это при условии что сам NAS не заткнется по производительности процессора), тут либо вместо дисков SSD, либо хотя бы использовать кеширование на SSD (не знаю, умеет ли, Synology умеет). Ну и рейд 50 или 60 (со страйпингом), хотя эта простая железка скорее не умеет сие. Это если действительно необходима такая производительность. Но что-то мне подсказывает, что сие было сделано скорее ради собственного интереса на деньги заказчика
Все верно. Но... потребление - актуально только при батарейном питании, чего лучше избегать. Нестабильность - есть и такое. Мое решение - устройства с большим трафиком сидят на 5Ghz AC, а мелочевка - на 2Ghz, к тому же с микротиковским CAPsMAN, что позволяет гибко настраивать управление точками доступа и перебрасывать клиентов в случаях загрузки каналов или падения уровня сигнала. Вполне рабочее решение, хоть и не тривиальное. Ну а вообще, я все же сторонник проводов... хотя и понимаю, для массового интереса людей WiFi предпочтительнее по ряду причин. Тоже согласен. Собственно я уже об этом говорил:
А теперь скажите, сколько своего личного времени Вы потратили на разработку, настройку и сопровождение всего этого? И какое у вас образование? И скажите мне, какие основные удобства данная система принесла жильцам вашего дома? Ну там с точки зрения комфорта, экономии и даже понтов? И представьте себе - вот к вам в гости пришел знакомый, и просит показать ваш Умный Дом - а вы ему - смотри, вот у меня так и так. А он такой - Вау, хочу себе такой же. Вы бы свою реализацию порекомендовали ему или нет?
@Adavt, про производительность по чтению-записи в 400-500 мегабайт в секунду для этого NAS вы пропустили? Для заказчика скорость работы с массивом изображений на этой системе выросла в разы Если такой пример вам кажется несколько надуманным для домашней системы, вот вам еще один. Задача передачи видео в 4k разрешении встает почти в любой средней или большой инсталляции. Если телевизоры еще умеют своими силами играть видео, то с проекторами так не получается. Передать 4k видео по HDMI дальше, чем на 10-15 метров получается плохо. Надо использовать активные кабели, кабели с трансиверами на концах и оптоволоконной вставкой, и т. д. А еще часто бывает нужно переключать видео между источниками и приемниками, подмешивать к видеопотоку другую картинку. Это долгое время выполнялось средствами видеопроцессоров и матричных HDMI коммутаторов. Дорогих и капризных. К счастью, это время прошло, и вместо них можно использовать виртуальные матрицы на основе HDMI-IP конвекторов и обычных сетевых коммутаторов. И даже 4k сигнал можно загнать в 1G Ethernet. Но лучше так не делать, потому что и качество картинки "замасливается", и задержки получаются до 0.5 секундны. Про эту проблему давно и хорошо известно, несколько компаний организовали альянс SDVoE (Software Defined Video over Ethernet) и разработали спецификации для оборудования, передающего не сжатое (или почти не сжатое) видео по IP сети с задержкой меньше 1 миллисекунды. И не мало компаний выпускает подобное оборудование. Вот только сеть, по которой идет этот поток, должна быть 10G.
И получается, что на управление 3 ваттной лампочкой ставится устройство с собственным потребление в 1.5 ватта. Типа экономия. Выделенная подсеть - решение хорошее, но теряется основное преимущество - отсутствие дополнительного оборудования. MQTT v3.0 стал популярен в конце 2012 года. Сейчас идёт разработка пятой версии. О чём-либо из этого в новом стандарте нет ни слова. Мне для использования MQTT-SN устройств приходится вот такие описания создавать: Код: "CN13_Ai":{ "default":0, "manifest":{ "MQTT-SN":{ "tag":"Ai7" }, "editor":"Integer" }, "menu":"Analog input internal reference", "rc":"X11,X12", "hint":"Analog input internal reference, CN13" } которые только я и могу использовать. (здесь должна быть очень грустная мордочка)