[vz-users] EasyMeter Q3BA1122/vzlogger - IR funktioniert, in log oder DB kommt nichts an

applicationMGR ecoCuyo applicationMGR at ecoCuyo.de
Thu Mar 23 10:42:57 CET 2017 

Hallo Frank, hallo Kollegen,

Ihr seid schneller als ich testen und wieder schreiben kann- DANKE für Eure Hilfe!!!

Ja, ist gesichert mit ps und pgrep etc. Da läuft keine Instanz im Hintergrund. Nutze zum Testen den vzlogger nur im Vordergrund (kein Daemon), weil’s einfacher abzuwürgen und neu zu starten ist.

Interessant ist nur, dass sich heute morgen beim ersten xxd ein anderes Bild ergab: die Daten „tröpfeln“ nur noch herein und es sind keine „ESYQ3“-Fetzen mehr zu sehen, die den Easymeter-Zähler identifizeiren:

$ xxd </dev/ttyUSB0
0000000: 0077 611a 5408 0047 4e78 4e5f 7700 771e  .wa.T..GNxN_w.w.
0000010: 7644 4640 462a 6417 4454 7f00 0311 4110  vDF at F*d.DT....A.
0000020: 2804 0040 1062 0445 7f00 6331 6773 4800  (.. at .b.E..c1gsH.
0000030: 2400 2446 0444 7f00 6331 6773 4000 2c00  $.$F.D..c1gs at .,.
0000040: 2406 0401 7f00 2311 4110 6c73 356e 6617  $.....#.A.ls5nf.
0000050: 4444 0023 1141 106c 7335 6e64 0704 457f  DD.#.A.ls5nd..E.
0000060: 0057 3167 7300 0000 4024 0404 4400 6348  .W1gs...@$..D.cH
0000070: 6773 4800 2400 2446 0445 7f00 6348 6773  gsH.$.$F.E..cHgs
0000080: 4000 2400 2446 0444 0063 4867 7348 0024  @.$.$F.D.cHgsH.$
0000090: 0024 4604 457f 0043 4867 7348 002c 0004  .$F.E..CHgsH.,..
00000a0: 0404 2000 736d 7968 1400 4277 402b 6074  .. .smyh..Bw at +`t
00000b0: 0063 2d67 7348 0024 0024 4644 4400 632d  .c-gsH.$.$FDD.c-
00000c0: 6773 4800 2c00 2446 4445 0043 2d67 7340  gsH.,.$FDE.C-gs@
00000d0: 002c 0024 4604 447f 2003 2d05 5261 183c  .,.$F.D. .-.Ra.<
00000e0: 4024 4644 557f 0053 1240 020b 2000 3548  @$FDU..S. at .. .5H
00000f0: 7908 1100 6348 6773 4000 2400 2446 0445  y...cHgs at .$.$F.E
0000100: 7f00 5335 6773 4800 0040 0404 4746 7f00  ..S5gsH.. at ..GF..
0000110: 576d 4128 1600 0015 006b 6000 0043 4867  WmA(.....k`..CHg
0000120: 7348 183c 4024 4644 547f 0043 4867 7348  sH.<@$FDT..CHgsH
0000130: 183c 4404 4644 5500 6320 6733 4800 2400  .<D.FDU.c g3H.$.
0000140: 2446 0400 0003 2040 102c 0440 0800 0004  $F.... @.,. at ....
0000150: 4500 0320 0010 2c04 0040 0002 040f 7f40  E.. ..,.. at .....@
0000160: 5761 1a54 4246 7348 2830 2668 0063 201a  Wa.TBFsH(0&h.c .
0000170: 5405 5f62 1844 7506 5200 6320 1a54 0000  T._b.Du.R.c .T..
0000180: 474e 784e 166e 0043 4867 7348 0024 0004  GNxN.n.CHgsH.$..
0000190: 4604 447f 0043 4867 7348 0024 0004 4604  F.D..CHgsH.$..F.
00001a0: 457f 0063 4867 7348 0024 0004 4644 547f  E..cHgsH.$..FDT.
00001b0: 0077 6d2e 5e16 0042 7750 2b40 0000 2308  .wm.^..BwP+ at ..#.
00001c0: 0510 6c73 402a 2007 0400 0043 2d67 7348  ..ls@* ....C-gsH
00001d0: 0024 0024 4604 4500 232d 0550 6118 0040  .$.$F.E.#-.Pa..@
00001e0: 2446 4714 4057 6d79 6c74 2842 7740 2b40  $FG. at Wmylt(Bw at +@
00001f0: 6d00 632d 6773 4000 2400 2446 0444 7f00  m.c-gs at .$.$F.D..
0000200: 232d 6773 4018 3c40 2446 4455 0077 2d67  #-gs at .<@$FDU.w-g

Wird wohl daran liegen, dass ich gestern Abend noch mit Parametern eines D0-Zählers experimentierte (mal so, mal so hin und her gespielt):

        "enabled" : true,
        "protocol" : "d0",                      // or "oms","sml", see http://volkszaehler.github.io/vzlogger/ to try other options
        "device" : "/dev/usb-ir-lesekopf0",
        "parity": "8n1",                        // or 7e1
        "pullseq": "2f3f210d0a",                // Pull sequence in 'hex' -> ASCII 2F=“/“, 3F=“?”, 21=“!”, 0x0D=“CR” und 0x0A=“LF”
//      „pullseq": "1b1b1b1b010101017603303062006200726500000100770101093131333131383632010101016303360076033031620062007265000007007501010101016314cb007603303262006200726500000200710163756d0000001b1b1b1b1a027241",

//      "ackseq": "auto",                       // optional (default: keine Antwortsequenz auf Zaehlerantwort) kann entweder feste hex-Sequenz sein (z.B. 063035310d0a für
                                                // mode C mit 9600bd oder 063030300d0a = 300bd) oder kann auf "auto" gesetzt werden, damit die Sequenz autom. berechnet
                                                // wird und autom. auf die max. Baudrate umgeschaltet wird (baudrate_read wird dann ignoriert)
        "ackseq": "063035300d0a",               // acknowledge intitially with standard baudrate 0f 300 baud
        "baudrate": 300,                        // default baudrate of meter
        "read_timeout": 10,                     // optional, default 10s. Timeout value in secs between single bytes received from device
        "baudrate_change_delay": 400,           // optional, default none. Delay value in ms after ACKSEQ send before baudrate change
        "baudrate_read": 9600,                  // Baudratenumschaltung auf gewünschte Baudrate, abhängig von Zählerantwort

Habe ich die Baudrate womöglich die Baudrate auf 300 verstellt!?

Dann habe ich erneut die PullSequenz für den Zählertyp Q3C abgefeuert:

        "enabled": true,
        "allowskip": false,
        "interval": -1,
        "aggtime": -1,
        "aggfixedinterval": false,
        "protocol": "sml",
        "device" : "/dev/usb-ir-lesekopf0",
        "pullseq": "1b1b1b1b010101017603303062006200726500000100770101093131333131383632010101016303360076033031620062007265000007007501010101016314cb007603303262006200726500000200710163756d0000001b1b1b1b1a027241",
        "baudrate": 9600,
        "parity": "8n1",                        // or 7e1


Und schwups, liefert xxd wieder in alter Hektik (gefühlt 9600 Baud):
$ xxd </dev/ttyUSB0
0000000: a3a3 a3a3 0101 0176 05a2 d539 7862 0062  .......v...9xb.b
0000010: 0072 6500 0001 0176 0101 0745 5359 5133  .re....v...ESYQ3
0000020: 420b 0901 4553 5911 039b d867 0101 63b1  B...ESY....g..c.
0000030: 8100 7605 a2d5 3979 6200 6200 7265 0000  ..v...9yb.b.re..
0000040: 0701 7701 0b09 0145 5359 1103 9bd8 6701  ..w....ESY....g.
0000050: 7262 0165 006e b88e 7c77 0781 81c7 8203  rb.e.n..|w......
0000060: ff01 0101 0104 4553 5901 7707 0100 0108  ......ESY.w.....
0000070: 00ff 0101 621e 52fc 6900 0000 0632 f563  ....b.R.i....2.c

Also wirkungslos scheint die pulseq auf der bidirektionalen Schnittstelle nicht zu sein. Ich verstehe nur noch nicht, warum vzlogger nicht parsen mag, denn der Auszug von xxd ist sehr gut Vergleichbar mit dem HEX-Output eines EMH-Zählers; auch da erkennt das geschulte Auge in xxd die Sequenz der Herstellerkennung das frisst der vzlogger anstandslos. Mir drängt sich eher der Verdacht auf, dass es am vzlogger selbst liegt?

Beispiel EMH:
$ xxd</dev/usb-ir-lesekopf0
0000000: 1b1b 1b1b 0101 0101 7607 0022 0262 67ee  ........v..".bg.
0000010: 6200 6200 7263 0101 7601 0107 0022 09ff  b.b.rc..v...."..
0000020: 77fa 0908 058a c12d 4c4f e401 0163 1ea9  w......-LO...c..
0000030: 0076 0700 2202 6267 ef62 0062 0072 6307  .v..".bg.b.b.rc.
0000040: 0177 0109 0805 8ac1 2d4c 4fe4 0172 6201  .w......-LO..rb.
0000050: 6509 ff04 2a76 7707 8181 c782 03ff 0101  e...*vw.........
0000060: 0101 0445 4d48 0177 0701 0000 0009 ff01  ...EMH.w

Hat zufällig jemand eine Übersicht/Doku, welche AT-Commands der Zähler Easymeter Q3BAxxxx annimmt und was diese bewirken?

Werde inzwischen weiter forschen :-)

Beste Grüße
Armin

> Am 23.03.2017 um 10:11 schrieb Frank Richter <frank.richter83 at gmail.com>:
> 
> Hallo Armin,
> 
> eigentlich sollte deine Config ok sein für SML.
> Kannst du ausschließen, dass da im Hintergrund ein weiterer vzlogger-Prozess läuft (durch Service gestartet?), der jetzt Ärger macht?
> 
> Grüße
> Frank
> 
> Am 23.03.2017 09:29 schrieb "applicationMGR ecoCuyo" <applicationMGR at ecocuyo.de <mailto:applicationMGR at ecocuyo.de>>:
> Hallo Udo, hallo Malte
> 
> 
> in der Bedienungsanleitung des Q3B steht unter Technische Ausführung folgendes:
> Bidirektionale Infrarot-Datenschnittstelle (MSB)/Unidirektionale Info-Schnittstelle: D0 (gemäß DIN EN 62056-21 und 62056-61)
> Datenprotokoll: SML 1.03
> <PastedGraphic-2.png>
> 
> Und die Schnittstelle oben am Zähler (Pos 2), die ich per Halteblech und Deinem IR-Lesekopf nutze, ist so beschrieben:
> Bidirektionale Infrarot-Datenschnittstelle (MSB) zum Datenaustausch mit Erweiterungsmodulen (energieversorgerseitig). Die Schnittstelle ist bei Auslieferung mit einem Etikett gegen unbefugten Zugriff versie- gelt.
> 
> <PastedGraphic-1.png>
> 
> Da kann man sich jetzt aussuchen, was man glauben soll… Aber ich sehe es wie Du, dass der mit xxd angezeigte Output kein Klartext, sondern SML ist.
> Nur bin ich weiter am rätseln, wie ich es schaffe, den SML-Auswurf der Schnittstelle mit vzlogger zu parsen. Plappern tut der Zähler ja erfreulicher Weise von alleine.
> 
> Wo hast du Deine Infos zu den Specs der Schnittstelle (SML mit 9600bd, 8N1) her?
> Bin für Tipps sehr dankbar.
> 
> Best Grüße
> Armin
> 
>> Am 22.03.2017 um 21:22 schrieb Udo1 <udo1 at gmx.net <mailto:udo1 at gmx.net>>:
>> 
>> 
>> 
>> Am 22.03.2017 um 20:51 schrieb Malte Diers:
>>> Ich habe auch ein EasyMeter Q3BA und Udos Lesekopf. Bei mir geht
>>> folgende Konfig:
>> 
>>> @Michael:
>>> Im anderen Thread magst Du es gelesen haben: Ich habe ein Easymeter Q3D
>> 
>> 
>> Malte, was hast du denn jetzt?
>> Ein Q3BA, oder einen Q3DA?
>> 
>> Weil, der Q3DA redet D0 mit 9600bd, 7E1,
>> während der Q3BA redet SML mit 9600bd, 8N1.
>> 
>> Gruß
>> Udo
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20170323/7658fbd4/attachment-0001.html>

More information about the volkszaehler-users mailing list