Discussion:
[vz-users] VZlogger mit Elster AS1140 und andere Problemchen
Juergen Kersting
2015-02-19 15:52:11 UTC
Permalink
Hallo,



ich habe gestern meine schönen USB-Leseköpfe von Udo bekommen.

Ich möchte gerne meine AS1440 Zähler (Bezug und PV) über den Volkszähler
auslesen und anzeigen. Später würde ich versuchen wollen, wenn möglich mit
aktuellen Zählerdaten auch für skripte für Schaltsteckdosen in FHEM zu
erstellen. Natürlich habe ich mir recht viel vorgenommen, denn meine Ahnung
von Linux/Perl ist (noch!) kaum vorhanden und somit ist es nicht einfach für
mich die Fehler zu finden.



Ich habe, was wohl nach obiger Einleitung zu erwarten war, einige Probleme
mit dem AS1440 auf dem VZ aber auch mit der Einrichtung der Köpfe.

Ich nutze das Image vom VZ für das Raspberry.

Erstmal zur Einrichtung nach Anleitung:



$ ls -l /dev/serial/{by-path,by-id}/*

Zeigt auch die richtig die beiden USB-IR-Lesekopf an



/sbin/udevadm info --query=all --name=/dev/ttyUSB0

Funktioniert auch bei beiden Köpfen





In der Ausgabe findet sich eine Zeile „E: ID_SERIAL_SHORT=ABC1234“. ABC1234
ist die Seriennummer des USB-Chips.

Nun kann man eine Datei “/etc/udev/rules.d/99-lesekopf.conf“ mit folgendem
Inhalt anlegen:

SUBSYSTEM=="tty", ATTRS{product}=="FT232R USB UART",
ATTRS{serial}=="ABC1234", NAME="lesekopf0"

Ergänzend ist zu erwähnen, dass je nach Linux Distribution die
udev-„Rules“-Datei, also z.B. “/etc/udev/rules.d/99-lesekopf.conf“ nicht mit
“.conf“, sondern mit “.rules“ enden muss, damit der udev-Dienst diese Datei
auch berücksichtigt. Dies betrifft unter anderem Ubuntu und Debian. Siehe
<http://wiki.debian.org/udev> debian-wiki (en). Nach dem die Datei angelegt
wurde noch kurz den udev-Dienst neu starten/laden (z.B. “/etc/init.d/udevd
reload“) und man kann über /dev/lesekopf0 auf den Lesekopf zugreifen. Egal,
welche anderen ttyUSB Geräte es noch gibt

Ich habe die Dateien (einmal .rules einmal .conf) mit Nano angelegt und egal
ob ich nur einen Kopf oder beide definiere, sie werden unter /dev/lesekopfX
nicht angezeigt. Der „reload“ funktioniert insofern nicht, dass ich das
Kommando mit STRG-C abbrechen muss.

Wenn ich nun /cat dev/ttyUSB0 eingebe kommt nichts, auch dieses muss ich mit
STRG-C abbrechen. Auch bei minicom funktioniert nix. Hier muss ich sogar
Putty schließen.
(Ach bitte, ist die Tastenkombi bei Minicom tatsächlich STRG A und Z ???: )

Nun habe ich gelesen, dass es nicht einfach wird den AS1440 überhaupt in den
VZ einzubinden. Alles was ich an VZ/AS1440 Meldungen finde, endet irgendwann
ohne Lösung:) Gibt es hier schon Fortschritte und ich bin nur zu doof zum
Suchen?

Wenn das alles mal läuft, wie komme ich an die nötige UUID und reicht es in
der conf Datei auf d0 als Protokoll zu setzen?

Für Hilfe wäre ich sehr dankbar.

VieleGrüße
Jürgen
Matthias Behr
2015-02-19 16:03:43 UTC
Permalink
Hallo,

lt. Wiki scheint das ein ganz normaler D0 Meter zu sein:
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440 <http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440>

D.h. du brauchst vzlogger und eine Konfiguration ala

{
"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
"dump_file": "/var/log/dumpD0.txt", // optional, if set logs all received/transmitted data to this file
// "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
"parity": "7E1", // oder 8N1
"baudrate": 300, // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
"ackseq": „auto", // optional (default: keine Antwortsequenz auf Zaehlerantwort) kann entweder feste hex-Sequenz sein (z.B. 063035300d0a 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)
// "baudrate_read": 300, // Baudratenumschaltung auf gewünschte Baudrate, abhängig von Zählerantwort
// "aggtime": 20, // in Sekunden
// "aggmode": "AVG", // Mittelwert für Leistung, "MAX" für Zähler, "SUM" für Counter
"interval": 1, // Wartezeit in Sekunden bis neue Werte in die middleware übertragen werden
"channel": { // Beispiel-channel
"uuid": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeee",
"middleware": "http://127.0.0.1/middleware.php",
"identifier": "1-0:1.8.1" // alias for '1-0:1.8.1', see 'vzlogger -h' for list of available aliases
}
},
Post by Juergen Kersting
Hallo,
ich habe gestern meine schönen USB-Leseköpfe von Udo bekommen.
Ich möchte gerne meine AS1440 Zähler (Bezug und PV) über den Volkszähler auslesen und anzeigen. Später würde ich versuchen wollen, wenn möglich mit aktuellen Zählerdaten auch für skripte für Schaltsteckdosen in FHEM zu erstellen. Natürlich habe ich mir recht viel vorgenommen, denn meine Ahnung von Linux/Perl ist (noch!) kaum vorhanden und somit ist es nicht einfach für mich die Fehler zu finden.
Ich habe, was wohl nach obiger Einleitung zu erwarten war, einige Probleme mit dem AS1440 auf dem VZ aber auch mit der Einrichtung der Köpfe.
Ich nutze das Image vom VZ für das Raspberry.
$ ls -l /dev/serial/{by-path,by-id}/*
Zeigt auch die richtig die beiden USB-IR-Lesekopf an
/sbin/udevadm info --query=all --name=/dev/ttyUSB0
Funktioniert auch bei beiden Köpfen
In der Ausgabe findet sich eine Zeile „E: ID_SERIAL_SHORT=ABC1234“. ABC1234 ist die Seriennummer des USB-Chips.
SUBSYSTEM=="tty", ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="ABC1234", NAME="lesekopf0"
Ergänzend ist zu erwähnen, dass je nach Linux Distribution die udev-„Rules“-Datei, also z.B. “/etc/udev/rules.d/99-lesekopf.conf“ nicht mit “.conf“, sondern mit “.rules“ enden muss, damit der udev-Dienst diese Datei auch berücksichtigt. Dies betrifft unter anderem Ubuntu und Debian. Siehe debian-wiki (en) <http://wiki.debian.org/udev>. Nach dem die Datei angelegt wurde noch kurz den udev-Dienst neu starten/laden (z.B. “/etc/init.d/udevd reload“) und man kann über /dev/lesekopf0 auf den Lesekopf zugreifen. Egal, welche anderen ttyUSB Geräte es noch gibt <image001.gif>
Ich habe die Dateien (einmal .rules einmal .conf) mit Nano angelegt und egal ob ich nur einen Kopf oder beide definiere, sie werden unter /dev/lesekopfX nicht angezeigt. Der „reload“ funktioniert insofern nicht, dass ich das Kommando mit STRG-C abbrechen muss.
Wenn ich nun /cat dev/ttyUSB0 eingebe kommt nichts, auch dieses muss ich mit STRG-C abbrechen. Auch bei minicom funktioniert nix. Hier muss ich sogar Putty schließen.
(Ach bitte, ist die Tastenkombi bei Minicom tatsächlich STRG A und Z ???: )
Nun habe ich gelesen, dass es nicht einfach wird den AS1440 überhaupt in den VZ einzubinden. Alles was ich an VZ/AS1440 Meldungen finde, endet irgendwann ohne LösungJ Gibt es hier schon Fortschritte und ich bin nur zu doof zum Suchen?
Wenn das alles mal läuft, wie komme ich an die nötige UUID und reicht es in der conf Datei auf d0 als Protokoll zu setzen?
Für Hilfe wäre ich sehr dankbar.
VieleGrüße
Jürgen
Gruß

Matthias Behr
Marius Hellmann
2015-02-19 19:07:21 UTC
Permalink
Hallo Matthias,

ich versuche mich auch gerade an einem AS1440.

Diverse Configs hab ich jetzt durch aber die einzige in der der ZÀhler was ausspuckt ist die wo ich keine ackseq sende und er nach 1,5 sec auf 300 Baud seinen kompletten Speicher, Lastgang etc. ausspuckt. Das dauert dann schon mal 5 Minuten... :-)

wenn ich z.b. die ackseq auf "auto" oder "063035300d0a" stelle bekomme ich nur "timeout sending pullseq"alle 10 Sekunden.

ihm irgendwie eine Umschaltung auf 9600 Baud bei zu bÃŒgeln bekomme ich nicht hin.

ich hÀng mal ein dumpD0.txt an...

Log hÀtte ich auch noch aber beide zusammen waren zu groß fÃŒr eine Mail...



"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
"dump_file": "/var/log/dumpD0.txt", // optional, if set logs all received/transmitted data to this file
// "read_timeout": 10, // optional, default 10s. Timeout value in secs between single bytes received frm device
// "baudrate_change_delay": 400, // optional, default none. Delay value in ms after ACKSEQ send before baudrate change
"parity": "7E1", // oder 8N1
"baudrate": 300 , // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
// "ackseq": "auto", // optional (default: keine Antwortsequenz auf Zaehlerantwort) kann entweder feste hex-Sequenz sein (z.B. 063035300d0a fÃŒr mode C mit 9600bd oder 063030300d0a = 300bd) od$
// "baudrate_read": 300, // Baudratenumschaltung auf gewÌnschte Baudrate, abhÀngig von ZÀhlerantwort
// "aggtime": 30, // in Sekunden
// "interval": 1, // Wartezeit in Sekunden bis neue Werte in die middleware ÃŒbertragen werden



Gruß Marius
Matthias Behr
2015-02-19 19:21:14 UTC
Permalink
Hallo,

mir reicht eigentlich der Dump.

Kannst du mir mal einen Dump mit ackseq:auto schicken? Danke!

Und Àndern „interval“: mal auf einen größeren Wert. (Z.B. 10, vielleicht mag der Logger nicht so schnell die Daten schicken. Der erste Aufruf scheint ja Daten zu liefern.)
Post by Marius Hellmann
Hallo Matthias,
ich versuche mich auch gerade an einem AS1440.
Diverse Configs hab ich jetzt durch aber die einzige in der der ZÀhler was ausspuckt ist die wo ich keine ackseq sende und er nach 1,5 sec auf 300 Baud seinen kompletten Speicher, Lastgang etc. ausspuckt. Das dauert dann schon mal 5 Minuten... :-)
wenn ich z.b. die ackseq auf "auto" oder "063035300d0a" stelle bekomme ich nur "timeout sending pullseq"alle 10 <x-apple-data-detectors://0> Sekunden.
ihm irgendwie eine Umschaltung auf 9600 Baud bei zu bÃŒgeln bekomme ich nicht hin.
ich hÀng mal ein dumpD0.txt an...
Log hÀtte ich auch noch aber beide zusammen waren zu groß fÃŒr eine Mail...
"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
"dump_file": "/var/log/dumpD0.txt", // optional, if set logs all received/transmitted data to this file
// "read_timeout": 10, // optional, default 10s. Timeout value in secs between single bytes received frm device
// "baudrate_change_delay": 400, // optional, default none. Delay value in ms after ACKSEQ send before baudrate change
"parity": "7E1", // oder 8N1
"baudrate": 300 , // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
// "ackseq": "auto", // optional (default: keine Antwortsequenz auf Zaehlerantwort) kann entweder feste hex-Sequenz sein (z.B. 063035300d0a fÃŒr mode C mit 9600bd oder 063030300d0a = 300bd) od$
// "baudrate_read": 300, // Baudratenumschaltung auf gewÌnschte Baudrate, abhÀngig von ZÀhlerantwort
// "aggtime": 30, // in Sekunden
// "interval": 1, // Wartezeit in Sekunden bis neue Werte in die middleware ÃŒbertragen werden
Gruß Marius
<dumpD0.txt>
Gruß

Matthias
Marius Hellmann
2015-02-20 07:53:15 UTC
Permalink
Post by Matthias Behr
mir reicht eigentlich der Dump.
Kannst du mir mal einen Dump mit ackseq:auto schicken? Danke!
Und Àndern „interval": mal auf einen größeren Wert. (Z.B. 10, vielleicht mag der Logger nicht so schnell die Daten schicken. Der erste Aufruf scheint ja Daten zu liefern.)
Hallo,

Hier der Dump mit ackseq auto. Intervall hab ich auf 10 sec. geÀndert.

Gruß Marius
Matthias Behr
2015-02-20 11:12:48 UTC
Permalink
Danke.

Ich verstehe nicht, was der Logger mit
Post by Juergen Kersting
Post by Matthias Behr
56.798496592s ( 0 ms)
06 7e 63 7f 0f

meint. Da das aber nach 0ms kommt (also schon im Buffer zu sein scheint), scheint es ein Timing Thema zu sein.

Der Logger antwortet auch mit einem komischen Identifier: /ELS5\@V9.34

das \@ ist komisch. Das ist lt Spec:
23) Sequence delimiter (backslash code 5CH), optional field. This character is always followed by a one character field 24). This field is part of the maximum 16 character wide identification field 14). Multiple pairs 23)/24) are allowed.

24) Enhanced baud rate and mode identification character (optional field). This field is part of the 16 character wide identification field 14). W must be registered with the administrator: The DLMS User Association (see the foreword). For details see 6.4.5.1.



Das 24) ist bei dir ein ‚@‚

0-1 -
2-
3-9 -

Other printable characters with exception of /, \ and !: manufacturer-specific use.



D.h. das ist irgend ein „manufacturer specific mode“




Kannst du mal 2 Tests machen:

a)
„baudrate_change_delay“: 500
in der .conf setzen.

und danach:

b) Dump mit 300baud:
"ackseq": "063030300d0a",
"baudrate_read": 300,
Post by Juergen Kersting
Post by Matthias Behr
mir reicht eigentlich der Dump.
Kannst du mir mal einen Dump mit ackseq:auto schicken? Danke!
Und Àndern „interval“: mal auf einen größeren Wert. (Z.B. 10, vielleicht mag der Logger nicht so schnell die Daten schicken. Der erste Aufruf scheint ja Daten zu liefern.)
Hallo,
Hier der Dump mit ackseq auto. Intervall hab ich auf 10 sec. geÀndert.
Gruß Marius
<dumpD0_MitAutoAck.txt>
Gruß

Matthias Behr
Marius Hellmann
2015-02-20 12:22:27 UTC
Permalink
Entspricht aber scheinbar dem was im wiki steht oder?
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation
a)
„baudrate_change_delay": 500
in der .conf setzen.
Lieferte nicht viel außer "Something unexpected happened: read:705!"
habs aber mal n paar Minuten laufen lassen..
Dump ist im Anhang...
"ackseq": "063030300d0a",
"baudrate_read": 300,
Lieferte auch nicht viel habs auch mal n paar Minuten laufen lassen..
Dump ist im Anhang...
Matthias Behr
2015-02-20 12:48:14 UTC
Permalink
Lass uns erst mal versuchen, den mit 300baud hinzubekommen:

bitte bei Fall b) (FixAckSeq) zusÀtzlich
read_timeout: 10
baudrate: 300
(zusÀtzlich zu baudrate_read: 300)

setzen.
Post by Marius Hellmann
Entspricht aber scheinbar dem was im wiki steht oder?
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation
Post by Matthias Behr
a)
„baudrate_change_delay“: 500
in der .conf setzen.
Lieferte nicht viel außer "Something unexpected happened: read:705!" habs aber mal n paar Minuten laufen lassen..
Dump ist im Anhang...
Post by Matthias Behr
"ackseq": "063030300d0a",
"baudrate_read": 300,
Lieferte auch nicht viel habs auch mal n paar Minuten laufen lassen..
Dump ist im Anhang...
<dumpD0_BaudRateChangeDelay.txt><dumpD0_BaudRateChangeDelay_u_FixAckSeq.txt>
Gruß
Matthias
Marius Hellmann
2015-02-20 12:56:41 UTC
Permalink
so sieht die Config aktuell aus...
Ausgabe ist aber die gleiche wie bei den beiden vorherigen versuchen...

"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead to
meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
"dump_file": "/var/log/dumpD0.txt", // optional, if set logs all
received/transmitted data to this file
// "read_timeout": 10, // optional, default 10s. Timeout value in secs
between single bytes received frm device
"baudrate_change_delay": 500, // optional, default none. Delay value in
ms after ACKSEQ send before baudrate change
"parity": "7E1", // oder 8N1
"baudrate": 300 , // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
"ackseq": "063030300d0a", // optional (default: keine Antwortsequenz
auf Zaehlerantwort) kann entweder feste hex-Sequenz sein (z.B.
063035300d0a fÃŒr mode C mit 9600bd oder 063030300d0a = 3$
"baudrate_read": 300, // Baudratenumschaltung auf gewÃŒnschte Baudrate,
abhÀngig von ZÀhlerantwort
// "aggtime": 30, // in Sekunden
"interval": 10, // Wartezeit in Sekunden bis neue Werte in die
middleware ÃŒbertragen werden

GrÌße Marius
Post by Matthias Behr
bitte bei Fall b) (FixAckSeq) zusÀtzlich
read_timeout: 10
baudrate: 300
(zusÀtzlich zu baudrate_read: 300)
setzen.
Entspricht aber scheinbar dem was im wiki steht oder?
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation [1]
a)
„baudrate_change_delay": 500
in der .conf setzen.
Lieferte nicht viel außer "Something unexpected happened: read:705!" habs aber mal n paar Minuten laufen lassen..
Dump ist im Anhang...
"ackseq": "063030300d0a",
"baudrate_read": 300,
Lieferte auch nicht viel habs auch mal n paar Minuten laufen lassen..
Dump ist im Anhang... &lt;dumpD0_BaudRateChangeDelay.txt>&lt;dumpD0_BaudRateChangeDelay_u_FixAckSeq.txt>
Gruß
Matthias

Links:
------
[1]
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation
Matthias Behr
2015-02-20 12:59:24 UTC
Permalink
Config sieht gut aus.
Dump sieht genau gleich aus?
Post by Marius Hellmann
so sieht die Config aktuell aus...
Ausgabe ist aber die gleiche wie bei den beiden vorherigen versuchen...
"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
"dump_file": "/var/log/dumpD0.txt", // optional, if set logs all received/transmitted data to this file
// "read_timeout": 10, // optional, default 10s. Timeout value in secs between single bytes received frm device
"baudrate_change_delay": 500, // optional, default none. Delay value in ms after ACKSEQ send before baudrate change
"parity": "7E1", // oder 8N1
"baudrate": 300 , // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
"ackseq": "063030300d0a", // optional (default: keine Antwortsequenz auf Zaehlerantwort) kann entweder feste hex-Sequenz sein (z.B. 063035300d0a fÃŒr mode C mit 9600bd oder 063030300d0a = 3$
"baudrate_read": 300, // Baudratenumschaltung auf gewÌnschte Baudrate, abhÀngig von ZÀhlerantwort
// "aggtime": 30, // in Sekunden
"interval": 10, // Wartezeit in Sekunden bis neue Werte in die middleware ÃŒbertragen werden
GrÌße Marius
Post by Matthias Behr
bitte bei Fall b) (FixAckSeq) zusÀtzlich
read_timeout: 10
baudrate: 300
(zusÀtzlich zu baudrate_read: 300)
setzen.
Post by Marius Hellmann
Entspricht aber scheinbar dem was im wiki steht oder?
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation <http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation>
a)
„baudrate_change_delay“: 500
in der .conf setzen.
Lieferte nicht viel außer "Something unexpected happened: read:705!" habs aber mal n paar Minuten laufen lassen..
Dump ist im Anhang...
"ackseq": "063030300d0a",
"baudrate_read": 300,
Lieferte auch nicht viel habs auch mal n paar Minuten laufen lassen..
Dump ist im Anhang...
&lt;dumpD0_BaudRateChangeDelay.txt>&lt;dumpD0_BaudRateChangeDelay_u_FixAckSeq.txt>
Gruß
Matthias
Gruß

Matthias Behr
Juergen Kersting
2015-02-20 13:03:48 UTC
Permalink
Ich habe eine kurze Zwischenfrage: Ich konnte heute Morgen via hterm zumindest den ZÀhler Ìberreden mir via 300 Baud seine Daten zu schicken.

Auf dem Raspberry ist mir das mit z.B. minicom nicht gelungen. Benötige ich auch auf dem Raspberry die entsprechenden Treiber?





Von: volkszaehler-users [mailto:volkszaehler-users-***@demo.volkszaehler.org] Im Auftrag von Matthias Behr
Gesendet: Freitag, 20. Februar 2015 13:59
An: volkszaehler.org - users
Betreff: Re: [vz-users] VZlogger mit Elster AS1140 und andere Problemchen



Config sieht gut aus.

Dump sieht genau gleich aus?



Am 20.02.2015 um 13:56 schrieb Marius Hellmann <***@hellmann.me <mailto:***@hellmann.me> >:



so sieht die Config aktuell aus...
Ausgabe ist aber die gleiche wie bei den beiden vorherigen versuchen...

"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
"dump_file": "/var/log/dumpD0.txt", // optional, if set logs all received/transmitted data to this file
// "read_timeout": 10, // optional, default 10s. Timeout value in secs between single bytes received frm device
"baudrate_change_delay": 500, // optional, default none. Delay value in ms after ACKSEQ send before baudrate change
"parity": "7E1", // oder 8N1
"baudrate": 300 , // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
"ackseq": "063030300d0a", // optional (default: keine Antwortsequenz auf Zaehlerantwort) kann entweder feste hex-Sequenz sein (z.B. 063035300d0a fÃŒr mode C mit 9600bd oder 063030300d0a = 3$
"baudrate_read": 300, // Baudratenumschaltung auf gewÌnschte Baudrate, abhÀngig von ZÀhlerantwort
// "aggtime": 30, // in Sekunden
"interval": 10, // Wartezeit in Sekunden bis neue Werte in die middleware ÃŒbertragen werden



GrÌße Marius





Am 20-02-2015 13:48, schrieb Matthias Behr:

Lass uns erst mal versuchen, den mit 300baud hinzubekommen:



bitte bei Fall b) (FixAckSeq) zusÀtzlich

read_timeout: 10

baudrate: 300

(zusÀtzlich zu baudrate_read: 300)



setzen.

Am 20.02.2015 um 13:22 schrieb Marius Hellmann &lt;***@hellmann.me <mailto:***@hellmann.me> >:





Der Logger antwortet auch mit einem komischen Identifier: /ELS5\@V9.34



das \@ ist komisch. Das ist lt Spec:



Entspricht aber scheinbar dem was im wiki steht oder?

http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation



Kannst du mal 2 Tests machen:



a)

„baudrate_change_delay“: 500

in der .conf setzen.

Lieferte nicht viel außer "Something unexpected happened: read:705!" habs aber mal n paar Minuten laufen lassen..

Dump ist im Anhang...

und danach:



b) Dump mit 300baud:

"ackseq": "063030300d0a",

"baudrate_read": 300,

Lieferte auch nicht viel habs auch mal n paar Minuten laufen lassen..

Dump ist im Anhang...

&lt;dumpD0_BaudRateChangeDelay.txt>&lt;dumpD0_BaudRateChangeDelay_u_FixAckSeq.txt>



Gruß

Matthias



Gruß



Matthias Behr
Tom Weber
2015-02-20 13:09:39 UTC
Permalink
habe ich die Tage auch probiert - da musste ich hterm aber DTR auf high
setzen. Wie macht man das bei minicom bzw. in php mit fopen ?
Post by Juergen Kersting
Ich habe eine kurze Zwischenfrage: Ich konnte heute Morgen via hterm
zumindest den ZÀhler Ìberreden mir via 300 Baud seine Daten zu schicken.
Auf dem Raspberry ist mir das mit z.B. minicom nicht gelungen.
Benötige ich auch auf dem Raspberry die entsprechenden Treiber?
*Von:*volkszaehler-users
von *Matthias Behr
*Gesendet:* Freitag, 20. Februar 2015 13:59
*An:* volkszaehler.org - users
*Betreff:* Re: [vz-users] VZlogger mit Elster AS1140 und andere
Problemchen
Config sieht gut aus.
Dump sieht genau gleich aus?
so sieht die Config aktuell aus...
Ausgabe ist aber die gleiche wie bei den beiden vorherigen
versuchen...
"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead
to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
"dump_file": "/var/log/dumpD0.txt", // optional, if set logs all
received/transmitted data to this file
// "read_timeout": 10, // optional, default 10s. Timeout value in
secs between single bytes received frm device
"baudrate_change_delay": 500, // optional, default none. Delay
value in ms after ACKSEQ send before baudrate change
"parity": "7E1", // oder 8N1
"baudrate": 300 , // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
"ackseq": "063030300d0a", // optional (default: keine
Antwortsequenz auf Zaehlerantwort) kann entweder feste hex-Sequenz
sein (z.B. 063035300d0a fÃŒr mode C mit 9600bd oder 063030300d0a = 3$
"baudrate_read": 300, // Baudratenumschaltung auf gewÃŒnschte
Baudrate, abhÀngig von ZÀhlerantwort
// "aggtime": 30, // in Sekunden
"interval": 10, // Wartezeit in Sekunden bis neue Werte in die
middleware ÃŒbertragen werden
GrÌße Marius
bitte bei Fall b) (FixAckSeq) zusÀtzlich
read_timeout: 10
baudrate: 300
(zusÀtzlich zu baudrate_read: 300)
setzen.
Am 20.02.2015 um 13:22 schrieb Marius Hellmann
Der Logger antwortet auch mit einem komischen
Entspricht aber scheinbar dem was im wiki steht oder?
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation
a)
„baudrate_change_delay“: 500
in der .conf setzen.
read:705!" habs aber mal n paar Minuten laufen lassen..
Dump ist im Anhang...
"ackseq": "063030300d0a",
"baudrate_read": 300,
Lieferte auch nicht viel habs auch mal n paar Minuten
laufen lassen..
Dump ist im Anhang...
&lt;dumpD0_BaudRateChangeDelay.txt>&lt;dumpD0_BaudRateChangeDelay_u_FixAckSeq.txt>
Gruß
Matthias
Gruß
Matthias Behr
Udo1
2015-02-20 13:41:01 UTC
Permalink
da musste ich hterm aber DTR auf high setzen. Wie macht man das bei
minicom
Auf dem Raspi gar nicht, der hat kein DTR.

Gruß
Udo
Matthias Behr
2015-02-20 13:44:46 UTC
Permalink
ah. passt.
Post by Udo1
da musste ich hterm aber DTR auf high setzen. Wie macht man das bei minicom
Auf dem Raspi gar nicht, der hat kein DTR.
Gruß
Udo
Gruß

Matthias Behr
Jürgen Kersting
2015-02-21 14:59:50 UTC
Permalink
Hallo,

wenn ich das richtig verstehe hat eigentlich niemand eine funktionierende Abfrage des AS1440 mit dem Vzlogger, oder?
Ich habe jetzt 2 Tage im Netz gesucht, mehr als Bruchstücke finde ich nicht und scheitere schon daran eine Abfrage auf dem Raspberry hinzubekommen :)




-----Ursprüngliche Nachricht-----
Von: volkszaehler-users [mailto:volkszaehler-users-***@demo.volkszaehler.org] Im Auftrag von Matthias Behr
Gesendet: Freitag, 20. Februar 2015 14:45
An: volkszaehler.org - users
Betreff: Re: [vz-users] VZlogger mit Elster AS1140 und andere Problemchen

ah. passt.
Post by Udo1
da musste ich hterm aber DTR auf high setzen. Wie macht man das bei minicom
Auf dem Raspi gar nicht, der hat kein DTR.
Gruß
Udo
Gruß

Matthias Behr
Matthias Behr
2015-02-21 16:00:02 UTC
Permalink
eine 300Baud Abfrage klappt recht gut, dauert aber jeweils fast 5 Min...
Eine 9600 Baud Abfrage funktioniert noch nicht zuverlÀssig, da bin ich noch dran. Der AS1440 scheint recht timing kritisch zu sein.

Gruß
Matthias

Sent from a mobile device.
Post by Juergen Kersting
Hallo,
wenn ich das richtig verstehe hat eigentlich niemand eine funktionierende Abfrage des AS1440 mit dem Vzlogger, oder?
Ich habe jetzt 2 Tage im Netz gesucht, mehr als BruchstÃŒcke finde ich nicht und scheitere schon daran eine Abfrage auf dem Raspberry hinzubekommen :)
-----UrsprÃŒngliche Nachricht-----
Gesendet: Freitag, 20. Februar 2015 14:45
An: volkszaehler.org - users
Betreff: Re: [vz-users] VZlogger mit Elster AS1140 und andere Problemchen
ah. passt.
Post by Udo1
da musste ich hterm aber DTR auf high setzen. Wie macht man das bei minicom
Auf dem Raspi gar nicht, der hat kein DTR.
Gruß
Udo
Gruß
Matthias Behr
Jürgen Kersting
2015-02-21 16:09:11 UTC
Permalink
Hallo Matthias,

was mache ich denn dann falsch?
Ich weiß das beide Köpfe funktionieren, da sie mit hterm unter Windows ansprechbar sind. Firmware ist übrigens 9.32

Ich habe dann dieses Script s.U. hier gefunden, das meiste auskommentiert und auf einer 2ten shell mit cat /dev/ttyUSB0 gehorcht. Absolut nix.
Wenn ich über vzlogger.conf alle einstellungen nach euren Postings mache, mir die UUID vom frontend geben lasse und in die .conf eintrage -> nothing to plot.
Ich weiß ja das es an mir liegt, macht es aber nicht einfacher :)


#!/bin/bash
#echo -e "\nStarte vzlogger:"
# vzlogger starten
#vzlogger -c /etc/vzlogger.conf -v 20
# Übertragungsparameter einstellen
stty -F /dev/ttyUSB0 300 parenb -parodd cs7 -cstopb raw
stty -F /dev/ttyUSB1 300 parenb -parodd cs7 -cstopb raw
# Initialisierung senden (Hexadezimal)
echo \x2f\x3f\x21\x0d\x0a' > /dev/ttyUSB0
echo \x2f\x3f\x21\x0d\x0a' > /dev/ttyUSB1
#sleep 1.5
#echo -e "\nÜbertragungsrate auf 9600 Baud hochsetzen"
# Bestätigung senden und Datenrate des Zählers auf 9600 Baud erhöhen
#echo \x06\x30\x35\x30\x0d\x0a' > /dev/ttyUSB0
#echo \x06\x30\x35\x30\x0d\x0a' > /dev/ttyUSB1
# Übertragungsrate auf 9600 hochsetzen
#stty -F /dev/ttyUSB0 9600
#stty -F /dev/ttyUSB1 9600



-----Ursprüngliche Nachricht-----
Von: volkszaehler-users [mailto:volkszaehler-users-***@demo.volkszaehler.org] Im Auftrag von Matthias Behr
Gesendet: Samstag, 21. Februar 2015 17:00
An: volkszaehler.org - users
Betreff: Re: [vz-users] VZlogger mit Elster AS1140 und andere Problemchen

eine 300Baud Abfrage klappt recht gut, dauert aber jeweils fast 5 Min...
Eine 9600 Baud Abfrage funktioniert noch nicht zuverlässig, da bin ich noch dran. Der AS1440 scheint recht timing kritisch zu sein.

Gruß
Matthias

Sent from a mobile device.
Post by Juergen Kersting
Hallo,
wenn ich das richtig verstehe hat eigentlich niemand eine funktionierende Abfrage des AS1440 mit dem Vzlogger, oder?
Ich habe jetzt 2 Tage im Netz gesucht, mehr als Bruchstücke finde ich nicht und scheitere schon daran eine Abfrage auf dem Raspberry hinzubekommen :)
-----Ursprüngliche Nachricht-----
Gesendet: Freitag, 20. Februar 2015 14:45
An: volkszaehler.org - users
Betreff: Re: [vz-users] VZlogger mit Elster AS1140 und andere Problemchen
ah. passt.
Post by Udo1
da musste ich hterm aber DTR auf high setzen. Wie macht man das bei minicom
Auf dem Raspi gar nicht, der hat kein DTR.
Gruß
Udo
Gruß
Matthias Behr
Matthias Behr
2015-02-21 16:56:26 UTC
Permalink
Nimm mal die folgende Konfig fÃŒr 300 baud:
{
"retry" : 30, /* how long to sleep between failed requests, in seconds */
"daemon": true, /* run periodically */
"verbosity" : 10, /* between 0 and 15 */
"log" : "/var/log/vzlogger.log",/* path to logfile, optional */

