Локалка на микроконтроллерах

Я увлекаюсь идеей умного дома и уже давно. В основе умного дома я вижу децентрализованную сеть сенсоров и исполнительных модулей, т.е. равноправных модулей способных обмениваться информацией непосредственно друг с другом. После определенного опыта домостроения на радиомодулях rfm12, проводной сети на rs485, было решено попробовать сконструировать Ethernet микроконтроллерную сеть с помощью модулей enc28j60 и TCP стека написанного Lifelover’ом (за что ему очередное огромное спасибо). О реализации такой сети и пойдет речь.

В качестве интерфейса для настройки и просмотра параметров модуля был естественно выбран протокол http. Возможность настройки с помощью браузера решила мою главную проблему – создание софта со стороны компа. После этого http сам собой напросился как протокол для обмена данными между микроконтроллерами. В результате получилась забавная локальная сеть из микроконтроллеров, каждый модуль в которой и веб сервер и клиент. Функционал на мой взгляд может быть использован не только в умном доме.
Процессорный модуль я решил взять самый простой и доступный. Выбор пал на плату arduino mini c atmega328 на борту. Эта плата была выбрана по нескольким причинам:
— во-первых, ардуины широко распространены и, с учетом труда на изготовление промышленной платы, цены на них на ибее вполне адекватные (конечно же ИМХО);
— во-вторых, готовая плата позволит избежать кучи ошибок возникающих при изготовлении своих плат;
— я нашел очень компактные модули (я так хорошо не спаяю);
— набрав на ибее arduino, вываливается огромное количество всяких разных плат периферии к ним, в том числе и плата Ethernet интерфейса с enc28j60 на борту;
— легче для новичков не знающих ЛУТ и т.п.;
В общем плюсы налицо.
Я не использовал среду разработки arduino, поэтому все кишки-бутлоадеры из ардуино долой, программируем через обычный програматор.

Итак железо: arduino mini (далее просто arduino) + enc28j60, стек — TCP/IP от Lifelover’а, IDE для разработки софта – AVRStudio 4, язык – C.

Проще всего рассмотреть работу сети на примере двух модулей: модуля реле и модуля датчиков контакта (кнопок).
Модуль реле:

Модуль кнопок:

Как видно из картинок практически все сделано на покупных модулях. Самодельное – кросс-плата между Ethernet и arduino с разъемом питания и более мощным стабилизатором на 3,3 В, т.к. та кроха, что стоит на плате arduino, не внушает доверия. Также на кросс плате установлен разъем для удобного программирования по spi. В принципе, те кто не умеет разводить платы могут легко и просто сконструировать кросс плату на макетке.
При первом включении всем устройствам назначен один ip адрес 192.168.0.254 и один MAC адрес. Естественно что после включения необходимо задать сетевые параметры устройства. Рекомендую придерживаться последовательности: подключил к компьютеру по сетевому кабелю комп<->комп, настроил и только после включай в сеть, т.к. подключив более одного нового устройства сразу в сеть, последняя начнет глючить, switch не сможет разобраться в устройствах с одинаковыми MAC адресами и т.д.
Настройка
Настройка производится с помощью компьютера по веб интерфейсу. Для этого вводим в браузере адрес устройства (по умолчанию адрес новых устройств 192.168.0.254). После чего браузер делает запрос методом GET на порт 80 (по умолчанию для http), который обрабатывается модулем и в ответ генерится вот такая веб страничка:

По адресу 192.168.0.254/admin нужно настроить сетевые параметры.

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

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

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


Все параметры запомнятся в EEPROM через минуту после простоя устройства (простоем считается не изменение параметров в течение какого-либо времени). Регистрация устройства состоит из ввода имени устройства. Она необходима, потому что в каждом модуле может существовать несколько логических устройств, например, кнопки + диммер, датчик температуры + датчик давления и т.д. И для корректной адресации в дополнение к IP адресу необходимы уникальные имена устройств. Максимальная длина имени пока только 8байт. После регистрации устройство начинает функционировать по полной программе. На главной странице устройства появляются ссылки modify и delete.

