MajorDoMo

T-REX-XP писал(а): Ср авг 01, 2018 9:44 pm основная задача это автоматом делать однотипные действия с добавлением во все места системы( терминали, ПУ, устройства онлайн,.... )

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

так а разве на сегодня не так ?

tarasfrompir1 писал(а): Ср авг 01, 2018 10:10 pm Почти со всем согласен - НО зачем это - "А так сказать нужный драйвер мы найдем в маркете и предложим установить/установим."
если все это можна автоматизировать и качать автоматом с гита для устанавливаемого устройства класс, методы и шаблон??? А потом все удалять если устройство удалилось из системы...
Просто я думаю что в маркет не дадут напихать даже с 10 устройств ...

все так. имею ввиду что модуль может найти сам драйвер в маркете и установить его.

маркет нужен как каталог модулей

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

Такс автоподкачку реализовал - теперь немного коечего переименовать и можна пробовать.
А вот автоуборку еще не реализовал - не докумкал.....еще... Уж очень много условий получается...

модуль при удалении не чистит за собой /var/www/html/modules/devices/addons (на уровень выше тоже мусор остался, еще и файлы задвоенные)
и в итоге даже если поудалять все классы они создаются заново (при рестарте циклов) при деинсталлированном модуле
п.с. tarasfrompir1 в тлг посмотрите там со скринами

Logrus писал(а): Пт авг 03, 2018 9:53 am модуль при удалении не чистит за собой /var/www/html/modules/devices/addons (на уровень выше тоже мусор остался, еще и файлы задвоенные)
и в итоге даже если поудалять все классы они создаются заново (при рестарте циклов) при деинсталлированном модуле
п.с. tarasfrompir1 в тлг посмотрите там со скринами

Logrus - спасибо за ответы
Автоуборка еще не реализована ВООБЩЕ
Да и модуль находится сейчас здесь в текущей наработке - https://github.com/tarasfrompir/SSDPFinder_betta
Да и мусор опишу потом какой удалять...
ПОКА все очень сыро

tarasfrompir1 писал(а): Ср авг 01, 2018 8:49 pm По поводу выбора ПУ
Была единственная разработка дающая возможность добавлять устройства програмно...
да и направлпение перспективное если сам разработчик его создавал...

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

Gelezako писал(а): Пт авг 03, 2018 11:44 am

tarasfrompir1 писал(а): Ср авг 01, 2018 8:49 pm По поводу выбора ПУ
Была единственная разработка дающая возможность добавлять устройства програмно...
да и направлпение перспективное если сам разработчик его создавал...

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

Вообще то Gelezako - ты красавчик ...
Уговорил за пять минут...

T-REX-XP писал(а): Ср авг 01, 2018 9:44 pm мне не удобно работать с разношерстными устройствами. мне нужен стандарт. это как раз и есть ПУ. А еще меня заебало в 2018 году устройства с нуля создавать в системе.

Юра, я не понял что ты имеешь ввиду под "устройства с нуля создавать в системе". В каком смысле с нуля?

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

А так сказать нужный драйвер мы найдем в маркете и предложим установить/установим.

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

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

Если я правильно понял, то архитектура Тараса такая: При создании модуля для управления устройствами, модуль должен сам автоматически создать объект в ПУ и пользователю останется просто прилинковать объект. Причём для управления устройством не используется интерфейс своего модуля, а используется механизм модуля ПУ для создания своего собственного шаблона управления устройством (прощайте стандартные контролы и концепция один шаблон под разные драйверы . Плюс в том что пользователю не нужно самому создавать объект, недостающие свойства, методы и наполнять их кодом. Т.к. объект генерирует сам драйвер, он может создать все недостающие свойства, методы и наполнить их управляющим кодом.

Архитектура Юры (T-REX-XP) такая: Шаблоны для стандартных устройств (пример лампочка) должны быть одинаковыми. Должна быть возможность использовать этот шаблон для управления любым однотипным устройством разного производителя (например Philips Hue или Yeelight). Архитектура не предусматривает автоматическое создание лампочки через ПУ. Пользователь сам создаёт лампочку через ПУ, а потом подтягивает нужный драйвер (модуль) для обнаружения и управления устройством. Минус такого подхода состоит в том что почти всегда нужно создавать вручную недостающие свойства, методы, наполнять их кодом, потом прилинковать их на странице драйвера (модуля). Драйвер не может этого сделать сам т.к. объект устройства ещё не создан пользователем. Плюс в том что у нас появляется один стандарт для всех устройств.

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

Gelezako писал(а): Пт авг 03, 2018 12:35 pm Если я правильно понял, то архитектура Тараса такая: При создании модуля для управления устройствами, модуль должен сам автоматически создать объект в ПУ и пользователю останется просто прилинковать объект. Причём для управления устройством не используется интерфейс своего модуля, а используется механизм модуля ПУ для создания своего собственного шаблона управления устройством (прощайте стандартные контролы и концепция один шаблон под разные драйверы . Плюс в том что пользователю не нужно самому создавать объект, недостающие свойства, методы и наполнять их кодом. Т.к. объект генерирует сам драйвер, он может создать все недостающие свойства, методы и наполнить их управляющим кодом.

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

Вот теперь по поводу архитектуры все написано очень правильно. И плюс огромный для этого.... Не нужно ничего делать нажал добавить и все...
Результат безсоной ночи и дня "рабочей" работы
Для желающих опробовать этот вариант - смотрите пока сюда - https://github.com/tarasfrompir/SSDPFinder_betta
со временем перенесем на нужное место...

Не решено несколько нюансов и мелких доводок - но они не заметны... (сломано лого не пойму как крутить его) Юра потом подправит или расскажет как это сделать...
ПО Поводу мусора -
1. снести сам модуль.
2. удалить все файлы по списку (хотя всего этого можно и не делать ) НО лучше сделать - поскольку во всех файлах в папке devices сам черт ногу сломит методов и так много а еще и не нужные методы лежат, поэтому лучше удалить.... ТЕПЕРЬ -
ВСЕ РАБОТАЕТ ТАК как и было-
НО модуль автоматически подкачивает - ("драйвера" для устройства) все файлы необходимые для работы текущего устройства.
И соответственно удаляет все это после того как будет удалено ПОСЛЕДНЕЕ устройство такого типа.
Тоесть если было 2 медиасервера и вы 1 удалили то все необходимые файлы останутся...

ТАКЖЕ удаляет все Созданные классы для даного устройства , записи в базе о созданных методах.
Чего еще не нашел - того не нашел... После нескольких тестов узнаю...
Просьба отписатся тем кто опробовал модуль Бета2