"local" : {
"enabled" : false, /* should we start the local HTTPd for serving live readings? */
"port" : 80, /* the TCP port for the local HTTPd */
"index" : true, /* should we provide a index listing of available channels if no UUID was requested? */
"timeout" : 30, /* timeout for long polling comet requests, 0 disables comet, in seconds */
"buffer" : 600 /* how long to buffer readings for the local interface, in seconds */
},

"meters" : [
{
"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
// "dump_file": "/var/log/dumpD0.txt", // optional, if set logs all received/transmitted data to this file
"read_timeout": 10, // optional, default 10s. Timeout value in secs between single bytes received frm device
"baudrate_change_delay": 500, // optional, default none. Delay value in ms after ACKSEQ send before baudrate change
"parity": "7E1", // oder 8N1
"baudrate": 300 , // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
"baudrate_read": 300, // Baudratenumschaltung auf gewÌnschte Baudrate, abhÀngig von ZÀhlerantwort
"interval": 10, // Wartezeit in Sekunden bis neue Werte in die middleware ÃŒbertragen werden
"channels": [{

und dann min. ein channel konfiguriert.

Dann muss im Logfile massenhaft:
Parsed reading (OBIS code=
) auftauchen.
Dann lÀuft der Logger mit Minimal-Konfig mit 300 baud.

Analog fÃŒr den 2. USB Port.

Sobald ich herausgefunden habe, wie man sauber auf 9600baud umschaltet, melde ich mich.
Post by Marius Hellmann
Hallo Matthias,
was mache ich denn dann falsch?
Ich weiß das beide Köpfe funktionieren, da sie mit hterm unter Windows ansprechbar sind. Firmware ist ÃŒbrigens 9.32
Ich habe dann dieses Script s.U. hier gefunden, das meiste auskommentiert und auf einer 2ten shell mit cat /dev/ttyUSB0 gehorcht. Absolut nix.
Wenn ich ÃŒber vzlogger.conf alle einstellungen nach euren Postings mache, mir die UUID vom frontend geben lasse und in die .conf eintrage -> nothing to plot.
Ich weiß ja das es an mir liegt, macht es aber nicht einfacher :)
#!/bin/bash
#echo -e "\nStarte vzlogger:"
# vzlogger starten
#vzlogger -c /etc/vzlogger.conf -v 20
# Übertragungsparameter einstellen
stty -F /dev/ttyUSB0 300 parenb -parodd cs7 -cstopb raw
stty -F /dev/ttyUSB1 300 parenb -parodd cs7 -cstopb raw
# Initialisierung senden (Hexadezimal)
echo \x2f\x3f\x21\x0d\x0a' > /dev/ttyUSB0
echo \x2f\x3f\x21\x0d\x0a' > /dev/ttyUSB1
#sleep 1.5
#echo -e "\nÜbertragungsrate auf 9600 Baud hochsetzen"
# BestÀtigung senden und Datenrate des ZÀhlers auf 9600 Baud erhöhen
#echo \x06\x30\x35\x30\x0d\x0a' > /dev/ttyUSB0
#echo \x06\x30\x35\x30\x0d\x0a' > /dev/ttyUSB1
# Übertragungsrate auf 9600 hochsetzen
#stty -F /dev/ttyUSB0 9600
#stty -F /dev/ttyUSB1 9600
-----UrsprÃŒngliche Nachricht-----
Gesendet: Samstag, 21. Februar 2015 17:00
An: volkszaehler.org - users
Betreff: Re: [vz-users] VZlogger mit Elster AS1140 und andere Problemchen
eine 300Baud Abfrage klappt recht gut, dauert aber jeweils fast 5 Min...
Eine 9600 Baud Abfrage funktioniert noch nicht zuverlÀssig, da bin ich noch dran. Der AS1440 scheint recht timing kritisch zu sein.
Gruß
Matthias
Sent from a mobile device.
Post by Juergen Kersting
Hallo,
wenn ich das richtig verstehe hat eigentlich niemand eine funktionierende Abfrage des AS1440 mit dem Vzlogger, oder?
Ich habe jetzt 2 Tage im Netz gesucht, mehr als BruchstÃŒcke finde ich nicht und scheitere schon daran eine Abfrage auf dem Raspberry hinzubekommen :)
-----UrsprÃŒngliche Nachricht-----
Gesendet: Freitag, 20. Februar 2015 14:45
An: volkszaehler.org - users
Betreff: Re: [vz-users] VZlogger mit Elster AS1140 und andere Problemchen
ah. passt.
Post by Udo1
da musste ich hterm aber DTR auf high setzen. Wie macht man das bei minicom
Auf dem Raspi gar nicht, der hat kein DTR.
Gruß
Udo
Gruß
Matthias Behr
Gruß

Matthias Behr

Udo1
2015-02-20 13:39:32 UTC
Permalink
Benötige ich auch auf dem Raspberry die entsprechenden Treiber?
Nein, nur minicom ist etwas zickig.

Gruß
Udo
Marius Hellmann
2015-02-20 13:17:25 UTC
Permalink
Sieht zumindest fÃŒr mich so aus...

hab die Pull und ACK Seq. grad mal mit Hterm probiert... da klappt es
mit 300b... und auch eine SCK seq. mit umschaltung auf 9600b

Sieht also tatsÀchlich so aus als wenn da timingtechnisch was schief
geht...
Config sieht gut aus. Dump sieht genau gleich aus?
so sieht die Config aktuell aus...
Ausgabe ist aber die gleiche wie bei den beiden vorherigen versuchen...
"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
"dump_file": "/var/log/dumpD0.txt", // optional, if set logs all received/transmitted data to this file
// "read_timeout": 10, // optional, default 10s. Timeout value in secs between single bytes received frm device
"baudrate_change_delay": 500, // optional, default none. Delay value in ms after ACKSEQ send before baudrate change
"parity": "7E1", // oder 8N1
"baudrate": 300 , // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
"ackseq": "063030300d0a", // optional (default: keine Antwortsequenz auf Zaehlerantwort) kann entweder feste hex-Sequenz sein (z.B. 063035300d0a fÃŒr mode C mit 9600bd oder 063030300d0a = 3$
"baudrate_read": 300, // Baudratenumschaltung auf gewÌnschte Baudrate, abhÀngig von ZÀhlerantwort
// "aggtime": 30, // in Sekunden
"interval": 10, // Wartezeit in Sekunden bis neue Werte in die middleware ÃŒbertragen werden
GrÌße Marius
bitte bei Fall b) (FixAckSeq) zusÀtzlich
read_timeout: 10
baudrate: 300
(zusÀtzlich zu baudrate_read: 300)
setzen.
Entspricht aber scheinbar dem was im wiki steht oder?
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation [1]
a)
„baudrate_change_delay": 500
in der .conf setzen.
Lieferte nicht viel außer "Something unexpected happened: read:705!" habs aber mal n paar Minuten laufen lassen..
Dump ist im Anhang...
"ackseq": "063030300d0a",
"baudrate_read": 300,
Lieferte auch nicht viel habs auch mal n paar Minuten laufen lassen..
Dump ist im Anhang... &lt;dumpD0_BaudRateChangeDelay.txt>&lt;dumpD0_BaudRateChangeDelay_u_FixAckSeq.txt>
Gruß
Matthias