Delet’ом можно отменить регистрацию. По ссылке modify можно увидеть параметры устройства.

Параметр Group пока что не выполняет никакой полезной функции, зарезервирован на будущее.
Параметр state для модуля реле соответствует восьми битам состояния выходных пинов, к которым подключен блок реле. Для включения нужно установить соответствующие биты, для выключения нужно проинвертировать байт включения и добавить девятый бит = 1 (флаг выключения). Значение вводится в десятиричном коде тремя цифрами в поле state, что позволяет вводить девятибитные числа (в двоичной системе). После нажатия кнопки OK значение присваивается порту ввода/вывода. Затем, кликнув в браузере по строке адреса, мы можем увидеть всю строку с введеными параметрами, она имеет вид типа 192.168.0.220/?device=sock220&group=0&state=1. Можно включить реле 1 просто вводом строки 192.168.0.220/?device=sock220&state=1. Если эта строка включает реле, то выключать надо строкой 192.168.0.220/?device=sock220&state=510.
Теперь мы можем управлять реле с компьютера, телефона и т.п.
Производим аналогичные настройки сети в модуле кнопок, залезаем на главную страничку веб сервера, регистрируем устройство. Входим по ссылке modify(редактировать) и видим что параметр state не редактируемый, но при нажатии на кнопку он принимает соответствующее значение (чтобы это увидеть в браузере нужно обновить страничку), что типично для модулей датчиков.

Запоминаем эти значения и идем дальше по ссылке event(событие). В графе eventX вписываем значение соответствующее какой-нибудь кнопке, а в графе Message вписываем содержимое сообщения, которое пошлется модулем в сеть при нажатии на эту кнопку.

