Category: it

Category was added automatically. Read all entries about "it".

API проекта автоматизации 5277. Структура данных ответа на запрос выбора локации.

Для коммуникации между собой таких узлов как клиент, контроллер и сервер я использую бинарный протокол.  Моя Java библиотека, с реализацией этого протокола, может преобразовывать его в JSON.  Для удобства чнетия я привожу описание структуры именно на JSON.

  *Это больше ознакомительная часть, чтобы иметь представление как оно работает. Вся детальная информация будет описана в отдельной документации.

  Здесь я опущу заголовочные данные пакета и рассмотрю только тело:


SCB - блок сценариев
LOCATIONS - блок локаций


TIMESTAMP - метка времени(в миллисекундах) последнего изменения сценариев, для определения актуальности данных
SCENARIO_GROUPS - блок  с группами сценариев


ID - идентификатор группы сценариев
LOCATION_ID - идентификатор локации, к которой привязана данная группа
DISABLED - сстояние группы(заблокирована или нет)
NAME - имя группы
SCENARIOS - блок сценариев данной группы


ID - идентификатор сценария
DISABLED - сстояние сценария(заблокирован или нет)
NAME - имя сценария
COMMENT - комментарий к сценарию
PARAMS - блок параметров


ID - идентификатор параметра
TYPE_ID - тип параметра
VALUE - данные параметра(структура и данные зависят от типа параметра)
*детально параметры сценария будут описаны отдельно

Блок SCB рассмотрен, возвращаюсь к верхним элементам.

ID - идентификатор локации
SERIAL - серийный номер контроллера(десятеричная форма), к которому привязана локация
NAME - имя локации
ICON - имя иконки локации
COMMENT - комментарий к локации
INTERROGATE_PERIOD_ID - идентификатор периода опроса устройств
AGGREGATION_PERIOD_ID - идентификатор периода выгрузки данных в БД для статистики
DISABLED - сстояние локации(заблокирован или нет)
IS_LINK - признак локации из другого проекта
PLACES - блок помещений в данной локации
GATEWAYS - блок шлюзов для конечных устройств
DEVICES - блок конечных устройств
GROUPS - группы конечных устройств(для режима вывода наборов показаний, вместо упорядоченного списка устройств с показаниями)
PERMS - блок разрешений, в рамках локации, для пользователей
DATA - блок с данными


ID - идентификатор помещения
NAME - имя помещения
ICON - имя иконки помещения
COMMENT - комментарий к помещению


ID - идентификатор шлюза
TYPE_ID - идентификатор типа шлюза
DEVICE_ID - идентификатор устройства в линейке устройств производителя
VENDOR_ID - идентификатор производителя
PARAMS - параметры устройства(ниже будут описаны на примере конечного устройства)
OWNER_IFACE_ID - идентфикатор физического порта интерфейса к которому подключено данное устройство(входящий).
IFACE - физический порт иннтерфейса который соединен с устройством к которому подключается данное устройство.


ID - идентифкатор интерфейса
IFACE_TYPE_ID - идентификатор типа интерфейса(например UART)
IFACE_NUM - порядковый номер интерфейса(например '0' - UART0)
PARAMS - блок параметров интерфейса


ID - идентификатор параметра
EXT_PARAM_ID - идентфикатор параметра из табличных данных описания набора интерфейсов и параметров каждого типа шлюза(дает гибкость системе, позволяя расширять систему буквально налету)
TYPE_ID - идентификатор типа параметра
SUBTYPE_ID - подтип идентификатора параметра(позволяет описать несколько параметров одного типа)

 Возвращаемся назад.

