Elgama Gama-350 i port P1

Posiadam licznik Elgama 350 i jedynie P1 jest tak dostępny.
Stoen Operator twierdzi, że nie będą mieć już więcej liczników z WMBUS, jedynie P1.
“Wszystkie obecnie nasze liczniki posiadają tylko interfejs odczytowy P1.
Nie będziemy mieli już żadnych liczników z WMBUS.”
Więc walczę z P1, dostałem od nich te dwa klucze, z którymi nie wiem co zrobić. ESP32 nie czyta żadnych sensownych danych z portu P1, więc pewnie będę musiał podłączyć się bezpośrednio i wtedy zobaczę, co tam na drucie lata.

Zakładam, że masz dokumentację do tego licznika? Warto podzielić się tymi informacjami.

Nik z nas nie wiem co jest podłączone do portu P1 i jak skonfigurowany jest “ESP32” do odczytu z tego portu.

I have posted this answer before, but have not received any feedback on, but you need something like this:

@macek or @szopen,

This two topic likely could be merged:

The Gama 150 is the single phase meter, meanwhile the 350 is the 3 phase meter.

Regarding the access to the port - I believe Stoen will change plastic cover to give you access to P1 port on request.
ESP32:
I’m using esphome, 5 V from the meter, grounds connected, RTS pulled high, 10K resistor between 3V3 and Rx.
Unfortunately I do not have any manuals on this device. :frowning:
Code I’m using on ESP32:

esphome:
  name: esp-p1reader
  platform: ESP32
  board: nodemcu-32s

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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "esp-p1reader"
    password: !secret fallback_password

captive_portal:

mqtt:
  broker: 192.168.0.172
  username: user
  password: !secret mqtt_passwd
  topic_prefix: esp32_p1meter
  birth_message:
    topic: myavailability/topic
    payload: online
  will_message:
    topic: myavailability/topic
    payload: offline

uart:
  id: uart_bus
  rx_pin: 
    number: GPIO16
    inverted: true
  baud_rate: 115200
  rx_buffer_size: 1700
  debug:
    direction: RX
    after:
      delimiter: "\r\n"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);
# Enable logging
logger:
  level: DEBUG  # Logging costs performnce, swithc to DEBUG when needed
  baud_rate: 0 # disable logging over uart (would use up a HW uart)
  
# Enable Home Assistant API
api:
  encryption:
    key: !secret encryption_key
    
ota:
  password: !secret ota_password
  platform: esphome
# Example configuration entry
dsmr:
  uart_id: uart_bus
  decryption_key: !secret decryption_key

sensor:
  - platform: dsmr
    energy_delivered_tariff1:
      name: Energy Consumed Tariff 1
    power_delivered:
      name: Power Delivered

That is not going to work with these meters.

They are all encrypted, they use DLMS/COSEM and HDLC usually for communication. They are not the non-encrypted DSMR protocol.

You need to have a decryption key.

I cannot remember the wiring but likely you did your research already. If you did the wiring as for P1 ports you should be right. Request should be pulled high (5V as I remember), otherwise you are just receiving as the meter should just send the data.

My suggestion is still the same, to try the linked amsmeter firmware to read the device:

Quick question, RJ11 or RJ45 port is on the meter? Can you share a picture how is it?

I guess you followed this for wiring or something similar:

Otherwise, I would try this:

Meter has RJ12 port - 6P6C with 5V able to sustain ESP32.
I have found your suggestion about amsreader and installed it, now I am trying different serial combinations to find out what is going on.
I’ve just contacted guys from homewizard - we’ll see the outcome.

I’ve installed amsreader, I have the decryption keys from Stoen:

Klucz AK: bexxxxxxxxxxxxxxxxxxxxxxxxxxxxda
Klucz EK: 98xxxxxxxxxxxxxxxxxxxxxxxxxxxx7f

I assume EK is for Encryption Key and AK for Authentication Key. Now I’m down to trying all possible configurations of baud rates and other stuff.

If AK is for Authentication Key, and you need to Authenticate, then you might be screwed… (my honest opinion…) BUT, maybe I am mistaken.

amsreader has authentication option, but to understand complexity: [v2.2.21] CGM decryption fails, if auth tag is present in the encrypted DLMS APDU, but no auth key is available · Issue #720 · UtilitechAS/amsreader-firmware · GitHub

You need this setting:

And as I remember there is a debugging option on the settings page.

This setting is not producing any sensible results.


Unchecking “inverted” only changes the error to “HAN: Unknown data received, check meter config”

Its GPIO16 in case anyone is concerned. :slight_smile:

Try debugging and see the messages, then you can try this as well:

And try to increase the buffer size maybe:

if you have not seen my previous message edit, try to increase the buffer size.

I tested various buffer sizes. I do not see any debug options in 2.3.9 version. “HAN: Footer checksum error”

Try to read this topic through:

Likely you have some similar issue.

Otherwise to have the debug option you need to add this:

to here (or whichever env you are using with your ESP32, basically -D AMS_REMOTE_DEBUG=1 is missing in your config) and reflash…

I don’t understand why that was omitted…

I may understand this - adding this parameter causes ESP bootloop.

Which version of ESP32 do you have? Which part are you using to compile?

It shouldn’t end in a bootloop. You should try v2.3.6. From v2.3.7 it was removed.

Does it bootloop when you power it from USB?

I have generic allegro ESP-32S version with ESP32-WROOM or something similar.
I installed Visual Studio Code, I installed PlatformIO addon, I cloned git repo, on default is compiles and it works flawlessly, If I add " -D AMS_REMOTE_DEBUG=1" it goes into bootloop after flashing. There is a possibility I need to flash all .bins, not only firmware. This is a problem for future me. :wink:
And yes - it bootloops if powered from USB.
I am escalating communication issue here: Stoen Operator meter Elgama Gama 350 G35 - Poland · UtilitechAS/amsreader-firmware · Discussion #883

1 Like