Direktes Lesen/Schreiben von CV in MySQL

[netsrac]

Das könnte man in r/w abfangen und da "MeineVariable" offensichtlich keine GA ist, stattdessen auf %plugin_info zugreifen.

Ich finde diesen Gedanken nicht kompliziert - allerdings verstehe ich zu wenig von der CV-Architektur, um die Umsetzungshürden einschätzen zu können. Wie würde man das anpacken?

Genau sowas wäre eben für meine Anwendung (kein Wiregate Plugin) auch das richtige. Ich will extern Daten schreiben und die CV soll sie lesen und Anzeigen. Demnach finde ich eine generelle Lösung am schönsten.

Ich hatte schon überlegt, ob man einen Wrapper um das "r" und "w" setzt, der die Requests entsprechend umbiegt. Leider bekommt man ja alle Adressen in einem Aufruf.

Gäbe es eine Möglichkeit, die CV davon zu überzeugen, für jede Adressgruppe (KNX:1/2/3, whatever:variable) einen eigenen Request zu machen.

Gruß, Netsrac

[Fry]

Für das interaktive Bearbeiten eines dicken und ziemlich statischem Status-Objektes - wie es z.B. so ein Szenen-Mapping ist - ist der Weg über das CometVisu-Protokoll und den KNX eher ungeschickt. Das ist nämlich für Echtzeit-Updates gedacht - was hier nicht gebraucht wird.

Prinzipiell korrekt, ich denke nur, dass man durch eine geringfügige Anpassung des Backends (lesen/schreiben von /tmp/wiregate_plugin.db statt über EIB) das gesamte Frontend nutzen könnte. Das hätte dann den Vorteil einer schönen und einheitlichen Oberfläche.

Die richtige Lösung wäre eine Web-Seite zu schreiben (persönlich bin ich ein Freund von PHP, in diesem konkreten Kontext und bzgl. der Fähigkeiten von Fry dürfte aber ein Perl CGI die bessere Wahl sein). Diese Web-Seite würde per <web>-Widget eingebunden. Wäre ja nicht die erste Anwendung davon...

Perl wäre auch besser wegen des leichten Zugriffs auf die DB.

Um dieser Aussage gleich zu widersprechen: Szenen sind ja nicht neu für KNX. Wieso nicht die übliche Lösung über den KNX selbst dafür?
D.h. alle gewünschten Kanäle werden normal eingestellt (z.B. per Slider). Und dann per speziellem Button (normalerweise Szenen-Nummer + 80h, oder so) werden diese Werte ausgelesen und unter dieser Szenen-Nummer gespeichert.

Siehe oben, weil nicht alle Aktoren für alle eingestellten Werte KOs fürs Auslesen anbieten. Plus, weil diese Option für das "massenweise" Einprogrammieren von Szenen sehr, sehr unkomfortabel ist. (vergleiche Klickoberfläche mit Tabellenoberfläche - hier wäre es sogar eine Rumrenn-Schalterdrück-Klick-Oberfläche)

Da ich nun wieder aus dem Urlaub zurück bin, kann ich wohl besser helfen hier zu einer passenden und sinnvollen Lösung zu kommen...

Das wäre super und ehrlich gesagt war das auch meine Hoffnung.

Also zurück auf die o.g. Idee: wie greifen eigentlich die <address>-Tags und die eibread-cgi/eibwrite-cgi ineinander? Kann man sich da nicht einklinken und einfach für die Fälle, wo <address> keine EIB-GA beinhaltet, auf die Datenbank zugreifen?

So in dem Stil

<switch><address>MeineVariable</address></switch>

Das könnte man in r/w abfangen und da "MeineVariable" offensichtlich keine GA ist, stattdessen auf %plugin_info zugreifen.

Ich finde diesen Gedanken nicht kompliziert - allerdings verstehe ich zu wenig von der CV-Architektur, um die Umsetzungshürden einschätzen zu können. Wie würde man das anpacken?

VG, Fry

[Chris M.]

Ich glaube auch, dass hier viel zu kompliziert gedacht wird.

Für das interaktive Bearbeiten eines dicken und ziemlich statischem Status-Objektes - wie es z.B. so ein Szenen-Mapping ist - ist der Weg über das CometVisu-Protokoll und den KNX eher ungeschickt. Das ist nämlich für Echtzeit-Updates gedacht - was hier nicht gebraucht wird.

