Получение данных с IAMMETER на вашем собственном сервере

Получение данных с IAMMETER на вашем собственном сервере

Wi-Fi счетчики энергии IAMMETER могут отправлять данные измерений напрямую на сервер, MQTT-брокер или платформу данных, управляемую клиентом. Это позволяет разработчикам и системным интеграторам создавать собственные EMS, BMS, IoT-сервисы, базы данных или панели мониторинга, не используя IAMMETER-Cloud в качестве приемника данных.

В этом руководстве рассматривается интеграция со стороны принимающего сервера:

• запуск тестового приемника;
• захват первой полезной нагрузки счетчика;
• идентификация счетчика и каналов измерения;
• нормализация и хранение данных;
• оценка объема поступающих данных;
• подготовка приемника к производственному развертыванию.

Счетчик IAMMETER
      │
      │ HTTP/HTTPS, MQTT/MQTTS или TCP/TLS
      ▼
Сервис приема данных клиента
      │
      ├── Журнал сырых данных
      ├── База данных временных рядов или реляционная БД
      ├── EMS / BMS / ERP
      └── Панель мониторинга, отчеты и службы оповещений

Для получения информации о возможностях прошивки и форматах адресов счетчиков используйте Руководство по Local API и открытым интерфейсам IAMMETER. Для выбора архитектуры см. Разработка собственной системы мониторинга энергии.

1. Выбор архитектуры приемника

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

Протокол	Компонент приемника	Хорошая отправная точка для
HTTP / HTTPS	Веб-эндпоинт	REST-бэкенды и самая простая первая интеграция
MQTT / MQTTS	MQTT-брокер и подписчик	Существующие IoT-платформы и конвейеры сообщений
TCP / TLS	Сокетный слушатель	Выделенные коллекторы и сервисы с пользовательским протоколом

HTTP обычно является самым простым способом для изучения первой полезной нагрузки, поскольку официальный тестовый приемник можно запустить с помощью небольшого примера на Node.js. MQTT — хороший выбор, если брокер уже является частью системы. TCP/TLS обеспечивает интеграцию на более низком уровне, но требует больше работы на стороне приемника.

Безопасные протоколы и форматы пользовательских портов описаны в текущем руководстве по прошивке, а не повторяются здесь.

2. Быстрый старт: получение первой полезной нагрузки по HTTP

IAMMETER предоставляет официальный пример HTTP-приемника на Node.js для тестирования интеграции.

2.1 Запуск тестового приемника

Скачайте пример с:

• Пример HTTP-сервера IAMMETER на GitHub

Запустите:

node Server.js

Пример прослушивает порт 8000. Когда приходит запрос, он:

• собирает тело HTTP-запроса;
• выводит URL запроса;
• выводит загруженное тело;
• возвращает HTTP-статус 200 с небольшим JSON-ответом об успехе.

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

2.2 Обеспечение доступности приемника

Перед настройкой счетчика убедитесь, что:

• сервер прослушивает ожидаемый интерфейс и порт;
• брандмауэр разрешает соединение;
• счетчик может разрешить доменное имя при его использовании;
• NAT, обратный прокси или VPN-путь работают;
• конечный URL достигает нужного маршрута приложения.

Для теста в локальной сети счетчик и приемник могут использовать одну локальную сеть без доступа в Интернет. Для удаленного приемника сайт должен иметь маршрут до сервера.

2.3 Направление счетчика на приемник

В текущем веб-интерфейсе счетчика выберите режим работы HTTP и введите адрес назначения, например:

{server-address}:8000/upload

HTTPS-эндпоинты могут использовать порт по умолчанию или пользовательский порт. Текущие правила адресации, включая https://host:port, описаны в разделе HTTP/HTTPS прошивки.

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

3. Понимание входящей полезной нагрузки IAMMETER

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

Полезная нагрузка обычно включает поля уровня устройства, такие как:

• SN — серийный номер счетчика для идентификации устройства;
• version — версия прошивки счетчика;
• method — метод сообщения или тип полезной нагрузки;
• Data или Datas — массивы измерений.

Data используется для одного канала измерения. Datas содержит несколько массивов измерений для многоканального или трехфазного счетчика.

Пример структуры одного канала:

{
  "method": "uploadsn",
  "mac": "B0F8932A295C",
  "version": "i.75.98.71y",
  "server": "em",
  "SN": "12345678",
  "Data": [228.91, 1.61, 225, 15066.47, 0]
}

Не жестко задавайте количество массивов для каждого счетчика. Количество каналов и доступных полей зависит от модели счетчика и включенных функций измерений.

Используйте авторитетное определение при реализации парсера:

• Определение JSON-данных счетчика энергии IAMMETER

3.1 Обработка в зависимости от модели

Держите логику обработки для конкретных моделей отдельно от приемника протокола передачи.

Например, WEM3046T и WEM3046TE измеряют вторичный выход 5 А внешнего трансформатора тока. Их значения должны быть преобразованы с применением соответствующего коэффициента CT для получения первичного измерения. Это характеристика счетчика и CT, а не различие между HTTP, MQTT или TCP.

Поэтому практичный конвейер приема данных разделяет:

1. декодирование протокола передачи;
2. валидацию JSON;
3. идентификацию счетчика и канала;
4. масштабирование или нормализацию в зависимости от модели;
5. хранение и бизнес-расчеты.

4. Проектирование модели данных приема

Храните достаточно информации для воспроизведения и диагностики исходных показаний.

Полезная минимальная модель включает:

Поле	Назначение
SN счетчика	Сопоставляет полезную нагрузку с зарегистрированным устройством
Индекс канала или фазы	Различает однофазные, разделенные и трехфазные данные
Время получения сервером	Обеспечивает согласованную временную метку приема
Voltage	Электрическое измерение
Current	Электрическое измерение
Active power	Входные данные для расчета импорта/экспорта или нагрузки в реальном времени
Import kWh	Накопленная импортированная энергия
Export kWh	Накопленная экспортированная энергия
Firmware version	Поддерживает устранение неполадок и совместимость парсера
Raw payload	Позволяет воспроизводить, аудировать и исправлять парсер

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

4.1 Хранение сырых и нормализованных данных отдельно

Для производственных систем рассмотрите возможность хранения:

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

Это упрощает исправление логики парсинга или коэффициента CT без потери исходной полезной нагрузки.

4.2 Аккуратное использование времени получения сервером

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

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

5. Реализация других типов приемников

5.1 MQTT или MQTTS приемник

Для приема через MQTT система клиента предоставляет:

• доступный MQTT-брокер;
• правила аутентификации и контроля доступа;
• сервис подписчика или потребителя;
• валидацию и сохранение полезной нагрузки;
• мониторинг работоспособности брокера и потребителя.

IAMMETER публикует данные в реальном времени по теме устройства, например:

device/{SN}/realtime

Используйте специальное руководство для настройки брокера, учетных данных, тем и вопросов MQTTS:

• Публикация данных IAMMETER в вашем MQTT-брокере

Home Assistant MQTT Discovery не требуется для интеграции с обычным сервером клиента.

5.2 TCP приемник

IAMMETER предоставляет минимальный пример TCP-слушателя на Node.js:

• Пример TCP-сервера IAMMETER на GitHub

Пример прослушивает порт 8000 и выводит полученные данные. Производственный TCP-приемник должен дополнительно обеспечивать:

• управление жизненным циклом соединений;
• буферизацию и валидацию полезной нагрузки;
• безопасную обработку частичных или объединенных сокетных фрагментов;
• идентификацию устройств;
• сохранение и обработку ошибок;
• мониторинг и контролируемые ограничения ресурсов.

Не предполагайте, что одно событие data сокета всегда равно одному полному сообщению приложения.

5.3 TLS приемник

Официальный пример TLS демонстрирует TLS-слушатель с серверным ключом и сертификатом:

• Пример TLS-сервера IAMMETER на GitHub

Перед производственным использованием замените демонстрационные сертификаты и настройки на утвержденные сертификаты организации, управление ключами и конфигурацию безопасности. Приемник должен регистрировать ошибки TLS отдельно от ошибок валидации полезной нагрузки.

Форматы адресов со стороны счетчика для TCP и TLS описаны в руководстве по интерфейсам прошивки.

6. Планирование интервала загрузки и мощности сервера

Текущая прошивка поддерживает интервал сторонней загрузки до 2 секунд. Короткий интервал полезен только в том случае, если принимающая система, хранилище и приложение нуждаются в таком разрешении.

Примерное количество записей, генерируемых одним счетчиком:

Интервал загрузки	Записей на счетчик в день	100 счетчиков в день	1 000 счетчиков в день
60 секунд	1 440	144 000	1 440 000
10 секунд	8 640	864 000	8 640 000
2 секунды	43 200	4 320 000	43 200 000

Эти числа представляют события загрузки, а не обязательно строки базы данных. Трехфазная полезная нагрузка может быть нормализована в несколько записей каналов, а индексы, хранение сырых данных или реплицированное хранилище увеличивают фактический объем базы данных.

Планирование мощности должно включать:

• пиковые одновременные соединения;
• запросы или сообщения в секунду;
• стоимость парсинга JSON;
• умножение строк на уровне каналов;
• индексы базы данных и хранение;
• панели мониторинга и агрегационные запросы;
• журналы, повторные попытки и хранение недоставленных сообщений;
• трафик резервного копирования и репликации.

Для управления или автоматизации с интервалом в одну секунду в той же локальной сети рассмотрите Modbus TCP вместо использования удаленного конвейера загрузки.

7. Обеспечение надежности и качества данных

Производственный приемник должен быть готов к сетевым и прикладным сбоям.

7.1 Валидация каждой полезной нагрузки

Проверяйте как минимум:

• синтаксис JSON;
• обязательные поля идентификации;
• ожидаемую структуру массивов;
• числовые типы и разумные диапазоны;
• поддерживаемое сопоставление модели или канала;
• вариации полей в зависимости от прошивки.

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

7.2 Планирование дублирующихся и пропущенных загрузок

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

Определите, как бизнес-система будет:

• обнаруживать дублирующиеся записи;
• выявлять пробелы;
• отличать молчащий счетчик от неработающего приемника;
• избегать вычисления энергии путем слепого суммирования накопительных регистров кВт·ч;
• согласовывать накопленную энергию после сбоя.

7.3 Мониторинг полного пути данных

Мониторьте больше, чем просто веб- или сокетный процесс. Полезные сигналы включают:

• время последней полезной нагрузки по каждому счетчику;
• количество неверных полезных нагрузок;
• время ответа приемника и частоту ошибок;
• активные TCP/TLS-соединения;
• задержку MQTT-потребителя;
• задержку записи в базу данных;
• глубину очереди;
• использование диска и задания по хранению.

8. Безопасность принимающей системы

Для приемника, доступного из Интернета:

• предпочитайте зашифрованный протокол передачи, поддерживаемый развертыванием;
• ограничивайте открытые порты и сетевые источники, где это возможно;
• применяйте аутентификацию MQTT и авторизацию тем;
• защищайте HTTP-эндпоинты с помощью окружения или архитектуры безопасности приложения;
• управляйте TLS-сертификатами и закрытыми ключами безопасно;
• избегайте записи учетных данных или полных чувствительных полезных нагрузок в журналы приложения;
• ограничивайте скорость и изолируйте некорректный или злонамеренный трафик;
• поддерживайте операционную систему, среду выполнения и зависимости в актуальном состоянии.

Просмотрите текущее поведение прошивки MQTTS, TLS и HTTPS в руководстве по прошивке и открытым интерфейсам перед выбором архитектуры безопасности.

9. Контрольный список производственного развертывания

Счетчик и сеть

• Версия прошивки записана и проверена
• SN счетчика сопоставлен с правильным объектом и каналами
• Адрес назначения и порт проверены
• DNS, брандмауэр, NAT или VPN-путь протестированы
• Требуемый интервал загрузки подтвержден

Приемник

• Сырая полезная нагрузка захвачена для каждой модели счетчика в области применения
• Созданы тесты парсера на основе реальных примеров полезной нагрузки
• Обрабатываются одно- и многоканальные полезные нагрузки
• Обработка коэффициента CT для WEM3046T/E проверена, где применимо
• Некорректные и неподдерживаемые полезные нагрузки изолированы безопасно
• Приемник возвращает или поддерживает поведение, ожидаемое выбранным протоколом

Хранение и эксплуатация

• Политика временных меток документирована
• Политика обработки дубликатов и пропущенных данных документирована
• Емкость базы данных рассчитана с учетом количества устройств и интервала
• Включены журналы, метрики и оповещения о последнем появлении по каждому счетчику
• Хранение, резервное копирование и восстановление протестированы
• Сертификаты, учетные данные и правила доступа проверены
• Сетевой сбой и перезапуск приемника протестированы

10. Связанная документация

• Разработка собственной системы мониторинга энергии
• Использование IAMMETER без Интернета или IAMMETER-Cloud
• Local API и открытые интерфейсы IAMMETER
• Интеграция MQTT счетчика энергии
• Определение JSON-данных измерений IAMMETER
• Обзор самостоятельного размещения и интеграции с открытым исходным кодом

11. Устаревшие скриншоты конфигурации со стороны счетчика

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

Устаревшая страница TCP

Устаревшая страница TLS

Устаревшая страница HTTP/HTTPS

В более ранней документации прошивки также использовался локальный метод конфигурации /api/uploadinterval и описывался минимум в шесть секунд. Текущая прошивка позволяет задавать интервал в веб-интерфейсе и поддерживает документированный минимум в 2 секунды.

Последнее обновление: 16 июля 2026 г.