MajorDoMo

Такое устройство можно сэмулировать, но для начала надо пометить на втором этаже, что является светом, что подсветкой, что тв/приставкой/ресивером И рулить всем этим через foreach. Купил, добавил RGB-ленту, пометил подсветкой, привязал ко второму этажу - и она тоже стала вкл/выкл по расписанию или по движению.

Через foreach то понятно что можно...у меня так и сделано. Но не каждому новичку это под силу.
В идеале пользователь вообще не должен знать, что такое объекты, свойства методы, и т.п.
Плюс имеется проблема, когда включаешь 1 из устройств группы - выключатель группы должен переводиться в on. А когда переводить выключатель в on - выполняется метод включения, который по идее должен подтягивать(включать) все объекты группы, и получается хаос)) Я то конечно способен открутить свойство от метода, и вызывать отдельно метод при ручном передергивании статуса, не трогая его при простом sg(). Но среднестатистического пользователя явно такие вещи беспокоить не должны.

Отправлено с моего G8441 через Tapatalk

ВОПРОС на засыпку - :
Кто, при срабатывании устройства - ну того же датчика движения - что делает ?
1. Толи запускает метод ?
2. Толи изменяет значение свойства устройство.status?

тут надо как то стандартизировать... или способ сработки устройства или методы дорабатывать..
ПС
Лично я бы изменял по второму варианту - тогда проще было бы универсализировать МЕТОДЫ для устройств...

ИЛИ же в каждый метод вставлять $this->setProperty('status', 1);

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

Отправлено с моего G8441 через Tapatalk

В статус прилетает 1 и по смене статуса срабатывает связанный метод, неча там стандартизировать

Это у нас так - а у людей огого..игого...

nick7zmail писал(а):Я уже предлагал пару десятков страниц назад хотя бы сделать групповые устройство, статус которого меняется, когда поменялось хотя бы одно устройство в группе, а ручное изменение статуса устройства отражалось бы на всей группе. Например есть групповое устройство свет на 2 этаже. Часть входящих в него устройств включены, часть выключены. Статус группового показывается вкл, и 1 кликом вырубается весь включенный свет на 2 этаже.

Как то без внимания осталось...

Отправлено с моего G8441 через Tapatalk

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

Приведу пример с Xiaomi Gateway. В модуле я добавил отдельно RGB-контроллер и отдельно датчик освещённости. Простые устройства создали 2 разных объекта со своим набором свойств для каждого устройства, но физически это одно устройство.

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

Upd: Упс! Спросоня вбил как коммент к файлу! Пришлось возвращаться и повторно отправлять: со смарта копирование в буфер не пахало и надо было драг энд дропом переносить...

nick7zmail писал(а):Я уже предлагал пару десятков страниц назад хотя бы сделать групповые устройство, статус которого меняется, когда поменялось хотя бы одно устройство в группе, а ручное изменение статуса устройства отражалось бы на всей группе. Например есть групповое устройство свет на 2 этаже. Часть входящих в него устройств включены, часть выключены. Статус группового показывается вкл, и 1 кликом вырубается весь включенный свет на 2 этаже.

Как то без внимания осталось...

Отправлено с моего G8441 через Tapatalk

Собственно я тоже высказывался на тему, что в идеале должно быть:
1. Простые входные устройства - датчики, кнопки, выключатели.
2. Простые выходные устройства: реле и т.д.
В простом случае - можно тупо завязать входное к выходному, как сейчас.

И 3: простые связки.

Т.е. банальная ситуация: есть люстра. Две лампы. И кнопка. Сейчас кнопку можно привязать напрямую нормально только к одной лампе. Или сразу обе туда-сюда.
Ставим "простую люстру" - на вход нашу кнопку или несколько, на выходы - наши лампы. При нажатии на кнопку срабатывает метод свитч "люстры", который по заданному циклу переключает лампы!

И т.д. и т.п. - виртуальные устройства, которые служат прослойкой для датчиков и исполнителей.

Режим NightMode.
Вопрос - кто-то им пользуется? И зачем?
В текущий момент есть DarknessMode, который обозначает "темноту на улице". Там вставляются "инъекции" от простых устройств, и в файле описаны некоторые действия для устройств, у которых включено "Выключать с рассветом"...допустим...

В NightMode же тоже есть "инъекция" простых устройств, но если открыть файлы - они пустые. Ничего не делают...
Допустим кто-то юзает этот режим для выключения звука на терминалах или ещё где, чтобы Алиса не будила какими нить инфо-сообщениями...но почему NightMode?? Я бы его назвал SilentMode, и использовал бы и днём к примеру в тихий час, или ещё когда...

Собственно в связи с чем предложение:
- Убрать его нафиг из простых устройств, ибо он всё равно ничего не делает (удалить файлы из devices, удалить "инъекции" в методы из формирования структуры)
- Убрать его из системы (те кто хочет оставить - могут оставить, те кому нужен будет на новых системах - создадут, а те, кому он не нужен - хотелось бы, чтобы была возможность удалить его!)

Кто за - отпишитесь, кто против - аргументируйте...