eBus->USB->Plugin->KNX

[Sandman60]

kann man den verkehr nicht irgendwie aufzeichnen? oder in eine datei schreiben lassen.
per putty kann ich im wiregate mir die schnittstelle ansehen, aufzeichnen wäre ja schöner.

Genau das macht der Daemon ja, aber er liefert nun halt auch noch Datum und Co. und damit einfach schöner. Weiter kannst Du dann zum einen mit dem Daemon aufzeichnen und zum anderen mit dem Serial-Write testen.

[Gast]

Die Option -d von ebusd zeichnet die ebus Daten im raw Format auf. (Hexeditor)

-d --dump         dump raw ebus messages to dump file.

[MarcusF]

Und wenn man es nicht im raw-Format haben möchte: Man kann jede Ausgabe auch ganz einfach in eine Datei umleiten.

ebusd -s /dev/ttyS0 -l3 -f -n >test.txt

schreibt die Bildschirmausgabe in die Datei test.txt

Marcus

[Sandman60]

Es huschen nun verdammt viele SYN-Zeichen über den Schirm. So macht der Parameter --nosyn tatsächlich mehr Sinn.

Danke nochmal dafür! Hatte gedacht, dass das auch bei Dir schon vorher so war...
Nun aber gleich meine nächste Frage:
Also bei mir huschen die AA's permanent über den Schirm (wenn ohne -n ) und manchmal auch "vollständige" und logisch aussehnde Pakete. Manchmal sehe ich aber auch z.B. folgende m.E. nach zu kurze und unlogische Pakete:
"00 aa" oder "05 aa" oder "00 00 8a 03 61 00 aa". Habt Ihr sowas auch, sprich ich muß noch weiter sehr feinjustieren, oder ist es ggf. besser es erst einmal so stehen zu lassen?

Cheers,
Oliver

[Gast]

@Sandman60:

Hast du eine Vaillant Anlage? Vielleicht sind das Irrläufer.

@MarcusF:

Warum nicht einfach das Logfile benutzen? Einfach ohne -f staten.

[Sandman60]

@Yuhu: Nein, schön wäre es Habe eine Hautec mit einer TEM-Steuerung.
Werde nun mal einen Langzeittrace laufen lassen und dann mal auswerten, wieviele Irrläufer unterwegs sind. Wenn sich das in Grenzen hält fasse ich den Poti besser nicht an...
Ist ja nun alles Dank Deines Daemons und dem -n alles kein Aufwand mehr
Cheers,
Oliver

[MarcusF]

Warum nicht einfach das Logfile benutzen? Einfach ohne -f staten.

Siehst Du, ich dachte, das zeichnet immer in raw auf... again what learned

Aber stdout umleiten kann man immer mal gebrauchen.

Marcus

[Anders]

boaaahhh

jung ihr habt einen stand, der werde ich nie hinkommen und ihr überspringt so viele schritte das ich noob das nicht packe.

wolftherme mit solar ist vorhanden, ebus an 232 - usb - wiregate bekommt fleißig werte.

hilft mir da jemand step by step durch / oder gibts da eine anleitung?

zwischenzeitlich muß meine familien frieren, weil ich die gastherme in mein arbeitszimmer gestellt habe, um da voran zu kommen.

gruß
andreas

[Sandman60]

@Andreas:
Nicht verzweifeln, Du bist nicht allein... Roland und Mirko sind da schon verdammt weit bzgl. Vaillant, wir Wolf und Hautec Kinders hinken da m.E. noch hinterher, jedenfalls auch mein Eindruck....

Mal mein Stand wie ich die "Roadmap" verstanden habe:
1. "Dechiffrieren der Werte" und erzeugen von "Abfragestatements". Bei mir heißt das Identifikation der Master-/Slaveadressen sowie der angebotenen Services und dann Trial&Error.
2. Bau eines Daemons, mit dem man dann Werte aus den Plug-Ins anfordern und dann auf den Bus bringen kann.
3. Bau eines Plug-In-Gerüsts.

Da 1.+2. sehr eng zusammenliegen war der Aufruf von Mirko, dass wir Non-Vaillant-Kinders mal ein paar Commands mitteilen, damit ggf. specials in 2. miteinfließen können.

Zu 2. hat Roland schon einiges gebaut, incl. dem Dump-Tool

Zu 3. hat Mirko ja schon ein paar Dinge hinsichtlich Plug-In gebaut, allerdings kam es soweit ich es verstanden habe zu Performance-Problemen und v.a. das Checksummen berechnen/anhängen war nicht mehr machbar.

@Mirko, Roland: Wie seht Ihr das?

Cheers,
Oliver

[Gast]

Der Stand der Dinge

Hallo Oliver!

