Textfeld > 14 Byte

[Chris M.]

Websockets sind inzwischen deutlich nutzbarer - aber keine Ahnung ob die relevanten Firewalls das durchlassen. Man ist hier halt nicht nur auf den Browser angewiesen...

Was leider kaum beachtet wird und genau dem entspricht, was wir hier brauchen sind https://en.wikipedia.org/wiki/Server-sent_events - die meisten relevanten Browser können das auch inzwischen (When can I use... Support tables for HTML5, CSS3, etc), nur natives Android fehlt leider.

Eine kurzfristiger Workaround könnte sein, die Wiregate-Plugin-Infrastruktur so zu erweitern, dass per URL der Inhalt eines $plugin_info ausgelesen werden kann.
Nun könnte man ein Widget machen, dass bei Aufruf einer GA diese URL aufruft und das Ergebnis anzeigt.

[makki]

..nur natives Android fehlt leider.

Also 68% des Smartphone-Markt.. Blöd..

Eine kurzfristiger Workaround .. dass bei Aufruf einer GA diese URL aufruft und das Ergebnis anzeigt.

Das ist easy bzw. gibts das schon (evtl. noch nicht im SVN) ist aber IMHO Banane weil eben dummes polling..
Mir schwebt eher vor, den Songtitel/Interpret nur an den client zu senden, wenn sich dieser geändert hat - dann aber dafür sofort!

Makki

[Chris M.]

Das ist easy bzw. gibts das schon (evtl. noch nicht im SVN) ist aber IMHO Banane weil eben dummes polling..

Eben nicht!

Ich sende auf eine GA die Info, dass sich etwas geändert hat (oder nutze eine andere GA mit, z.B. für Laufstärke).
Das Widget hört auf diese GA und nur wenn diese GA über den Bus kommt, wird die URL neu geladen.

=> Komplett Event getrieben, kein Polling notwendig.

[perf]

Eine kurzfristiger Workaround könnte sein, die Wiregate-Plugin-Infrastruktur so zu erweitern, dass per URL der Inhalt eines $plugin_info ausgelesen werden kann.
Nun könnte man ein Widget machen, dass bei Aufruf einer GA diese URL aufruft und das Ergebnis anzeigt.

Genau das ist was ich gern hätte!

/Per

[makki]

Das (Event-getrieben) ist aber so im Webserver aktuell nicht drin, mit einem einzigen Prozess/Thread (oder wie auch immer man das - je nach definition - nennt) x10 Visu Clients ist da schnell Ende-Gelände..
Bzw. nur mit recht viel Aufwand.. Man kann die BDB pollen, ja, aber push geht so nicht..
(der Trick wäre ein wrapper um $plugin_info{..} - wäre ja machbar aber die Frage ist: wohin damit.. TCP/UDP persistent rauszuschieben ist mit dem Rest kein Problem..)

Da könnte man sich nun was ganz eigenes ausdenken; tendiere aber eher dazu zukunftsträchtige Standards zu verwenden - sofern eben praktikabel&möglich.. Also Websockets..

Makki

[Chris M.]

Entweder ich drücke mich umständlich aus und Du verstehst mich nicht - oder ich verstehe Dich nicht

Also mal anders:
Bietet die aktuelle WG Infrastruktur die Möglichkeit mit überschaubarem Aufwand einen weiteren Web-Service / interaktive Webseite anzubieten, wo über die URL eine $plugin_info Variable ausgelesen wird?

Beispiel:

GET http://wiregate/voodoo?pluginname_foo

gibt sofort als Antwort

bar

unter der Annahme

$plugin_info{'pluginname_foo'} = 'bar'

(Und wenn der Key nicht existiert kommt halt was leeres zurück)

Um das ganze nicht Pollen zu müssen sonder nur bei Bedarf laden zu müssen, würde das Plugin ein extra knx_write() durchführen und das Widget auf diese GA hören. Aber das ist jetzt gerade NICHT die Frage. Die Frage ist nur das o.g. Beispiel...

[makki]

Entweder ich drücke mich umständlich aus und Du verstehst mich nicht - oder ich verstehe Dich nicht

Das ist in Foren oft so, aber noch besser als bei Twitter

Also mal anders:
Bietet die aktuelle WG Infrastruktur die Möglichkeit mit überschaubarem Aufwand einen weiteren Web-Service / interaktive Webseite anzubieten, wo über die URL eine $plugin_info Variable ausgelesen wird?

Kein Problem. Liegt irgendwo auf der Platte..

Um das ganze nicht Pollen zu müssen sonder nur bei Bedarf laden zu müssen, würde das Plugin ein extra knx_write() durchführen

Das war der fehlende Schlüssel weil das halt ein bisschen umständlich ist und ich es gerne eleganter lösen würde - aber klar: das würde so gehen!

(im schlimmsten Fall nimmt man das edit_plugins.cgi als Vorlage, da wird die plugin_info.db gelesen, filtert das, fertig..)

Makki

[perf]

Dann hoffe ich bald so ein Widget/Plugin-Combo zu probieren können!

[makki]

Der Ansatz von Chris ist pragmatisch&einfach, nachdem *jeder* aber die gesamte Infrastruktur via GPL unter Kontrolle hat, hätte ich mir was intelligenteres,durchdachtes gewünscht..
Vielleicht denke ich hier aber nun zu kompliziert