ID - идентификатор конечного устройства
TYPE_ID - идентификатор типа конечного устройства
NAME - имя конечного устройства
PLACE_ID - идентификатор помещения
COMMENT - комментарий к конечному устройству
INTERROGATE_PERIOD_ID - идентификатор периода опроса конкретного устройства
DISABLED - сстояние устройства(заблокирован или нет)
PARAMS - блок параметров устройства
DEVICE_ID - идентификатор устройства в линейке устройств производителя
VENDOR_ID - идентификатор производителя
GATEWAY_ID - шлюз, к которому подключено данное устройство, null - подключено непосредственно к контроллеру
ICON - имя иконки конечного устройства
AGGREGATION_PERIOD_ID - идентификатор периода выгрузки данных конкретного устройства в БД для статистики
AGGREGATION_EVENT_ID - идентификатор события вне периодической выгрузки данных конкретного устройства в БД для статистики
EXTRASCAN - признак поддержки конкретным устройством функционала экстренного опроса конечных устройств
PERMS - блок разрешений в рамках данного устройства для пользователей(аналогичен PERMS в описании LOCATION)
OWNER_IFACE_ID - идентфикатор физического порта интерфейса к которому подключено данное устройство(входящий).
IFACE - физический порт иннтерфейса который соединен с устройством к которому подключается данное устройство(аналогичен IFACE в GATEWAY).


ID - идентификатор параметра
PARAM_ID  - идентификатор типа параметра
VALUE - значение параметра
SUBTYPE_ID - подтип параметра(например для параметра 'Имя показания' здесь содержится идентификатор типа показания)

Возвращаемся назад.

ID - идентфикатор группы
NAME - имя группы
ICON - имя иконки группы
PLACE_ID - идентификатор помещения
COMMENT - комментарий к группе
*все вышеперечисленные параметры используются аналогично как и в DEVICE
SORT - значение для сорировки групп
ITEMS - блок элементов группы


ID - идентификатор элемента
DEVICE_ID - идентификатор конечного устройства
MEASURE_TYPE_ID - идентфикатор типа показания
NAME - имя показания
SORT - значение для сортировки элементов


ID - идентификатор разрешения
USER_ID - идентификатор пользователя
TYPE_ID - идентификатор типа разрешения


ID - идентфикатор локации
DEVICES - блок данных конечных устройств


ID - идентифкатор конечного устройства
MEASURES - блок показаний конечного устройства


TYPE_ID - идентификатор типа показания устройства
VALUE - значение показания устрйоства


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

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

Все это дает некоторую гибкость системе и позволяет ее достаточно легко расширять без участия разработчика.

Сценарии, начало.

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

  Итак, выбираем в меню 'Настройка сценариев'.


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


Создаем группу.
  Изначальное состояние группы - заблокировано, это означает, что контроллер не будет выполнять сценарии внутри этой группы. Рекомендую снять галку только после описания всех сценариев группы.
Объединение сценариев в группы имеет больше тематический характер, хотя есть и особенность, ведь группу можно включать и отключать(а также можно создать сценарий который будет выполнятся при этих действиях).
Этим можно воспользоваться, к примеру, занести в группу 'Сигнализация' все сценарии отвечающие за контроль дверей и прочее. Ну или скажем создать группу содержащую сценарии имеющие отношение ко временам года(хотя в самих сценариях можно указать периоды работы, например определенные месяцы).
  На этой форме, как и на предыдущей, есть кнопки стандартных действий: добавить, удалить, редактировать, обновить и клонировать. Последняя позволяет быстро сделать копию сценария.
  Также, внизу формы, есть кнопка 'Активировать изменения'. Эта кнопка передает все ваши текущие наработки в данной группе на сервер(или контроллер). До нажатия этой кнопки все изменения хранятся только на данной форме.


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

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


  Теперь детально:
Причина запуска:
1) Запуск группы сценариев - будет запущен при снятии галки 'заблокировать' данной группы. Это полезно, если необходимо при включении группы выполнять ряд действий, например послать всем устройствам управления команду 'вкл'.
2) Только системный вызов - означает что данный сценарий может запустить только другой сценарий.
3) В назначенное время - можно указать время(часы и минуты) когда требуется запустить сценарий, при этом можно указать время для повторного запуска. Контроллер будет выполнять повторы, скажем если было задано время запуска 00:00 с повтором каждый час, а текущее время создания данного сценария скажем 13:45. Т.е. запуск будет выполнен в 14:00, 15:00 и .т.д.


