Дистанционное снятие показаний электросчетчика Меркурий

[vad7]

Многотарифные 3-х фазные электро-счетчики Меркурий 231 АТ (230) имеют ИК интерфейс, через который можно снимать показания, изменять параметры счетчика, корректировать время.
Со счетчика можно считать достаточно много данных.

Для этого используется модуль на базе esp8266, который выступает еще в качестве веб-сервера. Он также занимается отправкой данных на IoT сервер, автоматически корректирует время, строит графики - по дням, по часам, по минутам.

Я использовал старый модуль esp01 из этого проекта, только перепаял флеш память на 16 Мбайт.
Память используется для постройки графиков и сохранения истории.
В ней хранится два циклических буфера - по дням на 7680 дней и детальное потребление до конца памяти (для флеши 4 Мбайта - 2136 дней).

Для хранения текущих указателей и других переменных массива истории используется 30 байт вечной памяти FRAM.
В принципе, можно было обойтись и без нее, но раз она уже у меня была распаяна, почему бы ее не использовать.



Графики строятся с помощью библиотеки D3.js:





Схема:


Подробнее здесь: Устройства для дома на микроконтроллерах: Дистанционное снятие показаний электросчетчика Меркурий

Прошивка здесь: Releases · vad7/PowerMeter-IrDA · GitHub

 

[Сергей_Ф]

Замечательно. Можно увидеть конструктив? Чем питается устройство? Что надо сделать, если отказаться от FRAM?

 

[vad7]

Фото в сборе к сожалений нет, есть только по частям.
Конструктив простейший - к esp01 припаяна платка на макетке с MCP2120, а к ней на проводах подсоединена платка с ИК сенсором TFDU4100.





Питание - микромодуль.

Отказаться от FRAM - дописать логику программы, чтобы при включении определяла текущие указатели в кольцевых буферах и время фактического отключения питания со счетчика, чтобы рассчитать смещение времени.

 

[aloika]

Отличный проект!
Работает ли ОТА? Стабильно ли?

 

[pvvx]

Замечательно. Можно увидеть конструктив? Чем питается устройство? Что надо сделать, если отказаться от FRAM?

Через диод подключить питание на RTC RAM от мелкого элемента-батарейки на 1.25В...
FRAM безусловно лучше, в любых сборщиках и при расчетах статистики. Тем более цена давно низкая. А вот мелких уже не купить, в основном идут от 16 килобайт. С большими объемами, чем 128 кило, в корпусах не для "кухонного" паяльника. Такая ветка.
Туда обычно сохраняют текущий кольцевой посекундный график, а так-же статистику по записям в flash. Как раз 16 кило - это минималка для обычного логгера с кольцевым буфером основных записей на год от десятка датчиков... Иначе вам придется при старте собирать кучу последних записей из Flash для вычисления среднего за последнюю неделю, месяц и другие интервалы графиков, а выключение питания будет приводить к потере-выпадениям к шагу записи в Flash. Выйдет не профессиональное, а ардуиновское решение. FRAM дешевле и практичнее супервайзера с UPS.
Данная система, как вижу построена на web-свалке, а она имеет корни именно от таких систем с FRAM + FLASH, которые уже работают более 15 лет непрерывно, но на контроллере попроще - обслуживание web до 4-х клиентов одновременно и показания по 16 датчикам с выбором показа графиком или распечаткой для принтера, ну и LAN с прямым выходом в глобальный Инет (вместо WiFi и "роутеров с бредмаурами", т.к. стабилен на 1000%), RAM 16 килобайт у MCU всего ..
Дизайн web немного другой:

