Подключение Broadlink RM Pro

[jon75]

А кто знает, orvibo работает с броадлинковской переферией (A1, SPmini)?
А использовать планшет как прокси отличная идея. Он же может использоваться для управления всей системой мажордомо.

[sergejey]

Да, там уже скомпилированные библиотеки . Я не смог найти информацию, можно ли как-то использовать библиотеки Android под другими операционками.
Есть идея написать под Android шлюз в какой-то стандартный TCP протокол. Тогда можно будет поднять его на одном из планшетов или на отдельном свистке.
Сергей, если писать такой шлюз, то какой лучше протокол выводить наружу?

Если есть возможность написать шлюз, то лучше всего иметь возможность к нему обратиться по HTTP и возможность в нём же настроить HTTP-callback, т.е. при возниконовении события делать из шлюза запрос в систему.

[jon75]

Вот здесь человек дает описание запроса udp на 80 порт. Пакет зашифрован, но при отправке на устройство срабатывает.
http://4pda.ru/forum/index.php?showtopic=573779&st=140
Сами пакеты тут
https://cloud.mail.ru/public/AY3p/75hjzhg5i
Может кто сможет вытянуть что полезное?

[sergejey]

Вот здесь человек дает описание запроса udp на 80 порт. Пакет зашифрован, но при отправке на устройство срабатывает.
http://4pda.ru/forum/index.php?showtopic=573779&st=140
Сами пакеты тут
https://cloud.mail.ru/public/AY3p/75hjzhg5i
Может кто сможет вытянуть что полезное?

Для анализа двух пакетов, боюсь, маловато будет. Если оно работает аналогично Orvibo, то там по-сложнее алгоритм, нежели отправка определённых пакетов.
Как это происходит у Orvibo:
1. Головной софт при старте отправляет широковещательный пакет типа "отзовитесь, кто живой"
2. Каждое из присутствующих в сети устройств присылает свою метку (свой mac-адрес и его тип)
3. Головной софт отправляет на каждое из отозвавшихся устройств запрос на "подписку", что значит возможность управления и приём событий от устройства
4. Каждое из устройств рапортует о подписке и готовности к приёму команд
5. Головной софт отправляет команды и получает уведомления

Каждый пункт связан с формированием пакета по особому алгоритму -- пакет обычно включает mac-адрес адресуемого устройства, тип команды, дополнительные данные для команды и контрольную сумму по особому алгоритму. Для разбора протокола нужна полная сессия общения между головным софтом и устройством с момента включения, а потом надо по крупицам собирать полезную информацию, сравнивая пакеты, находя закономерности и подбирая алгоритмы кодирования. В общем, всё сложно и желательно к этому подключить человека с соответствующим опытом разбора протоколов.

[olehs]

Если есть возможность написать шлюз, то лучше всего иметь возможность к нему обратиться по HTTP и возможность в нём же настроить HTTP-callback, т.е. при возниконовении события делать из шлюза запрос в систему.

Тут вопрос, насколько шлюз должен быть умным. API позволяет считать посылку из эфира, а потом отправить ее назад в эфир. Т.е. сохранение самого кода (а это десятки байт) ложиться на плечи ПО. Вопрос - должен ли шлюз сохранять эти коды, или же просто передавать дальше.

Я потому и спрашивал про протокол (я имею ввиду протокол прикладного уровня, поверх HTTP). Может есть протокол поверх HTTP (уже поддерживаемый МД), который умеет работать с посылками RC данных.

Насчет HTTP-Сallback: у RM Pro вроде бы и событий та никаких нет. Ну, разве что, получить температуру с внутреннего датчика, но я этого функционала в API не видел.

[sergejey]

Если есть возможность написать шлюз, то лучше всего иметь возможность к нему обратиться по HTTP и возможность в нём же настроить HTTP-callback, т.е. при возниконовении события делать из шлюза запрос в систему.

Тут вопрос, насколько шлюз должен быть умным. API позволяет считать посылку из эфира, а потом отправить ее назад в эфир. Т.е. сохранение самого кода (а это десятки байт) ложиться на плечи ПО. Вопрос - должен ли шлюз сохранять эти коды, или же просто передавать дальше.
Я потому и спрашивал про протокол (я имею ввиду протокол прикладного уровня, поверх HTTP). Может есть протокол поверх HTTP (уже поддерживаемый МД), который умеет работать с посылками RC данных.
Насчет HTTP-Сallback: у RM Pro вроде бы и событий та никаких нет. Ну, разве что, получить температуру с внутреннего датчика, но я этого функционала в API не видел.

Коды в шлюзе сохранять не обязательно, можно просто пересылать их в систему по HTTP, а система сама их будет хранить. Про API поверх HTTP можно почитать здесь, т.е. шлюз может устанавливать свойства объектов либо вызывать методы/сценарии, передавая им полученные данные. Самое простое, это вызвать сценарий по ссылке типа http://ip/objects/?script=myScript&para ... am2=value2.. (вместо paramN/valueN свои данные).

Событий там точно никаких нет? Мне почему-то думалось, что он может реагировать на радио-сигналы, но если нет, то нет.

[jon75]

RM PRO только передает записанные команды, считывает в режиме обучения, статус устройств отображает ПО.

[erandess]

Появилась возможность подключиться RM PRO через шлюз RM Bridge. Информация здесь http://milillicuti.com/an-api-to-connec ... on-system/ и здесь http://broadlink.ru/topic/37/upravlenie ... rumentami/ . Может кто из гуру поможет адаптировать его к мажордомо?

[olehs]

Как-то очень сложно все там на первый взгляд.
Я на днях как раз закончил свой bridge. Он без интерфейса, но по сути делает тоже самое.
Только, как по мне - у меня управление проще, т.к. он сам умеет запоминать коды.
Правда, работает только с самим RM2 Pro, просто прочих девайсов у меня нет.

Если кто хочет попробовать, выкладываю на GitHub (там же есть apk)

https://github.com/olehs/BroadlinkHTTPProxy

[erandess]

Не, несложно. Через RM-comander под виндой считываются коды пультов в отдельные файлы. А потом любым скриптом через curl на шлюз отправляются три файла: инициализации, выбора устройства и сам код. Примерный скрипт на PHP я набросал, а хотелось бы оформить это дело в модуль как с Orvibo.