Предложения по развитию проекта MegaD

Обсуждение статей, технологий домашней автоматизации, программных и аппаратных решений
Mixman
Сообщения: 395
Зарегистрирован: 17 фев 2013, 23:49
Откуда: Волгодонск, Ростовская обл.
Контактная информация:

Re: Предложения по развитию проекта MegaD

Сообщение Mixman » 20 дек 2013, 14:18

Pavel v, по Вашему вопросу тут очень много тем создано, давайте не будем тут флудить, а воспользуемся поиском?

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

dimik2000
Сообщения: 34
Зарегистрирован: 13 сен 2012, 12:51

Re: Предложения по развитию проекта MegaD

Сообщение dimik2000 » 20 дек 2013, 14:26

To Pavel v:
1. Да, как и сказал Andrey_B, доставка с алиэкспресс не быстрая, месяц-два, как и все посылки из Китая.
2. Краны есть всякие нужно только поискать, вот например:
http://www.aliexpress.com/wholesale?Sea ... 1220021036
3. Датчики давления, да, на 4 атм. но у меня выше и не бывает. Если поискать, то есть всякие, смотря какие нужны.
4. На счетчиках написано: "ВСГд-15" (горячая вода) и "ВСХд-15" (холодная вода) внешне выглядят вот так:
http://www.tehnopostavka.ru/kipia/index ... ductID=118
http://www.tehnopostavka.ru/kipia/index ... ductID=119
те которые со стёклышком.

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

lion_sm
Сообщения: 49
Зарегистрирован: 19 ноя 2013, 19:07

Re: Предложения по развитию проекта MegaD

Сообщение lion_sm » 20 дек 2013, 14:50

оффтопик.
dimik2000 - в дом. условиях С-сегмента не хватает? с трудом верится.

Mixman
Сообщения: 395
Зарегистрирован: 17 фев 2013, 23:49
Откуда: Волгодонск, Ростовская обл.
Контактная информация:

Re: Предложения по развитию проекта MegaD

Сообщение Mixman » 20 дек 2013, 16:57

Похоже планируется более 255 устройств.

Andrey_B
Администратор
Сообщения: 5327
Зарегистрирован: 18 мар 2011, 12:06

Re: Предложения по развитию проекта MegaD

Сообщение Andrey_B » 20 дек 2013, 17:13

Другая маска подсети и проблемы нет.

Pavel v
Сообщения: 4
Зарегистрирован: 20 дек 2013, 00:39

Re: Предложения по развитию проекта MegaD

Сообщение Pavel v » 20 дек 2013, 23:02

Всем спасибо за ответы и извинения за флуд.

Sergey Borovkov
Сообщения: 77
Зарегистрирован: 22 ноя 2013, 03:17

Re: Предложения по развитию проекта MegaD

Сообщение Sergey Borovkov » 23 дек 2013, 04:09

Мне не терпится подключить дополнительный функционал в MegaD: датчики давления bmp085 (их можно использовать в вентиляции и для определения атмосферного давления), датчики температуры, средние значения ADC (писал в соседней теме) и тд.

Что хочу предложить:
1. Можно сделать возможность выбора при компиляции, какие модули нужны. При этом все модули могут не влезать в мегу, но всегда можно будет выбрать наиболее нужные. К примеру - не нужен мне dhtХХ - выпиливаю его поддержку, но нужен bmp085 - добавляю ее. Делается довольно легко define'ами.
2. В рамках п.1. сделать web - интерфейс - опцией. Наверное, единственное, что нужно в реальности менять из веб-морды - ip адрес. Для всего остального можно написать небольшой php модуль, который опросит МегаD и выдаст всю инфу о ней - какие выводы как сконфигурены и тд. И из этого модуля можно будет переконфигурить megaD. Это, как мне кажется, даст существенный плюс: экономию памяти на буфере (не надо отдавать большие html), ну и экономию флеша под тексты. Я понимаю, что надо будет добавить код, выдающий в http коротко конфигурацию всех портов, но это вроде несложно, я исходники изучил.

Т.е. для чайников нужно иметь умолчальную прошивку, аналогичную текущей. А для не-чайников, которые могут запустить у себя простейший php, скомпилить новую прошивку, будет возможность получить новый функционал.

ArtSamovar
Сообщения: 184
Зарегистрирован: 07 ноя 2011, 08:45
Откуда: Ступино МО

Re: Предложения по развитию проекта MegaD

