esphome / feature-requests

ESPHome Feature Request Tracker
https://esphome.io/
415 stars 26 forks source link

Support Austrian Dsmr encryption with 2 keys for the Slimmelezer #1404

Open wieluk opened 3 years ago

wieluk commented 3 years ago

Describe the problem you have/What new integration you would like

I would like to use the slimmelezer in Austria with the Sagecom T210-D-r and the Sagecom S210 energy meter. All information I could gather so far are these: Safetylayer COSEM Security Suite 0, additional Datatransfer encryption, two keys needed GAK > Global authentification Key and GUEK > Global unicast encryption Key

The best documentation I found for Austria was this document for a austrian P1 concept: https://oesterreichsenergie.at/fileadmin/user_upload/Smart_Meter-Plattform/20200201_Konzept_Kundenschnittstelle_SM.pdf

Please describe your use case for this integration and alternatives you've tried:

I tried setting up the slimmelezer with setting both keys as Dsmr key individually. But my log only returns: [W][dsmr:126]: Timeout while waiting for encrypted data or invalid data received. and sometimes inbetween it sends Wifi-Signal strength or uptime.

Additional context

I contacted the seller of the slimmelezer and he was very nice but told me to ask here because he didn't write the code. He said that they also use two keys in Luxemburg. Maybe the data is similar? I will try to get more information in the next days. Unfortunately it seems really hard to get information on this.

wieluk commented 3 years ago

On the Sagecom S210 I am getting this error message in the log:

Invalid unit
[E][dsmr:138]: 1-0:1.8.0(000439385*Wh)
                    ^

so the decryption seem to work.

for the T210-D-r 99% of the time i get the log posted in my first post. But once I got this:

