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

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

Новый функционал, поддержка Меркурий230 и другое

Сегодня я реализовал новую библиотеку устройства - электросчетчика Меркурий230 от компании Инкотекс.

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

Кроме этого пофиксены мелкие и не очень баги контроллера и выложена новая версия с новыми библиотеками устройств.

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

http://5277.ru/distr/client/0.36/
http://5277.ru/distr/controller/0.7.7/

Ответы на вопросы

Уважаемый vladikoms задал мне несколько вопросов, отвечаю на них здесь.

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

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

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

Теперь вопросы:
1. Имеется ли подробная инструкция как всё запустить и настроить?

  Имеется несколько видеороликов на ютуб и статей в моем ЖЖ:
https://5277.livejournal.com/24482.html
https://5277.livejournal.com/23897.html
https://5277.livejournal.com/24066.html
https://5277.livejournal.com/23690.html

  Есть пара статей о сценариях:
https://5277.livejournal.com/26013.html
https://5277.livejournal.com/31432.html

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

2. Как понимаю, в настоящее время облачный контроллер не функционирует?
  Даже и не знаю (причина описана выше, не востребовано),  функционал был написан, оттестирован и забыт. Возникнет проблема - просто нужен фидбек - починю.

3. Хотелось бы иметь возможность подключать к системе и опрашивать сторонние устройства по RS485. Насколько сложно самому написать такую библиотеку, при условии что протокол обмена является открытым? Например, для простого однофазного счетчика Меркурий 206.

Вот, в качестве примера:
Температурный датчик Lumel p18
http://5277.ru/distr/other/src/x0005x0001_lumelsa_p18.java
Электросчетчик СЭБ-2А
http://5277.ru/distr/other/src/x0004x0001_frunze_seb2a.java

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

Класс библиотеки устройства должен быть наследован из абстрактных классов библиотеки интерфейсов http://5277.ru/distr/interfaces_lib/c5277_interfaces.jar, в ней-же есть примеры.

По поводу написания библиотеки самому - идея не доведена до ума.
Главная проблема в том, что многие параметры устройства и его показания задаются в БД и в выше обозначенной библиотеки.
Т.е. стороннему разработчику как-то нужно объяснить системе какие параметры и показания есть у устройства.
Этот вопрос на данный момент не решен.

Но есть другой вариант взаимодействия - я готов на бесплатных началах реализовывать библиотеки устройств (конечно если они не супер сложные, над которыми придется убить далеко ни один день типа как ВКТ-7) .
Мне нужно описание протокола и/или доступ к нему (например через TCP/IP с преобразователем в RS485). А еще будет полезен рабочий пример или дамп.
Какую-то информации я смогу найти сам.
Иногда будет достаточно просто просьбы.

И это будет и мне плюсом, так как чем больше устройств в проекте - тем он привлекательней.

Еще, можно обратиться ко мне с описанием параметров и показаний устройства, я их добавлю в систему и тогда можно будет самому писать библиотеку. Но я оставляю за собой право инспекции и правок перед распространением этой библиотеки.

И потом, при разработке библиотеки кем-то со стороны не решается вопрос ее распространения.

5277, варианты подключения группы устройств

Буду говорить об элементарном, но вдруг кому-то будет интересно.

Я запилил небольшую блок-схему:



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

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

Рассмотрю узел связи:
Устройство, обеспечивающее связь может быть любым, главное, чтобы оно имело интерфейс шины RS485 (либо любой другой, который можно преобразовать в RS485). На моей практике это почти всегда был GSM модем с интерфейсом RS485.
Но никто не мешает взять скажем модуль LoraWAN с UART интерфейсом и подключить к нему что-то простое, типа драйвера MAX485 с небольшой обвязкой задающей режим приема/передачи. Никакой дополнительной логики в виде МК здесь не нужно.

Центр:
Здесь тоже узел связи, при этом с контроллером он может соединяться как угодно UART,RS485, RS232, Ethernet, Wi-Fi и прочее.
Остается подобрать ПО, которое будет выполнять необходимые задачи. Среди которых должен быть опрос по определенному протоколу счетчиков.
ПО можно взять мое.

Также я предлагаю решение, где контроллер находится в облаке.
Т.е. в центре вообще не нужно будет что-либо разворачивать, просто установить клиент.

Более того, у меня есть недорогие наработки модулей - преобразователей с логикой.
Основное их преимущество - можно менять настройки исходящего интерфейса налету.
Это может быть востребовано, если скажем к Вашей шине RS485 подключены устройства с разными параметрами UART (например baudrate)

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

Update: Вот, кстати список поддерживаемых методов в моем предыдущем коммерческом решении как раз для Меркурий 230.



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

В этом же проекте лежат библиотеки устройств (латинские названия) с парктически полным функционалом.
Некоторый функционал был реализован только благодаря реверс-инжинирингу.

CAS_5010A,
P18,
PSCH_3ART.07.xxx
PSCH_3ART.07.xxx.1,
PSCH_3ART.07.xxx.2,
Pulsar,
SEB_2A.07.xxx.x,
SET_4TM,
SET_4TM_03M_01,
TEM104,
VKT5,
VKT7.

Сценарии на базе 'скриптов'

  Я не раз задумывался о том, как я буду реализовывать скрипты в своем проекте. Речь идет о скриптах для расширения возможностей сценариев, т.е. вместо заполнения параметров формы мы могли бы написать необходимый код. У этой задачи был довольно низкий приоритет, да и проект я позиционирую так, что знание программирования не обязательно.
  Было много разных мыслей, вплоть до написания своего интерпретатора типа Бейсик, разработки встроенного редактора и тому подобное.
Но вот сегодня меня наконец-то озарило, идея в следующем:
  Мне не нужен никакой редактор или интерпретатор, мне нужно сделать ровно тоже самое, что я проделал с кодом отвечающим за функционал устройств, шлюзов и сервисов.
А именно - описать Java интерфейс и на базе его создавать Java библиотеки реализующие необходимую логику.
Тогда, я просто ввожу в клиенте, в сценарии, в блоке условий новый элемент - Java библиотека. В котором задается вендор и сама библиотека и контроллер теперь знает какой код запускать.

При этом данные библиотеки будут разрабатываться кем угодно, также будет некий стандартный набор.

Новый элемент (Java библиотека) будет также в блоках 'Информирование' и 'Управление', что даст практически полную свободу разработчику.

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мс каждую итерацию.
Первая же добавленная заявка моментально выведет его из сна.


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