Радиоуправляемый выключатель своими руками. Часть 4 — Центр управления

[termsl]

Очень не дурно, однако веб сервера NASа очень скоро начнет не хватать, особенно для графиков и аналитики.

[shtirlitsus]

про шифрованный обмен не думали?

[avstepanov]

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

[shtirlitsus]

бренд ethernet-трансформатора доставляет

[mnemoLinux]

Почему бы не сделать сразу usb nrf24l01+ устройство для сервера на базе какой-нибудь avr'ки?

[Helius]

+1
У меня на USB проводе к серверу подключена связка Atmega32U4 (китайская arduino pro micro) + nrf24l01, первая имеет аппаратный USB, хотя можно было воспользоваться мостом usb-com, их в китае по полтора бакса за штуку вагонами отдают, и взять еще более простую AVR-ку.
Залил модифицированый пример usb-cdc от Atmel, минимум правок для обмена с радио частью, платка выплевывает принятые пакеты в json в виртуальный порт.

На серваке python скрипт выгребает строки из /dev/ttyUSB0, логгирует, запускает соотв. скрипты, в зависимости от принятых данных, (управлению вентиляцией и влажностью).

Но видимо сейчас это тренд — wifi в каждый выключатель, linux в каждое реле )

[aterentiev]

>Но видимо сейчас это тренд — wifi в каждый выключатель, linux в каждое реле
пару месяцев назад меня за это чуть не линчевали

[mnemoLinux]

Отличное решение, только бы я наверно сырые данные в виртуальный порт слал. Еще на ум приходит Raspberry Pi в качестве главного устройства, тогда вообще nrf24l01+ можно к нему прямо через GPIO прицепить, но тут уже зависит от поставленной задачи, кому-то нужны мощности посерьезней.

[Helius]

Сначала я думал в приемнике на AVR делать какой то парсинг по типам датчиков, наприме «давление», «температура», «выключатель», обрабатывать их посылки, а в порт выкидывать уже готовые ascii строки, типа

temprerature: +22C

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

Тогда я решил гнать сырые данные но в json, его легко сформировать на стороне AVR, а так же можно всегда прочитать из порта

cat /dev/ttyUSB0

и убедиться что все верно, и его легко парсить на серваке. Пример с DHT22:

{"type":1,"uid":2,"data":[1,211,0,246,0,0]}

DHT22 возвращает 4 байта данных, из которых очень легко получить значения температуры и влажности на Python:

Humidity = (value[0]*255 + value[1])*0.1
if (value[2]&0x80):
	Temperature = (value[2]&0x7F)*255 + value[3]
else:
	Temperature = (value[2]*255 + value[3])*0.1
print "Climat is ", Temperature, "C, ", Humidity, "%"

Таким образом, код на AVR не нужно менять при добавлении в систему новых датчиков, и на серваке легко работать с этими данными на том же Python.

[avstepanov]

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

[avstepanov]

В планах есть задачка сделать такой шлюз RF24<=>USB, но руки пока не дошли.

[mlu]

Посмотрите в сторону nRF24LU1+, там как раз всё в одном. На ебее платки продаются.

[avstepanov]

Спасибо! Интересный чип — надо попробовать.

Тогда моя система может существенно упроститься: в «розетки-выключатели» поставить nRF24LЕ1, а к «большому брату» прикрутить nRF24LU1.

Надо будет только с «новым» МК (в составе чипов) разобраться.

[mlu]

Заодно и простенькое шифрование сделаете вместе с «hardware AES co-processor» :) Жаль, что LE1 и LU1 пока сильно дороже «обычных» L01.

[MaksMS]

Обратите внимание на вариант переходника из USBasp. Там можно поправить клиентский код и реализовать сырые данные, описанные выше в комментариях. Все же 3 доллара это дешевле, чем nRF24LU1+ за 10$, где надо ещё разобраться с USB-шной частью…
Про nRF24LЕ1 тут уже я постарался «разжевать» и переход с ардуино+nRF24L01 на его получается не такой уж сложный.

[Muzzy0]

Любопытно.

Возможно, я отстал от жизни или слишком профессионально зашоренный, но мне кажется, что такие устройства надо собирать в сеть не на Ethernet, а на чём-то типа RS-485. А вот шлюзом между ними и «гражданской сетью» будет контроллер, который ими управляет.

[MaksMS]

Тут не сеть на Ethernet, он тут для подключения к «большому брату» нужен.

Хотя подключение к «большому брату» nrf24l01+ реализовывал через usb используя готовую плату USBasp -тоже неплохо выходит…