v1 и v2 - прошивки отличаются, схемы тоже.

Всем привет. Собрал устройство. Прошивка последняя выложенная.
Есть ряд проблем.
1 не отображает тариф Т3 почему-то. В пульте он есть. Судя по сумме тоже есть.
2 вылезают аномальные значения по напряжению. Толи у меня на линии ток, толи так данные получает устройство. Проставки на одной фазе одновременно с повышением на другой.

Добрый день!
1. Ну я просто парсер для Т3 не делал - у меня двухтарифный счётчик. Но там в скетче можно понять, где допилить.
2. Я думаю, это ровно то, о чем писал я, и с чем столкнулся shev377. Я бросил эту затею, и не снимаю действующие параметры. Беру только Т1 и Т2

Добавлено after 1 minute 51 second:

У меня, кстати, тоже пульт v2, и тоже нет вывода действующих значений. Только Т1, Т2 и сумма. А, ну ещё время выводит.

А как попасть в web интерфейс после того, как всё настроил?
Он у меня запрашивает логин/пароль. Что-то я не помню, при настройке такого пункта. В самой прошивке тоже не нашёл где вообще это есть.

_____________
Отвечу сам себе:
Используется библиотека IotWebConf

Для доступа в web имя пользователя "admin" пароль "пароль от wifi "

Открыт интернет-магазин MEAN WELL.Market – весь ассортимент MEAN WELL, выгодные цены

Открыта удобная площадка с выгодными ценами, поставляющая весь ассортимент продукции, производимой компанией MEAN WELL – от завоевавших популярность и известных на рынке изделий до новинок. MEAN WELL.Market предоставляет гарантийную и сервисную поддержку, удобный подбор продукции, оперативную доставку по России. На сайте интернет-магазина посетители смогут найти обзоры, интересные статьи о применении, максимальный объем технических сведений.

Подробнее>>

Надо бы докопаться до истины аномальных значений, но бросил на даче макетку год назад с кривым кодом - а оно шлёт себе значения, как-то работает - ну и нет ничего более постоянного, чем временное
Я склоняюсь к тому, что счётчик периодически ловит какой-нибудь запрос статуса или входит в какой-нибудь режим запроса доп информации и начинает отвечать не на наш запрос

LED-драйверы MOSO - надежные решения для индустриальных приложений

Продукция MOSO предназначена в основном для индустриальных приложений, использует инновационные решения на основе более 200 собственных патентов для силовой электроники и соответствует международным стандартам. LED-драйверы MOSO применяются в системах наружного освещения разных отраслей, включая промышленность, сельское хозяйство, транспорт и железную дорогу. В ряде серий реализована возможность дистанционного контроля и программирования работы по заданному сценарию. Разберем решения MOSO подробнее>>

Подниму тему. А никто протоколом от МИРТЕК не богат?

Есть в щитке счетчик "Каскад-1-MT-W1-A1-230-5-60A-S-OV3" однофазный, многотарифный. Хочу собрать оптопорт с возможность передавать данные удаленно (WiFi, Bluetooth).

К щитку не набегаешься. За 500 рублей купил на авито б/у точно такой же. Начал разбираться. Через оптопорт могу прочитать тарифы, напряжение, силу тока и т.п.

Но. Два счетчика присылают ответ разной длины на одну и туже команду. Тот который купил на один байт больше (например 42), а тот который в щитке на один меньше (например 41).

Вот например ответ на запрос тарифов.



MeterTools - оригинальная программа от производителя - читает оба корректно.

Не поняв, как определять размер хедера, тяжело написать универсальный код.

Спасибо.

Тоже хотел бы присоединиться к вопросу о протоколе.
На основе выложенных тут скетчей (спасибо!) собрал свой вариант, но словил проблемы, что уже описаны:
1. периодически счетчик перестаёт отвечать на запросы до смены тарифа в следующие сутки
поставил опрос раз в 30 минут, наблюдаю
2. иногда прилетают неадекватные значения напряжений и сил тока
после добавления контроля CRC проблема не ушла

А так добавил автообнаружение в homeassistant, отображение значений на странице настроек esp. Разобраться бы с протоколом и можно выкладывать.

Хорошо, протокола нет, но может кто поделится знаниями и мыслями, как быть с CRC? Сейчас объясню.

Есть абсолютно одинаковых два электросчетчика. Один в щитке, второй купил занедорого на авито для экспериментов. Так вот они на одни и теже запросы присылают ответы с разницей на один байт. Ну я это уже приводил https://www.radiokot.ru/forum/viewtopic ... 9#p4358269

