Голосовое? Что за примитив?!
А тайные желания уловить AVRом и их исполнить?

Смотрел я давече по euronews как за данную идею в европе берутся... и вспоминается как я на i8748 сваял дистанционное управление к телевизору в 1989 году. Тогда дифицит на это был страшный. Я только окончил институт продавать их собирался.

Там на прозрачное стекло двери выводится менюшка с картинками. Ну точпад конечно Ну например посудомоечная машина к интернету подключена.

У Вас есть посудомоечная машина? А интернет?

Простите мне пожалуйста мой пессимизм в данной сфере, но по-моему есть огромное колличество проектов где можно было бы "приложить руку". Для своей пользы. Пока мы ещё не доросли до данной темы финансово. А если Вы доростёте, то прикупите импортное и не будете задавать вопросы сюда. Как это ни прискорбно.

Не унывайте выбирите тему по "изящней" и занимайтесь.

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

Как мне кажется наилучшим вариантом для умного дома будет X-10 т.к. не всегда удобно долбить стены или ковырять плинтуса для того чтобе подключить к.л. устройство в сеть. А так где есть 220 есть и сеть.

Покувыркались мы недавно с передачей по сети 220. Выяснили следующее - если в доме нет китайских импульсных преобразователей (компы, зарядки) то по сети можно управлять и даже с фазы на фазу прыгает практически без проблем. Но стоит появиться представителю Великого Желтого соседа, как сеть становится слишком шумной и по ней устойчиво передать данные оченно тяжело, иногда невозможно. А Великий сосед уже в каждом доме и не только у нас. Так что вот так, подобную задачу пробуем пробить на 433 МГц, но в небольшом объеме. У многих клиентов уже все установлено и замазано-покрашено-заклеено, ковырять не хотят, а управлять хотца, скажем, обогревателями. вешаем на стенку хозяина, он меряет температуру и командует обогревателям включить-выключить. На обогревателях приемник и простенькая мега - расшифровали кому и что, выполнили. Вот вроде и все

есть ли у кого-то опыт подключения самых разных датчиков (охранных, температуры итд) в сеть ETHERNET ?
Может быть есть датчики с Ethernet - интерфейсом (со встроенным ВЕБ-интерфейсом) ? или Ethernet - адаптеры ?
Кто-нибудь может, что-нибудь сказать по этому поводу ?

Опыта применения пока нет, но в сторону XPort поглядываю
http://www.rodnik.ru/htmls/pr_110403.htm

Использую, но в контексте умного дома - 80 долларов за точку против 15 долларов LonWorks, 5 долларов CAN и 2 долларов LIN ?
Дом придется продать, а сеть проложить

Здравствуйте!
Я давно читаю этот форум. И очень много для себя нашел полезного (выражаю всем участникам и создателям сайта свою огромную благодарность), а написать решился впервые. Уж больно тема мне близка. Я как раз сейчас занимаюсь этим. Сразу скажу что я не профессионал ни в электронике ни в программировании, правда радиотехникой увлекаюсь с детства ( а оно было ну очень давно…) так что паяльник держать умею.
С вашего позволения немножко пред истории почему у меня возник интерес по данной теме. Где то больше пол года назад купил GSM сигнализацию что бы установить в доме который достался от родителей в наследство и находится где то за 300 км. Продавать не хочется. Так вот посмотрел я на возможности этого устройства (4 канала для дискретных датчиков и 4 канала для управления) и возник вопрос а можно ли сделать покруче? Дальше пошло поехало… Что надо? Как это можно реализовать? После прочтения множества информации ( сразу оговорюсь что решал конкретную свою задачу и не претендую на универсальность хотя есть элементы расширения ) пришел к следующему :

Задачи:
1. контроль дискретных датчиков ( движения, пожарные и т.д.);
2. аналоговые датчики ( наличия 220В, состояния резервных источников АКБ, электростанции и т.д.) ;
3. температурные датчики;
4. управление дискретными устройствами;
5. управление аналоговыми устройствами;
6. возможность дистанционного мониторинга и управления системой
( GSM, Интернет, локальная сеть) ;

Условия:
1.Возможность простого расширения системы (увеличения портов контроля и управления)
2. Малое потребление энергии от резервных источников ( для меня это актуально).

Решение:
Мое мнение, что п.п.1-5 оптимально реализовать на микроконтроллерах семейства AVR Mega. Шестой пункт особый он как бы «сердце» его можно реализовать по разному. Я для себя решил ( и уже приобрел ) что это будет плата DSTINIm400+DSTINIs-005 и GSM модем Wavecom Integra M2106 (сразу прошу не бить, я понимаю что это не дешево) . Просто в моем случае это самое то… что нужно.