Таким образом, при записи в поле Message строки “192.168.0.220/?device=sock220&state=1” (той самой которую мы посылали в модуль реле, только с одним параметром state и без http:// заголовка) на адрес 192.168.0.220 будет послано сообщение “GET /?device=sock220&state=1 HTTP/1.0\n\r\n\r”, что в свою очередь включит реле на пине 1 модуля релюшек с именем sock220.

По аналогии, были разработаны следующие устройства:

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


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


Модуль конвертор сигналов с ИК пульта с протоколом RC5. Модуль позволяет посылать сообщения о нажатии кнопок ИК пульта, т.е. управлять реле и т.п.


Модуль RFID меток на чипе RC522, который может посылать сообщения соответствующие коду RFID метки подносимой к сенсору. Соответствие задается в настройках. Модуль на фото сделан на отладочной плате arduino nano. Это плата с atmega328, но в отличие от мини версии имеет конвертор usb-com: ft232. Поэтому на этой плате и удобно отлаживать все модули с помощью гипертерминала.
Код для модуля RFID был нагло мной переписан из какого-то примера для arduino, без особого понимания процесса, так что все вопросы к первоисточнику см. аттач и даташиту RC522.pdf.


А вот и вся номенклатура плат:


Все приобреталось на ebay по следующим ценам:
Enhancement V2 Pro Mini 16​MHz(3.3V/5V adjustable) MEGA328P(Arduino-Compatible) — $10,4 (схема)
ENC28J60 LAN Module — $4,72
PIR Motion sensor — $6
Digital Temperature Sensor module DS18B20 V2.0 — $6,5
Arduino IR Remote Control 0038B Module — $7,98
Arduino Mini 2x4 Single Keypad — $8
8-Channel 5V Relay Module for Arduino — $15
RFID module Kit 13.56 Mhz with Tags SPI Write and Read For Arduino — $22
но замечу цены на многие модули падают, причем неплохо.

Схемы на платы периферии не привожу потому, что платы либо очень простые, просто три контакта GND VCC Data от датчика до разъема пробрасываются + подтяжка, либо мне неизвестны и цеплялись соответственно подписям ног на плате, например, ethernet и RFID цеплялись по SPI, а датчик движения по тому же GND VCC Data. По плате с реле, рекомендую брать с дополнительной гальванической развязкой перед самой релюшкой (см. фото), чтобы при КЗ испортилось только реле, а не весь модуль. Все трехпроводные датчики у меня цеплялись на следующие пины arduino mini: GND,2,3 (GND, PD2, PD3 пины микроконтроллера).

В заключение скажу, что конечно все устройства ещё сырые, в некоторых модулях в качестве питания для датчика используется логическая 1 на выходе процессора, но статья в первую очередь рассчитана на тех кто сможет понять исходники и довести их до ума под свои задачи. А у меня, как всегда, к концу года коллапс со временем и поэтому выкладываю всё как есть.
ПП кросс платы рисовалась в шпротеусе.
  • +6
  • 25 ноября 2012, 17:44
  • Stepani
  • 3
Файлы в топике: ПП.zip, rfid.zip, uc_ethernet_sources_17.12.12.zip

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

RSS свернуть / развернуть
детектор движения работает нормально, проверяли?
все хочу попробовать их…
0
  • avatar
  • kest
  • 25 ноября 2012, 18:20
Долго не гонял, только в тестовом устройстве. Но в принципе гонял схожий девайс: купил в леруа мерлене бытовой датчик движения для ламп, с креплением в подрозетник, разобрал, там две платы внутри, одна — бестрансформаторный блок питания, другая — непосрадственно сенсор, подключался к питанию абсолютно аналогично этому датчику. ББП выкинул, подцепил к своей схеме — работал нормально.
0
Вероятно, название статьи не соответствует содержимому. Так и написал бы модули для умного дома. Причем тут локалка ((.
+1
Вероятно, но я решил что сеть состоящую из таких серверов-клиентов можно применить не только в умном доме. И вообще я не видел конструкций именно с такими сетями на МК. Поэтому и обозвал так.
0
о б-же
люди вообще не имеют представления о целях и задачах под которые разрабатывались протоколы
что ethernet, что wlan

и где тут умный дом?
habrahabr.ru/post/160067/#habracut вот это еще можно назвать умным домом
-1
а я обещал рассказать про умный дом?
+1
Мне кажется, что такое решение потребует большого количества соединительных кабелей, и несколько роутеров.
+1
ну смотря что проектировать, вообще в каждом железе можно запрограммировать несколько сенсоров, так что в идеальном случае один модуль сенсоров на комнату… сколько у вас комнат в квартире?
0
а если нужно подцепить датчик температуры и детектор движения, которые физически находятся в разных частях комнаты?
0
мне тоже кажется, что эзернет каждому датчику — это как-то слишком.

Один модуль сенсоров на комнату — это да. Но от этого модуля с сенсорами всё равно нужна какая-то сеть.
0
Вообще, ИМХО, скомбинировать датчики в одном модуле с помощью моего кода очень просто, копируете си исходник сенсора в проект, добавляете указатель на его структуру в global_dev_list, увеличиваете количество сенсоров Q_DEVICES на 1, компилируете.
А как датчики от модуля пробрасывать — сильно зависит от рельефа местности :). Я предполагаю ставить модуль выключателей и реле в щиток, а дальше по одному модулю на комнату без разброса сети датчиков, т.к. в комнате предполагаются датчик температуры, IR, движения, ну может в будущем и датчик освещенности.
0
вообще в каждом железе можно запрограммировать несколько сенсорово
Тогда другое дело, однако в таком случает придется провода во всей комнаты тянуть к модулю.
+1
Спасибо за статью.

В основе умного дома я вижу децентрализованную сеть сенсоров и исполнительных модулей

А почему именно децентрализованная сеть с протоколами, базирующимися на TCP/IP?

ИМХО, логично сделать сеть типа «шина» (например, 485+простой прикладной протокол) с одним «контролером/мастером» который опрашивает датчики/исполнительные устройства, консолидирует данные, принимает решения и т. д.

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

Или я неправильно понял Вашу концепцию?
+2
А почему именно децентрализованная сеть с протоколами, базирующимися на TCP/IP


присоединяюсь к вопросу, ибо (ИМХО, подчеркиваю) вроде как проще и логичнее сделать как пишет выше e_mc2:

сеть типа «шина» (например, 485+простой прикладной протокол) с одним «контролером/мастером»
0
Потому как в централизованной сети выход контроллера из строя кладет всю систему. В прочем тот же эфект тут мы получим при выходе хаба из строя.
Вот если в модель e_mc2 в замен мастера ввести шлюз (конвертор HTTP<->шина), задача которого предоставлять интерфейс пользователю, а не управление всем и вся, то будет прелесть. Выход из строя шлюза не помешает* работе термостабилизатора или насоса накачки воду в бак на крыше.

(*) Имеется ввиду если шлюз не положит шину физически, путём КЗ или высоковольтного пробоя. Тут все равно надо предусматривать аварийную работу узлов при изоляции от сети.
0
ясно:) вообще да, шлюз гораздо лучше какого-либо мастера
0
Децентрализованная она принципиально :), потому что не воспринимаю умный дом как нечто статичное, всегда что-нибудь захочется добавить, что-то убрать и каждый раз переписывать мастера сложно. Потом выход из строя мастера действительно положит всю сеть, а выход из строя какого-либо узла децентрализованной сети только этот узел. Да, хаб тоже слабое место, но тут можно надеяться на современные технологии, все ж не первый день их разрабатывают.

