informid - wann und wo setzen?

[Talkabout]

Hallo zusammen,

bei der Ausgabe von Geräten in FHEMWEB wird den Elementen auch ein Attribut "informid" mitgegeben. Ich vermute dieses Attribut wird verwendet, um dann Aktualisierungen per longpoll zu tätigen. Jetzt ist mir aufgefallen, dass wenn ich über PERL das HTML für ein Gerät anfrage, das Attribut mal mit dabei ist und mal nicht. Im speziellen Fall hole ich mir den Aufbau über:

Code Auswählen Erweitern

FW_devState($d, $rf, \%extPage);

oder

Code Auswählen Erweitern

&{$modules{$defs{$d}{TYPE}}{FW_summaryFn}}($FW_wname, $d, $FW_room, \%extPage);

Der 2. Fall ist für Geräte, die die Eigenschaft "atPageEnd" haben. Im 2. Fall ist auch der Container bereits mit dabei, der das Attribut "informid" beinhaltet. Zumindest in den Fällen die ich bisher hatte. Im ersten Fall ist dies nicht der Fall, und ich muss dieses Attribut selber setzen.

Meine Frage ist nun ob meine Beschreibung so korrekt ist und ob ich das Attribut im 1. Fall tatsächlich selber setzen muss, oder ob es da einen "eleganteren" Weg gibt?

Danke!

Gruss

[rudolfkoenig]

informId wird von fhemweb.js verwendet, um die zu benachrichtigenden Elemente bzw. Funktionen zu finden.
Das Attribut wird im Raum-Uebersicht im Statusbild-Eltern-Element (<td>) gesetzt.

Dashboard/readingsGroup/etc muss das auch selbst machen. Das waere nicht notwendig, wenn das FW_devState es setzen wuerde, allerdings waere ein Umbau auch nicht unproblematisch, und ich habe ihn erstmal nicht vor.

[justme1968]

wenn ein device wie LightScene oder readingsGroup den status bzw. das icon eines oder mehrere anderer devices anzeigt würde das automatische setzen informid in FW_devState auch nicht
funktionieren weil die informid zu den tatsächlich in einem raum vorhandenen devices passen muss. sonst werden die events automatisch ausgefiltert und kommen erst garnicht  am browser an.

gruss
  andre
gruss
  andre

[Talkabout]

Hallo Jungs,

danke für die Information.

Ich habe nach dem Post noch mal einen Blick in die Struktur der ReadingsGroups und der "normalen" Devices geworfen, und verstehe nun, warum das Attribut von den Modulen selber gesetzt werden muss und auch, warum bei den ReadingsGroups dieses schon mit kommt.

Vom Algorithmus her, wie oben beschrieben, sollte es aber passen, oder? Oder kennt Ihr noch weitere Ausnahmen, die man mit beachten muss (ausser "atPageEnd")?.

Danke!

Gruss

[Talkabout]

Hallo Jungs,

im Zuge der Eingangsfrage bräuchte ich noch die Info, was gemacht werden muss, damit auch SVGs automatisch per Longpoll aktualisiert werden. Das alleinige Setzen der informId scheint da nicht zu reichen. Wie ist das vom Konzept her gedacht?

Danke!

Gruss

[rudolfkoenig]

Falls du mein Demo: "longpoll mit SVG, was in perl generiert wird, funktioniert nicht gut, schau mal" verwenden willst, dann muss du vorher pruefen, ob die SVGs per embed geladen werden (plotEmbed, default is false fuer iOS und true sonst), und longpollSVG gesetzt ist. Falls es immer noch nicht geht, dann kannst du gerne einen Patch liefern.

Oder, besser, 98_SVG.pm in JavaScript nachbauen, damit koennte es auch ohne flimmern funktionieren.

[gandy]

Oder, besser, 98_SVG.pm in JavaScript nachbauen, damit koennte es auch ohne flimmern funktionieren.

Nachdem ohnehin schon jQuery eingesetzt wird, könnte sich dazu evtl ein Blick auf http://keith-wood.name/svg.html#plot lohnen.

