[Модуль] Broadlink HTTP Bridge (dev_httpbrige) Устарело!

[secbit]

Я попробую реализовать логику BroadlinkCommand на PHP...если выйдет - то получится рулить рм-кой модулем без всяческих сторонних прог...

Если же не получится, то мне понравилась идея corpse. Если будет хорошее апи - помогу накатать интерфейс...возможно в виде модуля для МД. Панель управления тоже на бустрапе написана...

Вот если вы напишете возможность принимать пакеты и анализировать ответы, то это было бы очень круто, так как тогда бы можно было узнавать состояние к примеру розетки SP2 mini, возможно и других, не знаю. Хочу еще заказать выключатель бродлинковский и с ним попробовать.

[corpse]

Видимо в MP1 логика другая, тем более что это отдельное устройство по WiFi, так все немного не так, как с RM2

Ну, это было очевидно с самого начала.
В MP1 логика скорее всего такая же, как в SP1/SP2/SP3.
То есть, сначала отправляется некий пакет, или даже два, получается ответ и только после этого можно слать пакет на включение/выключение розетки.

Вот если вы напишете возможность принимать пакеты и анализировать ответы, то это было бы очень круто, так как тогда бы можно было узнавать состояние к примеру розетки SP2 mini, возможно и других, не знаю. Хочу еще заказать выключатель бродлинковский и с ним попробовать.

Я пытаюсь анализировать протокол, но остаток пейлоада для меня - тёмный лес. Как он формируется - непонятно.
Сейчас пытаюсь анализировать пакеты, летящие от MP1. Если разобраться с ними, то и с розетками всё станет просто.
Вот пример пейлоада типичного пакета для MP1:
5aa5aa555aa5aa550000000000000000000000000000000000000000000000004fdf0000b54e6a002a835a23c10d43b401000000a3c20000a578ffcc6236f306dcf509b0105705561e0df2262934c6fc958a548760b320e4c786a7152a368820c1e
a4aa35be4ab17

По порядку:
5aa5aa555aa5aa55000000000000000000000000000000000000000000000000 - общая часть для всех бродлинк устройств, длиной в 32 байта.
4fdf - первая группа из изменяющихся двух байт. Для RM Pro и им подобных можно ставить рандом. Для розеток первый байт меняется, по какому принципу, пока не понял. Второй байт для розеток и им подобных устойств, принимает несколько фиксированных значений. У меня это: ce, cf, d0, d1, d2, df. В изменениях первого байта на RM Pro для части пакетов нашел некоторую закономерность, но об этом позднее.
0000 - четыре нуля для всех пакетов, фиксировано
b54 - фиксировано для пары устройство - отправитель
e6a - фиксировано для устройства, отличается при отправке и приёме (с еконтрола на MP1 в этой позитиции уходит e6a, а с MP1 обратно приходит еее, например),
00 - в этих позициях у обоих моих устройств стоит два ноля при отправке, при приёме видел 03 как минимум
2a83 - вторая пара изменяющихся байт. Используется как идентификатор запроса - ответа, скорее всего зависит от времени, так как пакеты, стоящие рядом по таймлайну имеют одинаковую пару байт, на рм про можно генерировать рандомно
5a23c1 ещё шесть фиксированных байт, думаю, нужно рассматривать весь блок 002a835a23c
0d43b4 - это первые три байта мак адреса бродлинка в обратном порядке
01000000 - у меня везде одинаково вроде
А далее идёт неведомый пейлоад. Пейлоады, генерируемые еконтролом идентичны. БОльшая часть пакетов, летящих с MP и RM - так же повторяется. Ниже схема обмена данными с MP1 сначала вхолостую, в конце - два раза нажатие последовательности включение/выключение розетки. Я убрал весь мусор и оставил только те пары байт, что изменяются. Слева на всякий случай таймстемп, затем направление. Влево - на MP, вправо - обратно на e-Control.

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