А ethernet с TCP/IP она потому, что считаю, всё-таки, данную технологию гораздо более надежней. Кольцо rs485 очень легко убить, где-то провод оборвался, где-то закоротил, какой-нибудь модуль глюканул и выставил логический 0 на шину и всё, кольцо мертво. Потом, для надежности туда надо вводить гальваническую развязку (), а следовательно брать откуда-нибудь питание для отвязяной части… и понеслось, и поехало, получается система ничем не проще ethernet'a, но только разрабатывать её нужно самому. Я повозился с rs485 вот здесь, ищу новые пути.
0
Надежность этого решения — вопрос спорный.
Во первых, сам ethernet вполне охотно ложится.
Во вторых, подобная констрекция из нескольких плат держащихся на разъемах — не особо надежна.
В третьих, ENC28J60 имеет не лучшую репутацию. На редкость баговита и есть репорты, что периодически отказывается работать даже при выполнении всех рекомендаций эрраты.
Ну и в четвертых, при всем уважении к Lifelover'у — его стек тоже не самая надежная и полная реализация TCP/IP.

Ну и чисто по удобствам — Ethernet сеть достаточно сложная как в аппаратной, так и в программной реализации, что не лучшим образом сказывается на цене и надежности решения, а кабель ее довольно толстый, жесткий и неудобный для опутывания им всей квартиры. По этим причинам лично я бы предпочел что-то другое.
+1
что?
0
Конкретизируй вопрос.
0
что вместо ethernet'а продпочел?
0
Ничего. Я не делал умный дом. И вопрос выбора сети связи для него — весьма больной.
Лично меня в этом вопросе привлекают беспроводные сети, из-за их удобства. Хотя есть определенные проблемы с надежностью и защищенностью, поэтому скорее всего их нужно комбинировать с проводными. Ну и тоже не самое дешевое решение.
0
Ну если ориентироваться на высокую надежность, то хаб/свич тоже надо устранять, а каналы связи дублировать. Иначе с хабом вполне может случиться та же беда, что и с RS485 — пробъет датчик или ключ, к примеру, контроллер сгорит, броском напряжения убъет хаб и все. Вообще высоконадежные решения это отдельная область, там своих заморочек выше крыши. Причем главная это не обеспечить независимость функционирования, а обеспечить централизованное управление при децентрализованной обработке.
0
mesh
0
В любой системе с софтом самое ненадёжное — это софт. Так что чем меньше всяких стеков, протоколов, оопов, xml-ей, проще говоря, чем дубовее сделано — тем лучше. Простая шина на RS485 откажет с куда меньшей вероятностью, чем нагромождения (пусть якобы децентрализованные). Не зря RS485 закрепилась на производстве давно и надёжно.
+1
Ты будешь сильно удивлен, попав в клауд. Там самое ненадежное, как раз, железо.
0
Ну это уж точно неудачный пример — там задача софта свести на 0 возможность отказа по вине железа, так что отказ из-за железа = отказ из-за софта.
0
Наоборот, это как раз весьма удачный пример опровергающий тезис о ненадежности софта. И есть немало решений, которые вполне нормально живут на таком железе, на котором юзер не выдержал бы и дня из-за постоянных поглюкиваний, а уж на нормальном, но периодически выходящем из строя — легко. Замечу, что отказ из-за железа там не эквивалентен отказу из-за софта, поскольку отказ может быть из-за недостаточного количества железа, софт при этом вполне исправно функционирует в дежурном режиме и когда железа становится достаточно, восстанавливается и продолжает работу с того места где остановился.
0
Интересное чтиво про падение амазонского облака.
0
Спасибо, я в курсе :)
0
То, что шины на базе RS-485 закрепились — это да, но Ethernet (даже на основе оптики) — это современные промышленные решения, это я могу показать как очевидец, сопровождавший АСУ прокатного стана. Чтобы у людей не складывалось ошибочного мнения, я покажу разводку сети такого стана (хотя это внутренняя документация).