Сообщение ArtSamovar » 26 дек 2013, 21:01

Немножко похоливарю...

При всём уважении к тем, кто хочет диммер или кучу значений на ножку (1 раз - свет, два раза - весь свет, три - выключить всё)
Прошу - не забывайте, что в контроллере копеечная память и ограниченная частота и то, что сам МегаДевайс задумывался изначально "простыми мускулами" умного дома... Я тоже не прочь от диммера, но есть шим, а есть шим - есть диммер, хоть на 12В, хоть с доп. детальками на 220В (PIC10F200 + BT137 = диммер с 5-ти рублёвую монету).
Многозадачность решается количеством простых деталей... регистр + 2 Меги = 14 * 2 / кол-во выходов ригистра... Чем не многозадачность? =)

Если просить подарок к Новому Году, хоть и с опазданием, то надо просить оптимизацию всего того, что сейчас есть. :)

За пол-года Мега выросла до пятой версии, появились счетчики, появились порты (относительно 3 версии), работает пошустрее...

Но не настолько быстро, как могла.

Я солидарен с Sergey Borovkov
Пора делать веточку как на гитхабе )))
standard - то, что сейчас,
dev- модульная.

Из предложений - перебрать всю web часть... Кидаться только заголовками. Или реализовать простейшее REST приложение... GET POST
Добавить поддержку UDP (Андрей, не читайте. :D )

Всё освободившееся место от форм и "бешенного" парсинга url в буфер!..
На данный момента буфер под завязку, а столько еще всего хочется ))))

Почему я очень прошу буфер, UDP, частоту ?
1) по TCP скорость получения состояния порта 127-140 в секунду (это на 3.03 версии, извините, обновиться физически не могу) - медленно

2) буфер - это большее количество значений ADC и других состояний. Сейчас ~100 значений в секунду... (Мега может давать 1000 на 16MHz, без хлопот) - это приемлемая запись звука, это красивые графики в реальном времени, это... да это очень много интересного, где нужно измерять аналоговый сигнал.

3) UDP - на сервер вешаем любого демона на одном из (много-много) портов и слушаем мегу... Пусть мега ддосит сервер отправляя UDP пакетики (приблизительно по 4 или 8 кб в секунду - да простят меня математики, если я ошибся), а не на оборот
(на Линухе хоть в файл перенаправляем и обрабатываем аж javascript'ом, хоть сокет, хоть в dev устройство при определённых мучениях ))) echo "11:2" >> /dev/mega ...)

4) Половину функционала благодаря смене протокола вырастет в разы. Счётчики будут считать не до 255, (если с сохранением, то 255*255, сохраняя циклы... + значение) - буфер-то позволит. Короче - UDP это 100% обратная связь от железки.

5) WEB часть - в двух словах... header("CMD pass,11,1,25,12341....); парсить легче, чем _http://ip/pass/?cmd=...&pt=....&ip=..... Только "CMD pass" и цифры с ",". Такой парсинг перейдёт к switch - case. и уменьшит существующую простыню на >500 строк до 50... - а это level_up(buffer)

P.S. Скоро Новый год. С наступающим, форумчане!
Лень — двигатель прогресса...

ArtSamovar
Сообщения: 184
Зарегистрирован: 07 ноя 2011, 08:45
Откуда: Ступино МО

Re: Недостатки MEGAD

Сообщение ArtSamovar » 26 дек 2013, 22:32

Virtus-pro писал(а):....

т.е сама мега серверу будет отдавать в таком виде

Код: Выделить всё

...M6ImFhMyI7czoyOiJpcCI7czoxNDoiMTczLjE5OS44Ny4xMjYiO3M6NjoiY19wb3J0IjtzOjQ6Ijg3NzciO3M6NjoicV9wb3J0IjtzOjU6IjI3MDIwIjtzOjY6I
И почему кстати XML на последнее место? В php даже класс есть встроенный чтобы работать с xml, причем очень удобно.

Ну в общем это только мое предложение
Чуть-чуть математики...
Попробуйте на php написать парсер для строки url и генератор ответа. Без использования функций, кроме, count, strlen, substr и других примитивных и разумеется конструкций. Если вы напишите . У вас будет простыня из кучи if else, case, break. Да - работать будет. Но после этого первой строкой ini_set('memory_limit 'очень-очень мало килобайт');
и попробуйте запустить =)

Это реально запихнуть в чистую мегу, но в мегу, на которой в 32кб памяти:
веб сервер, парсер url, генератор форм, куча проверок на содержание url, проверки портов, генератор ответов серверу, 2 режима работы и куча остального....
Лень — двигатель прогресса...

Sergey Borovkov
Сообщения: 77
Зарегистрирован: 22 ноя 2013, 03:17

Re: Предложения по развитию проекта MegaD

Сообщение Sergey Borovkov » 27 дек 2013, 00:29

ArtSamovar писал(а):Немножко похоливарю...
Всё освободившееся место от форм и "бешенного" парсинга url в буфер!..
На данный момента буфер под завязку, а столько еще всего хочется ))))