1478499104 < 62cf 7a83 D
1478499105 < 6fcf 7a83 C
1478499105 > c5d0 7a83 E
1478499106 < 68df 4581 A
1478499106 > e4df 4581 B
1478499106 < 1dcf 2982 C
1478499107 < 1dcf 2982 C
1478499108 < 79cf 9381 D
1478499108 > dcd0 9381 E
1478499108 < 86cf 9381 C
1478499109 < 86cf 9381 C
1478499110 < 58df 3482 A
1478499110 > d4df 3482 B
1478499110 < f7ce 0283 C
1478499111 < 19cf 3282 D
1478499111 > 7cd0 3282 E
1478499111 < 26cf 3282 C
1478499112 < 26cf 3282 C
1478499113 < 26cf 3282 C
1478499114 < d9cf f282 D
1478499114 < 2fdf 0a83 A
1478499115 > 3cd1 f282 E
1478499115 > abdf 0a83 B
1478499115 < a4cf b181 C
1478499116 < a4cf b181 C

# Далее выключение розетки
1478499116 < 12d0 9783 F
1478499117 > 04d3 9783 G

1478499117 < 8ccf 9783 86bf C

# Включение
1478499117 < eacd 9082 39c2 H
1478499117 > 39cf 9082 62c2 I

# Возможно, это какое-то подтверждение включения
1478499118 < 99cf b381 26c2 D
1478499118 < a6cf b381 86bf C

# Возможно, ответ на D
1478499118 > 5bcf b381 I

1478499119 < dbdf b881 A
1478499119 > 57e0 b881 B
1478499119 < 85cf 9182 C
1478499120 < 85cf 9182 C

# Выключение
1478499120 < cecf 5383 F
1478499121 > c0d2 5383 G

# Включение
1478499121 < 16ce bd81 H
1478499121 > 65cf bd81 I

1478499121 < 4acf 6382 D
1478499121 < 57cf 6382 C

1478499121 > 0ccf 6382 I

1478499122 < 57cf 6382 C
1478499123 < bedf 9a82 A
1478499124 > 3ae0 9a82 B
1478499124 < 38cf 4680 C
1478499125 < 38cf 4680 C


< A -  a578ffcc6236f306dcf509b0105705561e0df2262934c6fc958a548760b320e4c786a7152a368820c1ea4aa35be4ab17
> B -  f019d29a0f7b371cd54957840fdc1268d075d7bee6ed515e1acdcfa42c30531d1bb31a6b954b0d77002785aed8d3f1c9
> B1 - a3f438f86d3d873ef7874a13d0acdbe03bd341cc59465219697c6ccb4e4e9a843d43308393c87414de742f50016019cf
< C -  aa2af58702019c0ed0c51b3475a0d309
< D -  5499c2b90027ccbd581e4794641597a9
> E -  0aaa6357a481c3ed3e0bc26ca24a66ba
> E1 - 9af5feabd105e7d4017fbdb7bb8c8669

< F -  46cf5165c08f297f46767d6df0ca7410 # SW2 OFF REQ
> G -  725ee45bf3dac64cba50c020f4ed959a # SW2 OFF RSP

< H -  16b5378c07286e4065454671ba21706b # SW2 ON REQ
> I -  27b51a2b2c9e0fb94a7c0421c8f9437f # SW2 ON RSP

B1 и E1 изменяются во времени. Позавчера в пакетах этого типа были пейлоады B и E, вчера B1 и E1, сегодня снова B и E. Посмотрим, что будет завтра.

Заметил интересную особенность. Если посмотреть на пейлоад пакетов, генерируемых со стороны e-Control в сторону MP1 в спокойном состоянии, то получается следующая картина - обратите внимание на пакеты типа D и следующие за ними пакеты типа C (в спокойном состоянии до отправки кодов):

