eBus->USB->Plugin->KNX

[kobza]

Hi yuhu,

ja eine kleine Beschreibung wäre gut, ich kann von meiner Seite die TEM Befehle (hoffentlich bald) dazu beitragen.

Gruß
Thomas

[JuMi2006]

Für die config oder für den ebusd ?

[kobza]

Für die config oder für den ebusd ?

Für die Config (die CVS Dateien), ich denke diese brauche ich um die get und set Befehle abzusetzen, richtig?

Gruß
Thomas

[JuMi2006]

Ja fangen wir mal bei get an.

Ein einfaches Beispiel:

get;ci;language;Sprachvariante;3;15;B509;3;0D2600;1;1;bcd;1.000;-;

get = Auswahl eines get/set/cyc ... hier will ich also einen Datensatz abrufen

ci = [class]
Hier nur ein Kürzel, könnte auch Pusteblume, Auto oder Sonne heißen ... frei wählbar.

language = [short]
Kurzname für die spätere Identifikation der Befehle ... auch hier wieder Blume,Sonne,Auto

Sprachvariante = [comment]
Naja wieder Blume,Sonne,Auto ... sinnvoll füllen.

3 = [type]
Telegrammtype, Boradcast / Master-Master / Master-Slave

15 = [zz]
Zieladresse

B509 = [pb sb]
Primär und Sekundärbefehl

3 = [nn]
Anzahl der Datenbytes die gesendet werden

0D2600 = [databytes]
Das sind die 3 Datenbytes 0x0d 0x26 0x00

1 = [answer_bytes]
Anzahl der Datenbytes der Antwort hier also ein Datenbyte als Antwort
Vorher kommt allerdings nach dem CRC des Senders noch ein ACK (0x00)

1 = [data_pos]
Hier geben wir an wo die Antwort enthalten ist. Da nur ein Byte gesendet wird ist es recht klar. Es kann aber auch sein dass 3 Bytes gesendet werden und die ersten 2 Bytes die Temperatur und das dritte den Status des Fühlers enthält.

bcd = [code]
Art der Codierung (bcd,d1b,d1c,d2b,d2c)

1.000 = [factor]
Falls der Wert mit irgendwas multipliziert werden muss.

Die Angaben in eckigen Klammern müsste Roland noch mal korrigieren, aber grundsätzlich sieht man wohin die Reise geht.
Ansonsten einfach mal die *.ods aus dem doc/vaillant Verzeichnis im SVN ansehen.

Wir senden also ein 00 15 B5 09 03 0D 26 00 CRC und erhalten dann 00 01 XX CRC. Jetzt senden wir wieder ein 00 AA
Am Bus sieht so ein Telegramm dann so aus: 00 15 B5 09 03 0D 26 00 CRC 00 01 02 CRC 00 AA.

Sprachvariante wäre also 02. CRC ist natürlich ein entsprechender Hex-Wert.

[kobza]

Hi

Danke Dir, die ods und csv Dateien habe ich mir angeschaut. D.h die Config kommt in die ods Dateien, wozu sind dann die csv? Sorry für die vielen Fragen...

Gruß
Thomas

[Gast]

Hi,

zum Bearbeiten der Config sind ods files besser geeignet.

Wenn fertig geändert einfach Speichern unter das cvs files abspeichern (als Feldtrenner ; wählen)

Der ebusd liest das cvs file ein.

[kleinklausi]

Es sollten mal die Leute was sage, die sowas benötigen.

• Wann Puffern und wieviel?
• Senden an welche Empfänger in welcher Form?
• Vielleicht einfach in eine Datei oder RRD schreiben?

Hallo,

es reicht leider grad nur zum mitlesen. Ich muss endlich mal wieder zum testen kommen. Und die CSV Datei muss ich auch dringend an den neuen Stand anpassen...

Ich mach mal Wunschkonzert :
Im Sinne der Trennung von ebusd und ebus-knxd, könnte ich mir gut vorstellen, dass der ebusd für alle cycle Telegramme in der Config jeweils den letzten Wert, der über den EBus gegangen ist, puffert. Somit könnte dann jeder im ebus-knxd die zeitliche Auflösung selber bestimmen. Entweder er pollt alle Minute und sendet auf den KNX oder er schreibt alle 30 Sekunden in ein RRD usw. Abfragen des ebusd könnte dann mit einem get_cycle oder auch mit einem get gemacht werden.

Falls jemand sehr genaue Wert haben will und/oder die Cycle Telegramme nur selten geschickt werden, könnte man ja der Benutzer "händisch" ein Master-Master Telegramm absetzen und somit ein Cycle Telegramm provozieren. Ob es sich lohnt das zusammenzufassen, bin ich mir nicht wirklich sicher.

Sofern das Senden auf den KNX oder das Schreiben in ein RRD in den ebusd wandern sollte, müsste man obiges wahrscheinlich nochmal überdenken.

