eBus->USB->Plugin->KNX

[Gast]

Mit Pufferung meine ich, dass ebusd und sein Client (ein ebusd.pl oder was-auch-immer) asynchron laufen.

Das habe ich vermutet. Ok, ist aus meiner Sicht ein "must have"

PS. Übrigens schlage ich vor, in krasser Abweichung vom Standard auch mehrfaches Senden im Fehlerfall (also >1 Wiederholung) per Option zuzulassen.

Das ist laut Spezifikation so definiert ist. Das habe ich getestet und Vaillant hält sich anscheinend daran. Danach muss der Bus jedoch wieder freigegeben werden.
Das danach ein weiterer oder mehrere Sendeversuche unternommen werden, ist auch mein Gedanke.

---

OK - Nachdem ich die positive Rückmeldung von MarcusF erhalten habe...

Perfekt, ebus_send funktioniert nun einwandfrei. Stresstest folgt noch, aber bisher sieht das gut aus.

Was die Diskussion über die Funktionen des ebusd angeht: Man sollte auch ohne lokal laufendes Perl in der Lage sein, mit dem eBus zu kommunizieren. Denn dann kann man auch Homeserver, EibPC und ähnliche Systeme darüber an den eBus anbinden.

Marcus

werde ich nun die ebus Schreibfunktionen in den Daemon einbauen. Ist ja nicht weiter spannend, da nur Copy & Paste bzw. Search & Replace.

Anschließend will ich die Daemon Config bauen, damit nicht ständig irgend welche Switches benutzt werden müssen.

Tja und dann wären wir auch schon bei der Netzwerkverbindung....dann reden wir nochmal darüber was alles benötigt wird.


Achja, fast hätte ich es vergessen.

Die Tools ebus_send und check will ich nicht so liegen lassen. Es wäre jetzt ein guter Zeitpunkt die Struktur noch etwas anzupassen.

ebusd, ebus_send und check hängen alle von ebus.c/h ab. Daher wandern die beiden tools in ein Verzeichnis unterhalb von ebusd.
Vielleicht kann mir da jemand helfen das / die Makefiles richtig anzupassen.

Danke.

[makki]

.. die Makefiles richtig anzupassen.

Erstmal alle .c/.h unter src/ würde die Sache vereinfachen

Makki

[Gast]

@makki:

von der Struktur dachte ich eher an sowas

Makefile
ChangeLog
INSTALL
README
COPYING
├── libebus
│   ├── ebus.c
│   ├── ebus.h
│   └── Makefile
├── src
│   ├── ebusd.c
│   ├── ebusd.h
│   ├── log.c
│   ├── log.h
│   ├── Makefile
│   ├── utils.c
│   └── utils.h
└── tools
    ├── check.c
    ├── ebus_send.c
    └── Makefile

[Fry]

Hallo zusammen,
jetzt krieg ich auch die ebus-Blues.

Ich habe begonnen, einfach mit ebusd den vorhandenen (cyclic) Traffic mitzuschneiden und mit Hilfe der offiziellen Specs in einem Perl-Skript zu interpretieren.

Erster Schritt war die Interpretation von PB und SB - soweit ok, die meisten Telegramme fallen in die doumentierten Kategorien.

Bevor ich fehlerhafte Daten konvertiere, wollte ich die CRC checken. Die Berechnung habe ich aus Ebus.pm übernommen (warum das Rad neu erfinden? Allerdings habe ich den Code übernommen, nicht einfach Ebus.pm eingebunden).

Jetzt kommt's: bei >99% der Telegramme stimmt die CRC nicht. Ist das normal? Oder muss ich da nochmal am Poti drehen?

VG, Fry

[makki]

Klingt plausibel, mit dem mischen von lib & daemon in einem Packerl bin ich aber auch erstmal ahnungslos; Solange es kompiliert, wird sich das hinfummeln lassen..

Wie die automakes in etwa aussehen könnten:
./Makefile.am

## Process this file with automake to produce Makefile.in

SUBDIRS = libebus src tools

ebusddocdir = ${prefix}/doc/ebus
ebusddoc_DATA = \
        README\
        COPYING\
        AUTHORS\
        ChangeLog\
        INSTALL\
        NEWS

INTLTOOL_FILES = intltool-extract.in \
        intltool-merge.in \
        intltool-update.in

EXTRA_DIST = $(ebusddoc_DATA) \
        $(INTLTOOL_FILES)

DISTCLEANFILES = intltool-extract \
        intltool-merge \
        intltool-update

# Remove doc directory on uninstall
uninstall-local:
        -rm -r $(ebusddocdir)

src/Makefile.am

## Process this file with automake to produce Makefile.in

