eBus->USB->Plugin->KNX

[kleinklausi]

Habe ich die Puzzleteile richtig verstanden? Irgendwie fehlt mir gerade das Bild wie es nachdem Daemon weitergehen soll.

Ich versuche mal (m)ein Puzzle zusammenzusetzen - es gibt halt nicht nur eine Möglichkeit wie es zusammen passt.

Zuerst mal high-level wie es mit Master-Slave Telegrammen gut funktionieren sollte:

1. ebusd kümmert sich ums Senden und Empfangen inkl. Retry, CRC etc.
2. Ein weiteres Programm/Daemon/Wiregate-Plugin wird alle x Minuten aufgerufen, verwendet den ebusd um eine Anfrage zu senden und empfängt die Antwort. Dieses Programm sendet den Wert auf eine GA des KNX
3. Speichern der Werte über die Zeit erfolgt in einem RRD - z.B. geht das in Perl sehr schön einfach
4. Grafische Aufbereitung der Werte des RRD - z.B. Cometvisu, Drraw, flot, sonst was im Wiregate, oder, oder

zu 1.

Wenn ebus_send und ebusd zusammengeführt wären, sollte 1. komplett sein

zu 2.
Mirko's Wiregate-Plugin macht wahrscheinlich genau das schon. Oder Mirko?
Ansonsten könnte es auch ein Programm/Skript sein, dass als cron-job aufgerufen wird. Die Frage, die bleibt, ist doch wie dieses Programm eine Benutzerfreundliche Config einliest und verwendet.

zu 3.
Je nach 2. würde z.B. ein Wiregate-Plugin oder ein Perl Daemon/Cron-Job das Schreiben ins RRD wohl direkt mit erledigen

zu 4.
ich denke das ist wirklich eine separate Aufgabe. Da gibt es dann unzählige Möglichkeiten

So, nun zu meinem eigentlichen Problem:
Solange man Master-Slave Telegramme benutzen kann, funktioniert obiges super. Bisher kenne ich aber so gut wie keine Master-Slave Telegramme für meine Wolf Therme. Fast alles wird zyklisch gesendet oder es handelt sich um Master-Master Telegramme.
Jetzt funktioniert 2. nicht mehr so einfach. Das Programm muss jetzt eine bestimmte Zeit auf dem Bus lauschen bis entweder das zyklische Telegramm oder zumindest die Master-Master-Antwort empfangen wurde. Hier brauchts noch eine bessere Idee.
Und vor allem, welcher Wert wird auf die GA gesendet und ins RRD geschrieben, wenn kein Telegramm gefunden wurde. Den letzten Wert kann man die nächsten Minuten vielleicht noch fortschreiben. Aber über die Nacht weg? Vielleicht wird es klarer, sobald die Master-Master Telegramme mit ebusd funktionieren.

Gruß Moritz

[kleinklausi]

was wir jetzt aber auch nicht vergessen dürfen ist dass wir in einem weiteren Perl-Daemon dann wieder die ganze Datenkonvertierung durchführen.

Das stimmt allerdings. Das ganze data2b etc. Geraffel wäre schon schön das im ebusd zu haben.

[Fry]

Die Aufteilung ist in eibd / wiregated.pl genauso, und aus gutem Grund. Dieses "Geraffel" ist nämlich in Perl ziemlich schmerzarm...
VG, Fry

[JuMi2006]

So, nun zu meinem eigentlichen Problem:
Solange man Master-Slave Telegramme benutzen kann, funktioniert obiges super. Bisher kenne ich aber so gut wie keine Master-Slave Telegramme für meine Wolf Therme. Fast alles wird zyklisch gesendet oder es handelt sich um Master-Master Telegramme.
...
Hier brauchts noch eine bessere Idee.
Und vor allem, welcher Wert wird auf die GA gesendet und ins RRD geschrieben, wenn kein Telegramm gefunden wurde. Den letzten Wert kann man die nächsten Minuten vielleicht noch fortschreiben. Aber über die Nacht weg? Vielleicht wird es klarer, sobald die Master-Master Telegramme mit ebusd funktionieren.

Gruß Moritz

Das ist der Punkt der dann zu erarbeiten ist. Ansonsten sträube ich mich nicht gegen die Lösung sofern wir keine zu starke Abhängigkeit auf ein Endgerät entwickeln bzw. yuhu alias Roland auch was davon hat .

Grüße


P.S.: Ich könnte für meinen Teil schon mit dem aktuellen ebus_send leben .

[Fry]

Ich würde das Ganze in einem Perlskript lösen - ich nenne das im folgenden mal "ebusd.pl" im Unterschied zum "ebusd". Den ebusd.pl würde ich zunächst als WG-Plugin implementieren.

Die Anpassung an eine andere (Linux-)Umgebung ohne wiregated wird dann straightforward sein:
* ein WG-Plugin ist ja bereits Teil eines Daemons, nämlich des wiregated, wobei das Signalhandling, der Fork usw eben vom wiregated übernommen werden.
* In einer Umgebung ohne wiregated müsste ebusd.pl als eigenständiger Daemon implementiert werden, d.h. fork, signalhandling usw. müssten da drin sein.
* Das können wir ziemlich leicht einfach vom wiregated abschreiben (dieser ist ja GPLed, und "unser" daemon wäre das wohl ebenfalls)
* Die Kommunikation zwischen ebusd.pl und ebusd sollte über ein Socket laufen (damit habe ich persönlich zwar nur limitierte Erfahrung, aber das lässt sich ändern). Pufferung im ebusd, Codierung/Decodierung der Datentypen im Perlskript. Genau wie zwischen wiregated und eibd. Makki hat uns das im Prinzip auf dem Silbertablett geliefert.
* Die Kommunikation zwischen Perlskript und restlichem System - nun ja, das hängt von der Umgebung ab. Entweder wieder ein Socket (wie etwa im Falle des Russound_RIO-Plugins für die Kommunikation mit der Russound) oder eben per knx_read/knx_write mit dem KNX-System.

Die Konfiguration der Datentypen usw. würde ich Perl-typisch in einer einlesbaren Datei im Stil wie etwa folgt lösen:

%config=(
"08 00" => {command=>"Sollwertuebertragung_des_Reglers_an_andere_Regler",
  databytes=>2,
  answerbytes=>0,
....
},

....

);

Übrigens brauchen wir mE nur EIN einziges Konfigfile für alle Geräte - die herstellerspezifischen Kommandos sollten sich ja eigentlich nicht gegenseitig stören, weil sie jeweils einen herstellerspezifischen PB enthalten - und dieses Konfigfile könnten wir dann gemeinsam befüllen, wenn wir mehr und mehr über die Kommandos lernen. Das geht gut, solange die Hersteller nicht gleiche PB/SB-Codes für verschiedene Dinge verwenden. Ich hoffe mal darauf, dass das so ist, und denke es auch, schließlich handelt es sich bei Heizungen um zertifizierte Systeme mit einem gewissen Risiko des Haus-Abfackelns, wenn was schiefgeht.

So, das wären meine Vorschläge zur Architektur, gerne lese ich euern Input dazu.

VG, heute aus Orlando,
Fry

[MarcusF]

@MarcusF: Der aktuelle Commit sollte Dein Problem behebe.

Perfekt, ebus_send funktioniert nun einwandfrei. Stresstest folgt noch, aber bisher sieht das gut aus.

Was die Diskussion über die Funktionen des ebusd angeht: Man sollte auch ohne lokal laufendes Perl in der Lage sein, mit dem eBus zu kommunizieren. Denn dann kann man auch Homeserver, EibPC und ähnliche Systeme darüber an den eBus anbinden.

Marcus

[Fry]

Was die Diskussion über die Funktionen des ebusd angeht: Man sollte auch ohne lokal laufendes Perl in der Lage sein, mit dem eBus zu kommunizieren. Denn dann kann man auch Homeserver, EibPC und ähnliche Systeme darüber an den eBus anbinden.

Sind denn Homeserver und EibPC freie und offene Systeme und basieren auf Linux? Wenn ja, ist Perl dort bereits vorhanden. Wenn nein, ist eine Ebus-Anbindung vom jeweiligen Hersteller zu implementieren, was mit yuhus Vorarbeit und dem, was hier noch folgen wird, auch nicht schwer sein dürfte. Sofern diese Hersteller das überhaupt wollen.

Fry

[MarcusF]

Mein Gedanke war eher, dass es Leute gibt, die bereits eine vorhandene Infrastruktur mit HS, eibPC o.ä. samt aufwendig ersteller Visu haben und diese auch weiterhin benutzen wollen. Dann könnte man mit einem Wiregate (oder einem Raspberry Pi wie schon vorgeschlagen) die ebus-Anbindung erledigen und mit dem bestehenden Geräten darauf zugreifen. Dazu müsste der ebusd halt per Telnet oder so von aussen ansprechbar sein.