Так вот. У того, который присылает на один байт меньше, с CRC все впорядке, пробегавшая здесь функция, немного мной адаптированная на любую длину пакета, прекрасно все проверяет и все сходится.

Спойлер

Код:

static uint8_t checksum(const uint8_t *src_buffer, uint8_t len) {
  // skip 73 55 header (and 55 footer is beyond checksum anyway)
  const uint8_t* table = &src_buffer[2];
  const uint8_t packet_len = len - 4;

  const uint8_t generator = 0xA9;

  uint8_t crc = 0;
  for(const uint8_t* ptr = table; ptr < table + packet_len; ptr++){
    crc ^= *ptr;
    for (uint8_t bit = 8; bit > 0; bit--)
      if (crc & 0x80)
        crc = (crc << 1) ^ generator;
      else
        crc <<= 1;
  }

  return crc;
}

А вот у того, который присылает ответ на один байт больше эта функция не подходит, значение получается другое.

Вопрос - может кто-то знает алгоритм расчета таких ответов? А возможно кто-то и объяснит разницу в длине ответа и научит, как это определять?

Это ответы на один байт больше.

Спойлер

Код:

73550400ffff8d4e0130067311000a048d4e0655
73551f00ffff8d4e3030067311002c0a045bb66ae617077e6cd9020000e6b0ac1b95110302000000040000fb0a2a55
73551f00ffff8d4e3030067311002c0a045bb66be617077e6cd9020000e6b0ac1b96110302000000040000fb0a1055
73551f00ffff8d4e0a3006731100013331373131313235323031303900000000000000000000000000000000001355
73551f00ffff8d4e0a300673110004cac0d1cac0c42d312dccd22d57312d41312d3233302d352d3630412d532dc655
73550700ffff8d4e1c30067311001b031301100117e655
73550500ffff8d4e2d3006731100000000a220e955
73550300ffff8d4e29300673110001a6595155
73550400ffff8d4e2c300673110001b40000fe55

А это на один байт меньше, где все нормально.

Спойлер

Код:

73551f00ffff921430300675002c0a045bb6d2f9c808e00c2b010000e6b0ac1bf1d12509000000040000e10cee55
73551f00ffff92140a30067500013431383131313235303532363600000000000000000000000000000000009655
73551f00ffff92140a3006750004cac0d1cac0c42d312dccd22d57312d41312d3233302d352d3630412d532d6655
73550700ffff92141c3006750028151206150117a955
73550500ffff92142d30067500290000a220c055
73550300ffff9214293006750001185bf955
73550400ffff92142c3006750001b608002c55

А еще, третий байт, который содержит или 0x20, или 0x21 в зависимости от длины запроса. Так вот, у меня еще проскочил такой - 0x24

Спойлер

Код:

735524009214ffff2600000000150117015655 - 19 байт, команда 26, добавочный блок 15011701  ????
73551600ffff9214263006750015011701a28a1b401b401740164013400f400d400c407155 - 37 байт, ответ

Не, я конечно пока сделал без проверки CRC, но это же не правильно.

Добавлено after 3 hours 6 minutes 13 seconds:
Короче, скажите спасибо моему сыну, я не смог найти эту информацию, а он смог.

https://habr.com/ru/company/spd/blog/576790/

Читать про самый последний счетчик - IEK «STAR 104/1». Полного конечно протокола нет, но хотя бы понятно, как построен пакет запроса и ответа.

Удачи.

В общем, если кому интересно, то я сделал удаленное снятие показаний через Bluetooth LE (для квартиры дальности хватает), с последующей передачей информации в Home Assistant.

Готового образца пока нет, но на макетке все работает.

Подробности тут.

В принципе, никто не мешает переписать код для той же esp32. Свое устройство я предполагаю разместить в обычной вилке на 220

Видимо, всё идет от битов третьего байта.

Перехватываю общение с пультом и в третьем байте получаю варианты
20 00100000
7 00000111
31 00110001
11 00010001
A0 10100000

Если старший бит равен 1, то CRC совпадает с указанной в запросе.
Следующий бит всегда 0.
Следующий - при запросе 1, при ответе 0.
Далее 5 бит, как писали выше, значения которых равны длине блока данных.

В общем у меня радостная весть

Почитав эту статью (которую я уже приводил), поступил точно так же, как автор - отправил запрос производителю счетчиков IEK. Вот они неделю думали и прислали мне вордовский документ. Никаких ограничений на распространение они не оговорили.

Ссылку на всякий случай уберу под спойлер. Удачи всем.

Спойлер

https://disk.yandex.ru/i/ry6hBLtraLg1RQ

