Сообщений в теме: 503

[Sander]

пальцем на таче рисуем нужную кривую (с обработкой запрещенных зигзугов разумеется)

Да-да, даешь эллиптическую!

[BorisKramer]

Сдается мне, вы ошибаетесь про CAN, как физический уровень. Это совсем не так, это 2-4 уровни модели. Но это не важно, в контексте форума и данной темы.

 

Теоретически конечно да. Можно CAN хоть по радио передавать. Но практически это обычно подразумевается сеть типа "шина" с физическим уровнем в виде дифференциальной пары. Причем мне больше нравится devicenet, которая позволяет ответвления от шины - ну не звезда, а больше ершик

[Starcomputer]

С таким же успехом может сломаться исполнительный блок какой-то, например блок автодолива или блок управления температурой - это все-равно потенциальная опасность. Много блоков = много проводов или ненадежный wifi или другой беспроводной интерфейс, в каждом блоке - свой процессор = дорого. По-моему, моноблок с модульной конструкцией будет лучше, одну плату вынул, другую вставил, вот и весь ремонт. Кроме того, управляющий блок, кроме настройки остальных, отвечает за диагностику всей системы и за алерты, будет плохо, если из-за проблем с коммуникациями между блоками сообщение о критическом повышении температуры, не дойдет до хозяина аквариума. 

Надежность любой системы определяется надежностью каждого элемента и их количеством. Небольшие блоки надежнее моноблока.

Atmega88 стоит менее 40 руб - пачка сигарет. Это ДОРОГО ?! "Одну плату вынул - другую вставил" - вот это дорого !

Не вижу причин в нарушении коммуникации между блоками, тем более, что центральный блок об этом сразу сообщит.

[Starcomputer]

У них связь очень редкая. А когда блок автодолива будет по вайфаю общаться с блоком емкости засола и блоком осмос-менеджера и не забывать скомандовать блоку управления розетками выключить помпу возврата при падении уровня воды в сампе то проблемы будут. Да, еще не забыть скомандовать блоку светильника выключится при получении информации от блока контроля температуры о перегреве аквариума.

То что на любом примитивном контроллере за 200 баксов делается в два десятка картинок FBD при реализации на WiFi превратится в мегамонстра, который будет отваливаться сам по себе. А в случае подвисания WiFi роутера (бывает) отвалися вообще сразу все.

Модули должны быть достаточно самостоятельными и сами выполнять текущие операции. Через центральный блок только настройка и некоторые межблочные связи.

[LeonidM]

Надежность любой системы определяется надежностью каждого элемента и их количеством. Небольшие блоки надежнее моноблока.

Atmega88 стоит менее 40 руб - пачка сигарет. Это ДОРОГО ?! "Одну плату вынул - другую вставил" - вот это дорого !

Не вижу причин в нарушении коммуникации между блоками, тем более, что центральный блок об этом сразу сообщит.

Так проблема не в стоимости комплектующих, а в стоимости конечного устройства, атмегу же еще надо запрограммировать, причем каждый блок своей программой. Интеллектуальное устройство с неким протоколом взаимодействия будет дороже, чем исполнительное. Не делают же дозаторы, например, состоящие из 5 отдельных насосов, общающихся с единой панелью управления, а делают одну коробку с 5-ю насосами. В общем куда ни кинь - получается профилюкс.

[balabollng]

Не будет оно дороже. Никто, подчеркиваю, совершенно никто не пользует весь спектр возможностей аквакомпьютера. По разным причинам. И тем более никто не покупает аквакомпьютер для баанки в 100л. Следовательно, моноблок - заведомо переплата.

Потребности у людей возникают поэтапно. И логично, что сама система должна иметь возможность масштабирования. Сегодня это грелка, завтра дозатор, послезавтра светильник и т.д. И только в тот момент когда появляется потребность это все объеденить должен появляться тот самы модуль комплексного управления. Просто грелка, дозатор и свет могут сразу быть компонентами будущей экосистемы, но работать независимо.

Т.е. стоймость экосистемы некорректно сравнивать со стоимостью монолита. Как и ее надежность.

Связь не проблема. WiFi это физика. Протокол - логика. Если WiFi чем-то не устраивает, ставим вместо адаптера WiFi адаптер Ethernet и получаем совершенно надежное соединение с любой топологией. Каны/маны это низкоуровневая передача имеющиая перед собой конкретные цели. CAN - конкурирование устройств. Т.е. если в шину начнет писать (условно) педаль тормоза и газа, то педаль тормоза будет в приоритете. В этом ее суть и смысл. Сову на глобус натягивать не нужно. Если конечно вам не нужна круглая сова ))

[Kiraso]

Модульность и нужна, она же масштабируемость. 

Я также за проводное соединение между модулями, а не по воздуху.

Если напрягает большой кросс-мозг (типа того, что предлагал выше), можно пойти чуть далее и кросс-плату сделать с некой интеллектуальной составляющей.

