Комментарии 36
Так. Использование витухи и стандартных розеток — это хорошо. А вот одинаковые розетки подписывать, что «здесь режим такой-то, здесь такой-то»? И, чтобы два раза не вставать: как чисто электрически работает вариант с 8-ю сенсорами без общего провода?
Вариант с 8-ю каналами это экстремальный и редко встречающийся вариант, когда у блока контактов больше 8-и. Тогда приходится прокидывать 2 соединения. В первом и земля и плюс и часть каналов, во втором — одни каналы. Пример — электромодуль Ардуино Мега Сервера (ссылка внизу статьи) с одним каналом напряжения и 13-ю токовыми каналами.
Розетки имеют маркировку. По маркировке можно определить тип подключения или можно посмотреть подробности на схеме по номеру розетки. Или визуально, ведь хаб и подключения видно.
Розетки имеют маркировку. По маркировке можно определить тип подключения или можно посмотреть подробности на схеме по номеру розетки. Или визуально, ведь хаб и подключения видно.
Ну и вообще, что общего у вашего стандарта с Ethernet или чем-либо еще, кроме типа кабеля?
Зачем отличия в типах датчиков? Или вы берете с них «сырой» сигнал?
Зачем отличия в типах датчиков? Или вы берете с них «сырой» сигнал?
Весь стандарт это «нашлёпка» на стандартном езернете. Он используется как транспорт. Мы просто добавляем ещё один уровень абстракции (железный).
Весь сыр-бор из-за экономии пинов. Если бы мы жили в идеальном мире, то на каждый датчик можно было бы выделить отдельный кабель. Но кабель это ценный ресурс и приходится совмещать датчики, например PIR и геркон, отсюда отличия в подключении датчиков — чтобы уместить 2 датчика в один канал.
Весь сыр-бор из-за экономии пинов. Если бы мы жили в идеальном мире, то на каждый датчик можно было бы выделить отдельный кабель. Но кабель это ценный ресурс и приходится совмещать датчики, например PIR и геркон, отсюда отличия в подключении датчиков — чтобы уместить 2 датчика в один канал.
Попробую повторить более конкретно. Вы берете от Ethernet только часть физического уровня, что касается кабеля, а все остальное — свое?
И про датчики. Их сигналы в «сыром» виде (типа замыкания проводов) прямо в таком виде идут до управляющего устройства?
И про датчики. Их сигналы в «сыром» виде (типа замыкания проводов) прямо в таком виде идут до управляющего устройства?
Совершенно верно. Только физический уровень. Есть, правда, экзотические варианты, когда в канале DATA идёт компьютерный сигнал, а в канале POWER — сигналы от датчиков.
Тоже верно прямо в контроллер, но контроллер не простой, там на входе стоит реконфигурируемая (физически) матрица с точностью до одного пина без паяльника. Что позволяет переконфигурировать весь умный дом на физическом уровне за пару часов. О контроллерах будет отдельная статья.
Тоже верно прямо в контроллер, но контроллер не простой, там на входе стоит реконфигурируемая (физически) матрица с точностью до одного пина без паяльника. Что позволяет переконфигурировать весь умный дом на физическом уровне за пару часов. О контроллерах будет отдельная статья.
Такой вопрос — а почему бы не взять какой-нибудь промышленный станадарт за основу и не доработать его для «бытовых» нужд? Есть же, скажем, к примеру, AS-i — две линии и датчиков хоть увешайся:
Тут пока речь идет о попытке структурировать и унифицировать кабельное хозяйство. Стандартов обмена информацией не завезли — насколько я понимаю, каждому сигналу с датчика в итоге своя жилка кабеля.
А разве AS-интерфейс не принадлежит с потрохами компании Сименс? Что то я сомневаюсь, что это так просто будет сделать.
Да, это так, но я и не предлагаю использовать его один-в-один. Протокол обмена, спецификации могут быть другие. Но мне очень нравится идея вешать датчики и исполнительные механизмы на одну линию, которую можно наращивать. А в вашем предложении каждое устройство висит на своей выделенной линии (если я правильно понял). В промышленности, скажем, если есть длинный конвейер, вдоль которого протянута такая шина, иначе в шкаф придется тянуть лапшу кабелей. То же и с домашней автоматизацией — протянуть по периметру помещения один кабель все ж таки проще, чем отдельный к каждому потребителю.
Я знаю что такое AS-интерфейс. Если мне память не изменяет, то Ethernet это тоже шина. Свичи позволяют осуществлять коммутированный доступ к узлам сети. Если вы не помните, но раньше были устройства которые назывались не свитч, а хаб. Отличие было в том, что они были просто ретрансляторами телеграмму отправленную с одного узла слышала вся сеть. В соответствии с этим никто не мешает в домашней сети умных устройств использовать некоммутированный доступ. Скорости 10 Мбит для такой сети будет более чем достаточно(даже избыточно). По принципу один передает все слушают. Скорее всего на конце такой сети по примеру других промышленных сетей придется вешать концевой резистор и длина одного сегмента такой сети будет естественно не более 100 м. Мои познания в электронике более чем скромные, однако я думаю такая схема вполне себе работоспособна. И мы сможем к каждому такому устройству обращаться по отдельному IP адресу. И при этом использовать вполне себе стандартное оборудование.
Тут идея такая: всё равно при строительстве или капремонте современного дома желательно установить СКС, уж больно много у неё достоинств и удобств. Почему бы просто не добавить копеечных хабов и не использовать все её достоинства для умного дома?
Мне лично очень нравится отключать и подключать контроллеры, как обычные роутеры патч-кордами, очень удобно. Или понадобилось пробросить сигнал датчика из одной комнаты в любую другую — нет проблем — воткнул тот же патч-корд и сигнал побежал туда, куда надо. Один раз ощутив удобство о других методах даже думать не хочется.
Ещё один момент: это решение универсальное и подходит не только для СКС, но идля отдельных поделок, собираемых на столе — к ним датчики тоже удобно подключать через стандартные кабели и разъёмы. Пример такого подхода — роботы Лего, там что-то вроде телефонных разъёмов.
Что касается других стандартов, то я только за. Если вы предложите что-то, то будет здорово.
Мне лично очень нравится отключать и подключать контроллеры, как обычные роутеры патч-кордами, очень удобно. Или понадобилось пробросить сигнал датчика из одной комнаты в любую другую — нет проблем — воткнул тот же патч-корд и сигнал побежал туда, куда надо. Один раз ощутив удобство о других методах даже думать не хочется.
Ещё один момент: это решение универсальное и подходит не только для СКС, но идля отдельных поделок, собираемых на столе — к ним датчики тоже удобно подключать через стандартные кабели и разъёмы. Пример такого подхода — роботы Лего, там что-то вроде телефонных разъёмов.
Что касается других стандартов, то я только за. Если вы предложите что-то, то будет здорово.
Не надо будить динозавров… :)
Количество датчиков ограничено 63 на ветку. И миллион других причин.
Количество датчиков ограничено 63 на ветку. И миллион других причин.
Смотрите. Мое мнение такое. Путь вы выбрали вроде как правильный. Хотя по моему мнению нужно было обеспечить полную совместимость со стандартами PoE. (IEEE 802.3af-2003). Это бы дало возможность коммутировать ваше оборудование посредством стандартных PoE свитчей. Плюс ко всему напряжение в 48 вольт позволило бы питать большее количество датчиков от одного устройства. В качестве контроллера можно было бы выбрать какой нибудь софт-контроллер для линукс или написать свой для распберри например. А еще лучше взять за основу какой нибудь из существующих серийных NAS за основу для управляющей системы. Сделать или свою прошивку или свое приложение. Чтоб пользователь Вашей системы не думал где взять коммутатор или где найти замену вышедшему из строя контроллеру. А самим сосредоточится на конечных устройствах. Датчиках, сенсорах, разработать серию красивых стеклянных выключателей и пр.
Обеспечить полную совместимость с POE невозможно в принципе потому, что сигналы от датчиков могут иметь потенциалы и ток, которые не понравятся стандартному компьютерному оборудованию. А если мы используем только железный уровень — у нас развязаны руки — гони что хочешь, только чтобы провода не поплавились (500 мА на жилу, кажется).
У меня реально работает очень экзотический вариант: по одному кабелю сеть 1-Wire обходит несколько комнат в канале DATA и возвращается обратно по тому же кабелю в канале POWER.
Это вещь очень универсальная, никто не мешает вам гнать 48 вольт в канале POWER. Единственный недостаток — нельзя ошибаться в подключениях, но это (естественная) плата за универсальность и потрясающие возможности.
Про софтверные решения не понял. Мы работаем только на железном уроне.
У меня реально работает очень экзотический вариант: по одному кабелю сеть 1-Wire обходит несколько комнат в канале DATA и возвращается обратно по тому же кабелю в канале POWER.
Это вещь очень универсальная, никто не мешает вам гнать 48 вольт в канале POWER. Единственный недостаток — нельзя ошибаться в подключениях, но это (естественная) плата за универсальность и потрясающие возможности.
Про софтверные решения не понял. Мы работаем только на железном уроне.
А почему нет? Вам только нужно сделать универсальные преобразователи датчик — Ethernet и сделать их компактными для возможности размещения в стандартный (и) или углубленный подрозетник. Для компактности можно пожертвовать разъемами, подключение осуществлять к компактным клеммам. Про софтверные решения. Смотрите. Железный контроллер не универсален. Если вы разрабатываете свой, то с одной стороны Вы получаете совместимую на 100% с Вашим оборудованием железку, но Вам необходимо будет потратить огромное количество сил, чтобы сделать эту железку сделать совместимой с множеством других более популярных интерфейсов. Иначе Ваш система нежизнеспособна в коммерческом плане. Если Вы берете сторонний контроллер и делаете для него скажем библиотеку для своих устройств или описываете методы работы с Вашими устройствами, то тут Вы попадаете в зависимость от сторонних производителей. Контроллер сняли с производства и Вам придется еще раз проходить этот путь по описанию методов или написанию библиотек. Я предложил взять за основу так называемый софт-контроллер. Желательно платформенно независимый. Что то типа контроллера под среду разработки CoDeSys, который может работать в принципе на стандартном компе под стандартной виндой. Я сейчас не вспомню название, но точно есть аналоги этого ПО на Open Source. Взять такой и адаптировать под Ваше оборудование.
Универсальность — недешевая штука. Например, датчик DHT22 имеет собственный протокол. Поэтому, либо остаемся на уровне железа ради универсальности, либо отказываемся от поддежки всего зоопарка протоколов ради абстрагирования, но тогда для спецефичных датчиков надо добавлять собственные контроллеры, при чем для каждого такого разнесенного датчика.
А зачем плодить зоопарк протоколов, если можно сделать универсальный преобразователь для аналоговых датчиков, видов которых в промышленности не так уж и много. Температура самые распространенные PT100, PT1000, NI100,NI1000, NTC термисторы с разными характеристиками. Датчики давления как правило дают уже нормированный сигнал 4-20мА. И гора всяких уже более сложных устройств(ветер, влага, атмосферное давление), которые как правило или дают нормированный сигнал по напряжению или току или дискретные импульсные сигналы. Адруинные дела я не рассматриваю в принципе. Это отдельный мир. Складывается впечатление, что оно все росло без оглядки на промышленные разработки и стандарты.
Идея сделать универсальный преобразователи датчик — Ethernet очень крутая, мне такое даже в голову не приходило (видимо из-за недостатка квалификации, не мой уровень). Если кто-то такое сделает, да ещё компактное это будет очень здорово.
Вообще тут идея попроще, вернее две идеи:
1-я: задействовать все преимущества СКС для проводки умного дома
2-я: Сделать стандартную железную обёртку (схема + разъёмы) для ЛЮБЫХ датчиков. И стандартизировать обслуживающий их код так, чтобы вы позвонили в интернет-магазин и сказали: «мне нужен OHAS PIR-датчик тип А», вам его доставили, вы его прищёлкнули и в коде добавили одну-две строчки логики (обслуживающий стандартный код уже есть). Пока всё это касается Ардуино, но никто не мешает добавить обслуживающий код на любую платформу).
Вообще тут идея попроще, вернее две идеи:
1-я: задействовать все преимущества СКС для проводки умного дома
2-я: Сделать стандартную железную обёртку (схема + разъёмы) для ЛЮБЫХ датчиков. И стандартизировать обслуживающий их код так, чтобы вы позвонили в интернет-магазин и сказали: «мне нужен OHAS PIR-датчик тип А», вам его доставили, вы его прищёлкнули и в коде добавили одну-две строчки логики (обслуживающий стандартный код уже есть). Пока всё это касается Ардуино, но никто не мешает добавить обслуживающий код на любую платформу).
По второму пункту. Стандартная система — это любое решение промышленной автоматизации. С головным устройством (ПЛК или ПК+SCADA) и модулями ввода-вывода (к которым уже подключаются датчики и исполнительные устройства). Объединяется все посредством Ethernet или RS-485. На следующем уровне — какой-нибудь протокол, например MODBUS-RTU в случае RS-485.
Когда я начинал думать о домашней автоматизации, то рассматривал именно такой вариант. Но пока отложил его, решив для разминки спроектировать что-нибудь более «узкое». Начал с управления освещением, вот раз и два.
Если вкратце — каждое устройство это бутерброд из процессорной и функциональной плат. Процессорная содержит Atmega8, адаптер RS-485 и стабилизатор питания. Себестоимость производства процессорной платы — менее 5$. При этом объединяются эти устройства нормальной сетью RS-485 (шина), протокол общения свой (простейший), но можно и MODBUS-RTU запилить.
К каждому устройству будет прокинута обычная витая пара (8 жил). 2 жилы — «вход» RS-485, 2 — выход, 2 — питание, 2 — резерв.
Первоначально, конечно, хотел Ethernet и PoE. Но получается в разы дороже.
Когда я начинал думать о домашней автоматизации, то рассматривал именно такой вариант. Но пока отложил его, решив для разминки спроектировать что-нибудь более «узкое». Начал с управления освещением, вот раз и два.
Если вкратце — каждое устройство это бутерброд из процессорной и функциональной плат. Процессорная содержит Atmega8, адаптер RS-485 и стабилизатор питания. Себестоимость производства процессорной платы — менее 5$. При этом объединяются эти устройства нормальной сетью RS-485 (шина), протокол общения свой (простейший), но можно и MODBUS-RTU запилить.
К каждому устройству будет прокинута обычная витая пара (8 жил). 2 жилы — «вход» RS-485, 2 — выход, 2 — питание, 2 — резерв.
Первоначально, конечно, хотел Ethernet и PoE. Но получается в разы дороже.
Мне вот интересно — и в «Искусстве схемотехники», и вот еще в этой статье говорится про проблему отражений в длинных кабелях с несогласованными сопротивлениями, причем дело не в частоте сигнала, а в скорости нарастания фронтов. При этом эффект можно наблюдать даже при длине кабеля в полметра. Вы как-то этот момент учитываете?
Дело в том, что я ни с какими проблемами во время разработки и эксплуатации стандарта не сталкивался. Поэтому учитывать указанную проблему (как и бесконечное множество других возможных проблем) мне в голову не пришло.
Этот стандарт не догма, а приглашение к обсуждению и сотрудничеству и любой желающий и вы в том числе, можете внести посильный вклад, например замерить отражение и доложить нам о результатах.
Этот стандарт не догма, а приглашение к обсуждению и сотрудничеству и любой желающий и вы в том числе, можете внести посильный вклад, например замерить отражение и доложить нам о результатах.
Я думаю, что измерять ничего не надо — они уже сделаны и представлены в книге и указанной статье. Это то же самое, что измерять гравитацию — вдруг она у меня другая. У вас хороший проект, я с восхищением слежу за циклом ваших статей, но вот такие очевидные схемотехнические проблемы надо решать. Может быть даже вместе с задачей защиты входов.
Немного странная ситуация: у меня 3 года работает звезда с лучами по 50 — 80 метров не то что без сбоев, но даже без намёков на сбои. И тут я неожиданно узнаю, что у меня есть проблемы.
Очевидно, что если есть какие-либо искажения сигнала, то они несущественны для данного применения. Я не вижу смысла решать проблему которой нет, мне вполне достаточно проблем, которые есть.
Очевидно, что если есть какие-либо искажения сигнала, то они несущественны для данного применения. Я не вижу смысла решать проблему которой нет, мне вполне достаточно проблем, которые есть.
Однажды что-то не будет работать, вот у вас будет одна из гипотез. Например, сигнал с камеры.
Подождите секундочку, OHAS это «нашлёпка» на стандартной СКС проводке. Если речь идёт о передаче сигнала с камеры, то мы можем вообще не рассматривать OHAS, а использовать витую пару как проводку СКС категории 5е. Насколько я понимаю, передать сигнал с камеры по стандартной проводке СКС — не проблема.
Если я правильно понял, то в вашей системе по одну сторону длинного провода — выход с сенсора, по другую — пин контроллера? Или сенсор передает сигнал в провод через драйвер провода, а контроллер получает сигнал через специальный приемник между пином и проводом?
Не совсем. В этой системе стандартная СКС проводка получает ещё один уровень абстракции (железный), а что и как там будет подключено решаете вы сами. Датчики и контроллеры это частный случай.
Здесь речь может идти о влиянии переходников на характеристики тракта, но в случае датчиков мы транспортируем практически постоянный ток и переход из 0 в 1 по фронту совершенно некритичен к этим характеристикам.
А вот как влияют лишние переходники на передачу высокочастотных сигналов это тема отдельной диссертации. Но практика показывает, что стандартная сеть 1 Гб/с транспортируется без каких-либо пролем.
Здесь речь может идти о влиянии переходников на характеристики тракта, но в случае датчиков мы транспортируем практически постоянный ток и переход из 0 в 1 по фронту совершенно некритичен к этим характеристикам.
А вот как влияют лишние переходники на передачу высокочастотных сигналов это тема отдельной диссертации. Но практика показывает, что стандартная сеть 1 Гб/с транспортируется без каких-либо пролем.
Я имею ввиду конкретно вашу реализацию умного дома — у вас сенсоры подключаются к пинам контроллера напрямую через длинный провод?
Высокочастотный сигнал 1 Гб/с транспортируется без каких-либо проблем, если согласовать импеданс приемника/передатчика с волновым сопротивлением кабеля, иначе никак. Но вообще тут и говорить нечего — на входе или выходе кабеля ставится резистор и готово.
Высокочастотный сигнал 1 Гб/с транспортируется без каких-либо проблем, если согласовать импеданс приемника/передатчика с волновым сопротивлением кабеля, иначе никак. Но вообще тут и говорить нечего — на входе или выходе кабеля ставится резистор и готово.
Не имею ничего против резистора: если он нужен для согласования — обязательно поставим. Я для этого и опубликовал стандарт, чтобы квалифицированные люди высказали свои предложения. Осталось только услышать ваши пояснения и методику по выбору номинала резистора.
Я погуглил и обнаружил, что в случае с витой парой, где каждый провод несет отдельный сигнал, не все так просто. Я сделаю работу и поищу материал. Пока что нашел вот это: http://www.eetimes.com/document.asp?doc_id=1277940
Про сам механизм отражений с реальными измерениями можно прочитать в «Искусстве схемотехники» — недавно вышло третье издание, а второе можно найти в электронном виде на любом языке.
Про сам механизм отражений с реальными измерениями можно прочитать в «Искусстве схемотехники» — недавно вышло третье издание, а второе можно найти в электронном виде на любом языке.
Я почитал материал про передачу данных по длинным проводам, витые пары, отражения и физический уровень Ethernet. Получается следующее:
- Для быстрой передачи данных сигнал придется передавать в дифференциальном виде, задействуя два провода на канал
- При этом каждую задействованную пару придется терминировать резистором для подавления отражений (для cat5 — 100 Ом)
- Если по отдельным проводам витой пары передавать произвольные сигналы относительно передаваемой отдельным проводом земли, то сигналы начнут мешать друг другу. Кроме того, в линии начнутся отражения, поскольку терминировать их станет невозможно. По таким каналам можно передавать только очень медленные сигналы
Понятно. Остаётся только один вопрос: что значит «медленные» сигналы? Судя по всему потребности автоматизации на порядки ниже, чем позволяет транспортировать OHAS. А для того, чтобы сказать конкретно, насколько ниже, нужно проводить лабораторные испытания. Пока стандарт неофициальный, я думаю, достаточно эмпирического опыта «всё работает, как часы».
Насколько медленные сигналы я вам сказать не смогу, это надо проводить испытание. Значение имеет не только частота передачи сигнала, но и скорость нарастания фронтов. Но если вам надо будет передать быстрый сигнал, то вы можете передавать его по одной из пар, вставив 100 Ом между проводами на приемном или передающем конце.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Open Home Automation Standard (OHAS)