Arduino.ru

HY-MINI это что?

HY-MINI

STM, я так и подумал

используешь отладку по jtag?

я ставил openremote на synology, не понял зачем он если все можно на вере сделать

хотя сейчас думаю если создать свою сеть умного дома на nrf24 то как раз прикрутить ее можно к openremote, не будет привязки к vera.

Что касается контроллера zvawe на распбери то я в это не верю как в перспективу. Контроллеры умного дома требуют все больше и больше ресурсов.конечно если в сети как у автора пять устройств хватит, но это сложно назвать умным домом. У меня десятки устройств - vera3 с трудом справляется

Openremote интересен прежде всего как вебморда для панелей. Ну не воспринимаю я интерфейс самой веры как "end-user i-face", как интерфейс разработчика - отличная вещь! по малине в качестве контроллера не  пробовал, но у меня на ней xbmc крутится, по моему скромному, соглашусь что серьезное оно не потянет, не понимаю я этого дрочева на эту штуку.

я поковырялся, может не разобрался, мне показалось сыровато все

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

придумал как можно сделать сеть более устойчивую чем у maniacbug

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

причме заносим их в порядке убывания приоритета передачи на устройство-координатор

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

если нет, то шлем через роутер делая попытки послать через начиная с первого соседа из списка

такая сеть будет подразумевать локальные связи каждого с каждым, но у нее будет свой минус - отправка сообщения не соседу будет вынуждать слать на координатор, а координатор обязан знать все взаимосвязи, т.е. иметь таблицы всех сосесдств и уметь строить оптимальный маршрут. посылка через координатор может быть не оптимально (например реально достаточно было послать через одного посредника), но чтобы избежать этого недостатка каждому устройству нужно знать ВСЮ топологию сети. Это потребует большую оперативную память - на сеть из 10 устройств в каждом устройстве сети потребуется хранить 42 пары взаимодействий по 2 байта - 84 байта массив. С ростом сети рост будет нелинейный и легко упереться в ограничение

на мой взгляд это, если и повысит надежность, НО точно снизит устойчивость. Мне больше нравится схема maniacbug, она по сути слизана с обычной IP маршрутизации, для надежности можно добавить альтернативный гейтвей, но и то надо смотреть на статистику потери пакетов. Сейчас смотрю исходный скетч, на предмет дополнить статистикой и погонять пару недель, прежде чем усложнять, надо понять зачем.

В догонку статья по 433 беспроводным модулям http://habrahabr.ru/post/182068/

что ты вкладываешь в понятие устойчивости? по мне надежность и устойчивость в данном контексте почти синонимы - так как сеть перестанет работать (станет ненадежной) при воздействии внешних фатокров (нарушение устойчивости) таких как разрядка батареек промежуточного устройства или возникновение сильных помех. Схема maniacbug хороша только простотой реализации - каждое устройство знает маршрут отрпавки сообщения. Но дальше в реальных ситуациях возникнут проблемы и с надежностью и с устойивостью.

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

под не устойчивостью в данном случае бОльшее количество ошибок в конфигурировании каждого нода. Мне проще прописать "соседа" и здесь я точно могу сделать только одну ошибку, и если она случилась найти ее будет не проблема. В случае если у нас (СТАТИЧНЫЙ) массив соседей то вопрос поиска ошибок сильно затруднен. А главное я не понимаю зачем. Т.е. в чем проблема? в эксплуатации у тебя было много потерь? (сейчас на этот вопрос просто не ответить, ибо нет статистики)

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

мощность nrf24 с усилителем меньше чем мощность хорошей точки доступа wifi, а мощность точки доступа в разы меньше мощности мобильника. Так что трусы надо было давно купить)) Стоит включить в городе на компе поиск точек доступа и пальцев уже не хватает, чтобы пересчитать их количество

что точно нужно делат для надежности - выделять ноды которые участвуют в ретрансляции и которые не участвуют. У maniacbug разделения нет. это плохо, потому, что даже разрядка батарейки одного из нод может привести к неработоспособности целого сегмента сети. Как я писал выше - например в zwave устройства на батарейках по умолчанию не участвуют в ретрансляции

убедил. ретранслятор (aka альтернативный гейтвей) нужен. но только один для гейта. Если падает один из нодов, мне нужен не альтернативный путь, а информация об этом!

предлагаю обсуждение перенести в http://arduino.ru/forum/proekty/platforma-dlya-upravleniya-umnym-domom-n...

еще бы перенести туда обсуждения из этой ветки

не знаю как. проще там ссылки сделать

Добрый деь, помогите с кодом шлюза? Делаю на Arduino Mega 2560 + w5100 + nrf24l01+ библиотеку для радио использую rf24network.

В идеале по GET запросу: "ip-адрес/?N=01&a=1" должна открыться страница, где будет всего лиш одна цифра - показания аналогового пина A1 узла 01.

Дело в том что работа со входящими соединениями html и nrf24 заверачиваются в разные циклы:

void loop() {
   while (nRF24network.available()) {
       //приняли через радио все нужные нам параметры
   }
   while (client.connected()) {
       EthernetClient client = server.available();
       while (client.connected()) {
           if (client.available()) {
               //разбираем GET и запрашиваем нужные данные у узла 01
               message.analogPin=1;
               message.value=0; //для контроля верности обнулим
               RF24NetworkHeader header(/*Кому*/ 01, /*Тип*/ 'a');
               network.write(header,&message,sizeof(message));
               //здесь по идее должны выводить результат:
               client.print(message.value);
           }
       }
      delay(1);
      client.stop();
   }
}

Как говорится "утро вечера мудренее".

Сам забыл вставить цикл на ожидание ответа:

void loop() {
   while (nRF24network.available()) {
       //приняли через радио все нужные нам параметры
   }
   while (client.connected()) {
       EthernetClient client = server.available();
       while (client.connected()) {
           if (client.available()) {
               //разбираем GET (тут код разбора GET)
               //и запрашиваем нужные данные у узла 01:
               message.analogPin=1;
               message.value=0; //для контроля верности обнулим
               RF24NetworkHeader header(/*Кому*/ 01, /*Тип*/ 'a');
               network.write(header,&message,sizeof(message));
               while (!network.available()) {
                   network.update(); //Слушать радио пока не придут нам данные
               }               
               //приняли через радио все что нужно (тут код обработки)
               //выводим результат:
               client.print(message.value);
           }
       }
      delay(1);
      client.stop();
   }
}