Hier nun meine Sicht der Dinge!

• Zu etwaigen Plugins kann ich nichts sagen. Für welchen Server oder Software eigenlich? Sorry für diese Frage.

• Entschlüssen der ebus Werte von Vaillant Anlagen:

• Die Telegramme, sind in Verbindung mit dem Orignaladapter und Software gut mitzuschneiden.

• Die Wärmepumpe sollte somit erledigt sein.

• Telegramme für das Solar- und das Frischwassermodul werde ich noch ergänzen, falls Mirko sowas nicht hat.

Die Hauptarbeit hat hier Mirko geleistet. Danke!

• Zugriff auf den ebus:

• Das Grundgerüst des Daemons ist aus meiner Sicht fertig.
  (Ich habe bewußt auf Threads verzichtet.
  Falls es zu Schwierigkeiten kommt muss ich nochmals darüber nachdenken.)

• Nachdem ich mich nun mit dem Schreiben intensiver ausseinander gesetzt habe,
  werde ich meinen ursprünglichen Plan, eine libebus zu erstellen, wieder aufnehmen.
  Diese lib wird Hersteller abhängig und unabhängige Teile enthalten.

• Die Dekodierungsfunktionen werden sicher abhängig vom Hersteller sein.
  Keine Ahnung ob hier alles über die Config abgefangen werden kann.

• Diverse Configs für den Daemon wollen noch erstellt werden.
  Dazu fehlen noch deren Funktionen zum Einlesen bzw. die notwendigen Datenstrukturen.

• Der Zugriff via Telnet ist derzeit ebenfalls noch ein weißer Fleck.
  Eventuell macht ein kleiner Client Sinn.

• 2-3 kleine Tools werden sicher auch noch dazu kommen.
  Telegramme bauen, Datentypen checken,...

Roland

[JuMi2006]

Ich denke eigentlich ist alles gesagt, sicherlich bleiben noch etliche Fragen zu Features.

Kurz noch meine Sicht und ein paar Erklärungen:

• Zu etwaigen Plugins kann ich nichts sagen. Für welchen Server oder Software eigenlich? Sorry für diese Frage.

Dabei geht es um Wiregate-Plugins, kleine Perl Codeschnipsel die unter einem daemon laufen.

• Telegramme für das Solar- und das Frischwassermodul werde ich noch ergänzen, falls Mirko sowas nicht hat.

Das muss leider jemand machen der sowas hat. Hier gibts nur ganz wenig Technik

• Nachdem ich mich nun mit dem Schreiben intensiver ausseinander gesetzt habe,
  werde ich meinen ursprünglichen Plan, eine libebus zu erstellen, wieder aufnehmen.
  Diese lib wird Hersteller abhängig und unabhängige Teile enthalten.

• Die Dekodierungsfunktionen werden sicher abhängig vom Hersteller sein.
  Keine Ahnung ob hier alles über die Config abgefangen werden kann.

Was denkst Du sind Herstellerabhängige Teile?

Die Dekodierung sollte mit der Config komplett abgefangen werden. Zumindest sind mir beim Erarbeiten jetzt keine Stolperfallen aufgefallen. Die Datentypen sind eBus-spezifisch und ansonsten gibts noch dividier/multiplier. Mehrere Daten in einem Telegramm lassen sich auch bedienen.

Hier hab ich bloss das C-Manko und hoffe auf weitere Hilfe von Interessierten, wie das laufen soll ist mir eigentlich schon klar.

• Diverse Configs für den Daemon wollen noch erstellt werden.
  Dazu fehlen noch deren Funktionen zum Einlesen bzw. die notwendigen Datenstrukturen.

Auch hier fehlt auch noch ein bisschen C So langsam bekomme ich ein schlechtes Gewissen gegenüber Roland ... ob er wusste worauf er sich eingelassen hat ?

• Der Zugriff via Telnet ist derzeit ebenfalls noch ein weißer Fleck.
  Eventuell macht ein kleiner Client Sinn.

• 2-3 kleine Tools werden sicher auch noch dazu kommen.
  Telegramme bauen, Datentypen checken,...

Da das Grundgerüst erstmal grundlegend funktioniert sehe ich die Prioritäten jetzt tatsächlich im Einlesen der Configs. Die Datentypen funktionieren bzw. könnten auch später noch mal ergänz werden. Das Senden funktioniert auch zuverlässig? Als nächstes sollte dann tatsächlich ein Telnet-Zugriff oder ähnliches zur Verfügung stehen. Ich denke erst dann kann man den Daemon so richtig "testen" ... Also mal zyklisch die Daten im Klartext abfragen.

Danke und Gruß
Mirko

[Gast]

Frage an die Gemeinde