Т.е. в микроконтроллер установленный на кросс-плате (ну так назовем для удобства) как раз будет отвечать за профили взаимодействия между модулями (триггерная и прочая логика) в "лего" конструкторе.

Отображение и настройка ложится на внешний модуль (ембеддед комп). В принципе, можно и без него настроечный профиль подтянуть, к примеру с sd карты (картридер на кросс-плате), но это уже когда вещь становится массовой и люди активно делятся своим опытом (что, как показывает практика, вещь редкая и рассчитывать не приходится). А так тот же профиль можно залить на карту через простой комп, где будет некая тулза, где графически (кубиками "лего") и связями между ними задается весь функционал. Т.е. в целях экономии внешний большой моцк и не нужен получается (но с ним удобней и оперативней). 

[balabollng]

Никто не будет кубики складывать. Оно должно все само... как-то...

[BorisKramer]

CAN - конкурирование устройств. Т.е. если в шину начнет писать (условно) педаль тормоза и газа, то педаль тормоза будет в приоритете. В этом ее суть и смысл.

 

И в этом ее основное преимущество. Если в шину одновременно пишет автодолив и сигнализатор протечки, то сигнализатор протечки будет в приоритете. Это офигенно удобно, когда у тебя мультимастерная шина с контролем/гарантией доставки пакетов.

[BorisKramer]

 

Если напрягает большой кросс-мозг (типа того, что предлагал выше), можно пойти чуть далее и кросс-плату сделать с некой интеллектуальной составляющей.

Т.е. в микроконтроллер установленный на кросс-плате (ну так назовем для удобства) как раз будет отвечать за профили взаимодействия между модулями (триггерная и прочая логика) в "лего" конструкторе.

 

Большой кросс-мозг нужен для общего управления и отображения. А в случае отказа мозга разные устройства, если они сидят на мультимастесной шине могут друг с другом общаться напрямую и без мозга.

[lexx8691]

Вообще если забыть про Романа с его идеями, вырисовывается системный блок в котором на шине стоят карты разного назначения и пара километров проводов в тумбе. 

[BorisKramer]

Вообще если забыть про Романа с его идеями, вырисовывается системный блок в котором на шине стоят карты разного назначения и пара километров проводов в тумбе. 

 

Количество проводов не меняется от количества идей

К каждому блоку идет питание. А подавать его двухжильным проводом или 4-х жильным особой разницы нет.

[balabollng]

И в этом ее основное преимущество. Если в шину одновременно пишет автодолив и сигнализатор протечки, то сигнализатор протечки будет в приоритете. Это офигенно удобно, когда у тебя мультимастерная шина с контролем/гарантией доставки пакетов.

В данном примере - да. Но все может обстоять и совершенно иначе. Тот же автодолив может для начала спрашивать разрешения у арбитра. Если он его не получает, не лить. Т.е. по умолчанию - запрещено. Таким образом, сестема гарантирована от протечек на все 100%. Но при этом, сам автодолив совершенно не обязан знать о всех устройствах на шине. Достаточно просто знать что есть арбитр. А вот арбитр уже может знать о всех. И выдавать не просто решение по датчику протечки, а принимать решение по какой-то логике, суммируя несколько входных параметров.

Т.е. возникает очевидное приемущество: конечное устройство оставаясь автономным, принимает верные решения не зная своего окружения.

[lexx8691]

Количество проводов не меняется от количества идей

К каждому блоку идет питание. А подавать его двухжильным проводом или 4-х жильным особой разницы нет.

Да какая разница 2 или 4 км.

Светильник питается 2,5 квадрата и вокруг обвиваем 0,2 квадрата сигнальный? Осмос стоит фиг знает где, от него идет трубочка, какая разница, кинем еще кабель сигнальный. К блоку управляемых розеток зачем провода тянуть, там БП встроенный.

[Kiraso]

....., если они сидят на мультимастесной шине могут друг с другом общаться напрямую и без мозга.

Для этого они должны быть уже достаточно интеллектуальны, чтобы общаться между собой, но не всегда можно учесть все возможные конфигурации, особенно с выходом новых модулей, о которых ранее ни чего не было известно. Перепрошивать слишком умные мозги модулей та еще затея.

 

Мне лично больше импонирует система с модулями -примитивами.

Не, свой внутренний функционал они должны отрабатывать безукоризненно и если там есть над чем подумать/посчитать то само собой все делается внутри и автономно.

А вот связь между модулями лучше возложить на специально заточенную хрень работающую по "людскому протоколу", типа того: подошел, посмотрел, потестил, что-то не понравилось, подкрутил там и сям и удалился.

При этом и кросс-хрень не обязана знать о новых модулях, логика связей между ними выстраивается именно по принципу:

- спросить у А, параметр #1 и #3,

- спросить у H, параметр #2

- если А.#1 > 40%, А.#3 - On,  H.#2 <= 10%, то в модуль С выставить #1 в 65%, а  в модуле D выключить #2  

