Многотарифные 3-х фазные электро-счетчики Меркурий 231 АТ (230) имеют ИК интерфейс, через который можно снимать показания, изменять характеристики счетчика, корректировать время.
Со счетчика можно считать довольно много данных.
Для этого применяется модуль на базе esp8266, который выступает еще в качестве веб-сервера. Он также занимается отправкой данных на IoT сервер, автоматом корректирует время, строит графики — по денькам, по часам, по минуткам.
Я использовал старенькый модуль esp01 из этого проекта, только перепаял флеш память на 16 Мбайт.
Память применяется для постройки графиков и сохранения истории.
В ней хранится два повторяющихся буфера — по денькам на 7680 дней и детализированное потребление до конца памяти (для флеши 4 Мбайта — 2136 дней).
Для хранения текущих указателей и других переменных массива истории применяется 30 б нескончаемой памяти FRAM.
В принципе, можно было обойтись и без нее, но раз она уже у меня была распаяна, почему бы ее не применять.
Графики строятся при помощи библиотеки D3.js:
Схема:
Последнее редактирование: 12 Апр 2017
Сергей_Ф
Moderator
Команда форума
Замечательно. Можно узреть конструктив? Чем питается устройство? Что нужно выполнить, если отрешиться от FRAM?
Active member
Фото в сборе к сожалений нет, есть только по частям.
Конструктив простой — к esp01 припаяна платка на макетке с MCP2120, а к ней на проводах подсоединена платка с ИК детектором TFDU4100.
Отрешиться от FRAM — дописать логику программы, дабы при включении определяла текущие указатели в кольцевых буферах и время фактического отключения питания со счетчика, дабы высчитать смещение времени.
Последнее редактирование: 17 Мар 2017
aloika
Active member
Хороший проект!
Работает ли ОТА? Размеренно ли?
Активный участник общества
Замечательно. Можно узреть конструктив? Чем питается устройство? Что нужно выполнить, если отрешиться от FRAM?
Через диодик подключить питание на RTC RAM от маленького элемента-батарейки на 1.25В.
FRAM непременно лучше, в всех собирателях и при расчетах статистики. Тем паче стоимость издавна низкая. А вот маленьких уже не приобрести, в главном идут от 16 кб. С большенными объемами, чем 128 кило, в корпусах не для "кухонного" паяльничка. Такая ветка.
Туда обычно сохраняют текущий кольцевой посекундный график, а так-же статистику по записям в flash. Как раз 16 кило — это минималка для обыденного логгера с кольцевым буфером главных записей на год от 10-ка датчиков. По другому для вас придется при старте собирать кучу последних записей из 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 для обычных устройств не годятся — обстоятельств много, пример:
Во-1-х, препядствия вызвали SD-карты памяти, которые при работе нередко давали сбои, для восстановления работоспособности карт их приходилось переформатировать и записывать образ системы повторно.
Источник <Спектр рабочих температур Raspberry Pi. Результаты тестов>
Пишем протоколы счетчиков Меркурий 230 и Меркурий 200 для OpenSCADA
Для кого
— Для тех кто употребляет OpenSCADA, но не может воплотить больше чем решения «из коробки»
— Для тех кто отыскивает СКАДу себе, но так и не может обусловится
— Для тех кто забросил этот проект, так и не разобравшись как он работает
Для чего
— Данное решение позволяет считывать показания счетчиков меркурий 230 и меркурий 200 без каких или лимитов
— Это безвозмездно
Проекту openscada (oscada.org) уделяют не заслужено не много внимания, о нем написана всего одна статья на хабре. Большая часть инженеров страшатся трогать и трехметровой палкой этот продукт, черт его знает какой этот ваш линукс. Разрабатывает его уже не 1-ый десяток лет практически один человек, Роман Савоченко.
Не имея ранее опыта со СКАДА вообщем (а с линуксом незначительно дружил) избрал конкретно его для реализации мониторинга объектов на предприятии. Так как сопоставить мне было не с чем, интерфейс и все связи данных с друг другом я воспринял как подабающее. Очень посодействовал видеоурок «быстрый старт», лично я считаю таких уроков можно было выполнить и побольше. Документацию тоже пришлось перечитывать не раз, но оно того стоило. Подключив 1-ый модуль сбора данных Невод+ длительно не мог осознать почему он не работает. Ведь как совместимый с протоколом DCON он в перечне проекта считался(поточнее его аналог). Полез в исходник протокола и… оказалось что совершенно он с ним не совместим, как и многие другие модули сбора из перечня. 1-ое воззвание на форум делему мою поправило и еще несколько ошибок достаточно оперативно. Говорить обо всех тонкостях системы я не буду, лучше прочтите вышеупомянутую статью на хабре либо поглядите «быстрый старт».
Спустя какое то время мне пригодилось снимать показания с электросчетчиков Меркурий 230. Поддержки этих счетчиков в openscada нет. Попробовал утилиту taskgroup от создателя всем известного konfiguratorа, опрашивать счетчики по CSD ей оказалось дохлым номером. Но все не так плохо как могло быть, openscada система максимально модульная и написать свой модуль можно хоть на С++, хоть на языке высокого уровня прямо в ней. Описание протокола обмена для меркурия 230 без заморочек можно отыскать в сети, производитель «Инкотекс» естественно может предоставить для вас описание по запросу, но мне не хотелось связываться с этой волокитой.
Итак, подключаем шину со счетчиками, для наглядности и наилучшей ориентации в протоколе ставим konfigurator и сниффер последовательно порта, открываем документацию. Пытаемся прочесть данные со счетчика с адресом 75.
все снимки экрана кликабельны
Лицезреем как побежали наши данные.
Протокол обмена для меркурий 230 очень похож на протокол modbus.
Запрос на открытие канала связи предназначен для разрешения доступа к данным с указанием уровня доступа. В счетчике реализован двухуровневый доступ к данным: 1-ый (низший) — уровень потребителя, и 2-ой (высший) — уровень владельца
Попытаемся при помощи конфигуратора опросить наш счетчик и лицезреем что 1-ый запрос это и есть пароль, а ответ счетчика это 4 б. включающие в себя
Сейчас попытаемся это воплотить на openscada. В С++ я не силен, потому решил воплотить на языке, интегрированном в саму СКАДу, который там зовется JavaLikeCalc.Javascript. Сам код опроса реализуется в 2-ух модулях UserProtocol и DevLib. Сделаем устройство в библиотеке устройств и назовем m230. Добавим атрибуты netaddr(сетевой адресок), password(пароль), transport(последовательный порт) и answer(ответ на запрос пароля). И напишем запрос.
Сейчас перейдем к протокольной части и сделаем в UserProtocol наш пользовательский протокол и назовем его так же m230. Начнем с преобразования сетевого адреса. Код расчета контрольной суммы modbus CRC16 уже был написан издавна, мне осталось его только воткнуть в свой код.
Сделаем и транспорт, прописав в нем подходящий порт, скорость и тайминги.
Сейчас сделаем устройства в LogivLev, в нем сделаем контроллер а так же характеристики (они же и есть счетчики). Избираем наш шаблон, в конфигурации прописываем сетевой адресок, пароль и транспорт.
Не излишним будет и включить архивацию в соответственной вкладке.
Перебегаем ко вкладке Атрибуты и лицезреем наши 4 б ответа от счетчика. Пароль принят, отлично.
Что все-таки попробуем считать показания электроэнергии. Добавляем в в атрибуты шаблона несколько записей еще несколько строк кода для каждого тарифа и для их суммы.
Дальше добавим в наш протокол еще строчки. Не излишнем будет проверить ответ на тот ли запрос пришел и проверить длину пакета. Каждый 4 б полезной инфы ответа интерпретируется собственной последовательностью б, для чтения энергии она видна на снимке экрана. В конце из 16ричной системы данные переводим в десятичную, к тому же это число нужно поделить на 1000.
Заходим снова в конфигурацию шаблона, ставим галку «Считывать энергию от сброса» и в атрибутах у нас уже видны данные о тарифах.
На этом останавливаться мы не собираемся и попробуем добавить секундные данные — напряжение, ток и мощность. Тут все тоже самое, меняем только 2-ой, 3-ий и 4-ый б, которые отвечают у нас за то, какую информацию мы желаем получить от счетчика.
Незначительно изменений добавим и на стороне протокола.Проверяем ответ на байты из чего строим предположение о его длине и проверяем ее, добавляем свою последовательность б, переводим в десятичную систему и делим на 100 для ответа о напряжении и мощности и на 1000 для ответа о токе.
Сейчас в атрибутах нашего счетчика лицезреем все его главные данные, которых естественно в разы больше и при желании можно добавить еще, к примеру частоту в герцах и почти все другое.
Добавим для наглядности еще несколько счетчиков. Но это не все, данные нужно не просто считывать но и представить их в комфортном виде. Для этого в openscada существует Vision (рабочий пользовательский интерфейс) в каком данные можно представить в любом комфортном вам виде, хоть в виде мнемосхемы, в виде графиков, в виде документов итд. Возьмем стандартный документ из шаблона и отредактируем его дабы вышло так.
А в обработку документа добавим строчку, дабы можно было просто читать архивы данных по денькам.
В конечном итоге запускаем проект и открываем наш документ.
Если необходимо представить секундные значения либо из архива то создаем график, добавляя туда наши значения. Вот вам наглядный пример значений для счетчика по напряжению.
Но спустя некоторое время не отпускала мысль написать заодно и протокол для однофазовых счетчиков меркурий 200. Описание протокола я в сети не отыскал, но мир не без хороших людей.
Сетевой адресок здесь и есть пароль счетчика. По дефлоту он равен последним 6 цифрам серийного номера. Попробуем написать шаблон.
Вот схема пакета запроса и ответа
Серийный номер счетчика очень длиннющий чтобы уместить его в 32-битное целое число, потому поделим его на две части.
Код запроса тарифа 0x27, пишем структуру запроса и выделяем какие байты за какой тариф у нас отвечают. И делим это значение на 100. И проверяем наш ответ на объем знаков.
Дабы считывать секундные значения используем код запроса 0х63. Также проверим наш ответ на количество байтов. Аспекты по каждому из этих значений тоже учитываем.
Но что делать если счетчик закодирован программкой наладчик+? К счастью как кодирует наладчик+ всем уже издавна понятно, потому добавляем строчку в начало нашего кода.
Перейдем к протокольной стороне. Преобразовываем наш адресок в шестнадцатеричную систему. Расчет контрольной суммы и запрос как и в прошлом протоколе.
Добавим несколько счетчиков и в конфигурации шаблона пропишем наши опции.
И во вкладке Атрибуты лицезреем как счетчик дает нужные нам значения.
Сделаем документ дабы просматривать эти значения в более комфортном виде. Отредактируем наш шаблон документа. Запустим наш проект.