4) Обновление показания устройств - анализ сценария будет запущен когда обновятся данные показаний участвующих в анализе(блок 'Условие')
5) Нажатие виртуальной кнопки - в конструкторе(редактор проекта) можно добавить виртуальную кнопку. Здесь можно описать эту кнопку, таким образом можно запускать сценарий нажатием кнопки устройства в клиенте.


6) Написана/произнесена фраза - запуск осуществляется когда с точки управления(Телеграм, Алиса и прочее) поступает фраза. Здесь выполняется ее анализ. Также можно задать фразу которую получит пользователь в ответ.


7) Случайно - запуск сценария осуществляется случайно, проверка раз в минуту, здесь требуется указать вероятность(1/100 - вероятность 1 раз в 100 минут) т.е. для вероятности раз в две минуты нужно указать 50/100 или 1/2.


8) События от устройств - некоторые устройства могут посылать специальные события, по которым контроллер запускает сценарий.


9) Смена состояния контроллера - здесь речь о соединении с сервером, можно запускать сценарий при успешно
установленном соединении или при недоступности сервера. Также можно указать время ожидания.


10) Смена состояния устройства - аналогично предыдущему, но здесь также можно определять перезагрузку для некоторых устройств.


11) Остановка группы сценариев - аналогично первому пункту, но здесь срабатывает сценарий когда мы ставим галку 'заблокировать'

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


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


3)  В течении периода(расширенная форма) - здесь используется методика планировки задач в crontab. Мы можем указать время, дату и дни недели в течении которых будет продолжен анализ. Используется логическое и. Т.е. если время или дата или день недели не попадает под условие то анализ будет прерван. В полях день, месяц и год можно использовать разделитель ',' и диапазон(через '-'). При наведении на поле появится подсказка.


  Условие
  Пожалуй это самый сложный блок. В нем два элемента 'По показаниям устройств (логическое 'И')' и 'По показаниям устройств (логическое 'ИЛИ')'. Т.е. для успешного анализа, условия правил внутри блока должны быть или все истинны или истинно хотя бы одно соответственно.
  Далее видим кнопки:
  1) Добавить формулу - используется если нам нужно сделать какое-то вычисление на базе показаний в добавленных правилах или констант.
  2) Разрешает повторное выполнение сценария, если мы получили событие от устройства, даже если сам снимок показаний не изменился. Актуально для таких устройств как инфракрасный датчик для ИК пультов. Он может принять одинаковую последовательность данных, что должно быть интерпретировано как еще одна команда.
  3) Разрешает выполнение сценария при первом показании. После запуска контроллера или изменении в проекте существует ситуация, при которой старого значения показания нет, а оно нужно для анализа сценариев. Т.е. анализ выполняется только при изменении показания, отсутствие старого показания не означает, что само показание изменилось. Включенная кнопка означает, что контроллер будет считать, что показание все же изменилось.
  4) Блокировка частого выполнения сценария. Существует внутренний триггер, который после успешного выполнения сценария защелкивается и не позволяет повторное выполнение до тех пор, пока сценарий не пройдет анализ. Таким образом, к примеру,  Вы не будет получать одно и тоже сообщение каждый раз когда контроллер выполнит один и тот же успешный сценарий. Отключение кнопки отключает анализ триггера.
  5) Кнопки + и -  позволяют добавлять правила и удалять выбранное правило.


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


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


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

  Теперь о формулах. Формула также имеет номер , поле для ввода условие и значение для условия. А также кнопку проверки корректности введенной формулы. С помощью меню(правая кнопка мыши) можно подставить показания устройств которые должны быть добавлены заранее. Как и с условиями по показаниям само условие может отсутствовать.


  Таким образом данный функционал позволяет выстраивать цепочки логического 'И' или 'ИЛИ' с любым набором устройств и с любым набором условий для каждого устройства. А также можно добавлять формулы.


