Умный Дом?

[YurkaM]

Прохладненько, однако у вас в комнате

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[YurkaM]

Вот здесь http://www.insyte.ru/powerdriveabout/ можно подсмотреть концепцию построения для тех, кто хочет делать без центрального хоста.

Неплохая мысль: хост используется только чтобы запрограммировать все оконечные устройства. Причем каждое обладает минимальным интеллектом, но с возможностью настройки типа "включиться, если [условие1] или [условие2] или ..."

Вот ещё интересно почитать (на русском) их инструкции http://insyte.ru/downloads/Manual_LanDrive_Config.pdf

и формат команд http://insyte.ru/downloads/Modbus_formats_LanDrive.pdf на вариант по витой паре (Modbus)

Да, а в варианте по витой паре они всё-таки применяют главный контроллер...

Изменено 4 октября, 2007 пользователем YurkaM

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[Sergei_Kos]

Прохладненько, однако у вас в комнате

Там на фото видно что к плате идёт два провода, просто датчики температуры не подключены вот контроллер и выдаёт "-0.0" Кстати это уже давно исправлено, теперь он пишет 'error'.

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[DJ Димон]

Без хоста это как то не серъёзно.

[Lexi]

Народ, давай те что собирать.

К примеру связь через 220В, хост и 1 выключатель. Хост естественно мастер, исполнители (или терминалы, пусть так назавем - слэйв). Лично для меня сча задача, как слэв подпитать от 220, габариты имеют место

[ЛЕВША]

какое напряжение и ток?

[pivasik]

2Lexi: давай начнем с малого - спроектируй и разведи устройство по управлению светом. Заложись на возможность добавить туда какой-нибудь интерфейс для связи. Лучше, если можно будет доабвить произвольно выбранный через переходную схему может даже. Таже фигня и для питания, если такое возможно.

Вот потом можно будет и собрать девайс.

Может кто возьмет на себя ответственность по другим устройствам?

Изменено 8 октября, 2007 пользователем pivasik

[Sergei_Kos]

Я тут вкратце набросал что умеет мой девайс (см пост #104). Если кому интересно можно и обсудить это. Архив прилагается:

system.rar

[Lexi]

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

[-=gga=-]

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

Вот тока я не знаю, у кого хватит возможностей его сделать... Дбровольцы есть?

[Lexi]

Для этого разработчики объеденяют усилия и договариваться. Давайте арвщики, делайте хост. Я на пике слелаю исполняющее устройсто, управление освещением на 3 "зоны". Управление люстрой )). Адрес 0x00h, опрос-0x00h или задача 0x01h, номера зон:1-ая зона 0x00h, 2-0x01h и третья 0x02h. команды: 0x00h - тушим, 0x01h - включаем. Вот синтаксис запрос [адрес][опрос][зона], ждем ответа [адрес][зона][состояние]. Вот синтаксис камнда [адрес][зона][состояние], ждем ответа [адрес][зона][состояние]. У меня будет 2 реле 1 кнопка. Хост должен опрашивать постоянно все адреса, особенно всякие датчики и кнопки, т.е. элементы управления. По их изменеию давать команду на реле включить или выключить - это в моём случае. Как понимаете все наращиваеться по адресам. Только придумывай как и что это дело описать. Какое правило общения будет в сети (по 220, по 380, по 10кВ шутка). Суть в том что сдесь не важно как подавать сигнал, а важно то, что в нем идет.

[YurkaM]

Вот синтаксис запрос [адрес][опрос][зона]

Вот синтаксис камнда [адрес][зона][состояние]

допустим принята посылка : [0x01][0x01][0x01].

Что это:

- устройству с адресом 0x01 в зоне 0x01 сделать команду 0x01

или устройству с адресом 0x01 запрос зоны 0x01 ???

Как-то надо наверно тщательнее продумпать это дело....

[YurkaM]

может вот так сделать. Чуть длиннее, зато универсальней. Пусть в пакете будет всегда 5 байтов:

[адрес кому][адрес от кого][запрос/команда/ответ/...][зона][параметр]

