eBus->USB->Plugin->KNX

[makki]

...

Beim ebusd bin ich an einem Punkt angelangt, wo dieser ausreichend gut funktioniert.
Vielleicht wäre jetzt ein guter Zeitpunkt eine Beschreibung bzw. Doku zu erstellen WAS bereits alles geht, damit dadurch mehr potentielle Nutzer angesprochen werden.

Man darf dafür gerne das CV-Wiki (cometvisu.de/wiki) nutzen, wir können auch alternativ ebus-wasweissich.de davorlegen, die Domain ist in 2 Minuten eingerichtet

Was die andere Sache angeht habe ich Jumi geschrieben: ich habe damit absolut keinen Schmerz, solange keiner verwirrt wird - schöner wäre natürlich wenn das in den wiregated einfliesst aber ich habe selbst gesündigt, weil der wurde *nie* als Realtime-Logikengine entworfen- ist beim ansteuern der trägen Heizung aber auch egal; langsam aber es kommt an..

Makki

[JuMi2006]

@makki:
schlimmer sind die memleaks . In einer ruhigen Minute teste ich mal meine Versuche am produktiven Wiregate. Aber los wird man die nicht und dann isses fast egal wann monit und Co. zuschlagen.

In 0,3 bis 0,6 Sekunden hab ich auch die Rückmeldung von der Heizung auf dem Bus, also damit kann ich leben.

Was die Verwirrung angeht liegt das einfach am Konstrukt als solches: Daemon -> Daemon -> KNX und dass noch keiner weiß ob das Plugin-tauglich bleibt (was es momentan ist).

Um das zu entwirren brauchts aber erstmal ein paar Tester, aber das wird schon kommen. So ein zweiter Perl-Daemon auf ner separaten Kiste kann ja vielleicht auch mal nützlich sein. Damit könnte man z.B. die ganzen Zählerscripte migrieren . Aber nun wirds OT ... vielleicht gibts ja doch irgendwann den wiregated-c oder den busd mit KNX.

Idealerweise spart man einfach einen Damon, aber ich habs letzte Woche schon im Chat gesagt ... C kommt mir diesen Winter nicht mehr ins Haus .

Grüße

[Frank0207]

Meldung "Speicherzugriffsverletzung"

@yuhu

Habe gestern Abend dann mal nur den ebusd mit .../ebusd -lALL -f -s laufen lassen und nach ca. 5 min ist er dann mit unten stehender Meldung ausgestiegen.

2013-02-20 23:05:07.233 [0x20 EBH]  aa
2013-02-20 23:05:07.246 [0x20 EBH]  50
2013-02-20 23:05:07.250 [0x20 EBH]  b5
2013-02-20 23:05:07.254 [0x20 EBH]  04
2013-02-20 23:05:07.258 [0x20 EBH]  01
2013-02-20 23:05:07.262 [0x20 EBH]  00
2013-02-20 23:05:07.267 [0x20 EBH]  ff
2013-02-20 23:05:07.271 [0x20 EBH]  00
2013-02-20 23:05:07.275 [0x20 EBH]  0a
2013-02-20 23:05:07.279 [0x20 EBH]  03
2013-02-20 23:05:07.288 [0x20 EBH]  05
2013-02-20 23:05:07.296 [0x20 EBH]  20
2013-02-20 23:05:07.300 [0x20 EBH]  02
2013-02-20 23:05:07.304 [0x20 EBH]  03
2013-02-20 23:05:07.309 [0x20 EBH]  13
2013-02-20 23:05:07.313 [0x20 EBH]  90
2013-02-20 23:05:07.317 [0x20 EBH]  01
2013-02-20 23:05:07.321 [0x20 EBH]  b4
2013-02-20 23:05:07.326 [0x20 EBH]  00
2013-02-20 23:05:08.090 [0x20 EBH]  fe
2013-02-20 23:05:08.098 [0x20 EBH]  05
2013-02-20 23:05:08.102 [0x20 EBH]  04
2013-02-20 23:05:08.107 [0x20 EBH]  27
2013-02-20 23:05:08.111 [0x20 EBH]  00
2013-02-20 23:05:08.115 [0x20 EBH]  22
2013-02-20 23:05:08.119 [0x20 EBH]  00
2013-02-20 23:05:08.123 [0x20 EBH]  5a
2013-02-20 23:05:08.127 [0x20 EBH]  aa
2013-02-20 23:05:08.128 [0x20 EBH]  50 b5 04 01 00 ff 00 0a 03 05 20 02 03 13 90 01 b4 00 fe 05 04 27 00 22 00 5a
Speicherzugriffsfehler
root@wiregate907:/home/ebus/ebusd/src#

