Category: литература

Category was added automatically. Read all entries about "литература".

Dipex, взаимодействие устройств без контроллера

Небольшое вступление:

"Dipex Group" - это компания - официальный представитель данного проекта.

Т.е. это общий проект, но есть некоторые отличия:
1) Главное - парк устройств. Устройства отличаются по функционалу, внешнему виду, количеству, логике и даже реализацией шины. Разработка схемотехники устройств и их прошивок отдельная, функционал не заимствуется, разве что элементарных функций.
2) Облаком - при регистрации и авторизации пользователь выбирает площадку, в зависимости от выбора будут использоваться либо сервера Dipex'а, либо мой сервер.
3) Дополнительными сервисами и кастомизацией.

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



И так, речь идет о взаимодействии устройств посредством шины DipexBus, без контроллера.
Как известно, самый распространенный и не дорогой протокол общения железок на шине типа RS485 - Modbus.
На мой взгляд, главный недостаток этого протокола - ведомый(slave) не может инициировать передачу. Т.е. обязательное наличие ведущего(master).
Здесь создан 'свой велосипед', на шине RS485 реализован протокол поддерживающий, кроме всего прочего,  динамическую адресацию и возможность вещать любому узлу независимо от ведущего.

На видео ниже я взял два устройства:
 - датчик температуры и влажности, далее 'Термометр' (также оснащен портом для DS18B20 и контактом, например для обнаружения открытия двери),
- двухканальное реле, далее 'Реле x2' (220В, 4Вт на канал, питание реле - 5В).


https://youtu.be/frVIKQ2P0bQ

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

По сути здесь ничего особенного, можно легко запрограммировать конкретное действие на конкретное событие.
Но этот проект является не каким-то решением под определенную задачу, это конструктор, функционал должен быть очень гибким не смотря на то, что здесь рассматривается только линейка устройств Dipex.

И да, есть сценарии. В них можно настроить многое, реализовать гораздо сложнее логику взаимодействия. Но эта логика будет отрабатывать на контроллере. Нет контроллера - нет логики.

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



В линейке Dipex устройств(в этом конфигураторе) можно задать пороги и триггеры. Т.е. пороги для датчиков, которые на базе этих данных будут сообщать в сеть события, и триггеры для исполнительных устройств, на базе которых устройства будут выполнять определенные действия по определенным событиям(при этом также будут сообщать о своих действиях в сеть в виде событий).

Т.е. здесь используется контроллер только для разовой записи порогов и триггеров, далее мы его попросту отключили. Остались устройства соединенные шиной и USB платка как источник питания.

И главное, обратите внимание, на сколько просто это делается. Вам не придется выяснять идентификаторы устройств, показаний, каналов, команд, формат показаний и прочее, прочее, прочее. Все достаточно просто. Еще я считаю вишенкой на торте возможность экспортировать и импортировать конфигурации.


https://youtu.be/nljlGcW8-PE

Конечно я рассказал не все, например я не стал рассказывать, как устройства обрабатывают коллизии. Но данный протокол проприетарный, поэтому подробностей не будет. Скажу только, что популярные методы CAN open я не использовал. Работает достаточно надежно. Но в любом случае будет также ряд рекомендаций для использования такого режима.

update: обновил битое видео

Новый функционал, HTTP точка управления

Добавил новую точку управления(облачный режим).


По сути она обрабатывает HTTP/HTTPS запросы.
С их помощью можно выполнить ограниченный функционал, например отправить команду для устройства.

Вот, например один из моих ярлыков на рабочем столе содержит следующую команду запуска:

Здесь я включаю в кабинете свет на 50%

В общем, на текущий момент работать с сервером можно следующими способами:
1) На базе моей полноценной библиотеки(Java). Которая дает достаточно полный функцинал для полноценной работы с сервером, подойдет для клиента с максимальной реализацией функционала.
2) На базе легковесной библиотеки, подойдет для простых клиентов, чья задача отправить команду и получить текущие показания. Например для виджетов на Android.
3) Токи управления:
3.1) HTTP запросы (типа рестфул), подойдет там где нет возможности(или просто лень) использовать мою легковесную  библиотеку, конечно если плевать на трафик.
3.2) Телеграм
3.3) Алиса
3.4) Почта
3.5.) SMS(пока не используется)

Главные вопросы, напоминание что это и зачем

Никто не понимает, что это у меня такое, часто и я забываю ответ на этот вопрос.
Потому, что не придерживаюсь шаблонов и моды, но они давят, давят и давят.
Я не поеду на конкурс, который заточен на ардуинщикуов - вот вам идиотское задание а вы из говна и палок создайте решение за короткое время.
Быстро - только мухи ибутся, хороший проект требует колоссального вложения ресурсов, я просто ничего не успею за сутки, за которые опытный ардуинщик родит говно-решение. В таком виде я не конкурентоспособный.

Что же я такое делаю? Давайте разбираться.

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

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

Все делается для того, чтобы можно было взять охапку различных конечных устройств и достаточно легко объединить их в одно целое, при этом получить богатый функционал в итоговом решении. При этом совершенно не нужно программировать, достаточно иметь просто общие, поверхностные, знания. Решение по большей части бесплатное - можно развернуть решение полностью бесплатно(будет ограничение на контроллере - 16 устройств максимум, возможно пересмотрю), платными будут дополнительные сервисы, скажем хранение на сервере большого объема статистики, или какие-то дополнительные сервисы. Ну или скажем разработка библиотеки редкого устройства или вовсе - его создание(впрочем я ранее об этом говорил).