- все слова в меню кликабельны и вызывают переключение или другую страницу... Остальное - "ком. тайна".
С ESP достичь такой стабильности в процессе 2-х лет тестов не удалось, сейчас и пилю RTL SDK для замены тех устройств на более новые с расширенными показаниями и возможностями, иначе придется использовать что-то более дорогое, а оно серийное... Может vad7 удастся допилить ESP (?)...
Да, c только Flash есть ещё одна особенность - время стирания сектора и записи блока. Если проц работает тоже из неё, тогда реакция системы становиться с этим интервалом, что не всегда применимо, к примеру в том-же ModBus RS-485, чтобы полностью обеспечить стандарт. Придется лепить или вторую Flash, или куски кода с зависимым временем реакции (ответа) должны сидеть в RAM. FRAM частично решает эти проблемы, т.к. можно отложить операцию с Flash.
SD для нормальных устройств не годятся - причин много, пример:
Во-первых, проблемы вызвали SD-карты памяти, которые при работе часто давали сбои, для восстановления работоспособности карт их приходилось переформатировать и записывать образ системы повторно.
Источник <Диапазон рабочих температур Raspberry Pi. Результаты тестов>

 

[pvvx]

@vad7 - а зачем стоит MCP2120? Встроенный IR режим в UART не работает?

 

[vad7]

@pvvx, есть то есть, но не работает ни фига. А разбираться нет ни времени ни желания.

Простое добавление UART_IRDA_EN не включает генерацию вообще. Если добавить UART_IRDA_TX_EN, то генерация начинается, выводит какую-то ерунду.

 

[Lstt]

Есть ли возможность варианта отказаться от FRAM, которую иногда трудно найти за пределами МКАД?
Планируется ли внедрение возможности передачи информации на MQTT сервер и подписку на топики? Вообще было бы супер!
Если было на Arduino, попытался бы изменить сам, а на Eclipse, увы, не умею..

 

[vad7]

@Lstt, нет, пока не планирую - сделал для себя, на текущий момент хватает. Единственное, позже добавлю график по месяцам и выбор года/периода. Щас это не актуально, так как данных еще мало собралось.

На алиэкспресс, где и брал, памяти FM24C04 (512 байт) много и стоит копейки. Есть даже в дип корпусе.

 

[Lstt]

Ок, закажу FM24c04 c Taobao..Мне оттуда проще..

 

[Lstt]

На самом деле эта память лишняя, так как в RTC уже есть такая память.
Но чтобы убрать лишнее вам придется самому это сделать.

Вы имеете ввиду, переработать код, убирая обращения по i2c? А как правильно запитать RTC память в случае с NodeMCU?

 

[vad7]

@nikolz, @Lstt - ага, выпаять феном у модуля крышку, умудриться припаять на VDD_RTC проводок к батарейке.
Офигительно просто.
Хотя тут вот прочел на сайте espressif, что он NC, то есть облом:
VDD_RTC is a reserved pin and powered by internal LDO.
Thus, it can just be NC.

UART IrDA у esp8266 с багом, глотает биты у второго байта и далее:

 

[pvvx]

ага, а нафига паять туда батарейку?

Чтобы данные сохраняло - зачем вообще FRAM и подобные?
Всё уже проверенно пару лет назад. Сброс питания RTC в ESP8266 заведен на чипселект - внутренний LDO при этом не работает. Диод и батарейка типа AG13 спасают дело RTC, т.к. чип с браком, но данное решение его обходит.

Вам хоть сто раз писать, всё равно глухи. Чтобы получить достоверные данные, необходимо ПОСТОЯННО опрашивать внешние датчики и при опросе хоть в 1 сек их не записать циклически в Flash объемом менее 128 Мегабайт, чтобы не перекрыть допустимый максимум ресурса записи Flash. Она после 10-ти тысяч записей/стираний в одну ячейку будет страдать вашей болезнью – быстрой забывчивостью. Логгеров вы ни разу в жизни не делали и их проблем не знаете. Для этого их описал для вас в предыдущих сообщениях данной темы, но приходиться повторять - быстрая забывчивость у вас?