Gruß

Matthias Behr

Links:
------
[1]
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation
Matthias Behr
2015-02-20 13:33:57 UTC
Permalink
komisch.

Sicher, dass die Config genutzt wird?
Das Timeout findet immer noch nach 2s statt und nicht nach 10s.
Post by Marius Hellmann
Sieht zumindest fÃŒr mich so aus...
hab die Pull und ACK Seq. grad mal mit Hterm probiert... da klappt es mit 300b... und auch eine SCK seq. mit umschaltung auf 9600b
Sieht also tatsÀchlich so aus als wenn da timingtechnisch was schief geht...
Post by Matthias Behr
Config sieht gut aus.
Dump sieht genau gleich aus?
Post by Marius Hellmann
so sieht die Config aktuell aus...
Ausgabe ist aber die gleiche wie bei den beiden vorherigen versuchen...
"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
"dump_file": "/var/log/dumpD0.txt", // optional, if set logs all received/transmitted data to this file
// "read_timeout": 10, // optional, default 10s. Timeout value in secs between single bytes received frm device
"baudrate_change_delay": 500, // optional, default none. Delay value in ms after ACKSEQ send before baudrate change
"parity": "7E1", // oder 8N1
"baudrate": 300 , // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
"ackseq": "063030300d0a", // optional (default: keine Antwortsequenz auf Zaehlerantwort) kann entweder feste hex-Sequenz sein (z.B. 063035300d0a fÃŒr mode C mit 9600bd oder 063030300d0a = 3$
"baudrate_read": 300, // Baudratenumschaltung auf gewÌnschte Baudrate, abhÀngig von ZÀhlerantwort
// "aggtime": 30, // in Sekunden
"interval": 10, // Wartezeit in Sekunden bis neue Werte in die middleware ÃŒbertragen werden
GrÌße Marius
bitte bei Fall b) (FixAckSeq) zusÀtzlich
read_timeout: 10
baudrate: 300
(zusÀtzlich zu baudrate_read: 300)
setzen.
Entspricht aber scheinbar dem was im wiki steht oder?
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation <http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation>
a)
„baudrate_change_delay“: 500
in der .conf setzen.
Lieferte nicht viel außer "Something unexpected happened: read:705!" habs aber mal n paar Minuten laufen lassen..
Dump ist im Anhang...
"ackseq": "063030300d0a",
"baudrate_read": 300,
Lieferte auch nicht viel habs auch mal n paar Minuten laufen lassen..
Dump ist im Anhang...
&lt;dumpD0_BaudRateChangeDelay.txt>&lt;dumpD0_BaudRateChangeDelay_u_FixAckSeq.txt>
Gruß
Matthias
Gruß
Matthias Behr
<dumpD0.txt><output_300b><output_9600b>
Gruß

