Комментарии 37
Поставил плюс за подход ;)
Даже дешевле чем на всяких «новомодных» ZigBee, при условии, что с питанием проблем нет.
А с питанием и нет — припаиваете его же БП и все работает — почти безотходное производство)
Проблема только с упихиванием этого в исходный корпус, но этим можно не страдать, а взять имеющийся под рукой корпус побольше, и все.
У вайфая есть ряд преимуществ перед кастомными радиомодулями, включая и зигби — как минимум вам не нужно будет устройство-мост, которое свяжет эту самую зигби сеть с вашей домашней.
А еще можно навесить камеру и стримить видео — это займет не намного больше времени чем конфигурирование CGI. А вот если вы захотите стримить видео по кастомному радиомодулю, то, боюсь, результаты будут далеко не скоро и далеко не такие как хотелось бы…
Проблема только с упихиванием этого в исходный корпус, но этим можно не страдать, а взять имеющийся под рукой корпус побольше, и все.
У вайфая есть ряд преимуществ перед кастомными радиомодулями, включая и зигби — как минимум вам не нужно будет устройство-мост, которое свяжет эту самую зигби сеть с вашей домашней.
А еще можно навесить камеру и стримить видео — это займет не намного больше времени чем конфигурирование CGI. А вот если вы захотите стримить видео по кастомному радиомодулю, то, боюсь, результаты будут далеко не скоро и далеко не такие как хотелось бы…
А сколько вообще свободных GPIO у этого девайса? одна релюшка — это конечно, лучше чем ничего, но все-таки ради одной покупать целый рутер сомнительная идея :)
Кстати, я таки пожалел денег на эксперименты и купил TL-WR703N — китайский брат этого рутера. OpenWRT прошил, после плясок с бубнами (сначала сдуру поставил DDWRT, с него фиг прошьешь так просто OpenWRT).
Но подружить его с 3G модемом не удалось, сделать из него мост -Ethernet — WiFi тоже не удалось (WiFi приставка для Raspberry например). К сети коннектится, адреса раздает, а вот бриджить что-то не хочет.
Кстати, я таки пожалел денег на эксперименты и купил TL-WR703N — китайский брат этого рутера. OpenWRT прошил, после плясок с бубнами (сначала сдуру поставил DDWRT, с него фиг прошьешь так просто OpenWRT).
Но подружить его с 3G модемом не удалось, сделать из него мост -Ethernet — WiFi тоже не удалось (WiFi приставка для Raspberry например). К сети коннектится, адреса раздает, а вот бриджить что-то не хочет.
4 GPIO на светодиоды, два неиспользуемые и подтянуты к земле, один — на кнопке, два — на трехпозиционном переключателе.
А в чем проблема имея USB и UART сделать себе столько GPIO, сколько нужно?) Ну а если уж совсем не хочется ничего делать — двух гпио достаточно для подключения сдвигового регистра, и, опять таки, получения нужного количество выходов.
А в чем проблема имея USB и UART сделать себе столько GPIO, сколько нужно?) Ну а если уж совсем не хочется ничего делать — двух гпио достаточно для подключения сдвигового регистра, и, опять таки, получения нужного количество выходов.
проблема с USB наверное в том, что я понятия не имею что с ним делать :)
А UART использовать для подключения МК разве что :)
А UART использовать для подключения МК разве что :)
Ну как минимум вы можете в USB воткнуть микросхему от FTDI, которая преобразует USB в ногодрыгание своими GPIO)
Причем, драйвер для этой штуки, насколько я помню, в ядре присутствует. Так часто поступают, когда не хотят разрабатывать свои USB-девайсы. В итоге у вас, по сути, будет набор весьма быстрых, управляемых из любого удобного языка программирования, GPIO. Работа с котороми будет сводится к посылке буферов данных и их приема от микросхемы.
С уартом при желании можно проделать то же самое, реализовав нечто похожее на любом контроллере.
Причем, драйвер для этой штуки, насколько я помню, в ядре присутствует. Так часто поступают, когда не хотят разрабатывать свои USB-девайсы. В итоге у вас, по сути, будет набор весьма быстрых, управляемых из любого удобного языка программирования, GPIO. Работа с котороми будет сводится к посылке буферов данных и их приема от микросхемы.
С уартом при желании можно проделать то же самое, реализовав нечто похожее на любом контроллере.
Я почти так и сделал: у меня был другой роутер, тоже китайский… вот что из него вышло.
Сейчас, кстати, наконец пригодился — стоит на работе как таймер и управляет подсветкой растений.
Сейчас, кстати, наконец пригодился — стоит на работе как таймер и управляет подсветкой растений.
Ну, наверное, можно, но мне как-то bitbang всегда казался извратом как и использование недокументированных хаков в винде — закроют их в следующей версии все. а тут как-то никогда не знаешь, будет оно работать или огребешь проблем. Мне вариант с AVR по I2C видится более правиьным. Надо только добраться до I2C на Raspberry
А AVR чем занимается, не бит-бангом? Все цифровые микросхемы им и занимаются.
Странные у вас предрассудки, I2C тоже битбанг — деграете пинами в соответствии со стандартом.
Как можно не знать «будет оно работать или нет», если FTDI для этого проектировалась? Хотите — делайте на ней I2C, хотите — SPI, хотите — интерфейс для дисплея реализуйте.
Странные у вас предрассудки, I2C тоже битбанг — деграете пинами в соответствии со стандартом.
Как можно не знать «будет оно работать или нет», если FTDI для этого проектировалась? Хотите — делайте на ней I2C, хотите — SPI, хотите — интерфейс для дисплея реализуйте.
В принципе, да, только «легально» :) Удобство в том, что тайминги на AVR соблюдать проще, реализуя любой интерфейс, а то и вообще не надо возиться — поддержка есть аппаратная. Вручную из под линукс у меня точно не хватит знаний реализовать эти шины. Или у вас есть готовый код?
В теории оно все красиво, а на практике замучаешься сделать что-то сложнее елочной гирлянды из 3х светодиодов :)
В теории оно все красиво, а на практике замучаешься сделать что-то сложнее елочной гирлянды из 3х светодиодов :)
Нет, вы не так поняли) на ГПИО самого линухового чипа в самом деле могут возникнуть проблемы при реализации быстрых шин, так как линукс не ОСРВ. Правда если вам нужно реле переключать через сдвиговый регистр, проблем не будет.
А чип фтди работает по другому принципу — у него собственный тактовый генератор, вы кидаете ему буфер данных, он выдвигает их на свои ГПИО, поэтому не будет проблем с таймингами.
Кода у меня нет, найти, думаю, не проблема — а на крайний случай — написать. На том же питоне.
А чип фтди работает по другому принципу — у него собственный тактовый генератор, вы кидаете ему буфер данных, он выдвигает их на свои ГПИО, поэтому не будет проблем с таймингами.
Кода у меня нет, найти, думаю, не проблема — а на крайний случай — написать. На том же питоне.
Да все я правильно понял, просто выдавать тому же FTDI команды и данные нужно с правильными интервалами, если шину реализуем относительно быструю. В общем, я в свое время наигрался с реализацией шин. Бывает просто, бывает не очень.
А питон — в лес :) не люблю интерпретируемые языки как класс, а уж в связке с железом реального мира — тем более. Все там через одно место. Для обучения детей годится, написать моргалку светодиодом годится. Но это неинтересно, а как чуть сложнее — логику на нем писать уже муторно.
А питон — в лес :) не люблю интерпретируемые языки как класс, а уж в связке с железом реального мира — тем более. Все там через одно место. Для обучения детей годится, написать моргалку светодиодом годится. Но это неинтересно, а как чуть сложнее — логику на нем писать уже муторно.
Вы не правы.
Питон тут объективно правильнее использовать, чем тот же C, как бы я его не не любил. Он уровнем выше чем С, скорость разработки выше на порядки, база кода огромна, переносимость великолепна.
На С пишут самые низкоуровневые блоки, как раз таки только самое нижнее общение с железом, всю логику выносят на него. Вы будете месяцами писать на С то, что на питоне реализуется и деплоится за неделю на железке.
Это реалии современного мира — я тоже не любил подобные языки, но приходится принимать современные подходы, чтобы не стать неэффективным.
Питон тут объективно правильнее использовать, чем тот же C, как бы я его не не любил. Он уровнем выше чем С, скорость разработки выше на порядки, база кода огромна, переносимость великолепна.
На С пишут самые низкоуровневые блоки, как раз таки только самое нижнее общение с железом, всю логику выносят на него. Вы будете месяцами писать на С то, что на питоне реализуется и деплоится за неделю на железке.
Это реалии современного мира — я тоже не любил подобные языки, но приходится принимать современные подходы, чтобы не стать неэффективным.
Не знаю, может оно и так, но написать что-то целиком на питоне на мой взгляд сложнее, чем целиком на С/С++. А зачем использовать два языка и еще мучаться с их стыковкой если можно один? Я, к счастью, не должен быть эффективным — мне достаточно чтобы это было просто и удобно для меня. А изучать десяток новых языков мне неудобно, потому что время затраченное на изучение питона я могу потратить на написание программы на С.
Я бы вообще предпочел DOS или Windows на Raspberry :) потому что тогда я мог бы писать там на том, что я знаю еще гораздо лучше — Pascal или вообще Delphi. Каждый новый язык — это в первый раз в первый класс — а как тут делается эта привычная вещь? а потом ловля детских ошибок. Если конечно вы не пишете код из 100-200 строк всего.
А что-то интересное имеет свойство разрастаться. Поморгать лампочками и правда можно на питоне. А обрабатывать данные с сенсоров: акселерометры, гиро, магнетометр, GPS. А при этом параллельно работать с сетью? Желательно не превращать при этом Raspberry в однозаданый контроллер, нагрузив его интерпретацией так, что он захлебнется. Работать с сетью, файлами? Я еще не подступался к этому на С под Linux, но точно знаю что кода море и я быстро разберусь, как только руки дойдут. А на питоне это удобно?
А OpenCV я смогу из него подцепить, когда дело до него дойдет? На С++ под Windows простое приложение с OpenCV заработало за 1 вечер, даже меньше.
Я бы вообще предпочел DOS или Windows на Raspberry :) потому что тогда я мог бы писать там на том, что я знаю еще гораздо лучше — Pascal или вообще Delphi. Каждый новый язык — это в первый раз в первый класс — а как тут делается эта привычная вещь? а потом ловля детских ошибок. Если конечно вы не пишете код из 100-200 строк всего.
А что-то интересное имеет свойство разрастаться. Поморгать лампочками и правда можно на питоне. А обрабатывать данные с сенсоров: акселерометры, гиро, магнетометр, GPS. А при этом параллельно работать с сетью? Желательно не превращать при этом Raspberry в однозаданый контроллер, нагрузив его интерпретацией так, что он захлебнется. Работать с сетью, файлами? Я еще не подступался к этому на С под Linux, но точно знаю что кода море и я быстро разберусь, как только руки дойдут. А на питоне это удобно?
А OpenCV я смогу из него подцепить, когда дело до него дойдет? На С++ под Windows простое приложение с OpenCV заработало за 1 вечер, даже меньше.
Два языка используют, чтобы максимально удобно и эффективно решить поставленную задачу. «Со стыковкой» никто не мучается. Вы затратите на порядок больше времени, пытаясь реализовать то же самое на каком-то одном языке, при этом выходной код получится куда менее поддерживаемым и куда более подверженным ошибкам.
>А обрабатывать данные с сенсоров: акселерометры, гиро, магнетометр, GPS. А при этом параллельно работать с сетью?
Я, к сожалению, связан NDA и не могу раскрывать подробности проектов с работы, но именно это мы и делали.
Вы на С, прошу прощения, затрахаетесь с этой параллельностью как раз. И быстро сделать не получится. На питоне это удобнее на порядки. У нас там крутилось здоровенное мультитред приложение, которое и информацию с датчиков собирало, и в бд параллельно писало, и с сетью работало. И это все на хилом 400 МГц процессоре.
И OpenCV и OpenCL — без проблем подключаются, можете нагуглить примеры.
Причем, мы писали код, параллельно деплоя его на ноутбуке (х86) и на аналогичной роутеру платформе (mips). Не меняя ни символа. Ну вот так задача стояла, получить результат и на ноуте и на эмбеддед платформе.
На С++ прикладной софт писать вообще не стоит уже, если уж встает вопрос о написании прикладного софта на PC, лучше обратиться к яве или шарпу, потому что на них, опять таки, выше скорость разработки, выше читабельность и поддерживаемость кода.
«Мне не надо быть эффективным» — это плохая отговорка, с ней вы так и будете на уровне «поморгать лампочкой», охотиться при помощи дубины, когда все вокруг уже перейдут на ружья. К тому же странно слышать какие-то выводы, если вы «не подступали» ни к С на Linux ни к питону.
>А обрабатывать данные с сенсоров: акселерометры, гиро, магнетометр, GPS. А при этом параллельно работать с сетью?
Я, к сожалению, связан NDA и не могу раскрывать подробности проектов с работы, но именно это мы и делали.
Вы на С, прошу прощения, затрахаетесь с этой параллельностью как раз. И быстро сделать не получится. На питоне это удобнее на порядки. У нас там крутилось здоровенное мультитред приложение, которое и информацию с датчиков собирало, и в бд параллельно писало, и с сетью работало. И это все на хилом 400 МГц процессоре.
И OpenCV и OpenCL — без проблем подключаются, можете нагуглить примеры.
Причем, мы писали код, параллельно деплоя его на ноутбуке (х86) и на аналогичной роутеру платформе (mips). Не меняя ни символа. Ну вот так задача стояла, получить результат и на ноуте и на эмбеддед платформе.
На С++ прикладной софт писать вообще не стоит уже, если уж встает вопрос о написании прикладного софта на PC, лучше обратиться к яве или шарпу, потому что на них, опять таки, выше скорость разработки, выше читабельность и поддерживаемость кода.
«Мне не надо быть эффективным» — это плохая отговорка, с ней вы так и будете на уровне «поморгать лампочкой», охотиться при помощи дубины, когда все вокруг уже перейдут на ружья. К тому же странно слышать какие-то выводы, если вы «не подступали» ни к С на Linux ни к питону.
Под Linux невелик опыт это факт. На С под Linux немного писал. Но совсем немного. Даже книги приличной не нашел, которая бы разложила по полочкам все быстро и дальше можно было с пониманием что к чему программить в этой ОС. В основном, все сосредточены на работе с GUI, а меня она под Linux не интересует вообще.
К сожалению, разработка для меня лишь хобби, ни копейки я этим уже давно не зарабатываю. Поэтому я стараюсь как можно меньше распыляться между различными платформами и языками. По опыту — чем лучше я знаю какой-то инструмент, тем быстрее и эффективнее я что-то могу им сделать, а для того, чтобы эффективно изучить несколько, нужно иметь много времени. У меня не одно хобби и выделить годы на изучение прежде чем приступить к реализации идеи, у меня нет возможности. Но и ограничивать свои возможности используя только Питон (для некоторых вещей все равно придется использовать С, а значит его тоже надо знать хорошо) не хочется. Это примерно как Arduino — Wiring простая надстройка над С++, но ужасно неэффективная и никогда не понимаешь что и как там работает, а когда хочешь использовать все возможности МК, выясняется, что там многие вещи конфликтуют друг с другом, и приходится переписывать все равно все самому.
А когда взял и немного разобрался с С для AVR, то стало куда проще дергать нужные библиотеки в качестве примеров кода, чуть-чуть адаптируя под себя. Работает быстрее, компактно и не приходится бороться с кучей глюков того монстра, который создали разработчки пытаясь уберечь чайников от изучения внутренностей МК.
К сожалению, разработка для меня лишь хобби, ни копейки я этим уже давно не зарабатываю. Поэтому я стараюсь как можно меньше распыляться между различными платформами и языками. По опыту — чем лучше я знаю какой-то инструмент, тем быстрее и эффективнее я что-то могу им сделать, а для того, чтобы эффективно изучить несколько, нужно иметь много времени. У меня не одно хобби и выделить годы на изучение прежде чем приступить к реализации идеи, у меня нет возможности. Но и ограничивать свои возможности используя только Питон (для некоторых вещей все равно придется использовать С, а значит его тоже надо знать хорошо) не хочется. Это примерно как Arduino — Wiring простая надстройка над С++, но ужасно неэффективная и никогда не понимаешь что и как там работает, а когда хочешь использовать все возможности МК, выясняется, что там многие вещи конфликтуют друг с другом, и приходится переписывать все равно все самому.
А когда взял и немного разобрался с С для AVR, то стало куда проще дергать нужные библиотеки в качестве примеров кода, чуть-чуть адаптируя под себя. Работает быстрее, компактно и не приходится бороться с кучей глюков того монстра, который создали разработчки пытаясь уберечь чайников от изучения внутренностей МК.
Вы хотите досконально изучить молоток, игнорируя пилу и топор.
Рано или поздно влетите в ситуацию, когда бить молотком бревно, в надежде что оно расколется, станет куда дольше, чем взять и попробовать топор.
Я понимаю, что есть разница между профессиональным подходом и хобби — но в то же время — хобби это же то, что вам интересно. Разве вам не интересно расширить свои горизонты?
Вы вот добавили в свой арсенал новый инструмент после AVR — системы совсем другого класса, достаточно мощные эмбеддед платформы с полноценной ОС. К ним в комплекте идут новые подходы и новые средства, пытаясь работать с новой платформой старыми методами и отбрасывая сразу новые вы очень сильно теряете и скорость разработки и качество итогового продукта.
Вы представляете, сколько времени у вас займет реализация стриминга видео и веб-сервера на каком-нибудь небольшом DSP? Даже при условии, что он его потянет?
Пока вы месяцами будете писать драйверы для камеры и кодек, студент первокурсник запустит стриминг на какой-нибудь похожей плате с линуксом за день.
Да, сама платформа будет несколько дороже — но это полностью компенсируется ценой разработки. Так и с языками программирования, нужно оценивать возможности, а не упираться в один.
Кстати, насчет платформы — сейчас это все так дешевеет, что не факт, что и дороже — та же карамбола стоит 22 евро, сравнимо со всякими отладочными для жопастых контроллеров. А MiniX стоит $70, при этом там гигагерцовый процессор и гигабайт памяти, при размерах 60х60 мм и потреблении в 1-2 ватта — что означает, что вы можете на порядок эффективнее разрабатвать свои продукты используя более удобные инструменты…
Рано или поздно влетите в ситуацию, когда бить молотком бревно, в надежде что оно расколется, станет куда дольше, чем взять и попробовать топор.
Я понимаю, что есть разница между профессиональным подходом и хобби — но в то же время — хобби это же то, что вам интересно. Разве вам не интересно расширить свои горизонты?
Вы вот добавили в свой арсенал новый инструмент после AVR — системы совсем другого класса, достаточно мощные эмбеддед платформы с полноценной ОС. К ним в комплекте идут новые подходы и новые средства, пытаясь работать с новой платформой старыми методами и отбрасывая сразу новые вы очень сильно теряете и скорость разработки и качество итогового продукта.
Вы представляете, сколько времени у вас займет реализация стриминга видео и веб-сервера на каком-нибудь небольшом DSP? Даже при условии, что он его потянет?
Пока вы месяцами будете писать драйверы для камеры и кодек, студент первокурсник запустит стриминг на какой-нибудь похожей плате с линуксом за день.
Да, сама платформа будет несколько дороже — но это полностью компенсируется ценой разработки. Так и с языками программирования, нужно оценивать возможности, а не упираться в один.
Кстати, насчет платформы — сейчас это все так дешевеет, что не факт, что и дороже — та же карамбола стоит 22 евро, сравнимо со всякими отладочными для жопастых контроллеров. А MiniX стоит $70, при этом там гигагерцовый процессор и гигабайт памяти, при размерах 60х60 мм и потреблении в 1-2 ватта — что означает, что вы можете на порядок эффективнее разрабатвать свои продукты используя более удобные инструменты…
Расширить горизонты в плане новых языков — нет, неинтересно. Полиглотом я был в свое время, понял, что это неэффективно. Да, увлекательно изучать новое. но мне гораздо больше нравится работать собственно над интересной частью, а не над изучением платформы. Восторг от новых железок прошел несколько лет назад, теперь мне интересно делать те штуки, которые я придумал, а не реализовывать очередной велосипед. Учиться ездить на велосипеде марки питон довольно скучно, благо под Linux мне пока все равно что изучать, лишь бы эффективнее было, попробую, может и пойдет.
стриминг видео на Raspberry у меня занял 3 часа вечером вчера — пока нашел способ поставить ffserver и он компилировался 2.5 часа. А с утра за полчаса mjpeg-streamer заработал так как надо.
Но это тупая железка никакой логики она не реализует. Если разберусь с OpenCV может удастся что-то поинтереснее сделать. Но там уже стриминг не нужен, достаточно обрабатывать видео локально.
DSP изучать не вижу надобности, для моих задач оно не нужно вообще. низкоуровненые кодеки я точно разрабатывать не буду.
стриминг видео на Raspberry у меня занял 3 часа вечером вчера — пока нашел способ поставить ffserver и он компилировался 2.5 часа. А с утра за полчаса mjpeg-streamer заработал так как надо.
Но это тупая железка никакой логики она не реализует. Если разберусь с OpenCV может удастся что-то поинтереснее сделать. Но там уже стриминг не нужен, достаточно обрабатывать видео локально.
DSP изучать не вижу надобности, для моих задач оно не нужно вообще. низкоуровненые кодеки я точно разрабатывать не буду.
Вы себе противоречите, чтобы «не реализовывать очередной велосипед», как раз и требуется владение инструментами, позволяющими использовать уже реализованное.
Причем тут изучение DSP и то, за сколько вы там стриминг подняли? Речь не об этом, это пример того, как нежелание отойти от одних инструментов и изучить другие приводит к жуткой потере времени — в данном случае, для примера, я сказал про реализацию стриминга на голом DSP и ту же реализацию на платформе с Linux.
Причем тут изучение DSP и то, за сколько вы там стриминг подняли? Речь не об этом, это пример того, как нежелание отойти от одних инструментов и изучить другие приводит к жуткой потере времени — в данном случае, для примера, я сказал про реализацию стриминга на голом DSP и ту же реализацию на платформе с Linux.
Вот для этого я и купил Raspberry — Linux по идее должен позволить использовать готовые наработки.
Пару книжек ко Python я скачал, посмотрим, что он даст. Но в целом меня раздражают решения, которые впустую тратят и так не слишком большие мощности девайса.
Да и лишние прослойки, ничего полезного не делающие, тоже не люблю. К сожалению, без некоторых не обойтись. Но хорошие библиотеки полезны.
Пару книжек ко Python я скачал, посмотрим, что он даст. Но в целом меня раздражают решения, которые впустую тратят и так не слишком большие мощности девайса.
Да и лишние прослойки, ничего полезного не делающие, тоже не люблю. К сожалению, без некоторых не обойтись. Но хорошие библиотеки полезны.
Не заморачиваясь с USB (и не разбирая роутер) можно так: habrahabr.ru/post/151982/. Но всего три выхода.
Есть еще ft245bm. С точки зрения USB-хоста(роутера) — FTDI USB-UART, а физически USB->8 TTL пинов.
Вот спасибо, мил человек! Там даже не выходы, а GIO. Не знаю, как случилось, что я до сегодняшнего дня не подумал о таком простом решении. Вот, и Ariman выше о том же пишет.
В вашем случае, конечно, нет. Я про другие применения, в которых это может быть важно.
Вы о потреблении?
Потребляет, в основном, передатчик — так что в случае с зигби потребление тоже не очень будет радовать.
Хотя конечно, связка кортекс-зигби, да еще и регулярно уводимая в сон, будет потреблять меньше.
Роутер без дополнительной периферии, со включенным wi-fi модулем потребляет, по моим замерам, 100 мА х 5В, что тоже, согласитесь, не так много.
Потребляет, в основном, передатчик — так что в случае с зигби потребление тоже не очень будет радовать.
Хотя конечно, связка кортекс-зигби, да еще и регулярно уводимая в сон, будет потреблять меньше.
Роутер без дополнительной периферии, со включенным wi-fi модулем потребляет, по моим замерам, 100 мА х 5В, что тоже, согласитесь, не так много.
Читаю такие посты и в голове начинает теплится надежда: через пару лет, когда будет своя квартира/дом, можно будет уже смело собирать сервер для автоматизации всего дома… начиная от примитива в виде автоматики освещения и заканчивая умным холодильником, отправляющим на телефон СМС со списком необходимых покупок.
А можно поинтересоваться, откуда узнали про свойства перемычки R113? А то хочется тоже сделать несколько проектов на WR703N, но не могу найти достаточно информации именно о таких вот моментах — перемычках, точках, куда подпаяться для получения плюшек… =)
Вот здесь энтузиасты отреверсили схему WR703N.
Она во многом совпадает со схемой mr3020.
Она во многом совпадает со схемой mr3020.
Автор, а как вы подали питание на шайтан-машинку? Во всей этой схеме смущает, в общем-то, только этот момент — ведь на выключателе, обычно, питания как такового нет.
Ага, этот момент я как раз на втором курсе вуза и прояснил, когда сделал первый подобный девайс. И тогда мне пришлось тянуть отдельно провод из розетки. С тех пор у меня было пять лет, чтобы этот вопрос как-то решить)
Когда менял люстру, увидел больше проводов чем надо — они были на случай, если там будет висеть пятирожковая люстра с индивидуальным выключателем на группу рожков — так как у меня их всего три и выключаются они одним выключателем, лишний провод я использовал для того, чтобы вывести себе питание (второй-то его конец был выведен там, где находится выключатель). А земля была, понятное дело — выключатель же вставлялся в разрез между лампой и землей.
Когда менял люстру, увидел больше проводов чем надо — они были на случай, если там будет висеть пятирожковая люстра с индивидуальным выключателем на группу рожков — так как у меня их всего три и выключаются они одним выключателем, лишний провод я использовал для того, чтобы вывести себе питание (второй-то его конец был выведен там, где находится выключатель). А земля была, понятное дело — выключатель же вставлялся в разрез между лампой и землей.
В таком случае получается, что вам просто повезло (я бы предпочёл шайтан-машинку разместить на месте выключателя, но не суть). В общем же случае или придётся тащить розетку или давать собственное питание, или прокидывать дополнительный провод…
PS на лампу земля обычно не подается, только фаза и ноль. По правилам выключатель должен размыкать фазу.
PS на лампу земля обычно не подается, только фаза и ноль. По правилам выключатель должен размыкать фазу.
Она и есть на месте выключателя, туда выходит провод. Да, вы правы, конечно же фазу размыкает, просто не стал акцентировать на этом внимание.
Собственное питание проводится без особых проблем во время ремонта — как раз когда меняют выключателем и прочие, собственно, во время ремонта я и подключил тот дополнительный провод.
Собственное питание проводится без особых проблем во время ремонта — как раз когда меняют выключателем и прочие, собственно, во время ремонта я и подключил тот дополнительный провод.
Не при всяком ремонте это возможно (В панельных домах бывают залиты каналы бетоном, в кирпичных домах чаще всего надо штукартурку штробить для прокладки новых кабелей). Да и ремонт не всегда возможен (обычно только в своём жилье).
Эхх… Кокгда уже можно будет получать питание по одному проводу или по радио без диких потерь и вреда для окружающих :(
Эхх… Кокгда уже можно будет получать питание по одному проводу или по радио без диких потерь и вреда для окружающих :(
Хорошая, статья, браво!
Вот, кстати, на просторах TP-LINK нашел еще один интересный роутер, WR-720N
На форуме openwrt утверждается, что он на том же железе, а благодаря встроенному блоку питания подобное устройство потребует гораздо меньшего количества проводов.
Вот, кстати, на просторах TP-LINK нашел еще один интересный роутер, WR-720N
На форуме openwrt утверждается, что он на том же железе, а благодаря встроенному блоку питания подобное устройство потребует гораздо меньшего количества проводов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Собираем wi-fi устройство управления электроприборами с веб-сервером и JS-фронтэндом