Это на сухом языке системы, для человека это есное дело должно быть по людски описано

[Sander]

Теоретически конечно да. Можно CAN хоть по радио передавать. Но практически это обычно подразумевается сеть типа "шина" с физическим уровнем в виде дифференциальной пары. Причем мне больше нравится devicenet, которая позволяет ответвления от шины - ну не звезда, а больше ершик

Блин, а вот не буду в дискуссию по CAN втягиваться, хотя и хочется.

[balabollng]

В целом, было бы не плохо для всех производителей и желающих им стать, а также самодельщиков, создать некий биль где определить протокол обмена и экосистему. Производителям взять на себя неконкурирующие задачи разработки и выпустить элементы такой системы. Что приведет к реальному прорыву в этой области, т. к. по отдельности это просто не осилить.

Потребитель получит уверенность в развитии и совместимости, что априори сейчас снижает доверие к разрозненным решениям.

Ну а потом, когда основа будет создана, вернуться к здоровой конкуренции.

Я не думаю, что это утопия. Требуется воля - да. Нужно описать правила игры - да. Но учитывая модель независимых девайсов, каждый получит профит который в любом случае сможет реализовать сам, если вдруг, что.

[V.Navi]

В целом, было бы не плохо для всех производителей и желающих им стать, а также самодельщиков, создать некий биль где определить протокол обмена и экосистему. Производителям взять на себя неконкурирующие задачи разработки и выпустить элементы такой системы. Что приведет к реальному прорыву в этой области, т. к. по отдельности это просто не осилить.
 

 

Роман, отличная идея. Воплотимая ли ?!

 

В качестве основного блока конечно же должен выступать микрокомпьютер уровня Raspberry Pi3 (МК).

Почему микрокомпьютер

 - прежде всего он должен обеспечить качественный понятный интерфейс взаимодействия между пользователем и железками (локальный вебсервер с настройками и облако)

 - должен иметь набор стандартных интерфейсов для работы с сетью (с облаком),

 - для работы с передачей видеоизображения (USB-камера)

 - для работы с сетью модулей исполнительных устройств (RS-485 или аналог) (CAN в данном случае избыточен и более дорог)

 - для работы с сетью датчиков (беспроводной BLE)

 

Архитектура снизу вверх:

 

Самое примитивное устройство - беспроводной датчик температуры\затопления и т.д. Выполняющий лишь роль индикатора\сигнализатора периодически отсылающего инфу на МК.

 

Исполнительное устройство - термостат\автодолив\управление помпой и. т.д. Полностью автономные устройства (не требующие управления от МК). Вся логика работы содержится исключительно в их внутренностях. По проводному интерфйесу модуль отчитывается МК о своем текущем статусе и различных предупреждениях\ошибках. Через тот же интерфейс МК может конфигурировать "некие рабочие параметры" устройства, если таковые имеются.

 

МК - головное устройство, задача которого, объединить все датчики, исполнительные устройства в единую виртуальную сеть и "подглядывать" за их работой, вести статистику. В случае нештатных ситуаций - информировать пользователя доступными способами. Обеспечить пользователю гибкий удобный интерфейс по конфигурировании своей "экосистемы" и возможность визуального наблюдения.

[NorkIn]

А почему ещё не кто не догадался связать все это с умным домом?!) например majerdomo, думаю не плохо будет, если тебе вслух озвучат проблему т к не всегда охото куда то лезть смотреть и т д !)

 

Не совсем с умным домом, но у меня уже год на обкатке система мониторинга в связке Blynk + ESP. Реализован мониторинг температуры воды в аквариуме, на радиаторе светильника и в тумбе стоит двойной датчик (температура + влажность), а так же ведется мониторинг уровня воды в емкости долива по двум точкам и отслеживается время работы самой помпы долива. Отслеживается UP-time железки (ESP) по которому видно падало ли 220В или нет и когда, присылается оповещение когда ESP не в сети (wi-fi), плюс настраиваются эвенты на оповещение при достижении определенных значений температур, уровня воды в емкости долива. Оповещения в виде push уведомлений на смартфон и отсылка e-mail. В приложении виджеты позволяют визуально наблюдать в режиме реального времени за всеми этими параметрами и даже собирается некая статистика в виде графика.

 

 

Как-то так...

[BorisKramer]

Да какая разница 2 или 4 км.

Светильник питается 2,5 квадрата и вокруг обвиваем 0,2 квадрата сигнальный? Осмос стоит фиг знает где, от него идет трубочка, какая разница, кинем еще кабель сигнальный. К блоку управляемых розеток зачем провода тянуть, там БП встроенный.

 

По проводам 2,5 квадрата к светильнику можно передать любую информацию если нужно. Но и пустить параллельно еще один сигнальный провод проблем не составляет. На самом деле количество проводов до датчиков и всяких помп настолько велико, что пара лишних роли не играет. Тем более что их и немного надо.