AM_CPPFLAGS = \
        -DPACKAGE_LOCALE_DIR=\""$(prefix)/$(DATADIRNAME)/locale"\" \
        -DPACKAGE_SRC_DIR=\""$(srcdir)"\" \
        -DPACKAGE_DATA_DIR=\""$(datadir)"\" 

AM_CFLAGS =\
         -Wall\
         -g\
     -lpthread -leibclient

bin_PROGRAMS = ebusd

ebusd_SOURCES = \
        main.c \
        main.h

ebusd_LDFLAGS = 

ebusd_LDADD =

So oder so ähnlich

Makki

[Gast]

Jetzt kommt's: bei >99% der Telegramme stimmt die CRC nicht. Ist das normal? Oder muss ich da nochmal am Poti drehen?

Falls Du keine SYN Zeichnen zwischen den Telegrammen siehst, dreh mal am Poti?

Muss in etwas so aussehen.

backup src # ./ebusd -l3 -f
2013-01-15 21:00:04.353 [INF] serial device /dev/ttyUSB0 successfully opened.
2013-01-15 21:00:04.353 [INF] tcp port 8888 successfully opened.
2013-01-15 21:00:04.461 [DBG]  aa
2013-01-15 21:00:04.505 [DBG]  aa
2013-01-15 21:00:04.549 [DBG]  aa
2013-01-15 21:00:04.593 [DBG]  aa
2013-01-15 21:00:04.637 [DBG]  aa
2013-01-15 21:00:04.681 [DBG]  aa
2013-01-15 21:00:04.725 [DBG]  aa
2013-01-15 21:00:04.804 [DBG]  10 50 b5 05 07 2b 00 01 00 00 00 00 24 00 00 00 00 aa
2013-01-15 21:00:04.848 [DBG]  aa
2013-01-15 21:00:04.892 [DBG]  aa
2013-01-15 21:00:04.993 [DBG]  10 08 b5 11 02 03 00 1e 00 0a 8f 01 6d 09 7b 08 00 28 00 00 b4 00 aa
2013-01-15 21:00:05.036 [DBG]  aa
2013-01-15 21:00:05.080 [DBG]  aa
2013-01-15 21:00:05.155 [DBG]  10 08 b5 11 01 02 8a 00 05 00 00 c8 00 c8 ca 00 aa
2013-01-15 21:00:05.199 [DBG]  aa
2013-01-15 21:00:05.278 [DBG]  01 ec b5 05 08 4d 40 01 00 00 00 00 00 e7 00 00 00 00 aa
2013-01-15 21:00:05.357 [DBG]  10 ed b5 08 07 07 01 01 e0 03 e0 01 87 00 00 00 00 aa
2013-01-15 21:00:05.401 [DBG]  aa
2013-01-15 21:00:05.445 [DBG]  aa
2013-01-15 21:00:05.489 [DBG]  aa
2013-01-15 21:00:05.539 [DBG]  01 fe b5 05 05 4e f6 0e 00 80 ab aa
2013-01-15 21:00:05.583 [DBG]  aa
2013-01-15 21:00:05.627 [DBG]  aa
2013-01-15 21:00:05.671 [DBG]  aa
2013-01-15 21:00:05.715 [DBG]  aa

[JuMi2006]

@fry:

Einfach mal ein log posten, dann sieht man es besser. Ich hab auch versucht die CRC-Berechnung aus dem Modul zu lösen, bin daran allerdings gescheitert. Probiere es einfach mal mit dem Modul und schau ob es dann wirklich nicht passt.

[Gast]

@Makki:

Das mit den Makefiles für die Autotools sieht gut aus. Nur kenne ich mich damit überhaupt nicht aus.

ERLEDIGT: - Was ich machen kann ist, dass die ebus.c/h von ebusd und ebus_client auf den gleichen Stand bringen.

Den Rest müsste dann jemand machen, der sich mit dem Autozeugs wirklich auskennt.

[Fry]

Falls Du keine SYN Zeichnen zwischen den Telegrammen siehst, dreh mal am Poti?

Nein, ich sehe jede Menge SYNs.

Und @Jumi: die CRC-Berechnung stimmt bei mir überein mit dem Ergebnis aus EBus.pm - außer in dem Sonderfall, wenn A9-characters im String vorkommen. Da meine ich übrigens, die Routine calcCrcExpanded in EBus.pm hat einen Bug - sie expandiert nämlich AAs zu A9 01, aber sie expandiert nicht A9s zu A9 00.

Seht's euch an (Zeilen 55ff im EBus.pm-Code):

for ( my $i = 0 ; $i < length($str) ; $i++ ) {                                                                                                      
    my $chr = substr( $str, $i, 1 );                                                                                                                
    if ( ord($chr) == 170 ) {                                                                                                                       
        $tmp .= chr(0xA9) . chr(0x01);                                                                                                              
    }                                                                                                                                               
    else {                                                                                                                                          
        $tmp .= $chr;                                                                                                                               
    }                                                                                                                                               
}