Братва! А кто нибудь копал в направлении счетчиков NP523.20D-1P1ALNI производства "Матрица"? Для их счетчиков есть гаджет по удаленному снятию информации RUD 512. Обмен данными через розетку. Радиоканала нет.

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

Все это здорово но именно для миртека кто-нибудь победил проблему с аномальными значениями? Я не понял как поправить это. В Ноme Assistant я ограничил пики, но не сильно спасает.

Может замена управляющих символов происходит, а мы этого не учитываем? Ну как вариант ...

Я например взял за основу My_Mirtek_GW_upd2, добавил себе вывод показаний на страничку с настройками.
Добавил переменные для того чтобы постоянно не делать преобразования и их вывожу, а так же для MQTT сделал простую проверку показаний перед отправкой, так как парсинг 5 (суммарные показания) и 7 (действующие значения токов и напряжения) вызываются сначала для серийного порта, а потом для передачи на MQTT, то в парсинге для серийного порта добавил в конец переменную err, если значения превышают пиковые то просто это все не проходит в MQTT.
Пока тестирую, но конечно это не дело.
А кто-то делал парсинг 1,2,3,4,6,8,9 посылок-ответов?
Как насчет даты/времени?

Немного поковырял код:
1. Добавлен парсер даты/времени в 1 запросе
2. На веб страницу и в MQTT выводится примерное последнее время запроса
3. Добавил вывод на веб страницу математического подсчета мощности по фазам
4. Добавил подуровень каталог топика MQTT = адресу счетчика, теперь можно чтобы несколько счетчиков присылались на один и тот же MQTT брокер, чтобы можно было различить какие данные от какого счетчика

ВАЖНО!!!
5. найдены пару багов: вроде указывает на несуществующий светодиод, поправил на 2 GPIO


Частые мигания (первые 30 секунд) - поднята точка доступа для конфигурирования;
Редкие мигания - подключение к Wifi;
Горит и очень редкое мигание (как ни странно сделано на потухание, наверное надо библиотеку ковырять) - соединено с MQTT брокером.

Внутренний светодиод на ESP32 Dev Kit v1 висит там), соответственно GDO2 переместил на D22
было:

стало:

Сначала думал что именно из-за этого получаются аномальные значения, но вроде нет, работает в коде отсечка для постинга в MQTT если напряжения превышают 400В или 60А, можете поправить на свои значения:

Костыль конечно, но вроде так будет правильнее.

Ковыряю дальше.
На столбе 3 счетчика у нас, 2 3-х фазные, 1-однофазный, с однофазного получает только суммарные показания кВт/ч, а с обоих 3-х фазных нормально получает все нужные параметры.

Кстати на китайском CC1101 с али надписи GDO написаны как GOD, а так же MISO не подписано, оно GDO/GOD1

Немного картинок:

Спойлер

Модуль с али, выдрал с него гребенку контактов, все-равно шаг не тот


Вот так на али выводы модуля подписаны


Вот тестовый эмулятор шлюза


Немного вот так приколхозил контакты, чтобы если что и в макетную плату можно было бы вставить ESP32 Dev Kit v1


За пайку не пинать, это тестовый вариант.

Добавлено after 4 hours 34 minutes 4 seconds:
Если вдруг кто-то использует передачу команд для запросов через MQTT, то поправьте следующий код

на

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

Увы, но делал более строгий контроль значений, так вот иногда они умудряются прилетать практически нормальными, но рандомными. Такое редко бывает, но прилетали показания с меньшими значениями по тарифам например, или нагрузка в 50А То есть, нужно всё-таки лезть в суть.

Эх, неужели за 3 года в форум так никто и не заглянул из миртековских программистов - энтузиастов, готовых помочь
Нам главное весь протокол-то не нужен, просто подсказка о том что это за случайные ответы счётчика и как с ними бороться)

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

SysCat, Спасибо за труд, пришло время обновить мой говнокод на что-то более прикольное с вебинтерфейсом

shev377, спасибо за отзыв, может как-то онлайн собрать энтузиастов по этому счетчику и вместе сделать нормальный продукт для любителей, дачников много, не всем удобно в MQTT, вот на днях планирую народный мониторинг прикрутить, так же на столбе в доступе радиоканала есть несколько 3-х фазных счетчиков и несколько однофазных.


Там в парсере же проверяется номер счетчика, соответственно если номер не совпадает, то пакет не разбирается, это как раз и защита от ответа несколько счетчиков одновременно в эфир.

Можно вместе поковырять и сделать удобную вещь.
Думаю что если примерную плату сделать под размер USB свистка то воткнув в телефонную зарядку - любой дачник почти сможет пользоваться им. Надо найти оптимальный по цене вариант, может что-то попроще чем EPS32, может сделать и батарейное питание.
Например моему коллеге это стало интересно - получение показаний удаленно, летом не так критично, так как много и часто на дачу ездят, а вот снимать показания зимой для передачи в энергокомпанию - нужное дело.

Думаю что спрос на платки будет как и на само законченное решение, так что есть над чем подумать.

А так всегда рад критике и помощи, ну и от меня по-возможности помощь.

Могу попробовать от юр лица отправить письмо, если напишите рыбу.
А так же ребенок сейчас пробует переписать под ESP-IDF.

А так же думаю что парсинг надо в конец запросов перенести, что бы не разбирать отдельно для parsing_5 и parsing_5_mqtt, думаю что надо превратить parsing_mqtt просто в send_mqtt, так же сделать send_serial, а парсинг в запросах (RequestPacket_), а в сендерах просто отправка в нужное место значений уже разобранных переменных.

Может стоит временно ТГ канал сделать чтобы делится соображениями и мыслями?

Подозреваю, что лучше не делать коммерческий продукт, могут возникнуть вопросы насчёт прав пользования протоколов счётчиков и правомерности его получения)
Считайте вы сделаете пользователям выбор: купить кривой радиомодем от разработчиков за неадекватный прайс, или гораздо более функциональное, законченное устройство за копейки.
Так что я думаю логический финал проекта - опенсурс проект, со ссылкой на заказ готовых плат на JlcPcb и прошивкой на гитхабе



В идеале - должно быть реализовано несколько протоколов основных счётчиков: Меркуриев, Миртеков, Энергомеры (их сейчас в квартирах поголовно ставят), IEK, и прочих..
Возможно кастом в стиле "укажите строку для запроса и маску ответа".
С выбором куда слать запросы, в UART, в радио с выбором параметров связи и прочих штук.
Ну это прям оверкилл если делать.

Батарейное питание - нафиг, тогда нельзя будет сделать график нагрузки в веб/HomeAssistant, от частых запросов батарейка будет дохнуть слишком быстро.
С другой стороны, можно воткнуть мелкий ионистор или 3 AA развязанные диодом, и при пропаже питания (повесить оптрон на вход) - делать последний запрос в счётчик, определять пропало ли питание или просто выдернули девайс из розетки, слать куда-нибудь уведомление о событии и впадать в глубокий анабиоз.

В идеале - все данные должны отображаться в веб интерфейсе, возможно со статистикой (где ее хранить только вопрос), возможность отправки в телеграмм событий и показаний раз в n часов, ну и mqtt с автодискавери.


Ну по сути, это уже не сильно актуально на самом деле. Практически везде, где устанавливаются подобные счетчики на столбах - автоматически собирают показания и отправляют их в личный кабинет раз в месяц, для этого их такие умные и устанавливали. А где нет - то в ближайшее время заменят на умные. Борьба с неплательщиками, типа. Потому и счётчики в недоступном месте, где-нибудь на столбе.
Так что это скорее баловство, как мне кажется. Лично для себя - хотел иметь текущие показания, нагрузку и напряжение по всем фазам, с обновлением раз в 10 минут


Уфф, вот тут точно нужна помощь сторонних наблюдателей



Я думаю нужно подождать энтузиастов с первых страниц, особенно Vittaly7 и уже делать чат. Вдвоём точно ничего путного не сообразим, я уже года два назад платку бросил в незаконченном виде, "авось и так работает"
Слишком намаялся со сбором протоколов ардуиной (ковырял параллельно еще irda-uart и modbus к другим счётчикам), без нормального логического анализатора, выработав аллергию к задумке) Особенно долго парили мозги как раз Энергомера с UART-IRDA портом, под который нужен особенный ик-порт-модуль, и Миртек)

UPD:
кстати, а может быть дело в том, что в какой-то момент управляющая организация может авторизовываться на счётчике и что-то запрашивать по таймеру, подвешивая порт счётчика? Может быть мы пытаемся сделать запрос от другого пользователя, и счётчик нас как-то блочит на полчасика? Тогда нужно попробовать сначала отправлять какую-то команду деавторизации/отключения от счётчика перед запросом. МетерТулз вроде что-то отсылал в счётчик при закрытии окна. Или может быть счётчик периодически загоняют в какой-нибудь режим настройки, отправляя новые тарифы/время, и "забывают" выйти из этого режима настройки? Кажется звучит как рабочий вариант