Ну типа умный дом в сотый раз
Короче, я всячески читал литературу и понял, что это капец и засада - делать умный дом. Народ что только не придумал. Я почитал-почитал и решил так.
Разделяем все на три логические сети:
Итак, вариантов физической реализации самой сети реального много всяких - 1-wire, CAN, I2C, Ethernet и прочие всякие извращения. В принципе, самый простой и в лоб - это 1-wire:
Все как бы круто, но гарантии, что это будет работать на больших расстояниях и большом количестве датчиков (у меня выходит больше ста) особой нет. Зато реально дешево, можно даже адаптер не покупать никакой, а все завязать на GPIO. Короче, как бы халява. Но есть такая штука - если головное устройство померло, то все. Сеть тоже померла. Ну и все сенсоры могут работать только в пассивном режиме. Ну и выбор сенсоров не очень велик, потому как перед каждым должен быть чип с уникальным ID.
Решил не делать так - не уверен, что прокатит. Проводов накидаем побольше - тем более, что Cat5e стоит не дорого, а на них можно будет мутить уже любую экзотику.
Тогда типа CAN - экономим провода и до кучи получаем хорошую надежность и устойчивость супротив всяких там помех:
Тут все круто, но есть засада. Распайки под CAN есть на большом количестве STM32 чипах и даже более старых всяких 8битных уродах. А вот под Raspberry можно например через USB это дело пускать - но денег стоит прилично.
А с другой стороны, нахрена вообще CAN, если сеть под него физически такая же как и под LAN? tcp-ip оно как-то проще писать и здоровее и вообще.
Короче, нахрен CAN, даешь Ethernet.
Но есть тоже всякие там но - типа найти микроконтроллер недорогой, на Cortex например, чтобы у него была сетевая дырка. Можно. А ведь можно и более примитивное железо использовать, типа Ардуины. Но на нее плата сетевая стоит как шуба. Ну их в жопу.
Короче, я думал и все такое и получилось так:
Всякие там C-программируемые контроллеры - это круто и надежно. Но во-первых, заколебешься писать на них код под С. Ну реально, читал некоторые исходники, там угрохаешься писать упражнение типа "мигни светодиодом два раза". Но надежно капец и недорого. А потом к этому всему нужно будет самому подбирать датчики и отлаживаться. Это уже более грустно - на эмуляторе не поотлаживаешься, нужно JTAG и прочее извращение подключать, а это как жопой чай пить - прикольно, но смысла особого нет - денег экономится не так уж и пропорционально много. А времени уходит куда больше.
Всякие ардуино идут сразу лесом из-за ценников. Удивительно, как хороший пиар может делать адскую цену. Гемора с отладкой и все такое несколько меньше - там просто комьюнити большое и уже адское количество проектов, на которых можно поучиться.
А еще есть Raspberry PI, я как раз себе купил парочку и баловался и они хорошие и не дорогие. С проводами тоже гемор. Но дебажить легче - писать можно на чем хочешь, хоть и дебаг выходит не такой глубокий как на голеньких микроконтроллерах, ну да и хрен с ним (убрал про жопу) :)
Есть еще один плюс у малинки ПИ - она адски расширяется - хочешь RTOS/RT Linux core, хочешь - через усб что-нибудь подключи и все такое.
Короче, херачим на малине.
Дальше так - сеть будет без головного устройства. Она будет читать показания сенсоров и бродкастить их в сеть - кому надо - прочитают и примут меры. Головное устройство может следить за всем этим (и будет) и внимательно все записывать. Но его смерть на работоспособоность сети никак не повлияет. Это хорошо.
То есть, как бы вот картинка традиционного и моего нового супер-инновационного (ггг) подходов:
Я закажу несколько сенсоров и макеток, чтобы начинать все это собирать вместе (сенсоров будет огого - температура, влажность, газы, свет, движение, детектор дыма, влага/вода, возможно ультразвуковые датчики, пока не знаю, геморные они какие-то).
А пока все это едет на поезде из Китая, я решил немного попрограммировать и задать вопрос.
Короче, пишем небольшой сервер, который будет слушать порт:
import config
from socket import *
def udp_listener():
address = (config.UDP_BIND_ADDRESS,config.UDP_BROADCAST_PORT)
server_socket = socket(AF_INET, SOCK_DGRAM)
server_socket.bind(address)
print('Listening on port %s' % config.UDP_BROADCAST_PORT)
while 1:
rec_data, rec_adr = server_socket.recvfrom(128)
print 'Got data from %s: > %s' % rec_adr, rec_data
И немного кода, чтобы как бы наэмулировать процесс бродкаста сообщений:
from socket import *
from utils import generate_random_token
def broadcast(number_of_messages = 10):
BROADCAST_PORT = 9010
for x in range(number_of_messages):
try:
random_token = generate_random_token(6)
print('sending network message: %s' % random_token)
broadcast_socket = socket(AF_INET,SOCK_DGRAM)
broadcast_socket.bind(('',0))
broadcast_socket.setsockopt(SOL_SOCKET,SO_BROADCAST,1)
broadcast_socket.sendto(random_token,('
',BROADCAST_PORT))
except Exception as e:
print 'Failed to send network message: %s' % e
Оно работает и все весело, но я что подумал (внимание вопрос, типа): есть ли смысл просто перекидываться строками (я понятно их отформачу, типа "[sensor_id][sample_time][sensor_class][sensor_value]") или таки использовать какой-нибудь например более формальный протокол, чтобы было как-то структурнее или веселее?
Ну и да - если тут есть всякие там умные инженеры и все такое, вы говорите/критикуйте, ну?
Разделяем все на три логические сети:
- Чувствительная сеть - это чисто сенсоры
- Ахтунговая сеть - это оповестительные разные механизмы и передача медиа-контента
- Управленческая сеть - это когда нужно чем-нибудь управлять
Итак, вариантов физической реализации самой сети реального много всяких - 1-wire, CAN, I2C, Ethernet и прочие всякие извращения. В принципе, самый простой и в лоб - это 1-wire:
Все как бы круто, но гарантии, что это будет работать на больших расстояниях и большом количестве датчиков (у меня выходит больше ста) особой нет. Зато реально дешево, можно даже адаптер не покупать никакой, а все завязать на GPIO. Короче, как бы халява. Но есть такая штука - если головное устройство померло, то все. Сеть тоже померла. Ну и все сенсоры могут работать только в пассивном режиме. Ну и выбор сенсоров не очень велик, потому как перед каждым должен быть чип с уникальным ID.
Решил не делать так - не уверен, что прокатит. Проводов накидаем побольше - тем более, что Cat5e стоит не дорого, а на них можно будет мутить уже любую экзотику.
Тогда типа CAN - экономим провода и до кучи получаем хорошую надежность и устойчивость супротив всяких там помех:
Тут все круто, но есть засада. Распайки под CAN есть на большом количестве STM32 чипах и даже более старых всяких 8битных уродах. А вот под Raspberry можно например через USB это дело пускать - но денег стоит прилично.
А с другой стороны, нахрена вообще CAN, если сеть под него физически такая же как и под LAN? tcp-ip оно как-то проще писать и здоровее и вообще.
Короче, нахрен CAN, даешь Ethernet.
Но есть тоже всякие там но - типа найти микроконтроллер недорогой, на Cortex например, чтобы у него была сетевая дырка. Можно. А ведь можно и более примитивное железо использовать, типа Ардуины. Но на нее плата сетевая стоит как шуба. Ну их в жопу.
Короче, я думал и все такое и получилось так:
Всякие там C-программируемые контроллеры - это круто и надежно. Но во-первых, заколебешься писать на них код под С. Ну реально, читал некоторые исходники, там угрохаешься писать упражнение типа "мигни светодиодом два раза". Но надежно капец и недорого. А потом к этому всему нужно будет самому подбирать датчики и отлаживаться. Это уже более грустно - на эмуляторе не поотлаживаешься, нужно JTAG и прочее извращение подключать, а это как жопой чай пить - прикольно, но смысла особого нет - денег экономится не так уж и пропорционально много. А времени уходит куда больше.
Всякие ардуино идут сразу лесом из-за ценников. Удивительно, как хороший пиар может делать адскую цену. Гемора с отладкой и все такое несколько меньше - там просто комьюнити большое и уже адское количество проектов, на которых можно поучиться.
А еще есть Raspberry PI, я как раз себе купил парочку и баловался и они хорошие и не дорогие. С проводами тоже гемор. Но дебажить легче - писать можно на чем хочешь, хоть и дебаг выходит не такой глубокий как на голеньких микроконтроллерах, ну да и хрен с ним (убрал про жопу) :)
Есть еще один плюс у малинки ПИ - она адски расширяется - хочешь RTOS/RT Linux core, хочешь - через усб что-нибудь подключи и все такое.
Короче, херачим на малине.
Дальше так - сеть будет без головного устройства. Она будет читать показания сенсоров и бродкастить их в сеть - кому надо - прочитают и примут меры. Головное устройство может следить за всем этим (и будет) и внимательно все записывать. Но его смерть на работоспособоность сети никак не повлияет. Это хорошо.
То есть, как бы вот картинка традиционного и моего нового супер-инновационного (ггг) подходов:
Я закажу несколько сенсоров и макеток, чтобы начинать все это собирать вместе (сенсоров будет огого - температура, влажность, газы, свет, движение, детектор дыма, влага/вода, возможно ультразвуковые датчики, пока не знаю, геморные они какие-то).
А пока все это едет на поезде из Китая, я решил немного попрограммировать и задать вопрос.
Короче, пишем небольшой сервер, который будет слушать порт:
import config
from socket import *
def udp_listener():
address = (config.UDP_BIND_ADDRESS,config.UDP_BROADCAST_PORT)
server_socket = socket(AF_INET, SOCK_DGRAM)
server_socket.bind(address)
print('Listening on port %s' % config.UDP_BROADCAST_PORT)
while 1:
rec_data, rec_adr = server_socket.recvfrom(128)
print 'Got data from %s: > %s' % rec_adr, rec_data
И немного кода, чтобы как бы наэмулировать процесс бродкаста сообщений:
from socket import *
from utils import generate_random_token
def broadcast(number_of_messages = 10):
BROADCAST_PORT = 9010
for x in range(number_of_messages):
try:
random_token = generate_random_token(6)
print('sending network message: %s' % random_token)
broadcast_socket = socket(AF_INET,SOCK_DGRAM)
broadcast_socket.bind(('',0))
broadcast_socket.setsockopt(SOL_SOCKET,SO_BROADCAST,1)
broadcast_socket.sendto(random_token,('
',BROADCAST_PORT))
except Exception as e:
print 'Failed to send network message: %s' % e
Оно работает и все весело, но я что подумал (внимание вопрос, типа): есть ли смысл просто перекидываться строками (я понятно их отформачу, типа "[sensor_id][sample_time][sensor_class][sensor_value]") или таки использовать какой-нибудь например более формальный протокол, чтобы было как-то структурнее или веселее?
Ну и да - если тут есть всякие там умные инженеры и все такое, вы говорите/критикуйте, ну?