Digimeto GS303 - D0 Schnittstelle auslesen - timeout [gelöst]

Ich habe zwei Digimeto GS303 (Bezugs- und Erzeugungszähler).

Bedienungsanleitung:

• GS303
• 190811_Produktinformation_EFR_SGM_DD_DE_WEB.pdf
• DIGImeto_efr_SGM-DD_Bedienungsanleitung_lang_Web.pdf

Heute habe ich mir erst einmal für einen die Freischalt-PIN per Telefon besorgt (den zweiten konnten sie in ihrer Datenbank nicht finden und sind auf der Suche..).

Dazu habe ich folgende Hardware:

• Raspberry Pi Zero WH
• Ethernet / USB HUB HAT für Raspberry Pi Zero, 1x RJ45, 3x USB
• SanDisk Extreme micro SDHC A1 UHS-I U3 Speicherkarte + Adapter 32GB
• 2x IR-USB-Lesekopf mit cp2102 ftdi von Hichi hier aus dem Forum

Konfiguration:

• vzlogger image installiert
• Guide: vzlogger mit unbekanntem eHz
• Genereller Guide: https://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf-usb-ausgang

Digimeto ist auf D0 eingestellt, SML geht aber auch (noch nicht getestet).

Bei dem generellen Guide kam ich bei minicom bzw. stty nicht weiter, daher habe ich dann die Schritte

von vzlogger mit unbekanntem eHz abgearbeitet.

Leider bekomme ich keine Ausgabe, weder für pull, noch für push mode, sowohl für

/dev/lesekopf0 als auch /dev/lesekopf0.

Bei push mode erscheint gar keine <<, bei pull mode lediglich:

##### 98.495674000s (     0 ms) opened
##### 98.512027000s (    17 ms) read
##### 98.512113000s (     0 ms) TCIOFLUSH and cfsetiospeed
<<<<< 98.512320000s (     0 ms)
2f 3f 21 0d 0a                                    /?!

##### 13.647120000s ( 15135 ms) timeout!
##### 13.650475000s (     3 ms) closed

.. wobei die Zeile 2f 3f 21 0d 0a m.E. die Pull Anfrage vom vzlogger ist, keine Antwort vom Digimeto.

Laut Handbuch sollte die Schnittstelle den Standard-Konfigs entsprechen:

Zitat

Beschreibung der Schnittstelle:

- Protokoll nach IEC 62056-21

- Einstellungen:

- 7 Datenbits, Parität even, 1 Stopbit

- Startbaudrate: 300 Bd

- Kommunikationsbaudrate: 9600 Bd

Kommunikationsaufbau:

Befehlskette:

Komm: 300,7,E,1

Send: /?!<CR><LF>

Recv: / [Herstellerkennung] <CR><LF>

Send: <ACK>050<CR><LF>

Komm: 9600,7,E,1

Recv: <STX>0-1:97.97.0*255(0) <CR><LF>

…

weiterer Datenempfang

…

Recv: ! <CR><LF>

Recv: <ETX><NAK> Soll: <NAK>

Kommunikation wird beendet

Übertragen werden u. a.:

0.1.2 bis zu 15 Vorwert-Speicherzeitpunkte

1.8.0 aktuell sowie bis zu 15 Vorwerte

1.8.1 aktuell sowie bis zu 15 Vorwerte

1.8.2 aktuell sowie bis zu 15 Vorwerte

2.8.0 aktuell sowie bis zu 15 Vorwerte

2.8.1 aktuell sowie bis zu 15 Vorwerte

2.8.2 aktuell sowie bis zu 15 Vorwerte

aber KEINE Leistungsangaben

Alles anzeigen

bzw. im GS303 Handbuch steht noch etwas, dass die D0-Schnittstellen-Abfrage die PIN benötigt:

Zitat

Diese Schnittstelle ist in 2 Modi betreibbar:

- D0-Dialogschnittstelle nach DIN IEC 62056-21 zur Auslesung von Tageszählerstandszeitreihen

(durch Ihre PIN-geschützt)

Kommunikations-Einstellungen: 7 Datenbits, Parität=even, 1 Stoppbit , Auto-Mode

C mit Anfangsbaudrate 300, Kommunikation bis 9600 Bd.

- DSS-Infoschnittstelle nach E IEC

Alles anzeigen

.. aber wie übermittle ich die PIN in der vzlogger.conf?

Gibt es noch weitere Tipps, wie ich die Suche fortführen kann?

Ok, nun auch mit SML Schnittstelle getestet.

• Einstellung am Digimeto von D0 auf SML gewechselt
• vzlogger.conf:

{
  "retry": 0,
  "daemon": false,
  "verbosity": 15,
  "log": "/home/pi/vzlogger.log",
  "local": {
    "enabled": false,
    "port": 8080,
    "index": false,
    "timeout": 0,
    "buffer": 0
  },
  "meters": [
    {
      "enabled": true,
      "allowskip": false,
      "protocol": "sml",
      "device": "/dev/lesekopf0",
      "dump_file": "/home/pi/vzlogger.txt",
      "baudrate": 9600,
      "parity": "8n1",
      "read_timeout": 60
    }
  ]
}

• sudo vzlogger -c /home/pi/vzlogger.conf
• cat /home/pi/vzlogger.txt:

##### 92.177367000s (     0 ms) opened
##### 92.193998000s (    16 ms) read
##### 57.724042000s ( 65531 ms) timeout!
##### 57.727581000s (     3 ms) closed

##### 22.852024000s (     0 ms) opened
##### 22.867693000s (    15 ms) read
##### 83.325660000s ( 60458 ms) timeout!
##### 83.329174000s (     4 ms) closed

Merkwürdig, weil ja SML ziemlich eindeutige Sprache ist und explizit im Handbuch erwähnt wird, dass Daten unverschlüsselt übertragen werden.

Nun kann ich nur noch vermuten, dass es am Lesekopf liegt bzw. an den USB-Anschlüssen. Beide sind ordentlich aufgelistet und erkannt:

ls -la /dev/lese*
> lrwxrwxrwx 1 root root 7 Mar 17 18:38 /dev/lesekopf0 -> ttyUSB0
> lrwxrwxrwx 1 root root 7 Mar 17 18:38 /dev/lesekopf1 -> ttyUSB1
ls -l /dev/serial/{by-path,by-id}/*
> lrwxrwxrwx 1 root root 13 Mar 17 18:16 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0074-if00-port0 -> ../../ttyUSB0
> lrwxrwxrwx 1 root root 13 Mar 17 18:16 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0075-if00-port0 -> ../../ttyUSB1
> lrwxrwxrwx 1 root root 13 Mar 17 18:16 /dev/serial/by-path/platform-20980000.usb-usb-0:1.1:1.0-port0 -> ../../ttyUSB0
> lrwxrwxrwx 1 root root 13 Mar 17 18:16 /dev/serial/by-path/platform-20980000.usb-usb-0:1.2:1.0-port0 -> ../../ttyUSB1

Jetzt hat die Infrarot-Ausgabe vom Digimeto drei Leuchten, der IR-Lesekopf aber nur zwei. Spielt es eine Rolle, welche der drei ich auslese? Ich habe ihn einfach horizontal angebracht (die obene Leuchte ist daher nicht genutzt).

Bei..

sudo cat /dev/lesekopf1
sudo cat /dev/lesekopf0

.. kommt jeweils auch gar keine Ausgabe.

Ich habe mit einer Digitalkamera getestet, und von den drei Leuchten blinkt die untere Rechte:

    *

*      [*]

Alles klar, hat sich erledigt: Der IR-Lesekopf zeigte auf die zwei falschen Leuchten. Nun gibt er korrekt aus:

Zitat

[Mar 18 11:35:32][mtr0] Reading: id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*255 value=934264.40 ts=4753766000

[Mar 18 11:35:32][mtr0] Reading: id=1-0:1.8.1*255/ObisIdentifier:1-0:1.8.1*255 value=607810.80 ts=4753766000

[Mar 18 11:35:32][mtr0] Reading: id=1-0:1.8.2*255/ObisIdentifier:1-0:1.8.2*255 value=326453.60 ts=4753766000

[Mar 18 11:35:32][mtr0] Reading: id=1-0:2.8.0*255/ObisIdentifier:1-0:2.8.0*255 value=1572856.80 ts=4753766000

[Mar 18 11:35:32][mtr0] Reading: id=1-0:2.8.1*255/ObisIdentifier:1-0:2.8.1*255 value=1572856.80 ts=4753766000

[Mar 18 11:35:32][mtr0] Reading: id=1-0:2.8.2*255/ObisIdentifier:1-0:2.8.2*255 value=0.00 ts=4753766000

[Mar 18 11:35:32][mtr0] Reading: id=1-0:16.7.0*255/ObisIdentifier:1-0:16.7.0*255 value=-2030.00 ts=1616063732108

Alles anzeigen

Ein weiterer Punkt, den ich im Anschluss noch herausgefunden habe:

Ich musste vzlogger von 0.70 auf 0.80 aktualisieren, damit Werte in den Log-Dateien erscheinen.

Siehe hier für eine Beschreibung des Updates und hier für eine Beschreibung des Problems.

libsml/vzlogger update ging problemlos, aber composer update lief nicht durch (ohnehin nur middleware/LAMP stack).

Also erst, Vorbereitung nach Anleitung:

cd /home/pi/
# ggf.Datensicherung
cp -r volkszaehler.org vz.org.bak
# Update
cd volkszaehler.org
git stash
git pull
git stash apply

Dann bei:

# Abhängigkeiten aktualisieren
sudo composer update

Dauerte es eine Stunde, bis der Prozess abbrach (Freeze oder Frozen/Abort.. genaue Meldung habe ich nicht mehr im Kopf).

Werde das bei Gelegenheit nochmal neu testen. Da ich aber ohnehin per MQTT an Solaranzeige / influxdb pushen möchte, ist die Middleware doch gar nicht so wichtig, oder?

Danke für die Antwort. Die Anlage ist an einer remote location, deswegen würde ich jetzt nur ungern über ssh/ipsec das update nochmal durchführen, falls etwas schiefgeht. Ich reicht das aber nach. Vielleicht war es nur ein einmalies Problem. In der Fehlermeldung kam "Process" und "kill" vor - als ob das System nach einer Stunde tiefschlaf entschieden hat, dass der Prozess genug Zeit hatte.