Ссылка на фото будет работать не всегда:

Разводка сети прокатного стана Danieli

Как видите: оптика, витая пара (Ethernet, Profibus и вероятно что-то там было ещё).

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

Самый простой пример из практики. Есть такая хрень, называется колокол. Она служит для того, чтобы проволока в кольцах, падая, набрасывалась на этот колокол и превращалась в бухту. Не суть важно, главное то, что эта хрень при своей работе очень сильно трясётся от движений туда-сюда обратно. Так вот, какой-то «ихний» инженер придумал коробку с контактами крепить на каркас, который держит конструкцию колокола. У нас (автоматчиков) периодически из-за чего-то происходила разборка стана (это пипец какая хрень) именно на этом участке и никто не мог понять причину, пока однажды мы не завинтили все винтики в этой самой коробке. Оказывается от тряски терялся зажим у контактов, что приводило к необъяснимому неотлавливаемому багу и разборке стана. А когда что-то не работает, то обычно винят автоматчиков, ибо это их работа — всё знать. В этот раз мы написали — электрики не проводил ТО как следует, причина — вибрация.

И таких историй на 1000 и 1 ночь.
0
К слову сказать, как очевидец пуско-наладочных работ на относительно новом полностью автоматизированном металлургическом производстве, могу ответственно доложить: железо и софт в промышленности не менее глючен, поэтому доводка всего идёт достаточно продолжительное время.
Глючен — это мягко сказано. При том, что всё это стоит бешеных денег.
0
В своей «поделке» на тему умного дома я тоже изначально серьезно задумался о надежности системы. Планировал дублировать основные узлы, датчики и каналы связи. Но система становилась мостроподобной.

Тогда я поступил радикально, тупо забил на это все, реализовал все максимально просто. Изначально все системы умного дома дублировали существующие вещи, но не замещали их. Если, вдруг, система накроется медным тазом – ничего смертельного не случится, входную дверь я открою обычным ключом, свет буду включать/выключать обычным выключателем, если кто-то позвонит в дверь – оторвусь от компа и пойду смотреть в обычный дверной глазок.

