eBus->USB->Plugin->KNX

[Gast]

Irgendwie habt Ihr mich nun in den letzten Posts abgehängt, aber ich versuche mal wiederzugeben was ich verstanden habe (ich lass jetzt mal das 0x für Hex weg):

30 76 50 22 03 57 44 03 a9 01 00 02 00 80 ac 00 aa

30 76 bedeutet Antwort vom Master 03 an Slave von Master 09.
50 22 ist irgendein Wolf/Kromschroeder spezifischer Befehl
03 ist die Bytelänge, also 3 Bytes

Nachdem nun aber deutlich mehr Bytes kommen ist die Schlussfolgerung, dass es sich um eine Antwort handelt.
57 44 03 wäre damit die Antwort, oder?
a9 01 00 kennzeichnet den Beginn der urspr. Antwort vom Slave?
02 gibt die Anzahl der Bytes der Slaveantwort wieder?
00 80 waren die Bytes der Slaveantwort?
ac ist die Checksumme des Gesamtpaketes?
00 aa ist ACK und SYN des Gesamtpaketes

Sorry, bin gerade etwas gaga, insb. wie ich das in eine Tabelle bringen soll
Cheers,
Oliver

Licht ins Dunkel!

Es handelt sich dabei um ein Master Slave Telegramm mit dem bekannten Aufbau.
[QQ ZZ PB SB NN Dx CRC] [ACK NN Dx CRC] [ACK SYN]

Master sendet an Slave
QQ 30 Master (Sender)
ZZ 76 Slave (Empfänger)
PB 50 Primär Befehl
SB 22 Sekundär Befehl
NN 03 Anzahl Datenbytes
D1 57
D2 44
D3 03
CRC a9 01 (von QQ-D3 vom Master - erweitert da crc=aa)

Antwort vom Slave
ACK 00 (crc von Master Telegramm ist korrekt)
NN 02
D1 00
D2 80
CRC ac (vom ACK/NN-D2 vom Slave - da ACK 00 ist kann es auch weggelassen werden)

Bestätigung vom Master an den Slave
ACK 00 (crc von Slave Telegramm ist korrekt)
SYN aa (Freigabe des Buses)

[JuMi2006]

Nochmal ein A9 00 was nicht aus einer CRC-Berechnung kommt.

70 50 b5 04 01 0d 2c 00 05 1a 00 a9 00 01 16 7f 00 aa

Gruß

[Sandman60]

Moin Mirko, Roland,

danke für das ausführliche Feedback. Verstanden. Habe diesen Teil der Spec wohl irgendwie überlesen/nicht gefunden.

Zum weiteren Vorgehen:
Nach einer ersten Schnellsuche in meinen Dumps habe ich auch so einige "a9 00" gefunden. Macht es Sinn diese hier zu posten? Brauchen wir hier ein besonderes Handling?

Cheers,
Oliver

[Gast]

Moin Mirko, Roland,

danke für das ausführliche Feedback. Verstanden. Habe diesen Teil der Spec wohl irgendwie überlesen/nicht gefunden.

Zum weiteren Vorgehen:
Nach einer ersten Schnellsuche in meinen Dumps habe ich auch so einige "a9 00" gefunden. Macht es Sinn diese hier zu posten? Brauchen wir hier ein besonderes Handling?

Cheers,
Oliver

Nein, das Posten ist nicht mehr notwendig. Danke an alle fürs Rückmelden.

Zum besonderen Handling:

Benötigt wird das beim Senden und Empfangen von Telegrammen bzw. zum Auswerten. Die notwendigen Funktionen ebus_esc() bzw. ebus_unesc() für das Handling des Telegrammverkehrs sind schon geschrieben.

[Gast]

negatives ACK vom Slave oder Master

Falls jemand sowas schon bekommen hat, bitte posten.

Hintergrund:

