Direktes Lesen/Schreiben von CV in MySQL

[Chris M.]

Die Frage ist, ob man das eher dem WireGate oder der CometVisu zuordnet...

Wenn man sagt, dass gehört zur CV, dann wäre der richtige Ort sicherlich als CometVisu-Plugin.

Persönlich hätte ich das allerdings eher als WG Bestandteil gesehen. Am besten gleich per Paket.
Aber realistisch betrachtet: packt das Skript am besten in ein CP-Plugin-Ordner...

[swiss]

Ok. Liegt warscheinlich aber daran, dass das WG Plugin schneller abgearbeitet wird, als die Abfrage der CV. Ich habe nämlich keine Verzögerung gesehen. Und dann kann es bei umfangeicheren WG Plugins die auch mal 1-2 Sekunden brauchen schon zu Probleme kommen...

[koend]

OK, ich schicke Chris mal eine PM mit einem Hinweis.

Der Vollständigkeit halber. Obwohl keine Pause eingebaut ist, funktioniert folgende config prima (also Variableninhalt wird beim Klicken erneuert, auf den gerade gesetzten Wert):

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

[swiss]

Supi Ist gern geschehen

Aber ich denke man sollte doch nochmal mit Chris darüber sprechen ob es nicht mehr Sinn ergeben würde das Plugin innerhalb des CV Ordners zu haben.

[koend]

Et voilà, es funktioniert! Mein zweiter Vorname ist fortan Blindfisch. (weil steht hier ja: https://knx-user-forum.de/cometvisu/...tml#post252600)

DANKE SEHR!!!

[swiss]

Ich sehe gerade wo das Problem liegt...

wg_plugindb.pl gehört direkt ins www Verzeichniss. Also eine Ebene nach oben

PS: Wiso das so ist... Weil warscheinlich der Punkt vor der Pfadangabe fehlt... Da müsste man mal Chris fragen ob man das fixen sollte denn eigentlich würde das Plugin innerhalb des CV Ordners mehr Sinn machen.

[koend]

Ich befürchte zwei Mal ja :-)

Ja, http://wiregateXXX/visu_svn/wg-plugi...peningHoursSet liefert

{  "openingHoursSet" : "jaa"  }

und

-rwxr-xr-x  1 root     root       639 29. Jun 22:57 wg-plugindb.pl

sollte auch stimmen.

Kannst du vielleicht einen entsprechenden Ausschnitt aus deiner Visu posten bitte?

Welche CV Version benutzt du?


Vielen Dank für deine ausdauernde Hilfe!

Zur Vollständigkeit hier einmal der Quellcode wgplugin_info.js:

/* info.js (c) 2012 by Christian Mayer [CometVisu at ChristianMayer dot de]
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License as published by the Free
 * Software Foundation; either version 3 of the License, or (at your option)
 * any later version.
 *
 * This program is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 * more details.
 *
 * You should have received a copy of the GNU General Public License along
 * with this program; if not, write to the Free Software Foundation, Inc.,
 * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA
 */

basicdesign.addCreator('wgplugin_info', {
  create: function( element, path, flavour, type ) {
    var $e = $(element);
    var layout = $e.children('layout')[0];
    var style = layout ? 'style="' + basicdesign.extractLayout( layout, type ) + '"' : '';
    var ret_val = $('<div class="widget clearfix info" ' + style + ' />');
    //type == '3d' && ret_val.data( extractLayout3d( layout ) ).bind( 'update3d', this.update3d );
    type == '3d' && $(document).bind( 'update3d', {element: ret_val, layout: basicdesign.extractLayout3d( layout )}, this.update3d );

    basicdesign.setWidgetLayout( ret_val, $e );
    basicdesign.makeWidgetLabel( ret_val, $e, flavour );
    if( $e.attr('flavour') ) flavour = $e.attr('flavour');// sub design choice
    if( flavour ) ret_val.addClass( 'flavour_' + flavour );
    var address = basicdesign.makeAddressList($e);

    var actor = '<div class="actor"><div class="value">blub</div></div>';
    var $actor = $(actor).data({
      'variable' : $e.attr('variable'),
      'address'  : address,
    });
    for( var addr in address ) $actor.bind( addr, this.update );
    ret_val.append( $actor );
    return ret_val;
  },
  update: function( e, data, passedElement )
  {
    var element = passedElement || $(this);

    var variable = element.data( 'variable' );
    var valueElement = element.find('.value');
    $.getJSON('/wg-plugindb.pl?name=' + variable, function(data) {
      templateEngine.setWidgetStyling(element, element.data('basicvalue'));

      if( element.data( 'align' ) )
        element.addClass(element.data( 'align' ) );
      valueElement.empty();
      valueElement.append( data[variable] );
    });
  },
  update3d: basicdesign.defaultUpdate3d
}); 

[swiss]

Hmmm...

Steht denn die Variable auf dem WG genau so zur verfügung? Vor allem das setzen der Berechtigungen für das CV_Plugin hast du auch gemacht? Denn bei mir funktioniert es auf Anhieb.

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

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

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]

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]

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

[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

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