Bleibe dran und teste weiter

Ergänzung:

2013-02-21 05:35:07.418 [0x20 EBH]  00
2013-02-21 05:35:07.422 [0x20 EBH]  38
2013-02-21 05:35:07.426 [0x20 EBH]  00
2013-02-21 05:35:07.430 [0x20 EBH]  aa
2013-02-21 05:35:07.430 [0x20 EBH]  03 00 10 fe b5 05 03 4a 01 00 f4 b5 03 29 07 00 4f 00 05 07 00 02 00 38 00
Speicherzugriffsfehler
root@wiregate907:/home/ebus/ebusd/src#

Laufzeit ca. 1min

Grüße

Frank

[Gast]

Hallo Frank,

für mich sieht das so aus, daß das Trimming noch nicht sauber ist.

EDIT: Das ist ein guter Hinweis auf das Trimming - Da ist die Zeitdiffernz zu hoch.

2013-02-20 23:05:[B]07.326[/B] [0x20 EBH]  00
2013-02-20 23:05:[B]08.090[/B] [0x20 EBH]  fe

Oder es gab hier mehrere Buszugriffsversuche was zu einer Datenwurst führte.
Wenn SYN Zeichen fehlen bzw. gleichzeitige Buszugriffe kommen, kann die Datenwurst schon etwas länger werden.

War das in einer früheren Version auch schon so?

Wenn es für dich möglich ist dann könntest du valgrind installieren und dann so ausführen.

"valgrind --leak-check=full --show-reachable=yes ./ebusd -lALL -f -s"

Damit würden wir die Codezeile bekommen, wo der falsche Zugriff passiert.

Zur Vorsicht habe ich mal den Buffer für das Serial Device von 100 auf 256 gestellt. ==> wieder auf 100 rückgestellt.

[Frank0207]

valgrind ebusd Ergebnis

Hallo yuhu,

anbei die Fehlermeldung mit valgrind.

2013-02-21 10:15:07.796 [0x20 EBH]  34
2013-02-21 10:15:07.861 [0x20 EBH]  aa
2013-02-21 10:15:07.866 [0x20 EBH]  10 00 00 10 00 00 10 00 b5 01 00 00 00 10 ca b5 00 10 00 b5 00 10 00 10 34
==8220== Invalid read of size 4
==8220==    at 0x804FC6A: eb_cyc_data_recv (ebus-bus.c:1709)
==8220==  Address 0x34333c is not stack'd, malloc'd or (recently) free'd
==8220==
==8220== Process terminating with default action of signal 11 (SIGSEGV)
==8220==  Access not within mapped region at address 0x34333C
==8220==    at 0x804FC6A: eb_cyc_data_recv (ebus-bus.c:1709)
==8220==
==8220== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 12 from 1)
==8220== malloc/free: in use at exit: 121,060 bytes in 164 blocks.
==8220== malloc/free: 2,338 allocs, 2,174 frees, 4,904,340 bytes allocated.
==8220== For counts of detected errors, rerun with: -v
==8220== searching for pointers to 164 not-freed blocks.
==8220== checked 181,004 bytes.
==8220==
==8220==
==8220== 268 bytes in 1 blocks are still reachable in loss record 1 of 3
==8220==    at 0x4022D6E: malloc (vg_replace_malloc.c:207)
==8220==    by 0x804B443: msg_queue_init (utils.c:53)
==8220==    by 0x804A600: main (ebusd.c:656)
==8220==
==8220==
==8220== 58,968 bytes in 1 blocks are still reachable in loss record 2 of 3
==8220==    at 0x4022E8C: realloc (vg_replace_malloc.c:429)
==8220==    by 0x804D54B: eb_cmd_fill (ebus-bus.c:773)
==8220==    by 0x804DD34: eb_cmd_file_read (ebus-bus.c:918)
==8220==    by 0x804DF3D: eb_cmd_dir_read (ebus-bus.c:961)
==8220==    by 0x804A55D: main (ebusd.c:622)
==8220==
==8220==
==8220== 61,824 bytes in 162 blocks are still reachable in loss record 3 of 3
==8220==    at 0x4022D6E: malloc (vg_replace_malloc.c:207)
==8220==    by 0x804D803: eb_cmd_fill (ebus-bus.c:822)
==8220==    by 0x804DD34: eb_cmd_file_read (ebus-bus.c:918)
==8220==    by 0x804DF3D: eb_cmd_dir_read (ebus-bus.c:961)
==8220==    by 0x804A55D: main (ebusd.c:622)
==8220==
==8220== LEAK SUMMARY:
==8220==    definitely lost: 0 bytes in 0 blocks.
==8220==      possibly lost: 0 bytes in 0 blocks.
==8220==    still reachable: 121,060 bytes in 164 blocks.
==8220==         suppressed: 0 bytes in 0 blocks.
Speicherzugriffsfehler
root@wiregate907:/home/ebus/ebusd/src#

