[Модуль] Broadlink (dev_broadlink)

[Nail]

Подскажите , в новом приложение я не нашел как скачивать рез.копирования для получения из облака коды ИК пультов и Rf коды ?

[AE_]

Доброе время суток.
Наткнулся вот на такую "особенность":
при попытке установить значения нескольких properties, привязанных к Broadlink устройству, сохраняется только последнее.
Проблема возникает если изменять свойства, передаваемые в устройство за один вызов. Для примера - HYSEN.set_advanced(...), где помимо прочего устанавливается диапазон допустимых значений целевой температуры, svl..svh.
В результате, код

Код: Выделить всё

setGlobal('therm1.svh', 10);
setGlobal('therm1.svl', 30);

сохраняет только значение svl.
Происходит это, поскольку при повторном вызове set_advanced() ему передается еще старое, не измененное значение проперти .svh

Это можно обойти, добавив небольшую задержку между setGlobal. В принципе, у меня достаточно и 0.1 секунды, 0.05 уже не помогает:

Код: Выделить всё

setGlobal('therm1.svh', 10);
usleep(100000);
setGlobal('therm1.svl', 30);

Тем не менее, этот хак можно применить не везде. Например, если описать "простое устройcтво", у которого присутствуют svl/svh, то из стандартного конфигуратора MD будет возможно изменить только одно значение.

MD - актуальный master, платформа win10. Под debian пока проверить не могу - умерла железка, увы.

Извините, оно само...

И еще вопрос: а почему закомментирован set_time()? Не по той же причине случайно?
Полезная же функция.
Я тут для WiFi термостата "простое устройство" нарисовал, хотелось бы не просто показать что время неправильное а сразу его синхронизировать.

[AE_]

Еще один багрепорт:
Время от времени термостат в ответ на запрос статуса присылает либо битый пакет, либо пакет другого формата.
Несмотря на то, что контроль целостности проходит - в payload содержатся неверные данные. Если при этом к свойтсву broadlink устройства привязано свойство класса MD - то оно получает неправильное значение. В результате срабатывает триггер на изменение значения свойства объекта, и это новое (уже не верное!) значение будет передано через Broadlink в термостат.
Как это выглядит:

Код: Выделить всё

10:03:40 HYNSEN.get_status: temp=29.5, [5..35]: 1,3,44,0,0,59,59,0,0,0,0,35,5,0,0,1,0,0,0,3,40,42,6,6,0,8,0,11,30,12,30,17,0,22,0,8,0,23,0,40,30,30,30,44,33,44,30,171,195
10:03:40 HYNSEN.get_status: temp=1.5, [0..0]: 165,165,90,90,98,193,3,11,9,0,0,0,0,59,59,35,5
10:03:40 dev_broadlink: 'thermostat_temp' set '1.5'
10:03:40 therm01.targetTemp changed to '1.5'
10:03:40 dev_broadlink: set_temp({8,0,1,6,0,1,0,3,152,11})
10:03:40 HYNSEN.set_advanced({19,0,1,16,0,2,0,5,10,0,9,0,0,0,5,0,0,1,0,165,250})
10:03:40 HYNSEN.get_status: temp=1.5, [0..0]: 1,3,44,0,0,59,3,0,0,0,0,0,0,0,0,1,0,0,0,3,40,55,6,6,0,8,0,11,30,12,30,17,0,22,0,8,0,23,0,40,30,30,30,44,33,44,30,191,5

И это совсем проблема, ибо на уровне MD такие глюки отфильтровать уже невозможно.
Фигня происходит несколько раз в сутки. Если через модуль привязывать SThermostats, то проблемы незаметно, ибо SThermostats плюет на текущие значения, каждый раз переустанавливая новое. А вот пользоваться термостатом как термостатом а не как реле системы обогрева при этом нельзя - температура сбрасывается на 1.5 градуса.

Workaround: в HYNSEN.get_status() хотя бы проверять не просто наличие данных, а наличие достаточного количества данных:
if(count($enc_payload) > 22){

Решением было бы проверять целостность пакета - если там вообще есть контрольная сумма.
Или хотя бы диапазон допустимых значений: (dayofweek>0) && (svh>svl) && (svl>0) и тд.

[nick7zmail]

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

[deemjd]

Я тут для WiFi термостата "простое устройство" нарисовал, хотелось бы не просто показать что время неправильное а сразу его синхронизировать.

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

[AE_]

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

Так всегда пожалуйста
Только минимально необходимая функциональность.
Если в свойствах targetTempNormal или targetTempEco указать температуру - она будет устанавливаться при переключении в соответствующий режим.

Обязательно прилинковать:
power => .status (вкл/выкл)
thermostat_temp => .targetTemp (оно самое)
auto_mode => .autoMode (для отключения режима работы по расписанию)
active => .active (состояние реле термостата)
min => .minutes (периодическое обновление статуса термостата)

Прилинковать желательно:
svh => .targetTempMax
svl => targetTempMin

А если прилинковать hour, или dayofweek, то будет видно, если на термостате неправильно выставлено время. Но просматривая исходники модуля я обнаружил что время на термостате в любом случае синхронизируется каждые сутки в 00:00

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


2nick7zmail: спасибо за commit!

[AE_]

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

Для завязки разговора: я готов подготовить PR еще для одной проблемы но требуется обсуждение

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

Причина в том, что модуль опрашивает все устройства подряд (dev_broadlink_check.inc.php#78), независимо от того, доступно ли в текущий момент устройство или нет. В результате опрос выключенного устройства занимает до 10 секунд (константа Broadlink->$timeout). Более того, некоторые устройства (тот же HYSEN) опрашиваются в несколько последовательных вызовов и время, соответственно, возрастает кратно.

Проблема более-менее эффективно решается если внутри цикла опроса сделать ping на устройство и проверить результаты (dev_broadlink_check.inc.php#84):

Код: Выделить всё

if(!is_null($rm) && $rm->ping() ) {

Я поигрался с этим workaround'ом, с таймаутом 500мс. В результате все работает как положено и даже при 10 недоступных устройствах (8 термостатов, RM4Pro и RM4mini) задержка составляет меньше 6 секунд. Успешный ping у меня отрабатывает 10-50мс, здесь тоже говорить не о чем.

НО.

Метод ping() уже реализован в базовом классе. И в нем вроде бы все хорошо - за одним исключением: по умолчанию (кроме пары устройств) используется UDP ping, который не работает ни с одним из моих устройств. В отличие от ICMP, который (насколько я понимаю) в локальной сети должен работать практически всегда. Но поскольку у меня нет возможности проверить это на всем зоопарке поддерживаемых устройств а последствия неправильно работающей проверки будут фатальны - вопрос: насколько безопасно будет перевернуть логику, сделав ICMP ping основным, а UDP - на правах исключения для устройств где это действительно необходимо?

Еще есть вариант "и нашим и вашим": ICMP ping, если устройство недоступно то UDP. Но в моей конфигурации UDP ping отрабатывает до 4 секунд. Это, конечно, лучше 20с но все равно овердофига...

Ну и как уже написал: если получу одобрямс то готов оформить PR. Если нет - опубликую workaround здесь, пусть кому нужно хакают сами

nik7zmail, м?

[AE_]

В результате все работает как положено и даже при 10 недоступных устройствах (8 термостатов, RM4Pro и RM4mini) задержка составляет меньше 6 секунд. Успешный ping у меня отрабатывает 10-50мс, здесь тоже говорить не о чем.

Спасибо nik7zmail за обновление модуля!

• Время на термостате теперь автоматически синхронизируется (в случае если часы убежали больше чем на 30 секунд) при каждом опросе а не только в течение первой минуты после полуночи.
• Модуль теперь умеет не опрашивать выключенные устройства. Для этого в настройках необходимо поставить галочку "проверять доступность устройств перед опросом".

[Vlad520i]

По rm4 какие нибудь продвижения есть?

[Vlad520i]

Если кто объяснит как с ним работать. готов поблагодарить.