Я убрал дублирующиеся пакеты типа С и все прочие пакеты:
1478499104 < 62cf 7a83 D
1478499105 < 6fcf 7a83 C
1478499108 < 79cf 9381 D
1478499108 < 86cf 9381 C
1478499111 < 19cf 3282 D
1478499111 < 26cf 3282 C

Берём первые байты в первой паре:
62->6f, 79->86, 19->26 - разница между этими парами чисел - ровно D, т.е. 13. Пока не знаю, что это значит.

После перехода в приложении на вкладку с MP1, прилетает пара-тройка жирных пейлоадов:
5aa5aa555aa5aa5500000000000000000000000000000000000000000000000054470000b54eee03a2805a23c10d43b40100000053c500001ae0d77d1f3572cf6897197c1f303e64df77086f19541a583464f66368bed6be0c3182b0b495d40d97f
7cd71a1df9a804d9f0931a143c0c86bdab05be0ac99d536ebcf538dbbf2a717a240ddccc7702e32b4dfbb7c57d18cab06865ea257a47c569080119ad6eaaaf322fc0bd0e63031fd46f0f3678952d6d6807fe541d6b468d6c47c573d9d3b4745ffedaa67
27d2b03e0c0b5ea248b43f98cfd89289ec105844030c272c50a0a8cb467e4ddded3d033ce37f45690eb4c5cca161aef353fca12c06c9de0b0d070820350525ae5d576921bae2b6858bca9f7a664a4ad8ad87de419e020855a8601514f365ae9d0cd858d
75ddc21845416f52161c97b5536a506a5379a56603f6128271183a84a9840bb003c00cd13c17c62ff775985bcac56c03531605b1ab6fe6727b4f0271c1759a5def7c95ddf260ef8ffad80634d8eb6b8efd9267964de19b93ca4e506133c37504e1f1b68
eefc9f41f955597450549c8833afc45570d13607431cc5ebc1162cf62550589546a40092fa4610e086967c2d03a94e86320c53b92c525d3ac330e18a58925b98e023a5d95f7edb9d88462d7ac63454c257e8ea615b8e682f5d84884198d03be5a203044
9d47d5d35163b5e464b24556ceac8e9c014333b31e218d7949b75b29d315e37fcbbd14eb7fb864cca78d2944acfb7c1c058be2074ddd3eb42a172978f91ce580f2e08555e75e25bca279553b66e310b7165d300b9696ecafe8880e7254fd42148dce1e9
c2b5bd6d878e5677937993dfcfe0678d20e4adbcc40163e4cc382449b021836ed0a5154fb5744fe4c7a53edadf4e467f3523e2582e882643a570640dac5e39ac88920774f5e3f21eb0c3f27c7d27ef95e1b75e003f2b55c75c80d7a9f4320239ad2b393
79e0867813063f4b181bff41a366aefff24f5c6579ec783cc801be0460877abcb1ab1e135fbeba55eb80fe642681ed5127c40357a0514c4638a57855c842e0c57dee52890fb1878a7f989c8cd2b34ce1e4cd31078c4b163ea4275b8a71514d0572256f7
346d94f22b256a66ef01abbf495f9d6257aa107a2e8e42ee07893cf1a1934f744ad8a8c46703eaade16561185f27

Думается, внутри может быть и состояние розеток. Так как никаких других пакетов в сторону MP1 кроме описанных выше нет, думаю, железка реагирует на первое поступление одного из пакетов типа A,C или D после долгой паузы.

Так же в коде https://github.com/mjg59/python-broadli ... _init__.py (видимо, недописанный модуль работы с бродлинковскими датчиками), тоже упоминается AES шифрование тела пакета. Но видимо, ключ постоянен. Пытаюсь разобраться, что считается ключом, но пока не смог вычленить из своих пейлоадов нужный кусок, чтобы получить что-то осмысленное. Может кто-нибудь поможет?