Die richtige Lösung wäre eine Web-Seite zu schreiben (persönlich bin ich ein Freund von PHP, in diesem konkreten Kontext und bzgl. der Fähigkeiten von Fry dürfte aber ein Perl CGI die bessere Wahl sein). Diese Web-Seite würde per <web>-Widget eingebunden. Wäre ja nicht die erste Anwendung davon...

Um dieser Aussage gleich zu widersprechen: Szenen sind ja nicht neu für KNX. Wieso nicht die übliche Lösung über den KNX selbst dafür?
D.h. alle gewünschten Kanäle werden normal eingestellt (z.B. per Slider). Und dann per speziellem Button (normalerweise Szenen-Nummer + 80h, oder so) werden diese Werte ausgelesen und unter dieser Szenen-Nummer gespeichert.

Der Charm an diesem Ansatz ist, dass man sieht, was man macht. Mit 70% Dim-Wert kann ich wenig anfangen - mit einer konkreten Helligkeit dagegen viel (und die ist dann eher 67% oder 74% - aber selten eine glatte Zahl...).

Da ich nun wieder aus dem Urlaub zurück bin, kann ich wohl besser helfen hier zu einer passenden und sinnvollen Lösung zu kommen...

[netsrac]

bin ja nicht der Profi, aber wärs nicht einfacher die (Szenen)-Daten in die Configdatei des Szenencontroller-Plugins zu schreiben?

Eigentlich ist das ja egal, ob es eine Config, eine Database oder irgendein andere Backend ist.

Es wäre schön, einen Weg zu finden, wie man Daten (Werte, Clicks usw) aus der CV über ein standarisiertes Gateway bekommt.

[Yfkt5A]

Hallo zusammen...

bin ja nicht der Profi, aber wärs nicht einfacher die (Szenen)-Daten in die Configdatei des Szenencontroller-Plugins zu schreiben?

Hier mal die Beschreibung so wie ich mir das Vorstellen würde:
In der CV lässt sich auf der Seite Szenen wählen ob man eine vorhandene Szene bearbeiten oder eine neue Anlegen will...
bei der bestehenden werden die GA´s und deren Werte eingelesen und dargestellt, ausserdem noch eine Möglichkeit andere GA´s zu ergänzen...
Bei einer neuen Szene kann man aus der im WG importierten GA´s wählen...
beim Speichern wird das dann in der Szenencontroller.conf abgelegt:

Schlafzimmer => {store=>'0/1/2', recall=>'0/1/3', gas=>{'1/2/3'=>'1/2/3', '1/2/4'=>'1/2/5'}},

[netsrac]

Im ersten Schritt wollte ich nur wissen, wann und womit r/w überhaupt aufgerufen werden. Ich habe daher r umgebogen auf /usr/bin/read-cgi mit folgendem Inhalt:

Du hättest doch auch einfach ins Logfile from Webserver schauen können....da hast Du sie auch drin :-)

[Fry]

Beim weiteren Kramen ist mir aufgefallen, dass es offenbar bereits ein Widget <wgplugin_info> gibt. Das könnte ja genau das sein, was ich hier brauche. Weiß jemand, wie man dieses Widget benutzt?
VG, Fry

[Fry]

Diese Idee hatte ich auch schon, und "r" und "w" durch Perl-Wrapper ersetzt. Die Idee ist, dass der Wrapper unterscheidet, ob eine Anfrage über den EIB oder anders beantwortet werden soll, und dann eibread/eibwrite oder eben was anderes aufruft.

Im ersten Schritt wollte ich nur wissen, wann und womit r/w überhaupt aufgerufen werden. Ich habe daher r umgebogen auf /usr/bin/read-cgi mit folgendem Inhalt:

#!/usr/bin/perl

my $out="REQUEST_METHOD='$ENV{REQUEST_METHOD}' QUERY_STRING='$ENV{QUERY_STRING}' CONTENT_LENGTH='$ENV{CONTENT_LENGTH}'";
open OUT, ">>/var/log/read.log";
print OUT "$out\n";
close OUT;

system "/usr/bin/eibread-cgi";

Ergebnis: die CometVisu funktioniert unverändert, im Logfile /var/log/read.log landet gar nichts (das File wird nicht mal erzeugt).

Irgendeinen Hinweis?

VG; Fry

[netsrac]

Mal andersrum gefragt: gibt es irgendwo eine Doku, wie die CV eigentlich funktioniert?

Jupp...das gibt es hier:

CometVisu/Protokoll (Deutsch) - Open Automation