Könntet Ihr Euch das so vorstellen?

Gruß Moritz

[JuMi2006]

Ja...

mal kurz was zum aktuellen Perl-Daemon ... makki meinte zwar ich soll mir das lieber in C machen und von russconnetcd abschreiben, aber C fange ich diesen Winter definitiv nicht mehr an .

Der ebusd-knx-Daemon ist soweit fertig, da er auch ganz normale WireGate Plugins auf jeder Plattform bearbeiten kann nenn ich den jetzt einfach mal knxd.

Im knxd läuft derzeit ein Plugin, das kann auch so bleiben weil man dort einfach keine anderen Plugins mit blockiert (sofern er separat läuft). Dieses Plugin macht bislang folgendes:

Als erstes werden die configs eingelesen in denen hier auch die GAs und DPTs mit drin stehen. Jetzt wird gezählt wieviele Werte ich hier per GA definiert habe. Also jeder Befehl der eine GA enthält.
Die Zykluszeit (240 Sekunden) wird dann durch die entsprechende Anzahl der auszulesenden Werte geteilt. Das sorgt dafür dass jeder Wert innerhalb von 240 Sekunden einmal aufgerufen wird und die Laufzeit nicht zu lang wird.
Schreiben in ein RRD folgt, hier muss die config noch wissen ob es sich um ein GAUGE oder COUNTER (siehe rrdtool-doku) handelt, der Rest ist (woanders) schon fertig.

Damit hätten wir das Lesen eigentlich abgefrühstückt. Die Auflösung sollte für den Hausgebrauch reichen.

Beim Schreiben wird wieder die config ausgelesen. Auch hier gibt es wieder GA und DPT in der config. Kommt jetzt ein Wert vom KNX rein wird der entsprechende Befehl an den ebusd geschickt. Jetzt vergleicht das Plugin den Befehl aus der Set-Liste mit den Befehlen aus der Get-Liste. Wichtig ist hier dass set und get die gleichen Kurznamen haben. Nach dem Setzen eines Wertes liest das Plugin dann via get den Wert nochmal vom Bus und sendet ihn an die angegeben GA. Damit hat man also eine Rückmeldeadresse, bislang ist es allerdings so dass alles was auch gesendet wird zyklisch ausgelesen wird.

Grüße

[kleinklausi]

OT

Der ebusd-knx-Daemon ist soweit fertig, da er auch ganz normale WireGate Plugins auf jeder Plattform bearbeiten kann nenn ich den jetzt einfach mal knxd.

Sorry, kurz off-topic: Mit diesem knxd könnte man auch beliebige andere "Wiregate" Plugins laufen lassen, die sonst zu lange Laufzeiten haben. Korrekt?

[JuMi2006]

Korrekt ... auch auf (fast) jeder beliebigen Maschine solange sich ein eibd im Netzwerk befindet. Weiterhin kann man auch die EIB-Anbindung im Daemon abschalten (falls man einfach nur RRDs loggen will).

Mehrere Instanzen könnte man auch laufen lassen, ist dann aber ein ziemliches config-Gefrickel.

[kleinklausi]

Das ist gut zu wissen :-) Danke

[kobza]

Hi,

leider kriege ich es nicht hin mit den Config Files, ich habe bereits etwas für TEM gebaut, die Files werden aber nicht eingelesen. Auch mit den CSV File aus dem SVN kriege ich Fehler:

2013-02-14 20:25:55.661 [0x02 NOT] /etc/ebusd/vaillant_cyc.csv
2013-02-14 20:25:55.665 [0x04 WAR] error during read command file
2013-02-14 20:25:55.682 [0x01 INF] /dev/ttyUSB2 opened.
2013-02-14 20:25:55.682 [0x01 INF] port 8080 opened.
2013-02-14 20:25:55.682 [0x01 INF] msg queue initialized.
2013-02-14 20:26:01.133 [0x20 EBH] 10 fe 08 02 08 00 1b 00 32 00 09 ff 00 eb
2013-02-14 20:26:11.117 [0x20 EBH] 10 fe 07 00 09 b3 ff 20 27 20 14 02 04 13 45

Was mache ich denn falsch? Wie könnte ich es debuggen?

Gruß
Thomas

[Gast]

Hi kobza,

zeig mal dein Config file.

[kobza]

Hi,

hier, TEM sendet sehr oft die Broadcast Nachrichten 700,800 und 801 ab un zu die 704, diese habe ich dort eingetragen.

Gruß
Thomas

[Gast]

Ok, das ist noch ein Zwischenstand. Das kann nicht funktionieren, da es noch nicht implementiert ist.

Ich bin gerade beim Umstellen auf die neue Konfigurationsstruktur.
Wenn diese im SVN ist, dann sollten auch zyklische Telegramme dekodiert werden.
Dazu muss ich aber noch etwas arbeit in den Daemon stecken.

Tut mir leid wenn das falsch verstanden wurde.