0,0
рейтинг
6 марта 2013 в 00:00

Администрирование → Беспроводные коммуникации «умного дома» tutorial

Когда начинающие (или продолжающие) «радиолюбители» наигрались со светодиодами и устали поворачивать сервы в различные положения, некоторые из них начинают прикладывать полученные знания к обычной бытовой сфере.
Как правило, это применение находится в двух областях — автомобиль или дом.
«Тюнить» авто лично мне как-то не интересно, а вот сделать собственное жилье чуточку «умнее» и комфортнее — достойный выбор.


На фото выше представлен работающий прототип «Панели управления» моим «умным» домом.
Лирическое отступление #1: Как все начиналось (можно пропустить, но кому-то может оказаться полезным).

Первоначальная философия моего «умного дома» была следующей: каждое созданное устройство сделано для достижения какой-то определенной цели и оно должно работать самостоятельно.
Так дома появились устройства типа:

В доме используются не только самодельные, но и покупные «умные» устройства. Одним из таких очень удачных устройств является хронотермостат:


Термостат работает в двух режимах:
  • «Ночной» — температура пониже, чтобы было комфортнее спать (и экономить газ).
  • «Дневной» — температура выше и более комфортная для бодрствования.

Все предельно удобно, настраивается индивидуальный график «ночного» и «дневного» режима, задаются обе температуры. «Ночной» режим для себя настроил так, что он включается как ночью, так и днем, когда дома никого нет.

Но так как мой рабочий день не нормирован, после нескольких ранних возвращений выяснилось, что возвращаться в прохладный дом с мороза днем как-то не очень приятно.

С этого момента началась эпопея с беспроводными коммуникациями (можно было, конечно, опутать весь дом «витой парой», но это не наш метод).

Выбор беспроводных модулей был достаточно спонтанный, но после нескольких месяцев эксплуатации он вполне оправдал себя.

Были приобретены дешевые трансиверы на 2.4ГГц nRF24L01+:


По характеристикам заявлено, что дальность до 100м (в прямой видимости) и скорость передачи данных до 2Мбит. Возможно использование любого из 126 доступных частотных каналов. Очень достойно для такой «крохи».

На всякий случай для наиболее «критичных» модулей нашлись «усиленные» версии:


Эти модули полностью совместимы с «обычными», но дополнительно оснащены усилителем мощности и внешней антенной.
Кстати, они пока так и лежат без дела — оказалось, что в моем случае достаточно «обычных» модулей.

Модули подключаются к МК через SPI.
Особенность модулей такова, что им для питания требуется 3.3В (т.е. необходимо им обеспечить индивидуальное питание, если вся остальная схема питается, например, от 5В). Приятной новостью является то, что эти RF-ки толерантны к 5В-сигналам (не требуется использовать схему согласования уровней).

Лирическое отступление #2: Первые опыты.
Первоначально для работы с беспроводными модулями использовалась библиотека Mirf.