[E][dsmr:138]: �P[�%A_��V�7�o'�k����÷]�YN�����e
^
Data should start with /

so decryption does not seem to work for this device.

I also found the meaning of the obis-codes on page 13: https://www.e-netze.at/downloads-data/pdf.aspx?pdf=EN_Bedienungsanleitung_LandisGyr_Smart%20Meter_Version%2011-20_ID2452_WEB.pdf

mmakaay commented 3 years ago

For the "Invalid unit" error, I have worked out a solution. The decryption indeed seems to work there, but the meter reports a value in Wh instead of kWh, which can be considered a violation of the standard. I wrote a fix for the DSMR parser library, which allows meters to report both Wh and kWh, which fixes this specific error. The fix was tested against my own and against @wieluk 's meter. Both are working with this change.

PR can be found at: https://github.com/glmnet/arduino-dsmr/pull/7

mprokop commented 2 years ago

Hello, is there an update to the unit problem?

Is there any way I can integrate / test this fix?

I tried to use the library from Github but I still get the "Invalid unit" errors.

mmakaay commented 2 years ago

If you are using the code from the PR that I mentioned, then possibly you are running into a different issue. Can you share the exact error message that you are getting, so this can be asserted?

mprokop commented 2 years ago

Thanks, I just used the library but not the PR for the component. After I changed the configuration it works, but I'm not able to the receive_timeout anymore.

Here is my configuration for reference.

esphome:
  name: $devicename
  platform: ESP32
  board: nodemcu-32s

  libraries:
    - https://github.com/glmnet/arduino-dsmr.git#master

external_components:
  - source: github://pr#2841
    components: [ dsmr ]

uart:
  id: uart_smart_meter
  rx_pin:
    number: GPIO16
    inverted: true
  baud_rate: 115200
  data_bits: 8
  parity: NONE
  stop_bits: 1
  rx_buffer_size: 3000

dsmr:
  uart_id: uart_smart_meter
  decryption_key: !secret smart_meter_GUEK
  max_telegram_length: 3000

sensor:
  - platform: dsmr
    energy_delivered_tariff1:
      id: energy_delivered_tariff1
      name: "${devicename}_energy_delivered_tariff1"
    power_delivered :
      id: power_delivered
      name: "${devicename}_power_delivered"
nagyrobi commented 2 years ago

Corresponding PR https://github.com/esphome/esphome/pull/2841 closed due to inactivity.

mmakaay commented 2 years ago

Reopened the issue. My change for the external Dsmr library was never incorporated, but the "Invalid unit" issue still stands. That's something that I want to fix through another route, dropping the external library.

friedheb commented 2 years ago

can confirm the invalid unit issue, here my output:

[21:24:46][E][dsmr:265]: 1-0:1.8.0(004329465*Wh)
                    ^
Invalid unit
mmakaay commented 2 years ago

Okay, that will be tackled.

maxodoble commented 2 years ago

any news on the status here?

@wieluk: do you have a working slimmelezer configuration for the Austrian T210 smartmeter you can share, or have infos on how to make it work for a esphome newbie?

thanks, Max

wieluk commented 2 years ago

Yea for me it is working right now. I don't know if the external Dsmr library from mmakaay is imported. I never updated to the most recent esphome version because for me it worked with adding his library manually.

My yaml looks like this right now.

substitutions:
  device_name: slimmelezerday
  device_description: "DIY P1 module to read your smart meter"

esphome:
  name: ${device_name}
  comment: "${device_description}"
  platform: ESP8266
  esp8266_restore_from_flash: true
  board: d1_mini
  name_add_mac_suffix: false

wifi:
  networks:
    - ssid: 'wifi'
      password: 'password'

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: ${device_name}
    password: 'password'
    ap_timeout: 15s

captive_portal:

logger:

api:

ota:

web_server:
  port: 80

uart:
  baud_rate: 115200
  rx_pin: D7

dsmr:
  decryption_key: #GUEK KEY

sensor:
  - platform: dsmr
    energy_delivered_lux:
      name: "Energy Consumed total_increasing"
      state_class: total_increasing
    energy_delivered_tariff1:
      name: "Energy Consumed total_increasing Tariff 1"
      state_class: total_increasing
    energy_delivered_tariff2:
      name: "Energy Consumed total_increasing Tariff 2"
      state_class: total_increasing
    power_delivered:
      name: "Power Consumed"
      #accuracy_decimals: 0
maxodoble commented 2 years ago

@wieluk:

Thanks, this is much appreciated

maxodoble commented 2 years ago

Hi,

i am getting bitten by this issue too with ESPHome 2022.8.3:

i am trying to get the readings from the slimmelezer for the austrian smartmeter.

decryption seems to work o.k, because i can see a correct reading in the log, but the dsmr component throws this error every 10 seconds, and i don't get any other sensor readings:

22:42:52 | [E] | [dsmr:265] | 1-0:1.8.0(001234567*Wh) ^ Invalid unit

Is there any workaround i could try to get this working until this issue get's fixed properly?

I tried to pull in the dsmr v0.6 (that version apparently seems to fix this problem, but esphome still uses dsmr v0.5 for whatever reasons there may be.) as external component, but that failed miserably, because i am a complete esphome newbie, and am a little lost here...

Any help here would be much appreciated.

Thanks, Max

maxodoble commented 2 years ago

Workaround: https://github.com/esphome/esphome/pull/3368/files

With a local ESP Dev Installation and using herbycheck/Dsmr@0.8.0 i am getting now the correct readings.

Would be nice though, if this issue would be fixed properly, so no workarounds are necessary anymore.

Thanks, Max

obstler42 commented 2 years ago

@maxodoble could you please describe how to include that fix into a local esphome installation (standard linux python commandline install)?

Edit:

Figured it out. Add the following section to your config.yaml file to include the herbycheck fix until it is in the official release:

external_components:
  # equivalent shorthand for GitHub
  - source: github://Herbycheck/esphome@dsmr-unit-fix
    components: [ dsmr ]
CodeMartn commented 1 year ago

Figured it out. Add the following section to your config.yaml file to include the herbycheck fix until it is in the official release:

external_components:
  # equivalent shorthand for GitHub
  - source: github://Herbycheck/esphome@dsmr-unit-fix
    components: [ dsmr ]

Thanks for sharing this.

derkrasseleo commented 1 year ago

I am also facing this issue with an Sagecom T210 and esphome. My provider is also e-netze (austria). I don't even get logs from dsmr tho, so I don't really know exactly goes wrong..

derkrasseleo commented 1 year ago

Is this fix still needed, or was it already merged in 0.8.0? No matter if I include the external component or not, I can't seem to get proper readings out of my Sagecom T210-D-r.

maxodoble commented 11 months ago

i don't think this fix should be needed anymore. but i'm not sure, as i m still using the old version, which works with this fix for now, so i don't touch it ;-)

derkrasseleo commented 11 months ago

I can confirm that esphome with dsmr works fine out of the box for Sagemcom T120D-R with the following configuration:

My mistake was, that I had dummy_receiver: true in my config, which somehow blocked dsmr from getting data. Also, only GUEK (Global Unicast Encryption Key) is sufficient, I still don't know what the second key (Global Authentication Key (GAK)) is for. So I think this issue can be closed, as I am pretty sure @wieluk and I have the same grid operator (e-netze)

esphome:
  name: smart-meter
  friendly_name: smart-meter

esp8266:
  board: d1_mini

# Enable logging
logger:
  baud_rate: 0
  # hardware_uart: UART0_SWAP
  level: VERBOSE # VERY_VERBOSE # DEBUG
  logs:
    homeassistant.components.dsmr: info
    # DSMR telegram parser library
    dsmr_parser: debug
    # And in case of a custom component to override the default dsmr integration:
    custom_components.dsmr: info

uart:
  id: uart_smart_meter
  rx_pin: 
    number: RX # D7
    inverted: true
  baud_rate: 115200 # 9600
  # data_bits: 8
  # parity: NONE #doesn't make a difference
  # stop_bits: 1
  # rx_buffer_size: 3000
  debug:
    direction: RX
    # dummy_receiver: true
    # after:
    #   delimiter: "\r\n"
    # sequence:
    #   - lambda: UARTDebug::log_string(direction, bytes);

# Enable Home Assistant API
api:
  encryption:
    key: "HPXVvrfejEIRNN9peuwqKk7o399RLaIo/U2ariAX3To="

ota:
  password: "af528ad48112c9d8a37b7e8d7901de61"

web_server:
  port: 80

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

captive_portal:

dsmr:
  uart_id: uart_smart_meter
  decryption_key: !secret decryption_key_GUEK
  request_interval: 10s

sensor:
  - platform: wifi_signal
    name: "wifi signal"
    update_interval: 10s
  - platform: dsmr
    # energy_delivered_lux:
    #   name: "Energy Consumed total_increasing"
    #   state_class: total_increasing
    # energy_returned_lux:
    #   name: "Energy Returned Lux"
    energy_delivered_tariff1:
      name: Energy Delivered Tariff 1
      state_class: total_increasing
      accuracy_decimals: 3
    energy_delivered_tariff2:
      name: Energy Delivered Tariff 2
      state_class: total_increasing
      accuracy_decimals: 3
    energy_returned_tariff1:
      name: Energy Returned Tariff 1
      accuracy_decimals: 3
    energy_returned_tariff2:
      name: Energy Returned Tariff 2
      accuracy_decimals: 3
    power_delivered:
      name: Power Consumed
      accuracy_decimals: 3
    power_returned:
      name: Power Returned
      accuracy_decimals: 3

text_sensor:
  - platform: dsmr
    identification:
      name: "DSMR Identification"
    timestamp:
      name: "DSMR Timestamp"
    electricity_tariff:
      name: "DSMR Tarif"

On the hardware side I just connected the 5V supply of he P1 Port to the request pin and the 5V pin of the esp, Data pin to RX (or D7, doesn't matter). No resistor or anything else needed..

Trainerr commented 3 months ago

Hi, i also had a Sagecom T210-D-r with P1 port from "Städtische Betriebe" in styria. I also got the GAK and GUEK key. When i use your @derkrasseleo code, i didn't got any value. Do you have any hints?

derkrasseleo commented 3 months ago

Do you have any hints?

I use the exact config I posted and it works for "Energie Steiermark". Do you not get any UART output at all? If not, it's probably have a hardware problem..

Here's the output I get:

``` 13:14:57][V][dsmr:199]: Start byte 0xDB of encrypted telegram found [13:14:57][V][dsmr:219]: Encrypted telegram length: 511 bytes [13:14:57][D][uart_debug:114]: <<< DB:08:53:41:47:35:00:06:CA:D0:82:01:F2:30:00:2A:D0:54:FF:BC:F4:0B:43:F9:40:E0:6F:3B:94:5C:20:A8:AA:C1:32:7C:39:B4:23:87:F3:8A:C9:EB:D9:AF:D3:9E:75:69:4D:9C:73:1D:33:94:0B:A6:8D:D1:AB:80:80:B4:80:00:21:0B:86:42:CB:A4:9C:79:82:90:6F:37:ED:F3:6F:BF:92:50:5C:7A:76:B8:F9:A0:91:11:E7:87:7D:57:E5:16:E6:18:C5:4F:66:69:0B:70:EB:8A:05:B7:79:5B:C2:9C:00:5E:39:15:7B:BA:34:67:ED:34:49:E5:06:56:6E:B3:73:95:B6:6D:FE:98:86:06:C4:5E:E6:47:46:F2:63:DB:2B:5A:C0:69 [13:14:57][D][uart_debug:114]: <<< 99:C9:BE:8B:BF:3A:46:50:ED:52:E1:F7:D5:2E:E2:CD:82:77:64:23:62:B6:39:61:76:E2:F7:9C:22:A6:3F:A7:CE:F1:7B:9E:84:06:4E:08:BF:9F:91:26:CF:4E:4C:E6:4D:B7:B8:D8:A8:FF:79:1D:73:6C:90:A1:F2:43:04:73:80:B4:9B:EE:0D:68:78:74:A4:A1:51:06:C4:56:42:AA:8F:4D:41:55:9A:A1:60:ED:D2:C8:1F:CE:9C:B3:4A:AF:F9:0A:79:3D:02:9A:D4:31:AB:50:25:EE:C8:25:92:3C:3A:2B:71:C3:0B:B3:A2:93:AB:E4:B2:28:9F:C2:06:61:9A:18:17:32:E7:5F:AD:C4:5D:90:6E:FB:06:0E:50:D2:34:63:F9:AA:17:33 [13:14:57][D][uart_debug:114]: <<< 12:E4:B2:72:48:31:9E:97:BD:B0:0F:49:53:59:6F:80:B1:67:E5:D6:A4:8D:43:75:82:C1:D6:64:42:9B:9A:4D:E2:6E:74:0D:4C:0A:2B:36:D8:89:6E:23:C8:6D:CE:98:CF:4B:03:D1:ED:5E:AA:61:68:48:15:35:11:F7:FB:0A:88:99:A0:9D:40:23:63:95:F8:DF:24:D6:D2:D3:D5:08:00:8B:17:D6:F0:3D:95:DD:82:4D:EB:9B:48:26:F6:73:84:9E:6A:3A:D0:1B:94:F8:58:98:DF:82:CA:4A:1B:68:DD:E6:1A:78:99:72:C7:2C:8A:B4:9E:0B:BA:4B:66:A2:97:5C:FE:2B:02:96:8C:C0:C4:23:62:5A:21:21:5E:52:F0:1D:D3:AD:3A:EF [13:14:57][V][dsmr:226]: End of encrypted telegram found [13:14:57][V][dsmr:245]: Decrypted telegram size: 494 bytes [13:14:57][V][dsmr:257]: Trying to parse telegram [13:14:57][V][dsmr:118]: Stop reading data from P1 port [13:14:57][V][sensor:043]: 'Energy Delivered Tariff 1': Received new state 6866.068848 [13:14:57][D][sensor:093]: 'Energy Delivered Tariff 1': Sending state 6866.06885 kWh with 3 decimals of accuracy [13:14:57][V][sensor:043]: 'Energy Delivered Tariff 2': Received new state 2876.811035 [13:14:57][D][sensor:093]: 'Energy Delivered Tariff 2': Sending state 2876.81104 kWh with 3 decimals of accuracy [13:14:57][V][sensor:043]: 'Energy Returned Tariff 1': Received new state 2259.080078 [13:14:57][D][sensor:093]: 'Energy Returned Tariff 1': Sending state 2259.08008 kWh with 3 decimals of accuracy [13:14:57][V][sensor:043]: 'Energy Returned Tariff 2': Received new state 0.061000 [13:14:57][D][sensor:093]: 'Energy Returned Tariff 2': Sending state 0.06100 kWh with 3 decimals of accuracy [13:14:57][V][sensor:043]: 'Power Consumed': Received new state 2.437000 [13:14:57][D][sensor:093]: 'Power Consumed': Sending state 2.43700 kW with 3 decimals of accuracy [13:14:57][V][sensor:043]: 'Power Returned': Received new state 0.000000 [13:14:57][D][sensor:093]: 'Power Returned': Sending state 0.00000 kW with 3 decimals of accuracy [13:14:57][V][text_sensor:013]: 'DSMR Identification': Received new state EST5\253717584_A [13:14:57][D][text_sensor:064]: 'DSMR Identification': Sending state 'EST5\253717584_A' [13:14:57][V][text_sensor:013]: 'DSMR Timestamp': Received new state 240703131458S [13:14:57][D][text_sensor:064]: 'DSMR Timestamp': Sending state '240703131458S' ```

derkrasseleo commented 3 months ago

I've created a repo with my findings, maybe this is helpful: https://github.com/derkrasseleo/esphome-p1dsmr/ Let me know if it works for you!

fabian-st commented 1 month ago

Has anyone found a solution to this issue so far? I'd also like to use the SlimmeLezer+ with a KNG/Siemens Smart Meter.

derkrasseleo commented 1 month ago

Has anyone found a solution to this issue so far? I'd also like to use the SlimmeLezer+ with a KNG/Siemens Smart Meter.

What exactly is your problem? Does it have two keys? Have you tried decryption_key: !secret decryption_key_GUEK ? I do not use the "GAK" and it works fine. Another problem for me was that the RX Pin was inverted.