Топология:
Можно все это рассредоточить как здесь предлагается…Но возникает вопрос интерфейса
связи, а это на мой взгляд не простая задача и только экономия проводов (я понимаю что не всегда их можно проложить но для меня не проблема). Поэтому я решил что проще все (кроме датчиков и исполнительных устройств разумеется) расположить все в одном месте тем более что это решает проблему интерфейсов и ограничения доступа (хотя с применением TINI это тоже не проблема у нее есть CAN).
Думаю что подключение дискретных и аналоговых датчиков вопросов не вызывает.
(провод для сигнализации 3-х или 5 парный). В качестве интерфейса между блоками I2C (дает возможность маштабирования системы), между TINI и модемом RS232.
Теперь почему TINI? Но во первых это то что я смог приобрести, и то пришлось заказывать в Москве через знакомых (я живу в Киеве и здесь ее нет, не говоря уже о более продвинутых решениях). Не спорю можно сделать все это на микроконтроллере, но еще раз повторюсь я не спец а только учусь. Для тех кому лень искать инфу о TINI: это по сути микрокомпьютер, и основное назначение это сопряжение высокоскоростных интерфейсов с низкоскоростными. В кратце, имеет порты: Ethernet, CAN, 1-Wire, RS232, 8bit paralell. Имеет файловую систему и Java машину.

На каком я этапе сейчас:
Во первых мое начальное знакомство с микроконтроллерами AVR заканчилось года 3-4 назад когда делал FUN карту для просмотра спутникового ТВ. Поэтому пришлось начинать с нуля. Сделал сначала подобие STK200/300 после нескольких неудачных экспериментов с Atmega 8 решил что нужен аналог STK500. При изучении программирования понял что и без JTAG не обойтись (Как оказалось симуляторы это одно а в железе часто бывает другое). Таким образом некоторое время ушло на создание железа в том числе отладочных плат (о чем совсем не жалею, хотя могу позволить купить себе готовые решения - наборы STK50Х и JTAG). Когда привезли Тиньку немножко поковырялся- запустил посмотрел пару примеров программ в том числе WEB сервер и отложил. Так же с модемом проверил пару AT команд вошел в GPRS сеть и все. Этим буду заниматься позже. Сейчас приступил к отладке программы для контроллера дискретных датчиков (Atmega16), так все вроде бы работает, но есть проблема в проверке правильно ли он шлет информацию по I2C. Пришлось ваять I2C<->RS232. Затык с USARTом, не пойму почему он шлет абракадабру. Интерфейс I2C работает нормально проверил (USB осциллограф с логическим анализатором).
Для чего все это я написал? А для того чтобы найти единомышленников и тех кто считает что «мы рождены что бы сказку сделать былью…» . Скептиков и прочих критиков прошу больно не реагировать. Я знаю что здесь много профи которые всегда подходят с точки зрения практически выгодного дела. Но думаю что есть и не мало любителей для которых главное реализация идей, а не сколько денег это принесет и есть ли в этом смысл. Ведь каждый человек имеет право на свои «причуды». Как говорится мир без чудаков скучен а без дураков не возможен…Я ни в коей мере не претендую на истину и на единственно правильный способ решения просто поделился своими идеями. Потому что считаю что все таки эта тема заслуживает внимания.

P.S. Как можно выложить фото «железа» дабы показать что это не треп и фантазии…

я вот тоже примерно по этому пути шел iasf.narod.ru только теперь смотрю на zigbee

to ASF
Признаю титанический труд. И очень интересный путь. Но к сожаленью ( а может к счастью) мне Zegbee не совсем подходит да и нет ее в Киеве. Мне не нужны беспроводные технологии, а тем более мне не под силу написать WEB сервер для микроконтроллера. Тут дай бог с более простыми вещами разобраться. Хотя у меня в перспективе есть подключение ASUS WL-HDD2.5 (Wifi точка+ HDD 40Gb+Ethernet, есть такая у меня штука) к Тини с целью получить доступ в интернет через GPRS и иметь в системе хард. По этому и купил модем с IP стеком. Да действительно есть очень классные вещи но увы не все у нас так быстро появляется...А пока появится то уже устаревает, прогресс не стоит...

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

Да я согласен Тини не ПК но для работы в медленых сетях она и предназначена...И поэтому логикой грузить ее не стоит. Тем более что параллельный порт у нее один. А делать расширенее на мой взгляд не оправдано. Добавить пару (даже на пару) логичеких микросхем и усложнить программы Тини? Какой смысл? Я просто в первом посте не описал структуру (он и так большой получился). На мой взгляд то что не требует НЕОДНОЗНАЧНОГО принятия решения надо оставить микроконтролерам