2 Fragen zu Datenstrukturen, welche wesentlich für die weitere Programmierung sind.

Bis jetzt habe ich alles in einem Array abgehandelt.
Also alles zwischen 2 SYN Zeichen. Dies wurde dann zerlegt und weiterverarbeitet.

1. Wäre es sinnvoller dieses mit einer Struktur zu casten und dann weiter zu verarbeiten?


Wenn ich mir die GET/SET Methoden so ansehe, wird das ein großes Array.
Die ersten 3 Daten Bytes gehören anscheinend noch zum Befehl dazu.

Das ist bei anderen Hersteller sicher anders.

2. Wie kann das sinnvoll gehandhabt werden?


roland

[JuMi2006]

Nun das ist ein wirklich schwieriger Teil. Grundsätzlich sollte in eine laufende config vielleicht auch nur das was man wirklich benötigt? Ich stelle mir das so so vor:

GET:
Ein get erwartet immer eine Antwort, in der config ist alles von QQ bis NN bekannt. Nun baut man den Befehl aus dem Array der config zusammen und sendet ihn. Gleichzeitig müsste man dann vom eBus lesen und seinen Befehl anhand QQ bis NN wiederfinden, prüfen ob es ein ACK gab und die Länge der Antwort mit der config übereinstimmt. Wenn alles positiv gelaufen ist kann man die lt. config definierten Antwortbytes auswerten. Die Antwort wäre also ein weiteres Array damit man Teilinformationen aus einer Antwort extrahieren könnte.

SET:
Ein set erwartet keine richtige Antwort, lediglich ein ACK. Hier ist es ein wenig einfacher. Man baut einfach den Befehl aus dem Array der config zusammen und schickt ihn auf die Reise. Nun wieder der Vergleich zwischen gelesen/gesendet und Prüfung des ACK. Wenn positiv ist alles in Butter.

"short names" könnten auch individuell festgelegt werden, da kann sich jeder also ausdenken was er will. Ein config Array würde also also aus folgenden Infos bestehen:

SET:

• short_name
• ZZ
• PB
• SB
• NN
• DB1-DBx
• (hier würde value eingesetzt)
• post_value_byte
• coding
• Multiplikator

-> ZZ bis DBx könnte man nach dem einlesen zusammenfassen und als einen einzigen Wert im Array behalten.

GET:

• short_name
• ZZ
• PB
• SB
• NN
• DB1-DBx
• (hier müsste man evtl. einen Feldtrenner einbauen um zu erkennen wo der Befehl endet)
• answer_byte
• data_position (als eigenes array)
• coding
• Dividend

-> ZZ bis DBx könnte man auch wieder nach dem einlesen zusammenfassen und als einen einzigen Wert im Array behalten.
-> Wie groß DBx ist könnte man ja sogar aus dem NN berechnen, aber das handling ist trotzdem knifflig.

Gruß

[kleinklausi]

GET:
[...] Die Antwort wäre also ein weiteres Array damit man Teilinformationen aus einer Antwort extrahieren könnte.

dabei musste ich nochmal über den Weg nachdenken, wie wir mehrere Parameter in einem Antwort- oder Cycle-Telegramm auswerten. Alle Parameter aus einem Telegramm in ein Array zu packen, scheint effizient. Man muss dann danach aber nochmal Aufwand treiben, um den richtigen Parameter/Wert rauszubekommen (wie pflege ich das in der Konfig?).
Von der Konfiguration scheint es mir einfacher, dass man jeden Parameter separat abfragt. Zugegeben, damit erhöht man die Anzahl der Get-Telegramme.

Hab ich mich klar genu ausgedrückt?

Gruß

[kleinklausi]

Zur Info an jene, welche mit dem Adapter von eserver-online arbeiten.
[...]
Es huschen nun verdammt viele SYN-Zeichen über den Schirm. So macht der Parameter --nosyn tatsächlich mehr Sinn.

Sorry, aber bevor ich am Poti drehe eine Bitte. Meint Ihr ich sollte bei unterem am Poti drehen und versuchen mehr SYN Zeichen zu bekommen?