Для устранения проблемы «прохладный дом» (см. Лирическое отступление #1) был создан «принудительный» термостат.
Модуль из себя представляет небольшую коробочку, которая подключается между газовым котлом и хронотермостатом:


Модуль оборудован 2 релюшками, которые обеспечивают необходимую коммутацию, собственным датчиком температуры (DS18B20) и 3 светодиодами для индикации режима работы.

Логика простая: если у «принудительного» термостата выбран автоматический режим работы — он изображает из себя «кусок кабеля» и никак не влияет на взаимодействие котла и хронотермостата. А вот если его перевели в режим «ручной» работы — хронотермостат отключается от котла и уже не участвует в работе, за температуру дома становится ответственным «принудительный» термостат.
Модуль обладает 2 параметрами:
  • Режим работы (0 — авто, 1 — ручной).
  • Заданная температура.

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

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

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

Выбор пал на плату gBoard (атмега328, gsm на базе sim900, интерфейс для nrf24l01 (используется аппаратный SPI), SD, кучка аналоговых пинов и проч.):


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

Опять же с использованием той же библиотеки для nrf24l01 (Mirf) был написан скетч.
Теперь появилась возможность через СМС запросить текущую температуру дома, задать желаемую температуру и перевести «принудительный» термостат из одного режима в другой.

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

Аналогичным образом модуль для ИК-управления светом был оснащен беспроводным модулем и тоже стал управляться через СМС (опять же, этот модуль стал еще одним «датчиком» в системе — температура/влажность/состояние света).

Через некоторое время почти все «поделки» обзавелись беспроводным интерфейсом и стали как минимум «датчиками», а как максимум — исполнительными устройствами с возможностью удаленного управления.

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


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

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

Формат структуры для передачи данных был не оптимален (для моего случая). Эту версию формата даже приводить не хочется.

Понятно, что необходимо как-то модифицировать (предпосылка #1).

Естественно, появилось желание получать информацию и управлять еще и через LAN. Была приобретена платка iBoard (атмега328, LAN на базе Wiznet W5100, интерфейс для nrf24l01, SD, кучка аналоговых пинов и проч.):


И все вроде бы все как на gBoard, но оказалось, что беспроводной модуль разведен совсем не так, как ожидалось. Аппаратный SPI в этой плате используется для LAN и SD, а вот для беспроводного модуля предлагалось реализовать этот интерфейс самостоятельно. Сделано это было скорее всего для того, чтобы можно было «одновременно» работать как с LAN, так и с RF.

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

Очевидно, что надо что-то делать, иначе хорошая плата пойдет «в стол» до лучших времен (предпосылка #2).

Была обнаружена чудесная библиотека RF24 (автор maniacbug, Сиэтл, США) и еще более чудесный форк iBoardRF24 сделанный Андреем Карповым (Киев, Украина).

Библиотеки замечательным образом заработали на всех имеющихся устройствах (тестовые примеры), но вот устройства с разными библиотеками (Mirf и RF24) между собой не могут общаться (предпосылка #3).

Стало очевидно, что настал-таки тот самый момент, когда надо все переделать.
Далее будут приводиться куски кода (Arduino IDE) для иллюстрации текущего решения. Полный листинг не привожу, чтобы оставить простор для творчества.

Имея за плечами уже солидный накопленный опыт, взял из структуры передаваемых данных все хорошее и учел имеющиеся недостатки пришел к тому, что лучше использовать следующую структуру «пакета» данных:
// структура для передачи значений
typedef struct{         
  int SensorID;        // идентификатор датчика
  int CommandTo;       // команда модулю номер ...
  int Command;         // команда
                            // 0 - нет команды или ответ
                            // 1 - получить значение
                            // 2 - установить значение
  int ParamID;         // идентификатор параметра 
  float ParamValue;    // значение параметра
  boolean Status;      // статус 0 - ошибка, 1 - ок
  char Comment[16];    // комментарий
}
Message;

Из комментариев почти везде понятно, какой параметр для чего используется. То что непонятно, будет объяснено чуть ниже.

Внутри же каждого «датчика» необходимо иметь структуры для параметров:
// структура для параметров и значений
typedef struct{
  float Value;         // значение 
  boolean Status;      // статус - 0-ошибка (false), 1-ок (true)
  char Note[16];       // комментарий
} 
Parameter;

В структуру заведено три параметра. Ну со «значением» все понятно, поле «Note» используется для того, чтобы дать какое-то внятное (но краткое) объяснение, что же это за датчик и, возможно, единица измерения.
Status заведен больше для контроля и возможной гибкости в дальнейшем.
Сейчас это используется, например, если не удалось по каким-то причинам считать данные с какого-то датчика, то система может спокойно обработать эту ситуацию и передать 0, обозначив проблему.

Видно, что вторая структура полностью повторяет «конец» структуры передаваемого пакета.

Формат передаваемого «пакета» абсолютно идентичен как для «master» (тот, кто рассылает команды и собирает данные), так и для «slave» (тот, кто принимает команды и отчитывается о проделанной работе). Более того, при таком подходе master и slave — достаточно условные обозначения. Модули реально общаются «на равных» и запросы с ответами могут идти в обе стороны.

Теперь можно уже приступать к описанию конкретного модуля. Возьмем какой-нибудь гипотетический модуль с 3 параметрами. Кодироваться это будет следующим образом:
// описание параметров модуля
#define SID 100                        // идентификатор датчика
#define NumSensors 3                   // количество сенсоров (и еще одно обязательное занчение - имя датчика)

Parameter MySensors[NumSensors+1] = {    // описание датчиков (и первичная инициализация)
  NumSensors,1,"Sensor 100: LED",        // в поле "комментарий" указываем пояснительную информацию о датчике и количество сенсоров, 1 в статусе означает "отвечаем на запросы"
  0,0,"value A0",
  0,0,"counter",
  0,0,"set_value",
};
Message sensor; 

Обратите внимание, что не смотря на то, что параметров 3 — объявляется структура из 4 элементов. Для себя я принял, что в «нулевом» элементе я буду всегда кодировать информацию о самом «модуле» — количество его датчиков, давать информацию о том, что датчик может принимать команды или он только «датчик» и текстовое описание датчика.
Сейчас думаю, что при описании датчика параметр Status можно использовать для обозначения — можно ли этот параметр менять (т.е. «исполнительный механизм») или нельзя (просто «значение датчика»).
Или ввести для этого еще один параметр?

С данными разобрались, перейдем к функциям:
boolean sendMasterMessage(int From, int To, int Command, int ParamID, float Value, char* Comment, Message* answer);

Так объявлена функция, с помощью которой отправляется команда.
Возвращает «true», если пришел правильный ответ или «false», если постигла неудача.
Входные параметры: от какого модуля идет команда, какому модулю, команда (читаем или устанавливаем), какой параметр, значение, комментарий и ссылка на структуру для ответа.
Параметр «комментарий» тут является больше «закладкой на будущее» для того, чтобы, например, можно было менять имена модулей и названия параметров.

Результат функции определяется по следующим правилам:
  1. ответ должен быть получен от того датчика, к которому обращались
  2. ответ должен предназначаться тому мастеру, который инициировал запрос
  3. в ответе должен быть ParamID тот, что участвовал в передаче

Таким образом, чтобы узнать значение первого датчика с нашего гипотетического сенсора, достаточно на мастере (пусть его SID будет 900) вызвать функцию следующим образом:
  ...
  Message answer;
  ...
  if(sendMasterMessage(900, 100, 1, 1, 0, "", answer)) {
    Serial.println(answer.ParamValue);
  }
  else {
    Serial.println("No answer");
  }
  ...


Соответственно на «принимающей» стороне в основном цикле должен быть примерно такой код:
  // если получена команда
  if (radio.available()) {
    bool done = false;
    while (!done)
    {
      done = radio.read( &sensor, sizeof(sensor) );
      // если команда этому датчику - обрабатываем
      if (sensor.CommandTo == SID) {
        // исполнить команду (от кого, команда, парметр, комментарий)
        doCommand(sensor.SensorID, sensor.Command, sensor.ParamID, sensor.ParamValue, sensor.Status, sensor.Comment);
      }
    }
  }


Функция doCommand может быть примерно такой:
void doCommand(int From, int Command, int ParamID, float ParamValue, boolean Status, char* Comment) {
  switch (Command) {
    case 0:
      // ничего не делаем 
      break;
    case 1:
      // читаем и отправляем назад
      sendSlaveMessage(From, ParamID);
      break;
    case 2:
      // устанавливаем
      setValue(From, ParamID, ParamValue, Comment);
      break;
    default:
      break; 
  }
  // ответим "командующему"
  sendSlaveMessage(From, ParamID);

  return;
}


Функция sendSlaveMessage — почти такая же, как sendMasterMessage, но не проверяет правильность ответа после того, как отправила данные и содержит меньше входных параметров — функция принимает на входе идентификатор того модуля, кому отвечает и идентификатор параметра, информацию о котором необходимо переслать.
Остальные обязательные данные для состава «пакета» отправки система и так уже знает (напомню, там еще обязательные поля — идентификатор модуля, который осуществляет отправку данных в текущий момент, команда (в данном случае это будет 0, т.к. просто отправляем текущее значение)).

Таким образом, логика работы получается простая:
  • Master инициирует адресный запрос к модулю и требует прочитать (или установить) значение определенного параметра.
  • Slave принимает эту команду (и если она адресована именно ему) и выполняет требуемое, о чем «отчитывается» в ответном сообщении.
  • Master анализирует принятый пакет и если удовлетворен результатом — занимается дальше своими делами или делает повторный запрос (нужное количество раз).

Код для gBoard тоже был переписан соответствующим образом и теперь взаимодействие через СМС выглядит примерно так (часть скриншота с моего телефона):

Первой СМС я запрашиваю температуру восточного датчика у «погодного» модуля, второй СМС — устанавливаю желаемую температуру «принудительному» термостату. В ответ я получаю измеренное значение или ответ об успешно установленном значении (в конце сообщения есть «ОК!»).

Хорошо видно, что в СМС включаются данные, необходимые для формирования полного запроса для конкретного модуля. Соглашусь, что не слишком простой формат исходящих сообщений, потом можно будет переписать во что-то более «человекопонятное».

На этом «адресный» обмен данными описывать закончу.

Но ведь в домашней системе есть и другие модули, которые являются примитивными «датчиками». Типичный образец такого модуля — датчик температуры и влажности, который, возможно, работает от батарейки и ему свои ресурсы надо беречь и «спать крепким сном» и просыпаться исключительно для того, чтобы быстренько отправить данные о своем состоянии и снова «спать».
Для него режим «запрос-ответ» не подходит (придется держать как минимум RF-модуль в «бодрствующем» состоянии, что негативно скажется на времени автономной работы).

Тогда придумал, что можно устраивать «флуд» в эфире: датчики могут на регулярной основе отправлять значения своих параметров (всех или только некоторых — зависит от конкретной реализации) для всех (тогда параметр To (кому) принимает значение 0 (т.е. «всем»)).

Получается эдакий «мультикаст» — модуль проснулся, выдал в эфир свое состояние (и ему не важно, услышал кто-то или нет) и снова уснул.

Почти всем модулям, которые работают «адресно» добавил и режим «флуда», чтобы они тоже регулярно сообщали в эфир свое состояние (для системы логирования).
Переписать (точнее будет сказать «скорректировать») код скетчей для тех модулей, что уже работали (под новую библиотеку), оказалось очень простой задачкой — не более 15-20 минут на модуль. Процесс «миграции» прошел абсолютно безболезненно.

А теперь осталось только данные собрать воедино. Тут-то и пригодилась плата iBoard (еще раз приведу ее фото, с уже установленным RF-модулем):


На этот модуль возложена одна простая, но очень важная функция — слушать «флуд» и отправлять данные (метод POST) на веб-сервер. Модуль на iBoard вообще ничего не знает о количестве и «составе» передающих модулей — слушает все.

В пакете данных для веб-сервера передается «ключ» (чтобы сервер понимал, что это «свои») и полный принятый пакет (еще раз повторю, что в пакете приходят следующие ключевые данные: SID модуля, ID параметра, значение этого параметра, комментарий (имя параметра и/или единица измерения)).
Если же в принятом пакете ParamID равен нулю, то в значении параметра мы имеем количество «сенсоров» у модуля, а в «комментарии» — имя модуля.

На веб-сервере в автоматическом режиме формируются записи в 2 табличках: sensor_list и sensor_value (из названий, думаю, все понятно).

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

В качестве веб-сервера использовал то, что «было под рукой» (Synology DS411+II) — в пару кликов был поднят веб-сервер с php и mySQL. В случае, если «под рукой» нет ничего подходящего и не хочется ради этого держать включенный комп — можно воспользоваться сторонним хостингом, приобрести что-то типа этого (приятно и полезно) или, например, сервисом cosm.com

В зависимости от выбора «хранилища», код для МК с LAN-модулем будет изменяться минимальным образом (на cosm.com для ардуинки есть своя библиотека и удобный режим отладки — использовать очень просто).

Данные собрали (а в случае использования cosm.com — уже и отобразили на графиках).

В своем проекте для отображения я использовал Google Charts. Получается примерно так (только погодные параметры):


Специально привожу скриншот, а не даю ссылку на страницу — NAS, думаю, не выдержит нагрузки с хабра.
Данные с датчиков «зашумлены», надо бы применить фильтр Калмана, но руки пока не дошли до этого.

Собственно, со сбором и отображением данных — тоже закончил.

Осталось реализовать управление через LAN (а вот это еще как раз и не сделано и, если будет интересно, станет темой еще одного поста (хотя основные принципы уже все озвучены — как делать уже понятно, надо только «сесть и написать»)).

Вы можете спросить: «При чем же та картинка, с которой начался пост?»

А это еще одна плата для быстрого прототипирования — iBoardPro (построена уже на mega2560, LAN, RTC, SD, RF-интерфейс, 40-пиновый разъем для подключения TFT дисплеев с тачскрином и другими «плюшками»):


На фото хорошо виден дисплей TFT 2.4" 320*240 с резистивным тачскрином ITDB02-2.4E. Выглядит хорошо, но вот для работы пальцами — мелковат, да и тексты хотелось бы покрупнее (буду смотреть в сторону 5 или даже 7-дюймовых дисплеев).

С использованием вышеописанных принципов на этой плате реализован (но все еще дописывается) «контрольный модуль», на который выводятся данные с желаемых датчиков и можно управлять теми устройствами, которые это поддерживают.

Небольшое видео, демонстрирующее текущую работу прототипа:


Логика работы следующая:
  • Есть «главные» экраны — на них попадают «сводные» данные («Погода» — зеленый, «Дом» — желтый)
  • Есть «субэкраны» — на них отображаются данные с датчиков (на видео это продемонстрировано для «желтой» закладки — «домашние параметры»: температура и влажность в двух точках дома и данные по электропотреблению).
  • «Красный» экран — это «сводка из сводок» — наиболее востребованные данные.
  • «Синий» экран — управление. В средней его части находится управление светом, в нижней — управление «принудительным» термостатом. Слева снизу красный «индикатор» — это отображение того самого параметра (о котором я писал выше), отображающего, можно ли газовому котлу в текущий момент времени работать.

«Кнопки» управления на экране обладают «обратной связью»: т.е. после включения конкретного режима — это отображается соответствующим цветом. Если что-то уже было включено ранее, то при переходе на экран управления это будет сразу видно.
Каждое «нажатие» на кнопку порождает вызов функции sendMasterMessage с соответствующими параметрами и получение ответа от конкретного датчика (именно по этим данным и происходит «перекрашивание» кнопок или изменение значения, как это видно для заданной температуры «принудительного» термостата).

Видно, что есть определенная задержка при «перекрашивании» кнопки и изменении параметра — это обусловлено не только медлительностью МК при отрисовке, но и тем, что требуется время на отправку запроса и получения ответа (иногда процесс «запрос-ответ» проходит не единожды — master умеет повторять свой «приказ», если не дождался ожидаемого ответа).

«Фиолетовый» экран планируется использовать для вывода данных о состоянии системы: текущий IP-адрес, время старта, время последней синхронизации через NTP, времена последних «коннектов» (или «прослушиваний») с конкретными датчиками и т.п.

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

Извините за качество фото — снимал на микроволновку телефон.

P.S. «Железки» приобретал в этом магазине (конечно, переплатил, но ждать долго-долго из Китая не хотелось, за это время успел заказать и получить несколько посылок из НСК). Ближе и быстрее нигде не нашел.

P.P.S. да, все эти «железки» (ну разве что кроме дисплея) можно собрать дома, но это не было целью.
Алексей Степанов @avstepanov
карма
103,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (56)

  • +1
    А можете поподробнее рассказать про дальность работы датчиков? Интересует как они работают именно в реальном доме, есть ли на пути радиосигнала бетонные стены?
    • +3
      Я полное тестирование проводил.
      Те, что без антены работают через одну стену уверенно, через две могут терять сигнал, может потребоваться позиционирование (повертеть модулем для лучшего приема) — зависит от того, что внутри стен и между ними.
      Реальная скорость передачи (с моим драйвером) составила где-то 540 КБит при включенном подтверждении доставки. В прямой видимости (относительно прямой, городские условия) дальность уверенная до 50м, выше — надо позиционировать модуль.
      Через межэтажное перекрытие может пробить, если повезет, опять-таки, позиционировать требуется точно (то бишь, стоять прямо под ответным модулем).

      Тот что с антенной — через тонкие стены пробивает уверенно, не знаю сколько их нужно, чтобы заглушить сигнал, через несущие 2-3 тоже без особых проблем. Скорость такая же. Дальность метров 300 выжимал (городские условия), на 300 уже приходилось серьезно целиться антенной в ответный модуль. До 150 — уверенно ловится. Через два этажа пробивает (перекрытия), на третьем уже долго целиться надо.

      P.S. Все тесты проводились с тем приемником, что с антенной! Передатчик, соответственно, менял.
      • 0
        > приходилось серьезно целиться антенной в ответный модуль

        Можно подробнее об этом? Чем, куда, и каким образом целились?
    • 0
      У меня сейчас между датчиками не более 10 метров (по прямой). Преграды в виде кирпичных стен, деревянных перекрытий (в различных комбинациях и количествах) и т.п. — все работает. Дальность не проверял (будет потеплее — сделаю пару тестов «с улицы»).
    • 0
      Предельная толщина препятствия, через которую может пройти радиосигнал 2.4 ГГц
      Кирпичная стена: 0.78 м
      Бетон: 0.09 м

      habrahabr.ru/post/164215/
      • +1
        Никто не запрещает сделать на базе этих модулей mesh-сеть (в голове полная картинка еще не сложилась, но пакет, думаю, не сильно изменится — нужно будет еще пару параметров добавить). Нужно будет теорию графов освежить для построения «путей».
        • 0
          SNAP не пробовали?
          • 0
            нет, что это? где почитать? (гугл только про музыку ссылки подкидывает)
            • +1
              SNAP — это универсальная сетевая операционная система для реализации Mesh-сетей, позволяющая абстрагироваться от аппаратных особенностей приемопередатчика. Используя любой или все из доступных на устройстве интерфейсов связи, стек SNAP выполняет пересылку и сетевую маршрутизацию сообщений, превращая данное устройство в полнофункциональный узел интеллектуальной самоорганизующейся и самовосстанавливающиеся Mesh-сети. Для связи с остальными узлами сети при этом может использоваться любой современный проводной или беспроводной интерфейс: IEEE802.15.4, Wi-Fi, TCP/IP, Ethernet, USB, RS232, RS485 и др.

              www.synapse-wireless.com/snap
              • 0
                Спс за ссылку. Выгледит очень вкусно.
        • 0
          С протоколами маршрутизации придеться помучаться, или взять уже готовую реализацию — ленивый вариант.

          А в общем MESH сети весьма интересны. Я периодически прорабатываю архитектуру войсковой АСУ тактического звена на основе MESH сетей. Очень перспективное направление.
  • 0
    Классно… Задумался о том что-бы реализовать что-то похожее у себя дома.
    Еще что-то придумать с размерами сенсорной панели… Или сделать аппаратные кнопки и просто дисплей состояния…
    • 0
      Сделайте аппаратные кнопки по бокам, как в банкоматах — на экране просто значение кнопки в данном режиме…
  • 0
    Ну уж центральный-то модуль с дисплеем чего на меге мучать?)
    И рисовать отвратно, и ОС нормальной нет (а значит — сильно урезаны возможности — хотя бы по выводу своего девайса в веб) и дорого, и вайфая нет. Центральный однозначно рекомендую делать на какой-нибудь небольшой плате с линухом на борту.
    • 0
      Этот модуль не претендует на роль «центрального» — это именно «панель управления»: отображаем нужные параметры и можем что-то там включать. И вообще, пока для моей системы само понятие «центрального модуля» — не определено. Все работают индивидуально, но могут управляться.
      • 0
        Панель управления — тем более. Для GUI надо выбирать наиболее удобные инструменты, чтобы потом не проклинать себя и эти АВРки.
        • 0
          Я пока доволен результатом (результат на сегодня — работающая система беспроводных модулей, а не «панель управления»).

          В дальнейшем, «панелями управления» скорее всего станут андроид-планшеты.
          • 0
            Также думал про использование планшетов, даже написал комментарий.

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

            Графики погодных параметров, приведенные в статье за какой период времени?
            Там только часть года видна. Может год убрать правее — важнее время и дата в этом случае.
            • 0
              Графики погодных параметров — за 3 дня. Когда это не картинка (а реальная страница с графиком) — можно навести на график курсор мыши — появится всплывающая подсказка, где для каждой точки графика можно увидеть значение и дату/время.
    • 0
      RaspberryPi к примеру.
      Или может софт под андроид написать для управления по сети, или веб-сайт замутить для управления на NAS'е.
      Юзать можно как с мобилки, так и небольшой планшет взять и прилепить к стене — модная панелька!
  • +1
    А что с питанием у вас, кстати? Вы там упомянули «время автономной работы» — как организовано питание модулей? И здоровых, и мелких, с датчиками.
    • 0
      Пока у каждого «здорового» модуля стоит блок питания (ужас, однозначно буду с этим что-то делать). С мелкими пока работаю — есть варианты на батарейках. Сейчас готовлю один прототип на солнечных батареях… в процессе пока.
  • 0
    А того что кто нибудь с улицы решит по управлять вашим домом не опасаетесь?
    • +1
      Даже зная формат пакета (а кто сказал, что тут опубликована «боевая» версия пакета?) нужно перебрать массу параметров (частотный канал, pipes), чтобы только начать «слушать».

      Потом я не просто так в пакет вставил идентификатор модуля, от которого идет команда. На модулях есть проверка, можно ли от этого «инициатора» исполнять команды.

      «Взломать», конечно, можно… но хлопотно это.
      • 0
        Было бы желание взломать…
        • 0
          да это понятно…
  • 0
    Интересно про работу внешних датчиков, а именно как там avr/arduino при минусовой температуре? По даташитам atmega328 и NRF24 до -40, но в реальности все обычно иначе, в тч из-за прочих компонентов.
    Ну и с батареями проблема, хотя тут товарищ недавно выкладывал простой вариант с ионистором и солнечной батареей.
    • 0
      У меня на улице стоят только покупные Oregon. Остальные модули пока домашние, так что по этому поводу пока ничего не скажу.
  • 0
    Не понимаю, почему выбор на iboardpro?
    Почему не купить ту же малину, ну не намного дороже же!
    Можно и cubieboard, но когда будет поставки хз.
    Туда уже можно много чего подключить, и обрабатывать там же. Поднять и веб и бд для обработки.

    Как я сожалею, что у меня нету времени этим заниматься.
    • 0
      Что было доступно — то и взял. Малинка — да, можно, но пока я еще не готов линукс осваивать.

      Дальше будет скорее всего «панель управления» на андроиде… модули-то работают, GSM-шлюз по управлению и мониторингу — есть, LAN по мониторигну — тоже есть, LAN по управлению появится «вот-вот».

      А «центральный модуль» в моей системе — пока без надобности (уже писал об этом выше). Возможно, он появится для реализации «сценариев» (но опять же не факт, что это будет что-то «мощное»).
      • 0
        А может взять готвый какойнить планшетек за 50уев из китая, посадить его на внешнее питаниие а на его usb хост управление Вашим зверинцем устройств. Ну и вдорогнку можно тогда будет и по SIP'у управлять, звоня на домашний IVR )
        • 0
          про планшетник за 50уев я уже думал — скорее всего это станет основной версией «панелей» управления (но это когда уже софт будет соответствующий написан). Можно будет повесить по такому в нужных местах дома.

          usb host его использовать не вижу смысла… зачем? все ж беспроводное. Планшетник подключится к домашней сети через wifi и будет работать со «зверинцем» через LAN-шлюз.
      • 0
        Ясно.

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

        Не подскажате, какие девайсы взять для следующего.

        Во глове кухни хочу поставить cubieboard — у него есть I2C и SPI.
        Далее я хочу поставить приемник/передатчик на 433 что бы собирать сразу данные температуры, давления, влажность (для начало)
        что то типа nRF24L01+ но для 433.

        • 0
          Да, у меня спрашивали.

          Ответ тут есть.
          • 0
            Ну гуглить понятно, может быть просто уже есть проверенные и рабочие девайсы.
            • 0
              Поскольку у меня нет того девайса, который вы хотите использовать, то «проверенный вариант» я точно подсказать не смогу. Сорри.
        • 0
          Cubie на Allwinner A10? Туда очень легко впихнуть дебиан и забыть навсегда о проблемах с кросс-компилом и прочих радостях, рекомендую.
          • 0
            Там и так уже стоит давно две системы Gentoo и ubuntu 13.04, вопрос бы не в этом :)
  • 0
    А датчики как разместили вне дома? Вопросы защиты от погодных условий как решили?
    • 0
      Ничего особенного не делал — повесил, где было удобно (в обоих случаях это под большим козырьком крыши) на двух разных сторонах дома. Посмотрел только чтобы прямых солнечных лучей не было и в сильный дождь с ОЧЕНЬ сильным ветром чтобы не заливало.
  • 0
    А есть где-то толковая статья про эти самые беспроводные модули, желательно с примерами? А то не очень ясно как они работают.
    • 0
      Возьмите две ардуины (любые), два таких модуля, загрузите библиотеки, ссылки на которые есть в статье и залейте тестовые примеры из комплекта библиотек — все станет понятно. Если честно, я не знаю, что про них еще можно написать?
      • 0
        Про использование понятно, меня интересует их внутренний протокол. Как я понял, они multimaster, то есть каждый передаёт сразу всем. С коллизиями какая-то борьба аппаратная есть? Какое-то встроенное шифрование есть или надо на уровне пакетов делать?

  • 0
    а почему бы не взять в качестве сервера готовую систему, типа LinuxMCE, а свой код добавить плагинами в нее? тогда решится много вопросов по интеграции новых устройств
  • 0
    Прекрасная статья, большое спасибо! Я как раз давно думаю над тем, что бы «опутать» дом проводной сетью датчиков и «исполнителей» таким образом, что бы система по возможности была бы модульной, а отдельные датчики и «исполнители» по возможности мало зависели друг от друга.
    • 0
      Имхо, это самый правильный вариант — пусть работают сами по себе и при необходимости — коммуницируют. Но если вдруг с коммуникациями что-то не так — все равно продолжали работать.
      • 0
        НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Очень интересно читать на Хабре про «умный дом», но, к сожалению, мне в основном попадаются статьи, описывающие опыт создания с нуля, в то время как хотелось получить обзоры и по готовым решениям, их практическому применению, особенностям и подводным камням, аналогично обзорам новых гаджетов
    • 0
      Купите готовое решение, внедрите и расскажите — мне тоже интересно.
      Но цены на покупные решения, как бы помягче выразиться, «кусаются».
      • 0
        Постараюсь обязательно. Пока заинтересовал такой вариант habrahabr.ru/post/160493/ Но хочется узнать и про аналоги.
  • +5
    Я с модулями nRF24L01+ тоже поработал немного на STM32 и Arduino. Помог мне в этом аппноут nAN24-12:
    www.nordicsemi.com/eng/nordic/download_resource/10640/11/94955352

    Его я, с разрешения Nordiс Semiconductor, серьёзно перепилил, избавив от мусора и упростив портирование. Результат можно взять у меня на гуглодиске:
    nrf24l01p.zip: goo.gl/IPZPM

    Для портирования нужно написать всего две функции (их прототипы есть в nrf24l01p.h) — дрыганье линией SS и полнодуплексный I/O по SPI:

    void nrf24l01p_spi_ss(nrf24l01p_spi_ss_level_t level);
    uint8_t nrf24l01p_spi_rw(uint8_t value);

    Библиотека чисто сишная (C99), проверял на STM32VLDiscovery (STM32F100RBT6), STM32F4Discovery (STM32F407VGT6) и Arduino (ATmega168 и ATmega328). Все функции, структуры и т.д. подробно документированы авторами оригинального аппноута.

    // Тестовый код

    Arduino:
    nrf_rx.zip: goo.gl/Lsxzp
    nrf_tx.zip: goo.gl/P4shM

    STM32:
    stm32f4d_nrf_tx.zip: goo.gl/si8Rv
    stm32vld_nrf_rx.zip: goo.gl/ScgF8
    stm32vld_nrf_tx.zip: goo.gl/dmLle

    // IMHO

    Всю прелесть работы с nRF24L01+ я ощутил в полной мере, только когда пришлось разрабатывать сеть беспроводных датчиков на CC430 (MSP430 + радио CC1101, Texas Instruments). Если провести параллели с дистрибутивами Linux, то nRF'ки — это Ubuntu, а CC430 — Arch. У каждого радиочипа свои преимущества, но с nRF работать не в пример легче.
  • 0
    Тоже делаю систему на этих радио модулях и столкнулся со странностью — два простых модуля (с антенной на плате) работают лучше (если тестировать на пробитие стен) чем один с внешней антенной + один «простой». Два с внешними антеннами работаю отлично. Не могу понять в чем проблема, по теории так быть не должно, но на практике это так.
  • 0
    Подумываю по похожему сценарию, но пока немного хочется отойти от беспроводных блоков — ведь приходится организовывать блок питания на каждой точке :(

    Сейчас проще кинуть 4-жильный телефонный провод, и по нему уже общаться и питаться. Конечно, при смене обстановки, лапша по 10 метров уходит в негодность, но всё же это проще.

    Например загородный дом. У меня одна точка бесперебойного питания вместе с основными мозгами. Далее лапша уходит на датчики. На одну линию можно вешать, например, несколько температурных 1-wire, или объемников (однозонные получаются).
    • 0
      Я после долгих раздумий решил сделать тоже провода. В планах шина rs485/modbus, питание 12/24. раскидывать витуху по квартире придется в любом случае.

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