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

А получилось среверсить генерацию подписи?
Оно очень похоже на вариацию CRC8 (взял из ардуиновской прошивки - генератор 0xA9, начальное значение 0x7E и в конце xor 0xA1, попытка воспроизвести на сях в приложении), но почему-то сходится далеко не для всех примеров, что есть в теме - такое ощущение, что либо данные как-то еще меняются перед и после передачи, либо разные параметры чексуммы в зависимости от третьего байта (который 0x20 в команде 0x01), кореллирующего с длинной пакета (либо там в одном байте кусок длины/тип пакета и еще что-то).

Еще в ардуиновской прошивке вроде как байт длины пакета тоже идет в чексумму, но учитывая что в uart оно прилетает уже без него - это странно и не правильно, мб поэтому не сходится

Добавлено after 4 hours 16 minutes 57 seconds:
Слегка причесал симулятор lcd, теперь выключенные сегменты светлосерые и добавил реакцию на клики

Да, получилось.
Но ардуинью у меня забрала молодёжь, сделали на ней гирлянды на ёлку
Поэтому портирую всё это на MSP430, у меня их много.
Вот такие

Не знаю как оно будет выглядеть на С, на асме MSP430 выглядит так:

С адреса, в данном случае 3000h, лежит строка начиная с байта следующего после 55h
в принятом или отправляемом сообщении.

Получается, там все-таки классический crc-8 с полиномом 0xA9, просто пакет это не ровно то, что по радио передается
(Еще оказалось меня чуть подвело модное маковское распознавание текста с картинок и часть примеров пакетов были с опечатками, а на скрине с исправленной мощностью crc от пакета с нулями)

Теперь все тесты прошли:

Это хорошо.
Но это мы просчитали из готовых запросов/ответов.
А если мы формируем запрос, где имеется № прибора, команда и её аргументы,
преамбула и маркеры начала и конца пакета так же нам известны.
Необходимо правильно подсчитать недостающие элементы (выделены красным цветом)
73 55 хх 00 7C 64 FE FF 2B 00 00 00 00 10 xx 55

Хотя, что тут считать...
Из тех запросов, что формирует пульт (а о других пока и не говорим) они (запросы) есть двух видов.
С байтом 20h в начале и байтом 21h. Других пока не видел. Следовательно пока так:

Судя по тому же коду чексуммы - в первом байте по маске 0x1F (младшие 5 бит) это длина данных запроса/ответа после заголовка (заголовок длиной 0xb - этот байт и до пароля включительно),
причем от счетчика в примерах в поле пароля тоже вроде приходят одни и те же 4 байта, но пока не ясно что они значат, возможно есть связь с серийником),
5й бит (0x20) это направляение пакета (0x20 - в сторону счетчика, 0 - обратно) либо тип "команда/ответ", остальные биты не ясно, но пока только нули встречались

А имея первый - да, второй байт уже знаем как считать, это сама чексумма

Ничего не понял
О каком пароле речь ?
Вот запрос на открытие канала связи, он идёт первым:
73 55 20 00 7C 64 FE FF 01 00 00 00 00 CE 55
Красным выделен пароль, по умолчанию 0
вот ответ на этот запрос:
73 55 04 00 FE FF 7C 64 01 A8 05 5B 00 09 05 7C 64 A7 55

Запрос на открытие канала:
73 55 20 00 7C 64 FE FF 01 00 00 00 00 CE 55

Ответ:
73 55 04 00 FE FF 7C 64 01 A8 05 5B 00 09 05 7C 64 A7 55

зеленое это фиксированная часть каждого пакета, 11 байт (0xb в шестнадцатиричной), красное - дополнительные данные, которые есть не в каждом пакете и их разное количество, вот их длина и идет в те пять бит длины. В примере ответа - их 4 штуки, бита 0x20 нет, т.к. ответ => первый байт после преамбулы 04.

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

Причем вот эта часть:
73 55 04 00 FE FF 7C 64 01 A8 05 5B 00 09 05 7C 64 A7 55
одинаковая во всех ответах, и, в принципе, в этом есть логика. В запросе там точно пароль, вероятно в ответе это тоже какое-то подобие пароля

A8 05 5B 00 изменилось на A8 01 5B 00 как только изменился день
В других ответах меняется ещё по 2 байта, видимо тикают часы.
Но формат записи я ещё не определил.
7C64h --> 647Ch --> 25724 сетевой адрес прибора, последние 5 цифр серийника.

Поделюсь своими достижениями (пока не очевидными):
1. Сделал трансивер на базе ESP32 и CC1101. Собрал слушалку эфира, и с помощью неё удалось подслушать радиообмен моего пульта с моим счётчиком. Выводы:
1.1. радиообмен идёт действительно на канале 22 (16Hex) - на остальных каналах тишина.
1.2. У меня стартовый пакет выглядит по-другому
1.3. В ответ на запросы пульта от счётчика ловится не один длинный пакет-ответ, а три коротких. такое впечатление, что пакет бьётся на 3 части. Причём это очень стабильно воспроизводится:



2. Собрал ещё один трансивер на втором ESP32 и втором CC1101. С помощью него попытался сэмультировтаь запрос счётчика. И вот тут самое большое разочарование: первый трансивер видит запрос от второго трансивера с эмуляцией запроса - он полностью совпадает с первым запросом пульта. Но при этом ответа от счётчика нет - он не отвечает. Как такое возможно - пока не могу понять...

Ну в общем, удалось сделать самоделку на ESP32+CC1101. Схема подключения:

К PIN16 можно подключить светодиод - будет показывать статус подключения к WiFi.
Устройство умеет отправлять 7 разных пакетов-запросов. В ответ приходит пакет-ответ.
Запррос показаний счётчика - 5. В ответ, помимо самого пакета-ответа, придёт 3 параметра: сумма, Т1 и Т2.
Запрос текущих значений электросети (напряжения по фазам, токи по фазам и т.д.) - 7. В ответ, помимо самого пакета-ответа, придут эти параметры.

Умеет работать по MQTT и через Serial.
При первом включении устройство создаёт AP "Mirtek_GW". К ней можно подключиться по WiFi (пароль 12345678) и зайти браузером по 192.168.4.1. Далее через WEB конфигурятся параметры вашего WiFi, сервера MQTT и номер счётчика.

В режиме Serial:
отправляем цифру-номер запроса от 1 до 7. В ответ приходит пакет-ответ от счетчика. Если это запросы 5 или 7, то помимо этого придут распарсенные значения параметров (см. выше).

В режиме MQTT:
в топик mirtek/action отправить номер запроса 5 или 7 (в MQTT реализовал только их). В ответ в отдельные топики придут соответствующие значения параметров счётчика, а также в отдельный топик mirtek/Request_Status результат запроса: Ok или Error.

Код сильно не оптимален (я не настоящий программист, прошу простить), но вроде как работает. Желающие могут доработать.

Но есть проблема: запрос текущих параметров сети (напряжения, токи и т.д.) на мом счетчике работает сильно криво: ответ приходит сильно битый, CRC не совпадает. Правильное значение можно получить 1 раз из 100. Причём на всех соседских счётчиках аналогичная ситуация. Не знаю, с чем это связано, но очень обидно. Возможно, нужно направлять другой пакет-запрос. Я направляю тот, что был ранее указан в этой ветке форума. Примерно такого вида: 10 73 55 21 0 XX XX 9 FF 2B 0 0 0 0 0 5C 55 (XX - это номер счётчика). Если бы кто-нибудь смог помочь, и прислать запрос, который отправляет пульт для отображения текущий параметров сети, был бы очень благодарен.

Код написан в среде Arduino, использованные дополнительные библиотеки:
https://github.com/LSatan/SmartRC-CC1101-Driver-Lib
https://github.com/prampec/IotWebConf
https://github.com/RobTillaart/CRC
https://github.com/GyverLibs/TimerMs

Огромное спасибо Сергею Безрукову (Ser60), Dismas, _borisovich_, Vasfed! Без вашей информации я бы не справился.

Исходник .ino во вложении.

Добавлено after 4 minutes 17 seconds:
Прошу прощения, в предыдущем посте не удалось приложить файлы. Прикладываю.

Супер! Обязательно сделаю себе! А почему не esp8266 используется?
Вопрос к знатокам. У меня стоит счётчик миртек 3 фазы + пульт 830. Я не могу получить никакие данные, кроме потреблённой энергии по тарифам. Ни напряжение ни нагрузка. Как быть? Что-то можно сделать или не поддерживает счётчик который установили?

Добрый день.

Я вообще стараюсь теперь не использовать ESP8266, потому что ESP32 мощнее (как по ЦПУ, так и по памяти), а стоят они сейчас примерно одинаково.

Ну я же писал: у меня это реализовано, правда пока только через Serial в тестовом режиме, так как работает сильно со сбоями (см пояснения в моём посте). Попробуйте через Serial послать команду 7 (просто введите цифру 7 и ввод), и посмотрите, что прилетит: адекватные значения, или нет. По поводу пульта - у меня аналогичная ситуация - ничего, кроме потреблённой энергии и текущего времени/даты он у меня не показывает.

Я ещё не собрал. Пока нет esp32.

Я про пульт писал. Почему в нем нет, не понимаю.

В документации на пульт написано, что перечень выводимых параметров зависит как от модели счётчика, так и от запрограммированного режима (перечень параметров, которые можно выводить на пульт, также программируются в счётчике).

Спасибо большое за ответ. А как-то можно это все обновить и изменить?

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

Контр. сумма в строке запроса верная ? (в данном случае указана 5С)

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

Заметил у себя ещё одно необычное поведение счётчика: я реализовал опрос 1 раз в 5 минут, чтобы можно было отслеживать потребление по периодам времени. Так вот: иногда счётчик перестаёт вообще отвечать на запросы. Ответы возобновляются при переходе счётчика на следующий тариф (например, с Т2 на Т1, или наоборот). Я думаю, это конкретная проблема моего экземпляра счётчика.

Это не проблема счётчика, а его реакция на неправильные (с его точки зрения) запросы.
Такая себе "капча" от спамеров
Запросов обычно несколько в одном обращении.
Важна (видимо) и их последовательность.
Пакет запросов-ответов "Информация-->Мгновенные значения"
И собственно сами данные в формате анализатора LA1010