Почему я очень прошу буфер, UDP, частоту ?
1) по TCP скорость получения состояния порта 127-140 в секунду (это на 3.03 версии, извините, обновиться физически не могу) - медленно
Зачем быстрее? Я правда не понимаю. Писать звук при помощи MegaD - нецелевое использование устройства. Для передачи звука или видео есть более подходящие девайсы.

Т.е. пожалуйста, если делать абстрактную модель, в которой http сервер будет абстрактным с несколькими методами получения и отправки запросов/ответов, то наверное можно будет сделать отсылку значений не через http и даже через UDP. С меня максимум - уровень абстракции http сервера, когда придет шилд w5100.

ArtSamovar
Сообщения: 184
Зарегистрирован: 07 ноя 2011, 08:45
Откуда: Ступино МО

Re: Предложения по развитию проекта MegaD

Сообщение ArtSamovar » 27 дек 2013, 01:15

Sergey Borovkov писал(а): Зачем быстрее? Я правда не понимаю. Писать звук при помощи MegaD - нецелевое использование устройства. Для передачи звука или видео есть более подходящие девайсы.
Если вы почитаете ветку о голосовом управлении, то Вы поймете, что скажем так, довольно не дёшево и проблематично запихнуть более 3-4 микрофонов в один компьютер...

Давайте отойдём от микрофонов.

Буквально на втором мониторе у меня открыт редактор, в нем 3.12beta1

Как отдаются ответы? Просто читаем порт и отдаём... Всё. Чем это не хорошо?

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

Пока всё хорошо.

А теперь плохо.
Берем 5-6 серверов. (Допустим у нас большой дом, там медиа сервер, резервный, основной... ну любим железки) =)))
И тут по разным причинам они просят у одной меги значения всех портов...
Пакетики падают в очередь, и ответ Меги вырастает ровно на количество запрашиваемых серверов.... То есть в пять раз. (GSM - модем не берем в рачёт, это ещё дольше)...

Постараюсь на 2 вопроса ответить... почему её надо разгонять и желательно (хотя не обязательно) использовать UDP

Вернусь к исходнику...
Там есть
ISR(TIMER1_COMPA_vect) - и это таймер. что он делает?
что то считает, каждые N тактов (точно сколько не помню) и эта мощь используется только на ожидание ответа от сервера (Если я не прав, не бейте)
Это то место, где на 3 версии прошивки, при заданном ip сервере, при выключенном онном, свет с кнопки включался как раз с задержкой этого таймера... В соседней ветке (не читал), но уверен, что обсуждали эту задержку...

Вариант оптимизаии и исполнение желания на команду get_all =)

в этом таймере собираем все порты, пакуем в 1 пакетик и ОДИН пакетик, отправляем. Поверьте, по сравнению с for(0...14) get port i, это вернёт все значения быстрее, к тому же задержка на обработку 5 запросов будет раза в три, в четыре меньше, благодаря этому таймеру и бОльшему буферу



Так вот, снова о пакетиках. TCP состоит их кучи заголовков, общается просто - отправил запрос, получил, отправил данные, получил ответ...
Если отправляется ОДНО значение порта (цифра от 0...1024) , то 60% ответа на TCP занимают заголовки... Ненужные данные...
UDP - заголовки (что, куда, checksum) + data... и работает так: Взяли порт, взяли адрес и отправили наши данные... что с ними, пришли, не пришли - UDP не волнует...

Разницу чувствуете? ТО есть самой Меге будет легче формировать сетевые пакеты, вырастет время отклика...

