[ebusd] Frage zu command.csv

[Matthi]

Nein, am Wochenende war das Wetter einfach zu Geil, da habe ich mal ein Ausflug mit meiner Familie gemacht.

MfG Matthias

Hi,

bist Du schon ein Stück weiter gekommen?

roland

[Matthi]

nicht wirklich, ich habe nur eine VMWare auf einem anderen Windows PC mit freetz.habe da auch testweise schonmal ebusD laufen gehabt mit usb-COM-adapter beim Raspi benutze ich den onbord UART. das teste ich mal am Wochenende.

Mfg Matthi

Jein.

Kannst Du das temporär auf einem anderen Linux Rechner mit valgrind testen bis der Fehler auftritt?

[Matthi]

Hallo yuhu, haste eine Idee?

[Matthi]

Ich glaub ich bin zu blöd dazu:

pi@raspberrypi /usr/bin/ebusd $ sudo valgrind --leak-check=full --show-reachable=yes ./ebusd
==8716== Memcheck, a memory error detector
==8716== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8716== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8716== Command: ./ebusd
==8716==
2014-02-10 22:47:47.878 [EBH]   10 50 b5 05 07 2b 00 01 00 00 00 00 24 00 00 00 00
disInstr(arm): unhandled instruction: 0xF1010200
                 cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)
==8716== valgrind: Unrecognised instruction at address 0x4843588.
==8716==    at 0x4843588: ??? (in /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so)
==8716== Your program just tried to execute an instruction that Valgrind
==8716== did not recognise.  There are two possible reasons for this.
==8716== 1. Your program has a bug and erroneously jumped to a non-code
==8716==    location.  If you are running Memcheck and you just saw a
==8716==    warning about a bad jump, it's probably your program's fault.
==8716== 2. The instruction is legitimate but Valgrind doesn't handle it,
==8716==    i.e. it's Valgrind's fault.  If you think this is the case or
==8716==    you are not sure, please let us know and we'll try to fix it.
==8716== Either way, Valgrind will now raise a SIGILL signal which will
==8716== probably kill your program.
==8716==
==8716== Process terminating with default action of signal 4 (SIGILL)
==8716==  Illegal opcode at address 0x4843588
==8716==    at 0x4843588: ??? (in /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so)
==8716==
==8716== HEAP SUMMARY:
==8716==     in use at exit: 428,008 bytes in 547 blocks
==8716==   total heap usage: 1,133 allocs, 586 frees, 57,778,111 bytes allocated
==8716==
==8716== 272 bytes in 1 blocks are still reachable in loss record 1 of 4
==8716==    at 0x4835978: malloc (vg_replace_malloc.c:263)
==8716==    by 0xA7E7: msg_queue_init (utils.c:53)
==8716==    by 0x951F: main (ebusd.c:738)
==8716==
==8716== 1,104 bytes in 1 blocks are still reachable in loss record 2 of 4
==8716==    at 0x4835A7C: realloc (vg_replace_malloc.c:632)
==8716==    by 0xE023: eb_cmd_fill (ebus-cmd.c:880)
==8716==    by 0xE1B3: eb_cmd_file_read (ebus-cmd.c:936)
==8716==    by 0xE397: eb_cmd_dir_read (ebus-cmd.c:984)
==8716==    by 0x94B3: main (ebusd.c:706)
==8716==
==8716== 211,072 bytes in 1 blocks are still reachable in loss record 3 of 4
==8716==    at 0x4835A7C: realloc (vg_replace_malloc.c:632)
==8716==    by 0xDB1F: eb_cmd_fill (ebus-cmd.c:780)
==8716==    by 0xE1B3: eb_cmd_file_read (ebus-cmd.c:936)
==8716==    by 0xE397: eb_cmd_dir_read (ebus-cmd.c:984)
==8716==    by 0x94B3: main (ebusd.c:706)
==8716==
==8716== 215,560 bytes in 544 blocks are still reachable in loss record 4 of 4
==8716==    at 0x4835978: malloc (vg_replace_malloc.c:263)
==8716==    by 0xDD4B: eb_cmd_fill (ebus-cmd.c:835)
==8716==    by 0xE1B3: eb_cmd_file_read (ebus-cmd.c:936)
==8716==    by 0xE397: eb_cmd_dir_read (ebus-cmd.c:984)
==8716==    by 0x94B3: main (ebusd.c:706)
==8716==
==8716== LEAK SUMMARY:
==8716==    definitely lost: 0 bytes in 0 blocks
==8716==    indirectly lost: 0 bytes in 0 blocks
==8716==      possibly lost: 0 bytes in 0 blocks
==8716==    still reachable: 428,008 bytes in 547 blocks
==8716==         suppressed: 0 bytes in 0 blocks
==8716==
==8716== For counts of detected and suppressed errors, rerun with: -v
==8716== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 6)
pi@raspberrypi /usr/bin/ebusd $

