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

Thu Mar 23 11:03:09 CET 2017

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": "1b1b1b1b0101010176033030620062
> 007265000001007701010931313331313836320101010163033600760330
> 31620062007265000007007501010101016314cb00760330326200620072
> 6500000200710163756d0000001b1b1b1b1a027241",
>
> //      "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": "1b1b1b1b0101010176033030620062
> 007265000001007701010931313331313836320101010163033600760330
> 31620062007265000007007501010101016314cb00760330326200620072
> 6500000200710163756d0000001b1b1b1b1a027241",
>         "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 (gemäß 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/8b1c818d/attachment-0001.html>