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

Frank Richter frank.richter83 at gmail.com
Thu Mar 23 12:13:17 CET 2017 

Als minimale Config für den Funktionstest eines SML-Zählers genügt
erfahrungsgemäß schon folgendes:

{
"verbosity" : 15,
"log" : "/tmp/vzlogger.log",

"meters" :
[{
"enabled" : true,
"protocol" : "sml",
"device" : "/dev/ttyUSB0"
}]
}

Grüße
Frank
Am 23.03.2017 11:05 schrieb "applicationMGR ecoCuyo" <
applicationMGR at ecocuyo.de>:

> Hallo Frank,
>
> stimmt - klaro, das macht Sinn! Also kann man schon mal festhalten, dass
> der Zähler auch ohne *pulseq* mit 9600 Baud vor sich hin trällert.
>
> Danke
> Armin
>
>
> Am 23.03.2017 um 11:03 schrieb Frank Richter <frank.richter83 at gmail.com>:
>
> Hallo Armin,
>
> mit dem D0-Test hast du halt deine USB-Schnittstelle auf 300 Baud
> umgestellt, deswegen ist das langsam und nicht lesbar.
> Mit der SML-Config hast du das wieder rückgängig gemacht.
> Dass die pullseq hier was bewirkt, glaube ich weiterhin nicht.
> Die üblichen pull-Zähler liefern doch nach Aufforderung einen Datensatz,
> das scheint ja hier nicht so zu sein (du sendest pullseq per vzlogger und
> liest später per xxd).
>
> Grüße
> Frank
> Am 23.03.2017 10:43 schrieb "applicationMGR ecoCuyo" <
> applicationMGR at ecocuyo.de>:
>
>> 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 <04400%208000004>
>> $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 <05506%201180040>
>> .$.$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": "1b1b1b1b010101017603303062006
>> 200726500000100770101093131333131383632010101016303360076033
>> 031620062007265000007007501010101016314cb0076033032620062007
>> 26500000200710163756d0000001b1b1b1b1a027241",
>>
>> //      "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": "1b1b1b1b010101017603303062006
>> 200726500000100770101093131333131383632010101016303360076033
>> 031620062007265000007007501010101016314cb0076033032620062007
>> 26500000200710163756d0000001b1b1b1b1a027241",
>>         "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>:
>>
>>> 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>:
>>>
>>>
>>>
>>> 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/8abf1fb6/attachment-0001.html>

More information about the volkszaehler-users mailing list