Comments 45
Хм-м-м, странно, кусок статьи до ката, полученный по RSS, не совпадает с куском полной статьи до того же места, и на прошлой неделе кто-то в комментах о том же писал… Это так совпало, что два автора дополнили статьи после публикации, или это новая фича: показывать до ката не непрерывную часть статьи?
Мне же нужен конвектор на пару-тройку недель в году обогревать пом. в ~13 м2. При разнице цены в 8 000-10 000 (плюс монтаж на фасаде ~3 000), и дельте экономии 1-1.5 кВт окупаемость будет порядка 1500 часов работы — или ~9 недель. Т.е. реально что-то экономить эта штука начнет через ~4 года. А там и ТО. Реальные цифры будут еще хуже потому что систему надо брать нормальную, а это от 20к, а не 12-14, т.е. дельта будет больше. Конвектор, ясно дело молотит не 24\7 на 100% мощности, а на 50-70%. ТО опять таки. Отдельные риски переезда и мобильности.
Бонусом:
— Согласование размещения на фасаде внешнего блока (у меня нет балкона)
— Эстетическая составляющая внутреннего блока. Дезигн квартиры никто не отменял и белая юлда на стенке не всем нравится.
Заголовок aa 0c
Байты неизменны из пакета в пакет, возможно, это внутренний ID устройства.
1й байт — это одна из распространенных сигнатур начала пакета (10101010), 2й байт — это длинна блока данных.
А зачем скрывать название девайса? Информация из статьи могла бы быть полезна для других людей, если бы они знали к чему она относится.
1й байт — это одна из распространенных сигнатур начала пакета (10101010), 2й байт — это длинна блока данных.
Оу, про длину блока даже не подумал, спасибо. Гляну на остальные пакеты — похоже на правду.
А зачем скрывать название девайса?
Потому что непонятно чем грозит реверс-инжиниринг такой штуки. Все же данное изделие довольно дыряво с точки зрения безопасности. Да и кто хочет, найдет и поймет о чем речь.
У меня кондиционер без wi-fi, и когда нужно было дистанционно управлять, то вопрос решил через мост WI-FI-IR на esp8266, а дальше или mqtt или http.
Чтобы понять что менять — надо понять как оно работает. В случае с ESP32\ESP8266 сдается мне, быстрее написать самому с нуля, чем разбираться в чужом коде с немецкими комментариями.
// mill kommandoer
char settPower[] = {0x00, 0x10, 0x06, 0x00, 0x47, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; // Powertoggle er pos 5
char settTemp[] = {0x00, 0x10, 0x08, 0x00, 0x43, 0x04, 0x0A, 0x01, 0x12, 0x02}; //, 0x20, 0x03, 0x0A}; // temperatursetting er pos 8Видимо второе.
Команды конвектора:
Для примера только для on\off:
aa 0c 0a 01 1a 01 06 00 00 00 00 05 00 01 e8 - включить
aa 0c 0a 00 1a 01 06 00 00 00 00 05 00 01 e7 - отключитьВ них нужно прописать по аналогии ваши данные UART вместо Millheat.
В начальном посте, вместо того чтобы использовать дефолтный wi-fi адаптер, его отключают и заменяют на ESP01 (чип ESP8266).
В дальнейшем появляется JDolven, который заменяет HF-LPT120A в каком то другом устройстве, на Wemos D1 mini (чип ESP8266)
I was succesfull using parts of the code and a wemos D1 mini to replace the HF-LPT120A.
Ну и в репе он об этом же пишет:
Replacing HF_LPT120A in a millheat heater using a Wemos D1 mini and ESPhome
Соответственно:
1. эти куски кода подходит только для Wemos D1 mini\ESP01.
2. принимают и парсят протокол обмена с Mill Glass. У них там как минимум стартовый байт-код есть и стоповый:
Serial.write((byte)0x5A); // Startbyte
...
Serial.write((byte)0x5B); // StoppbyteВ моем конвекторе стопового байт-кода нет.
Краткое содержание: берем пароль, считаем от него SHA384 (почему 384?), разбиваем на два байтовых массива [32-48] и [0-32].
Опечатка. Берем ключ enc_key.
Потратил некоторое время, чтобы понять это и реализовать алгоритм на PHP
Опечатка. Берем ключ enc_key.
Это краткое описание функции в отрыве от приложения.
В любом случае, парой строк ниже:
Внимание вопрос — что же у нас может выступать в роли пароля? Может быть, тот самый enc_key из JSONa передающийся открытым http?
То же являюсь владельцем умного конвектора и задавался вопросом как его прокинуть в Home Assistant. Так как никогда не занимался реверс-инженирингом, дальше просмотра приложения в JD-GUI и выяснения REST API запросов в Wireshark не продвинулся.
Благодаря статье смог продвинуться дальше в понимании общения с сервером/конвектором и начать писать клиент на PHP
Я вот хочу для HA написать сразу нативный плагин (там же вроде питон), но пока нет на это времени =(
Да, там питон, но мне PHP ближе, поэтому начать проще на нем.
наработки на php. Пока работает авторизация и чтение информации через консольные команды.
Удалось выключить устройство и больше «примитивные» команды на изменение состояния не сработали ))
github.com/Ailme/home-assistant
Здесь реализовал шифрование/расшифровку на python. Научиться писать компоненты для HA — та еще морока
— можно в потоке расшифровывать сообщения через копи/паст в файл
— в цикле читать сокет и отправлять json-сообщения, помещенные в файл на сервер
К сожалению изменение состояния так и удалось заставить работать. Отправляю точно такое же сообщение, как и приложение. Видимо чего-то еще не хватает
Самый примитивный сценарий, который сейчас возможно реализовать через костыль: запускать переодически скрипт на чтение состояния и средствами HA парсить полученный в ответ json для отображения состояния устройства
создал группу в телеге для желающих принять участие по этой теме
t.me/joinchat/psTUBFY5E4swZTAy
-> {«lang»:«ru»,«command»:«setDeviceParams»,«data»:{«device»:[{«params»:{«temp_comfort»:«12»},«uid»:«188577»}]}}
< — {«message_id»:"",«command»:«setDeviceParams»,«result»:true,«message»:""}
< — {«command»:«changedDeviceParams»,«data»:{«188577»:{...«temp_comfort»:12,...}}}
-> {«lang»:«ru»,«command»:«setDeviceParams»,«data»:{«device»:[{«params»:{«temp_comfort»:«20»},«uid»:«188577»}]}}
< — {«message_id»:"",«command»:«setDeviceParams»,«result»:true,«message»:""}
< — {«command»:«changedDeviceParams»,«data»:{«188577»:{...«temp_comfort»:20,...}}}
пробная версия climate компонента для управления конвектором
предстоит еще много работы, чтобы довести до ума, так как это мой первый опыт создания компонентов для HA
Здравствуйте, есть новости про ESP ?
К сожалению нет.
Я уперся в отсутствие осциллографа, конвертера из +-5 В в 3.3 В. Т.е. проблема в том что непонятен уровень сигналов - питание поступающее с конвектора +5 В, а вот уровни UART под вопросом. Спалить мозги (или ESP) чет не очень хочется.
Подцепить ESP на эту же плату, если она без дела.
Не понял смысла зачем цеплять ESP к HF-LPT220?
Изначально идея была заменить HF-LPT220 (ESP всяко дешевле). Т.е. надо понять уровни Tx\Rx в "USB" разъеме.
Да не к HF-LPT220 а на плату где стоит китайский модуль, это про проблему где взять 3 вольта. Естественно HF-LPT220 нужно снять или отцепить хотя бы от 2х контактов TX RX.
А что за уровни TX RX в usb, там просто uart или про что вы говорите?
Попробовал перехватить запросы между конвектором и сервером, у меня получились другие сообщения.
Сообщения от сервера:
aa0107b2
aa0108b3
aa019742
aa03081004c9
Сообщения от устройства:
aa118700000000000000000000000000141539a4
aa0e8800211604071500000000021b01b5
aa0e8800211604071600000000021b01b6
aa08d7202a0b08010001e8
aa08d71f2b0b08010001e8
aa08d7012a0b08010001c9
aa08d7012b0b08010001ca
aa08d7012c0b08010001cb
aa08d731280c08010001f8
нигде намека на aa0c
Как писали выше в комментариях. На примере aa08d7012a0b08010001c9 :
aa - это последовательность 1010 1010 - используется в проводных интерфейсах для "начала" передачи (однозначная последовательность)
08 - длинна сообщения (8 байт)
d7.01.2a.0b.08.01.00.01 - сообщение, 8 байт
c9 - контрольная сумма (в подсчете длинны сообщения не участвует)
d7.01.2a.0b.08.01.00.01 - сообщение, конечно интересное. Возможно они обновили прошивку, или у вас другое устройство (новая ревизия?)
насчет ревизии не знаю. смог только выяснить 2 команды
aa 0b 0a 21 16 04 07 01 01 05 00 02 1b 25 - вкл
aa 0b 0a 20 16 04 07 01 01 05 00 02 1b 24 - выкл
ответ на выключение
aa 0e 88 00 20 16 04 07 10 01 01 05 00 02 1b 01 b6
в случае включения
aa 0e 09 00 21 16 04 07 10 01 01 05 00 02 1b 01 38 (снова меняются 20 и 21, и получается по информации из таблицы, что это сам конвектор инициировал ответ, хотя 88 команду так и не увидел)
и часто от сервера приходят команды
aa 01 07 b2
aa 01 08 b3
aa 01 97 04 42 будто бы после отправки команды на устройство или подтверждения, так и не понял
попробовал через nc отправить в порт сообщения
aa 01 08 b3
aa 0b 0a 21 16 04 07 01 01 05 00 02 1b 25
aa 01 97 04 42
устройство включилось. выключить аналогичным образом не получается
Насколько я помню, достаточно просто отправить команду на вкл.\откл, железка не требует подтверждения\разрешения\каких-то протоколов. Т.е. достаточно просто отправлять aa 0b 0a 21 16 04 07 01 01 05 00 02 1b 25
Меня смущает, что у вас разная длина сообщений. Обмен с сервером идет через 14-байтовые сообщения, а вы отправляете через nc - 11.
что это сам конвектор инициировал ответ, хотя 88 команду так и не увидел
Он сам иногда шлет данные т.к. вы же можете кнопками включить тот или иной режим. Им было лень писать событийный обработчик и тупо зафаршмачили обновление данных на сервере по КД.
еще попробовал на роутере подменить хост, чтобы dongle.rusklimat вел на малину, но к порту 10001 устройство подключаться не хочет ((
по информации в wireshark, дальше резолва домена запросы не проходят.
должно быть:
7 7.173314 192.168.1.1 192.168.1.43 DNS 125 Standard query response 0x0004 A dongle.rusklimat.ru A 193.23.147.10 OPT
8 7.198374 192.168.1.43 193.23.147.10 TCP 58 1029 → 10001 [SYN] Seq=0 Win=1460 Len=0 MSS=1460
после подмены
9 6.305875 192.168.1.1 192.168.1.43 DNS 95 Standard query response 0x0004 A dongle.rusklimat.ru A 192.168.1.49
10 30.002453 Shanghai_24:b4:ea Broadcast ARP 42 Who has 192.168.1.49? Tell 192.168.1.43
от моих брелков (или устройств) уходит версия BAIGE-1.8-20170810. Проверил, для сервера достаточно отправлять BAIGE-1.8. Если указать версию ниже, то в ответ приходит
AT+UPURL=http://demo14.om-sv.ru/,mfw.bin
разумеется файл скачать не удалось
Так как при общении сервер-устройство, для идентификации уходят только версия прошивки и mac брелка, то с идеей подмены сервера возникают новые сложности: локальный сервер не сможет по mac понять что это за тип устройства без создания локальной базы устройств
И еще появляется вопрос, какие версии прошивок существуют и какие у них форматы сообщений. "Мои" сообщения отличаются от тех, что описаны в статье
выяснил следующее:
конвектор периодически отправляет на сервер свое время в сообщении
aa 08 d7 03 22 0c 09 09 14 03 e3
d7 - информация о том, что отправили время
остальные байты: секунда минута час день месяц год (2 цифры после 2000-го) день_недели
aa 08 a7 15 2a 0c 08 09 15 03 cd - команда от сервера на установку системного времени в устройстве
ответ конвектора о своем состоянии:
aa 0e 09 00 21 16 04 07 10 01 01 05 00 02 1b 01 38
09 - Команда или событие (как в таблице, в том числе 88, 8a)
00 - не выяснил
21 - битовая информация; флаги:
- вкл/выкл дисплей
- яркость 100% или 50%
- не выяснил за что отвечает бит
- режим mute
- открытое окно
- блок
- вкл/выкл
16 - установленная температура
04 - не выяснил
07 - не выяснил
10 - температура в помещении
01 - режим работы: 00 - комфорт, 01 - эко, 02 - анти-фрост
01 - режим мощности: 00 - auto, 01 - manual
05 - текущая мощность
00 - статус таймера. 0 - выкл, 1 - вкл
0b 1b - время таймера в минутах
01 - не выяснил
и аналогично команда от сервера на установку состояния
aa 0b 0a 21 16 04 07 01 01 05 00 02 1b 25
0a - команда на установку значения
21 - битовая информация; флаги состояний
16 - температура
04 - не выяснил
07 - не выяснил
01 - режим работы: комфорт/эко/анти-фрост
01 - режим мощности auto/manual
05 - мощность
00 - статус таймера
02 1b - время таймера в минутах
Кому интересен готовый альтернативный модуль для управления конвекторами Ballu и им подобным - https://habr.com/ru/company/coolrf/blog/589381/
Реверс-инжиниринг протоколов управления конвектором