Здесь зона может не только указывать реально зону, а быть просто внутренним адресом, регистром. Параметр может означать разное в зависимости от конкретного назначения устройства и данной зоны, т.е это может быть просто 1-вкл/0-выкл. или 0...255 если это яркость или время зажигания и т.д.

"Адрес кому" = 0x00 пусть означает "всем". 0x01 - Хость. 0x02...0xFF конечные устройства. И кстати остаётся лазейка для работы без хоста...

Третий байт оставляем как было, т.е 0x00-запрос, 0x01- команда. Дальше может ещё чего понадобиться, допустим 0x02 - ответ, 0xAA - инициализация и т.п.

Изменено 9 октября, 2007 пользователем YurkaM

[YurkaM]

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

[Migray]

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

Температура, смотря с какой точностью, но тоже в байт может не поместиться.

Да малоличем еще оперировать придется.

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

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

И формат данных внутри пакета будет обуждаться при более детальной разработке конкретного устройства.

В таком случае, если заголовок-окончание для всех пакетов одинаковые, любое устройство читает заголовок, смотрит мое/чужое. Мое - берет, чужое - отсчитывает нужное число байт.

А блок данных для конкретного устройства будет именно него, никак не затрагивая все остальное.

Сейчас рассмотреть все системы "умного дома" до мелочей мы не в состоянии, переругаемся и все.

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

Без контрольной суммы тоже не хочется, дом всетаки, на жизнь хозяина влияет.

Персоналка или что другое - опять "гайка М3".

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

[YurkaM]

Персоналка или что другое - опять "гайка М3".

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

Да причем здесь гайка? Я говорю не о реализации, а о способе достичь её! Именно не заморачиваясь чего там будет в конце концов в качестве хоста. Комп удобен на этапе наладки и настройки.

[pivasik]

1. В сети с несколькими каскадами как будет адресоваться узел? Например, это может быть 00.01.04.01.FF, где FF - маркер широковещательного пакета.

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

3. Будет ли конечное устройство предоставлять сведения о себе по запросу? Например, после подключения корневой контроллер может запросить Human readable имя устройства ("Управлятор люстры на 5 секций") или назначить ему новое.

4. Будет ли, и если будет то как уведомляться контроллер верхнего уровня уведомляться об ошибках? Например, при посылке контроллером подсети 00.01 в подсеть 04.01 узлу 05, обнаружилось, что подсеть 01 недоступна - как уведомлять об ошибке?

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

[Sergei_Kos]

Узел виден для хоста в виде набора регистров, все регистры могут работать как на запись так и на чтение. 1 - код устройства. 2 - включено или выключено. 3 - яркость (если она регулируется). 4 - освещённость (если она измеряется этим устройством). 5,6 - значение с первого датчика температуры. 6,7 - значение со второго датчика температуры. 8,9 - принятый код по RC5. 10 - код нажатой кнопки (если это клавиатура). 11 - регистр состояния, в этом регистре выставляются биты в зависимости от произошедших событий и сбрасываются только центральным хостом после прочтения нужных регистров.

[YurkaM]

pivasik, Да вы с ума сошли! Нахрена такие сложности?? Какие каскады? Какие подсети? Вы такого монстра до ума не скоро доведёте, если вообще доведёте!!

2 После подключения нового устройства ручками прописываем его в хосте и всё!

3 Ненадо никакого имени. Просто предусмотреть возможность установки адреса на каждом девайсе. Ну как максимум можно прописывать жестко ID в каждый девайс на этапе прошивки мозгов. Если хочется красивые имена типа "Управлятор люстры на 5 секций", это можн вбивать уже в хосте, например так:

Изменено 9 октября, 2007 пользователем YurkaM

[YurkaM]

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

И формат данных внутри пакета будет обуждаться при более детальной разработке конкретного устройства.

В таком случае, если заголовок-окончание для всех пакетов одинаковые, любое устройство читает заголовок, смотрит мое/чужое. Мое - берет, чужое - отсчитывает нужное число байт.

А блок данных для конкретного устройства будет именно него, никак не затрагивая все остальное.

Согласен. Тогда нужно уточнить. Мысль такая. В каждом пакете обязательными будут первые три байта, а за ними блок данных:

