Умный дом: концепция
Добавлено: Вт апр 12, 2016 1:56 pm
Цели и назначение
С давних пор у меня существует 1-wire сеть, которая собирает с помощью роутера (а ранее и ПК) все возможные температурные данные по квартире. Предыстория вопроса тут: viewtopic.php?f=3&t=10.
Для этого по квартире на этапе косметического ремонта была проложена шина из UTP 5e кабеля, в которой разведено и питание и 1-wire. В целом функционально все это выглядит так:
Модуль питания и коммутации описан тут: viewtopic.php?f=3&t=73
RJ-45 это разьем типа распред. коробка типа такой:
http://www.oldi.ru/upload/resaiz_images ... 9213_2.JPG
Со временем пришлой уйти от двухпроводного включения ds18b20, т.к. при этом все-таки проскакивали ошибки измерения и получения температуры.
Целью данного проекта было расширение возможности существующего функционала сбора температуры для целей мониторинга и последующего событийного управления. Это очень похоже на проекты Умных домов.
Базовый сценарий: температура одного из датчиков ds18b20 превысила некий заданный предел, при этом на улице отрицательная температура, тогда открыли окно. Если температура на улице выше нуля, то включили кондиционер.
Было перечитано много страниц в интернете на темы умных домой, где подробно и не очень расписывались плюсы и минусы выбранных решений но решающим было существующее у меня база модулей по работе с Ethernet, RS485 и radio.
Решающую роль сыграла вот эта статья http://radiokot.ru/circuit/digital/automat/11/
Дабы предотвратить холивары и «фи» сразу скажу, что можно было сделать все более надежнее и правильнее, применив can + любой opensource проект с GUI, но я пошел своим путем и пока будет так!
Архитектура
Система представляет собой распределённую децентрализованную сеть для независимого общения сенсоров, исполнительных устройств и т.д. Физические линии выполнены на основе RS485 (max485) и радиоканала 2.4 мГц (nRF24L01). Ретрансляция между RS485 и радио выполняет специальное устройство – ретранслятор. Периферийные устройства (пульты реле датчики) могут собираться на двух каналах (RS485 и радио) или только на одном из каналов (RS485 или радио). Все устройства в сети полностью самостоятельны, одно устройство может управлять другим команды, если в него заложена такая логика. Общее управление всеми устройствами возложено на специальное устройство – сценарист. В сети возможны широковещательные сообщения, на которые реагируют все устройства сети, широковещательные сообщения могу отправляться сенсорами с данными измерения температуры, влажности и т.д.
Передача данных
В сети используется Цифровая последовательная передача данных по одному проводу в дуплексном режиме по шине с топологией шина (за основу взята RS485). Шифрование данных не применяется для упрощения.
Общие принципы взаимодействия устройств
Каждое устройство в сети имеет свой уникальный идентификатор – ID. Каждое устройство в сети может посылать целевые сообщения или широковещательные сообщения. В целевых сообщениях указывается адрес принимающего устройства, в широковещательных сообщениях – нет (нулевой адрес). Все устройства слушают эфир и реагируют на соответствующие сообщения, которое имеет адрес получателя равное ID слушателя или все устройства реагируют на широковещательное сообщение.
В целях оптимизации и упрощения реализации принимаются следующие ограничения:
• В один момент времени устройство может принять, обработать, исполнить и отправить результаты, только по одному сообщению (команде).
• На принятое, обработанное и взятое в исполнение сообщение (команду), устройство в обязательно порядке отправляет подтверждение (квитанция), устройству отправившему сообщение.
• Подтверждение на получения подтверждения не выполняется, т.е. квиток на квиток не посылается.
• Подтверждение (квитанция) на широковещательное сообщение не отправляются.
Протокол
Протокол имеет уникальный формат, в котором обязательно присутствует:
ID отправителя
ID получателя
Команда
Параметры команды
CRC
Этому будет посвящена отдельная статья.
Основные принципы выбора протокола: простота в реализации на МК (AVR ATmega8), самодостаточность для домашней сети в 5-10 устройств.
Исключение коллизий
Коллизия не исключены, но сведены к минимуму за счет применения в каждом устройстве алгоритма уникальной технологической паузы перед отправкой сообщения в сеть. Допустимы коллизии для 8% сообщений в час. Т.о. каждое устройство, перед тем как отправить сообщение в сеть, проверяет, что сеть свободна (отсутствие принятых байтов по сети за определенный промежуток времени уникальный для каждого устройства).
Если сеть свободна, то устройство начинает передавать сообщение до его окончания, но по одному сообщению за раз.
Если сеть занята, то делается технологическая паузу, составляющая не менее длительности передачи двух символов (принимаем как задержку в распределении сигнала по всей сети) в сеть на максимальной скорости передачи данных в сеть (115200 бод), плюс задержка, рассчитанная от значения ID устройства.
Пока не реализовано и видимо уже не будет: Каждое устройство при передаче по алгоритму выше, слушает сеть и проверяет, что передаваемые байты совпадают с принимаемыми. Если байты не совпадают, то считаем, что возникла коллизия и прекращаем передачу и выдерживаем технологическую паузу.
Гарантированная доставка команд
Доставка сообщение от отправителя до получателя достигается за счет подтверждения (квитирование) получателем принятой команды, а отправитель при отсутствии подтверждения, повторяет отправку команды в сеть фиксированное количество раз.
Маршрутизация
Специального механизма маршрутизации не предусмотрено, сеть может быть расширена применением репитеров. Маршрутизация между физическими сетями RS485 и радио выполняется методами широковещательных сообщений (broadcasting) или однонаправленными сообщениями (unicast).
Алгоритмы
Рисунок 1, Алгоритм обработки команд в прерывании по приему байта через USART
Рисунок 2, Алгоритм обработки команды в бесконечном цикле
Use Case
Имя сценария Сбор температуры
Участники Устройство опроса датчиков ds18b20, логгер.
Цель сохранение на сервер температуры со всех датчиков ds18b20.
Порядок событий
1. мастер сети ds18b20 опрашивает и получается температуру со всех подключенных к нему датчиков ds18b20
2. мастер ds18b20 отравляет сообщение с температурой каждого датчика в сеть.
3. Логгер получает эти сообщения и передает их на хранение на внешний сервер.
С давних пор у меня существует 1-wire сеть, которая собирает с помощью роутера (а ранее и ПК) все возможные температурные данные по квартире. Предыстория вопроса тут: viewtopic.php?f=3&t=10.
Для этого по квартире на этапе косметического ремонта была проложена шина из UTP 5e кабеля, в которой разведено и питание и 1-wire. В целом функционально все это выглядит так:
- 1wire_net.jpg (48.02 КБ) 12245 просмотров
RJ-45 это разьем типа распред. коробка типа такой:
http://www.oldi.ru/upload/resaiz_images ... 9213_2.JPG
Со временем пришлой уйти от двухпроводного включения ds18b20, т.к. при этом все-таки проскакивали ошибки измерения и получения температуры.
Целью данного проекта было расширение возможности существующего функционала сбора температуры для целей мониторинга и последующего событийного управления. Это очень похоже на проекты Умных домов.
Базовый сценарий: температура одного из датчиков ds18b20 превысила некий заданный предел, при этом на улице отрицательная температура, тогда открыли окно. Если температура на улице выше нуля, то включили кондиционер.
Было перечитано много страниц в интернете на темы умных домой, где подробно и не очень расписывались плюсы и минусы выбранных решений но решающим было существующее у меня база модулей по работе с Ethernet, RS485 и radio.
Решающую роль сыграла вот эта статья http://radiokot.ru/circuit/digital/automat/11/
Дабы предотвратить холивары и «фи» сразу скажу, что можно было сделать все более надежнее и правильнее, применив can + любой opensource проект с GUI, но я пошел своим путем и пока будет так!
Архитектура
Система представляет собой распределённую децентрализованную сеть для независимого общения сенсоров, исполнительных устройств и т.д. Физические линии выполнены на основе RS485 (max485) и радиоканала 2.4 мГц (nRF24L01). Ретрансляция между RS485 и радио выполняет специальное устройство – ретранслятор. Периферийные устройства (пульты реле датчики) могут собираться на двух каналах (RS485 и радио) или только на одном из каналов (RS485 или радио). Все устройства в сети полностью самостоятельны, одно устройство может управлять другим команды, если в него заложена такая логика. Общее управление всеми устройствами возложено на специальное устройство – сценарист. В сети возможны широковещательные сообщения, на которые реагируют все устройства сети, широковещательные сообщения могу отправляться сенсорами с данными измерения температуры, влажности и т.д.
Передача данных
В сети используется Цифровая последовательная передача данных по одному проводу в дуплексном режиме по шине с топологией шина (за основу взята RS485). Шифрование данных не применяется для упрощения.
Общие принципы взаимодействия устройств
Каждое устройство в сети имеет свой уникальный идентификатор – ID. Каждое устройство в сети может посылать целевые сообщения или широковещательные сообщения. В целевых сообщениях указывается адрес принимающего устройства, в широковещательных сообщениях – нет (нулевой адрес). Все устройства слушают эфир и реагируют на соответствующие сообщения, которое имеет адрес получателя равное ID слушателя или все устройства реагируют на широковещательное сообщение.
В целях оптимизации и упрощения реализации принимаются следующие ограничения:
• В один момент времени устройство может принять, обработать, исполнить и отправить результаты, только по одному сообщению (команде).
• На принятое, обработанное и взятое в исполнение сообщение (команду), устройство в обязательно порядке отправляет подтверждение (квитанция), устройству отправившему сообщение.
• Подтверждение на получения подтверждения не выполняется, т.е. квиток на квиток не посылается.
• Подтверждение (квитанция) на широковещательное сообщение не отправляются.
Протокол
Протокол имеет уникальный формат, в котором обязательно присутствует:
ID отправителя
ID получателя
Команда
Параметры команды
CRC
Этому будет посвящена отдельная статья.
Основные принципы выбора протокола: простота в реализации на МК (AVR ATmega8), самодостаточность для домашней сети в 5-10 устройств.
Исключение коллизий
Коллизия не исключены, но сведены к минимуму за счет применения в каждом устройстве алгоритма уникальной технологической паузы перед отправкой сообщения в сеть. Допустимы коллизии для 8% сообщений в час. Т.о. каждое устройство, перед тем как отправить сообщение в сеть, проверяет, что сеть свободна (отсутствие принятых байтов по сети за определенный промежуток времени уникальный для каждого устройства).
Если сеть свободна, то устройство начинает передавать сообщение до его окончания, но по одному сообщению за раз.
Если сеть занята, то делается технологическая паузу, составляющая не менее длительности передачи двух символов (принимаем как задержку в распределении сигнала по всей сети) в сеть на максимальной скорости передачи данных в сеть (115200 бод), плюс задержка, рассчитанная от значения ID устройства.
Пока не реализовано и видимо уже не будет: Каждое устройство при передаче по алгоритму выше, слушает сеть и проверяет, что передаваемые байты совпадают с принимаемыми. Если байты не совпадают, то считаем, что возникла коллизия и прекращаем передачу и выдерживаем технологическую паузу.
Гарантированная доставка команд
Доставка сообщение от отправителя до получателя достигается за счет подтверждения (квитирование) получателем принятой команды, а отправитель при отсутствии подтверждения, повторяет отправку команды в сеть фиксированное количество раз.
Маршрутизация
Специального механизма маршрутизации не предусмотрено, сеть может быть расширена применением репитеров. Маршрутизация между физическими сетями RS485 и радио выполняется методами широковещательных сообщений (broadcasting) или однонаправленными сообщениями (unicast).
Алгоритмы
- usart.jpg (22.06 КБ) 12246 просмотров
- бесконечный цикл.jpg (31.61 КБ) 12246 просмотров
Use Case
Имя сценария Сбор температуры
Участники Устройство опроса датчиков ds18b20, логгер.
Цель сохранение на сервер температуры со всех датчиков ds18b20.
Порядок событий
1. мастер сети ds18b20 опрашивает и получается температуру со всех подключенных к нему датчиков ds18b20
2. мастер ds18b20 отравляет сообщение с температурой каждого датчика в сеть.
3. Логгер получает эти сообщения и передает их на хранение на внешний сервер.