eBus->USB->Plugin->KNX

[MarcusF]

Wollte meinen Adapter auch schonmal anschließen. Unser Solarmodul hat dafür auch außen einen Anschluss. Sieht aus wie ein Western-Stecker. Dachte da würde ein normaler 4-poliger Telefonstecker reinpassen...aber leider nicht. Ist kleiner :-(

Die Modularstecker (RJ-11, RJ-12) für Telefone sind eigentlich 6-polig. Es gibt auch 4-polige Modularstecker, die sind schmaler (RJ-10) und werden oft für den Anschluss von Telefonhörern benutzt. Da könntest Du fündig werden.

Marcus

[kleinklausi]

Hi Mirko,

@moritz, genau das meinte ich. Die Telegramme bestätigen auch den Verdacht.

ok, dann werde ich die data_pos für alle Zeilen anpassen und bei 1 anfangen.

1. Ein Broadcast Telegramm (Ziel=0xFE) bekommt natürlich kein ACK (0x00) und sendet das SYN (0xAA) direkt im Anschluss.
2. Die cycle Telegramme bei Wolf sind keine Anfragetelegramme i.d.S. dass der Empfänger die auszuwertenden Daten sendet. Daraus folgt dann dass answer_bytes eben 0 ist bzw. erstmal leer ist. Ich wäre dennoch für das ausfüllen der Spalte. Nach den Datenbytes kommt dann lediglich das CRC, dann das ACK vom Empfänger und das SYN des Senders.

Das blicke ich nicht. Was soll ich als answer_bytes eintragen? 00? Das ist aber ja das ACK, oder? Oder sollen answer_bytes und databytes gleich sein?

Das interpretieren von Bits müsste dann das Plugin oder was immer übernehmen.

Jepp, hört sich sinnvoll an.

Gruß

[kleinklausi]

1. bei Service 05 03 gibt es laut Spezifikatioion zwei Blöcke. Diese werden über byte 06 angegeben. Allerdings habe ich bei mir bisher nur Block 01 gesehen.

Hi Mirko,

Die aktuelle Konfiguration deckt im Moment nicht den folgenden Fall ab: Service 05 03 - Betriebsdaten des Feuerungsautomaten an den Regler.

Hier gibt es für einen Service zwei Blöcke - also zwei Telegramme, bei denen QQ ZZ PB SB gleich sind. Sie unterscheiden sich in NN (Block 1 NN=8 und Block 2 NN=7) und M6 (Block 1 M6=01 und Block 2 M6=02).

Wenn QQ ZZ PB SB NN ausgewertet würde, sollte es funktionieren. Ohne NN allerdings nicht. Sauberer wäre aber irgendwie den M6 mit abzufragen...

Hast Du einen solchen Fall auch bei der Vaillant?
(siehe Spec_Prot_7_V1_6_3_D.pdf)

Gruß Moritz

[JuMi2006]

Das blicke ich nicht. Was soll ich als answer_bytes eintragen? 00? Das ist aber ja das ACK, oder? Oder sollen answer_bytes und databytes gleich sein?

answer_bytes ist kein Byte im Sinne von 0x1E sondern lediglich die Anzahl der Antwortbytes eines Master-Slave Telegrammes:

Beispiel:

Der Master schickt eine Anfrage an einen Slave (get):
10 08 B5 09 03 0D 05 06 CRC

Nun Antwortet der Slave:
ACK 02 07 08 CRC

Der Master bestätigt mit einem ACK und SYN:
00 AA

Am Ebus sieht das Telegramm dann so aus:
10 08 B5 09 03 0D 05 06 CRC 00 02 07 08 CRC 00 AA

Also ein klassisches Master-Slave-Telegramm. In diesem Falle wäre 02 eben die Anzahl der Antwort-Bytes die die Daten enthält (07 und 08). Die Datenposition wäre 1,2.

Beim cycle sieht das eben anders aus, aber ich denke wir dürfen in der config nicht mit absoluten Zahlen arbeiten sondern immer relativ zu einem bestimmten Datenpunkt.

Wenn es also Antwort-Byte > 0 in der config existiert weiß er ab wo er zählen soll. Wenn Antwort-Byte = 0 dann muss der Daemon von einem anderen Punkt aus zählen.

Gruß

[JuMi2006]

Hi Mirko,

Die aktuelle Konfiguration deckt im Moment nicht den folgenden Fall ab: Service 05 03 - Betriebsdaten des Feuerungsautomaten an den Regler.

Hier gibt es für einen Service zwei Blöcke - also zwei Telegramme, bei denen QQ ZZ PB SB gleich sind. Sie unterscheiden sich in NN (Block 1 NN=8 und Block 2 NN=7) und M6 (Block 1 M6=01 und Block 2 M6=02).

Wenn QQ ZZ PB SB NN ausgewertet würde, sollte es funktionieren. Ohne NN allerdings nicht. Sauberer wäre aber irgendwie den M6 mit abzufragen...

Hast Du einen solchen Fall auch bei der Vaillant?
(siehe Spec_Prot_7_V1_6_3_D.pdf)

Gruß Moritz

NN wird mit in die config eingepflegt, heißt nur anders .
Bei Vaillant laufen 80% der Abfragen über ein QQ ZZ B5 09 03. NN=03.

[kleinklausi]

Beim cycle sieht das eben anders aus, aber ich denke wir dürfen in der config nicht mit absoluten Zahlen arbeiten sondern immer relativ zu einem bestimmten Datenpunkt.

Ja, master-slave Telegramme verstehe ich. Nur ist mir nicht klar, was ich am besten beim cycle für answer_byte eintragen soll. Hast du ein Beispiel dafür?

Gruß

[kleinklausi]

NN wird mit in die config eingepflegt, heißt nur anders . Bei Vaillant laufen 80% der Abfragen über ein QQ ZZ B5 09 03. NN=03.

Perfekt, dann passt es ja!

[Gast]

expandierte Daten oder CRC Byte

Hallo,

hat von Euch schon mal ein expandierts Daten oder CRC Byte gesehen / aufgezeichnet?

Zur Info:

* aus einem AA wird A9 01
* aus einem A9 wird A9 00

Falls jemand sowas hat bitte das Telegramm posten. Danke.

Roland

[JuMi2006]

Tadaaaaa !!!

00 08 b5 09 03 0d 13 00 a9 01 00 01 00 9b 00 aa

Das CRC wäre ein AA gewesen.

[kleinklausi]

hat von Euch schon mal ein expandierts Daten oder CRC Byte gesehen / aufgezeichnet?

und bei mir:

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

das Telgramm kommt bei mir ca. alle 10 Minuten.

Und

03 fe 05 03 08 01 0a 40 2c 4c 21 34 08 a9 00 aa

Gruß

[Gast]

Danke

[Fry]

Moritz -
erstmal tausend Dank! Ich werde deine Anleitung jetzt einfach mal abarbeiten.

Was Infos von Wolf angeht: falls diese "Geheimtelegramme" von Wolf selbst entwickelt wurden, werde ich die mit Sicherheit kriegen, muss aber dann noch klären, inwiefern ich sowas weitergeben darf. Bin da aber eher zuversichtlich.

Viele Grüße und nochmals danke!
Fry

[JuMi2006]

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

Nochmal zurück zur config, hier wäre data_Bytes = 02 = 0x02 = Anzahl der Datenbytes in der Antwort vom Slave. Als data_pos wäre dann 1,2 also 0x00 und 0x80 auszuwerten. Die Bytes 0x57, 0x44 und 0x03 stellen höchst wahrscheinlich nur die Identifikation des abzufragenden Wertes dar.

Grüße

Baustelle 2.0

[Sandman60]

Nochmal zurück zur config, hier wäre data_Bytes = 02 = 0x02 = Anzahl der Datenbytes in der Antwort vom Slave. Als data_pos wäre dann 1,2 also 0x00 und 0x80 auszuwerten. Die Bytes 0x57, 0x44 und 0x03 stellen höchst wahrscheinlich nur die Identifikation des abzufragenden Wertes dar.

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

[JuMi2006]

Hallo Oliver da hast Du Dir ein ungünstiges Telegramm für die Basics ausgesucht ich versuchs trotzdem:

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

30 - Master-Adresse des Absenders (seine eigene Slave-Adresse ist 30+5=35)
76 - Slave-Adresse des Empfängers (seine eigene Master-Adresse ist 76-5=71)
50 - Primärbefehl (herstellerspezifisch)
22 - Sekundärbefehl (herstellerspezifisch)
03 - Anzahl der zu sendenden Datenbytes
55 - Datenbyte #1
44 - Datenbyte #2
03 - Datenbyte #3

Jetzt kommt das CRC-Byte, hier ist aber ein Sonderfall. Das berechnete CRC aus den vorhergehenden Bytes wäre AA. Da AA aber das SYNC Zeichen am Telegrammende ist, hätte man jetzt ein Problem. Deswegen wird aus dem AA hier ein A9 01. Das ist in der eBus-Spezifikation so festgelegt.

A9 01 - CRC Byte(s) - normalerweise nur ein Byte
00 - Ist die positive Empfangsbestätigung des Slaves -> ACK
02 - Gibt die Anzahl der Bytes an, die der Slave zurücksendet
00 - Datenbyte #1
80 - Datenbyte #2
AC - CRC des Slaves der jetzt antwortet, wird nur von 02 bis 80 berechnet.
00 - positive Empfangsbestätigung des Empfängers, wird also vom Master bestätigt -> ACK
AA - Das ist das SYN-Zeichen, hier gibt der Master den Bus wieder frei.

Wenn wir mal von einem CRC ausgehen das nicht gerade AA ist dann würde die Nachricht so aussehen:

Master - Slave

30 76 50 22 03 57 44 03 1e 00 02 00 80 ac 00 aa

Grüße