Это также хороший инструмент для управления различными DIY устройствами, например сейчас много китайщины с ужасными приложениями, где не продумано почти ничего, только как включить, выключить и задать параметр включения. Мой проект позволяет элементарно просто управлять такими железками, собирать с них данные, описывать процессы, информировать, и многое другое. Т.е. выступает аналогом приложения от вендроа но с гораздо большим и функционалом при этом с возможностью легко объединять большое количество устройств. Вот тут я хочу, в будущем, предложить свое решение китайским производителям как универсальное решение, в том числе и для их устройств.

Единственное что нужно сделать - написать Java библиотеку на базе моего интерфейса(кем угодно, в том числе и я), проверить ее код, добавить в БД новое устройство(автоматически обновляется и на клиенте) и вложить в общий дистрибутив(я или компания). Также заложен функционал с пулом идентификаторов устройств для непосредственного внедрения библиотек устройств локально(без участия кого-либо со стороны кроме самого разработчика устройства)

Дополнение:
Уже несколько лет я применяю свое решение у себя дома.
Я управляю светом почти во всех комнатах, измеряю температуру и влажность, управляю другими электроприборами, при этом я не использую ни чужие устройства ни чужое ПО, но могу, они у меня есть. Я смотрю графики, получаю уведомления управляю сообщениями через тот-же телеграм, жена постоянно задает яркость диммеру в зале просто кидая фразы боту типа '35' или '320'(Зал, яркость 20%), есть постоянный контроль входной двери с звуковым сопровождением и сообщениями на мобильные устройства. И все это не ново и уже никого не удивляет - любой настырный ардуинщик может сделать тоже самое. Главное отличие в том, что когда я это все настраивал, дополнял, изменял условия и многое другое - я ни написал ни одной строчки кода, при этом имея очень богатый функционал. Все что я сделал - при желании сможет повторить моя супруга или подросток просто ознакомившись с роликами на ютубе(которых пока нет, но обязательно будут).

Система достаточно легко усваивается, и она универсальна, главное - чтобы Ваше устройство в ней поддерживалось, и здесь я готов получив ваш код, его проинспектировать и добавить, либо за вознаграждение написать сам. Хотя вероятнее всего, если Ваше устройство широко распространено, оно либо уже в моей системе, либо скоро появится.

Контроллер, описание модели опроса устройств

Механизм опроса достаточно сложен, порой я сам забываю как он работает в деталях.

Я думаю, этот пост будет важен не только мне, но и интеграторам при создании сложного проекта.

И так, как я уже сегодня писал, контроллер формирует заявки на опрос устройства с периодичностью указанной либо в локации, либо непосредственно в устройстве. Опрос может выполняться чаще(раз в минуту) если предыдущий опрос(с тремя попытками) был не успешным. Также заявка на опрос подается при получении команды для устройства или формировании ее сценариями. Ну и клиент тоже может сформировать такую заявку.

Заявки поступают опрашивателю(interrogator). Опрашиватель создается для каждого используемого физического интерфейса контроллера. Таким образом есть возможность вести параллельный опрос различных устройств подключив их к разным шинам, например используя несколько USB->RS485 шлюзов.
При получении заявки опрашиватель добавляет ее в свою очередь(FIFO), также проверяет принадлежность данного устройства к типу устройств поддерживающих функционал ExtraScan.

Если устройство поддерживает ExtraScan, а шлюз непосредственно подключенный к устройству не поддерживает, то опрашиватель берет эту задачу на себя, выполняя частый, постоянный опрос таких устройств.
Идея ExtraScan проста, она дает возможность быстро реагировать на события от устройств, которые не могут передавать события, например устройства реализованные на базе RS485 Modbus.

Далее, каждый опрашиватель постоянно выполняет обработку очереди заявок, выдерживая паузу между итерациями как минимум в 300 миллисекунд (иначе будет высокая нагрузка на ЦП).

Первым выполняется функционал ExtraScan для всех поддерживающих устройств, при обнаружении необходимости считать данные заявка на опрос устройства будет помещена в начало очереди.
При выдержке паузы в 300мс учитывается время потраченное на ExtraScan.

Далее идет непосредственно обработка очереди заявок. Устанавливается соединение с устройством. Создается пустой снимок показаний. Проверяется наличие других заявок для устройства(например чтение/запись конфигурации) и выполняются все команды управления устройством. Затем выполняется опрос в котором библиотека устройства выполняет все необходимые действия и наполняет снимок показаниями.
Есть поддержка асинхронных устройств, устройство может ответить, что заявка принята и данные будут позже, в этом случае опрашиватель оставляет снимок показаний пустым, считая, что опрос пройден успешно(механизм получения данных будет рассмотрен отдельно).
Сразу после этого еще раз выполняются новые команды управления устройством(да, могли появиться после опроса, если сейчас не выполнить, то будет пауза(некоторые устройства выдерживают паузы при подключении, отключении и между передачей пакетов данных, паузы могут быть значительные)). Закрываем соединение и проверяем результат всех действий, если где-то что-то пошло не так, то повторяем еще раз(максимум 3 попытки) добавляя нашу заявку заново в конец очереди.
И еще раз проверяем на наличие новых команд, если есть то добавляем также в конец очереди. Последним этапом, в случае успешного опроса или при исчерпании всех попыток, форсируется работа коммуникатора(он отвечает за взаимодействие с сервером в облаке) заставляя его передать полученные данные с минимальными задержками.

В случае, если заявок у опрашивателья нет, то он выполняет ExtraScan функционал и спит по 300мс каждую итерацию.
Первая же добавленная заявка моментально выведет его из сна.


*Пост будет редактироваться по мере внесения изменений в функционал.