Умный дом своими руками. Часть первая. Сеть: архитектура и принципы обмена.
С давних пор у меня дома существует 1-wire сеть, которая собирает с помощью роутера (а ранее - ПК) все возможные температурные данные по квартире. Предыстория вопроса тут. По квартире на этапе косметического ремонта была проложена шина из UTP 5e кабеля, в которой разведено и питание и 1-wire.
Со временем пришлой уйти от двухпроводного включения
Целью данного проекта было расширение возможности существующего функционала сбора температуры для целей мониторинга и последующего событийного управления. Это очень похоже на проекты Умных домов.
В целом схема моей "сети" выглядит так:
Модуль питания и коммутации описан тут. RJ-45 это разьем типа распредкоробка, вроде такого, как на картинке ниже.
Базовый сценарий: температура одного из датчиков
Было перечитано много страниц в интернете на темы умных домой, где подробно и не очень расписывались плюсы и минусы выбранных решений но решающим было существующее у меня база модулей по работе с Ethernet, RS485 и radio.
Решающую роль сыграла вот эта статья.
Дабы предотвратить холивары и «фи» сразу скажу, что можно было сделать все более надежнее и правильнее, применив can + любой opensource проект с GUI, но я пошел своим путем и пока будет так!
Архитектура
Система представляет собой распределённую децентрализованную сеть для независимого общения сенсоров, исполнительных устройств и т.д. Физические линии выполнены на основе RS485 (
Передача данных
В сети используется Цифровая последовательная передача данных по одному проводу в дуплексном режиме по шине с топологией шина (за основу взята RS485). Шифрование данных не применяется для упрощения.
{ads1}
Общие принципы взаимодействия устройств
Каждое устройство в сети имеет свой уникальный идентификатор – ID. Каждое устройство в сети может посылать целевые сообщения или широковещательные сообщения. В целевых сообщениях указывается адрес принимающего устройства, в широковещательных сообщениях – нет (нулевой адрес). Все устройства слушают эфир и реагируют на соответствующие сообщения, которое имеет адрес получателя равное ID слушателя или все устройства реагируют на широковещательное сообщение.
В целях оптимизации и упрощения реализации принимаются следующие ограничения:
- В один момент времени устройство может принять, обработать, исполнить и отправить результаты, только по одному сообщению (команде).
- На принятое, обработанное и взятое в исполнение сообщение (команду), устройство в обязательно порядке отправляет подтверждение (квитанция), устройству отправившему сообщение.
- Подтверждение на получения подтверждения не выполняется, т.е. квиток на квиток не посылается.
- Подтверждение (квитанция) на широковещательное сообщение не отправляются.
Протокол
Протокол имеет уникальный формат, в котором обязательно присутствует:
- ID отправителя
- ID получателя
- Команда
- Параметры команды
- CRC
Подробности будут позже, в следующей части статьи.
Основные принципы выбора протокола: простота в реализации на МК (AVR
Исключение коллизий
Коллизия не исключены, но сведены к минимуму за счет применения в каждом устройстве алгоритма уникальной технологической паузы перед отправкой сообщения в сеть. Допустимы коллизии для 8% сообщений в час. Т.о. каждое устройство, перед тем как отправить сообщение в сеть, проверяет, что сеть свободна (отсутствие принятых байтов по сети за определенный промежуток времени уникальный для каждого устройства).
Если сеть свободна, то устройство начинает передавать сообщение до его окончания, но по одному сообщению за раз.
Если сеть занята, то делается технологическая паузу, составляющая не менее длительности передачи двух символов (принимаем как задержку в распределении сигнала по всей сети) в сеть на максимальной скорости передачи данных в сеть (115200 бод), плюс задержка, рассчитанная от значения ID устройства.
Пока не реализовано из-за уже разведенной платы (и, видимо, уже не будет): Каждое устройство при передаче по алгоритму выше, слушает сеть и проверяет, что передаваемые байты совпадают с принимаемыми. Если байты не совпадают, то считаем, что возникла коллизия и прекращаем передачу и выдерживаем технологическую паузу.
Гарантированная доставка команд
Доставка сообщение от отправителя до получателя достигается за счет подтверждения (квитирование) получателем принятой команды, а отправитель при отсутствии подтверждения, повторяет отправку команды в сеть фиксированное количество раз.
Маршрутизация
Специального механизма маршрутизации не предусмотрено, сеть может быть расширена применением репитеров. Маршрутизация между физическими сетями RS485 и радио выполняется методами широковещательных сообщений (broadcasting) или однонаправленными сообщениями (unicast).
Алгоритмы
Алгоритм обработки команд в прерывании по приему байта через USART
Алгоритм обработки команды в бесконечном цикле
Вариант использования
Имя сценария | Сбор температуры |
Участники | Устройство опроса датчиков |
Цель | Cохранение на сервер температуры со всех датчиков |
Порядок событий |
Продолжение следует
Комментарии
RSS лента комментариев этой записи