Ах да, ещё постоянно с бродлинка летят в сторону телефона даже с выключенным приложением еконтрола пакеты, оканчивающиеся на 0000000200. В их пейлоаде есть полностью все байты мак адреса бродлинка, развёрнутые в обратном порядке и айпишник. Но смысла в них особого не вижу, разве что пассивный мониторинг живости устройства.

[corpse]

В общем, заменил крафтинг пакетов через скапи на обычный сокет - MP1 заработал. Это очень хорошо.
Хорошая новость для тех, у кого есть розетки. Из предыдущей схемы пакет типа A - это запрос состояния. Пакет типа B - это ответ. Внутри этого ответа зашифровано состояние моих розеток, по крайней мере для MP1. Т.е. если включены все розетки, я получаю пейлоад B1, если выключить первую - B2, вторую - B3 и так все возможные комбинации. Без учёта кнопки питания, у нас получится 2^4 = 16 вариантов. То есть, если снять все варианты ответа на запрос A во всех состояниях, можно опрашивать устройство без всяких проблем.
И ещё одна хорошая новость, по крайей мере для MP1 не нужно отправлять никакого wakeup пакета. Всё работает очень просто. Один пакет туда, один обратно.

Теперь нужно переписать логику сканирования и сохранения пакетов для mp*/sp*.

Поделитесь пожалуйста pcap дампом те, у кого есть розетки sp*. В дампе хочется следующее:
1. открыта вкладка е-контрол для управления розеткой, розетка включена - примерно 15-20 скеунд
2. нажатие кнопки в приложении (розетка выключена), после этого примерно те же 15-20 секунд
3. повторное нажатие кнопки (розетка включена), снова 15-20 секунд

Дамп можно снять на рутованных телефонах/планшетах.
Ставим из маркета termux,
Делаем apt-get update && apt-get install tcpdump
Дожидаемся установки пакетов.
Затем делаем
pwd
su -
tcpdump udp and host тутайпишникрозетки -w /sdcard/sp1.pcap

Для того, чтобы прервать запись пакетов, нажимаем на телефоне кнопку громкости вверх и q на клавиатуре - появляется дополнительная всплывающая клавиатура. На ней нажимаем ctrl и английскую c.
Подбираем файлик, выкладываем сюда или шлём мне.

Готов потом поделиться форматом и алгоритмом сохранения и загрузки кодов с товарищами, которые хотят сделать плагин для php.

[sergeich]

Http Bridge v2.4 не работает с RM2 Pro последней версии при обучении и сохранении кодов. Ни через веб-интерфейс, ни через команды. В режим обучения входит и все. Я так понимаю, что изменился алгоритм обучения, вначале RM2 сканирует рабочую частоту, а вторым этапом сканирует команду. Бридж же просто переводит устройство в режим обучения и все. Получилось только путем обучения в E-control обучать команды и после каждого обучения сохранять последнюю команду бриджем через action=save

[anton_z]

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

[C_3AXAPOB]

удалил модуль но после него в иксрее периодически выдает такое сообщение:
dev_httpbrige.processSubscription error (module class not found)
Что делать?

[nick7zmail]

удалил модуль но после него в иксрее периодически выдает такое сообщение:
dev_httpbrige.processSubscription error (module class not found)
Что делать?

Это подписка на событие HOURLY...я хз как её отменять, в описании функции ничего не было)...вот тут задал вопрос, Сергей ответит, посмотрим.

[olehs]

вроде как unsubscribeFromEvent в uninstall, нет?

[C_3AXAPOB]

вроде как unsubscribeFromEvent в uninstall, нет?

А где это?


Отправлено с моего iPhone используя Tapatalk

[olehs]

вроде как unsubscribeFromEvent в uninstall, нет?

А где это?

Это нужно чтобы nick7zmail в модуль добавил.

А Вы попробуйте в консоли выполнить

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

unsubscribeFromEvent('dev_httpbrige', 'HOURLY')