So, nachdem ich lange herumgetestet habe hier mal mein Ergebnis bis jetzt.
Ich habe herausgefunden, dass der Optokopf bei mir ttyUSB1 ist, da die Abfrage mittels:
ergab, dass ID_SERIAL_SHORT=AB0JEXXX existiert und die Seriennummer des Optokopfes wohl AB0JEXXX ist.
ergab, dass das dann wohl der SDM630 ist: ID_SERIAL=1a86_USB2.0-Serial
Es scheint wichtig zu sein in welchem USB-Port die Dinger stecken, denn in manchen Konstellationen habe ich in der
/var/log/vzlogger.log timeouts und komische Werte gehabt.
Code: Alles auswählen
[Aug 24 10:25:45][d0] nothing received for more than 20 seconds
[Aug 24 10:25:45][d0] read timed out!, context: 0, bytes read: 0, last byte 0x0
Code: Alles auswählen
[Aug 24 10:15:24][d0] Something unexpected happened: read:732!
[Aug 24 10:15:44][d0] Something unexpected happened: read:732!
Nach jedem Umstecken nicht vergessen die korrekte /dev/ttyUSBx zu ermitteln und in beiden Konfigurationen zu ändern.
Bei mir ist der IR Optokopf auch ca. 20m entfernt vom Raspi und mittels
USB 2.0 to RJ45 Network Extension angebunden.
Meine /etc/vzlogger.conf für den
Weidmann Elektronik Stromzähler, Smart Meter IR (Infrarot) Schreib/Lesekopf USB (Optokopf) bisher:
Code: Alles auswählen
{
"retry": 0,
"daemon": true,
"verbosity": 1,
"log": "/var/log/vzlogger.log",
"local": {
"enabled": true,
"port": 8080,
"index": true,
"timeout": 20,
"buffer": -1
},
"meters": [
{
"enabled": true,
"allowskip": false,
"interval": 15, // -1,
"aggtime": -1,
"aggfixedinterval": false,
"channels": [
{
"api": "null", // middleware api, default volkszaehler
"uuid": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeee1",
"middleware": "http://localhost/middleware.php",
"identifier": "1-0:16.7.0", /* Leistung */
}, {
"api": "null", // middleware api, default volkszaehler
"uuid": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeee2",
"middleware": "http://localhost/middleware.php",
"identifier": "1-0:1.8.0", /* Wirkarbeit Bezug +A */
}, {
"api": "null", // middleware api, default volkszaehler
"uuid": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeee3",
"middleware": "http://localhost/middleware.php",
"identifier": "1-0:2.8.0", /* Wirkarbeit Lieferung -A */
}
// {
// "uuid": "fde8f1d0-c5d0-11e0-856e-f9e4360ced10",
// "identifier": "1-0:1.8.0",
// "api": "volkszaehler",
// "middleware": "http://localhost/middleware.php",
// "aggmode": "none",
// "duplicates": 0
// }
],
"protocol": "d0",
// "protocol": "sml",
"device": "/dev/ttyUSB1",
"pullseq": "2F3F210D0A",
// "ackseq": "063035300d0a",
"baudrate": 300,
"baudrate_read": 9600,
"parity": "7e1",
"wait_sync": "off",
"read_timeout": 20,
"baudrate_change_delay": 0
}
]
}
hatte den Zähler total verwirrt...
Interessant ist aber, dass beim Aufruf von
sich der Wert von aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeee2 nicht zu ändern scheint.
beim Einspeisen sehe ich Veränderung.
...
......... jetzt beim schreiben fällt mir auch der Grund auf...

Natürlich ändert sich der Zählersand für den BEZUG nicht wenn er gerade EINSPEIST.
Ok, somit bleibt mir nur noch ein Problem... Mein Zähler liefert kein OBIS 16.7.0 (momentane Wirkleistung)...
Da muss ich mal beim Versorger nachhaken ob ich den irgendwie herauspopeln kann.
klappt leider auch nicht um zumindest EVU Einspeisung an zu zeigen.
PV Erzeugung holt er sich schon zuverlässig vom
Kostal Piko alt
Edit: das fällt mir ein dass gestern die Daten vom SDM630 überhaupt nicht angekommen sind. Ob das nach der heutigen Arbeit klappt weiß ich aber erst wenn meine Frau vom Dienst erscheint.