MajorDoMo

sergejey писал(а): Видимо, из-за того что я интернет-программист, то описано как для себе подобных

Хорошо, можно тогда начать "от печки"?

В GitHub сказано, что MajorDoMo написан на php. Если я правильно понимаю, это означает, что доступ ко всем ресурсам на самом сервере - через сервисы php. Что интерпретатор php предоставляет, то и имеем - доступ к сервисам оси, usb, блютусу, и т.п. - все через него. Верно? Если я хочу подключить свое собственное железо, напимер, через usb, то сначала я должен каким-то образом подрихтовать php, а потом написать"модуль" для MajorDoMo. Однако если, к примеру, мое железо подключается к usb при помощи драйвера класса CDC и появляется в системе как виртуальный Com порт, то мне, наверное, рихтовать php не потребуется, я сразу смогу начать писать модуль для MajorDoMo.

А доступ к ресурсам вне сервера - такой же, как к любым другим интранет/интернет ресурсам. То есть, через IP попадаем на нужную страницу, и уже оттуда вытягиваем информацию в том виде, в каком она там представлена. А поскольку стандартов нет (или есть, может, я просто не знаю?), то каждое устройство выкладывает инфу в том виде, в каком захотелось его разработчикам, поэтому каждое конкретное устройство нуждается в индивидуальной привязке. Поэтому, если я сделаю эзернет-железяку, с которой можно будет общаться при помощи веб-страницы, то особых проблем не будет, так или иначе можно будет написать специальный модуль, который с этой страницы считает инфу и по командам MajorDoMo будет нажимать на этой странице кнопки. Я правильно понимаю?

akouz писал(а):В GitHub сказано, что MajorDoMo написан на php. Если я правильно понимаю, это означает, что доступ ко всем ресурсам на самом сервере - через сервисы php. Что интерпретатор php предоставляет, то и имеем - доступ к сервисам оси, usb, блютусу, и т.п. - все через него. Верно? Если я хочу подключить свое собственное железо, напимер, через usb, то сначала я должен каким-то образом подрихтовать php, а потом написать"модуль" для MajorDoMo. Однако если, к примеру, мое железо подключается к usb при помощи драйвера класса CDC и появляется в системе как виртуальный Com порт, то мне, наверное, рихтовать php не потребуется, я сразу смогу начать писать модуль для MajorDoMo.

А доступ к ресурсам вне сервера - такой же, как к любым другим интранет/интернет ресурсам. То есть, через IP попадаем на нужную страницу, и уже оттуда вытягиваем информацию в том виде, в каком она там представлена. А поскольку стандартов нет (или есть, может, я просто не знаю?), то каждое устройство выкладывает инфу в том виде, в каком захотелось его разработчикам, поэтому каждое конкретное устройство нуждается в индивидуальной привязке. Поэтому, если я сделаю эзернет-железяку, с которой можно будет общаться при помощи веб-страницы, то особых проблем не будет, так или иначе можно будет написать специальный модуль, который с этой страницы считает инфу и по командам MajorDoMo будет нажимать на этой странице кнопки. Я правильно понимаю?

Писать модуль для устройства и, тем более, "рихтовать" PHP задача достаточно нетривиальная и редко необходимая. Модули обычно пишутся под распостранённые и востребованные протоколы, чтобы работать с ними было удобней. Для работы с устройствами можно вполне обойтись и без модулей -- в системе присутствует достаточно продвинутая модель классов/объектов, используя которую можно реализовать взаимодействие практически с любым устройством, до которого можно каким-то образом достучаться и протокол обмена с которым как-то описан -- через сеть, через командную строку, через COM-порт и т.п.

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

Что касается доступа к ресурсам вне сервера -- приблизительно так как описано. Плюс есть ещё кое-какие сетевые стандарты, работающие не по http. Например, SNMP или MQTT, модули для работы с которыми идут в "коробке".

sergejey писал(а):

akouz писал(а): был написан класс с методами взаимодействия и каждый может его у себя создать, а потом добавить свои устройства как объекты ну и работать с ними в системе как с любыми другими объектами.
...
есть ещё кое-какие сетевые стандарты, работающие не по http. Например, SNMP или MQTT, модули для работы с которыми идут в "коробке".

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

akouz писал(а):Таким образом, если делать собственное железо или интегрировать какое-то готовое, то для USB его проще всего будет привязать через этот класс, а для эзернета - через MQTT. Соответственно, при выборе готовых систем нужно сразу смотреть, какую связку они предоставляют. И если, к примеру, в описании бриджа USB-Velbus написано, что он использует CDC драйвер, то есть неплохой шанс, что его удастся привязать через этот класс.

USB, COM, ETHERNET -- это транспортный уровень, поверх которого работает уровень протокола обмена, который может быть совершенно разным у разных производителей. У того же Velbus он достаточно специфический и беглый обзор показал, что USB-адаптер реализует транспортный уровень (если я правильно понял, то адаптер организует COM-порт для отправки/приёма команд) и поверх этого транспортного уровня нужно реализовывать систему команд. Некоторые производители работают на каком-то из стандартных протоколов обмена (ModBus, MQTT, SNMP и т.д.). Другие производители работают по сети и предоставляют какой-то интерфейс для работы с ними извне (какое-то API с набором команд).

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

cycle.php -- запуск основных циклов системы (см. папку cycles\)

у меня такой папки вообще нет. а посмотреть на скрипты хочется. Версия 0.7.0b

RusikOk писал(а):

cycle.php -- запуск основных циклов системы (см. папку cycles\)

у меня такой папки вообще нет. а посмотреть на скрипты хочется. Версия 0.7.0b

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

Смотрите папку "scripts". Там они все родимые лежат.

если я правильно понимаю, то весь информационный обмен происходит (как и любой другой web ориентированной информационной системе) через БД. и данные с датчиков не исключение

Сергей, если не секрет, из каких соображений в качестве языка сценариев был выбран PHP а не Python?

Alpor писал(а):Сергей, если не секрет, из каких соображений в качестве языка сценариев был выбран PHP а не Python?

думаю по причине здравого смысла

Alpor писал(а):Сергей, если не секрет, из каких соображений в качестве языка сценариев был выбран PHP а не Python?

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