ИМХО, в данном случае, особо увлекаться надежностью системы нет смысла.
+1
ИМХО, в данном случае, особо увлекаться надежностью системы нет смысла.
Категорически поддерживаю. Высоконадежные системы нужны там, где их создание, установка/настройка и поддержание в работоспособном состоянии дешевле, чем стоимость решения проблем вызванных недостаточно надежностью. Потому как не дешевое это удовольствие.
0
согласен, что все должно быть в меру, в том числе и надежность, дублировать узлы и каналы я тоже не собираюсь, но в то же время это ведь не значит, что все должно собираться на соплях. Использованные компоненты вроде не супердорогие. Да ethernet жрет много ресурсов, но он и другие плюсы дает, во-первых: простой модуль согласования с компом, во-вторых: вот сделали мы сеть датчиков — всяко захочется и музыку и видео гонять в УД, так берем и гоняем по тем же проводам, т.е. просто совместимость с ethernet других систем позволяет их встраивать в такой умный дом. А совместимость это большой плюс и уже много где является решающим фактором.
0
Добавлю, что, на самом деле, ориентация на TCP/IP может быть правильным решением в долгосрочной перспективе. Во-первых, нижний уровень может быть не только Ethernet (хотя и он не так уж плох, да и есть много где). Во-вторых, он дает основу для высоконадежного решения, если вдруг такое понадобится. В-третих, куча готовых протоколов и решений на все случаи жизни. Для авр-ок это может слегка и тяжеловато, но есть много других контроллеров, куда стек ложится без напряга по ресурсам.
0
Согласен, в этом контексте Ваш подход смотрится однозначно выигрышно.
0
Много лет тому назад, когда мы строили свой коттедж, я заложил в штробы сразу 2 UTP кабеля на будущее (кроме всего остального). На это ушло пару бухт, зато, когда у нас появился телек с поддержкой HD и DLNA, я смог со стороннего сервака через miniDLNA гнать кино с высокой чёткостью. Сеть давала возможность его через себя «прокачать». Это уже часть Умного Дома, когда я могу выделить домашний мультимедиа сервер с видеотекой и по одной из витых пар раскидывать контент по этажам.
После работы в промышленности мне захотелось сделать то же самое уже на оптике. Это когда-нить в будущем. Вторую сетку я закладывал для телеметрии как раз. Так что всё у вас нормально, только нужно разделить телеметрию и медиа, ибо медиа может перегрузить сеть, если вы будете делать как я.
0
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
Хаб хоть и слабое место, но выборр их достаточно широк. И в случае поломки хаба не составляет большой проблемы зайти в ближайший компьютерный магазин и купить любой на выбор.
Чего не скажешь о самодельном устройстве централизации. тут надо либюо сразу делать с запасом, либо потом подывать инфу, заказывать комплектуху, паять.
0
кольцо можно убить, но так же можно и оживить. Удаление с шины закоротившего устройства поднимает её, ведь так? Надо только решить вопрос поиска сбойного модуля (чему могут помочь банальные светодиоды рх-тх).
0
да, можно, но модули могут быть широко разбросаны, а некоторые ещё и быть расположены в труднодоступных местах. Так что можно, но сложно.
0
Делаем сплит сети, хоть половинным дилением, хоть золотым сечением, хоть все разом. Да, нужно время. Но сразу можно проверить только «жизненно важные» функции, а остальное как будет время.
0
Не проще ли для подобных задач использовать сеть типа CAN? Контроллеры с ним нынче не редкость.
+1
Был выбран простейший :) контроллер. Хотя у самого лежит stm32 демо плата с CAN на борту, но подозреваю что он тоже не такой простой.
0
кстати, я смотрю, вы имеете опыт с этой шиной, написали бы обзорную статейку, думаю не мне одному интересно было бы.
0
Если раньше для обмена данными с веб серверами мы посылали запрос методом GET, по получении которого вебсервер генерил страничку, то теперь мы будем использовать метод POST, т.к. страничка нам уже совсем не нужна.
POST тоже подразумевает выдачу странички. Кромет ого, он подразумевает передачу данных в теле запроса. Если же подразумевается, что информация передается в URL, а ответ не нужен — разумней использовать или GET, или HEAD (который как раз подразумевает, что в ответе не будет странички — только заголовки).

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