Ist die ebusd version mit vergrößertem Buffer im svn?

Grüße

Frank

[Gast]

Die Dekodierung der zyklischen ebus Nachrichten ist nun für alle Nachrichtentypen implementiert.

• Broadcast
• Master-Master
• Master-Slave

Ist von mir jedoch noch ungetestet.


@Frank - bitte auf diese Version upgraden und nochmals mit Valgrind ausführen. Am besten ein make distclean vor dem Bauen ausführen.

[Frank0207]

hier das Ergebnis

Hi yuhu,

anbei das Ergebnis:

2013-02-21 16:30:08.684 [0x20 EBH]  10 29 04 03 00 10 00 b5 60 10 00 ba 25 03 10 00 10 00 10 00 10 01 03 dc
==32751== Invalid read of size 4
==32751==    at 0x804FC6A: eb_cyc_data_recv (ebus-bus.c:1709)
==32751==  Address 0xbee6004f is not stack'd, malloc'd or (recently) free'd
==32751==
==32751== Process terminating with default action of signal 11 (SIGSEGV)
==32751==  Access not within mapped region at address 0xBEE6004F
==32751==    at 0x804FC6A: eb_cyc_data_recv (ebus-bus.c:1709)
==32751==
==32751== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 12 from 1)
==32751== malloc/free: in use at exit: 121,060 bytes in 164 blocks.
==32751== malloc/free: 10,310 allocs, 10,146 frees, 5,023,920 bytes allocated.
==32751== For counts of detected errors, rerun with: -v
==32751== searching for pointers to 164 not-freed blocks.
==32751== checked 181,004 bytes.
==32751==
==32751==
==32751== 268 bytes in 1 blocks are still reachable in loss record 1 of 3
==32751==    at 0x4022D6E: malloc (vg_replace_malloc.c:207)
==32751==    by 0x804B443: msg_queue_init (utils.c:53)
==32751==    by 0x804A600: main (ebusd.c:656)
==32751==
==32751==
==32751== 58,968 bytes in 1 blocks are still reachable in loss record 2 of 3
==32751==    at 0x4022E8C: realloc (vg_replace_malloc.c:429)
==32751==    by 0x804D54B: eb_cmd_fill (ebus-bus.c:773)
==32751==    by 0x804DD34: eb_cmd_file_read (ebus-bus.c:918)
==32751==    by 0x804DF3D: eb_cmd_dir_read (ebus-bus.c:961)
==32751==    by 0x804A55D: main (ebusd.c:622)
==32751==
==32751==
==32751== 61,824 bytes in 162 blocks are still reachable in loss record 3 of 3
==32751==    at 0x4022D6E: malloc (vg_replace_malloc.c:207)
==32751==    by 0x804D803: eb_cmd_fill (ebus-bus.c:822)
==32751==    by 0x804DD34: eb_cmd_file_read (ebus-bus.c:918)
==32751==    by 0x804DF3D: eb_cmd_dir_read (ebus-bus.c:961)
==32751==    by 0x804A55D: main (ebusd.c:622)
==32751==
==32751== LEAK SUMMARY:
==32751==    definitely lost: 0 bytes in 0 blocks.
==32751==      possibly lost: 0 bytes in 0 blocks.
==32751==    still reachable: 121,060 bytes in 164 blocks.
==32751==         suppressed: 0 bytes in 0 blocks.
Speicherzugriffsfehler
root@wiregate907:/home/ebus/ebusd/src#

Der Fehler ist jetzt nach einer Laufzeit con ca. 30 min aufgetreten.

Grüße

Frank

[Gast]

Hallo Frank,

du dürftest immer noch eine alte lib haben - ich habe beim letzten SVN commit bei logging was verändert und das fällt mir sofort auf.

Dazu kommt, dass der aktuelle Source auf Zeile 1709 ausserhalb einer Funktion ist und das kann nicht sein.

Also bitte mit "svn update" die aktuelle Version besorgen.
Im Verzeichnis ebusd eine "make distclean" ausführen. (löscht alle generierte Datein)
Und mit "./autogen.sh" neu bauen.

[Frank0207]

jetzt...

...ist was anders!

Hatte davor die rev 1517 drauf und jetzt die 1520.
distclean habe ich auch ausgeführt und dann alles neu erstellt.

root@wiregate907:/home/ebus/ebusd/src# valgrind --leak-check=full --show-reachable=yes ./ebusd -lALL -f -s
==13338== Memcheck, a memory error detector.
==13338== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==13338== Using LibVEX rev 1854, a library for dynamic binary translation.
==13338== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==13338== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==13338== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==13338== For more details, rerun with: -v
==13338==
2013-02-21 19:26:29.738 [NOT] /etc/ebusd/vaillant_get.csv
2013-02-21 19:26:30.993 [NOT] /etc/ebusd/vaillant_get.csv success
2013-02-21 19:26:31.012 [INF] command files read.
2013-02-21 19:26:31.078 [INF] /dev/ttyUSB0 opened.
2013-02-21 19:26:31.105 [INF] port 8888 opened.
2013-02-21 19:26:31.127 [INF] msg queue initialized.
==13338== Syscall param read(count) contains uninitialised byte(s)
==13338==    at 0x40E8F8E: read (in /lib/libc-2.7.so)
==13338==    by 0x804FEE8: eb_cyc_data_recv (ebus-bus.c:1842)
==13338==    by 0x8049C0C: main_loop (ebusd.c:475)
==13338==    by 0x804A5FC: main (ebusd.c:659)
==13338==
==13338== Syscall param read(buf) points to unaddressable byte(s)
==13338==    at 0x40E8F8E: read (in /lib/libc-2.7.so)
==13338==    by 0x804FEE8: eb_cyc_data_recv (ebus-bus.c:1842)
==13338==    by 0x8049C0C: main_loop (ebusd.c:475)
==13338==    by 0x804A5FC: main (ebusd.c:659)
==13338==  Address 0xbeb42000 is not stack'd, malloc'd or (recently) free'd
2013-02-21 19:26:31.416 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:31.422 [WAR] error read serial device
2013-02-21 19:26:31.768 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:31.770 [WAR] error read serial device
2013-02-21 19:26:31.967 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:31.969 [WAR] error read serial device
2013-02-21 19:26:32.580 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:32.582 [WAR] error read serial device
2013-02-21 19:26:33.137 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:33.139 [WAR] error read serial device
2013-02-21 19:26:33.317 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:33.319 [WAR] error read serial device
2013-02-21 19:26:33.501 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:33.503 [WAR] error read serial device
2013-02-21 19:26:33.514 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:33.516 [WAR] error read serial device
2013-02-21 19:26:33.789 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:33.791 [WAR] error read serial device
2013-02-21 19:26:34.536 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:34.538 [WAR] error read serial device
2013-02-21 19:26:35.021 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:35.023 [WAR] error read serial device
2013-02-21 19:26:35.325 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:35.327 [WAR] error read serial device
2013-02-21 19:26:35.633 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:35.635 [WAR] error read serial device
2013-02-21 19:26:36.249 [ERR] ebus-bus.c: 1021: eb_serial_recv: Error Bad address
2013-02-21 19:26:36.251 [WAR] error read serial device
^C==13338==
==13338== ERROR SUMMARY: 28 errors from 2 contexts (suppressed: 12 from 1)
==13338== malloc/free: in use at exit: 121,060 bytes in 164 blocks.
==13338== malloc/free: 383 allocs, 219 frees, 4,875,015 bytes allocated.
==13338== For counts of detected errors, rerun with: -v
==13338== searching for pointers to 164 not-freed blocks.
==13338== checked 180,884 bytes.
==13338==
==13338==
==13338== 268 bytes in 1 blocks are still reachable in loss record 1 of 3
==13338==    at 0x4022D6E: malloc (vg_replace_malloc.c:207)
==13338==    by 0x804B413: msg_queue_init (utils.c:53)
==13338==    by 0x804A5D0: main (ebusd.c:650)
==13338==
==13338==
==13338== 58,968 bytes in 1 blocks are still reachable in loss record 2 of 3
==13338==    at 0x4022E8C: realloc (vg_replace_malloc.c:429)
==13338==    by 0x804D68B: eb_cmd_fill (ebus-bus.c:657)
==13338==    by 0x804DE74: eb_cmd_file_read (ebus-bus.c:802)
==13338==    by 0x804E07D: eb_cmd_dir_read (ebus-bus.c:845)
==13338==    by 0x804A52D: main (ebusd.c:616)
==13338==
==13338==
==13338== 61,824 bytes in 162 blocks are still reachable in loss record 3 of 3
==13338==    at 0x4022D6E: malloc (vg_replace_malloc.c:207)
==13338==    by 0x804D943: eb_cmd_fill (ebus-bus.c:706)
==13338==    by 0x804DE74: eb_cmd_file_read (ebus-bus.c:802)
==13338==    by 0x804E07D: eb_cmd_dir_read (ebus-bus.c:845)
==13338==    by 0x804A52D: main (ebusd.c:616)
==13338==
==13338== LEAK SUMMARY:
==13338==    definitely lost: 0 bytes in 0 blocks.
==13338==      possibly lost: 0 bytes in 0 blocks.
==13338==    still reachable: 121,060 bytes in 164 blocks.
==13338==         suppressed: 0 bytes in 0 blocks.

