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

applicationMGR ecoCuyo applicationMGR at ecoCuyo.de
Thu Mar 23 20:19:59 CET 2017 

Hallo Frank et alii,

am vzlogger lag's nicht:

$ sudo ~/code/vzlogger/src/vzlogger -c /etc/vzlogger.conf.udo
[Mar 23 20:11:24][main] vzlogger v0.6.1 based on heads/master-0-g99f8edbcb4 from Mon, 6 Mar 2017 19:03:42 +0100 started.
[Mar 23 20:11:24][mtr0] Creating new meter with protocol sml.
[Mar 23 20:11:24][mtr0] Meter configured, enabled.
[Mar 23 20:11:24]       New meter initialized (protocol=sml)
[Mar 23 20:11:24]       Have 1 meters.
[Mar 23 20:11:24][main] log level is 15
[Mar 23 20:11:24][main] daemon=0, local=0
[Mar 23 20:11:24]       Process not  daemonized...
[Mar 23 20:11:24]       Opened logfile /tmp/vzlogger.log
[Mar 23 20:11:24][push] No pushDataServer defined.
[Mar 23 20:11:24][]     ===> Start meters
[Mar 23 20:11:24][mtr0] Meter connection established
[Mar 23 20:11:24][mtr0] Meter thread started
[Mar 23 20:11:24][mtr0] Meter is opened. Starting channels.
[Mar 23 20:11:24][]     Startup done.
[Mar 23 20:11:24][mtr0] Number of readers: 32
[Mar 23 20:11:24][mtr0] Config.daemon: 0
[Mar 23 20:11:24][mtr0] Config.local: 0
^C[Mar 23 20:11:57]       MapContainer::quit terminating on signal 2.
[Mar 23 20:11:57]       Closing connections to terminate
[Mar 23 20:11:57][main] MeterMap::cancel entered...
[Mar 23 20:11:57][main] MeterMap::cancel wait for readingthread
[Mar 23 20:11:57][main] MeterMap::cancel wait for meter::close
[Mar 23 20:11:57][main] MeterMap::cancel finished.
[Mar 23 20:11:57][main] MapContainer::quit finished.
[Mar 23 20:11:57][]     Server stopped.
[Mar 23 20:11:57][]     Trying to delete curlSessionProvider...
[Mar 23 20:11:57][]     deleted curlSessionProvider


vzlogger.log:

[Mar 23 20:10:58]       Opened logfile /tmp/vzlogger.log
[Mar 23 20:10:58][push] No pushDataServer defined.
[Mar 23 20:10:58][]     ===> Start meters
[Mar 23 20:10:58][mtr0] Meter connection established
[Mar 23 20:10:58][mtr0] Meter thread started
[Mar 23 20:10:58][mtr0] Meter is opened. Starting channels.
[Mar 23 20:10:58][]     Startup done.
[Mar 23 20:10:58][mtr0] Number of readers: 32
[Mar 23 20:10:58][mtr0] Config.daemon: 0
[Mar 23 20:10:58][mtr0] Config.local: 0
[Mar 23 20:11:01]       terminating on signal 2.
[Mar 23 20:11:01]       Closing connections to terminate
[Mar 23 20:11:01][]     Server stopped.
[Mar 23 20:11:01][]     Trying to delete curlSessionProvider...
[Mar 23 20:11:01][]     deleted curlSessionProvider
[Mar 23 20:11:24][main] vzlogger v0.6.1 based on heads/master-0-g99f8edbcb4 from Mon, 6 Mar 2017 19:03:42 +0100 started.
[Mar 23 20:11:24][mtr0] Creating new meter with protocol sml.
[Mar 23 20:11:24][mtr0] Meter configured, enabled.
[Mar 23 20:11:24]       New meter initialized (protocol=sml)
[Mar 23 20:11:24]       Have 1 meters.
[Mar 23 20:11:24][main] log level is 15
[Mar 23 20:11:24][main] daemon=0, local=0
[Mar 23 20:11:24]       Process not  daemonized...
[Mar 23 20:11:24]       Opened logfile /tmp/vzlogger.log
[Mar 23 20:11:24][push] No pushDataServer defined.
[Mar 23 20:11:24][]     ===> Start meters
[Mar 23 20:11:24][mtr0] Meter connection established
[Mar 23 20:11:24][mtr0] Meter thread started
[Mar 23 20:11:24][mtr0] Meter is opened. Starting channels.
[Mar 23 20:11:24][]     Startup done.
[Mar 23 20:11:24][mtr0] Number of readers: 32
[Mar 23 20:11:24][mtr0] Config.daemon: 0
[Mar 23 20:11:24][mtr0] Config.local: 0
[Mar 23 20:11:57]       MapContainer::quit terminating on signal 2.
[Mar 23 20:11:57]       Closing connections to terminate
[Mar 23 20:11:57][main] MeterMap::cancel entered...
[Mar 23 20:11:57][main] MeterMap::cancel wait for readingthread
[Mar 23 20:11:57][main] MeterMap::cancel wait for meter::close
[Mar 23 20:11:57][main] MeterMap::cancel finished.
[Mar 23 20:11:57][main] MapContainer::quit finished.
[Mar 23 20:11:57][]     Server stopped.
[Mar 23 20:11:57][]     Trying to delete curlSessionProvider...
[Mar 23 20:11:57][]     deleted curlSessionProvider

vzlogger.conf:

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