Makki

Edit: Je länger ich darüber nachdenke, desto besser gefällt mir Chris' Ansatz nach dem Update eine GA zu triggern denn das ist zwar serverseitig nicht 100% smart aber lässt sich einfach umsetzen..

[makki]

Also mal in schnell runtergeschrieben, ein CGI das plugin_info als JSON ausgibt:
Speichern als - und
chmod a+x /var/www/wg-plugindb.pl

#!/usr/bin/perl -w

use DB_File;
use Fcntl;
use strict;

my $plugin_infofile = "/tmp/wiregate_plugin.db";
my %plugin_info;
tie %plugin_info, "DB_File", $plugin_infofile, O_RDONLY, 0666, $DB_HASH
 or die "Cannot open file 'plugin_info': $!";

print "Content-Type: text/plain\n\n";

print "{ ";
# Split query-string into name/value pairs
my @pairs = split(/&/, $ENV{'QUERY_STRING'});
my $sep ='';

foreach my $pair (@pairs)
{
    my ($name, $value) = split(/=/, $pair);
    if ($name eq "name" && defined($plugin_info{$value}) ) {
        print "$sep \"$value\" : \"$plugin_info{$value}\" ";
        $sep = ',';
    }
}

# end json
print " }";

Sicher nicht perfekt, geht aber.
- Nimmt als Parameter name=, also
"http://wiregateXXX/wg-plugindb.pl?name=Meinplugin.pl_Titel&name=Meinplug in.pl_Interpret" gibt ein JSON aus mit
{ "Meinplugin.pl_Titel" : "DerTitel", "Meinplugin.pl_Interpret" : "DerInterpret" }
- Als Perl (wollts eigentlich in PHP machen) weil die plugin_info.db ein tied-Hash ist und das etwas eklig ist in PHP; Alternative analog zu rsslog einfach ne sep. sqlite-DB machen oder (einfacher) das JSON wegschreiben (oder, oder oder.. es gäbe hunderte andere Wege)
- Wenn man den Weg gehen will gehört das natürlich ins SVN was ich dann machen würde.
- use CGI/Carp habe ich bewusst erstmal vermieden, weil das alles dick&fett ist..
- 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.

Wenn mir mal langweilig ist (Treppenwitz) teste ich das mit den Websockets, damit sollte es eigentlich theoretisch kein Problem sein die Visu ohne Umwege bei Bedarf mit sowas zu direkt zu füttern ohne den Webserver und eine sep. Perl-Instanz bemühen zu müssen..

Makki

[perf]

Toll!

Chris: Ist das passende CV-Plugin eine einfache Sache?

/Per

[makki]

Das CV-Plugin sollte übersichtlich sein, vglbar RSSLog oder so..
Aber wiegesagt: so richtig gefallen tut mir der Ansatz noch nicht, im Sinne des CV-Protokolls fände ich einen eigenständigen "Push-Service" eleganter; also sowas wie D-Bus nur in schlank&einfach..
-> Anregungen willkommen.

Weil wir haben beide Seiten des Codes im Griff, die Variante Perl->PluginDB->BDB->Webserver->Perl->CV ist irgendwie so eine Knie-Brust-Auge-Nummer
Bis mir was besseres einfällt, ists aber eine Lösung..

Makki

[Chris M.]

Aber wiegesagt: so richtig gefallen tut mir der Ansatz noch nicht, im Sinne des CV-Protokolls fände ich einen eigenständigen "Push-Service" eleganter; also sowas wie D-Bus nur in schlank&einfach..
-> Anregungen willkommen.

Die Richtige Lösung ist die internen Werte der LogicEngine auch auf die CometVisu-Übertragung zu legen.

Das Protokoll kann's (-> Namespace) - nur das aktuelle Backend mit den WG-Plugins nicht.

Für mich ist die richtige Lösung also eine richtige LogicEngine. Bis dahin gibt's das Provisorium (oder einen beliebigen anderen Ansatz aus der Community...).

[Chris M.]

Mit Revision 999 ist jetzt das Widget <wgplugin_info> vorhanden. Ein Beispiel der Nutzung ist in der Demo-Config unter erweiterte Widgets zu finden.

Hinweis:
Das ist eine schnell gehackte Version... Ich habe es auch noch nicht mit WG-Plugins mit Leerzeichen im Namen ausprobiert.

Da aber Leerzeichen im Namen im Browser beim Testen schon nicht funktionert hatte, habe ich in Zeile 22 von Makkis Code dies eingefügt:

$value =~ s/%([A-Fa-f0-9]{2})/pack('C', hex($1))/seg;

[makki]

Nun, LE kann ich grad keine liefern aber man könnte trotzdem die middleware schonmal schlau&skalierbar machen; möchte das Thema daher im Auge behalten.
Also im Prinzip vermutlich ein eigenes transform so wie KNX, das optimalerweise mit long-polling und ohne trigger-GA arbeitet..

-> aber es ist sicherlich sinnvoll erstmal eine funktionierende, praktikable Lösung mit wenig Aufwand zu haben!!

Leerzeichen in Dateinamen sind nach meiner Doktrin schlicht verboten ich schau mir das nochmal an - da gibts sicher auch noch 1-2 andere Dinge zu optimieren - und würde es dann zum CV-Plugin ins SVN schieben..

Makki