FW_devState() verwendung

[justme1968]

ich versuche gerade eine "Kopie" eines device icons an einer anderen stelle (detailFn und summaryFn bzw. weblink) einzublenden.

in der detailFn funktioniert das probemlos wenn ich FW_devState() verwende. das icon ist 'live' und ich kann es klicken und es wird per longpoll aktualsieiert. egal ob ich das original oder die kopie klicke sind beide immer synchron.

in der detailFn bzw. dem weblink funktioniert das aber nicht. das icon reagiert nur auf den ersten klick und wird auch nicht per longpoll aktualisiert.

Code Auswählen Erweitern

define beispiel dummy
attr beispiel devStateIcon on:black_Steckdose.on:off off:black_Steckdose.off:on
attr beispiel room beispiel
attr beispiel setList on off

define wlBeispiel weblink htmlCode {FW_devState("beispiel","&room=beispiel")}
attr wlBeispiel room beispiel
wenn man mit dem obigen beispiel ein browser fenster im raum beispiel und ein fenster in der detail ansicht zu wlBeispiel auf macht kann main das dummy device mit den webCmds oder dem icon schalten und das icon in der detail ansicht wird per longpoll aktualisiert. der gleiche weblink in der raum ansicht aber nicht.

wenn man in der detail ansicht auf das icon klickt wird für den übergang off->on das device korrekt aktualsiert. für den übergang on->off wird zwei mal geschalten ein mal off und dann gleich wieder on. das tritt aber nur in dem beispiel auf. in der langen version in LightScene funktioniert das einwandfrei.

ein klick auf den weblink sendet natürlich immer das gleiche event weil die aktualisierung per longpoll nicht geht.

gruss
  andre

[rudolfkoenig]

Ich habe schon Angst, wenn ich von Andre was sehe, es ist meist kompliziert, er hat haeufig Recht, und ich Arbeit :)

Hier sind mehrere Probleme bzw. Artefakte:
1. Der Status wird aktualisiert, indem fhemweb.js nach einem (== ersten) passenden id im html sucht, dessen Inhalt er ersetzt.
-> es wird nur ein ein Bild aktualisiert, weiterhin hat Weblink (da es nicht in der Tabelle sondern am Ende der seite dargestellt wird) gar kein id.
2. devState generiert zwar auch ein id="name", der ist aber irrelevant, da das nicht mehr das Erste ist.
3. Mehrere Browserfenster haben mit longpoll ein Problem, da (wenigstens bei Firefox) nur einer von denen benachrichtigt wird.

Ich muss die Probleme mal anschauen, allerdings wird das noch etwas dauern...

[justme1968]

danke... ich werde an dem häufig arbeiten :)

[rudolfkoenig]

Ich meine diese Probleme gefixed zu haben:
- der inform Aufruf in fhemweb.js bei longpoll enthaelt jetzt ein timestamp, damit funktioniert longpoll parallel in mehreren Browser-Fenstern
- id in der Tabelle geaendert zu informId, und fhemweb.js macht eine Schleife ueber alle solche Eintraege. Achtung: da es querySelectorAll verwendet, funktioniert longpoll in alten Browser nicht mehr. Dein Beispiel von unten muss so umgebaut werden:

Code Auswählen Erweitern

define wlBeispiel weblink htmlCode {"<div informId='beispiel'>".FW_devState("beispiel","&room=beispiel")."</div>"}


id=room wurde zu class=room umgebaut, da es mehr als einmal auf der Seite vorkommt -> reload der .css im Browser ist notwendig.

[justme1968]

das klingt sehr gut.

anbei ein patch der das in 98_weblink.pm für den readings typ nachzieht (und alle devices mit ignore aus dem regex match raus lässt).

oder soll ich das schnell selber einchecken ?

gruss
  andre

[rudolfkoenig]

eingecheckt

[UliM]

Dein Beispiel von unten muss so umgebaut werden:

Hi,
weisst Du ob floorplan nachgezogen werden muss?
Gruß, Uli

[rudolfkoenig]

Danke das Du fragst: ja.

Ich vermute alle td's mit colspan= muessen ein informId=\"$d\" bekommen. Bisher hat es auch nicht "richtig" funktioniert, weil fhemweb.js beim ersten update in den alten div einen weiteren eingebaut hat, was aber nie aufgefallen ist.

Apropos fhemweb.js:
das Laden der fhemweb.js ist ab sofort mit einer Schleife ueber FW_fhemwebjs zu ersetzen, siehe 01_FHEMWEB.pm.
Ist justme1968 "geschuldet", der seinen colorpicker auch updaten will, und deswegen musste ich fhemweb.js modularisieren.

[justme1968]

ich hab leider doch noch ein problem gefunden. wenn der weblink aus dem beispiel nicht im gleichen raum ist wie der dummy geht der refresh per longpoll noch nicht.

also das beispiel von oben mit einem zweiten raum:

Code Auswählen Erweitern

define beispiel dummy
attr beispiel devStateIcon on:black_Steckdose.on:off off:black_Steckdose.off:on
attr beispiel room beispiel
attr beispiel setList on off