Der Sonderfall AA/A9 soll mir hier aber erstmal egal sein. In allen anderen Fällen berechnet meine Routine das gleiche Ergebnis wie calcCrcExpanded. Leider stimmt dieses Ergebnis fast nie überein mit dem CRC auf dem Bus.

Beispiel:

2013-00-15 18:33:39.651 [DBG]  70 51 50 14 07 03 00 30 1a 1b 00 1e 4c 00 09 00 40 59 49 00 e8 00 6e 28 87 00 a8 aa

2013-00-15 18:33:39.651 [DBG]  Heizungsregler2 Mischer2 SollWarmwasser(5014) 7( 03 00 30 1a 1b 00 1e ) [4c?dd] ACK 9( 00 40 59 49 00 e8 00 6e 28 ) [87?16] ACK a8 SYN

(oben der raw Log, unten meine Interpretation. In den eckigen Klammern die abweichenden CRCs).

Irgendjemand eine Idee dazu?

VG; Fry

[JuMi2006]

Hallo Fry,

bzgl. des CRC hab ich auch keinen Schimmer. Aber Dein Interpretation hat auch einen Haken.

70 Master
51 Slave
50 Primärbefehl
14 Sekundärbefehl
07 Anzahl-Datenbytes
03 #1
00 #2
30 #3
1a #4
1b #5
00 #6
1e #7
4c CRC (51-1e)
00 ACK (vom Slave)
09 Anzahl-Datenbytes
00 #1
40 #2
59 #3
49 #4
00 #5
e8 #6
00 #7
6e #8
28 #9
87 CRC
00 ACK (vom Master)
a8 ??? Was ist das? Das hat hier nix zu suchen. ???
aa SYN (vom Master)


Grüße

[Fry]

Du hast völlig recht, das habe ich natürlich auch gesehen.

Erste Reaktion: naja, wenn die CRC nicht stimmt, gab es wohl einen Übertragungsfehler.

Allerdings sehe ich praktisch NUR Telegramme mit fehlerhafter (=anderer als von mir bzw EBus.pm berechneter) CRC.

Hier ein anderes Beispiel:

2013-00-15 14:33:19.735 [DBG]  70 51 50 14 07 03 00 34 b7 0c 00 4c f9 00 09 00 40 04 00 00 0b 89 3d 00 d5 aa

2013-00-15 14:33:19.735 [DBG]  Heizungsregler2 Mischer2 SollWarmwasser(5014) 7( 03 00 34 b7 0c 00 4c ) [f9?02] ACK 9( 00 40 04 00 00 0b 89 3d 00 ) [d5?f1] SYN

Muss wohl nochmal am Poti drehen. Bin leider gerade auf der anderen Seite der Erde.

VG, Fry

[JuMi2006]

Da fehlt das ACK ... puh seltsam ... erstmal Poti drehen und dann weiter wundern.

Du wärst der erste der von einer abweichenden CRC-Berechnung berichtet.

[Gast]

Was für zwischendurch, ich denke ich habe hier ein Optimum gefunden.

Der alleinige Buszugriff ist beim Senden das Hauptproblem.

Nun habe ich beim Skip (also die Anzahl der SYN Zeichen welche ausgelassen werden, wenn ein Problem festgestellt wurde) das als Funktion von retry abgebildet.

skip += retry*2;

Der Aufruf erfolgt dann mit -r 7, also 7 Versuchen den Buszugriff zu bekommen.

    from: 2013-01-15 22:38:09
      to: 2013-01-15 22:40:54
wait (s): 0
 repeats: 100
commands: 12
    send: 1200
  errors: 0

[JuMi2006]

Also beim Versuch nach einem SYN zu senden wird im Fehlerfall hier 14 SYN Zeichen gewartet und dann erneut gesendet. Das Ganze wiederholt sich dann 7 mal ?

[Fry]

Hab noch was gefunden.

2013-00-15 15:33:22.163 [DBG]  f1 fe 05 03 08 02 08 00 ff 66 ff 29 ff 74 aa

2013-00-15 15:33:22.163 [DBG]  Heizungsregler Broadcast Aussentemperatur(0503) 8( 02 08 00 ff 66 ff 29 ff ) [74?18] SYN

Oben der Log, unten die Interpretation. Dieses Telegramm ist identisch so zigfach über den Bus gelaufen. An einen Übertragungsfehler mag ich deshalb nicht glauben.

Nur: die CRC der Folge F1 FE 05 03 08 02 08 00 FF 66 FF 29 FF ist 18h, nicht 74h.

Mag das mal jemand überprüfen?

Bin schon fast daran zu glauben, dass Wolf die CRCs mit einem anderen Generatorpolynom berechnet... (das wäre dann die nächste zu überprüfende Sache)

VG, Fry