Marcus

[Gast]

Hallo,

gut das sich nun ein paar Leute zu Wort melden und einen Input geben in welche Richtung das Ganze gehen könnte.

Wie schon erwähnt wollte ich zu Begin nur mal ein paar Kurven aufzeichnen, anzeigen und die Anlage optimieren.
Über das Aufzeichnen, Speichern und vor allem das Anzeigen und Auswerten habe ich noch nicht viel nachgedacht.

Bietet dies das Ökosystem "Wiregate" als Solches an? Wenn ja, würde ich mir eine VM mit Wiregate als bald einrichten.

---

Man sollte auch ohne lokal laufendes Perl in der Lage sein, mit dem eBus zu kommunizieren.
Denn dann kann man auch Homeserver, EibPC und ähnliche Systeme darüber an den eBus anbinden.

Es wäre schön wenn die ebus Funktion auch für andere Systeme offen sind.

Für mich stellt sich die Frage: Auf welcher Ebene soll der ebusd arbeiten?
* Reines ebus Handling (Input: Bytestream Ouput: Bytestream ; versenden, empfangen, escape und crc)
* Oder auch das En-/Dekoden (Input: Befehl Output: Antwort; zB get_AT -> -3.5°C)

Das das ganze über Sockets angesprochen wird, von dem gehe ich aus.

Für das reine Senden kann, wie von Mirko schon erwähnt, ebus_send verwendet werden.

lg roland

[JuMi2006]

Also dem vorletzten Beitrag von Fry kann ich mich absolut nicht anschließen.
Ich möchte das Endgeräte unabhängig verwenden können. Keine weiteren Abhängigkeiten (bzw. so wenig wie möglich).

Nach dem was Roland und ich da bereits an Zeit reingesteckt haben erlaube ich mir das mal so offen zu sagen. ebusd->ebusd.pl->wiregated->eibd als erste Option zu programmieren wäre nicht mein way of live. Ich häng da jetzt seit 4 Monaten dran und hab diverse Foren, Wiki-Seiten und eigene Programmierveranstaltungen besucht. Gerade der Blick auf das csv-config-File zeigt dass es das Ur-Interesse war/ist andere Hersteller als Vaillant mit ins Boot zu bekommen. Roland und Ich haben beide die selbe Wärmepumpe, aber One-Man-Shows gibt es im Netz schon zuhauf.

Wir sind (auch nur Dank Roland) auf so einem hohen Level was die Buskommunikation angeht dass eine Zerstückelung da alles wieder in die Bastelschiene führt. Mit Erschrecken guck ich da immer ins IPS-Forum was da alles so auf einem Oversized-Windows-Rechner gequält wird. Windows CE hat und hatte sicherlich auch seine Berechtigung im Bereich der Automation und Industrie aber gerade die zeigt uns immer mehr dass der eigentliche weg ein anständiges Linux ist .

Open Source (GPL) heisst für mich nicht nur "Du darfst meinen Code gerne kopieren" sondern dient irgendwie auch Wissen/Software einer breiten Masse kostenlos zur Verfügung zu stellen. Dies kann man mit und ohne Gewinnabsichten gerne machen. Dies soll nun aber nicht Thema der Diskussion werden, hier geht es ums "Wie weiter?".

Das wir mit dem WireGate eine sehr gute Basis dafür haben ist ja unbestritten, sollte aber eben nicht die Vorraussetzung für die Nutzung sein.

Option1:
ebusd (inkl. kompletter Datenverarbeitung/config + RRD + eibd) - UDP/Telnet - Wiregate Plugin

Option2:
ebusd - ebusd.pl (inkl. kompletter Datenverarbeitung + RRD + eibd) - UDP/Telnet - Wiregate Plugin

Option3:
ebusd - UDP/Telnet - Wiregate Plugin

Das die Hersteller irgendwas tun glaube ich nicht ... die meisten Funktionen gibt es bei Herstellern die offen arbeiten und Ihre Community pflegen. eBus ist da so eine Sonderlocke dass es kaum jemanden interessiert und wir schließen diese User wieder ein wenig aus wenn wir da nicht mit minimalen Anforderungen für einen Daemon glänzen. Von Vaillant gab es kein einziges Telegramm über einen öffentlichen Kanal ... was da geblockt wird kann man sich nur sehr schwer vorstellen. Ich habs erlebt und gerade deswegen liegt es mir "am Herzen" das für viele User und Systeme zu erarbeiten.

