FHEM Forum

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.

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

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

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

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

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

eingecheckt

Zitat von: rudolfkoenig schrieb am Mo, 15 Juli 2013 11:12Dein Beispiel von unten muss so umgebaut werden:

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

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.

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

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

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.

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

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

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

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

> in diesem modul jedes reading das ich anzeigen möchte zu einem eigenen mache. d.h. aus dem original kopiere.

Das ist doch gar nicht notwendig, Hauptsache dass ein Event fuer dieses Geraet die Aenderung anzeigt.


> vielleicht sollte ich die zeit lieber verwenden um einen patch zu bauen der es zeigt statt es erklären zu wollen :)

Haette den Vorteil, dass man nicht aneinander vorbeiredet :)

> Das ist doch gar nicht notwendig, Hauptsache dass ein Event fuer dieses Geraet die Aenderung anzeigt.

wie soll denn das gehen? wenn ich das reading nicht kopiere muss ich es mit der informId des anderen devices versehen. die passt dann aber nicht zu meinem event. wenn ich eine eigene informId verwende muss das reading doch auch bei mir sein. sonst passt der longpoll update nicht zum reading.

konkretes beispiel: eine reading group mit temperaturen. ich würde gerne als informId <original device>-<temperature>verwenden. dann muss nur genau ein mal die seite aufgebaut werden und im prinzip würde alles gehen wenn ich die <original device>s irgendwie in die inform liste bekomme ohne das sie im gleichen raum sein müssen weil das original device genau die events erzeugt die zu dieser informId passen.

wenn ich selber events erzeuge muss ich eine informId der form <eigenes device>-<...> verwenden sonst passt mein event ja nicht. und dann muss ich auch noch mein reading namen auf das orignal mappen weil ich ja nicht beide male temperature verwenden kann.

stehe ich gerade auf dem schlauch ?


> Haette den Vorteil, dass man nicht aneinander vorbeiredet :)

und den nachteil vielleicht etwas umsonst zu machen wenn du es nicht einsiehst :)

aber als ersten schnellschuss: in FW_roomStatesForInform nach dem devspec2array alle devices aus der rl nach ->{Delegates} fragen und wenn etwas zurück kommt diese mit ins array pushen.

das würde nur für echte devices etwas ändern und den weblink fall nicht abdecken. aber der gefällt dir ja sowieso nicht :)

> wenn ich eine eigene informId verwende muss das reading doch auch bei mir sein.

Gar nicht: wenn ein event fuer ein Teil reinkommt, generierst du ein Event fuer die eigene Instanz, und FHEMWEB laesst die komplette Gruppe nochmal malen.

Ich glaube ich verstehe, was Dir vorschwebt: nur Teile der Gruppe aktualisieren. Dazu im readingsGroup->notifyFn pruefen ob Device/Event fuer readingsGroupName relevant ist, falls ja es nochmal mit DoTrigger("readingsGroupName", "deviceName-eventName: eventValue") posten. Die deviceName Zeile muesste jeweils in <td informName="readingsGroupName-deviceName-eventName"> eingeschlossen werden.

Falls du so ein readingsGroup Modul baust, dann steuere ich im JavaScript ein Fading rot->schwarz bei. :)

> aber als ersten schnellschuss:...

Entspricht meinem Vorschlag weiter oben, bloss dass ich Attribute statt ->{Delegates} verwenden wuerde, damit es auch fuer weblinks funktioniert. Ist mir aber zu teuer, was CPU angeht :)

> Ich glaube ich verstehe, was Dir vorschwebt:

ja. genau. immer nur den teil aktualisieren der auch wirklich geändert werden muss.

die readings group baue ich.


> Ist mir aber zu teuer, was CPU angeht :)

genau das glaube ich eben nicht. es kostet ja nur cpu wenn das element auch wirklich gerade angezeigt wird.

alles was über events und trigger geht kostet immer cpu egal ob das ding gerade angezeigt wird oder nicht.
ich muss ja dann z.b. in jedem fall jedes reinkommende event imm er auf alle devices prüfen und triggern.


ich baue mal die readings group mit dem trigger mechanismus. ich hoffe das sich dann wenigstens der code der das mapping vornimmt wieder verwenden lässt. ich habe ja auch noch die lightscene und die remotecontroll im hinterkopf. wenn ich es schaffe diesen teil in mehr als einem modul zu verwenden würdest du ihn dann irgendwo zentral einbauen?


