Direktes Lesen/Schreiben von CV in MySQL

[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

[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

[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 :-)

[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]

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.

[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...

[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

[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

[Chris M.]

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.

Grundsätzlich ist es der CV ja egal, was sich hinter den Adressen verbirgt.
Ich hatte auch extra die Namespaces eingeführt um hier zwischen verschiedenen Datenquellen im Backend unterscheiden zu können.

D.h. das Backend müsste die Adressen nach Namespace parsen und die Requests entsprechend aufteilen.

Zur einheitlichen Oberfläche: die Hilft natürlich nur so weit es die benötigten Widgets gibt.
D.h. wenn Du eine editierbare Tabelle möchtest, wirst Du damit aktuell nicht weiterkommen...

Hier könntest Du ein CV-Plugin schreiben, das sich darum kümmert (ein CV-Plugin ist ähnlich einem Widget, nur das es deutlich komplexer sein darf. Es darf auch eigene Verbindungen aufmachen - was z.B. das Diagram-Plugin nutzt um die Daten zu holen. Ohne jeglich Verwendung des CometVisu-Protokolls, übrigens)

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?

Die Info im <address>-Element wird 1:1 an "r" und "w" weitergeleitet. Ob da drinnen nun "foo", "bar", "KNX:1/2/3" oder "9/8/7" steht ist der CV vollkommen egal.
Am Server ist "r" und "w" per Symlink auf eibread-cgi bzw. eibwrite-cgi gemappt. Hier könntest Du das Mapping natürlich auf etwas ganz anderes umbiegen, wenn Du willst - wichtig ist nur, dass das CometVisu-Protokoll gesprochen wird (Doku davon auf der Homepage: CometVisu/Protokoll (Deutsch) - Open Automation)

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

Klar, Du musst nur das CV-Protokoll sprechen.

Server die das CV-Protokoll sprechen hab ich inzwischen übrigens in mehreren Sprachen und Varianten geschrieben. Das ist nicht sonderlich schwer...

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?

Lies mal die Doku des Protokolls. Dann sollte schon mal vieles klar werden. Hoffe ich...

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.

Klar, der nächste Schritt wäre dem aktuellen Backend weitere Namespaces beizubringen.

Da allerdings das aktuelle Backend ein typisches Provisorium ist (nichts hält länger...), dürfte eine Neuimplementierung sauberer sein.

Die bin ich übrigens mit GrAF angegangen. Das kann auch Namespaces. Man müsste nur noch die anderen Datenquellen anflanschen.
Zwar nicht schwer, das ist aber in Summe Mittelfristig und nicht Kurzfristig...
Das Thema GrAF bin ich durchaus bereit zu diskutieren - aber bitte auf der Open Automation Mailingliste, da das erst mal mit der CV nichts zu tun hat. (Status von GrAF ist, dass ich noch kurz davor bin, etwas zu haben, mit dem man als Grundlage anfangen kann zu Diskutieren. Dann wollte ich nach Mitstreitern suchen - vorher wäre es zu abstrakt)

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.

Nein, das macht so leider keinen Sinn. Da würde man sich bisschen Einfachkeit bei der Implementierung durch schlechteres Laufzeitverhalten (hier: Ressourcen) einfangen.
Die CV probiert ganz bewusst den umgedrehten Weg zu gehen: Egal wie schwer die Implementierung ist, die Laufzeit hat optimal zu sein!

Richtig ist, dass die CometVisu-Anwendung eine Verbindung aufmacht und das Backend dann entsprechend aufteilt (s.o. in diesem Reply)

[ctr]

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

Auch wenn eigtl schon alles gesagt ist hier noch der vollstäbdigkeit halber:
Man braucht noch folgendes Perlscript:
https://knx-user-forum.de/252600-post40.html

[koend]

Moin,

mangels findbarer Doku doch mal hier die Frage: wie funktioniert wgplugin_info denn nun? ;-)

Ich habe mir den Quelltext angeschaut (structure/pure/wgplugin_info.js) und verstehe den so, dass
- das Element eine GA abonniert,
- beim Aufruf der GA das JSON Perlscript aufruft,
- Rückgabewert parst und
- das Element mit dem neuen Wert füllt.

Also dachte ich dass wenn ich
- einen via multitrigger die abonnierte GA anstoße und
- das entsprechende WG-plugin den plugin_info Wert setzen lasse,
- das obige Element den neuen Wert von plugin_info anzeigen müsste.


Das Perlscript direkt aufgerufen funktioniert prima hier.

Vielen Dank im Voraus

Koen

[swiss]

Hallo

Also bei mir funktioniert es. Die Frage ist wiso es bei dir nicht tut...

Hast du auch den DPT korrekt mit DPT:1.001 eingetragen?

Wiso nutzt du zum antriggern den Multitrigger? Der sendet doch verschiedene Werte an 1 GA. Aber das ist beim plugin_info ja überflüssig. Ich habe einfach einen normalen Trigger genommen der mir eine 1 sendet.

[koend]

Danke für die Info, gut zu wissen dass der Fehler wohl bei mir liegt und nicht an der cometvisu. :-)

Das Plugin zum Ändern der plugin_info sieht wie folgt aus (wenn auf der GA etwas empfangen wird):

        if ($msg{'data'} eq '02') {
            $plugin_info{'openingHoursSet'} = 'jaa';
        }
    
        if ($msg{'data'} eq '05') {
            $plugin_info{'openingHoursSet'} = 'jaja';
        }

Im Moment nur zwei Zustände, aber das werden wohl noch mehr. Deswegen auch der Multitrigger, der mit DPT:5.001 das Plugin anstößt. Damit kann ich dann über eine GA mehrere Zustände anstoßen.

        <multitrigger showstatus="true" button1label="jaa" button1value="1" button2label="jaja" button2value="2">
          <address transform="DPT:5.001" mode="write">2/1/2</address>
        </multitrigger>
        <wgplugin_info variable="openingHoursSet">
          <address transform="DPT:5.001" mode="read">2/1/2</address>
        </wgplugin_info>

Werde morgen mal probieren das Plugin auf DPT:1.001 umzubiegen... mal schauen ob das etwas bringt.

Benutze übrigens die cometvisu direkt aus dem Repository (svn update), falls das noch einen Unterschied macht.

[swiss]

Ach soo...

Ja das geht so nicht... In dem Beitrag in dem makki auch das Plugin veröffentlicht hat (und du es warscheinlich auch her hast ) steht nämlich:

- Beachten muss man dabei: Die Plugin_info wird erst nach dem beenden des Plugins geschrieben! Also sollte im CV-Plugin um auf der sicheren Seite zu sein - sagen wir mal - nach dem Trigger ein Delay von 500-1000ms für die Abfrage rein.

Bedeutet schlicht, dass du nicht gleichzeitig über die GA ein Plugin aufrufen kannst, dass die Plugininfo variable beschreibt und mit der gleichen GA zeitgleich das Widget antriggern, das den Status lesen soll... Ausser deine Version hat ein delay drinn. Meines nämlich nicht.

[koend]

Jep, das hatte ich gelesen, aber wohl nicht so ganz verstanden. :-)

Trotzdem sitzt irgendwie bei mir wohl ein Knoten im Gehirn...

        <wgplugin_info variable="openingHoursSet">
          <address transform="DPT:1.001" mode="read">3/0/0</address>
        </wgplugin_info>

Habe eine willkürliche GA genommen und sende da 1 und 0... und nichts passiert in der CV. Der - (Standardausgabe von wgplugin_info) bleibt stehen.
Müsste wgplugin_info nicht auf die GA reagieren und den aktuellen Wert ausgeben?

Vielen Dank und Gruß