Информирование
1)  Никому - блок просто игнорируется
2)  Только мне - информирование будет выполнено только автору сценария
3)  Группе - информирование будет выполнено только для участников группы(пока не реализовано)
4)  Всем - всем в проекте, кто может получать информирование

  Форма для всех типов выглядит одинаково.
  Верхняя часть элементов:
  1)   Метка - в клиенте будет подсвечено красным показания присутствующие в условиях блока 'Условие'
  2)  Сообщение - сообщение будет выведено посредством клиента.
  3)  Телеграм - сообщение получат все пользователи с точкой входа 'Телеграм'
  4)  Эл. почта - аналогично, но для эл. почты.
  5)  СМС - аналогично, но для смс(пока не реализован шлюз, смс стоят денег)
  6)  Звук - на контроллере будет проигран звуковой файл.


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

Управление
1) Не управлять - игнорируем данный блок
2)  Управлять устройствами - здесь мы можем добавить несколько устройств, команды которых мы планируем выполнить.
3)  Запуск сценариев - аналогично, здесь мы добавляем сценарии, который планируем выполнить.
4)  Остановка сценариев - аналогично для остановки. На данный момент остановка нужна только для проигрывания звукового файла.
5)  Запуск внешнего скрипта - bash команда или файл выполняется на стороне контроллера
6)  Здесь можно выбрать сценарий, который не принадлежит текущему контроллеру. Т.е. текущий сценарий будет проанализирован скажем на контроллере А, а выполнен сценарий на контроллере Б.



Пример использования
  Это тестовый набор сценариев, обычного термореле(теплый пол). Задача - включать обогрев при температуре меньше или равно 35 градусам и выключать при температуре больше либо равно 36 градусам.

Первый, на включение обогрева.


Второй, на выключение обогрева.



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

update: добавил картинки

Видео, установка полнофункционального клиента под Windows



Клиент также, без особых проблем, ставится под различные Debian дистрибутивы Linux'а.




Ну и конечно всегда можно скачать архив с Джава машиной или без, и развернуть решение на любой другой ОС, где может работать Джава.

Дистрибутивы, клиент

Кхм, я уже давно выкладываю свой клиент в общий доступ.

Здесь есть и apk для Android'а, и инсталяционыый deb пакет для debian, и инсталлятор для windows, и даже инсталлятор для MacOs. Плюс ко всему лежат архивы для разных платформ с виртуальнй Джава машиной в комплекте и без нее. В основном все ставится очень просто и не требует ничего, просто запускаем ярлык по итогу.

Адрес стандартный http://5277.ru/distr.
Пробуйте, интересуйтесь, не лохотрон, вреда там нет. Это ведь не сложно? Более того, клиент теперь может подключаться к устройствам напрямую, без сервера и контроллера. Да и контроллер виртуальный есть.

Сейчас готова новая версия, планирую завтра ее выложить, 20 релиз.

Update: 20-ю версию выложил.

Хлебные крошки системотехника, watchdog под armbian

Я тут немного воюю с ресурсами nanopi с 256MB RAM, хочу, чтобы там себя хорошо чувствовала java8, при этом swap изначально там очень маленький, что-то около 200MB.
А сама JVM любит кушать 150MB минимум(без кучи), не хватат в общем.

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

Взаимодействие проще некуда:
Я добавляю параметр при запуске java контрллера -w /dev/watchdog.
А дальше работает мой контроллер, он инициирует watchdog и каждые 5 секунд обнуляет его, при завершении процесса watchgog отключается.
Таким образом, произойдет полный перезапуск железки, если упадет jvm или зависнет linux(ядро).

Watchdog кормлю '1' для инициализации, '.' для сброса счетчика и 'V' для отключения.

Java Json + Deflater/Inflater

Не совсем новый функционал, но теперь это рабочий функционал.

