Предположим что пинов хватит на все на это.. и они не будут друг-друга перекрывать. А поскольку что-то из этого потребует определенных пинов (с поддержкой шим например) то значит мы эти входы на корпусе сгруппируем и обведем красной линией например. Все 1-wire датчики тоже посадим на 1 пин, а на корпус выведем десять например, и обведем синей линией - что сюда вставлять все что 1-wire. и т.д.
Вобщем все датчики, шилды и т.п. втыкаются в Мегу, в Нано соответсвенно ваша фотоловушка, сервы и 1 радиомодуль - правильно?
Логику вроде вы уже описали сами: опрашивать датчики, по езернету данные отдавать в локалку, по уарт в ПК.
Только непонятно причем тут нано, и связь с ней через радиомодули - она вроде отдельный эелемен и с задачей крутить сервы по сигналу фотодида справится и сама..
Лично я не планирую устраивать мешанину.. посто хочу предусмотреть на будущее. Что с центральным девайсом закончить, и потом заниматься только подключаемыми модулями до конца времен.
Puhlyaviy
Хорошо, давайте попробуем. Вот список датчиков и других устройств которые я подключаю сейчас (одновременно), при тестировании прототипа:
термо датчики 1-wire несколько
датчики влажности и температуры DHT22 несколько
реле - 8шт
модуль из 4 фотодатчиков и 4 лазеров
шаговики с драйверами - 3шт
DC моторы -2шт
электромагнитные клапаны 3шт (считай реле)
газовый счетчик потока
датчики затопления
.... так, я что-то уже должен был понять?
Давайте ещ набросаем список модулей которые планируются на будущее
датчик IR
датчик шума
модуль дозиметров жидкости
модули измерения солесодержания
и еще несколько, вобщем-то однотипных..
Взаимосвязи между всеми этими устройствами конечно не в случайном порядке.. а по определнной схеме, так что они образуют какие-то блоки. Скажем 3 шаговика работают в рамках системы 3-х плоскостного подвеса.
Может это не очень много, но не так уж и мало.
Постараюсь еще раз объяснить зачем нужны плагины:
Допустим человек подключил дозирующую станцию - ему же нужно её настроить, по определенной схеме (т.е. на высоком уровне) - для этого подключается плагин и в интерфейсе появляется окно настроек: в каких пропорциях смешивать жидкости, к какой последовательности и т.п.) но и можно задать взаимосвязи с другими установленными модулями, не как в голову придет конечно, а только с определенными: например зависимость состава раствора от температуры.. если нет подключенного датчика температуры, то поле неактивно.
А например связать с влажностью воздуха нельзя, поскольку это не имеет значения.. вот для формирования такой вот определенной логики поведения и нужны плагины.
Другой пример - газ. в плагине для управления газовым клапаном должны быть настройки осносительно количества газа который нужно прокачать, и некоторые предопределенные опции, например: усилить вентиляцию, на время подачи. Если модуль вентиляции установлен - то эта галочка активна.
Или к примеру увлажнитель воздуха - если в системе установлены датчики влажности и температуры, то в настройках этого модуля активируется возможность установить зависимость.. а если нет, то остается только запуск по таймеру.
Вот, я перечислил реальные устройства, модули и их использование.. И вроде только убедился в необходимости модульной системы, т.е. плагинов.
гыыы и это все у вас будет висеть на одном МК? тоесть датчики и моторы по всему дому стоят и толстые кабеля тащатся в шкаф в подвале в котором и стоит МК? немецкие фантастические фильмы вас до добра не доведут.
Блин уже в пятый раз повторяю речь не про умный дом! Все перечисленные модули располагаются в тесном пространстве несколько кв. метров. Управляющее устройство там же, или за стенкой.
Блин уже в пятый раз повторяю речь не про умный дом! Все перечисленные модули располагаются в тесном пространстве несколько кв. метров. Управляющее устройство там же, или за стенкой.
тоесть это производственая линия? которую неадекватные работники будут переделывать каждое утро втыкая новые датчики?
я понял это такой новый сюжет порнофильма с участием МК?
вы мне напомнили тут был один.. он все хотел что бы ему помогли сделать автоматическую лампочку в туалете для кота которого они забрали с деревни, и который боялся ходить в туалет в темноте.. потом выяснилось что запитывать нужно от изменяющегося напряжения 12-14 вольт и нужно еще контролировать стеклоподьемники и подогрев сиденья делать :)
У вас куча интерфейсов, но рулить всем будет всё равно ПК. Так не выносите вообще никакую логику за его пределы. Сделайте всю переферию чисто исполнительной. Делать её активной-интеллектуальной без широкого доступа к данным от других устройств бессмысленно. Берите любой микроПК с любой осью с кучей различных интерфейсов, добавьте нужное количество платок расширения и варите всю кашу в нём.
Берите любой микроПК с любой осью с кучей различных интерфейсов, добавьте нужное количество платок расширения и варите всю кашу в нём.
каша в ПК.. удобно... заодно утилизируем тепло от процесора для приготовления еды.. но вижу проблему с помывкой корпуса после приготовления в нем каши :)
У мя дома системник маслонаполненный, можно и картошку пожарить, если найти древнюю, но мощную видяху, да БП на послабее заменить.. А так даже разогреть не выйдет.
С производственно линией близко.. Но зачем каждое утро?
Например раз в полгода или раз в два года. Да и не менять. а добавлять. Например в минимальной конфигурации достаточно лампочки и кипятильника, но все не очень автоматизированно - потому что нет датчиков.. хотя по таймеру тоже можно настроить, на глаз что называется.. Потом люди подкопили денег, расширились - и докупили датчики и линию дозировки реактивов - подключили и оно встроилось в общую систему управления. через месяц-другой добавили еще какое-то улучшение на пути к автономности и автоматизации.
ourlive
Ну вобщем тоже подумываю вынести логику на управление миниPC, а он будет уже управлять адруино (или подобным) контроллером, отдавая команды на исполнение. Подобно тому как например Processing работает с Arduino через библиотеку firmata. только смущает что видимо библиотеки для работы с интерфейсами тогда придется переписывать..
А я таки и говорю как раз про плаг энд плей: воткнул, скачались драйвера сами собой и все работает.. ничего пользователю делать не нужно.. у всех есть постоянный выход ви интренет ...
УТОПИЯ
для приверки - дайте десяти домохозяйкам десять принтеров и попросите их подключить к компьютерам. драйвера есть на сайте производителя. то, что профессионал сделает за 20 сек, обыватель не сделает никогда
Пох оду (ошибку заметил, исправлять не стал) думается мне что автор слегонца сам не понимает чего и зачем хочет... Я вот например вижу проблему в том, что сам по себе факт подключения миллиона разных датчиков на разные и-ф не вопрос. Вопрос - А как они взаимодействуют? Я, например никак не могу подогнать логику работы самогонного аппарата, где входных параметров всего 8-11 и 4 управляемых органа (подача воды в пароген и холодильник, моща насоса, моща тенов). Я просто не могу вычислить формулу, возможно еще параметров не хватает. Или, вариант, драйвер обменника валют... вроде из разницы только собсно сегменты... А у них разные напряжения и токи. Писец универсальности...
Я это к чему... В общем ВСЕ датчики и органы можна свести к единому интерфейсу (хоть бы и на безе Nrf24l01) с единой структурой команд и данных(дада автор, у КАЖДОГО по МК, хоть бы и тини13а). Ввести им нечто вроде мак адреса у РС тип-модель-номер. Протокол определения. Например у базы 3 приемника на разных частотах 1 для ловли бродкастов от неопознаных девайсов и настройки их в сети, 2 - для приема от неуправляемых датчиков. 3 - для двустороннего общения. Определится с протоколами передачи комманд на исполнение этим устройствам и данных от них(меня вот NMEA 1831 пленил, просто и со вкусом). Прописать на исполнителях отработку ими принятых комманд.
НО ХРЕН ты заставишь МК рулить этим всем. Дальше либо микро РС с хитрым и тяжелым софтом и дуиной на компорту (шлюз для получения/отправки команд), либо дуину ТРЕ ждать, там линух на борту.
Кистати я вот помню тут недавно ктото хотел было прошивать контролленры по радио :))) Так и не убедили что это глупо т.к. смысла шить нету. Максимум парамерты в ЕППРОМе поменять.
Автору видимо нужна возможность выполнять любой код без перепрошивки основного скетча.
Т.е. для нового датчика компилируется некий модуль, назовем его "драйвером", заливается на сд карту, "основной скетч" его находит, подгружает и добавляет вызов в конец своего основного цикла.
С системой команд микроконтроллеров почти не знаком, но если есть возможность писать в "программное адресное" пространство, то это вполне реализуемо
З.ы.
Вроде реализуемо. Нужно писать свой загрузчик, который должен еще и перелинковывать(корректировать адреса переменных и переходов) подгружаемый код. Тут подробнее:
Я чуть о другом. Я о его сути "$"+тип команды(исполнители)+параметры+контролька. Если собрать каталог стандарных девайсов то например "$SET, D, LGT, A, 001, I, 127,C, 2345" - контрольнику света 001 установить интенсивность 50% и проверка, вся ли строка пришла. Дальше шлюзу плевать на то как контрольник этого добьется. Надо только дождаться подтверждения или его отсутствие, например "$HOME, D, LGT, A, 001, I, 127, C, 2349".
NMEA не только навигационные данные передаёт, там вроде как любые типы датчиков к стандартным протоколам приведены, вот только разбираться в этим всем.. Не говоря уж об избыточности. Хотя если у вас завалялся нав комп из какого нибудь танкера, то с самогонным аппаратом он уж точно справится, а интерфейсов хватит на целый нинно-водочный цех.
Это не я предложил плагин спутниковой навигации к самогонному аппарату прикрутить... Я его сюда прикрутил как пример очень геморной связи датчиков - исполнителей, которые не особо слепишь, кроме как с помощью ПИД-ов. А НМЕА именно как пример удобной реализации команд/данных, для связи "шлюза" и подключаемых на лету исполнителей (плагинов?).
В этом направлении мне интересно только одно, как добиваются того, чтобы удалённые устройства 2 и долее не начинали гнать инфу одновременно? Вот например у меня уже есть контроллер с DS18B20 - 4 шт. В развёрнутом виде на запрос отдать температуру всех датчиков, ответ будет в пол сотни байт (<id типа устройства><id устройства><данные>). Ключь типа $ я не передаю, также как и контрольную сумму (хотя наверное надо сразу допилить). Как то внутрь uart'а не вникал, там есть бит начала, бит окончения передачи, а есть бит готовности к приёму?
ЕСли у вас устройСтва отвечают на запросы, зачем им "гнать инфу" самостоятельно? Если же возможны коллизии, делать проверку по контрольным суммам и передавать через случайный период времени, примерно так же как это реализованов ethernet
как по мне то они должны не орать все вместе, а отвечать на запросы с заданным оператором интервалом.
- Датчику 1: подъем!
- Шлюзу: встал я, че тебе?
- Датчику 1: че_там_у_тя?
- Шлюзу: т=20, д=750!
- Датчику 1: ладно, спи давай.
- Грелке 1: подъем!
- Шлюзу: встал я, че тебе?
- Грелке 1: тут похолодало, давай 20% подбавим
- Шлюзу: понял, добавил.
- Грелке 1: ладно, спи давай.
Потому я и предлагал 2ю частоту на радио для тех кто спит много и не может постоянно висеть в эфире. 2я частота только для сообщения о готовности ответить на первой включившегося датчика.
ЕСли у вас устройСтва отвечают на запросы, зачем им "гнать инфу" самостоятельно? Если же возможны коллизии, делать проверку по контрольным суммам и передавать через случайный период времени, примерно так же как это реализованов ethernet
в езернете не так. Тама комутатор(свич) следит за порядком в эфире. А вот на коаксиале такида, но там пакет короткий относительно скорости. Контроль же колизий лежит уже на 4м уровне TCP|UDР.
кстати комутатор уартов это же модно :) на каждый вход по буферу и передавать на выход по очереди. с выхода транслировать на все входы. Как по мне, то не слишком сложно в реализации.
"в езернете не так. Тама комутатор(свич) следит за порядком в эфире." - "тама" каждое передающее устройство следит не испортились ли его данные, Media Access Control называется, тут примерно этого же можно добиться проверкой контрольных сумм. В свичах коллизии другого рода
"в езернете не так. Тама комутатор(свич) следит за порядком в эфире." - "тама" каждое передающее устройство следит не испортились ли его данные, Media Access Control называется, тут примерно этого же можно добиться проверкой контрольных сумм. В свичах коллизии другого рода
МАС - это как раз то чем оперирует свич для определения направления для пакета чтоб не срать им на всю сеть. Этим он от хаба в основном и отличается. :) МАС только указывает адрес получателя, а все вместе они находятся в одном "домене колизий", что кагбе намекает... Кроме того зачастую на кадрах (L2) контрольной суммы то и нету.
Если мы про TCP (L4), то там передача пакета с контролькой - отсылка подтверждения о доставке - подтверждение подтверждения. UDP - пофих на получение данных.
зачем им "гнать инфу" самостоятельно? Например аварийная ситуация, устройство обязано покричать об этом до очередного штатного опроса, возможен широкополосный опрос, когда на единый запрос все устройства выдают свой ид и статус. Также желательно прямое взаимодействие отдельных МК (если их разведётся сильно много), тогда даже при отказе центрального МК (если вообще такой будет нужен) большая часть сети продолжит работу. Пока на эту тему не придумал ничего иног, кроме как посадинь на шину МК с часами реального времени, который будет таймслоты раздавать всем присутствующим.
То что вы написали про MAC подуровень, относится к LLC подуровню канального уровня. В свиче вообще нет домена коллизий, для этого он и нужен. Почитайте про CSMA/CD чтобы узнать про коллизии и множественный доступ к среде реализованный в Ethernet
olegab Чесно признаюсь читал лет надцать назад, мог и подзабыть. Предлагаю завязать т.к. далее уже не касабельно сабжа.
По сабжу. Комуникации с сервисными девайсами запрос-ответ. С оперативными: АСК(ахтунг!)-запрос-ответ-, если запрос не последовал, опять АСК. Все кроме АСК с проверкой контрольной суммы.
ourlive пишет:
Также желательно прямое взаимодействие отдельных МК (если их разведётся сильно много), тогда даже при отказе центрального МК (если вообще такой будет нужен) большая часть сети продолжит работу.
В тренде темы не согласен. Именно строгая иерархия - залог универсальности. Если девайсы могут общаться еще с кем-то, кроме шлюза и четко предусмотренных для них подчиненных - это надо прописывать в их логику (прошивать), что не согласуется с ролью "плаг&плей". То-есть вся логика взаимодействий только в шлюзе.
Спасибо, кое-что подчерпнул из последней дискуссии..
Непомню кто спрашивал, что мол Получать данные это просто, а вот как потом наладить логику их обработки?
Так на мой взгляд это как раз не вызывает сложностей.. Для этого я и веду речь про модули (плагины) в смысл которых некоторые не врубаются никак. Вот пример:
подключается датчик скажем тот же DS18B20 (на сам датчик можно напаять некий маркер передающий его уникальный id, чтобы найти для него нужный маркер, а можно просто дать пользователю выбрать устройство из списка поддерживаемых) - дальше скачивается плагин для устройства, который содержит в себе библиотеку для работы с протоколом датчика, общается с Arduino так же как это делает к примеру библиотека Firmata (для Processing). Про протокол, контрольные суммы, запрос -ответ, останавливаться не буду, это уже вторично, перейдем к логике.
Подключаемый модуль(плагин) передает в основное приложение (экспортирует) функцию Temp(C\F), которая возвращает текущую температуру в цельсиях или фарингейтах.
Также каждый подключаемый модуль содержит функцию GUI, которая задает внешний вид интерфейса закладки этого модуля в пользовательском интерфейсе.
Соответственно основное приложение переодически опрашивает датчик температуры, вызывая функцию Temp(C) плагина DS18B20, и получаес в ответ нечто вроде "20С" что записывается в файл статистики.
Дальше у нас есть к примеру "Вентилятор" (двигатель через плату управления):
Т.е. плагин вентилятора должен экспортировать функции: Power(1,0) -включение выключение, setSpeed (0-255) - задать скорость вращения, СurrentSpeed() - текущая скорость. И свой графический интерфейс, в котором к примеру будут кнопки +\- т.е. быстрее\медленнее, и ON\OFF которые будут мануально рулить вентилятором.
Т.е. как рулить всем поотдельности вроде ясно, так? А если нам нужно задавать скорость вращения, в зависимости от температуры?
Тогда такая логика должна быть прописана в один из плагинов, лучше исполнительный, т.е. вентилятора.
Тогда дополнительно появится экспортируемая функция, что-то вроде "желаемая температура" - настройки которой активны в интерфейсе, только если в системе зарегистрирован плагин температуры (к примеру проверка по списку имен, мы же знаем какие плагины мы выпускали. или некий универсальный флаг, к примеру TEMP).
Сама логика управления скоростью может быть любой: прямая корреляция, тупо вкл\выкл либо же на основе pid генератора, но общая логика будет такой - запрашиваем функцию temp() нужного плагина (если в системе несколько датчиков - то выпадающий список), полученное значение отправляем на вход функции DesiredTemp() на выходе получаем аргумент для функции setSpeed() - все, система работает.
Соответственно, если нужно задать зависимость, которая не предусмотрена в модуле, или вы подключили какой-то неподдерживаемый датчик - значит надо ждать обновлений модуля от производителя.. все просто. Или - альтернатива - в главном приложении сделать настройщик зависимостей, который будет получать список всех плагинов и экспортируемых функций и позволит произвольно выбрать другую функцию, от которой будет зависить значение передаваемое скажем в SetSpeed().. и задать уже условия <,>,= и т.п. что делать - но это сильно перегрузит интерфейс.
Клаупаций,
Нет, плагины будут бесплатными. Ведь они бесполезны без самого програмно-аппаратного пакета. К тому же, я считаю что если человек однажды заплатил за програмный продукт, то все новые версии, обновления, дополнения и проч. плюшки он должен получать бесплатно до скончания веков.
А почему нет? У всех устройств есть зашитый стандартный алгоритм действия. При включении устройство обращается к центральному МК для обновления инструкций взаимодействия. Если таковые есть, получает их по тому же UART'у, так как в большинстве своём инструкций не может быть много, то хранить это легко можно в одной строковой переменной. А если ведомый МК болшьшой и толстый, потребляющих на вычисление чего то важного много ресурсов (соответственно имеющий сложные алгоритмы), то ему можно и внешнюю флешку подарить, пусть там хранит. И тут уже не нужно перегонять весь обновлённый алгоритм (от стокового), а всего лишь сверить версии и гнать данные только при обновлении версии.
А почему нет? У всех устройств есть зашитый стандартный алгоритм действия. При включении устройство обращается к центральному МК для обновления инструкций взаимодействия. Если таковые есть, получает их по тому же UART'у, так как в большинстве своём инструкций не может быть много, то хранить это легко можно в одной строковой переменной. А если ведомый МК болшьшой и толстый, потребляющих на вычисление чего то важного много ресурсов (соответственно имеющий сложные алгоритмы), то ему можно и внешнюю флешку подарить, пусть там хранит. И тут уже не нужно перегонять весь обновлённый алгоритм (от стокового), а всего лишь сверить версии и гнать данные только при обновлении версии.
стоп стоп... А тут есть не самая здравая, но мысль... Не помню кто развлекался так: 2 контроллера: 1 строго ISP для второго, второй уже рулит свои сенсоры/механизмы. Тогда уже шлюз мог бы и передать с флешки прошиву соответствующую ситуации на нужный ISP, тот вшить соседу. Абы сеть не лаганула. Как вариант?
подключается датчик скажем тот же DS18B20 (на сам датчик можно напаять некий маркер передающий его уникальный id, чтобы найти для него нужный маркер, а можно просто дать пользователю выбрать устройство из списка поддерживаемых) - дальше скачивается плагин для устройства, который содержит в себе библиотеку для работы с протоколом датчика, общается с Arduino так же как это делает к примеру библиотека Firmata (для Processing). Про протокол, контрольные суммы, запрос -ответ, останавливаться не буду, это уже вторично, перейдем к логике.
Подключаемый модуль(плагин) передает в основное приложение (экспортирует) функцию Temp(C\F), которая возвращает текущую температуру в цельсиях или фарингейтах.
Также каждый подключаемый модуль содержит функцию GUI, которая задает внешний вид интерфейса закладки этого модуля в пользовательском интерфейсе.
так... приехали... ЗАБУДЬ про датчик... Есть контроллер с датчиком... у контроллера уже есть средства передачи данных, имя и т.д. Attiny13 по полбакса, 328 по полтора для ком. продукта - котейки... далее их хоть по уарту, хоть по радио, хоть по ИК соединяй. Абы это все понимал шлюз. (шлюз это строго устройство приема-передачи для всего зоопарка). Дальше логику вешай хоть на планшет с андроидом, хоть на ПК и к нему уже клей плагины.
стоп стоп... А тут есть не самая здравая, но мысль...
Не перепрошил, а передал алгоритм работы. Не получится заставить датчик температуры мерить давление, а вот алгоритм измерения температуры поменять можно, например сменить точность, поменять приоритетность. Например вчера МК температуры знал, что его данные очень нужны и слал результаты в сеть каждые 3 секунды без запроса, а сегодня надо только по запросу и с самым низким приоритетом (чтоб не мешал другим).
Не перепрошил, а передал алгоритм работы. Не получится заставить датчик температуры мерить давление, а вот алгоритм измерения температуры поменять можно, например сменить точность, поменять приоритетность. Например вчера МК температуры знал, что его данные очень нужны и слал результаты в сеть каждые 3 секунды без запроса, а сегодня надо только по запросу и с самым низким приоритетом (чтоб не мешал другим).
Это можна забить переменными в ЕЕПРОМ и прописать символы для их смены в командах датчику...
Мы же вроде говорили именно про изменения логики для возможности автономной работы. Например не трогая голову напрямую рулить термостатами, которые висят на другом МК. Могут менятся, и т.д. Тоесть мозг дает команду: держать температуру 22гр и не ипет... А градусник же хз сколько у него доступных термостатов есть и где они, даже если они как то отмаячат, что они живые. Опять же это можна в тот же ЕППРОМ вписать, но все равно это будет вписываться в иерархическую структуру. Т.к. тогда термостатами рулит градусник по ЦУ головы, которая пропишет термостаты именно этому градуснику.
А вот если нас вдруг припрет проверить не открыты ли окна и закрыть если холодно, тогда нада шить :)
Нет, плагины будут бесплатными. Ведь они бесполезны без самого програмно-аппаратного пакета. К тому же, я считаю что если человек однажды заплатил за програмный продукт, то все новые версии, обновления, дополнения и проч. плюшки он должен получать бесплатно до скончания веков.
да это вообще не проблема. ведь сказали же, что плагины будут бесплатными, поэтому от желающих разработчиков отбою не будет
я вообще не улавливаю суть архитектурной концепции хотелок топикстартера - какой-то поток сознания: скачивать плагины с удалённого ресурса, складывать в папку, не перепрошивать флеш, шифровать вдоль и поперёк от взлома(после критических замечаний концепция сменилась на "усё для удобства тупой домохозяйки"), автоматически определять тип подключаемых устройств...
*как можно аппаратно определить что подключен светодиод или кнопка? - не иначе, как плагины скачать бесплатно.
*как можно аппаратно определить что подключен светодиод или кнопка? - не иначе, как плагины скачать бесплатно.
я аж 2 варианта знаю :)
1. Аппаратно: Разъем из 2х пинов. На одном резистор включеный в аналогрид. Далее контроллер, по уровню выставляет второй пин в правильное состояние и следит за изменениями уровня на 1м эсли вдрух заменят. (что он с ним потом делает, это не ко мне).
2. Програмно. Если кнопка подключена через свой личный контроллер, который орет что он кнопка.
Вот teodor4ik правильно написал - как распознать подключенное устройство, что это кнопка или диод. Програмно - т.е. добавлять к каждому устройство маркер, который будет сообщать центральному МК кто он есть.
Но имеется и еще более примитивный путь: дать пользователю самому выбрать подключенное устройство. Дать список поддерживаемых устройств, и он сам выберет из него то, которое он поключил, и порт к которому он его подключил. Вобщем не вижу проблемы в подключении новых устройств.
Если продукт будет успешным, то желающие писать "плахины" найдутся, а если нет, то это и не понадобится. Мне сейчас интересно сделать концепт, для себя прежде всего.
Но имеется и еще более примитивный путь: дать пользователю самому выбрать подключенное устройство. Дать список поддерживаемых устройств, и он сам выберет из него то, которое он поключил, и порт к которому он его подключил. Вобщем не вижу проблемы в подключении новых устройств.
... и ждать что будет, если пользователь включит кнопку, до того как напишет что она уже не лампочка. Х_х
А что будет? ничего не будет. Кнопка не замыкает же цепь в не нажатом положении - так что не будет ничего. Но если эту мысль развивать - то да, теоретически что-то может быть.. хотя лично мне пока сжеть arduino не удалось.. переодически втыкаю что-нибудь не туда, на монтажной плате, но либо просто не работает, либо бывает тухнет диод питания до половины - значит что-то не то, переставил и дальше работает.
можно конечно ставить чипы на все подряд, ради защиты от дурака например.
не представляю как можно поднять нормальный GUI без компьютера. Поэтому конечно вся настройка идет через пользовательское приложение на компьютере.
А затем устройство работает автономно. Но, не забываем что оно на своем борту тоже имеет микрокомпьютер (1.5Ггц 1Гб RAM и 4Гб флешпамяти), помимо cамой Arduino и пары шилдов. Поэтому совсем без компьютеров конечно никак.
Памойму кто-то пробует изобрести веру 3... не понимая как она работает и зачем...
Клапауций пишет:
вот это мне и не понятно - без компьютера это работать будет? если "да", то каким образом?
Моя версия: Например контроллер Дуина тре(ждемсь) или пи по УАРТУ связывается с медиашлюзом(иксби,нрф, уарты или еще чегототам т.д.) например на меге... шлюз только регистрирует исполнителей с строго описанными параметрами, передает/принимает команды и сообщает о изменениях в структуре "сети" контроллеру. На контроллере (с убунтой или мусорником) уже по данным от шлюза строится возможная структура и прописываются связи. Собсно плахины, это и есть "Дрова" для конкретных исполнителей.
На борту у устройства о котором идет речь. т.е. есть некотое устройство (центральный процессор можно назвать) в которое подключается переферия.
Так вот, оно (как я планировал) состоит из Arduino+пари шилдов расширения, для работы с шаговыми двигателями например, которая по ком-порту общается с микрокомпьютером на базе Linux (в том же корпусе). Основное програмное обеспечение находится на флеш-памяти микрокомпьютера, туда же поступают плагины для работы с новыми подключенными устройствами.
А уже этот микрокомпьютер подключается к пользовательскому компьютеру - либо проводом (т.е. через ком-порт) либо удаленно, посредством wifi (wifi модуль встроен в микрокомп) - в таком случае обмен данными возможен либо по ssh, либо в виде веб-интерфеса (развернуть вебсервер на микрокомпьютере ноль проблем).
Так вот, оно (как я планировал) состоит из Arduino+пари шилдов расширения, для работы с шаговыми двигателями например, которая по ком-порту общается с микрокомпьютером на базе Linux (в том же корпусе). Основное програмное обеспечение находится на флеш-памяти микрокомпьютера, туда же поступают плагины для работы с новыми подключенными устройствами.
так НЕ будет... каждый датчик/исполнитель должен иметь свой МК. Например разные моторы могут иметь разные параметры работы при одном сигнале. Задача будет переложить на МК при моторе понять СТАНДАРТНУЮ команду, например задать 3000 оборотов/мин далее МК уже следит за исполнением своими силами. Тоесть главного не волнуют подробности как она будет исполнена. Вот есть же библиотека "серво"... Пишем команду, ищем в библиотеке что с ней делать. А нахуа? Та же библиотека может быть в МК мотора, пусть он ее и обрабатывает. Так ты решишь проблему ограниченности к-ва типов девайсов у Главного. Например послав команду вывести данные на экран соотв. исполнитель уже разбирается какой у него драйвер и экран собс-но, какие там шрифты и т.д. Соответственно тебе не надо прописывать все возможные типы драйверов. Хватит данных от МК исполнителя о к-ве символов на экране..
Спасибо, любопытно.. не слышал до этого. Ну тогда да, что-то в этом роде. Только сама идея беспроводной коммуникации, в данном проекте излишнея, поэтому нет нужды в каждое устройство пихать приемопередатчик и т.п. а Так да, в целом похоже.
Ок, вобщем-то хорошо, например.
Предположим что пинов хватит на все на это.. и они не будут друг-друга перекрывать. А поскольку что-то из этого потребует определенных пинов (с поддержкой шим например) то значит мы эти входы на корпусе сгруппируем и обведем красной линией например. Все 1-wire датчики тоже посадим на 1 пин, а на корпус выведем десять например, и обведем синей линией - что сюда вставлять все что 1-wire. и т.д.
Вобщем все датчики, шилды и т.п. втыкаются в Мегу, в Нано соответсвенно ваша фотоловушка, сервы и 1 радиомодуль - правильно?
Логику вроде вы уже описали сами: опрашивать датчики, по езернету данные отдавать в локалку, по уарт в ПК.
Только непонятно причем тут нано, и связь с ней через радиомодули - она вроде отдельный эелемен и с задачей крутить сервы по сигналу фотодида справится и сама..
Лично я не планирую устраивать мешанину.. посто хочу предусмотреть на будущее. Что с центральным девайсом закончить, и потом заниматься только подключаемыми модулями до конца времен.
Puhlyaviy
Хорошо, давайте попробуем. Вот список датчиков и других устройств которые я подключаю сейчас (одновременно), при тестировании прототипа:
термо датчики 1-wire несколько
датчики влажности и температуры DHT22 несколько
реле - 8шт
модуль из 4 фотодатчиков и 4 лазеров
шаговики с драйверами - 3шт
DC моторы -2шт
электромагнитные клапаны 3шт (считай реле)
газовый счетчик потока
датчики затопления
.... так, я что-то уже должен был понять?
Давайте ещ набросаем список модулей которые планируются на будущее
датчик IR
датчик шума
модуль дозиметров жидкости
модули измерения солесодержания
и еще несколько, вобщем-то однотипных..
Взаимосвязи между всеми этими устройствами конечно не в случайном порядке.. а по определнной схеме, так что они образуют какие-то блоки. Скажем 3 шаговика работают в рамках системы 3-х плоскостного подвеса.
Может это не очень много, но не так уж и мало.
Постараюсь еще раз объяснить зачем нужны плагины:
Допустим человек подключил дозирующую станцию - ему же нужно её настроить, по определенной схеме (т.е. на высоком уровне) - для этого подключается плагин и в интерфейсе появляется окно настроек: в каких пропорциях смешивать жидкости, к какой последовательности и т.п.) но и можно задать взаимосвязи с другими установленными модулями, не как в голову придет конечно, а только с определенными: например зависимость состава раствора от температуры.. если нет подключенного датчика температуры, то поле неактивно.
А например связать с влажностью воздуха нельзя, поскольку это не имеет значения.. вот для формирования такой вот определенной логики поведения и нужны плагины.
Другой пример - газ. в плагине для управления газовым клапаном должны быть настройки осносительно количества газа который нужно прокачать, и некоторые предопределенные опции, например: усилить вентиляцию, на время подачи. Если модуль вентиляции установлен - то эта галочка активна.
Или к примеру увлажнитель воздуха - если в системе установлены датчики влажности и температуры, то в настройках этого модуля активируется возможность установить зависимость.. а если нет, то остается только запуск по таймеру.
Вот, я перечислил реальные устройства, модули и их использование.. И вроде только убедился в необходимости модульной системы, т.е. плагинов.
гыыы и это все у вас будет висеть на одном МК? тоесть датчики и моторы по всему дому стоят и толстые кабеля тащатся в шкаф в подвале в котором и стоит МК? немецкие фантастические фильмы вас до добра не доведут.
Блин уже в пятый раз повторяю речь не про умный дом! Все перечисленные модули располагаются в тесном пространстве несколько кв. метров. Управляющее устройство там же, или за стенкой.
Блин уже в пятый раз повторяю речь не про умный дом! Все перечисленные модули располагаются в тесном пространстве несколько кв. метров. Управляющее устройство там же, или за стенкой.
тоесть это производственая линия? которую неадекватные работники будут переделывать каждое утро втыкая новые датчики?
я понял это такой новый сюжет порнофильма с участием МК?
вы мне напомнили тут был один.. он все хотел что бы ему помогли сделать автоматическую лампочку в туалете для кота которого они забрали с деревни, и который боялся ходить в туалет в темноте.. потом выяснилось что запитывать нужно от изменяющегося напряжения 12-14 вольт и нужно еще контролировать стеклоподьемники и подогрев сиденья делать :)
У вас куча интерфейсов, но рулить всем будет всё равно ПК. Так не выносите вообще никакую логику за его пределы. Сделайте всю переферию чисто исполнительной. Делать её активной-интеллектуальной без широкого доступа к данным от других устройств бессмысленно. Берите любой микроПК с любой осью с кучей различных интерфейсов, добавьте нужное количество платок расширения и варите всю кашу в нём.
Берите любой микроПК с любой осью с кучей различных интерфейсов, добавьте нужное количество платок расширения и варите всю кашу в нём.
каша в ПК.. удобно... заодно утилизируем тепло от процесора для приготовления еды.. но вижу проблему с помывкой корпуса после приготовления в нем каши :)
каша в ПК. удобно...
У мя дома системник маслонаполненный, можно и картошку пожарить, если найти древнюю, но мощную видяху, да БП на послабее заменить.. А так даже разогреть не выйдет.
С производственно линией близко.. Но зачем каждое утро?
Например раз в полгода или раз в два года. Да и не менять. а добавлять. Например в минимальной конфигурации достаточно лампочки и кипятильника, но все не очень автоматизированно - потому что нет датчиков.. хотя по таймеру тоже можно настроить, на глаз что называется.. Потом люди подкопили денег, расширились - и докупили датчики и линию дозировки реактивов - подключили и оно встроилось в общую систему управления. через месяц-другой добавили еще какое-то улучшение на пути к автономности и автоматизации.
ourlive
Ну вобщем тоже подумываю вынести логику на управление миниPC, а он будет уже управлять адруино (или подобным) контроллером, отдавая команды на исполнение. Подобно тому как например Processing работает с Arduino через библиотеку firmata. только смущает что видимо библиотеки для работы с интерфейсами тогда придется переписывать..
А я таки и говорю как раз про плаг энд плей: воткнул, скачались драйвера сами собой и все работает.. ничего пользователю делать не нужно.. у всех есть постоянный выход ви интренет ...
УТОПИЯ
для приверки - дайте десяти домохозяйкам десять принтеров и попросите их подключить к компьютерам. драйвера есть на сайте производителя. то, что профессионал сделает за 20 сек, обыватель не сделает никогда
я утерял смысл хотелок топикстартера, но краем мосга улавливаю, что вся суета исключительно для автоматизации регулярного развода клиента на бапки.
я утерял смысл хотелок топикстартера, но краем мосга улавливаю, что вся суета исключительно для автоматизации регулярного развода клиента на бапки.
явка провалена :)
Пох оду (ошибку заметил, исправлять не стал) думается мне что автор слегонца сам не понимает чего и зачем хочет... Я вот например вижу проблему в том, что сам по себе факт подключения миллиона разных датчиков на разные и-ф не вопрос. Вопрос - А как они взаимодействуют? Я, например никак не могу подогнать логику работы самогонного аппарата, где входных параметров всего 8-11 и 4 управляемых органа (подача воды в пароген и холодильник, моща насоса, моща тенов). Я просто не могу вычислить формулу, возможно еще параметров не хватает. Или, вариант, драйвер обменника валют... вроде из разницы только собсно сегменты... А у них разные напряжения и токи. Писец универсальности...
Я это к чему... В общем ВСЕ датчики и органы можна свести к единому интерфейсу (хоть бы и на безе Nrf24l01) с единой структурой команд и данных(дада автор, у КАЖДОГО по МК, хоть бы и тини13а). Ввести им нечто вроде мак адреса у РС тип-модель-номер. Протокол определения. Например у базы 3 приемника на разных частотах 1 для ловли бродкастов от неопознаных девайсов и настройки их в сети, 2 - для приема от неуправляемых датчиков. 3 - для двустороннего общения. Определится с протоколами передачи комманд на исполнение этим устройствам и данных от них(меня вот NMEA 1831 пленил, просто и со вкусом). Прописать на исполнителях отработку ими принятых комманд.
НО ХРЕН ты заставишь МК рулить этим всем. Дальше либо микро РС с хитрым и тяжелым софтом и дуиной на компорту (шлюз для получения/отправки команд), либо дуину ТРЕ ждать, там линух на борту.
Кистати я вот помню тут недавно ктото хотел было прошивать контролленры по радио :))) Так и не убедили что это глупо т.к. смысла шить нету. Максимум парамерты в ЕППРОМе поменять.
Автору видимо нужна возможность выполнять любой код без перепрошивки основного скетча.
Т.е. для нового датчика компилируется некий модуль, назовем его "драйвером", заливается на сд карту, "основной скетч" его находит, подгружает и добавляет вызов в конец своего основного цикла.
С системой команд микроконтроллеров почти не знаком, но если есть возможность писать в "программное адресное" пространство, то это вполне реализуемо
З.ы.
Вроде реализуемо. Нужно писать свой загрузчик, который должен еще и перелинковывать(корректировать адреса переменных и переходов) подгружаемый код. Тут подробнее:
http://microsin.net/programming/AVR/avr109-self-programming.html
плахины, плахины то при каких делах?
категорически подозреваю, что плахины должны быть очень платные.
NMEA для самогонного аппарата? Неплохо...
NMEA для самогонного аппарата? Неплохо...
плагин "самогон" - 15$
плагин "виски" - 60$
"вотка-палёнка" - бесплатно за счёт производителя плахина.
NMEA для самогонного аппарата? Неплохо...
а как его в лесу потом искать иначе? :)
Я чуть о другом. Я о его сути "$"+тип команды(исполнители)+параметры+контролька. Если собрать каталог стандарных девайсов то например "$SET, D, LGT, A, 001, I, 127,C, 2345" - контрольнику света 001 установить интенсивность 50% и проверка, вся ли строка пришла. Дальше шлюзу плевать на то как контрольник этого добьется. Надо только дождаться подтверждения или его отсутствие, например "$HOME, D, LGT, A, 001, I, 127, C, 2349".
Может товарищу Веру показать по секрету?
NMEA не только навигационные данные передаёт, там вроде как любые типы датчиков к стандартным протоколам приведены, вот только разбираться в этим всем.. Не говоря уж об избыточности. Хотя если у вас завалялся нав комп из какого нибудь танкера, то с самогонным аппаратом он уж точно справится, а интерфейсов хватит на целый нинно-водочный цех.
Это не я предложил плагин спутниковой навигации к самогонному аппарату прикрутить... Я его сюда прикрутил как пример очень геморной связи датчиков - исполнителей, которые не особо слепишь, кроме как с помощью ПИД-ов. А НМЕА именно как пример удобной реализации команд/данных, для связи "шлюза" и подключаемых на лету исполнителей (плагинов?).
В этом направлении мне интересно только одно, как добиваются того, чтобы удалённые устройства 2 и долее не начинали гнать инфу одновременно? Вот например у меня уже есть контроллер с DS18B20 - 4 шт. В развёрнутом виде на запрос отдать температуру всех датчиков, ответ будет в пол сотни байт (<id типа устройства><id устройства><данные>). Ключь типа $ я не передаю, также как и контрольную сумму (хотя наверное надо сразу допилить). Как то внутрь uart'а не вникал, там есть бит начала, бит окончения передачи, а есть бит готовности к приёму?
ЕСли у вас устройСтва отвечают на запросы, зачем им "гнать инфу" самостоятельно? Если же возможны коллизии, делать проверку по контрольным суммам и передавать через случайный период времени, примерно так же как это реализованов ethernet
как по мне то они должны не орать все вместе, а отвечать на запросы с заданным оператором интервалом.
- Датчику 1: подъем!
- Шлюзу: встал я, че тебе?
- Датчику 1: че_там_у_тя?
- Шлюзу: т=20, д=750!
- Датчику 1: ладно, спи давай.
- Грелке 1: подъем!
- Шлюзу: встал я, че тебе?
- Грелке 1: тут похолодало, давай 20% подбавим
- Шлюзу: понял, добавил.
- Грелке 1: ладно, спи давай.
Потому я и предлагал 2ю частоту на радио для тех кто спит много и не может постоянно висеть в эфире. 2я частота только для сообщения о готовности ответить на первой включившегося датчика.
ЕСли у вас устройСтва отвечают на запросы, зачем им "гнать инфу" самостоятельно? Если же возможны коллизии, делать проверку по контрольным суммам и передавать через случайный период времени, примерно так же как это реализованов ethernet
в езернете не так. Тама комутатор(свич) следит за порядком в эфире. А вот на коаксиале такида, но там пакет короткий относительно скорости. Контроль же колизий лежит уже на 4м уровне TCP|UDР.
кстати комутатор уартов это же модно :) на каждый вход по буферу и передавать на выход по очереди. с выхода транслировать на все входы. Как по мне, то не слишком сложно в реализации.
"в езернете не так. Тама комутатор(свич) следит за порядком в эфире." - "тама" каждое передающее устройство следит не испортились ли его данные, Media Access Control называется, тут примерно этого же можно добиться проверкой контрольных сумм. В свичах коллизии другого рода
"в езернете не так. Тама комутатор(свич) следит за порядком в эфире." - "тама" каждое передающее устройство следит не испортились ли его данные, Media Access Control называется, тут примерно этого же можно добиться проверкой контрольных сумм. В свичах коллизии другого рода
МАС - это как раз то чем оперирует свич для определения направления для пакета чтоб не срать им на всю сеть. Этим он от хаба в основном и отличается. :) МАС только указывает адрес получателя, а все вместе они находятся в одном "домене колизий", что кагбе намекает... Кроме того зачастую на кадрах (L2) контрольной суммы то и нету.
Если мы про TCP (L4), то там передача пакета с контролькой - отсылка подтверждения о доставке - подтверждение подтверждения. UDP - пофих на получение данных.
зачем им "гнать инфу" самостоятельно? Например аварийная ситуация, устройство обязано покричать об этом до очередного штатного опроса, возможен широкополосный опрос, когда на единый запрос все устройства выдают свой ид и статус. Также желательно прямое взаимодействие отдельных МК (если их разведётся сильно много), тогда даже при отказе центрального МК (если вообще такой будет нужен) большая часть сети продолжит работу. Пока на эту тему не придумал ничего иног, кроме как посадинь на шину МК с часами реального времени, который будет таймслоты раздавать всем присутствующим.
То что вы написали про MAC подуровень, относится к LLC подуровню канального уровня. В свиче вообще нет домена коллизий, для этого он и нужен. Почитайте про CSMA/CD чтобы узнать про коллизии и множественный доступ к среде реализованный в Ethernet
В тренде темы не согласен. Именно строгая иерархия - залог универсальности. Если девайсы могут общаться еще с кем-то, кроме шлюза и четко предусмотренных для них подчиненных - это надо прописывать в их логику (прошивать), что не согласуется с ролью "плаг&плей". То-есть вся логика взаимодействий только в шлюзе.
Спасибо, кое-что подчерпнул из последней дискуссии..
Непомню кто спрашивал, что мол Получать данные это просто, а вот как потом наладить логику их обработки?
Так на мой взгляд это как раз не вызывает сложностей.. Для этого я и веду речь про модули (плагины) в смысл которых некоторые не врубаются никак. Вот пример:
подключается датчик скажем тот же DS18B20 (на сам датчик можно напаять некий маркер передающий его уникальный id, чтобы найти для него нужный маркер, а можно просто дать пользователю выбрать устройство из списка поддерживаемых) - дальше скачивается плагин для устройства, который содержит в себе библиотеку для работы с протоколом датчика, общается с Arduino так же как это делает к примеру библиотека Firmata (для Processing). Про протокол, контрольные суммы, запрос -ответ, останавливаться не буду, это уже вторично, перейдем к логике.
Подключаемый модуль(плагин) передает в основное приложение (экспортирует) функцию Temp(C\F), которая возвращает текущую температуру в цельсиях или фарингейтах.
Также каждый подключаемый модуль содержит функцию GUI, которая задает внешний вид интерфейса закладки этого модуля в пользовательском интерфейсе.
Соответственно основное приложение переодически опрашивает датчик температуры, вызывая функцию Temp(C) плагина DS18B20, и получаес в ответ нечто вроде "20С" что записывается в файл статистики.
Дальше у нас есть к примеру "Вентилятор" (двигатель через плату управления):
Т.е. плагин вентилятора должен экспортировать функции: Power(1,0) -включение выключение, setSpeed (0-255) - задать скорость вращения, СurrentSpeed() - текущая скорость. И свой графический интерфейс, в котором к примеру будут кнопки +\- т.е. быстрее\медленнее, и ON\OFF которые будут мануально рулить вентилятором.
Т.е. как рулить всем поотдельности вроде ясно, так? А если нам нужно задавать скорость вращения, в зависимости от температуры?
Тогда такая логика должна быть прописана в один из плагинов, лучше исполнительный, т.е. вентилятора.
Тогда дополнительно появится экспортируемая функция, что-то вроде "желаемая температура" - настройки которой активны в интерфейсе, только если в системе зарегистрирован плагин температуры (к примеру проверка по списку имен, мы же знаем какие плагины мы выпускали. или некий универсальный флаг, к примеру TEMP).
Сама логика управления скоростью может быть любой: прямая корреляция, тупо вкл\выкл либо же на основе pid генератора, но общая логика будет такой - запрашиваем функцию temp() нужного плагина (если в системе несколько датчиков - то выпадающий список), полученное значение отправляем на вход функции DesiredTemp() на выходе получаем аргумент для функции setSpeed() - все, система работает.
Соответственно, если нужно задать зависимость, которая не предусмотрена в модуле, или вы подключили какой-то неподдерживаемый датчик - значит надо ждать обновлений модуля от производителя.. все просто. Или - альтернатива - в главном приложении сделать настройщик зависимостей, который будет получать список всех плагинов и экспортируемых функций и позволит произвольно выбрать другую функцию, от которой будет зависить значение передаваемое скажем в SetSpeed().. и задать уже условия <,>,= и т.п. что делать - но это сильно перегрузит интерфейс.
Клаупаций,
Нет, плагины будут бесплатными. Ведь они бесполезны без самого програмно-аппаратного пакета. К тому же, я считаю что если человек однажды заплатил за програмный продукт, то все новые версии, обновления, дополнения и проч. плюшки он должен получать бесплатно до скончания веков.
В тренде темы
А почему нет? У всех устройств есть зашитый стандартный алгоритм действия. При включении устройство обращается к центральному МК для обновления инструкций взаимодействия. Если таковые есть, получает их по тому же UART'у, так как в большинстве своём инструкций не может быть много, то хранить это легко можно в одной строковой переменной. А если ведомый МК болшьшой и толстый, потребляющих на вычисление чего то важного много ресурсов (соответственно имеющий сложные алгоритмы), то ему можно и внешнюю флешку подарить, пусть там хранит. И тут уже не нужно перегонять весь обновлённый алгоритм (от стокового), а всего лишь сверить версии и гнать данные только при обновлении версии.
В тренде темы
А почему нет? У всех устройств есть зашитый стандартный алгоритм действия. При включении устройство обращается к центральному МК для обновления инструкций взаимодействия. Если таковые есть, получает их по тому же UART'у, так как в большинстве своём инструкций не может быть много, то хранить это легко можно в одной строковой переменной. А если ведомый МК болшьшой и толстый, потребляющих на вычисление чего то важного много ресурсов (соответственно имеющий сложные алгоритмы), то ему можно и внешнюю флешку подарить, пусть там хранит. И тут уже не нужно перегонять весь обновлённый алгоритм (от стокового), а всего лишь сверить версии и гнать данные только при обновлении версии.
стоп стоп... А тут есть не самая здравая, но мысль... Не помню кто развлекался так: 2 контроллера: 1 строго ISP для второго, второй уже рулит свои сенсоры/механизмы. Тогда уже шлюз мог бы и передать с флешки прошиву соответствующую ситуации на нужный ISP, тот вшить соседу. Абы сеть не лаганула. Как вариант?
подключается датчик скажем тот же DS18B20 (на сам датчик можно напаять некий маркер передающий его уникальный id, чтобы найти для него нужный маркер, а можно просто дать пользователю выбрать устройство из списка поддерживаемых) - дальше скачивается плагин для устройства, который содержит в себе библиотеку для работы с протоколом датчика, общается с Arduino так же как это делает к примеру библиотека Firmata (для Processing). Про протокол, контрольные суммы, запрос -ответ, останавливаться не буду, это уже вторично, перейдем к логике.
Подключаемый модуль(плагин) передает в основное приложение (экспортирует) функцию Temp(C\F), которая возвращает текущую температуру в цельсиях или фарингейтах.
Также каждый подключаемый модуль содержит функцию GUI, которая задает внешний вид интерфейса закладки этого модуля в пользовательском интерфейсе.
так... приехали... ЗАБУДЬ про датчик... Есть контроллер с датчиком... у контроллера уже есть средства передачи данных, имя и т.д. Attiny13 по полбакса, 328 по полтора для ком. продукта - котейки... далее их хоть по уарту, хоть по радио, хоть по ИК соединяй. Абы это все понимал шлюз. (шлюз это строго устройство приема-передачи для всего зоопарка). Дальше логику вешай хоть на планшет с андроидом, хоть на ПК и к нему уже клей плагины.
стоп стоп... А тут есть не самая здравая, но мысль...
Не перепрошил, а передал алгоритм работы. Не получится заставить датчик температуры мерить давление, а вот алгоритм измерения температуры поменять можно, например сменить точность, поменять приоритетность. Например вчера МК температуры знал, что его данные очень нужны и слал результаты в сеть каждые 3 секунды без запроса, а сегодня надо только по запросу и с самым низким приоритетом (чтоб не мешал другим).
Не перепрошил, а передал алгоритм работы. Не получится заставить датчик температуры мерить давление, а вот алгоритм измерения температуры поменять можно, например сменить точность, поменять приоритетность. Например вчера МК температуры знал, что его данные очень нужны и слал результаты в сеть каждые 3 секунды без запроса, а сегодня надо только по запросу и с самым низким приоритетом (чтоб не мешал другим).
Это можна забить переменными в ЕЕПРОМ и прописать символы для их смены в командах датчику...
Мы же вроде говорили именно про изменения логики для возможности автономной работы. Например не трогая голову напрямую рулить термостатами, которые висят на другом МК. Могут менятся, и т.д. Тоесть мозг дает команду: держать температуру 22гр и не ипет... А градусник же хз сколько у него доступных термостатов есть и где они, даже если они как то отмаячат, что они живые. Опять же это можна в тот же ЕППРОМ вписать, но все равно это будет вписываться в иерархическую структуру. Т.к. тогда термостатами рулит градусник по ЦУ головы, которая пропишет термостаты именно этому градуснику.
А вот если нас вдруг припрет проверить не открыты ли окна и закрыть если холодно, тогда нада шить :)
Клаупаций,
Нет, плагины будут бесплатными. Ведь они бесполезны без самого програмно-аппаратного пакета. К тому же, я считаю что если человек однажды заплатил за програмный продукт, то все новые версии, обновления, дополнения и проч. плюшки он должен получать бесплатно до скончания веков.
дело за малым - найти того, кто напишет плахины.
дело за малым - найти того, кто напишет плахины.
да это вообще не проблема. ведь сказали же, что плагины будут бесплатными, поэтому от желающих разработчиков отбою не будет
да это вообще не проблема. ведь сказали же, что плагины будут бесплатными, поэтому от желающих разработчиков отбою не будет
я вообще не улавливаю суть архитектурной концепции хотелок топикстартера - какой-то поток сознания: скачивать плагины с удалённого ресурса, складывать в папку, не перепрошивать флеш, шифровать вдоль и поперёк от взлома(после критических замечаний концепция сменилась на "усё для удобства тупой домохозяйки"), автоматически определять тип подключаемых устройств...
*как можно аппаратно определить что подключен светодиод или кнопка? - не иначе, как плагины скачать бесплатно.
*как можно аппаратно определить что подключен светодиод или кнопка? - не иначе, как плагины скачать бесплатно.
я аж 2 варианта знаю :)
1. Аппаратно: Разъем из 2х пинов. На одном резистор включеный в аналогрид. Далее контроллер, по уровню выставляет второй пин в правильное состояние и следит за изменениями уровня на 1м эсли вдрух заменят. (что он с ним потом делает, это не ко мне).
2. Програмно. Если кнопка подключена через свой личный контроллер, который орет что он кнопка.
Клапауций
Вот teodor4ik правильно написал - как распознать подключенное устройство, что это кнопка или диод. Програмно - т.е. добавлять к каждому устройство маркер, который будет сообщать центральному МК кто он есть.
Но имеется и еще более примитивный путь: дать пользователю самому выбрать подключенное устройство. Дать список поддерживаемых устройств, и он сам выберет из него то, которое он поключил, и порт к которому он его подключил. Вобщем не вижу проблемы в подключении новых устройств.
Если продукт будет успешным, то желающие писать "плахины" найдутся, а если нет, то это и не понадобится. Мне сейчас интересно сделать концепт, для себя прежде всего.
Но имеется и еще более примитивный путь: дать пользователю самому выбрать подключенное устройство. Дать список поддерживаемых устройств, и он сам выберет из него то, которое он поключил, и порт к которому он его подключил. Вобщем не вижу проблемы в подключении новых устройств.
... и ждать что будет, если пользователь включит кнопку, до того как напишет что она уже не лампочка. Х_х
Мне сейчас интересно сделать концепт, для себя прежде всего.
вот это мне и не понятно - без компьютера это работать будет? если "да", то каким образом?
А что будет? ничего не будет. Кнопка не замыкает же цепь в не нажатом положении - так что не будет ничего. Но если эту мысль развивать - то да, теоретически что-то может быть.. хотя лично мне пока сжеть arduino не удалось.. переодически втыкаю что-нибудь не туда, на монтажной плате, но либо просто не работает, либо бывает тухнет диод питания до половины - значит что-то не то, переставил и дальше работает.
можно конечно ставить чипы на все подряд, ради защиты от дурака например.
Клапауций
не представляю как можно поднять нормальный GUI без компьютера. Поэтому конечно вся настройка идет через пользовательское приложение на компьютере.
А затем устройство работает автономно. Но, не забываем что оно на своем борту тоже имеет микрокомпьютер (1.5Ггц 1Гб RAM и 4Гб флешпамяти), помимо cамой Arduino и пары шилдов. Поэтому совсем без компьютеров конечно никак.
бред.
бред.
Памойму кто-то пробует изобрести веру 3... не понимая как она работает и зачем...
вот это мне и не понятно - без компьютера это работать будет? если "да", то каким образом?
Моя версия: Например контроллер Дуина тре(ждемсь) или пи по УАРТУ связывается с медиашлюзом(иксби,нрф, уарты или еще чегототам т.д.) например на меге... шлюз только регистрирует исполнителей с строго описанными параметрами, передает/принимает команды и сообщает о изменениях в структуре "сети" контроллеру. На контроллере (с убунтой или мусорником) уже по данным от шлюза строится возможная структура и прописываются связи. Собсно плахины, это и есть "Дрова" для конкретных исполнителей.
Но, не забываем что оно на своем борту тоже имеет микрокомпьютер (1.5Ггц 1Гб RAM и 4Гб флешпамяти
Походу я этот момент упустил. Кто и что имеет на борту? Огласите список?
teodor4ik
Что еще за вера-3?
На борту у устройства о котором идет речь. т.е. есть некотое устройство (центральный процессор можно назвать) в которое подключается переферия.
Так вот, оно (как я планировал) состоит из Arduino+пари шилдов расширения, для работы с шаговыми двигателями например, которая по ком-порту общается с микрокомпьютером на базе Linux (в том же корпусе). Основное програмное обеспечение находится на флеш-памяти микрокомпьютера, туда же поступают плагины для работы с новыми подключенными устройствами.
А уже этот микрокомпьютер подключается к пользовательскому компьютеру - либо проводом (т.е. через ком-порт) либо удаленно, посредством wifi (wifi модуль встроен в микрокомп) - в таком случае обмен данными возможен либо по ssh, либо в виде веб-интерфеса (развернуть вебсервер на микрокомпьютере ноль проблем).
http://www.z-wave.ru/obzory/vera3-pervoe-znakomstvo.html :)
teodor4ik
Так вот, оно (как я планировал) состоит из Arduino+пари шилдов расширения, для работы с шаговыми двигателями например, которая по ком-порту общается с микрокомпьютером на базе Linux (в том же корпусе). Основное програмное обеспечение находится на флеш-памяти микрокомпьютера, туда же поступают плагины для работы с новыми подключенными устройствами.
так НЕ будет... каждый датчик/исполнитель должен иметь свой МК. Например разные моторы могут иметь разные параметры работы при одном сигнале. Задача будет переложить на МК при моторе понять СТАНДАРТНУЮ команду, например задать 3000 оборотов/мин далее МК уже следит за исполнением своими силами. Тоесть главного не волнуют подробности как она будет исполнена. Вот есть же библиотека "серво"... Пишем команду, ищем в библиотеке что с ней делать. А нахуа? Та же библиотека может быть в МК мотора, пусть он ее и обрабатывает. Так ты решишь проблему ограниченности к-ва типов девайсов у Главного. Например послав команду вывести данные на экран соотв. исполнитель уже разбирается какой у него драйвер и экран собс-но, какие там шрифты и т.д. Соответственно тебе не надо прописывать все возможные типы драйверов. Хватит данных от МК исполнителя о к-ве символов на экране..
teodor4ik
Спасибо, любопытно.. не слышал до этого. Ну тогда да, что-то в этом роде. Только сама идея беспроводной коммуникации, в данном проекте излишнея, поэтому нет нужды в каждое устройство пихать приемопередатчик и т.п. а Так да, в целом похоже.