Las den ebusd einfach mit valgrind eine Zeit lang laufen. Der Segment fault wird schon kommen, wenn er noch da ist.

[Matthi]

so, habe das valgrind mal ausgeführt, aber das segmentation fault kommt grad nicht, ich dachte der wartet da irgendwie drauf:

pi@raspberrypi /usr/bin $ valgrind --leak-check=full --show-reachable=yes ./ebusd/ebusd
==8071== Memcheck, a memory error detector
==8071== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8071== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8071== Command: ./ebusd/ebusd
==8071==
==8071==
==8071== HEAP SUMMARY:
==8071==     in use at exit: 360 bytes in 1 blocks
==8071==   total heap usage: 11 allocs, 10 frees, 10,498 bytes allocated
==8071==
==8071== 360 bytes in 1 blocks are still reachable in loss record 1 of 1
==8071==    at 0x4835978: malloc (vg_replace_malloc.c:263)
==8071==    by 0x48B6DAF: __fopen_internal (iofopen.c:76)
==8071==    by 0x1023F: log_open (log.c:88)
==8071==    by 0x949B: main (ebusd.c:696)
==8071==
==8071== LEAK SUMMARY:
==8071==    definitely lost: 0 bytes in 0 blocks
==8071==    indirectly lost: 0 bytes in 0 blocks
==8071==      possibly lost: 0 bytes in 0 blocks
==8071==    still reachable: 360 bytes in 1 blocks
==8071==         suppressed: 0 bytes in 0 blocks
==8071==
==8071== For counts of detected and suppressed errors, rerun with: -v
==8071== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 6)
pi@raspberrypi /usr/bin $ ==8076==
==8076== HEAP SUMMARY:
==8076==     in use at exit: 0 bytes in 0 blocks
==8076==   total heap usage: 15 allocs, 15 frees, 19,132 bytes allocated
==8076==
==8076== All heap blocks were freed -- no leaks are possible
==8076==
==8076== For counts of detected and suppressed errors, rerun with: -v
==8076== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 6)
d/ebusdd --leak-check=full --show-reachable=yes ./ebusd
==8078== Memcheck, a memory error detector
==8078== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8078== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8078== Command: ./ebusd/ebusd
==8078==
==8078==
==8078== HEAP SUMMARY:
==8078==     in use at exit: 360 bytes in 1 blocks
==8078==   total heap usage: 11 allocs, 10 frees, 10,498 bytes allocated
==8078==
==8078== 360 bytes in 1 blocks are still reachable in loss record 1 of 1
==8078==    at 0x4835978: malloc (vg_replace_malloc.c:263)
==8078==    by 0x48B6DAF: __fopen_internal (iofopen.c:76)
==8078==    by 0x1023F: log_open (log.c:88)
==8078==    by 0x949B: main (ebusd.c:696)
==8078==
==8078== LEAK SUMMARY:
==8078==    definitely lost: 0 bytes in 0 blocks
==8078==    indirectly lost: 0 bytes in 0 blocks
==8078==      possibly lost: 0 bytes in 0 blocks
==8078==    still reachable: 360 bytes in 1 blocks
==8078==         suppressed: 0 bytes in 0 blocks
==8078==
==8078== For counts of detected and suppressed errors, rerun with: -v
==8078== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 6)
pi@raspberrypi /usr/bin $ ==8082==
==8082== HEAP SUMMARY:
==8082==     in use at exit: 0 bytes in 0 blocks
==8082==   total heap usage: 15 allocs, 15 frees, 19,132 bytes allocated
==8082==
==8082== All heap blocks were freed -- no leaks are possible
==8082==
==8082== For counts of detected and suppressed errors, rerun with: -v
==8082== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 6)
d/ebusdd --leak-check=full --show-reachable=yes ./ebusd
==8084== Memcheck, a memory error detector
==8084== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8084== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8084== Command: ./ebusd/ebusd
==8084==
==8084==
==8084== HEAP SUMMARY:
==8084==     in use at exit: 360 bytes in 1 blocks
==8084==   total heap usage: 11 allocs, 10 frees, 10,498 bytes allocated
==8084==
==8084== 360 bytes in 1 blocks are still reachable in loss record 1 of 1
==8084==    at 0x4835978: malloc (vg_replace_malloc.c:263)
==8084==    by 0x48B6DAF: __fopen_internal (iofopen.c:76)
==8084==    by 0x1023F: log_open (log.c:88)
==8084==    by 0x949B: main (ebusd.c:696)
==8084==
==8084== LEAK SUMMARY:
==8084==    definitely lost: 0 bytes in 0 blocks
==8084==    indirectly lost: 0 bytes in 0 blocks
==8084==      possibly lost: 0 bytes in 0 blocks
==8084==    still reachable: 360 bytes in 1 blocks
==8084==         suppressed: 0 bytes in 0 blocks
==8084==
==8084== For counts of detected and suppressed errors, rerun with: -v
==8084== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 6)
pi@raspberrypi /usr/bin $ ==8088==
==8088== HEAP SUMMARY:
==8088==     in use at exit: 0 bytes in 0 blocks
==8088==   total heap usage: 15 allocs, 15 frees, 19,132 bytes allocated
==8088==
==8088== All heap blocks were freed -- no leaks are possible
==8088==
==8088== For counts of detected and suppressed errors, rerun with: -v
==8088== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 6)

