СПОДЭС/DLMS/COSEM • МЭК-61107/IEC-61107 • Энергомера МЭК/IEC • Энергомера CE • СПб ЗИП ЦЭ2727А • Ленэлектро ЛЕ-2 • Пульсар-М • Энергомера BLE

Компонент требует дополнительного тестирования с разными счетчиками - пишите на anton.viktorov@live.com

• 1. Назначение
• 2. Отказ от ответственности
• 3. Функции
• 4. Принцип работы
• 5. Подключение
• 6. Настройка основного компонента
• 7. Настройка сенсоров для опроса счетчика
• 8. Примеры готовых конфигураций
• 8.1 НЕВА
• 9. Проблемы, особенности, рекомендации

Компонент для считывания данных с приборов учета (ПУ) электроэнергии, воды, газа и пр., поддерживающих протокол стандарта МЭК/IEC 61107-2011 или IEC 62056-21.

Примечание: Начиная с 2017 года МЭК 61107 заменен более современным стандартом СПОДЭС на основе стэка DLMS/COSEM. Компонент для работы с новым стандартом тут: https://github.com/latonita/esphome-dlms-cosem.

Пользуясь данным ПО пользователь полностью берет на себя всю ответственность за любые последствия.

• подключение как безадресное (широковещательный запрос), так и по адресу (9 последних цифр заводского номера),
• индивидуальна настройка сенсоров под конкретные запросы,
• работа с массивом возвращаемых значений,
• два вида сенсоров: числовой и текстовый,
• работа по оптопорту согласно протоколу: сначала 300 бод, затем переключение на скорость, запрошенную счетчиком (обычно 9600 бод), либо (не по стандарту) сразу работа на указанной скорости,
• работа по RS-485 проверена на скорости 9600 бод,
• работа с несколькими ПУ на одной шине RS-485,
• работа с несколькими шинами RS-485.

Требуется подключение по оптопорту или RS-485 или CAN. Настраиваются общие параметры подключения к ПУ, а также набор сенсоров для считывания. Компонент поддерживает работу по протоколу МЭК 61107 в режиме C. В данном режиме работа идет по принципу запрос-ответ. Для каждого сенсора указывается запрос к регистру в виде OBIS кода в общем случае (A-B:C.D.E*F), а в частном - каждый производитель делает всё немного по-разному. Требуется ознакомиться с документацией на ПУ.

Устройства:

• микроконтроллер Esp (работа провена на модулях на базе esp32, esp32s, esp32s2, esp8266)
  • если испольуется UART0, то в модуле логгера нужно отключать вывод в порт (baud_rate:0)
• оптопорт TTL-IR (не USB!) на 3.3 вольта
• или модуль трансивера RS-485,

  • должен быть расчитан на 3.3 вольта (связка Esp + модуль на max485 расчитаный на 5 вольт может работать некорректно)

  • запитываем либо от esp модуля, либо отдельно, земля общая

  • A+ и B- на счетчике соединяем с модулем

    • желательно подключение витой парой (А и В переплетены между собой)
    • земли счетчика и модуля 485 не соединяем, а если кабель с экраном/оплеткой - можно соеденить с землей только со стороны модуля для уменьшения наводок
    • если расстояние до счетчика большое, то может понадобиться терминирующий резистор 120 Ом между A и B
• пользуемся документацией на счетчик для уточнения схем подключений

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

Протестирована работа с головкой MY014-D

┌───────┐           3.3В     ┌─────────────┐  ┌────────────────┐
│       │            └── VCC ┤             │  │                │
│  MCU  ├ RX ──────────── RX ┤  TTL to IR  ├  ┤ Электросчетчик │
│ ESPxx ├ TX ──────────── TX ┤   module    ├  ┤                │
│       │                    │             │  │                │
│       │                    │             │  ┤                │
│       ├ GND ────────── GND ┤             │  ┤                │
└───────┘                    └─────────────┘  └────────────────┘

На данный момент в продаже много модулей RS-485 с расширеным набором функций - с логикой автоматического выбора направления передачи, защитными диодами и предохранителями. Эти модули рекомендуются к использованию, т.к. более надежны.
Например, модуль XY-017

┌───────┐           3.3В     ┌─────────────┐                 ┌────────────────┐
│       │            └── VCC ┤             │                 │                │
│  MCU  ├ RX ──────────── RX ┤ RS485<->TTL ├ A ───┐─┐─┐─── A ┤ Электросчетчик │
│ ESPxx ├ TX ──────────── TX ┤   module    ├ B ───└─└─└─── B ┤                │
│       │                    │             │                 │                │
│       │                    │             │          ┌─── + ┤                │
│       ├ GND ────────── GND ┤             │      9-12В ── - ┤                │
└───────┘                    └─────────────┘                 └────────────────┘

Иногда RX/TX на модуле перепутаны - ничего страшного, просто меняем.

Классический модуль с RO/DI/DE/RE входами + общая земля. MAX485 расчитан на 5В, а MAX3485 на 3.3В, хотя первый в 90% случаев прекрасно работает и от 3.3В тоже.