А ещё лучше возьмем датчик движения, реагирующий на тепло (тоже аналог) и представим ситуацию...
дома кот, балкон, автоматически открывается/закрывается окно . Задача проветрить помещение, пока вас нет дома и не дать любопытному кошаку вылезти на окно (понимаю, что не упадёт, но жена, например паникует) Задача? Да...
Прибавим второго кота и отправим их бегать по квартире.
Берем несколько датчиков по углам...
Решение: если кот на балконе -> закрыть окно, иначе открыть.

Перемещение кота до меги, как в 24 кадров в секунду, после уже кадров 8-10...
Мега в 30% не среагирует на закрытие окна. Кот пулей пробежит, оставив два - три значения на сервере...
Примеров можно придумать куча, и ещё более реальных.


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

UDP в роутере можно перенаправить на TCP
UDP - это поток данных... Примеры приводил выше.


Не надо менять на UDP полностью, его спокойно можно запрашивать с флагом в заголовке на разрешение буферизации порта.... (или портов) и тогда мега до какого то действия будет отправлять данные...

В общем, всё как работало - так и будет, работать, только быстрее =)
Лень — двигатель прогресса...

xboct
Сообщения: 73
Зарегистрирован: 17 ноя 2011, 01:09

Re: Предложения по развитию проекта MegaD

Сообщение xboct » 27 дек 2013, 01:50

ArtSamovar писал(а):Немножко похоливарю...

Из предложений - перебрать всю web часть... Кидаться только заголовками. Или реализовать простейшее REST приложение... GET POST
Добавить поддержку UDP (Андрей, не читайте. :D )
REST-> https://github.com/jjg/RESTduino
https://github.com/thiseldo/EtherShield_RESTduino
ArtSamovar писал(а): 3) UDP - на сервер вешаем любого демона на одном из (много-много) портов и слушаем мегу... Пусть мега ддосит сервер отправляя UDP пакетики (приблизительно по 4 или 8 кб в секунду - да простят меня математики, если я ошибся), а не на оборот
(на Линухе хоть в файл перенаправляем и обрабатываем аж javascript'ом, хоть сокет, хоть в dev устройство при определённых мучениях ))) echo "11:2" >> /dev/mega ...)
стеки с UDP (правда с ограничениями. бродкаст только в 255.255.255.255)
https://github.com/jcw/ethercard
https://github.com/ntruchsess/arduino_uip
у последнего стека полное АПИ от официального шилда на w5100.... правда от этого он стал несколько жирнее.

ArtSamovar
Сообщения: 184
Зарегистрирован: 07 ноя 2011, 08:45
Откуда: Ступино МО

Re: Предложения по развитию проекта MegaD

Сообщение ArtSamovar » 27 дек 2013, 02:27

Поизучаю, спасибо...

Уже спать пора, голова еле думает.
//ip_arp_udp_tcp.c.{h.c}
В нашей Меге максимальные пакетики по 220 байт UDP
и два варианта, либо в ручную заполнять и отправлять, либо выделить буфер и просто отдавать его (хоть наполовину заполненным)

Время считал исходя из этих 220. таймер 10ms (в beta 5ms) 10 (220) * 10 = 2,2 + если поднять частоту, то с натягом примерно 3 кб. (но если по 5ms, то 5(220) * 2 *10 = 4,4 + частота с 12,2 до 16. до 5 кб в секуду.) хотя и 4 хватит с головой, 4000 значений в секунду отправит. с 8 погорячился...

А если отойти от REST и прийти только к заголовкам, как вам?
установка скрипта header("CMD 1,192,168,0,101,path,to,dir,script,php");
некое дерево.
имя -> тип -> порт -> value1 -> value2.....

что будет в меге - представляю, ей парсить по запятой, а дальше тривиальная логика с работой по портам... Генератор форм просто уже будет не нужен - а это только по символам около 2 кб места для буфера
и
header("HTTP/1.0 304 1,192,168,0,101,path,to,dir,script,php"); // ответ сервера, если мы переместили наш скрипт в другое место
мега при этом заголовке пере-конфигурируется сама...
(примеры заголовков тривиальны, не описывают стандарты, но явного запрета в прошивке на них пока не видел)
header("HTTP/1.0 101"); //смена протокола...

от меги header("HTTP/1.0 201"); смена настроек
от меги header("HTTP/1.0 204"); порт выключен
от меги header("HTTP/1.0 205"); сброс счетчиков

и тому подобное...

Такие ответы парсить куда легче на сервере, чем разбирать html регулярками...
Управление ajax'ом... всего одним спец. заголовком, которй мега будет понимать...
Трафик почти в ноль, парсинг команд с обеих сторон проще, да много чего классного...

Заговорился... =) Извнините...