Ich habe hier eine VWS 101/3.
Wenn ich dem Empfänger 15 das Telegramm für "Energie Dezember Vorjahr" schicke sieht das so aus.

ff 15 b5 09 03 0d 85 58 80 und die Antwort lautet 00 02 d9 11 4e da alles richtig ist.

Nun habe ich bewußt ein falsches CRC geschickt und als Antwort ein negatives ACK erwartet.

ff 15 b5 09 03 0d 85 58 34 und als Antwort kommt nichts - ein AutoSYN aa folgt

[Rocky]

Ich weiss nicht ob's hilft oder alles auch schon bekannt ist aber für mich war dieses Doc seht informativ. (5.1 7.4 7.5)

http://pixelland.de/eBUS/Spec_Prot_12_V1_3_1.pdf

VG
Thomas

@all: Danke das ihr euch alle so reinkniet, Respekt, Lob und Anerkennung

[JuMi2006]

Womit hast Du das jetzt gesendet? Bei meinen damaligen Versuchen wurde mir ein falsches ACK immer mit 0xff quittiert, ich hab allerdings erst heute Abend wieder Zugriff auf hterm.

Grüße

[Gast]

Ich weiss nicht ob's hilft oder alles auch schon bekannt ist aber für mich war dieses Doc seht informativ. (5.1 7.4 7.5)

http://pixelland.de/eBUS/Spec_Prot_12_V1_3_1.pdf

VG
Thomas

@all: Danke das ihr euch alle so reinkniet, Respekt, Lob und Anerkennung

Ja, ist mir bekannt, da ich danach implementiere.

Womit hast Du das jetzt gesendet? Bei meinen damaligen Versuchen wurde mir ein falsches ACK immer mit 0xff quittiert, ich hab allerdings erst heute Abend wieder Zugriff auf hterm.

Grüße

Aktuelle Version von serial_write

Vielleicht kann das jemand verifizieren (egal mit was gesendet wird).

QQ 15 b5 09 03 0d 85 58 ungültiges CRC

[JuMi2006]

Dort wird doch das CRC automatisch berechnet oder kannst Du das mal als Test ins SVN schieben?

[JuMi2006]

Nun habe ich bewußt ein falsches CRC geschickt und als Antwort ein negatives ACK erwartet.

ff 15 b5 09 03 0d 85 58 34 und als Antwort kommt nichts - ein AutoSYN aa folgt

Also hier kommt mit hterm wie erwartet:

ff 15 b5 09 03 0d 85 58 34 ff aa

Grüße

[Gast]

Danke fürs testen.

Ich konnte es bis jetzt auch nicht mehr nachstellen. Das kommt in die Kategorie: Einmal ist Keinmal

Eine neue bitte.

Ich bräuchte ein Master Master Telegramm zum testen.

roland

[Fry]

@alle: tausend Dank für die Hilfe. Jetzt nutze ich auch das e-service-Interface, und ich sehe die "aa"s und die Telegramme. Endlich kann ich hier mitreden :-)
VG
Fry

[JuMi2006]

@fry: Das ist toll!
Für das parsen der config suche ich immernoch einen freiwilligen
https://knx-user-forum.de/276409-post162.html

Grüße

[Fry]

Einen kleinen Config-Parser from scratch schreiben, sehe ich nicht als das große Problem. Außer, der soll irgendwelchen hohen Standards genügen. JSON kann ich nicht einschätzen, habe mich damit nicht beschäftigt. Ein Config-File vom Stil eines CSV oder einer typischen bash-artigen Konfig sollte kein großes Thema sein.

Beschreibe doch bitte mal die Aufgabe genauer (Beispiel-Konfig, gewünschtes Ergebnis des Parsers).

VG, Fry

[Gast]

Ihr solltet Euch das mal ansehen.

Da ist jemand schon viel weiter.

http://www.ip-symcon.de/forum/thread...eBus-Connector

http://www.ip-symcon.de/forum/thread...7-eBus-Manager