Support more OBIS codes in DSMR Component and rename two for more global use

[Bascht74]

Hi,

I am a user of esphome in Germany and using it for my smart meters.
I need the dsmr reader (DSMR Component) that is depending on arduino-dsmr.
In Germany (maybe in Austria or other countries as well) there are some more OBIS codes used.

Especially

• 1-65:1.8.3 - 1-65:1.8.9 --> are missing so far. Right now there are only energy_delivered_tariff1 and energy_delivered_tariff1. There are some Companies that offer more tariff changes a day, like mine (e.g. 20-6, 6-14, 14-17, 17-20). So energy_delivered_tariff3-9 would be a nice addition.

• Maybe the OBIS-Code 1-65:1.8.0 should be renamed to energy_delivered_total. In some countries, only totals are relevant, but those counters should not have the country name in it (right now: energy_delivered_lux). In Germany I got 1.8.0 for the totaI (using this entity right now) and 1.8.1 - 1.8.4 (4 tariffs).

• 1-65:2.8.0 --> This counter should be renamed to energy_returned_total as well. Actual name: energy_returned_lux.

• Maybe add 1-65:2.8.3 - 9 as well (energy_returned_tariff3-9, but not used in Germany to my knowledge.

specs here:
https://www.edi-energy.de/index.php?id=38&tx_bdew_bdew%5Buid%5D=838&tx_bdew_bdew%5Baction%5D=download&tx_bdew_bdew%5Bcontroller%5D=Dokument&cHash=a7a251b9c22a4b3fa581f0717736a8ef

I found something for Europe as well:
https://www.promotic.eu/en/pmdoc/Subsystems/Comm/PmDrivers/IEC62056_OBIS.htm
https://www.satec-global.com/sites/default/files/EM920-IEC-62056-21.pdf
https://oms-group.org/fileadmin/files/download4all/specification/Vol2/4.1.2/OMS-Spec_Vol2_AnnexA_B042.pdf

I tried to contact somebody here, as I thought that esphome is using that library:
https://github.com/matthijskooijman/arduino-dsmr
But it seems to be dead.

Is there anybody I can talk to about this change and the additions?

Thx for any hint and sorry for the not-so-perfect English,

Seb

[oxan]

@mmakaay this might be relevant/interesting for you.

[Bascht74]

OK, thank you.

[Bascht74]

Hi, @mmakaay
I am unsure how to discuss these ideas with the right people.
Could you direct me to the right direction?
Very appreciated!

Thx,

Sebastian

[mmakaay]

One problem with DSMR using the Arduino library, is well.... that it's an Arduino library. This means that is external from the ESPHome code and that makes it hard to change. We already have the library forked at glmnet/arduino-dsmr to make it a bit easier, but this still is not optimal.
I am currently in the process of doing some code restructuring for the DSMR component, to eventually implement a built-in parser. That should make it a lot easier to get missing codes integrated.

I agree on the naming of things. I think it would be good to use generic names when they are used in multiple countries. We ought to keep the old names as aliases in that case, to prevent breaking existing configurations.

[Bascht74]

I am currently in the process of doing some code restructuring for the DSMR component, to eventually implement a built-in parser. That should make it a lot easier to get missing codes integrated.

OK Thx, I'll be patient...

I agree on the naming of things. I think it would be good to use generic names when they are used in multiple countries. We ought to keep the old names as aliases in that case, to prevent breaking existing configurations.

Yes, at least for some releases. In HA they get rid of old stuff 4-6 months later... so you have enough time to change the config.

[Strixx76]

In Sweden the standard follows IEC 62056-6-1. (OBIS)
Which means that the "lux" parts in the underlying library is misnamed. They are not specific for Luxembourg, instead they are actually following a internationally standard.

So I would also suggest some name changes:

OBIS         Old name                New name
----         --------                --------
1-0:1.8.0    energy_delivered_lux    total_energy_delivered
1-0:2.8.0    energy_returned_lux     total_energy_returned
1-0:3.8.0    total_imported_energy   total_reactive_energy_delivered
1-0:4.8.0    total_exported_energy   total_reactive_energy_returned

[mmakaay]

That kind of configuration is what I'm actually after, with the main reason being deprecating the use of the external, incomplete and hard to maintain library. Only, I would like to not make the full OBIS code configuration a responsibility for the user configuration, but allow for use of generic names that reference various OBIS codes.
Setting specific keys for a sensor after choosing a generic OBIS code would help in getting for example units of measurement issues fixed (in case a smart meter provides the wrong unit type for example).

[Strixx76]

That sounds nice. I guess you could put all those generic names that reference different OBIS codes in the python part of the code? Then the example yaml above could still be valid for "not supported" registers, and the user could still set it up more simple like:

sensor:
  - platform: h1
    value: total_energy_delivered
    name: "Total Energy Delivered"

[kloodhu]

I'd like to set up some custom obis codes. Is this feature alive? I cant find any information in the documentation. Thank you!

[derkrasseleo]

I'm also intereset in custom OBIS codes, as the ones from my provider aren't fully supported..

[kallik]

Any news on this? I'd be interested in adding specific codes from my provider and I also think there should be an option of maintaining different includes for different "energy providers", this could be an option when adopting a device in HA to either select from a list of providers or "custom" and pick supported OBIS codes similar to what @Strixx76 mentioned.