Модератор:immortal
Код: Выделить всё
$mac = $this->getProperty('MAC');
$name = $params['name'];
$json = getUrl($this->getProperty('Proxy')."/sendCode?mac=$mac&name=$name", 0);
$res = json_decode($json);
return $res->code; Код: Выделить всё
$name = $params['name'];
$res = $this->callMethod("send", array("name"=>$name));
if($res == 0) {
$val = $this->getProperty($name);
$this->setProperty($name, $val == 1 ? 0 : 1);
}
return $res; 
Вот тут и вопрос всплывает:nick7zmail писал(а): А свойство с объектом выбрал из выпадающего списка, привязал к выключателю например - и работает без единой строчки кода.
По-моему Вы недооцениваете пользователей Мажордомоnick7zmail писал(а):И тем более описывать пользователю не шарящиму в пхп, что чтобы отправить команду - он должен создать скрипт или метод, в котором будет вызывать данный метод у бродлинка, в котором надо указать в качестве параметра имя команды, которое надо еще взять из таблицы данных, для чего надо вернуться в таблицу с данными модуля бродлинк, посмотреть это имя, если его нет - вписать туда......это ж утопиться можно)) а если он там еще и опечатается по пути - дак всё...пиши - пропала...
А свойство с объектом выбрал из выпадающего списка, привязал к выключателю например - и работает без единой строчки кода.
Не совсем так. Свойство создаем, например,slgeo писал(а): Например, свойство Status = 1 - включен, Status = 0 - выключен. Ты писал, что при отправке команды это свойство выставляется в 1, а потом в 0. Так как выключать то?
Услуги в профиле коннектВ Погоде у Вас просто один объект с кодом, а здесь универсальный класс для типа устройства (RMPro, RM3), а объекты - это физические устройства Broadlink, создаваемые по discover и имена им дает пользовательnick7zmail писал(а):Плюс - если так делать - опять привязка к определенному объекту (без права выбора имени объекта)...сам так делал в модуле яндекс погоды, но не считаю, что это правильно. А тут любые объекты, любые свойства - выбирай не хочу))
В том же методе fun.turnONOFF, который я описал выше - ничего не мешает вам сделать третье свойство, не связанное с командой (fun.Status к примеру), которое как раз будет отслеживать "текущее" состояние. И кстати, если кто-то включит руками тот же вентилятор - сломается схема с хранением статуса) ибо нормальной обратной связи ни в РФ ни в ИР нету.slgeo писал(а):Вот тут и вопрос всплывает:nick7zmail писал(а): А свойство с объектом выбрал из выпадающего списка, привязал к выключателю например - и работает без единой строчки кода.
Например, свойство Status = 1 - включен, Status = 0 - выключен. Ты писал, что при отправке команды это свойство выставляется в 1, а потом в 0. Так как выключать то?
Ну класс то определенный опять же...без права выбора имени)) А если его кто переименует - при апдейте новый создастся...olehs писал(а): В Погоде у Вас просто один объект с кодом, а здесь универсальный класс для типа устройства (RMPro, RM3), а объекты - это физические устройства Broadlink, создаваемые по discover и имена им дает пользователь
Да не...я с уважением отношусь ко всем пользователям МД...но одно дело - люди, у которых МД уже лет 5 на нескольких серваках крутятся, а совсем другое - человек, который "скачал чтоб посмотреть", и тут его уже заставляют php коды на вызов метода писать)) Это во-первых отталкивает, во-вторых если таки не оттолкнуло - очень долго, с десятком скринов, объяснять приходится - как создать объект, зачем ему свойства/методы, и что он вообще делает))olehs писал(а): По-моему Вы недооцениваете пользователей Мажордомо
Объясню, почему я так сделал: вентилятор включается и выключается одной кнопкой пульта, а такая схема позволяет отслеживать состояние вентилятора на уровне объекта RM.
Думаю, для пользователей достаточно одного скриншота с настройкой кнопки с вызовом метода и он разберется
Услуги в профиле коннект Услуги в профиле коннект С этой идеей согласен, и мне нравится мысль перетащить по возможности все из модулей в классы и объекты - это как-то нагляднее, что-ли. Но на сколько это адекватно еще не совсем понял.olehs писал(а): универсальный класс для типа устройства (RMPro, RM3), а объекты - это физические устройства Broadlink, создаваемые по discover и имена им дает пользователь
Дак под это по-идее изначально все заточено. Т.е. Создаешь класс (бродлинк к примеру), создаешь объекты(РМ, А1, СП2 и т.д.), идешь в модуль, добавляешь устройство РМ, к нему привязываешь объект РМ, устройство А1, объект А1...и т.д. Модуль играет роль хранилища настроек и апи-обращений к данным устройствам, и транслирует всё в свойства данных объектов...Ged писал(а): С этой идеей согласен, и мне нравится мысль перетащить по возможности все из модулей в классы и объекты - это как-то нагляднее, что-ли. Но на сколько это адекватно еще не совсем понял.
Ну для начала не "какие сможет выдернуть", а все, которые обозначены в апи. Что вы будете делать с массивом данных? Мне вот просто интересно... Сделать то это не проблема...проблема применить)))пока не пойму зачем? Будет у вас с А1 массив $response={'temp':'24', 'hum':'56', 'noise':'1', 'qual':'2', 'lum':'3'}...ну и что с ним делать? Вы же эти значения по-любому по свойствам распихивать будете...А зачем это делать, если это за вас модуль уже делает?Ged писал(а): Команду хочу, и еще хотелось бы таки, все параметры получать в массив. Опять-таки, это для меня понятнее и прозрачнее, чем "оно раз в час обновляет свойства, какие сможет выдернуть"
Услуги в профиле коннект