define wlBeispiel weblink htmlCode {"<div informId='beispiel'>".FW_devState("beispiel","&room=beispiel")."</div>"}
attr wlBeispiel room beispiel,beispiel2
und dann beide raume jeweils in einem browser fenster auf machen. der raum beispiel in dem dummy und weblink zusammen sind geht, die detail ansicht des weblink geht jetzt auch (das war vorher nicht so) aber der zweite raum geht nicht.

das betrifft nicht nur das konstruierte beispiel sondern z.b. auch ein weblink mit readings oder die html übersicht des lightscene moduls.. da werden die readings oder icons auch nur aktualisiert wenn der weblink in gleichen raum ist wie die devices.

[rudolfkoenig]

> wenn der weblink aus dem beispiel nicht im gleichen raum ist wie der dummy geht der refresh per longpoll noch nicht.

Das ist klar, da longpoll z.Zt den refresh auf die Geraete begrenzt, die im Raum sind, um traffic zu sparen.
Und ich finde das auch eine gute Idee :)

Ich vermute Du musst statt weblink ein Geraet (structure?) bauen, der selbst ein event generiert.

[justme1968]

das ist ein klein bischen doof weil es bei dem weblink ja gerade darum geht eine sicht auf ein oder mehrere devices oder teile der selben an anderer stelle noch mal zu haben.

kann man longpoll irgendwiel 'vorgaukeln' das das eigentliche gerät da ist? in diesem fall soll ja tatsächlich aktualisert werden weil eine kopie da ist und nicht zeit gespart werden weil das device eh nicht im raum ist.

[rudolfkoenig]

> bei dem weblink ja gerade darum geht eine sicht auf ein oder mehrere devices oder teile der selben an anderer stelle noch mal zu haben.

Das ist aber nicht meine Auffassung.

Weblink war (wie der Name sagt) als Moeglichkeit gedacht in FHEMWEB Links (<a>,<img>,<iframe>) zu platzieren, und ich will es nicht zur Loesung fuer alle FHEMWEB-Darstellungsprobleme ausbauen.

Da die Plots frueher von gnuplot generierte Bilder waren, kamen diese ueber weblink ins FHEMWEB. Beim Umbau zu SVG habe ich nicht wirklich nachgedacht, deswegen blieb es bei weblink. Mein Plan ist SVG zu einem richtigen Modul umzubauen und aus weblink zu entfernen, das ist dank summaryFn/detailFn inzwischen auch einfach.
gnuplot/gnuplot-svg ist damit Vergangenheit.

Eine neues Modul (readingsGroup?) waere mAn fuer dein Problem die bessere Loesung. Ich als Anfaenger wuerde nicht in weblink die Loesung so eines Problems vermuten, und readingsGroup koennte auch bei anderen Frontends wenigstens als Objekt verwendet werden.

[justme1968]

es geht gar nicht darum ein darstellungsproblem zu reparieren oder weblink als workaround dafür zu verwenden.

ich verwende weblink nur dazu um auf einfache weise htmlcode anzuzeigen ohne ein komplettes modul zu schreiben. ich finde schon das das genau der anwendungsfall für weblink ist.

ganz unabhängig davon ob es sauberer ist für die readings liste einen weblink oder ein eigenes modul zu verwenden löst das eigene modul nicht das problem das longpoll die readings nicht aktualisiert. auch bei dem modul wäre das original device nicht auf der seite und longpoll würde die zeilen in der readingsgroup ignorieren. dazu müsste man sich an die notifys hängen und dann selber die zeilen aktualisieren. damit mache ich aber dann alles mögliche doppelt das fhem intern doch schon längst macht. auch würde meine notify routine immer aufgerufen. ganz unabhängig davon ob das modul gerade auf einer seite dargestellt wird oder nicht.

das argument mit den anderen frontends verstehe ich in diesem zusammenhang nicht ganz. es betrifft ja module die dinge visuell darstellen. nicht als text. so lange ein anderes frontend html einbinden kann funktioniert das ganz unabhängig davon ob es ein weblink ist oder ein eigenes modul.

es betrifft ja nicht nur die readings anzeige. lightscene hat das gleiche problem und das ist ein modul. die remotecontrol wird das problem auch bekommen wenn es erweitert wird damit die tasten den aktuellen status anzeigen. die av module werden das problem bekommen wenn sie coverart darstellen wollen ohne das das device selber im raum ist. sogar die wetter icons haben das problem. hier fällt es nur nicht nicht auf weil sie sich so selten ändern. aber ein touch pannel an der wand das den ganzen tag dieaktuellen wettericons in einer ecke anzeigt geht z.b. zur zeit nicht weil es kein update gibt.

die einschränkung besteht immer wenn das device und die zugehörige anzeige nicht im gleichen raum oder dem gleichen floorplan ist. unabhängig davon ob man es als fhem modul löst oder per weblink.

