Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
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.
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...
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.
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.
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?
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.
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:
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.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar