РЕКЛАМА НА ФОРУМХАУС Эта проблема с "переполнением счетчика" свойственна не только абдуринщикам. Она присутствует в SDK zStack от Texas Instruments. Возможно, индус, писавший код, любитель ардуино, но это бросает тень на TI. Кстати, кто нибудь в курсе происхождения термина Arduino? Прихожу к выводу, что это комбинация двух итальянских слов Arduo и asino. Хотя могу ошибаться.
Проблема не у ардуинщиков, проблема у "знатоков", теряющих свое ощущение элитарности и причастности к Тайнам: любой школнег по картинке из интернета, даже не умея понимать "принципиальные схемы", не зная целочисленной арифметики и языка ассемблера теперь способен собрать какую-то заумную хрень, которая как бы даже работает А проблема потому, что как у любого специалиста - знаток ограничен мышлением в области своей специализации. Например, зачем CAN в выключателе - он не понимает, потому что это избыточно, не для того и вообще ардуинство. Между тем - причина понятна и ясна для любого, кто на практике сталкивался именно с выключателями: это надёжность и время срабатывания. Это тот случай когда критически важно время реакции и недопустимы сбои, потому что их заметно сразу. Любые радиоканалы тут - либо задержка, либо нестабильность, либо то и другое сразу. Проводное соединение решает эту проблему, но либо приводит к фиксации структурного узла "выключатель-контроллер", либо требует некой шины, ну например CAN как вариант вполне допустим: малое время реакции, гарантированная доставка с контролем. Но знатокам этого не понять, они просто мыслят в другой плоскости Байтики считают, нолики-единички.
Это Вы здорово подметили, Прямо в точку. У ЗНАТОКОВ, по идее хватает ума понять, что происходит в современном мире, и что школьник им не конкурент. Скорее всего настоящий ЗНАТОК, не должен терять ощущение элитарности, если ребенок 4 класса в состоянии создать в TinkerCad аналог гирлянды, используя блочное программирование, собрать макет на Ардуино и перенести туда код. А вот определить "знатока" можно по фразе "Ардуино зависает". Многие "знатоки" даже не в курсе, что Ардуино, - это просто платформа, позволяющая быстро собирать прототипы, и программировать микроконтроллер Atmel, и стандартная обвязка этого микроконтроллера в производственных решениях, практически ни чем не отличается. Любая инженерная задача имеет множество путей решения. Но если "знаток" уверен, что провода это прошлый век, он даже не будет вникать в задачу, и сразу скажет, что это неправильно, и так делают только "ламеры". Настоящий ЗНАТОК сперва проанализирует задачу, и только потом будет комментировать. И комментировать будет осторожно, так как знает пословицу "Век живи - век учись".
Трудно не согласиться. Проблемы только у тех, кто способен критически мыслить, просчитать, увидеть узкие места, найти разумные решения. У тех кто собирает какую-то заумную хрень из @овна и палок по картинкам из и-нета проблем нет. Ключевые слова "как бы даже работает", результат не важен. У тех, кто, по твоим словам, сталкивается на практике с выключателем, не возникает мысли, что малое время реакции требуется только если выключатель и лампочка в одном помещении, иначе вообще на$рать на время реакции? Нет? А разместить контроллер в непосредственной близости от выключателя и лампочки и соединить напрямую без всяких CANов? Не? Такого варианта нет на картинках в и-нете? Может причина в чем-то другом? Например в ограниченности некоторых способностей... Не заточена ардуина на грамотную разработку, только на повторение по картинкам.
Эх... Мультиварка тоже не заточена под серьёзную кухню. Только на "повторение по картинкам" жёнами, зачем-то варящими обед "из говна и палок", вместо того, чтобы кормить знатоков, проектирующих мультиварки, в ресторане. Представляете, как бесятся шеф-повары...
Я ж говорю, "мыслит в другой плоскости" - вот и пример. Абисняю: Тема - "разработка умного дома", то есть как бы предполагается, что речь идет о доме, где люди, как правило, включают свет в помещении, находясь в этом помещении, а не за 100500 километров. Логично? Логично. Итак, люди, находясь в помещении, щелкают выключателем, и надеются получить быстро-немедленно реакцию. Что по техническим причинам при наличии беспроводной связи в общем случае гарантировать сложно. Да, 99 раз оно сработает идеально, но 1 раз будет задержка в 0.7 секунды и это будет РАЗДРАЖАТЬ, как хлебная крошка под жопой в постели. Поэтому провода тут лучше, но есть нюанс. Да, можно "разместить в непосредственной близости без всяких шин", но тогда этот блок получается структурной единицей. Неделимой. То есть есть некое "реле" и некая "кнопка" у этого реле, они связаны в пространстве, размещаются вместе (или очень близко) и работают как единое целое. Допустим, у реле есть также "виртуальная кнопка", которую можно нажать удаленно - но остается и физическая. Если у нее есть фиксированная позиция, как у обычного настенного выключателя почти всегда - то получается неоднозначность: - выключатель включен, а реле выключено удаленно: несоответствие. - выключатель выключен, а реле включено удаленно: снова несоответсвие. И это снова РАЗДРАЖАЕТ. Это можно решить кнопками без фиксации и контроллером реле, позволяющим просто переключать состояние. Будет прекрасно, но ровно до того момента, пока реле и кнопка одни. Добавляем второе независимое реле - и начинаем решать вопросы совмещения двух кнопок в одном корпусе, да еще возможно с гальванической развязкой, либо заменой двух реле на одно двухканальное. Либо трехканальное - потому что вот приспичило включать еще и подсветку углового столика. И шторы отодвинуть. И экран проектора опустить... Так вот тогда и возникает потребность в некой шине, чтобы полностью уйти от созависимости управляющего (кнопки) и исполняющего (реле) элементов. Просто кто-то до этого в принципе не доходит, у него в мыслях ровно одно реле по умолчанию, а кто-то заранее хочет предусмотреть все варианты. Ну а то что в качестве шины выбирают CAN, а не что-то другое - да просто потому что подключить адаптер CAN-шины в разы проще, чем спроектировать собственный интерфейс, от физического уровня до уровня приложения, реализовать его в схеме, изготовить, запрограммировать... Потом долгая отладка всего этого... В этом нет смысла сейчас, при наличии кучи готовых модулей. Если человек не готов организовывать собственное промышленное производство своей собственной аппаратной платформы - это никогда не окупится.
Не согласен. Если есть "физическая индикация" состояния выключателя, то от этого не уйти, при наличии удалённого управления. Если, конечно, удалённо не управлять самой клавишей выключателя А если её нет, то это раздражает не меньше. Хотя, впринципе, решаемо управлением одной кнопкой или сенсором. И, если уж к выключателю всёравно тянуть провода, то лучше напрямую от исполнительного устройства, чем через "центр управления всего". По крайней мере, не будет зависимости от центра. А уж само исполнительное устройство пусть общается с "центром" при его наличии и исправности, либо продолжает работать с кнопкой независимо от остального. Чтобы "умный дом" в случае сбоя мозгов не превращался в тыкву.
Занафига? У углового столика должна быть СВОЯ кнопка. Где-то ближе к самому этому столику. И у штор должна быть СВОЯ кнопка - где-то, где этими шторами удобно управлять, когда они мешаются физически (окно захотелось открыть, например). А занафига единственный вариант управления "одной кнопкой туалетного выключателя"? Впрочем, если хочется, то для этого есть "мозговой центр", который гибко программируется на взаимодействие всех, связанных с ним исполнительных устройств между собой. Но кнопка, которая управляет конкретным устройством, при "отвале мозгов" должна быть своя, в непосредственной близости от этого устройства. И иметь для него (конкретного устройства) наивысший приоритет.
А вот для этого и не должно быть "единого центра". Должна быть по возможности децентрализованная сеть, где Кнопка 1 может обращаться к Реле 4 или Реле 18, в зависимости от настроенной конфигурации, с возможностью перестройки этой самой конфигурации. К сожалению, именно этого как правило и не делают разработчики "умных домов": во главе ставится Великий Контроллер со сценариями, удобными интерфейсами и прочим (или Большой Шкаф с кучей реле) - и всё зависит от работоспособности этого центра. Кстати, та же CAN-шина вполне себе децентрализованная по своей сути. Если ее физически не разрушить - участники обмена вполне могут обмениваться данными друг с другом. Ее аналог в IP-среде (проводной или беспроводной) - MQTT, там из централизованного только брокер, который сам по себе никакой особой функции не несет, и в принципе может быть легко заменен.
И вопрос даже не в зависании этого ящика, а в элементарной аварии, например блока питания. И у пользователя начинаются пляски, за 100 км. от дачи. Это не только с умным домом, но и с отоплением. Попробуйте в ветках отопления написать, что лучше иметь распределенную систему, заклюют. Там уровень контроллера определяется сколькими насосами, котлами и тэнами он может управлять одновременно.
Это везде так: чем больше свистелок и перделок - тем круче Еще высокоинтегрированные системы, где ни один элемент не может быть быть просто так отключен или заменен: к контроллеру ХХХ непременно нужен блок УУУ, иначе ничего не будет работать. В "товарных" системах это преимущество: можно продать целую линейку связанных товаров, подсадив клиента на своё решение, и клиенту это оправдывают "хорошей совместимостью" и "оригинальным качеством", но вот потом, когда что-то идёт не так - получается та самая тыква.
Децентрализованная архитектура и есть "баня, а через дорогу раздевалка". Раздевалка должна быть в бане, а через дорогу может быть администрация. Правильно Pop70 говорит, в целях надежности устройство должно быть функционально законченным, со своими органами управления. Если это рольставни, то значит контроллер управления одной рольставней, кнопки расположены непосредственно у окна и подключены прямо к контроллеру, без всяких канов, ланов, вайфаев. Если отопление - то контроллер отопления со своими датчиками/насосами/клапанами. Да, появляется некий зоопарк устройств, но устройства работают автономно, пока есть питание. А в твоем случае нужно что бы работало всё и сразу. Прокладывание CAN шины это отдельная песня, как и конфигурирование децентрализованной системы. CAN если и нужен, то в автомобиле. В доме ему делать нечего. Есть две крайности: -тащить все провода к одному центральному контроллеру; -ставить контроллер на каждый выключатель/розетку/лампочку. Ты топишь за вторую. Не бывает так, что бы система автоматизации заработала с полпинка. Её монтируют месяцами, потом отлаживают всю оставшуюся жизнь. Потому разумнее отладить отдельно взятое устройство, а потом последовательно его тиражировать по количеству окон/помещений/этажей в доме, чем пытаться запустить всю систему сразу. С другой стороны: в доме могут идти отделочные работы, а системы автоматизации еще нет. Разумно так проложить в стенах провода, что бы на начальном этапе все могло работать без всяких контроллеров в чисто ручном режиме. Встает резонный вопрос, какой интерфейс использовать между устройствами... тот который необходим и достаточен для данных условий. С точки зрения монтажа произвольная топология сети обычным кабелем предпочтительнее витой пары с шинной архитектурой. Какие, Netbyka, интерфейсы ты знаешь, что бы передавать сотни бит информации в сутки по сети с произвольной топологией?
А для этого система и должна быть децентрализованной. О чем я и говорю. Простой пример, с теми же выключателями (наиболее очевидный): Как уже говорилось - по ряду причин получается, что надежнее и быстрее провода. Но чтобы не вызывало диссонанса с возможностью удаленного управления - кнопки, а не тумблеры (я сейчас о сути, а не о форме. По форме - клавиши без фиксации). То есть, одно устройство - "реле с кнопкой", для простоты однотипные контроллеры с 3 выводами на кнопки и 3 выводами на реле. Тянуть шину по всему дому - гемморой (хотя все легко решается - CAN не требует специальных разветвителей, можно элементарно соединять отдельные участки витой пары). Кстати, витая пара - намного удобнее "обычного кабеля" (какого? ШВВП? телефонной лапши?) - 5мм шнур, 4 пары, разные цвета. Удобно. Но все равно - лично мне не понравилось такое решение, хотя его логику и причины я понимаю. Поэтому у меня контроллеры все-таки беспроводные, на ESP (хотя локальные кнопки - провод). Но они - одинаковые, только с разными ID в сети, и отправить на них управляющую команду в принципе можно откуда угодно, по MQTT. Прошивка заливается одна и та же, что позволяет их тиражировать. Связность - mesh-сеть. Вот и получаем именно как сказано: незачем чего-то ждать: ставим очередной блок, монтируем кнопки, пользуемся сразу. А вот сейчас, например, прикрутил обработчик событий MotionDetection с камер (транслируются в MQTT) к отправке команд на включение некоторых контроллеров (тоже по MQTT). В результате свет в нужных помещениях включается сам, когда туда кто-то заходит. Без нажатий на кнопки, без прокладки новых проводов. Конкретно за эту операцию отвечает одна небольшая коробочка. Если с ней что-то вдруг случится - ее замена встанет в заливку файла в очередную ESP, а пока можно будет пользоваться кнопками. Вот это я и называю децентрализацией. Нет Главного Сервера. Хотя корректнее наверное было бы обновить прошивку контроллеров и дописать в нее возможность самостоятельно подписываться на нужные события - тогда и специальная коробочка не понадобится. Обновляется она всем однотипным блокам одновременно, что тоже удобно, хоть сотня их будет. Но если бы когда-то давно выбрал CAN - мало бы что изменилось: просто устройства добавлялись бы на шину, проводами, а не заводились в сеть. Совсем необязательно "всё и сразу". Да откуда ж мне их знать-то? Так, на ходу выдумываю всякое... Пусть вон знатоки рассказывают.
Вы сами себе противоречите. Если нет единого центра (пусть даже в виде "шины"), то никаким боком разные кнопки не будут обращаться как им вздумается к каким угодно реле. Да и для удалённого управления, без центрального блока не обойтись. У Вас это MQTT брокер, к которому один чёрт нужно прикручивать "панель управления". А потому, что MQTT - это только "события", без "состояний". А удалённо хочется видеть именно состояния, и генерировать события, эти состояния изменяющие. И без MQTT, через который Ваши кнопки обращаются к Вашим реле, и кнопки, и реле превращаются в тыкву, которой не только удалённо, но и локально управлять не получится. Поэтому, каждое устройство должно быть законченным, с собственным полноценным функционалом, не зависящим ни от чего более. А роль центра - отслеживать события и состояния отдельных устройств, и по запрограммированным правилам "бегать по дому", и "жать на кнопки" уже в масштабах всего дома. Mesh тут ничего не решает. Потому, что это - СРЕДА передачи сообщений и только. С той же задачей справится и обыкновенный wifi, и зигби, и радиоканал... Да хоть тот же CAN. Сообщения напрямую между устройствами - тоже вариант так себе. Много перенастроек множества конечных устройств при изменении логики их взаимодействия, ведёт к хаосу, плохой предсказуемости результатов этих перенастроек, к "разветвлённой", а то и "зацикленной" логике. В случае единого центра, проще работать с законченными сценами и сценариями, привязываемыми к конкретным событиям. Сам центр всегда знает именно текущее СОСТОЯНИЕ любого устройства, и системы вцелом.
Можно, но только последовательно, произвольная топология недопустима. Попробуй добавить через год еще один девайс - потащишь ВП от дальнего конца или будешь врезать петлю. Тем, что помимо ВП нужно тащить еще и питающий кабель? Или тем, что одножильные провода ВП легче ломаются? Офигенная логика. Вайфай нужен для передачи голоса и видео, для управления светом достаточно и Zigbee. Но Zigbee забыли прикрутить к Ардуино, а ты сам не можешь, так ведь? А чо не GSM? У всякого интерфейса есть свое назначение. Прикручивать 100 Мб/сек для передачи 100 бит в сутки. Круто и бессмысленно. Ты бы еще оптоволокно прокинул к каждой розетке. Местные кулибины так и поступают, как ты, берут всё что под руки попадается, соединяют синей изолентой, и называют это системой автоматизации дома. Либо бери готовое решение, либо - если взялся за разработку своей системы - разрабатывай, а не собирай из @овна и палок. Он просто технично соскочил с крайней децентрализации на промежуточную архитектуру.