Структура:

1. Контроллер дискретных датчиков (Atmega16)
24 порта.
функции:
-отслеживание состояния и информирование системы о событии на портах
-ответ на запрос системы о своем состоянии.
-временые задержки включения датчиков
-отключенее (включение) отдельных портов
-проверка связи с системой (самодиагностика)

2. Контроллер исполнительных дискретных устройств (Atmega16)
-включение (отключение) портов
-ответ системе о своем сотояниии
-проверка связи с системой (самодиагностика)

3. Контроллер (назову его главный который и обеспечивает связь и подготовку информацию для Тини)
-связь с контролерами 1 и 2
-отслеживание 8 ми аналогових датчиков
-управление аналоговыми устройствами
-управление ЖКИ
-связь с DTMF (тональное управление с телефона)
-диагностика котроллеров 1 и 2

На мой взляд здесь оптимально Atmega32 (обьема ОЗУ больше)

Связь между микроконтроллерами и Тини (общая) - I2C. Посколько предполагается что все это находится в одном месте. Для связи с еще одним микроконтроллером (можно и не одним, это перспектива) управления электростанцией- CAN (Поставить микроконтроллеру 3 преобразователь TX<->CAN) или задействовать CAN Тини. Ну в общих чертах я вижу так.
По поводу многопроцесорных систем:
На мой взгляд проще написать отладить каждый узел системы отдельно (тем более что он становиться законченым узлом) нежели ломать голову где же рвет программма и программа ли? Я убедился что экономя $4 убиваешь несколько вечеров работы. А самое главное что чем сложнее программа тем больше вероятность баггов которые не всегда обнаружишь ( не все связи между подпрограммами и прерываниями можно предусмотреть, я убедился в этом с USART наконец его победил!). Одним словом мой хоть и не большой опыт программирования убедил меня в том что отказ (технический) нескольких микроконтроллеров имеет меньшую вероятность нежели скрытые багги программы (ну может я плохой програмист... Но я и не претендую на профи). Для меня такой путь кажется проще, я не говорю что он эффективный...

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

To Dog Pawlowa

Скажите пожалуйста какой внутренний интерфейс предпочли бы Вы? Что бы была и открытость системы и простая диагностика "каналов" связи? Я взял слово каналы в кавычки не зря. Нету у меня каналов связи, нету и все... У меня есть внутрений интерфейс ( шина) между блоками, а он может быть
параллельным либо последовательным увы третьего не дано. Паралельный мне не подходит слишком много "ног" микроконтроллера заберет. Что остается? Правильно, последовательный...CAN, Ethernet и т.д. прочие промышленные стандарты мне не нужны (ну не нужны мне сотни метров пока...) таким образом имеем: 1-Wire,I2C,RS232,SPI (USB и прочая шина это уже слишком). Почему из этих четырех именно I2C уже не трудно догадаться.
По поводу диагностики I2C. Да нет ничего проще, сделал я энтот монитор на PCF8584 еще месяц назад. Да только на фиг он мне оказался нужен. Не буду расписывать почему он мне не подходит. Скажу вкратце не предусмотрен в программе монитора адрес этого самого монитора. Вот и все. Я каждый раз как вспоминаю об этом так начинаю злиться...Я вначале приобрел USB осциллограф с логическим анализатором потому что там в описании возможностей говорилось что есть терминал 1-Wire,I2c,RS232 и SPI. А оказалось что оно ни фига не работает как терминал а только как анализатор. Я от расстройства погорячился и собрал монитор на PCF8584 особо не вникая в работу программы, как оказалось опять зря. А вот недавно меня "осенило" а не проще ли взять любую AVR с TWI и UART хотя бы Atmega8 и сделать программный RS232<->TWI? Так я и сделал. И есть теперь у меня счастье...
Теперь о достоверности. Ничто не мешает програмно реализовать контрольные суммы и прочую лабуду (да хоть 3-des шифрование) на что фантазии хватит...Да только я строю не шатл и даже не самолет, и при передаче нескольких десятков байт стоит ли огород городить?

Вам уже советовали LIN. I2C с длинными линиями себя плохо ведет, кроме того, зависание одного элемента исключает работоспособность всеи сети. конечно, если RESET по отделному проводу вести то систему всегда поднимать можно ( а Вы случаино некогда не размышляли зачем PCF8584 Reset вывод ?) можете и свои интерфеис сделать, примеров много, удобно делать "монтажный ИЛИ" из входов-выходов USART в 9битном режиме- 9ый бит указатель адрес/дата.

