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

Thu Mar 23 11:16:58 CET 2017

Hast du auch mal ein bisschen mit der Ausrichtung des Lesekopfs gespielt?
Am 23.03.2017 11:09 schrieb "applicationMGR ecoCuyo" <
applicationMGR at ecocuyo.de>:

> Hallo Frank,
>
> yep, ist ein Raspi. Teste das mal…
>
> Besten Grüße
> Armin
>
>
> Am 23.03.2017 um 11:08 schrieb Frank Richter <frank.richter83 at gmail.com>:
>
> Noch was: worauf läuft das Setup? Wenn es ein Raspberry Pi ist, wäre ein
> Test mit einer zweiten Speicherkarte und dem Image mit neuerer
> vzlogger-Version schnell gemacht, ohne dass du dein bestehendes Setup
> ändern musst.
>
> Frank
> Am 23.03.2017 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 (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/adbc8782/attachment-0001.html>