na toll, dann muss ich mal ne auswertung machen, wie oft das paket kaputt ist, was gesendet wird um den vaillant jungs das zu erzählen.... nich das irgendwas bald kaputt geht

Ich würde selbst mal probieren, ob du das nicht verbessern kannst.

Wie mache ich das jetzt,ich lasse den ebusd laufen und starte gleichzeitig dieses valgrind? ich probiers mal

Du must valgrind mit ebusd im Vordergrund starten. Dranhängen geht nicht.

valgrind ./ebusd -f ....

[Matthi]

na toll, dann muss ich mal ne auswertung machen, wie oft das paket kaputt ist, was gesendet wird um den vaillant jungs das zu erzählen.... nich das irgendwas bald kaputt geht

So, das ding installiert sich grad, ich habe übrigens als betriebssystem das standart raspian wheezy installiert.

Wie mache ich das jetzt,ich lasse den ebusd laufen und starte gleichzeitig dieses valgrind? ich probiers mal


MfG Matthi

Kein problem, wenn du mir verätst wo ich das runterladen kann und wie ich das installieren kann.

Kommt darauf an was du einsetzt. Auf meine Raspberry mit einem Debian Image kann ich bequem mit "apt-get install valgrind" die Installation durchführen.

Macht eigentlich diese problemenur meine wärmepumpe oder andere auch?

Du bist der Erste. Das ursächliche Problem ist die miese Qualtität der Signale am Bus.

[Matthi]

Kein problem, wenn du mir verätst wo ich das runterladen kann und wie ich das installieren kann.

Macht eigentlich diese problemenur meine wärmepumpe oder andere auch?