Grüße

[makki]

Nur meine 5ct: ich bin ein Freund davon, alles gleich auf den EIB zu schaffen, weil da für mich der "Backbone" und gemeinsame Nenner ist; die eibclient.h fügt natürlich eine Abhängigkeit hinzu, ist aber ansich broteinfach..
Vorlagen gibts genug (russconnectd z.B.)
Das Telnet-Interface ist zum debuggen/entwickeln sicherlich praktischer, muss man aber halt erst wieder irgendwo einbinden, was man sich bei KNX zumindest mit dem hier gägigen komplett sparen kann..

Das erstellen von RRD etc. würde ich auch extern machen, obwohl es natürlich auch direkt im C-deamon machbar wäre.

Makki

[Fry]

Mein Gedanke war eher, dass es Leute gibt, die bereits eine vorhandene Infrastruktur mit HS, eibPC o.ä. samt aufwendig ersteller Visu haben und diese auch weiterhin benutzen wollen. Dann könnte man mit einem Wiregate (oder einem Raspberry Pi wie schon vorgeschlagen) die ebus-Anbindung erledigen und mit dem bestehenden Geräten darauf zugreifen. Dazu müsste der ebusd halt per Telnet oder so von aussen ansprechbar sein.

Verstehe. Aber für diesen Zweck wäre es ausreichend - und sogar angemessen/elegant - wenn der ebusd auf einem WG oder RPi liefe und (via wiregated und ebusd.pl-Plugin) über KNX erreichbar wäre.

VG, Fry

[Gast]

Und was ist, wenn ich einfach beide Möglichkeiten implementiere?

[Fry]

JuMi -
du hast dein letztes Posting angefangen mit "dem vorletzten Beitrag von Fry kann ich mich absolut nicht anschließen", aber in dem was folgt, kann ich irgendwie keinen Konflikt mit dem, was ich geschrieben habe, erkennen.

Kannst du das bitte nochmal klarstellen - was sind hier eigentlich die gegensätzlichen Positionen?

Wenn aus yuhus Arbeit ein ebusd entsteht, der analog zum eibd die Kommunikationsschicht inkl. CRC und Pufferung erledigt, und daneben ein offener ebusd.pl mit leicht erweiterbarem Konfigurationsfile für alle Ebus-Systeme, dann ist deinen (wie auch meinen) Zielen doch gedient, oder?

Und wenn man einen Daemon in Perl implementiert, dann enthält dieser Daemon automatisch 90% dessen, was man für ein WG-Plugin braucht und umgekehrt. Insofern ist mir persönlich auch nicht wichtig, in welcher Reihenfolge wir dieses machen - ich würde das Plugin als erstes machen, weil ich mir dann keine Gedanken über Signale, Prozesshandling, Crash-recovery usw. machen muss.

Deiner Zielsetzung stimme ich übrigens voll und ganz zu.

(Wobei ich persönlich ein Freund des Wiregate bin - weil offenes System, siehe auch Communitygate - und den Homeserver/Eibpc einfach nicht als meine Baustelle betrachte. Meines Wissens - ich kann mich aber irren - sind beide geschlossene Systeme, was sie für mich uninteressant macht, solange es eine offene Alternative gibt. Mal ganz abgesehen vom Preis. Aber das ist hier off-topic.)

VG,
Fry

[Fry]

Option1:
ebusd (inkl. kompletter Datenverarbeitung/config + RRD + eibd) - UDP/Telnet - Wiregate Plugin

Option2:
ebusd - ebusd.pl (inkl. kompletter Datenverarbeitung + RRD + eibd) - UDP/Telnet - Wiregate Plugin

Option3:
ebusd - UDP/Telnet - Wiregate Plugin

Option 1 finde ich suboptimal. Sie stellt den längeren Weg zum Ziel dar und ist schwerer zu pflegen. Immerhin ist ebus bei weitem nicht so gut standardisiert wie KNX. Daher kann es gut sein, dass irgendwelche Hersteller sich nicht ganz an die "offizielle" Doku halten. Und irgendwelche non-Standard-Telegramme nachträglich in den C-Code zu hacken, ist zwar möglich, aber eben schwerer. Wenn sich natürlich jemand die Mühe machen möchte, nur zu...

Option 2 und 3 finde ich beide prima.

VG, Fry