Вопрос: в какое место поставить [длина пакета]? Или это будет только длина блока данных?

Варианты:

1) [кому][от кого][длина пакета]<блок данных>

2) [кому][от кого][длина блока данных]<блок данных>

3) [длина пакета][кому][от кого]<блок данных>

Вариант, когда первым идет адрес назначения удобнее для обработки приемником (ИМХО). Когда чужое, то просто пропускаем этот пакет и ждём следующий.

Изменено 9 октября, 2007 пользователем YurkaM

[ВВЛ]

Извините за вклин.

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

[Migray]

Согласен. Тогда нужно уточнить. Мысль такая. В каждом пакете обязательными будут первые три байта, а за ними блок данных:

Вопрос: в какое место поставить [длина пакета]? Или это будет только длина блока данных?

Варианты:

1) [кому][от кого][длина пакета]<блок данных>

2) [кому][от кого][длина блока данных]<блок данных>

3) [длина пакета][кому][от кого]<блок данных>

Вариант, когда первым идет адрес назначения удобнее для обработки приемником (ИМХО). Когда чужое, то просто пропускаем этот пакет и ждём следующий.

[кому][от кого][длина оставшегося пакета]<блок данных>[контрольная сумма]

длина оставшегося пакета - это блок данных и контрольной суммы

Такое число удобно для простых и медленных процов.

Проц уже знает, что блок например не для него, записывает его оставшийся размер в переменную и в каждом прерывании от UARTa просто ее уменьшает. Дошел до 0 - значит не его блок кончился, можно ждать свой.

Извините за вклин.

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

Да все нормально, тем более по делу.

Без контрольной суммы я и сам не привык работать.

Обратная квитанция возможна, для этого и вводился адрес источника, что-бы премник знал, кому квитанцию слать.

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

Изменено 9 октября, 2007 пользователем Migray

[YurkaM]

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

[-=gga=-]

Я на пике слелаю исполняющее устройсто, управление освещением на 3 "зоны". Управление люстрой )). Адрес 0x00h, опрос-0x00h или задача 0x01h, номера зон:1-ая зона 0x00h, 2-0x01h и третья 0x02h. команды: 0x00h - тушим, 0x01h - включаем. Вот синтаксис запрос [адрес][опрос][зона], ждем ответа [адрес][зона][состояние]. Вот синтаксис камнда [адрес][зона][состояние], ждем ответа [адрес][зона][состояние]. У меня будет 2 реле 1 кнопка. Хост должен опрашивать постоянно все адреса, особенно всякие датчики и кнопки, т.е. элементы управления. По их изменеию давать команду на реле включить или выключить - это в моём случае. Как понимаете все наращиваеться по адресам. Только придумывай как и что это дело описать. Какое правило общения будет в сети (по 220, по 380, по 10кВ шутка). Суть в том что сдесь не важно как подавать сигнал, а важно то, что в нем идет.

Я чтотоне въехал, если свет будет включать/выключать хост то есть главный то зачем тогда твоё устр-во ? ИМХО надо вот так:

Твоя схемка контролирует кол-во людей в комнате. если в комнате 1 чел то в зависимости от освещённости оно должно включить свет. Если изначально в комнате было более-менее светло, то свет должен включитьса на 50%. так же надо контролировать время. Если это ночь то свет должен включитьса на процентов 10, напрмер чел в сортир пошол... Надо решить проблему со спальной, и сделать несколько режимов работы. например если эта зоня яв-ся спальной, то позже 12 часов свет должен выключитьса. Потомучто в спальне по любому будет один или более человек... Так же былобы неплохо предусмотреть ручное вкл\выкл света, например одиночным\двойным хлопком в ладоши.

Задачи хоста:

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

PS чтобы тут не мусолить эту тему, я тебе в асю напишу, обсудим, а потом выложим сдесь, то до чего мы дошли, для критики, и только потом начнём собирать...

[YurkaM]

Не то! Не то вы делаете!!! Вся прелесть хоста в том, что можно легко и быстро реализовать и перестроить любую логику работы. Причем можно делать зависимость от сколько угодно параметров, будь то сигнал с датчика (со многих датчиков!!), время суток, время года, настроение и воля божья...