Wenn ich das nachstelle paßt alles.

tools/csv tools/. -ad
2014-02-09 23:51:43.110 [NOT] tools/./cyc.csv
2014-02-09 23:51:43.110 [NOT] tools/./cyc.csv success
2014-02-09 23:51:43.110 [INF] [000] cyc :                    vwl.OutUnitData                                   (type: MS) E0B52100         (len: 5) [7] ==> AusseneinheitDaten
2014-02-09 23:51:43.110 [INF]           stat1                sd pos: 1             bcd [ 1.00] [-]     -    -
2014-02-09 23:51:43.110 [INF]           stat2                sd pos: 2             bcd [ 1.00] [-]     -    -
2014-02-09 23:51:43.110 [INF]           sole                 sd pos: 3,4           d2c [ 1.00] [°C]     -    Temperatur
2014-02-09 23:51:43.110 [INF]           zuluft               sd pos: 5,6           d2c [ 1.00] [°C]     -    Temperatur
2014-02-09 23:51:43.110 [INF]           stat3                sd pos: 7             bcd [ 1.00] [-]     -    -
2014-02-09 23:51:43.110 [INF]           fanspeed             sd pos: 8             d1b [10.00] [Upm]     -    Drehzahl
2014-02-09 23:51:43.110 [INF]           fanpower             sd pos: 9             d1b [ 1.00] [%]     -    Power
2014-02-09 23:51:43.110 [INF] 
Test command >cyc vwl OutUnitData<
2014-02-09 23:51:43.110 [EBH] 1 03 e0 b5 21 05 00 02 07 00 e7 65 80 42 40 a0 10 d0 12 d0 10 10 50 1b 90 0d fc 23 b5 05 07
2014-02-09 23:51:43.110 [EBH] 2 2b 00 01 00 00 00 00 79 00 00 00 00
2014-02-09 23:51:43.110 [NOT]  found: E0B5210500 type: MS ==> id: 0
2014-02-09 23:51:43.110 [WAR] Slave DB Len Error (66 > 12)
2014-02-09 23:51:43.110 [NOT]  found: E0B5210500 type: MS ==> id: 0
2014-02-09 23:51:43.110 [DBG] id: 0 elem: 0 p1: 1 p2: 0 p3: 0 p4: 0
2014-02-09 23:51:43.110 [DBG] buf: 0
2014-02-09 23:51:43.110 [DBG] id: 0 elem: 1 p1: 2 p2: 0 p3: 0 p4: 0
2014-02-09 23:51:43.110 [DBG] buf: 0
2014-02-09 23:51:43.110 [DBG] id: 0 elem: 2 p1: 3 p2: 4 p3: 0 p4: 0
2014-02-09 23:51:43.110 [DBG] buf: 0.000000
2014-02-09 23:51:43.110 [DBG] id: 0 elem: 3 p1: 5 p2: 6 p3: 0 p4: 0
2014-02-09 23:51:43.110 [DBG] buf: 0.000000
2014-02-09 23:51:43.110 [DBG] id: 0 elem: 4 p1: 7 p2: 0 p3: 0 p4: 0
2014-02-09 23:51:43.110 [DBG] buf: 0
2014-02-09 23:51:43.110 [DBG] id: 0 elem: 5 p1: 8 p2: 0 p3: 0 p4: 0
2014-02-09 23:51:43.110 [DBG] buf: 0.000000
2014-02-09 23:51:43.110 [DBG] id: 0 elem: 6 p1: 9 p2: 0 p3: 0 p4: 0
2014-02-09 23:51:43.110 [DBG] buf: 0.000000
tcpbuf: 0 0 0.000000 0.000000 0 0.000000 0.000000
 tcpbuflen: 42

Im Moment habe ich keine Ahnung was es da haben kann.

Wenn du Valgrind installieren kannst, dann wäre folgender Aufruf (nicht als Daemon) gut:

valgrind --leak-check=full --show-reachable=yes ./ebusd