За ссылки спасибо. Завтра и почитаю.
Лень — двигатель прогресса...

alexsis_76

Re: Предложения по развитию проекта MegaD

Сообщение alexsis_76 » 27 дек 2013, 02:58

ISR(TIMER1_COMPA_vect)
из таймера делают SysTick , по UDP,экомия памяти получится внушительная

Sergey Borovkov
Сообщения: 77
Зарегистрирован: 22 ноя 2013, 03:17

Re: Предложения по развитию проекта MegaD

Сообщение Sergey Borovkov » 27 дек 2013, 22:11

По поводу передачи звука - это спокойно пропихивается через tcp, если допустить, что задержка может быть 0.1 секунды. И слать блоками по 200-300 байт. Вешаешься на прерывание ADC и вперед.

Функционал получения за один запрос данных всех ног - надо сделать. Для этого надо в любой момент иметь данные по всем ногам, и все. Т.е. данные по ADC получать в прерывании и сохранять его.
Я бы еще добавил запрос, получить сразу полную конфигурацию устройства.

alexsis_76

Re: Предложения по развитию проекта MegaD

Сообщение alexsis_76 » 28 дек 2013, 03:19

Добрый день попробывал udp реализацию данного девайса поубирал все формы поуменьшал буфера , вывод следующий за щет удаления форм освободилась много памяти программ , значительно меньше оперативной памяти (особенно если учесть что ее там всего ничего),большого прироста быстродействия не заметил,зато удобства работы значительно поубавилось, вообщем я думаю что не надо выдумывать ничего нового а просто заняться оптимизацией существующего.

ArtSamovar
Сообщения: 184
Зарегистрирован: 07 ноя 2011, 08:45
Откуда: Ступино МО

Re: Предложения по развитию проекта MegaD

Сообщение ArtSamovar » 28 дек 2013, 11:27

alexsis_76 писал(а):...значительно меньше оперативной памяти...
/* А если заполнять его в таймере? (или только ацп, или все порты в него и отдать строкой) */

Код: Выделить всё

if ( adc_check_flag == 1 )
{
    if ( adc_timer > 1000 )
    {
        for ( i = 0; i < IO_SIZE; i++ )
        {
            ....
            if (_port_type[i] == 2 || port_letter == 'A' )
            {
                if ( _port_misc[i] < 1024 && _port_m[i] != 0 )
                {
                    ...
                    ...
                    
                    port_misc_cur[i] = my_val; 
                }
            }
        }

        adc_timer = 0;
    }
}
Лень — двигатель прогресса...

captain
Сообщения: 18
Зарегистрирован: 29 дек 2013, 13:51

Re: Предложения по развитию проекта MegaD

Сообщение captain » 29 дек 2013, 14:49

1. Можно сделать возможность выбора при компиляции, какие модули нужны. При этом все модули могут не влезать в мегу, но всегда можно будет выбрать наиболее нужные. К примеру - не нужен мне dhtХХ - выпиливаю его поддержку, но нужен bmp085 - добавляю ее. Делается довольно легко define'ами.
Очень интересное решение,достаточно трудоемкое,но мне кажется в будущем это может окупится! Ну и конечно же при таком пути надо использовать систему контроля версий.

andron
Сообщения: 1
Зарегистрирован: 23 янв 2014, 06:39

Re: Предложения по развитию проекта MegaD

Сообщение andron » 23 янв 2014, 06:59

Очень понравился мегадевайс. И возникло такое предложение: пожертвовать двумя пинами и добавить поддержку USART, дав ыозможность серверу отправить туда команду(несколько байт) и получить ответ. Это даст посредством мелкого контроллера (и простой програмки в него) реализовать подключение датчиков (1Wire, IIC , DHT) , LCD , расширение портов , диммер, либо свои собственные задумки . А если еще дать возможность мегадевайсу самому отдавать или принимать команды в/из USART то я с трудом уже представляю, что из этого можно наворотить. Кроме того легко можно сделать гальваническую развязку, прикрутить 485 интерфейс и навешать несколько таких доп.контроллеров на одну шину.

Wadim1
Сообщения: 44
Зарегистрирован: 22 фев 2014, 23:22
Откуда: МоскоуСити
Контактная информация:

Re: Предложения по развитию проекта MegaD

Сообщение Wadim1 » 23 фев 2014, 20:54

+1

Ответить