При отключении питания данные от счетчика не нужны, но пропуск последних влияет на общую картину. Снимать раз в минуту данные не фильтруя/усредняя за период – это не датчик и не статистика, а глупые разрозненные точки неизвестно о чем. Тормозить запрос показаний пользователю за последний период, путем быстрого перебора половины flash для расчета сумм и усреднения - никто, кроме вас так не делает. Их надо иметь всегда готовыми и рассчитанными. Если реакция устройства на действия пользователя более 0.2 секунд – это значит, что кнопка будет разбита или его надо постучать молотком – отвалилось что-то. Расчет последних усреднений при обрыве питания без записи в FRAM тоже сорвется и при последующем включении поздно махать руками, перелопачивая всю flash, да у контроллера нет столько ресурсов, чтобы поддерживать множественные алгоритмы восстановления данных после обрыва и для рабочего цикла… Дешевле поставить FRAM– будет меньше объем кода и ошибок в ПО.

 

[Lstt]

При отключении питания данные от счетчика не нужны, но пропуск последних влияет на общую картину. Снимать раз в минуту данные не фильтруя/усредняя за период – это не датчик и не статистика, а глупые разрозненные точки неизвестно о чем. Тормозить запрос показаний пользователю за последний период, путем быстрого перебора половины flash для расчета сумм и усреднения - никто, кроме вас так не делает. Их надо иметь всегда готовыми и рассчитанными. Если реакция устройства на действия пользователя более 0.2 секунд – это значит, что кнопка будет разбита или его надо постучать молотком – отвалилось что-то. Расчет последних усреднений при обрыве питания без записи в FRAM тоже сорвется и при последующем включении поздно махать руками, перелопачивая всю flash, да у контроллера нет столько ресурсов, чтобы поддерживать множественные алгоритмы восстановления данных после обрыва и для рабочего цикла… Дешевле поставить FRAM– будет меньше объем кода и ошибок в ПО.

Для себя вижу ещё более простой вариант - банально, опрос счётчика с определенным интервалом (например, раз в минуту) и (при наличии внешнего сервера-контроллера) посылка данных (напругу, мощность и т.д.) по MQTT на этот сервак(контроллер). Там данные сохраняются в SQL . А там уже можно делать, чего душа пожелает - запрос со смартфона через Telegram (любые цифры статистики) и т.д.
Естественно, при наличии, внешнего сервака..Я использую IOBroker - ioBroker – Automate your life , ioBroker Forum - Русскоязычные форумы

 

[vad7]

@Lstt, у меня отсылается на IoT Analytics - ThingSpeak

 

[vad7]

То,что Вы собрали это хорошо.
Но это далеко до оптимального и более простого решения.
Поэтому попробую объяснить, что именно в этом решении не оптимально по-моему мнению.
Т е расскажу свое решение, которое проще этого но решает все тоже самое.
----------------------------
1) Схема устройства - любая esp (110 руб)+ блок птания из USB зарядки (45 руб)+ IK фотодиод. Если связь двухсторонняя то еще светодиод.
--------------------------------------------
2) Так как в устройстве используется время с SNTP сервера, то это предполагает наличие выхода в интернет.
Поэтому накопленный блок данных передается в сеансе выхода в эфир на какой-нибудь сервер для хранения данных , можно передать в любое облако например яндекса или майла или на свой хост или на локальный комп.
------------------------------------
3.1) циклический сбор организуется в RAM (40 кбайт) для сбора мгновенных значений параметров.
При пропадании питания пропадает лишь последний буфер накопленных данных.
3.2) циклический сбор организуется во flash.
Указатели буфера хранятся в памяти RTC.
При пропадании питания восстанавливаются по обнаружению конца записи в буфере.
---------------------
4) Все остальные чудеса (графики, таблицы данных за последние 100 лет) я бы сформировал в любом другом удобном месте а не лепил бы это все в eSP.
---------------------
В результате получается банально простое в реализации устройство можно сделать даже на луа и уж тем более на стандартном SDK и без всяких свалок и помоек.

Так это наоборот усложнение получается:
Ручная обработка ИК,
Сторонние сервера для хранения данных, которые могут быть также обесточены, если дома, и не доступны или внезапно платны, если внешние.
В моем случае ничего, кроме собранного устройства не нужно.

Отсутствие энергонезависимой памяти усложняет код, и не факт, что проще - купить и припаять FRAM или пытаться ее "заменить".
Вот сделал я двухстадийный ОТА для флеши 512к, и хотя там пару строчек кода, а припаять флеш на 16Мб оказалось проще.

 