Was würde man brauchen um das Thema anzugehen? M.E. braucht es einen Mechanismus, der einmalig Daten bereitstellt um den Plot zu füllen zumindest aber um ein Minimum an Code in die Seite einzufügen und einen, um neue Daten hinzuzufügen. Das erstmalige Befüllen könnte auch verzögert von javascript aus in kleineren Chunks erfolgen, um den Seitenaufbau zu beschleunigen. Mit den gleichen Mitteln könnte man beim Scrollen in den Daten scrollen die bislang nicht angezeigten Bereiche dynamisch nachladen.

Ist dein Demo eine geeignete Grundlage um darauf aufbauen zu können? Oder wie würde die Lösung auf FHEM Seite aussehen?

[Markus Bloch]

wenn ein device wie LightScene oder readingsGroup den status bzw. das icon eines oder mehrere anderer devices anzeigt würde das automatische setzen informid in FW_devState auch nicht
funktionieren weil die informid zu den tatsächlich in einem raum vorhandenen devices passen muss. sonst werden die events automatisch ausgefiltert und kommen erst garnicht  am browser an.

Selbst das ist nur ein Teil. Man kann offenbar auch keine informId's verwenden die nicht auf ein existierendes Reading passen. Ich möchte meinem HTML Output eigene informId's zu verpassen um diese über eine eigene setValueFn zu aktualisieren bzw. um die Tabelle zu verändern. Dennoch werden informIds in Form von devicename-wert nicht akzeptiert, wenn sie nicht zu real existierenden Readings passen. Das entsprechende Device existiert auch im Raum.

Kann man nachlesen unter: http://forum.fhem.de/index.php/topic,37869.0.html

Gruß
Markus

[rudolfkoenig]

@gandy:
Mein Demo als ausgangspunkt ist natuerlich nicht geeignet, der setzt einen fertig gerenderten SVG voraus, und laedt diese neu, falls es sich geaendert haben _koennte_. Ich spiele mit dem Gedanken der SVG-Neuimplementierung in JS seit 2 Jahren, und es sind dazu "schon" alle Voraussetzungen geschaffen: FileLog liefert die Daten direkt, wenn man im get kein column_spec spezifiziert. Falls man plotmode auf jsSVG stellt, dann liefert 98_SVG.pm ein <div> aus, mit dem .gplot, dem SVG und FHEMWEB Attributen. Ich finde es wichtig weitgehend kompatibel mit der bisherigen Loesung zu sein, aus diesem Grund werde ich auf Fremdbibliotheken verzichten. Sowas wie Neues Charting Frontend gibt es schon.

Man kann offenbar auch keine informId's verwenden die nicht auf ein existierendes Reading passen.

Das ist so nicht korrekt. informId muss dem ersten Parameter entsprechen, was an dem Browser geschickt wird, und das ist bei allen ausser atPageEnd Geraeten Name des Event-Ausloesenden Geraetes, und (zusaetzliche Nachrichten) der String, was aus Geraetaname-Reading besteht, wobei Reading ist das, was im Event vor dem : steht.
Man kann Events auch ohne Reading generieren, und man kann auch FW_directNotify verwenden, ohne den Umweg ueber Events.

[Markus Bloch]

Das ist so nicht korrekt. informId muss dem ersten Parameter entsprechen, was an dem Browser geschickt wird, und das ist bei allen ausser atPageEnd Geraeten Name des Event-Ausloesenden Geraetes, und (zusaetzliche Nachrichten) der String, was aus Geraetaname-Reading besteht, wobei Reading ist das, was im Event vor dem : steht.
Man kann Events auch ohne Reading generieren, und man kann auch FW_directNotify verwenden, ohne den Umweg ueber Events.

Danke Rudi für die Info. Könntest du auf "ausser atPageEnd Geraeten" etwas näher eingehen? Da FB_CALLLIST genau diesen Parameter besitzt. Ich verwende dabei auch FW_directNotify.

Gruß
Markus

[rudolfkoenig]

Siehe Zeilen 2383++ in 01_FHEMWEB.pm.
- Falls kein atPageEnd, an Browser ["name", "status", "Bild"] schicken
- Events, die kein : enthalten, ignorieren, die anderen in "reading" und "wert" aufteilen, und ["name-reading", "wert", "wert"] und ["name-reading-ts", "AktuelleUhrzeit", "AktuelleUhrzeit"] an dem Browser schicken.