"meters" : [
        {
        "enabled" : true,
        "protocol" : "sml",                     // or "oms","sml", see http://volkszaehler.github.io/vzlogger/ to try other options
        "device" : "/dev/ttyUSB0",
        }
       ]
}

Mal sehen, was ich da noch herausfinden kann…

Beste Grüße
Armin


> Am 23.03.2017 um 16:42 schrieb applicationMGR ecoCuyo <applicationMGR at ecoCuyo.de>:
> 
> Hallo Frank,
> 
> ist schon länger auf Jessie, war nur mit dem Logger vorsichtig… never touch a running system …
> 
> Best Grüße
> Armin
> 
>> Am 23.03.2017 um 14:19 schrieb Frank Richter <frank.richter83 at gmail.com <mailto:frank.richter83 at gmail.com>>:
>> 
>> Hallo Armin
>> 
>> wenn du ein Backup hast ist ja alles entspannt:-)
>> Falls du in dem Zug auch Middleware/Frontend aktualisieren willst: dafür braucht man glaub ich seit einiger Zeit mindestens Debian Jessie. Wenn der Rest genauso alt ist wie dein vzlogger, könnte es sein, dass du da auch ran musst.
>> 
>> Grüße
>> Frank
>> 
>> Am 23.03.2017 13:46 schrieb "applicationMGR ecoCuyo" <applicationMGR at ecocuyo.de <mailto:applicationMGR at ecocuyo.de>>:
>> Hallo Frank,
>> hab das Image mit dd gesichert und dachte mir, dass ist am einfachsten. Falls es dann funktioniert, wäre ich fertig.
>> Mit dem zweiten Image müsste ich ein neues Image Linux/vzlogger braten, auf dem dann nichts von dem ist (was viel Zeit gekostet hat). Wenn das neu Image dann funktionierte, müsste ich ohnehin den update auf dem Original machen. Aber selbst dann könnte es sein, dass ein anderer Hinderungsgrund auf dem Original den Erfolg verbaut.
>> 
>> Du hast natürlich einen guten Punkt, wenn das ganze gar nicht an vz-Version liegt, dann müsste ich entweder auf dem Original den Fehler suchen oder auf dem neuen Image alles wieder nachziehen und die DB importieren… In dem Fall wäre start from scratch ganz klar die sicherere Variante, um nicht alte Bugs mit zu schleifen und sich Nebeneffekten herum ärgern.
>> 
>> Schau mer ma :-) und vielen Dank nochmals für die Tipps & Anregungen an Euch alle!
>> 
>> Beste Grüße
>> Armin
>> 
>>> Am 23.03.2017 um 13:02 schrieb Frank Richter <frank.richter83 at gmail.com <mailto:frank.richter83 at gmail.com>>:
>>> 
>>> Dachte du wolltest erstmal nichts ändern am vorhandenen System? Deswegen der Vorschlag Image auf zweite Speicherkarte. Ist ja nicht gesagt dass es tatsächlich an der vzlogger-Version liegt...
>>> 
>>> Grüße
>>> Frank
>>> 
>>> Am 23.03.2017 12:51 schrieb "applicationMGR ecoCuyo" <applicationMGR at ecocuyo.de <mailto:applicationMGR at ecocuyo.de>>:
>>> Hallo Frank,
>>> 
>>> ja, das funktionert eigenltich so auch - nur in diesem Fall schweigt vzlogger:
>>> 
>>> sudo vzlogger -c /etc/vzlogger.conf.mini
>>> [Mar 23 12:49:06][main] vzlogger v0.4.7 based on heads/master-0-g64c5ec088a from Tue, 10 Nov 2015 08:14:41 +0100 started.
>>> [Mar 23 12:49:06][mtr0] Creating new meter with protocol sml.
>>> [Mar 23 12:49:06][mtr0] Meter configured, enabled.
>>> [Mar 23 12:49:06]       New meter initialized (protocol=sml)
>>> [Mar 23 12:49:06]       Have 1 meters.
>>> [Mar 23 12:49:06][main] log level is 15
>>> [Mar 23 12:49:06][main] daemon=0, local=0
>>> [Mar 23 12:49:06]       Process not  daemonized...
>>> [Mar 23 12:49:06]       Opened logfile /tmp/vzlogger.log
>>> [Mar 23 12:49:06][push] No pushDataServer defined.
>>> [Mar 23 12:49:06][]     ===> Start meters
>>> [Mar 23 12:49:06][mtr0] Meter connection established
>>> [Mar 23 12:49:06][mtr0] Meter thread started
>>> [Mar 23 12:49:06][mtr0] Meter is opened. Starting channels.
>>> [Mar 23 12:49:06][]     Startup done.
>>> [Mar 23 12:49:06][mtr0] Number of readers: 32
>>> [Mar 23 12:49:06][mtr0] Config.daemon: 0
>>> [Mar 23 12:49:06][mtr0] Config.local: 0 
>>> 
>>> … und dann kommt nichts mehr (:+(
>>> 
>>> Mache gerade den update/git pull auf die neueste Version.
>>> 
>>> Beste Grüße
>>> Armin
>>> 
>>> 
>>>> Am 23.03.2017 um 12:13 schrieb Frank Richter <frank.richter83 at gmail.com <mailto:frank.richter83 at gmail.com>>:
>>>> 
>>>> 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 <mailto: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 <mailto: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 <mailto: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 <tel: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 <tel: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/ <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 <http://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 <mailto: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/8c555068/attachment-0001.html>

More information about the volkszaehler-users mailing list