Smart Meter Interface - SML has issues decoding obis_code "1-0:96.1.0"

stoffelll commented 10 months ago

The problem

I installed yesterday my new IR reading head with an ESP01s running esphome for my smart meter. This new reading head with wifi is an replacement for my existing one, which was connected previously via USB to my PI 4 which is running home assistant.

Unfortunately I experienced regular "crashes" (values in HA Dashboard were available/shown for some miliseconds and afterwards disappearing again). This behaviour started when I added a text sensor for the obis_code: 1-0:96.1.0" (metering ID/serial number). When I removed it again, I got stable values in the HA Dashboard.

Using the "old" IR reading head (with USB), it worked well and got the correct metering ID.

This is my config:

  uart:
  id: uart_bus
  tx_pin: 1
  rx_pin: 3
  baud_rate: 9600
  debug:

sml:
  id: mysml
  uart_id: uart_bus

text_sensor:  
  - platform: sml
    name: "Metering ID"
    sml_id: mysml
    #server_id: "0123456789abcdef"
    obis_code: "1-0:96.1.0"

And this is the value I get via debug:

[22:48:38][D][sml:066]: OBIS info:
[22:48:38][D][sml:072]:   (0a0149534b000479f6f9) 1-0:96.50.1 [0x49534b]
[22:48:38][D][sml:072]:   (0a0149534b000479f6f9) 1-0:96.1.0 [0x0a0149534b000479f6f9]
[22:48:38][D][sml:072]:   (0a0149534b000479f6f9) 1-0:1.8.0 [removed]
[22:48:38][D][sml:072]:   (0a0149534b000479f6f9) 1-0:2.8.0 [removed]
[22:48:38][D][sml:072]:   (0a0149534b000479f6f9) 1-0:16.7.0 [removed]

and this was causes the "crash": [22:48:38][D][sml:072]: (0a0149534b000479f6f9) 1-0:96.1.0 [0x0a0149534b000479f6f9]

Which version of ESPHome has the issue?

2023.10.6

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2023.11.2

What platform are you using?

ESP8266

Board

ESP01S

Component causing the issue

SML

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

hmichels commented 7 months ago

Hello! I have similar the same problem, the OBIS identifier "1-0:96.1.0" cannot be interpreted as text (roughly the HEX code as above).

Does anyone have a solution for this?

Abdull commented 1 month ago

@stoffelll :

[22:48:38][D][sml:072]:   (0a0149534b000479f6f9) 1-0:96.1.0 [0x0a0149534b000479f6f9]

May it be you are/were reporting data from an iskra smart meter? Because 0x0a0149534b000479f6f9 decodes as follows:

Line Feed (LF) character (0a)
Start of Heading (SOH) control character (01)
ASCII representation of "ISK"
Null character (00)
End of Transmission (EOT) control character (04)
ASCII representation of "y"
The last two bytes (f6 and f9) are outside the standard ASCII range and could represent extended ASCII characters, part of a multi-byte encoding, or some kind of checksum or special data

I have the same symptoms as described by you, caused by an Apator smart meter. For OBIS identifier "1-0:96.1.0", ESPHome reports a similar telegram with LF, SOH, and EOT control characters, just as the middle three-letter representation, it gives "APA" (as in "Apator").

I have the feeling that some software component within the ESPHome / SML stack is incorrectly unwrapping payload data.

Regarding "values in HA Dashboard were available/shown for some miliseconds and afterwards disappearing again": in my system the root cause seems to be an exception happening on the Home Assistant side:

# ...
# the following log entries repeat again and again
# ...
Aug 17 18:25:57 my-ha-server hass[996]: 2024-08-17 18:25:57.858 INFO (MainThread) [aioesphomeapi.reconnect_logic] Successfully connected to my-esp32-device @ 192.168.11.22 in 0.045s
Aug 17 18:25:58 my-ha-server hass[996]: 2024-08-17 18:25:58.155 INFO (MainThread) [aioesphomeapi.reconnect_logic] Successful handshake with my-esp32-device @ 192.168.11.22 in 0.298s
Aug 17 18:26:01 my-ha-server hass[996]: 2024-08-17 18:26:01.433 ERROR (MainThread) [aioesphomeapi.connection] my-esp32-device @ 192.168.11.22: Invalid protobuf message: type=TextSensorStateResponse data=b'\r\xbf`\xd6!\x12\n\n\x01APA\x01\x04\xe6\x00\xcb': Error parsing message
Aug 17 18:26:01 my-ha-server hass[996]: Traceback (most recent call last):
Aug 17 18:26:01 my-ha-server hass[996]:   File "aioesphomeapi/connection.py", line 893, in aioesphomeapi.connection.APIConnection.process_packet
Aug 17 18:26:01 my-ha-server hass[996]: google.protobuf.message.DecodeError: Error parsing message
Aug 17 18:26:01 my-ha-server hass[996]: 2024-08-17 18:26:01.434 WARNING (MainThread) [aioesphomeapi.connection] my-esp32-device @ 192.168.11.22: Connection error occurred: Invalid proto
buf message: type=TextSensorStateResponse data=b'\r\xbf`\xd6!\x12\n\n\x01APA\x01\x04\xe6\x00\xcb': Error parsing message
# ...
# above log entries repeat again and again and again
# ...

My assumption:

Smart meter produces new "telegram" once per second, including the 1-0:96.1.0 data.
ESPHome stack incorrectly processes 1-0:96.1.0 value, creates unvalidated protobuf message from this garbled value, and sends it to Home Assistant API.
Home Assistant receives message, parses/validates it, notices it stinks, and throws exception/aborts further processing.
Repeat once per second with each new smart meter telegram; and/or ESPHome retries delivering the same garbled data ad infinitum. Latter hypothesis would explain why the Home Assistant dashboard flickers between showing "Unknown" and any previous correct data even when removing the ESP32 IR sensor from the smart meter IR sender port.

stoffelll commented 1 month ago

Correct, it’s an iskra smart meter, but as you have the same issue it seems to be a generic issue.

esphome / issues