• RO - прием,
• DI - передача,
• DE + R̅E̅ - контроль линии для передачи данных (flow_control_pin в yaml)

┌───────┐           3.3В     ┌─────────────┐                 ┌────────────────┐
│       │            └───VCC ┤             │                 │                │
│  MCU  ├ RX ──────────── RO ┤ RS485<->TTL ├ A ───┐─┐─┐─── A ┤ Электросчетчик │
│ ESPxx ├ TX ──────────── DI ┤   module    ├ B ───└─└─└─── B ┤                │
│       ├ FLOW ──────┬─── RE ┤             │                 │                │
│       │            └─── DE ┤             │          ┌─── + ┤                │
│       ├ GND ────────── GND ┤             │      9-12В ── - ┤                │
└───────┘                    └─────────────┘                 └────────────────┘

Подключение нескольких счетчиков возможно двумя способами:

• Подключение к одной шине RS-485 - самый простой вариант, просто необходимо параллельно подключить счетчики к одной шине: соединить А c А, B с B

     ┌─────┐    ┌─────┐         ┌─────┐
     │ # 1 │    │ # 2 │  ...    │ # N │
     │ A B │    │ A B │  ...    │ A B │
     └─┬─┬─┘    └─┬─┬─┘         └─┬─┬─┘
       │ │        │ │             │ │
  ─ A ─┴──────────┴───── ... ─────┘ │
  ─ B ───┴──────────┴─── ... ───────┘

• Подключение к разным шинам RS485 - нужно подключать два модуля RS485.

Подлючаем внешний компонент из репозитория

external_components:
  - source: github://latonita/esphome-iec61107-meter
    refresh: 30s
    components: [iec61107]

Смотрим документацию к ПУ. По стандарту МЭК 61107 для оптопорта 300 бод 7е1, далее переключение на 9600. RS485 не требует переключений, сразу работает на 9600. :

uart:
  rx_pin: GPIO16
  tx_pin: GPIO17
  baud_rate: 300
  data_bits: 7
  parity: EVEN
  stop_bits: 1

Основной модуль (hub)

iec61107:
  id: neva-mt
  update_interval: 30s
  baud_rate_handshake: 300   # стартовая скорость оптопорта, при работе с rs485 поставить необходимую (9600)
  receive_timeout: 3000ms    # время ожидания ответа от счетчика
  crc_method: SUM7           # Метод расчета контрольной суммы SUM7 или XOR
#  programming_mode: false        # Некоторые требуют формального входа в режим программирования
#  password: "00000000"           # и указания пароля (в Неве, по-умолчанию, "00000000")
#  address: 123456789             # обязательно, если несколько устройств на одной шине
#  delay_between_requests: 100ms  # задержка между запросами к счетчику
#  flow_control_pin: GPIO32
#  uart_id: bus_01               

• address - по-умолчанию пустой, если счетчик один - то адрес не требуется. Если несколько счетчиков - то там указываем его адрес - это последние 9 цифр его заводского номера.
• receive_timeout - по-умолчанию 500мс, если ответы длинные - то можем не успеть дождаться ответа - увеличиваем. для оптопорта нужно брать 2-3 с
• delay_between_requests - по-умолчанию 100мс, иногда счетчик может тупить после больших запросов и не успевает принять новый - увеличиваем. важно - больше 1.5с не рекомендую, в счетчиках есть таймаут от 1.5с до 3с - если их не дергают, они считают, что общение закончено и закрывают сессию.
• flow_control_pin - указываем, если 485 модуль требует сигнал направления передачи RE/DE
• uart_id - если использьзуете несколько портов UART, указать его id

Если установлено несколько устройств на одной шине, необходимо обязательно указывать адрес счетчика. В противном случае счетчики начнут отвечать одновременно и процесс считывания данных будет нарушен.

uart:
    id: bus_1
    ...

iec61107:
  - id: meter_01
    uart_id: bus_1
    address: 123456001
  - id: meter_02
    uart_id: bus_1
    address: 123456002

sensor:
  - platform: iec61107
    iec61107_id: meter_01
    obis_code: xxx
    name: xxx1

  - platform: iec61107
    iec61107_id: meter_02
    obis_code: xxx
    name: xxx2

Реализованы два типа сенсоров:

• sensor - числовые данные, float
• text_sensor - текстовые данные в формате "как пришли от счетчика"

sensor/text_sensor:
  - platform: iec61107
    # iec61107_id: meter_01   # если несколько счетчиков
    name: Название сенсора ЛАТИНИЦЕЙ!!
    obis_code: Код ОБИС согласно документации к ПУ.
    index: индекс ответа, по-умолчанию 1
    sub_index: суб-индекс внутри ответа, по-умолчанию 0 = весь ответ из скобок
    ... остальные стандартные параметры для сенсора ...

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

В общем случае код представлен в виде A-B:C.D.E*F. При этом в документации A,B,F могут быть не указаны. Запись кодов может отличаться, иногда пишут 1-0:15.8.1*255, иногда 1.0.15.8.1.255.