ich denke die tatsächliche last ist in beiden fällen unterm strich etwa gleich sobald etwas getan wird. im einen fall ist halt immer ein bischen zu tun im anderen fall nur beim anzeigen und dafür mehr. im zweifel wäre ich auf einem langsamen system aber eher dafür das im normal betrieb bei dem nichts angezeigt wird die dauer last so gering wie möglich ist ist. man könnte beide varianten ja auch mal wirklich vergleichen...


noch etwas ganz anderes: bei den av modulen die cover art darstellen gibt es das problem das an diversen stellen die bilder gecached werden. eine stelle ist fhemweb selber. gibt es eine möglichkeit fhemweb zu sagen das sich ein bestimmtes bild geändert hat und es neu gelesen werden sollte?

> gibt es eine möglichkeit fhemweb zu sagen das sich ein bestimmtes bild geändert hat und es neu gelesen werden sollte?

Haengt davon ab, was du damit meinst.
- Dateien (z.Bsp. Bilder) kann man von FHEM direkt holen, es wird nichts gecached.
- FHEMWEB merkt alle Bildernamen von iconPath (kein Inhalt) fuer die Status-Bild-Berechnung. Das kann man mit "set WEB rereadicons" neu triggern, dabei werden ein paar Verzeichnisse aufgelistet.
- Browser fragen haeufig per "If-None-Match" Headerzeile den etag ab, was FHEMWEB mit dem mtime vergleicht, und falls gleich ist, liefert dann "304 Not Modified" zurueck. Hier muss man das mtime der Datei aendern, falls sich was geaendert hat.

ich habe jetzt eine idee wie es funktionieren kann. es funken noch ein paar ganz andere effekte zwischen rein.

- es reicht nicht das gleiche file auf platte immer wieder zu überschreiben. der browser macht kein refresh wenn sich der file name nicht ändert.

  -> zwei files im wechsel verwenden funktioniert.

- der state muss sich tatsächlich ändern wenn mehrfach hintereinander nur das event play kommt wird entweder kein oder ein falsches icon angezeigt.

  -> entweder die album id als state verwenden. das funktioniert. hat aber den nachteil das der state dann nicht mehr den zustand play oder pause anzeigt.

  -> dem icon in der summaryFn die inform id des album id readings geben. dann wird der refresh immer aufgerufen unabhängig von state. der nachteil dabei ist das dann im browser alles kurz flackert weil fhemweb dem übergeordneten div ebenfalls eine informid verpasst und denn zwei mal refreshed wird.

irgendwo gibt es noch ein problem mit longpoll sobald ein '.' (punkt) im reading namen vorkommt.

ein beispiel: per telnet:
define test dummy
attr test room test
{readingsSingleUpdate($defs{test},"A", 11, 1)}
{readingsSingleUpdate($defs{test},"B", 12, 1)}
{readingsSingleUpdate($defs{test},"A.A", 13, 1)}
dann im browser in die detail ansicht von test gehen und per telnet:
{readingsSingleUpdate($defs{test},"A", 21, 1)}
{readingsSingleUpdate($defs{test},"B", 22, 1)}
{readingsSingleUpdate($defs{test},"A.A", 23, 1)}
es werden die readings A und B per longpoll aktualisiert A.A nicht mehr. wen mann danach noch mal werte ändert wird gar kein reading mehr aktualisiert.

im safari webinformationen fenster sieht man das es einen fehler 'semantikproblem: an invalid or illegal string was specified' in der zeile mit dem querySelectorAll gab.

die readings mit dem punkt im namen sind mindestens für 1-wire und swap relevant.

Zitat von: rudolfkoenig schrieb am Mo, 15 Juli 2013 22:04Ich vermute alle td's mit colspan= muessen ein informId=\"$d\" bekommen.
[...]
das Laden der fhemweb.js ist ab sofort mit einer Schleife ueber FW_fhemwebjs zu ersetzen

floorplan done.

hattest du den post weiter oben mit dem '.' problem gesehen ?

gruss
  andre

Jaja, ruhig Blut :) Habs auch gefixed:
  document.querySelectorAll("[informId=XXX]");
funktioniert nur wenn XXX kein Punkt usw. enthaelt, folgendes ist besser:
  document.querySelectorAll("[informId='XXX']");

Wenn wir schon dabei sind: die erste Zeile in FW_colorpickerUpdateLine ist mAn kaputt (name gibts nicht).

das sollte kein drängeln sein :)

du hast recht was das mit dem namen angeht. ich habe keine ahnung wie diese version ins svn gerutsch ist.

ich hab nur gerade noch ein viel grösseres problem bemerkt. das konzept mit dem updateLine funktioniert nur wenn es auch ein reading mit dem gleichen namen wie das webCmd gibt. und das ist weder bei den hue lampen noch beim swap rgb driver board der fall.