Matthias Behr
Matthias Behr
2015-02-20 13:44:11 UTC
Permalink
Musst du mit HTerm auch DTR setzen?

Das tun wir nÀmlich nicht.
Falls ja, kannst du vor Start von vzlogger mal ein:
sudo stty -F /dev/ttyUSB0 cdtrdsr

machen?
Post by Matthias Behr
komisch.
Sicher, dass die Config genutzt wird?
Das Timeout findet immer noch nach 2s statt und nicht nach 10s.
Post by Marius Hellmann
Sieht zumindest fÃŒr mich so aus...
hab die Pull und ACK Seq. grad mal mit Hterm probiert... da klappt es mit 300b... und auch eine SCK seq. mit umschaltung auf 9600b
Sieht also tatsÀchlich so aus als wenn da timingtechnisch was schief geht...
Post by Matthias Behr
Config sieht gut aus.
Dump sieht genau gleich aus?
Post by Marius Hellmann
so sieht die Config aktuell aus...
Ausgabe ist aber die gleiche wie bei den beiden vorherigen versuchen...
"enabled": true, // disabled meters will be ignored (default)
"skip": false, // if enabled, errors when opening meter will lead to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for list of available protocols
"device": "/dev/ttyUSB0",
"dump_file": "/var/log/dumpD0.txt", // optional, if set logs all received/transmitted data to this file
// "read_timeout": 10, // optional, default 10s. Timeout value in secs between single bytes received frm device
"baudrate_change_delay": 500, // optional, default none. Delay value in ms after ACKSEQ send before baudrate change
"parity": "7E1", // oder 8N1
"baudrate": 300 , // oder 300
"pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
"ackseq": "063030300d0a", // optional (default: keine Antwortsequenz auf Zaehlerantwort) kann entweder feste hex-Sequenz sein (z.B. 063035300d0a fÃŒr mode C mit 9600bd oder 063030300d0a = 3$
"baudrate_read": 300, // Baudratenumschaltung auf gewÌnschte Baudrate, abhÀngig von ZÀhlerantwort
// "aggtime": 30, // in Sekunden
"interval": 10, // Wartezeit in Sekunden bis neue Werte in die middleware ÃŒbertragen werden
GrÌße Marius
bitte bei Fall b) (FixAckSeq) zusÀtzlich
read_timeout: 10
baudrate: 300
(zusÀtzlich zu baudrate_read: 300)
setzen.
Entspricht aber scheinbar dem was im wiki steht oder?
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation <http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#kommunikation>
a)
„baudrate_change_delay“: 500
in der .conf setzen.
Lieferte nicht viel außer "Something unexpected happened: read:705!" habs aber mal n paar Minuten laufen lassen..
Dump ist im Anhang...
"ackseq": "063030300d0a",
"baudrate_read": 300,
Lieferte auch nicht viel habs auch mal n paar Minuten laufen lassen..
Dump ist im Anhang...
&lt;dumpD0_BaudRateChangeDelay.txt>&lt;dumpD0_BaudRateChangeDelay_u_FixAckSeq.txt>
Gruß
Matthias
Gruß
Matthias Behr
<dumpD0.txt><output_300b><output_9600b>
Gruß
Matthias Behr
Gruß

Matthias Behr
Udo1
2015-02-20 13:32:19 UTC
Permalink
Post by Marius Hellmann
"baudrate_change_delay": 500,
Sieht eigentlich nicht gut aus!
500bd kann der nicht. Entweder 300bd oder 9600bd.

Gruß
Udo
Udo1
2015-02-20 13:33:48 UTC
Permalink
Sorry,, vergesst die Mail. Ich habe noch gepennt....
Post by Udo1
Post by Marius Hellmann
"baudrate_change_delay": 500,
Sieht eigentlich nicht gut aus!
500bd kann der nicht. Entweder 300bd oder 9600bd.
Gruß
Udo
Matthias Behr
2015-02-20 13:33:00 UTC
Permalink
das „baudrate_change_delay“ ist nur die Zeit vor dem Wechsel der Baudrate (in ms).
Post by Udo1
Post by Marius Hellmann
"baudrate_change_delay": 500,
Sieht eigentlich nicht gut aus!
500bd kann der nicht. Entweder 300bd oder 9600bd.
Gruß
Udo
Gruß

Matthias
Loading...