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

Frank Richter frank.richter83 at gmail.com
Thu Mar 23 20:27:04 CET 2017 

Schade...

Aber nochmals die Frage: hast du mal die Ausrichtung des Lesekopfs ein
bisschen verändert? Vielleicht sind Übertragungsfehler dabei, die die
Checksumme ungültig machen?

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

> 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>:
>
> 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>:
>
>> 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>:
>>
>> 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>:
>>
>>> 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
>>> >:
>>>
>>> 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/f14f89e1/attachment-0001.html>

More information about the volkszaehler-users mailing list