Wobei im Moment eben nur "r" und "w" implementiert sind. Man müsste also entweder die CV davon überzeugen, verschiedene Backends zu nehmen oder - in meinen Augen die bessere Lösung - die "r" und "w" durch ein besseres Backend (evtl. mit Plugin-Basis) zu ersetzen...

[Fry]

Mal andersrum gefragt: gibt es irgendwo eine Doku, wie die CV eigentlich funktioniert? Also wie die verschiedenen Skripte ineinandergreifen. Denn ich weiß momentan nichtmal, wo ich eigentlich anfangen muss zu lesen...

[netsrac]

Naja, generell ist die Idee ja nicht schlecht, noch andere "Connection Types" zu erlauben. Für meinen Fall wäre es memcached, den ich gerne nutzt würde im Werte in der CV darzustellen - Daten wir Stromverbrauch im diesen und im letzten Monat, daraus entstehende Kosten, Niederschlagsmende in bestimmten Zeiträumen...all das "verschmutzt" mir unnötig den Bus. Zumal sie von dem selben Rechner generiert und ermittelt werden, der die CV hostet....sie gehen also nur auf den KNX Bus um dann lokal wieder gelesen zu werden....macht irgendwie wenig Sinn.

Hatte aber leider noch keine Zeit, hier mal zu experimentieren...

Netsrac

[JuMi2006]

Also ganz ehrlich ... bevor da alles umgebogen wird is es doch einfacher ein iframe/web einzubinden.

Also erstmal jenseits der CV den Kram in ein cgi/php/html zu gießen und dann via <web>...meinkram.cgi</web> in die CV einbinden.
Wie man nun via http auf die Datenbank zugreift kann ich auch nicht sagen (Null Plan) aber ich denke google wird da gut helfen können. Somit kannst Du Deine Perl-fähigkeiten da voll ausspielen

Grüße

[Fry]

Ok, dann erkläre ich es nochmal:

Ich HABE ein WG-Plugin, das Szenen realisiert. Es reagiert auf ein Telegramm zB eines Tasters, indem es mehrere Telegramme zB an Schaltaktoren und Jalousieaktoren sendet. Genau welche Inhalte es dabei sendet, wird in %plugin_info und damit in der Berkeley-DB /tmp/wiregate_plugin.db gespeichert. Soweit alles ok und PERLig. (Die Möglichkeiten der Wiregate-Plugins überblicke ich übrigens ganz gut -> die Plugins Szenencontroller, Logikprozessor, Ansagen und Anwesenheitssimulation sowie Heizungsregler stammen von mir).

Nun möchte ich in der CometVisu auf einfache Weise Szenen dieses Plugins programmieren ("einlernen") können. Ich stelle mir eine Seite in der Visu vor, in der ich auf einfache Weise in Tabellenform Szenen einprogrammieren kann (Tabellenzeile=Szenennummer, Spalte=Licht oder Jalousie). Soweit ist meine Vorstellung relativ einfach.

Das Problem ist, die beiden Sachen miteinander zu verbinden. Die CV läuft - soweit ich es verstehe - mit XML, Javascript, CSS, whatever, alles Sachen die ich nicht "kann", weil ich mich bisher nicht in Web-Programmierung eingearbeitet habe (bisher kein Anlass). Das einzige Medium, über das die CV kommunizieren kann - soweit ich weiß - ist der KNX-Bus. Um die o.g. Idee umzusetzen, müsste ich daher alles auf den Bus schicken. Das gefällt mir konzeptionell nicht, denn alles, was ich mit o.g. Tabelle machen will, ist die Datenbank /tmp/wiregate_plugin.db direkt lesen und schreiben.

Wie würdest du das technisch umsetzen?

VG, Fry

PS. Vermutlich wirst du jetzt darauf hinweisen, dass man Szenen "einlernen" kann, indem man Jalousien/Lichter schaltet und dann beim Senden der "Szene speichern"-GA diese Werte abfragt und speichert, um sie später bei der "Szene abrufen"-GA wieder aufzurufen. Genau das tut mein Plugin. Mein o.g. Ansatz soll helfen, dass man Szenen auch direkt und übersichtlich in Tabellenform eingeben kann, ohne den Umweg über das Teach-in gehen zu müssen.

Ein weiterer Grund, warum ich die direkte Programmierung möchte, ist dass nicht alle meine Aktoren überhaupt KOs dafür anbieten, alle eingestellten Werte abzufragen. Zum Beispiel hat der MDT-Dalicontrol nur ENTWEDER Rückmeldeobjekte für AN/AUS ODER Rückmeldeobjekte für den Dimmwert, aber nicht beides - und im Fall der Einzel-EVG-Ansteuerung gar kein Rückmeldeobjekt.