Обычно, код OBIS выглядит, например, для частоты сети так: 1-0:14.7.0:255. Производители часто первые две цифры опускают и указывают 14.7.0:255. или даже опускают последний 255, и получается 14.7.0.

Также допускается запись в шестнадцатиричном формате. Например, производитель Тайпит для счетчиков указывает OBIS код в шестнадцатиричном формате и использует 4 цифры. Для частоты сети это 0E0701FF, что соответствует коду 14.7.1*255, а точнее 1-0:14.7.1*255.

Производитель Энергомера для разных моделей использует разные кодировки, вместо OBIS кодов использует свои названия функций. Например, ET0PE.

Если запрос возвращает несколько значений, то, по-умолчанию, берется первое, но можно выбрать указав номер ответа (индекс, начинается с 1). Если в скобках указано несколько значений через запятую, то можно указать какое именно брать (суб-индекс, начинается с 1). Примеры запросов и ответов от счетчика:

Запросы берем из руководств на счетчики.

Важный момент - при компиляции Esphome заменяет все не-латинские символы на _. А значит, если попадутся два сенсора с одинаковыми названиями с учетом замен - то Home Assistant будет смешивать их данные. Крайне рекомендую в yaml писать на английском/латинице, а уже в HASS переименовывать на русский.

# Выжимка из конфига, скачайте полный файл neva-324-mt.yaml, в нем десятки сенсоров

esphome:
  name: neva-324-mt

esp32:
  board: esp32dev
  framework:
    type: arduino

external_components:
  - source: github://latonita/esphome-iec61107-meter
    refresh: 30s
    components: [iec61107]

uart:
  rx_pin: GPIO16
  tx_pin: GPIO17
  baud_rate: 300              # для rs485 поменяйте на 9600
  data_bits: 7
  parity: EVEN
  stop_bits: 1


iec61107:
  - id: meter_01
    update_interval: 30s
    receive_timeout: 3000ms
    baud_rate_handshake: 300  # Оптопорт начинает работу с 300 бод, для rs485 - обычно 9600
    programming_mode: true    # Счетчики НЕВА требуют формального входа в режим программирования
    password: "00000000"      # и указания пароля (по-умолчанию "00000000")
    crc_method: XOR           # Метод расчета контрольной суммы в Неве - XOR

sensor:
  - platform: iec61107
    obis_code: 0F0880FF     # Ответ от счетчика 0F0880FF(020044.63,015023.90,005020.73,000000.00,000000.00)
    index: 1                # Берем первые скобки
    sub_index: 1            # Первое значение из списка: 020044.63
    name: Energy Total
    unit_of_measurement: kWh
    accuracy_decimals: 0
    device_class: energy
    state_class: total_increasing

- platform: iec61107
    obis_code: 0F0880FF     # Такой же код как и выше, но нужно вытащить другое значение
    index: 1                # Тоже берем первые скобки
    sub_index: 2            # Теперь берем второе значение из списка: 015023.90
    name: Energy T1
    unit_of_measurement: kWh
    accuracy_decimals: 0
    device_class: energy
    state_class: total_increasing

  - platform: iec61107
    obis_code: 0F0880FF
    index: 1
    sub_index: 3
    name: Energy T2
    unit_of_measurement: kWh
    accuracy_decimals: 0
    device_class: energy
    state_class: total_increasing

# ...

text_sensor:
  - platform: iec61107
    name: Serial number
    obis_code: 600100FF
    entity_category: diagnostic

• "да должно всё работать" :)
• основная проблема - неверно выбранное питание/модуль для 485. еще достаточно часто модули встречаются нерабочие.
• при слабом сигнале wifi, esp может терять точку доступа и часто заново подключаться. А если esp одноядерная (например, esp8266 или esp32s2), то это может влиять на сбор данных со счетчика и, в целом, может приводить к неожиданным перезагрузкам
• по идее, hardware uart всегда надежнее, но, в целом, software uart и на esp8266 работает без сбоев, если не делать запросы, которые возвращают кучу данных
• забавно, что у кого-то бывает работает только software uart, у кого-то - только hardware uart, у многих - и так и так
• модуль 485 желательно брать с защитными диодами - наблюдали как умершую esp8266, так и модуль, у которого работала только отправка, а прием не работал
• модули 485 с маркировкой пинов rx/tx - иногда rx/tx наоборот :)
• внимательно смотрите на номера пинов на esp - ориентируйтесь на распиновку модулей (pinout diagram). Часто производители нумеруют пины на плате совсем не так, как они пронумерованы на чипе esp (например, nodemcu). Указывайте номера, как на чипе (GPIOxx)
• при подключении нескольких счетчиков на одну шину - опрос происходит последовательно
• при подключении нескольких счетчиков на разные шины - опрос может происходить параллельно и если используется SoftwareSerial, то могут появляться ошибки при считывании, рекомендуется использовать esp32 и только HardwareSerial