Die Alternative ist die Funktion FW_directNotify, damit schickt man ohne den Umweg ueber Events an alle Frontends die im Parameter spezifizierten Werte, falls das erste Argument (GeraeteName) im angezeigten Raum ist. Das passende Widget-Handler-Javascript im Browser muss diese Werte interpretieren koennen, und es muss ein Widget mit informId=GeraeteName gerade angezeigt sein.

[Markus Bloch]

So wie du es beschrieben hast, habe ich es aktuell auch gelöst.

Kleiner Schönheitsfehler: Wenn in HTML-Output durch FW_detailFn/FW_summaryFn eine eigene informId gesetzt wird, so müssen alle Eltern-Tags im DOM-Baum auf eine vorhandene informId geprüft werden und bei Vorhandensein gelöscht werden. Aktuell benutze ich dazu in fhemweb_fbcalllist.js folgenden Code:

Code Auswählen Erweitern

// WORKAROUND - should be removed if a more suitable solution is found
// remove all similar informid's in all parent elements to ensure further updates
$(function () {
    $("div[arg=fbcalllist][informid]").each(function (index, obj) {
        name = $(obj).attr("dev");
        $(obj).parents("[informid="+name+"]").removeAttr("informid");
    });
});

Da ich nur so meinen setValueFn Handler setzen kann, muss ich die durch FHEMWEB eingefügte informId löschen.

Ist das so gedacht?

Gruß
Markus

[rudolfkoenig]

Gedacht ist uebertrieben. setValueFn koennte auch die falschen Eintraege ignorieren, wenn das weniger Aufwand ist.

[Talkabout]

Hallo Markus,

in welchem Fall wird denn bei den Parents die informId gesetzt? Ich hatte das Problem z.b. im Dashboard, dass dort im Code die informId gesetzt wurde, zusätzlich dann aber auch im Device selber. Das habe ich nun aber angepasst, so dass die informId nur ein mal erscheint. Wo bist Du dem Problem begegnet?

Gruss

[gandy]

@gandy:
Mein Demo als ausgangspunkt ist natuerlich nicht geeignet, der setzt einen fertig gerenderten SVG voraus, und laedt diese neu, falls es sich geaendert haben _koennte_. Ich spiele mit dem Gedanken der SVG-Neuimplementierung in JS seit 2 Jahren, und es sind dazu "schon" alle Voraussetzungen geschaffen: FileLog liefert die Daten direkt, wenn man im get kein column_spec spezifiziert. Falls man plotmode auf jsSVG stellt, dann liefert 98_SVG.pm ein <div> aus, mit dem .gplot, dem SVG und FHEMWEB Attributen. Ich finde es wichtig weitgehend kompatibel mit der bisherigen Loesung zu sein, aus diesem Grund werde ich auf Fremdbibliotheken verzichten. Sowas wie Neues Charting Frontend gibt es schon.

Kompatibilität finde ich an der Stelle essentiell. Alternative Frontend Ansätze sind ja grundsätzlich nicht verkehrt, aber worum es hier geht ist ja, Plots im bestehenden Umfeld so zu implementieren, dass das User-Experience nicht so sehr leidet, wie es aktuell dein so-gehts-gar-nicht-demo recht eindrucksvoll demonstriert. Insofern also völlig deiner Meinung. Was aber spräche dagegen, fertige Routinen zur Manipulation des svg einzusetzen?

[Markus Bloch]

Hallo Markus,

in welchem Fall wird denn bei den Parents die informId gesetzt? Ich hatte das Problem z.b. im Dashboard, dass dort im Code die informId gesetzt wurde, zusätzlich dann aber auch im Device selber. Das habe ich nun aber angepasst, so dass die informId nur ein mal erscheint. Wo bist Du dem Problem begegnet?

Gruss

Als ich mit atPageEnd gespielt habe um herauszufinden wofür es genau da ist, wie ich aber gerade im HTML Quelltext bemerkt ist, gibt es keine informId in den Parent-Elementen bei aktiviertem atPageEnd (was aktuell gesetzt ist). Dann kann ich es wieder herausnehmen.

Danke
Gruß
Markus