[ctr]

Ich verstehe immernoch nicht was Du wirklich willst, ich glaube Du verkomplizierst hier alles unnötig.
Mal so in den Raum geworfen:
- Wenn Du aus einem Plugin %plugin_info abrufst, geht das *nicht* über den Bus (insofern gibt es keinen "Umweg über den Bus")
- Ein Umstellen der wiregate_plugin.db auf MySQL ist mitnichten möglich. Du kannst evtl eine MySQL Datenbank erstellen, die die Datenstruktur hat, möglicherweise auch die Daten (zum Zeitpunkt der Konvertierung), aber das Wiregate selbst wird trotzdem weiterhin in die BDB in /tmp/wiregate_plugin.db schreiben und auch daraus lesen und nicht aus Deiner MySQL DB
- Direkt auf die BDB zuzugreifen mag gehen (da bin ich mir sogar ziemlich sicher), aber ich sehe nicht was Dir das bringt, was nicht auch im Wiregate-Kontext geht und außerdem besteht natürlich auch noch die Möglichkeit (ohne Dir zu Nahe treten zu wollen, aber bei dem Level sogar eine sehr große) dass Du Dir die DB schrotest und das WG dann ein Fall für den Support ist

Also nochmal von vorn: Was willst Du eigentlich erreichen? Was soll bei dem Knopfdruck passieren? Eine vordefinierte Szene abspielen? Wie willst Du die Szene einlernen?

Ich mir zu 99% sicher, das was Du erreichen willst mit einem einfachen WG Plugin ohne jeglichen direkten "DB" Zugriff möglich ist...

[Fry]

Das Hash %plugin_info ist mittels des Perl-Kommandos "tie" im wiregated.pl an die Datenbank /tmp/wiregate_plugin.db geknüpft. Das bedeutet, jeder Schreib/Lesezugriff auf %plugin_info wird in einen Datenbankzugriff umgewandelt. Das ist übrigens auch der Grund, weshalb man nur Skalare in %plugin_info speichern kann (also keine Substruktur).

Mein Gedanke war nun, diese Datenbank und damit das Hash %plugin_info gleichzeitig mit dem wiregated.pl auch per CV/PHP-Skript zu lesen/schreiben und damit den Umweg über den Bus zu vermeiden.

Allerdings ist - da hatte ich mich geirrt - /tmp/wiregate_plugin.db keine MySQL-Datenbank, sondern eine Berkeley-Datenbank. Insofern ist mir auch nicht klar, ob man gleichzeitig mit einem PHP-Interface auf die DB zugreifen kann, oder ob das zu Fehlern führt. An dieser Verwirrung seht ihr schon, ich kenne mich damit nicht wirklich aus. EDIT: habs nachgesehen, Berkely DBs erlauben gleichzeitige Zugriffe über ein einfaches Modell namens "CDS". Das würde hier vermutlich reichen. Im Zweifel könnte man auch auf eine SQL-DB umstellen (MySQL oder SQLite), dann gehen parallele Zugriffe auf jeden Fall.

So oder so hätte ich also Bedarf für die Möglichkeit, per CV auf eine Datenbank zuzugreifen. Ich stelle mir das in der CV-Konfi praktisch so vor, dass man die vorhandenen Widgets nutzt, nur statt <address>...</address> eben ein <database>....</database>-Tag einführt, in dem der DB-Schlüssel genannt wird, der gelesen/geschrieben wird.

Kann eigentlich nicht so schwer sein. Nur für mich ist der Weg etwas lang, weil ich an XML/CSS/PHP/SQL nicht gewöhnt bin (ist aber Standardkram für Web-Programmierer).

Ist es jetzt klarer geworden? Tut mir leid, wenn ich die Frage nicht ganz korrekt gestellt habe. Jetzt ist es zumindest mir selbst klarer geworden. Implementieren kann ich es trotzdem noch nicht.

VG, Fry

PS. Noch was: ja, Szenen können viele Aktoren realisieren, aber offenbar ist das kein übergreifendes, einheitliches Konzept in KNX. Zumindest meine Aktoren haben offenbar mehrere verschiedene Konzepte dafür (zB Pear-Schaltaktor vs MDT-Dali-Gateway vs übrige MDT-Aktoren). Ich würde das daher lieber über ein WG-Plugin lösen.