beim rgb board habe ich die passenden werte in einem register stehen. und damit funktioniert es.

bei den hue lampen gibt es kein reading das direkt irgend etwas mit den rgb werten zu tun hat. da muss ich erst noch etwas umbauen.


edit: beim debuggen ist mir eben aufgefallen das alles noch ziemlich flackert wenn man auf einen normalen text webCmd link klickt. spricht etwas dagegen das auch auf XHR umzustellen wie die devState icons? ich hab das eben für die colorpicker presets gemacht und das geht wunderbar. dann würde auch die 5 sekunden reconnect meldung verschwinden.

edit2: im prinzip habe ich jetzt eine version für das swap rgb board alles korrekt per updateLine aktualisiert so lange ich die farbe per telnet setze. wenn ich im web die farben mit einem XHR link setze funktioniert auch alles. beim setzen mit einem normalen webCmd link leider noch nicht. da schlägt das 5 sekunden reconect zu und es gehen genau die readings verloren die das update triggern sollten.

edit3: ich hatte eben die idee das über ein unsichtbares reading .rgb zu machen. das könnte dann bei allen devices mit lichtfarbe gleich sein. leider erzeugen unsichtbare readings keine events...

edit4: aber man kann es mit CommandTrigger() faken. und das funktioniert wunderbar um das nicht vorhandene reading zu ersetzen :) jetzt bleiben nur noch die verlorenen events.

das oben beschriebene verloren gehen von events beim click auf die webCmd liste habe ich inzwischen auch bei homematic bemerkt:

beim schalten ändert sich der state dort zweistufig. beim einschalten wird der state z.b. auf 'set-on' gesetzt und erst wenn die bestätigung vom aktor kommt endgültig auf 'on'.

wenn das einschalten über die webCmd liste passiert kommt das erst update per longpoll auf set-on noch an, dann kommt die 5 sec reconnect message und der endgültige update auf on geht verloren und das icon  bleibt im falschen zustand.

wenn man durch klick auf das devStateIcon schaltet geht es per XHR und die reconnect message bleibt aus. das icon wechselt nacheinander sauber auf set-on und dann auf on.

spricht etwas dagegen auch die webCmd liste (zumindest konfigurierbar für neue browser) per XHR zu machen? und den maus cursor dann per cursor:pointer im stylesheet zu setzen?

> dann kommt die 5 sec reconnect message

Das ist komisch, ich wuesste gerne wieso. In der aktuellen FHEMWEB Version sollte beim Schalten keine Meldung sichtbar sein.

> und der endgültige update auf on geht verloren und das icon bleibt im falschen zustand.

Ist auch komisch. Mit longpoll wird nach dem aktivieren des longpolls genau aus diesem Grund FW_roomStatesForInform ausgefuehrt, um verlorengegangene Events abzuholen.

Diese Probleme sollten erst untersucht werden, bevor wir das mit XHR flicken.


Martin@HM hat mir in FHEMWEB einige Probeme mit seinem set_on->on Logik eingebracht, ich habe HM vor ihm mit set (wie FS20) und MISSING-ACK gebaut, ich wusste schon wieso.

mit den versionen bis  gestern habe ich die 5sec meldung zuverlässig und reproduzierbar.

wenn ich debug ausgaben in mein update line ein einbaue sehr ich nur im xhr fall alle aufrufe in der debug konsole. im 5sec fall nicht. im safari ist auch reproduzierbar das flackern der seite beim neuaufbau zu sehen wenn kein xhr verwendet wird.

kann ich irgendetwas tun um beim untersuchen zu helfen?

für das swap protokoll ist das zweistufige set-xxx und dann xxx das logische vorgehen weil es kein ack/nack gibt sondern eine antwort mit dem aktuellen zustand.

>  kann ich irgendetwas tun um beim untersuchen zu helfen?

Ja.
- tritt die Meldung auch mit FS20 auf? Ich hab kein HM Schalter jetzt hier, und sehe kein Problem mit FS20.
- was liefert FW_roomStatesForInform an fhemweb.js
- welche Events kommen in "inform timer"?

die meldeung ist eben bei fs20 nicht aufgetreten. der refresh der seite aber schon.

im mommen erscheint die 5sec meldung aber auch bei homematic nicht. das verhalten mit den nicht passenden icons tritt aber trozdem auf.

angehängt die inform timer meldungen jeweils ein mal per click auf webCmd ausgelöst und ein mal per klick auf das icon. ich glaube die unterscheiden sich nicht.