root@wiregate248:/home/user/src/ebusd/ebusd# ./ebusd -s /dev/ttyUSBHeizung -f -l3 -n
2013-00-05 10:49:59.890 [INF] serial device /dev/ttyUSBHeizung successfully opened.
2013-00-05 10:49:59.891 [INF] tcp port 8888 successfully opened.
2013-00-05 10:50:02.321 [DBG]  00 10 03 08 00 08 b3 1e 00 08 80 01 00 37 60 aa
2013-00-05 10:50:06.777 [DBG]  f1 fe 08 00 08 b3 1e b3 07 00 00 00 37 44 71 fe 50 17 10 00 01 9a 00 b6 00 00 80 00 80 00 80 00 80 00 80 4c 30 50 50 14 07 03 00 1e b3 1a 00 6e 84 30 50 50 14 07 03 00 1e b3 1a 00 6e 84 30 90 50 12 00 2e 30 90 50 12 00 2e 30 fe 50 23 09 28 00 0a 14 00 5d 01 00 00 4e 30 71 50 23 09 4c 66 00 00 00 5d 01 00 00 88 00 aa
2013-00-05 10:50:07.089 [DBG]  30 71 50 23 09 10 13 00 26 02 5d 01 00 00 94 00 aa
2013-00-05 10:50:07.405 [DBG]  30 71 50 23 09 b8 72 00 00 00 5d 01 00 00 04 00 aa
2013-00-05 10:50:07.757 [DBG]  10 03 05 07 09 bb 06 eb 01 00 80 ff 6e ff 97 aa
2013-00-05 10:50:11.177 [DBG]  f1 fe 05 03 08 01 01 00 ff 3a ff 31 08 86 71 30 50 23 09 b0 f4 02 00 04 5d 01 00 00 80 00 aa
2013-00-05 10:50:12.733 [DBG]  10 03 08 00 08 b3 1e 00 08 80 01 00 37 60 aa
2013-00-05 10:50:14.737 [DBG]  f1 fe 08 00 08 b3 1e b3 07 00 00 00 37 44 30 71 50 23 09 60 62 00 01 00 5d 01 00 00 57 00 aa
2013-00-05 10:50:17.721 [DBG]  30 fe 07 00 09 00 80 10 50 10 ff ff 06 ff 1f 10 03 05 07 09 bb 01 eb 01 00 80 ff 6e ff 18 aa
2013-00-05 10:50:22.653 [DBG]  f1 fe 05 03 08 01 01 00 ff 3a ff 31 08 86 71 fe 50 18 0e 00 80 00 80 00 80 00 80 00 80 00 80 00 00 09 10 03 08 00 08 b3 1e 00 08 80 01 00 37 60 aa
2013-00-05 10:50:27.657 [DBG]  f1 fe 08 00 08 b3 1e b3 07 00 00 00 37 44 10 03 05 07 09 bb 03 eb 01 00 80 ff 6e ff 2f aa
2013-00-05 10:50:32.593 [DBG]  f1 fe 05 03 08 01 01 30 ff 4e ff 31 08 1a 00 10 03 08 00 08 b3 1e 00 08 80 01 00 37 60 aa
2013-00-05 10:50:37.581 [DBG]  f1 fe 08 00 08 b3 1e b3 07 00 00 00 37 44 71 fe 50 17 10 00 01 9a 00 b6 00 00 80 00 80 00 80 00 80 00 80 4c 10 03 05 07 09 bb 06 eb 01 00 80 ff 6e ff 97 aa
2013-00-05 10:50:41.137 [DBG]  f1 fe 05 03 08 01 01 30 ff 4e ff 31 08 1a 71 30 50 23 09 b0 f4 02 00 04 5d 01 00 00 80 00 aa
2013-00-05 10:50:42.565 [DBG]  10 03 08 00 08 b3 1e 00 08 80 01 00 37 60 aa
2013-00-05 10:50:47.525 [DBG]  f1 fe 08 00 08 b3 1e b3 07 00 00 00 37 44 10 03 05 07 09 bb 01 eb 01 00 80 ff 6e ff 18 aa
2013-00-05 10:50:52.501 [DBG]  f1 fe 05 03 08 01 01 30 ff 4e ff 31 08 1a 71 fe 50 18 0e 00 80 00 80 00 80 00 80 00 80 00 80 00 00 09 10 03 08 00 08 b3 1e 00 08 80 01 00 37 60 aa
2013-00-05 10:50:57.457 [DBG]  f1 fe 08 00 08 b3 1e b3 07 00 00 00 37 44 10 03 05 07 09 bb 03 eb 01 00 80 ff 6e ff 2f aa
2013-00-05 10:51:02.413 [DBG]  f1 fe 05 03 08 01 01 00 ff 46 ff 31 08 28 00 10 03 08 00 08 b3 1e 00 08 80 01 00 37 60 aa
2013-00-05 10:51:06.425 [DBG]  f1 fe 08 00 08 b3 1e b3 07 00 00 00 37 44 71 fe 50 17 10 00 01 9a 00 b6 00 00 80 00 80 00 80 00 80 00 80 4c 70 51 50 14 07 01 00 05 00 1a 00 6e 3f 70 51 50 14 07 01 00 05 00 1a 00 6e 3f 30 71 50 23 09 4c 66 00 00 00 5d 01 00 00 88 00 aa

Danke und Gruß