Damit würden wir einen Hinweis bekommen, wo das Ding rausfliegt.

[Matthi]

sowas wirst du finden: 2014-02-08 19:45:02.164 [WAR] Slave DB Len Error (66 > 12)

ah, ich sitz grad vor der ssh konsole und beobachte das geschehen. meine Frau fragte übrigens, grad was das sein soll: Das ist die MATRIX ;-)
Folgendes habe ich schon gesehen:

Mit neuer ebud-version bei Fehlern:

2014-02-09 22:52:47.492 [EBH]   03 e0 b5 21 05 00 06 07 00 e7 86 80 42 40 a0 04 94 02 3a 02 02 42 03 52 ff
2014-02-09 22:52:47.493 [NOT]  found: E0B5210500 type: MS ==> id: 68
2014-02-09 22:52:47.493 [WAR] Slave DB Len Error (66 > 12)

Wenn das Datenpaket richtig kommt:

2014-02-09 22:58:27.540 [EBH]   03 e0 b5 21 05 00 05 07 00 e7 64 00 09 01 06 f3 ff 29 00 07 3f 46 77 00
2014-02-09 22:58:27.541 [NOT]  found: E0B5210500 type: MS ==> id: 68
2014-02-09 22:58:27.541 [DBG] id: 68 elem: 0 p1: 1 p2: 0 p3: 0 p4: 0
2014-02-09 22:58:27.541 [DBG] buf: 1
2014-02-09 22:58:27.541 [DBG] id: 68 elem: 1 p1: 2 p2: 0 p3: 0 p4: 0
2014-02-09 22:58:27.541 [DBG] buf: 6
2014-02-09 22:58:27.541 [DBG] id: 68 elem: 2 p1: 3 p2: 4 p3: 0 p4: 0
2014-02-09 22:58:27.541 [DBG] buf: -0.812500
2014-02-09 22:58:27.542 [DBG] id: 68 elem: 3 p1: 5 p2: 6 p3: 0 p4: 0
2014-02-09 22:58:27.542 [DBG] buf: 2.562500
2014-02-09 22:58:27.542 [DBG] id: 68 elem: 4 p1: 7 p2: 0 p3: 0 p4: 0
2014-02-09 22:58:27.542 [DBG] buf: 7
2014-02-09 22:58:27.542 [DBG] id: 68 elem: 5 p1: 8 p2: 0 p3: 0 p4: 0
2014-02-09 22:58:27.542 [DBG] buf: 630.000000
2014-02-09 22:58:27.542 [DBG] id: 68 elem: 6 p1: 9 p2: 0 p3: 0 p4: 0
2014-02-09 22:58:27.542 [DBG] buf: 70.000000
2014-02-09 22:58:27.543 [EBS] 1 6 -0.812500 2.562500 7 630.000000 70.000000

Übrigens, das sind -0,8°C Soletemperatur und 2,6°C Zulufttemp zum Wärmetauscher und 630Upm des Lüfters bei 70% Anteuerung

scheint zu laufen, mal sehen obs bis morgen durchläuft, dann gehts!

EDIT:

läuft nicht:

2014-02-09 23:13:27.855 [EBH] 1 03 e0 b5 21 05 00 02 07 00 e7 65 80 42 40 a0 10 d0 12 d0 10 10 50 1b 90 0d [COLOR=Red]fc 23 b5 05 07[/COLOR]
2014-02-09 23:13:27.855 [EBH][COLOR=Black] [/COLOR][COLOR=Red][COLOR=Black]2[/COLOR] 2b 00 01 00 00 00 00 79 00 00 00 00[/COLOR]
Segmentation fault

da ist noch irgendwie ein 2tes paket mit drinn, hier grad mal rot gekennzeichnet

MfG Matthi

Steht denn dann später auch im LOG drin, wenn ein segmentation fault durchgelaufen ist???

sowas wirst du finden: 2014-02-08 19:45:02.164 [WAR] Slave DB Len Error (66 > 12)