was spricht denn dagegen das man sagen kann 'diese anzeige gehört zu device xy. bitte bei longpoll berücksichtgen' ?

[rudolfkoenig]

> ich verwende weblink nur dazu um auf einfache weise htmlcode anzuzeigen ohne ein komplettes modul zu schreiben.

Das geht ja auch. Das Problem ist, dass das Frontend dieses HTML-Code nicht automatisch refresht, wenn die Bestandteile sich aendern. Und hier faengt unsere Diskussion an: Du meinst, FHEMWEB soll es rauszufinden, ob dieses Geraet sich geaendert hat, und ich meine das zu melden ist Aufgabe eines Moduls. Du argumentierst damit, dass es dadurch Code gespart wird, und ich, dass es keine saubere Trennung der Aufgaben ist.


> dazu müsste man sich an die notifys hängen und dann selber die zeilen aktualisieren.

Nicht direkt: in notify muss dazu ein Event ausgeloest werden.


> auch würde meine notify routine immer aufgerufen.

Effizient ist die Alternative vermutlich auch nicht (ich stelle ein Attribut vor, der die Liste der Teilgeraete beinhaltet), da das NotifyFn in FHEMWEB bei jedem Event alle anderen Geraete pruefen muss, ob diese auf der Seite sind und wenn ja, ob die vom Event betroffen sind. Es gibt evtl. schnellere Alternativen, die andere Nachteile (Pflege) haben.

Deine Beispiele mit lightscene & co sind problematisch: erstens muesste man ueberall die besagten Attribute automatisch setzen (unschoen), weiterhin muessten alle Frontends (oder wer auch immer die Module braucht) die oben beschriebene Logik der Suche implementieren.

Beim weather zaehlt dein Argument nicht, da man hier nicht auf weitere Geraete zeigen kann, dessen Event ein refresh des Bildes ausloesen soll. Ein at mit "trigger wlName" loest dagegen auch jetzt ein refresh aus.


>  was spricht denn dagegen das man sagen kann 'diese anzeige gehört zu device xy. bitte bei longpoll berücksichtgen' ?

Dass es eine Spezialloesung fuer weblinks ist, und foerdert damit Hacks mit weblinks, die einfach fuer den Entwickler aber undurchsichtig fuer den Anwender sind. Alle anderen Module koennen problemlos notifyFn implementieren. Was effizienter ist, ist fraglich.

[justme1968]

es geht mir auch nicht um einen weblink spezialfall und ich möchte nicht aufgaben auf fhemweb abwälzen die aufgaben des modulautors sind.  ich möchte nur das was fhemweb jetzt schon kann (per longpoll html teile aktualisieren) ein klein wenig verallgemeinern.

es ist ja fast alles dafür da. das einzige das dem meiner meinung nach im weg steht ist das die optimierung (die sehr sinnvoll ist) darauf beruht das die dinge die aktualisiert werden sollen im gleichen raum sein müssen wie das device zu dem sie gehören.


am beispiel der readings: das es eventuell sinnvoll ist diese readings gruppe doch in ein eigenes modul zu verwandenl bestreite ich ja garnicht. aber aber nicht um die anzeige hin zu bekommen sondern aus ein paar anderen gründen.

selbst dann würde ich gerne das delegieren der anzeige von "dingen" aus einem device an ein anderes device delegieren können. der weg mit einem eigenen modul den du vorschlägst funktioniert zur zeit nämlich auch erst wenn ich in diesem modul jedes reading das ich anzeigen möchte zu einem eigenen mache. d.h. aus dem original kopiere. das erzeugt nicht nur den overhead das ich alle events aller devices verarbeiten muss sondern ich muss dann nach dem duplizieren auch noch eigene events erzeugen. d.h. ich habe nicht nur die readings dupliziert sondern auch noch die events.

das alles kann ich vermeiden wenn ich der optmierung auf irgend eine art sagen kann: 'bitte die werte für device xy nicht ignorieren ich bin stellvertretend dafür da'.


wenn man die liste der für inform relevanten devices beim aufbau der html seite erstellt und nicht später per FW_roomStatesForInform kann man an dieser stelle jedes device fragen für welche devices es 'delegations aufgaben' erfült und dann diese in die liste eintragen. wenn es keine gibt wie bisher das device selber.

das kann man auch für andere frontends die inform verwenden völlig transparent machen in dem die devices die auf regex matchen ein mal nach den 'orignalen' gefragt werden und diese mit in die liste tut.

am beispiel readingsgroup: wenn ich mir eine readings group für die temperaturen aller devices erstelle würde diese auf die anfrage genau alle temperatur sensoren zurück liefern die dann bei inform zusätzich in die liste eingefügt werden würden.

das wäre rückwärtskompatibel und es ist nichts automatisch zu setzen. kein frontend müsste eine suche implementieren. inform würde das transparent machen.

arg... viel zu lang und konfus. ich glaube mal wieder das es eigentlich ganz einfach ist. vielleicht sollte ich die zeit lieber verwenden um einen patch zu bauen der es zeigt statt es erklären zu wollen :)