Question about Hager OBIS codes

[Bouni]

Hi,

first of all thank you so much for this awesome ESPHome integration :-)

I worked for the last two years on a PCB that allows me to read out my two smart meters. It was set aside because of various reasons but finally I managed to get it working 🥳

So currently I work on the ESPhome config. So far everyhing is clear, I used the HAGER documentation for the OBIS codes:

https://hager.com/de/katalog/download/product/asset/file/22DE0001-TECHNIK-EHZ.PDF/

Entries like 01 00 01 08 00 FF Zählerstand Totalregister are totally clear, the notation is in HEX so 01 00 01 08 00 becomes 1-0:1.8.0. What the FF means is not clear to me.

But the document further down the list has these entries:

01 00 60 32 03 03 Spannungsminimum
01 00 60 32 03 04 Spannungsmaximum
01 00 60 32 00 03 Minimale Chiptemperatur
01 00 60 32 00 04 Maximale Chiptemperatur
01 00 60 32 00 05 Gemittelte Chiptemperatur

The first 2would share the same OBIS code, the same goes for the last 3. Any ideas how this works or how the OBIS code has to be set in order to get these measurements?

[the78mole]

Hi Bouni,

The OBIS Codes are standardized identifiers for measurement values and have the syntax: A-B:C.D.E*F The alphabetic characters [A...F] each representing a byte value, the symbols [-:.*] are just seperators to make them more readable. The default representation uses decimal coding (0...255). Meaning FF = 255

In short, simply convert hex to decimal and put it together with the seperators like that:

01 00 01 08 00 FF -> 1-0:1.8.0*255
01 00 60 32 03 03 -> 1-0:96.50.3*3
01 00 60 32 03 04 -> 1-0:96.50.3*3

FF = 255 is also widely used for summing values, as far as I remember.

Hope this helps.

Regards, Daniel

[alengwenus]

As far as I remember the last part of the OBIS number (*...) is not supported by this component. I simply did not know about it. I will have a look into the code. Maybe it's not that hard to implement.

[Bouni]

@the78mole Thanks for the detailed explanation, highly appreciate it 😊

@alengwenus That would be awesome, te component ist already more than awesome. As soon as I finished my project I'll open source it and maybe make it available on Tindie or a similar platform for sale.

Here's a picture of the board in a freshly printed case on my test meter on my bench:

@alengwenus do you have any kind of support page (buymeacoffee / Ko-Fi / patreon / ...) so that I can send you a small donation?

[alengwenus]

@Bouni I implemented the optional 6th byte in the OBIS code (main branch). In your configuration you may now use: obis_code: "A-B:C.D.E*F" as well as obis_code: A-B:C.D.E. In the latter case the *255 is appended automatically as a default value. It would be great if you could test it, please.

Please note, that I only implemented it in this custom component. It's not yet integrated in the SML ESPHome component. As soon as you confirm functionality, I'll catch up.

[Bouni]

Sure, I'll test it in my lunch break and let you know!

Just to be sure, I need to use this component like this, right?

external_components:
  - source: github.com/alengwenus/esphome_components@main
    components: [ sml ]

Hopefully this will then be merged into the ESPHome comonent as well!

[alengwenus]

Yes, that should do. And if everything works well, feel free to use this link: https://www.buymeacoffee.com/alengwenus :-)

[Bouni]

Seems to work 🥳

- platform: sml
  name: "Chip temperature"
  obis_code: "1-0:96.50.0*2"
  unit_of_measurement: "°C"
  accuracy_decimals: 1
  device_class: temperature
  state_class: measurement
  filters:
    - multiply: 0.1

- platform: sml
  name: "Chip temperature minimum"
  obis_code: "1-0:96.50.0*3"
  unit_of_measurement: "°C"
  accuracy_decimals: 1
  device_class: temperature
  state_class: measurement

- platform: sml
  name: "Chip temperature maximum"
  obis_code: "1-0:96.50.0*4"
  unit_of_measurement: "°C"
  accuracy_decimals: 1
  device_class: temperature
  state_class: measurement

- platform: sml
  name: "Chip temperature mean"
  obis_code: "1-0:96.50.0*5"
  unit_of_measurement: "°C"
  accuracy_decimals: 1
  device_class: temperature
  state_class: measurement

- platform: sml
  name: "Voltage minimum"
  obis_code: "1-0:96.50.3*3"
  unit_of_measurement: V
  accuracy_decimals: 1
  device_class: voltage
  state_class: measurement

- platform: sml
  name: "Voltage maximum"
  obis_code: "1-0:96.50.3*4"
  unit_of_measurement: V
  accuracy_decimals: 1
  device_class: voltage
  state_class: measurement      

[Bouni]

Any idea why the sensors in HA keep toggling between value und not available?

https://user-images.githubusercontent.com/948965/212402733-e4dd894e-f18f-4864-a0f5-e564ba734314.mp4

[alengwenus]

Does this happen since the last changes? Is there anything in the log (maybe set the log log level to DEBUG)? How offen does your Smart Meter transmit a data packet? The frequency of changes seems to be rather high. What about the WIFI Signal strength and the API connection to HASS?

There are many reported issues in the ESPHome issue tracker which describe these kind of problems (e.g. here). I just want to assure it‘s definitely related to the SML component.

[Bouni]

I have the boards now mounted to the meters in my house. All the tests were done on another HAGER meter at work (bought of ebay). In the web interface everything looks ok and thats the only place I used for development aith the test meter so I cannot say for sure whats the difference.

I do some tests now and see if I can figure out where this problem comes from.

[Bouni]

I figured it out and to my surprise quicker than I thought 😄

Adding the logger at debug level I saw frequent disconnects from HA and I saw this:

20:53:43    [D] [text_sensor:067]   
'Public key': Sending state '����   ��x
                                           |�B8
                                               �\Z��j��șl~��@��|�͊#'

I had a text sensor that should give me the public key like this:

- platform: sml
  name: "Public key"
  obis_code: "129-129:199.130.5"
  format: text
  sml_id: smlid

I guess this somehow crashed the API connection. AS I don't really need the publik key, I removed it and et voila it works like a charm 🥳

[alengwenus]

I guess the public key is a hexadecimal string. Then you should define the format parameter in your text sensor's configuration as hex to get a hexadecimal string representation.

Defining the parameter as text would lead to an ASCII representation of the transmitted bytes. Those are not necessarily alphanumeric but also control characters which can lead to unpredictable behavior.