[pvvx]

Если переводите разговор об общем понятии устройств логгирования – то у нас нет среды для её создания. Эта область IoT ещё не сформирована. Ни один ESP в неё не вписывается, т.к. это удел устройств с несколькими мегабайтами RAM. В его составе должен быть web-сервер на несколько подключений любых стандартных на сегодняшний день устройств, позволяющий производить конфигурацию устройства и вывод статистики работы устройства за всю жизнь в графическом и текстовом виде. Никакие внешние сервера при этом не требуются и не нужны для набора статистики. Управление и слияние с внешним миром – это другая задача и зависит от пипа устройства. Статистика нужна любому современному устройству, от лампочки, аккумулятора до холодильника или автомобиля. Не имеет смысла содержание их данных на внешних серверах.
Web-свалка - это только кусочек зачаток таких систем. Ваши же движения идут в обратную сторону, чтобы удалить время создания структуры таких систем и затормозить прогресс

Наиболее близким по возможностям и поддержки класса IoT устройств находящегося между простым передающим датчиком и системой на OpenWRT или Линукс счас является mbed. Другие структуры и среды разработки очень далеки от этого. Mbed пока дает и формирует только уровень api. Тоже ещё далеко, но он всё же ближе к цели, чем другие. Так что забудьте о всяких Arduino, Lua и прочих – это игрушки, нашлепки над системой, для других задач, даже не IoT. Им до формирования функциональности в IoT дальше всех.

Не сформировано ещё основного набора концепций api с минимальными ресурсами системы (RAM от 1 до 16 МВ, Flash от 8 до 128 МВ) –

1. Конфигуратора настроек подключения устройства к внешним системам – управления драйверами типа WiFi, NFС и т.д. для активации соединения.
2. Дисковой системы для хранения файлов и сопровождения логгирования (объемы от десятка МВ).
3. Системы минимальных стандартных сетевых драйверов для обеспечения соединения с любым устройством (DHCP, mDNS, NETBIOS, …).
4. Стеков сетевых протоколов TCPcHTTP + TSL/SSL с многопользовательской поддержкой.
5. Управления многозадачностью (apiдля RTOS)
6. Api для Web, websocket и прочим серверам и клиентам.
7. Api для драйверов контроллеров периферии работающей по DMA (SPI, I2С, PCM, ...)

На сегодня это формируется только в Mbed. Web-свалка - это первый вариант пробы создания общей структуры на конроллере, который не совсем годиться для этого. По этому имеет многие ограничения и специфику, например - переносимость на другие устройства. Но её цель не в том, а в демонстрации, что это возможно на ограниченных ресурсах (а не на луникс со своими заморочками долгой загрузки) и она её выполнила на 1000%.
А вот ваших вариантов решений пока не видно - одни стенания и предложения горбатых решений, уводящих от построения и развития концепций для устройств IoT.
Тут уж ничего не поделать, если вы слепы и не видите тенденций движения и развития в IoT. На следующий год как раз уже все MCU с WiFi и прочими системами связи будут иметь необходимый минимум аппаратной части для данного класса устройств. Этот класс будет востребован на сроки не менее 15 лет развития IoT. ESP8266 или ESP-32S в них не входит и являются мертворожденными вариантами для IoT.
PS: Под концепции описываемого класса счас и пытаюсь перелопатить SDK от RTL871x с 2.5МВ RAM. Но уже ожидаются более подходящие микроконтроллеры... Наиболее близкие решения к данному классу рынок выпускал в виде роутеров - там есть система web и конфигурации связи с внешним миром. Больше там ничего нет и требует дополнений, а имеющая часть реализации не имеет стандартизированного api.
Я не думаю, что вы справитесь с современными SoC, т.к. процессор там самая последняя часть по приоритету, а более важными являются интегрированные в SoC решения и необходимый для их поддержки объем RAM и Flash. Для “телепузиков” это уже непроходимый объем информации как связать все потроха и вызывает у них "перегрузку мозгу" и стенания, вроде ваших.
Так што решение @vad7 находится в правильном направлении, но реализовать всё нормально не позволяет убогость и качество ESP8266. И нефиг выдумывать какие-то костыли к нему, т.к. оно собрано из того что есть с учетом описываемого
Ой как сложно поставить FRAM... Надо выдумывать внешние сервера и другие глупости, которые для основного функционирования данного устройства вообще не нужны, а вписать передачу накопленных данных - дело пяти минут.

 