P.S. «Registration», все же. А лучше — «Register» («зарегистрировать»).
0
  • avatar
  • Vga
  • 26 ноября 2012, 00:23
Спасибо за замечания. Тут я конечно полный новичек (в http), просто нигде не увидел явным образом, чтобы на POST нужно было бы страничкой отвечать. обычно «При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса.», ну я и отвечаю «HTTP/1.0 200 OK».

А смысл использовать заводские платы следующий: при написании первых статей про умный дом ко мне обращались люди, которые не умеют разводить платы, но умеют программировать. А кросс плата очень простая, её можно и на макетке напаять, или вообще проводами %)). К тому же, поимев опыт с заказом плат, считаю, что дуино платы с китая вполне себе вариант.

А в чем у вас сомнения в надежности?
0
обычно «При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса.»
«Сообщение об итоге...» — это и есть страничка. Впрочем, всегда можно ответить Content-Length: 0 или просто оборвать соединение и клиент поймет, что никакой страничкой ему отвечать не собираются. Но лучше все же HEAD — тогда никто и не ждет ответа, кроме как HTTP/1.1 200 OK (плюс заголовки, опционально).
А смысл использовать заводские платы следующий ...
Для прототипов так делать можно (ну и кто не умеет паять — тоже вполне может экспериментировать с прототипами), но для «боевого применения» я бы предпочел собрать все на одной плате. Можно их и заказать, в принципе — PCB Prototyping Service у китайцев довольно недорогой.
А в чем у вас сомнения в надежности?
Болтающиеся разъемы с висящими на них платам надежностью никогда не отличались. PLS/PBS пары и вовсе требуют правильного применения для обеспечения хоть какой-то надежности. В частности, не стоит соединять платы просто однорядными гребенками — болтаются.
0
ну так это и есть прототип. Поэтому и болтающиеся разъемы и не закрепленые платы. Хотя для прототипа по-моему достаточно надежно, есть крепежные отверстия на дуинах, корпусуй-нехочу называется :).
0
Вот именно что не хочу, проектировать корпус для такого клубка плат — бррр)
0
Вы бы дополнили свою статью, а именно расписали где какой модуль брали с ссылками на покупку и ценами, ссылками на схемы их, если есть, ну и можно было другими модулями расширить, например модулем индикатора и т.д.
0
eBay, очевидно же. поиск там имеется — получаете актуальную информацию по цене и количеству. Да и мазазинов с полобным барахлом предостаточно.
Постить в тело статьи не вижу смысла, так как начнется очередной холливар на тему «стс говневый магазин, вот я блал на дх — дх говно, вот я брал на стс....»
0
Сначала подумал, что автор статьи, а потом прочитал и забыл…
P.S. Есть такая «наука» — Словоблудие.
0
дополнил опорными словами для поиска и ценами по которым покупал я, ссылки не дал так как покупались платы мной давно и прямых ссылок уже на них нету. Расширение сети другими модулями предполагается в будущем, какими ещё не придумал. Я бы скорее начал программировать сценариста, но уже на более мощной stm32, так как на него у avr ресурсов не хватит. Индикатор — не перспективно, лучше тогда програмку на андроид со сбором данных и отображением, осталось только под андроид программировать научиться ;).
+1
Да, стало понятнее. А по поводу цен — я ставлю на ebay товар на ожидание и некоторые дают скидку
0
ну вот, только опубликовал и тут же прилетела ссылка на похожий проект :)
0
Да, это началось вот с чего: Умный Дом по Ethernet. После этого топика многие хотели повторить сей девайс, я в том числе, ибо собирался почти на коленке.
Стек там используется вот этот: HTTP/TCP with an atmega88 microcontroller (AVR web server).
По теме можно было добавить и вот этот ресурс: avr-uip (Port of uIP tcp/ip stack from Adam Dunkels to use with AVR microcontrollers).
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.