Всем привет. Собрал устройство. Прошивка последняя выложенная. Есть ряд проблем. 1 не отображает тариф Т3 почему-то. В пульте он есть. Судя по сумме тоже есть. 2 вылезают аномальные значения по напряжению. Толи у меня на линии ток, толи так данные получает устройство. Проставки на одной фазе одновременно с повышением на другой.
Всем привет. Собрал устройство. Прошивка последняя выложенная. Есть ряд проблем. 1 не отображает тариф Т3 почему-то. В пульте он есть. Судя по сумме тоже есть. 2 вылезают аномальные значения по напряжению. Толи у меня на линии ток, толи так данные получает устройство. Проставки на одной фазе одновременно с повышением на другой.
Добрый день! 1. Ну я просто парсер для Т3 не делал - у меня двухтарифный счётчик. Но там в скетче можно понять, где допилить. 2. Я думаю, это ровно то, о чем писал я, и с чем столкнулся shev377. Я бросил эту затею, и не снимаю действующие параметры. Беру только Т1 и Т2
А как попасть в web интерфейс после того, как всё настроил? Он у меня запрашивает логин/пароль. Что-то я не помню, при настройке такого пункта. В самой прошивке тоже не нашёл где вообще это есть.
_____________ Отвечу сам себе: Используется библиотека IotWebConf
Для доступа в web имя пользователя "admin" пароль "пароль от wifi "
Надо бы докопаться до истины аномальных значений, но бросил на даче макетку год назад с кривым кодом - а оно шлёт себе значения, как-то работает - ну и нет ничего более постоянного, чем временное Я склоняюсь к тому, что счётчик периодически ловит какой-нибудь запрос статуса или входит в какой-нибудь режим запроса доп информации и начинает отвечать не на наш запрос
Подниму тему. А никто протоколом от МИРТЕК не богат?
Есть в щитке счетчик "Каскад-1-MT-W1-A1-230-5-60A-S-OV3" однофазный, многотарифный. Хочу собрать оптопорт с возможность передавать данные удаленно (WiFi, Bluetooth).
К щитку не набегаешься. За 500 рублей купил на авито б/у точно такой же. Начал разбираться. Через оптопорт могу прочитать тарифы, напряжение, силу тока и т.п.
Но. Два счетчика присылают ответ разной длины на одну и туже команду. Тот который купил на один байт больше (например 42), а тот который в щитке на один меньше (например 41).
Вот например ответ на запрос тарифов.
Код:
735520008d4effff0500000000ae55 - запрос 15 73551a00ffffxxxx0530067500 |3af51400|a2203001|0000|44050600|91240600|65cb0800|00000000|bc55 - ответ 41 73551a00ffff8d4e053006731100|bad62300|a2203001|0000|ea260b00|598d0a00|77220e00|00000000|6d55 - ответ 42 head | sum | ? | ? | tariff1| tariff2| tariff3| tariff4|
MeterTools - оригинальная программа от производителя - читает оба корректно.
Не поняв, как определять размер хедера, тяжело написать универсальный код.
Тоже хотел бы присоединиться к вопросу о протоколе. На основе выложенных тут скетчей (спасибо!) собрал свой вариант, но словил проблемы, что уже описаны: 1. периодически счетчик перестаёт отвечать на запросы до смены тарифа в следующие сутки поставил опрос раз в 30 минут, наблюдаю 2. иногда прилетают неадекватные значения напряжений и сил тока после добавления контроля CRC проблема не ушла
А так добавил автообнаружение в homeassistant, отображение значений на странице настроек esp. Разобраться бы с протоколом и можно выкладывать.
Хорошо, протокола нет, но может кто поделится знаниями и мыслями, как быть с CRC? Сейчас объясню.
Есть абсолютно одинаковых два электросчетчика. Один в щитке, второй купил занедорого на авито для экспериментов. Так вот они на одни и теже запросы присылают ответы с разницей на один байт. Ну я это уже приводил https://www.radiokot.ru/forum/viewtopic ... 9#p4358269
Так вот. У того, который присылает на один байт меньше, с CRC все впорядке, пробегавшая здесь функция, немного мной адаптированная на любую длину пакета, прекрасно все проверяет и все сходится.
А еще, третий байт, который содержит или 0x20, или 0x21 в зависимости от длины запроса. Так вот, у меня еще проскочил такой - 0x24 Спойлер
Код:
735524009214ffff2600000000150117015655 - 19 байт, команда 26, добавочный блок 15011701 ???? 73551600ffff9214263006750015011701a28a1b401b401740164013400f400d400c407155 - 37 байт, ответ
Не, я конечно пока сделал без проверки CRC, но это же не правильно.
Добавлено after 3 hours 6 minutes 13 seconds: Короче, скажите спасибо моему сыну, я не смог найти эту информацию, а он смог.
В общем, если кому интересно, то я сделал удаленное снятие показаний через Bluetooth LE (для квартиры дальности хватает), с последующей передачей информации в Home Assistant.
Готового образца пока нет, но на макетке все работает.
Хорошо, протокола нет, но может кто поделится знаниями и мыслями, как быть с CRC? Сейчас объясню. А еще, третий байт, который содержит или 0x20, или 0x21 в зависимости от длины запроса. Так вот, у меня еще проскочил такой - 0x24 Спойлер
Код:
735524009214ffff2600000000150117015655 - 19 байт, команда 26, добавочный блок 15011701 ???? 73551600ffff9214263006750015011701a28a1b401b401740164013400f400d400c407155 - 37 байт, ответ
Видимо, всё идет от битов третьего байта.
Перехватываю общение с пультом и в третьем байте получаю варианты 20 00100000 7 00000111 31 00110001 11 00010001 A0 10100000
Если старший бит равен 1, то CRC совпадает с указанной в запросе. Следующий бит всегда 0. Следующий - при запросе 1, при ответе 0. Далее 5 бит, как писали выше, значения которых равны длине блока данных.
Почитав эту статью (которую я уже приводил), поступил точно так же, как автор - отправил запрос производителю счетчиков IEK. Вот они неделю думали и прислали мне вордовский документ. Никаких ограничений на распространение они не оговорили.
Ссылку на всякий случай уберу под спойлер. Удачи всем.
Братва! А кто нибудь копал в направлении счетчиков NP523.20D-1P1ALNI производства "Матрица"? Для их счетчиков есть гаджет по удаленному снятию информации RUD 512. Обмен данными через розетку. Радиоканала нет.
Все это здорово но именно для миртека кто-нибудь победил проблему с аномальными значениями? Я не понял как поправить это. В Ноme Assistant я ограничил пики, но не сильно спасает.
Все это здорово но именно для миртека кто-нибудь победил проблему с аномальными значениями? Я не понял как поправить это. В Ноme Assistant я ограничил пики, но не сильно спасает.
Может замена управляющих символов происходит, а мы этого не учитываем? Ну как вариант ...
Я например взял за основу My_Mirtek_GW_upd2, добавил себе вывод показаний на страничку с настройками. Добавил переменные для того чтобы постоянно не делать преобразования и их вывожу, а так же для MQTT сделал простую проверку показаний перед отправкой, так как парсинг 5 (суммарные показания) и 7 (действующие значения токов и напряжения) вызываются сначала для серийного порта, а потом для передачи на MQTT, то в парсинге для серийного порта добавил в конец переменную err, если значения превышают пиковые то просто это все не проходит в MQTT. Пока тестирую, но конечно это не дело. А кто-то делал парсинг 1,2,3,4,6,8,9 посылок-ответов? Как насчет даты/времени?
Вложения:
Комментарий к файлу: за основу взят My_Mirtek_GW_upd2, сделал небольшие модификации My_Mirtek_GW.zip [6.92 KiB]
Скачиваний: 123
Немного поковырял код: 1. Добавлен парсер даты/времени в 1 запросе 2. На веб страницу и в MQTT выводится примерное последнее время запроса 3. Добавил вывод на веб страницу математического подсчета мощности по фазам 4. Добавил подуровень каталог топика MQTT = адресу счетчика, теперь можно чтобы несколько счетчиков присылались на один и тот же MQTT брокер, чтобы можно было различить какие данные от какого счетчика
ВАЖНО!!! 5. найдены пару багов:
Код:
#define STATUS_PIN 16
вроде указывает на несуществующий светодиод, поправил на 2 GPIO
Код:
#define STATUS_PIN 2
Частые мигания (первые 30 секунд) - поднята точка доступа для конфигурирования; Редкие мигания - подключение к Wifi; Горит и очень редкое мигание (как ни странно сделано на потухание, наверное надо библиотеку ковырять) - соединено с MQTT брокером.
Внутренний светодиод на ESP32 Dev Kit v1 висит там), соответственно GDO2 переместил на D22 было:
Код:
int gdo0 = 2
стало:
Код:
int gdo0 = 22
Сначала думал что именно из-за этого получаются аномальные значения, но вроде нет, работает в коде отсечка для постинга в MQTT если напряжения превышают 400В или 60А, можете поправить на свои значения:
Код:
v1>400 or v2>400 or v3>400 or i1>60 or i2>60 or i3>60
Костыль конечно, но вроде так будет правильнее.
Ковыряю дальше. На столбе 3 счетчика у нас, 2 3-х фазные, 1-однофазный, с однофазного получает только суммарные показания кВт/ч, а с обоих 3-х фазных нормально получает все нужные параметры.
Кстати на китайском CC1101 с али надписи GDO написаны как GOD, а так же MISO не подписано, оно GDO/GOD1
Немного картинок: СпойлерМодуль с али, выдрал с него гребенку контактов, все-равно шаг не тот
Вот так на али выводы модуля подписаны
Вот тестовый эмулятор шлюза
Немного вот так приколхозил контакты, чтобы если что и в макетную плату можно было бы вставить ESP32 Dev Kit v1
За пайку не пинать, это тестовый вариант.
Добавлено after 4 hours 34 minutes 4 seconds: Если вдруг кто-то использует передачу команд для запросов через MQTT, то поправьте следующий код
v1>400 or v2>400 or v3>400 or i1>60 or i2>60 or i3>60 Костыль конечно, но вроде так будет правильнее.
Увы, но делал более строгий контроль значений, так вот иногда они умудряются прилетать практически нормальными, но рандомными. Такое редко бывает, но прилетали показания с меньшими значениями по тарифам например, или нагрузка в 50А То есть, нужно всё-таки лезть в суть.
Эх, неужели за 3 года в форум так никто и не заглянул из миртековских программистов - энтузиастов, готовых помочь Нам главное весь протокол-то не нужен, просто подсказка о том что это за случайные ответы счётчика и как с ними бороться)
Может быть у кого-то появилась возможность отправить запрос от обслуживающей организации, на получение протокола, для интеграции во "внутреннюю архитектуру мониторинга организации" или что-то вроде того?
SysCat, Спасибо за труд, пришло время обновить мой говнокод на что-то более прикольное с вебинтерфейсом
shev377, спасибо за отзыв, может как-то онлайн собрать энтузиастов по этому счетчику и вместе сделать нормальный продукт для любителей, дачников много, не всем удобно в MQTT, вот на днях планирую народный мониторинг прикрутить, так же на столбе в доступе радиоканала есть несколько 3-х фазных счетчиков и несколько однофазных.
Цитата:
Возможно это сотня счётчиков вокруг отвечает одновременно и всё бьётся, ибо вроде я не видел в функции парсинга проверки контрольной суммы (давно ковырял, не помню)
Там в парсере же проверяется номер счетчика, соответственно если номер не совпадает, то пакет не разбирается, это как раз и защита от ответа несколько счетчиков одновременно в эфир.
Можно вместе поковырять и сделать удобную вещь. Думаю что если примерную плату сделать под размер USB свистка то воткнув в телефонную зарядку - любой дачник почти сможет пользоваться им. Надо найти оптимальный по цене вариант, может что-то попроще чем EPS32, может сделать и батарейное питание. Например моему коллеге это стало интересно - получение показаний удаленно, летом не так критично, так как много и часто на дачу ездят, а вот снимать показания зимой для передачи в энергокомпанию - нужное дело.
Думаю что спрос на платки будет как и на само законченное решение, так что есть над чем подумать.
А так всегда рад критике и помощи, ну и от меня по-возможности помощь.
Могу попробовать от юр лица отправить письмо, если напишите рыбу. А так же ребенок сейчас пробует переписать под ESP-IDF.
А так же думаю что парсинг надо в конец запросов перенести, что бы не разбирать отдельно для parsing_5 и parsing_5_mqtt, думаю что надо превратить parsing_mqtt просто в send_mqtt, так же сделать send_serial, а парсинг в запросах (RequestPacket_), а в сендерах просто отправка в нужное место значений уже разобранных переменных.
Может стоит временно ТГ канал сделать чтобы делится соображениями и мыслями?
Думаю что спрос на платки будет как и на само законченное решение, так что есть над чем подумать.
Подозреваю, что лучше не делать коммерческий продукт, могут возникнуть вопросы насчёт прав пользования протоколов счётчиков и правомерности его получения) Считайте вы сделаете пользователям выбор: купить кривой радиомодем от разработчиков за неадекватный прайс, или гораздо более функциональное, законченное устройство за копейки. Так что я думаю логический финал проекта - опенсурс проект, со ссылкой на заказ готовых плат на JlcPcb и прошивкой на гитхабе
Можно вместе поковырять и сделать удобную вещь. Надо найти оптимальный по цене вариант, может что-то попроще чем EPS32, может сделать и батарейное питание.
В идеале - должно быть реализовано несколько протоколов основных счётчиков: Меркуриев, Миртеков, Энергомеры (их сейчас в квартирах поголовно ставят), IEK, и прочих.. Возможно кастом в стиле "укажите строку для запроса и маску ответа". С выбором куда слать запросы, в UART, в радио с выбором параметров связи и прочих штук. Ну это прям оверкилл если делать.
Батарейное питание - нафиг, тогда нельзя будет сделать график нагрузки в веб/HomeAssistant, от частых запросов батарейка будет дохнуть слишком быстро. С другой стороны, можно воткнуть мелкий ионистор или 3 AA развязанные диодом, и при пропаже питания (повесить оптрон на вход) - делать последний запрос в счётчик, определять пропало ли питание или просто выдернули девайс из розетки, слать куда-нибудь уведомление о событии и впадать в глубокий анабиоз.
В идеале - все данные должны отображаться в веб интерфейсе, возможно со статистикой (где ее хранить только вопрос), возможность отправки в телеграмм событий и показаний раз в n часов, ну и mqtt с автодискавери.
а вот снимать показания зимой для передачи в энергокомпанию - нужное дело.
Ну по сути, это уже не сильно актуально на самом деле. Практически везде, где устанавливаются подобные счетчики на столбах - автоматически собирают показания и отправляют их в личный кабинет раз в месяц, для этого их такие умные и устанавливали. А где нет - то в ближайшее время заменят на умные. Борьба с неплательщиками, типа. Потому и счётчики в недоступном месте, где-нибудь на столбе. Так что это скорее баловство, как мне кажется. Лично для себя - хотел иметь текущие показания, нагрузку и напряжение по всем фазам, с обновлением раз в 10 минут
Может стоит временно ТГ канал сделать чтобы делится соображениями и мыслями?
Я думаю нужно подождать энтузиастов с первых страниц, особенно Vittaly7 и уже делать чат. Вдвоём точно ничего путного не сообразим, я уже года два назад платку бросил в незаконченном виде, "авось и так работает" Слишком намаялся со сбором протоколов ардуиной (ковырял параллельно еще irda-uart и modbus к другим счётчикам), без нормального логического анализатора, выработав аллергию к задумке) Особенно долго парили мозги как раз Энергомера с UART-IRDA портом, под который нужен особенный ик-порт-модуль, и Миртек)
UPD: кстати, а может быть дело в том, что в какой-то момент управляющая организация может авторизовываться на счётчике и что-то запрашивать по таймеру, подвешивая порт счётчика? Может быть мы пытаемся сделать запрос от другого пользователя, и счётчик нас как-то блочит на полчасика? Тогда нужно попробовать сначала отправлять какую-то команду деавторизации/отключения от счётчика перед запросом. МетерТулз вроде что-то отсылал в счётчик при закрытии окна. Или может быть счётчик периодически загоняют в какой-нибудь режим настройки, отправляя новые тарифы/время, и "забывают" выйти из этого режима настройки? Кажется звучит как рабочий вариант
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