Здесь стоит рассказать о вещах лежащих в основе.
Если рассмотреть тот-же радиус протокол(ну понятно такого протокола нет, есть куча rfc), то мы увидим, что раньше передаваемые данные старались сделать максимально компактными, особенно в вопросах заголовков, посмотрите в тот-же ipv4 протокол(не забываем про флаг security rfc3514, шутка про голубей, лично по мне, меркнет по сравнению с этим rfc).

Так вот, почти каждый, вчера сильнейше обкурившись и начавший программировать профессионально под веб, знает что такое JSON.

Ну а старым пердунам куда деваться? Пока опишешь, перепишешь все поля и их содержимое в статическую структуру - так и кони двинуть можно, не молоды ведь. Остается пользоваться более простыми вещами, пусть и расточительными.
Вот и я, вырвав несколько седых волос, решил не заморачиваться и использовать текстовый формат передачи данных - JSON. Но! первое что я сделал для оптимизации - вместо названий полей стал использовать численные идентификаторы в шестнадцатеричном формате, затем обернул все зиппом используя Dedlater и Inflater. В итоге получил существенную оптимизацию, для больших данных экономия достигает 80%.
Стоит ли говорить о том, что передача показаний(а это основное) сжимается плохо, где-то на 30%, однако передаваемые сжатые данные чаще всего весят меньше чем обычный http заголовок(который сейчас очень популярен).

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

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

Java, изменение строки

Наткнулся на статейку http://www.skipy.ru/technics/strings.html#mutation

Там вполне грамотный чел рассказывает о возможности в Java изменить текст строки, даже не смотря на то, что строка объявлена неизменяемой (final).

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

В принципе так и делают многие компании, в нете также много онлайн тестов подобного характера.

И меня мучает один вопрос, как подобные знания применимы на практике?
Лично для меня это загадка.
Попросту потому, что нет никакой необходимости изменять таким образом текст строки в собственном проекте.
Более того, все эти хитрости в основном надуманные, мне незачем усложнять свой собственный код.
Оптимизация? А вам, к примеру, известно, что очень крупная торговая компания, пишет свои проекты в основном на 1C? Для этого она выделяет сервера с терабайтами оперативки и сетка между компьютерами там как минимум 1ГБит. Разработчики там получают по максимуму для нашего рынка.
Т.е. выигрыш в производительности после оптимизации кода на Java просто ничтожен, если сравнивать с продуктами писаными в той компании, а ведь там, судя по ЗП, программисты высшего уровня.

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

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

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

А еще меня смущает мода. Меня как-то поправил студент которого спросили, как правильно  Ява или Джава?
Парнишке с умным видом было невдомек, что некоторые названия имеют русский вариант произношения, например Австралия, мы же не говорим Оустрэлия.

Короче все плохо, мало того, что сферу интенсивно занимают люди, чья главная особенность - хорошая память, так еще хуже то, что сделать они надежные решения не могут. Ведь приглядитесь, все глючит, глючит в элементарной логике, в базовой логике, зачастую ошибки лезут из-за отвратительно плохой логики взаимодействия узлов системы.
Я из того поколения, который юность провел без интернета, работая на ZX Spectrum, позже немного в MS-DOS.
Я отлично помню программы, достаточно сложные программы, которые не глючили и были интуитивно понятны, в том числе и игры. Сейчас такое ПО - большая редкость. И можно сказать, что современная разработка ПО находится где-то на дне. Плохо то, что сейчас тоже самое происходит и со схемотехникой, где, на мой взгляд, основной причиной выступает торговая марка Ардуино.

О проекте (периодически обновляется)

Приветствую.

Похоже мне стоит кратко описать свой проект.