Вот все больше убеждаюсь что почему то у многих прям ненависть к I2C. А вот у разработчиков телевизоров, мониторов и прочей техники совершенно противоположное мнение. И чего то не замечал что бы мои телевизоры "висли". Да и сейчас при отладке программы контроллера дискретнных датчиков не замечаю ни чего подобного...Ладно поживем увидим.

Я бы взял RS485. Да собственно почему "БЫ" - я взял RS485
Открытость можно трактовать как простое добавление нового устройства в параллель.
Простая диагностика - возможность постоянного ведения логов обмена и визуализация текущего состояния. Скриншот программки визуализации приаттачен.
Нажмите для просмотра прикрепленного файла
Шаттл чужой. А дача своя Разморозить систему отопления из-за сбоя ? Объявить ложную пожарную тревогу? Это не телевизор мигнет.

Вы путаете ненависть с пониманием области применения - телевизоры, мониторы и прочая ПОДОБНАЯ техника.

работаем и с Ethernet.
Связка 51(основной) + 51(сетевой) + CS8900A(в набор входит и трансик и разьёмчик) + ОЗУ(32). Стэк свой (ARP, ICMP, IP, UDP) с поддержанием дефрагментации на IP уровне и иже. Управляются установки из под форточек (UDP). Так же сканируем параметры работы установок (приточно-вытяжные). Сканируются более десятка параметров, в том числе и температурные датчики с шагом от 1 с. до 10 с.. В экселе получаются красивые графики аднака...

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

с уважением
(круглый)

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

CAN и только CAN !!! Максимум 150руб на устройство - зато никакой мороки с протоколами и прочими арбитражами. Сказал "послать кадр для 15-го" - и он послался. Все.
Про качество интерфейса, думаю, говорить не надо. Конечно, подороже ср485 от Sipex, зато удобства выше крыши.

Идеологии промышленности несколько отличаются от заявленной темы - "умный дом"
Дом сам должен ( пусть относительно медленно) проверять , перепроверять себя и принимать решения.
Сигнализировать об ошибке, нарушении , или временно оставить без внимания некоторые "не доступные" датчики.
Во главу угла - не жестокие протоколы типа CAN, а идеология - что делать если ответ от датчика не тот, что ожидали.
Программное решение разрулит и I2C и RS485. И вообще простота установки иполнительных и следящих систем -
применение радио канала. Вот найти ("изобрести") приемопередатчики этак за 200-300 руб., да протокол связи с упором на
идеологию , а не "ченоящечную зигбю"!
Умный дом - это объем в реальных границах (желательно не конфликтующий с соседним умным домом). Вот и нужно
заполять этот объем радио (эфиром) , где дотупность -не дыра в стене, или провода по плинтусу, а наличие розетки (или
батарейки).

У меня возник вопрос как нужно реализовывать управление что бы при отказе автоматического исполнительного устройства оставалось ручное управление?
В качестве среды думаю самое актуальное радио (не нужно долбить стены) или RS-485 (много устройств автоматизации работает на MODBUS).
В плане дешового радио поднималась тема тут на форуме
Оттуда взял вот этот передатчик возник вопрос для "Умного дома" как реализовать маршрутизацию пакета при малой дальности передачи в помещении:
Если есть пять точек одна видит до двух соседей как от первого передать пакет пятому
1-2-3-4-5
1 видит 2 и 3
2 видит 1, 3 и 4
3 видит всех
...
5 видит 3 и 4

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

Идея с координатором (ZigBee, например) конечно хороша, но если ложится координатор - ложится сеть. А так как все остальные устройства координатором не могут являться (это я про острый случай бюджетного варианта - нет ресурсов), и подхватить упавшее знамя не могут, то получается (_*_). Конечно, можно резервировать координатор, но, лично у меня, душа к такому решению не лежит.

Это откуда такая инфа??? Координатор нужен для первоначального постороения сети, состоящей из роутеров и конечных устройств. И если в такой работающей сети отключить координатор, то она продолжет спкойно функционировать. Естественно, данные на координатор не будут доходить, но все остальные узлы будут между собой нормально общаться.

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

А к чему лежит? Я пока нашел построение таких вещей только в Zig Bee
И еще вопрос периемо передатчик который я преводил выше можно применять для Zig Bee. Диапазон вроде совпадает?

Ну я так понимаю, подходящего вида модуляции там нет.

Кстати, обещанный патент:
Нажмите для просмотра прикрепленного файла