[pvvx]

Для себя вижу ещё более простой вариант - банально, опрос счётчика с определенным интервалом (например, раз в минуту) и (при наличии внешнего сервера-контроллера) посылка данных (напругу, мощность и т.д.) по MQTT на этот сервак(контроллер). Там данные сохраняются в SQL . А там уже можно делать, чего душа пожелает - запрос со смартфона через Telegram (любые цифры статистики) и т.д.
Естественно, при наличии, внешнего сервака..Я использую IOBroker - ioBroker – Automate your life , ioBroker Forum - Русскоязычные форумы

Да-да-да - всё выкинуть, т.к. любимая Arduino на любимом глюке ESP8266 не позволяет сделать нормального решения. Лучше заплатить провайдерам и за обслуживание вешними серверами раз в 100 больше, чем просто добавить один раз сотню руб в стоимость устройства и взять подходящий SoC. Привычка жить в кредит (оплачивать потом во много раз больше)?
Без наблюдающего папочки с выплатами ему жить уже никак (по другому не пробовали)? Кому нужны нежизнеспособные, зависящие от внешнего мира устройства? Природа не создает таких – у неё все имеют определенный уровень автономности.
Дайте мне бесплатный сервер, способный собирать статистику с приемом данных от 1000 точек в секунду и покажите когда это будет доступно для пропускной способности сети для каждого устройства в доме, считая от каждой лампочки
Выборка по одной точке в сек с обычного счетчика электроэнергии - это не является правильными данными и по ней невозможно получить правильные показания потребления. Что-то счетчик так не делает, а отслеживает каждые 3 фазы полуволны 50 Гц - минимум 300 точек в сек.
При вашем методе за сутки наберется расхождение с показаниями счетчика в более 10%.
В связи с имеющимся интерфейсом связи у счетчика вам нельзя пропускать ни одного импульса ИК с него. И т.к. у вас Arduino в мозгах, понятно, что это невозможно на ней и вы ищите халявные, кое как сделанные, решения предоставленные для дальнейшего получения прибыли от вас сторонними держателями серверов. Главная цель которых - посадить на иглу Наверняка каким-то боком кормитесь от данного направления посредников и предложение использовать внешние сервера является очередной рекламой их недоработанного сервиса, не позволяющего обеспечить требуемой функциональности.

 

[pvvx]

Задачи которые решаются на этом форуме - это задачи на 5 минут. Это очень примитивные задачи по их логике, поэтому какой смысл говорить о том, что припаять микросхему просто или нет.

Это ваше видение. Оно в корне неверно и подобрано под ваши условия и недальновидность, с желанием получить только халяву и не развиваться далее. Уже давно вы тут пропагандируете решения ухода от развития - всё новое вам страшно, чуждо, и воспринимаете с трудом. А основные цели форума в обучении, а не как за 5 минут сделать что-то кривое.
Обучение подразумевает предоставление альтернативных решений на выбор и умение их использовать. От вас решений и вариантов не исходит. Волочитесь далее, ничего не понимая
Вот чё вы вперлись в данную тему? Тут вашего ничего нет, а хаять может любой.
Мы тут как-бы создаем новые направления на имеющихся наших разработках, а не создаем халяву под ваши условия для сборки за пять минут на кухне безграмотными в электронике, вроде вас .

 

[pvvx]

Автор @vad7 тут описывает, что не так в филармонии, предоставляя своё решение на имеющихся кусках. Вы что тут предоставили, чтобы выяснить, как далее вести дальнейшее развитие хоть темы IoT на простых SoC?
Свой понос про Остапов?