Sieht nicht besser aus. Leider bin ich hier noch etwas überfordert;-)

Grüße

Frank

[Gast]

OK - bitte SVN 1522 testen.

Kannst du mir deine csv Datei schicken?

[Frank0207]

Test mit 1522...

Hallo Roland,

Test mit 1522 läuft und im Anhang meine CSV.
Habe diese auf meine Bedürfnisse etwas eingekürzt.

Grüße

Frank

[Gast]

Putty - ebusd

Zur Info: Für die Verbindung zum ebusd mittels Putty ist der raw Modus zu benutzen.

EDIT: Mit dem aktuelle Commit funktioniert nun auch der telnet Modus.

[JuMi2006]

Hallo Roland,

Freitag kam mein Pi an ... heute mal getestet ... der knxd läuft soweit ... allerdings bekomme ich ./autogen.sh nicht durch.

Das Zeug liegt auf /root/ebus Zugangsdaten bekommste per PN ...

root@smarthome:~/ebus/ebusd# ./autogen.sh
>>> aclocal/usr/bin/aclocal
./autogen.sh: 35: [: 0: unexpected operator
 command failed

Scheint am Raspbian zu liegen ...


EDIT:
Erledigt.
Dann eben ohne script Vielleicht sind die vielen Textdateien bei so einem Paket doch mal ganz sinnvoll

Vermelde dann jetzt eBusd und knxd auf Raspberry Pi - Schreibtisch wird leergeräumt und das zieht die Woche mal in den HWR .


Grüße!

[Gast]

Stabilisierungsphase

Ein paar Fragen an die Mitstreiter:

1. Welche Langzeiterfahrung habt ihr mit dem ebusd?
2. Fehlt noch etwas damit der Daemon produktiv werden kann?
3. Was und in welcher Form sollte dokumentiert werden?
4. Will sich jemand aktiv einbringen?

[JuMi2006]

1. durchweg positiv
2. Fleissarbeit in meinem KNX System, init Script (ich muss meines nochmal überarbeiten), logrotate (siehe init Script), Befehle für die anderen Systeme (ich bin glücklich)
3. Wenn man da ein Paket draus baut fehlt nur die Doku zur config des eBusd und den csv
4. Nicht mehr diesen Winter in C

ad 3.
Könnten eigentlich nur noch Feature Requests fehlen.