Проект представляет собой конструктор, под этим термином подразумеваются следующие особенности:
1) Широкая поддержка различных производителей и их устройств.
В проект заложены основы позволяющие его дополнять поддержкой сторонних устройств, в том числе сделанных своими руками.
2) Широкие возможности настройки подключения устройств.
Проект поддерживает большой набор различных интерфейсов подключения. Позволяет подключать конечные устройства через большое количество шлюзов, как простых так и с дополнительно настраиваемой логикой.
3) Контроллер (основной локальный узел управления конечными устройствами) может быть развернут на любом компьютере поддерживаемом Java 6 и выше (это может быть настольный компьютер, сервер, мини компьютер и даже в будущем Android устройство).
Проект позволяет выполнить поддержку всех интерфейсов подобных устройств при этом пользовательский интерфейс описания данных подключений достаточно понятный и не требует специфичных знаний.
4) Возможность как локального подключения клиента к контроллеру, так и облачного, что дает широкие преимущества, как например информирование, сбор статистики и удаленное управление.
5) Финансовая выгода - основные компоненты проекта бесплатны, платными будут дополнительные сервисы, как например разработка доп. функционала под заказ, использование дополнительных веб сервисов, аренда дискового пространства под статистику или разработка нового устройства.
6) Проект не потребует от вас специфичных знаний в электронике или знаний программирования, все достаточно просто и понятно. Однако подразумевается, что Вы имеете некоторое представление в области автоматизации.
7) В рамках проекта также разрабатываются недорогие устройства с существенными особенностями в сравнении с аналогами на рынке.


Основными компонентами проекта являются:
1) Удаленный сервер.
Предоставляет облачное решение (авторизация пользователей,  удаленное управление, мониторинг, сбор статистики и ее выгрузка, информирование, виртуальные контроллеры и тому подобное)
Сервер не распространяется, права на его использование есть только у меня и у компании 'Dipex group'.
На текущий момент заложены три площадки - официальная dipexlab, студентческая dipexlab и моя, для DIY инженеров.

2) Java контроллер.
Программное обеспечение которое можно развернуть практически на любом устройстве поддерживаемом Java 6 и выше.
Размещается на сайте вместе с устройствами автоматизации. Выполняет опрос устройств, управление (в том числе и по заложенным сценариям), передачу данных на сервер либо непосредственно в клиент.
Вся логика управления устройствами заложена в нем (хотя часть может находиться на конечных устройствах),
т. е. не требует наличия сервера(доступа к облаку).
В будущем будет доступен для Android устройств начиная с версии 4.0

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

Кроме этого, есть сторонние решения для управления устройствами (точки входа). В проекте заложен механизм позволяющий получать информацию об устройствах и управлять ими на базе фраз. На текущий момент реализованы следующие точки входа:
1) Мессенджер Телеграм.
2) Голосовой помощник Алиса.
3) Электронная почта
В будущем будет поднят СМС шлюз, появится СМС точка входа.

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

Среда передачи данных
Я сторонник проводных решений, в основном RS485. Существует большое количество минусов в беспроводных решениях, а их плюсы вряд ли перевесят минусы. В Dipexlab, как и в моих проектах, используется RS485 но с разными протоколами. Однако мои предпочтения никак не сказываются на самом проекте, точно также можно легко создать решение на базе WiFi к примеру.



И главное, еще раз, это конструктор.
Он Вам не нужен, если Вы купили комплексное решение от, скажем, Xiaomi. Но если Вы интегратор, или просто увлекаетесь электроникой и решили обвесить свой дом различными недорогими устройствами управления и датчиками, то здесь он в самый раз.
Безусловно, если вы купили, скажем, с десяток RGB WiFi ламп и теперь желаете все это дело объединить, то этот проект Вам также будет очень полезен.
Хотя, Вы в любой момент можете купить ограниченный в функционале готовый контроллер известного производителя  для ограниченного количества и типа устройств заплатив за него значительно больше чем за недорогой мини копьютер.

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

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

У проекта есть юр. лицо http://dipex.ru, есть лаборатория в ДВФУ(C305 - центр проектной деятельности)

UPDATE, 12.08.2019 добавлена информация