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

[rudolfkoenig]

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

[justme1968]

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

[rudolfkoenig]

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

[justme1968]

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

[rudolfkoenig]

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

[justme1968]

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.

[justme1968]

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

ein beispiel: per telnet:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[UliM]

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

[justme1968]

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

gruss
  andre

[rudolfkoenig]

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

[justme1968]

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.

[justme1968]

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?

[rudolfkoenig]

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

[justme1968]

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.

[rudolfkoenig]

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

[justme1968]

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.

FS20

2013-07-25 13:04:44 FS20 Garten on
2013-07-25 13:04:48 FS20 Garten off

2013-07-25 13:04:49 FS20 Garten on
2013-07-25 13:04:51 FS20 Garten off[/code]

HOMEMATIC

2013-07-25 13:05:09 CUL_HM CUL_HM_switch_1D9AEE CMDs_pending
2013-07-25 13:05:09 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 set_on-10
2013-07-25 13:05:09 CUL_HM CUL_HM_switch_1D9AEE CMDs_processing...
2013-07-25 13:05:10 CUL_HM CUL_HM_switch_1D9AEE CMDs_done_events:3
2013-07-25 13:05:10 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 CommandAccepted: yes
2013-07-25 13:05:10 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 level: 100 %
2013-07-25 13:05:10 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 deviceMsg: on (to cul2)
2013-07-25 13:05:10 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 on
2013-07-25 13:05:11 CUL_HM CUL_HM_switch_1D9AEE CMDs_pending
2013-07-25 13:05:11 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 set_off
2013-07-25 13:05:11 CUL_HM CUL_HM_switch_1D9AEE CMDs_processing...
2013-07-25 13:05:12 CUL_HM CUL_HM_switch_1D9AEE CMDs_done_events:3
2013-07-25 13:05:12 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 CommandAccepted: yes
2013-07-25 13:05:12 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 level: 0 %
2013-07-25 13:05:12 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 deviceMsg: off (to cul2)
2013-07-25 13:05:12 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 off
2013-07-25 13:05:13 CUL_HM CUL_HM_switch_1D9AEE CMDs_pending
2013-07-25 13:05:13 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 set_on
2013-07-25 13:05:13 CUL_HM CUL_HM_switch_1D9AEE CMDs_processing...
2013-07-25 13:05:13 CUL_HM CUL_HM_switch_1D9AEE CMDs_done_events:3
2013-07-25 13:05:13 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 CommandAccepted: yes
2013-07-25 13:05:13 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 level: 100 %
2013-07-25 13:05:13 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 deviceMsg: on (to cul2)
2013-07-25 13:05:13 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 on

2013-07-25 13:05:15 CUL_HM CUL_HM_switch_1D9AEE CMDs_pending
2013-07-25 13:05:15 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 set_off
2013-07-25 13:05:15 CUL_HM CUL_HM_switch_1D9AEE CMDs_processing...
2013-07-25 13:05:15 CUL_HM CUL_HM_switch_1D9AEE CMDs_done_events:3
2013-07-25 13:05:15 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 CommandAccepted: yes
2013-07-25 13:05:15 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 level: 0 %
2013-07-25 13:05:15 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 deviceMsg: off (to cul2)
2013-07-25 13:05:15 CUL_HM CUL_HM_switch_1D9AEE_Sw_03 off[/code]

in dem raum in dem die beiden geräte von oben sind ist FW_roomStatesForInform leer.

in einem anderen Raum in dem ich zwei swap devices mit dem gleichen verhalten habe ist FW_roomStatesForInform:

Code Auswählen Erweitern

2013.07.25 13:14:15 3: FW_roomStatesForInform: $VAR1 = 'SWAP_AA<<off<<<a onClick="FW_cmd(\'/fhem?XHR=1&cmd.SWAP_AA=set SWAP_AA on&room=SWAP\')"><div id="SWAP_AA"  class="col2"><svg class=" off" version="1.0" xmlns="[url=www.w3.org/2000/svg]http://www.w3.org/2000/svg[/url]"  width="468pt" height="617pt" viewBox="0 0 468 617"  preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)"  stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg></div></a>
SWAP_CC<<off<<<a onClick="FW_cmd(\'/fhem?XHR=1&cmd.SWAP_CC=set SWAP_CC on&room=SWAP\')"><div id="SWAP_CC"  class="col2"><svg class=" off" version="1.0" xmlns="[url=www.w3.org/2000/svg]http://www.w3.org/2000/svg[/url]"  width="468pt" height="617pt" viewBox="0 0 468 617"  preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)"  stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg></div></a>
temppress<<28.2°C 1015.5mbar<<<div id="temppress"  class="col2">28.2°C 1015.5mbar</div>
';

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

[justme1968]

gerade noch mal mit firefox getestet. gleicher effekt. hm devices bekommen das zweite update nicht mit. auch ohne die 5sec meldung.

zusätzlich sehe ich gerade das mein firefox auf dem mac statt dem svg icons überall jeweils den text "Created by potrace 1.8, written by Peter Selinger 2001-2007" anzeigt.

[rudolfkoenig]

Ich finde Martin@HM uebertreibt mit Events, mit einem HM Schalter hat FHEM mind. 8x mehr zu tun, als mit einem FS20. Wir sollten ihm zeigen, dass man readings auch ohne event setzen kann (4. Parameter bei readingsBulkUpdate auf 0 setzen), ich schreibe es per PM.

Da ich z.Zt. kein HM Schalter in Griff habe, habe ich versucht das Verhalten mit dummy&sleep zu reproduzieren, geht aber nicht so einfach, bzw. es funktioniert. Es hilft mir auch nicht wirklich, wenn Du die FW_roomStatesForInform Ausgabe zu einem swap Geraet, die events aber zu einem Homematic Schalter zeigst. Nach etwas Code-Untersuchung weiss ich jetzt, dass ich zusaetzlich die Daten auch vom FW_FlushInform benoetige.

Ich vermute folgendes:
fhemweb.js/longpoll benoetigt on bzw. off als STATE des Schalters, direkt im notifyFn von FHEMWEB.
CUL_HM triggert zwar on/off, aber das massgaebliche STATE wird vermutlich nach diesem notify (oder garnicht?) auf on gesetzt. Detailliert mit Geraet kann ich das Problem erst in ein paar Tagen pruefen.

Dein swap Log kann evtl. auf ein Problem mit NL hinweisen, falls du die debug Ausgabe direkt vor dem return eingebaut hast.

[justme1968]

das debug war direkt vor dem return. vom swap raum deshalb weil es im anderen raum leer war.

ich mach noch mal logs und debug ausgaben inklusive FW_FlushInform und swap raum.

ein unterschied zwischen hm oder swap und fs20 ist das der status als reaktion auf die antwort vom device gesetzt wird und nicht schon beim senden an das device. das laesst sich über du dummys vermutlich genau nicht abbilden.

[rudolfkoenig]

Pruef bitte auch, ob beim FW_notifyFn Aufruf swap STATE schon richtig gesetzt ist.

[rudolfkoenig]

Mit einem "einfachen" HM-LC-SW1-PL kann ich das Problem nicht nachvollziehen.

Ich kriege beim Schalten "nur" folgende Events:

Code Auswählen Erweitern

2013-07-30 09:08:22.596 CUL_HM hm1 set_on
2013-07-30 09:08:22.750 CUL_HM hm1 level: 100 %
2013-07-30 09:08:22.750 CUL_HM hm1 deviceMsg: on (to CUL)
2013-07-30 09:08:22.750 CUL_HM hm1 on

Das Bild wechselt zuerst zur Lampe mit Ausrufungszeichen und dann zum Endergebnis.
Getestet mit FF, Chrome und telnet (als trigger).
Evtl. hat Martin@HM hier was wesentliches geaendert.

[justme1968]

ich habe eben noch ein wenig gespielt: ein HM-LC-SW1-PL liefert tatsächlich sehr viel weniger events als ein HM-LC-SW4-DR oder ein HM-LC-Bl1PBU-FM.

es liegt aber nicht an der anzahl der events eines devices sondern hängt vom raum ab in dem das device ist. wenn ich den HM-LC-SW1-PL im raum Büro lasse geht es. wenn ich ihn in den gleichen raum schiebe wie den HM-LC-SW4-DR aus dem log oben geht er nicht mehr. umgekehrt geht der HM-LC-SW4-DR wenn ich ihn in einen raum test schiebe dort plötzlich auch.

ich mache noch mal logs inklusive  FW_roomStatesForInform, ...

unabhängig davon zappelt die ganze web seite bei jedem schaltvorgang oder baut sich zum teil verzögert auf. das ist bei der xhr version besser.

[justme1968]

so... was lange wärt...

anbei eine erste version der readingsGroup.

die html ansicht geht erstmal nur in der detail ansicht oder kann mit 'readingsGroup_2html("<name>")' in einen weblink eingebettet werden.

definition wie beim weblink typ readings. also z.b. so:

Code Auswählen Erweitern

define test readingsGroup .* oder mit mehreren <device> bzw <device>:regex paramtern wenn es nicht so viel sein soll :).

das mapping muss aber ins attribut mapping und es wird %NAME ersetzt statt $NAME. die spezialargumente wie *noheader gehen noch nicht. die wandern auch noch in attribute. formatieren kommt auch später.

die neu ausgesendeten trigger sind zur zeit nur auf device ebene eingeschränkt. noch nicht auf readings ebene. d.h. es sind noch ein paar zu viel.

ist das eher so wie du es dir vorgestellt hat? das mit dem rot machen brauchst du nicht extra zu bauen. das geht direkt schon.

gruss
  andre

achja: die doku ist auch noch nicht fertig :)

edit: die angehängt version noch mal aktualisiert. die interne device liste wird jetzt bei define, rename und delete irgendeines devices aktualisiert.

[rudolfkoenig]

> ist das eher so wie du es dir vorgestellt hat?

Prinzipiell ja, bis auf Details, siehe unten.

Es schaut bei mir noch komisch aus, da .*:battery mir eine Liste mit 6x battery anzeigt, damit weiss ich nicht welche Zeile was ist. Ich wuerde statt reading lieber  devname oder devname:reading sehen wollen.
Hoffentlich muss man hier nicht mapping verwenden. Apropos mapping: ich glaube Du musst ein Beispiel bringen, sonst versteht das kein Endbenutzer.

Das get verstehe ich nicht (schaut im Frontend komisch aus), und auch der Hinweis auf weblink ist mir schleierhaft (ja, es geht, aber wozu, direkt ist es doch einfacher), aber vlt. hat Du damit was vor, und da will ich nicht reinreden :)

[justme1968]

kommt alles noch :). das war nur in einer halben stunde aus drei anderen modulen zusammenkopiert und umbenannt um das mit dem triggern zu testen.

zur zeit muss man noch alles mappen. beispiele hier: Link.

defaults und doku werden natürlich noch benutzerfreundlicher.

ist es sinnvoll den weblink readings typ wieder zu entfernen wenn es so weit ist? man könnte ja erst mal einen hinweis einblenden.

[rudolfkoenig]

> ist es sinnvoll den weblink readings typ wieder zu entfernen wenn es so weit ist?

Ja, darum wollte ich dich noch bitten :), ist mir bei fileplot/dbplot nach SVG schieben aufgefallen.

Aber erst nachdem dieses Modul eingecheckt ist.

[justme1968]

ich habe gerade eingebaut das man die html ausgabe ähnlich wie vei devStateStyle formatieren kann. ich habe dazu die attribute style,labelStyle und valueStyle. entweder als string wie bei devStateStyle oder als perl ausdruck der jeweils reading namen und wert übergeben bekommt. damit kann man dann z.b. entweder so etwas machen wie die reading werte rechtsbündig anzeigen oder in einer zusammenfassung von temperaturen das label oder den wert für warmwasser rot und für kaltwasser blau.  

damit könnte man dann z.b. in der readingsgroup alle batterie readings die nicht ok sind rot machen. oder die heitzungsgemperaturen die außerhalb des vorgegeben wertebereichs sind oder die bodenfeuchte der pflanzen die zu trocken sind oder ...

das geht für die namen und werte der readings unabhängig voneinander. dazu wäre es jetzt schön zum einen das rot einfärben beim longpoll update readingsweise abschaltbar zu machen und zum anderen dir farbe mit der eingefärbt wird vom wert abhängig zu machen.

das wertabhängig stylen kann ich zur zeit nur beim ersten auf aufbau der html seite. die farben oder formatierung soll sich aber natürlich dynamisch anpassen wenn sich die werte ändern. hast du eine idee wie man das mit dem longpoll mechanismus integriert?

wie wäre es das stylen der readings nicht nur in der readingsgroup zu erlauben sondern auch in der detail ansicht? wenn man so werte ausserhalb eines erlaubten bereichs leicht erkenne kann wäre das glaube ich allgemein recht praktisch. ebenso die {} erweiterung auch bei devStateStyle.

ein verweis auf die stylesheets reicht jetzt aber nicht weil die nicht dynamisch wertabhängig und auch nicht individuell für einzelne readings sind. für einen anwender ist es auch deutlich einfacher ein paar attribute zu setzen als stylesheets anzupassen.

edit: erste idee: beim automatisch rot machen nur den timestamp einfärben. und den wert nicht. dann kommt sich beides nicht in die quere.

[rudolfkoenig]

> beim automatisch rot machen nur den timestamp einfärben. und den wert nicht.

DAS kriegt man aber bestimmt per stylesheet hin :)

Ich meine natuerlich das Nichteinfaerben nur fuer readingGroup Werte.

[justme1968]

ich merke schon. du hat den komplizierten teil ignoriert :)

und auch dein einfachen teil bekommt man nicht per stylesheet hin. in fhemweb.js  wird hart für spalte 1 und 2 (wert und timestamp) class=changed gesetzt. das kann ich im stylesheet nicht spaltenweise wieder ausschalten. um nur den timestamp einzufärben darf man class=changed nur für spalte 2 setzen.

ich würde vorschlagen in einem aller ersten schritt fhemweb.js so zu ändern das class=changed nur für spalte 2 (den timestamp) gesetzt wird. dann wird nur der timestamp rot wenn das reading gesetzt wird. das ist aus mehreren gründen passend:
- die farbe sagt nur aus das der wert neu ist. nicht das er sich geändert hat.
- es ist weniger rot auf dem monitor.
- der wert kann anhand anderer kriterien engefärbt werden ohne das es durch longpoll überschrieben wird.

ich würde gerne für die readings group so wenig wie möglich sonderwege gehen. und das stylen der readings ist auch für die normale detail ansicht nett.

edit: ich kann die changed farben aus dem readingsGroup modul überschreiben. d.h. punkt drei von oben spielt keine rolle mehr. die ersten beiden fände ich persönlich aber immer noch relevant.

hast du eine idee wie man den anwender in die lage versetzen kann aus dem modul kriterien für dsa einfärben aus dem javascript longpoll zu konfigurieren ohne das er das stylesheet anfassen muss? mit den style attributen von oben geht es nur einmalig beim seitenaufbau.

anbei die aktuelle version mit etwas verbesserter doku. der weblink ist nicht mehr nötig. das wäre der stand den ich einchecken würde.  das einfärben per javasctipt wäre dann version 2. der patch um im weblink readings einen deprecated hinweis einzublenden kommt noch.

[justme1968]

noch einmal eine aktualisierte version:
- doku verbessert
- möglichkeit auch internal values anzuzeigen

und drei mal patches für doku und weblink.

wenn kein wiederspruch kommt würde ich die readingsGroup morgen einchecken. übernimmst du die drei patches?

gruss
  andre

[rudolfkoenig]

>  wenn kein wiederspruch kommt...
kein Widerspruch

> übernimmst du die drei patches?

Habs gemacht. Und die Rotfaerbung auf den Timestamp begrenzt.

[justme1968]

und eingecheckt.

[justme1968]

ich habe eben mal eine art 'proof of concept' gebastelt um aus der readingGroup das dynamische stylen eines reading wertes auch dann zu ermöglichen wenn der wert per longpoll aktualisiert wird.

damit lässt sich per trigger/doTrigger und longpoll der style (und auch andere attribute) eines reading wertes per javascript ändern ohne die seite neu aufzubauen. hierzu wird an den reading namen ein '@' angehängt:

Code Auswählen Erweitern

trigger <device> battery@: style="color:red"
für eine endgültige version sollte man u.a. noch verhindern das in diesem fall auch das -ts event los geschickt wird.

wenn du keine prinzipiellen einwände hast würde ich den patch gerne in dieser richtung weiter entwickeln und in der readingsGroup verwenden.

[rudolfkoenig]

Ich habe prinzipiell nichts dagegen, obwohl ich dein Plan (auf Server Seite) noch nicht ganz verstehe.


>  für eine endgültige version sollte man u.a. noch verhindern das in diesem fall auch das -ts event los geschickt wird.

Bin auf deinem Vorschlag gespannt :)

[justme1968]

der eigentliche plan dahinter ist den style (d.h. normalerweise die farbe) eines reading wertes nicht statisch per stylehseet oder konfiguration zu vergeben sondern dynamisch am wert fest zu machen (z.b. rot für battery low und grün für ok). und das natürlich auch wenn sich der wert per longpoll ändert.

das verhindern ist ganz einfach. das push nur machen wenn kein @ im namen des readings ist:

Code Auswählen Erweitern

push @data, "$dn-$readingName-ts<<$tn<<$tn" if( $readingName !~ m/\@$/;

ich hab aber inzwischen noch ein wenig weiter probiert und statt dem fhemweb.js patch von oben die readingsGroup so geändert das sich die informId genau so wie bei devState nicht auf das <div> mit dem wert sondern auf das <td> darüber bezieht. dann kann ich im longpoll nicht nur den text sondern das ganze <div> mit samt dem style austauschen.
                                                                                                                                           
ich glaube fast diese version gefällt mir noch besser zumal keinerlei overhead für den 'fast path' entsteht. oder denkst du es könnte probleme geben wenn im inform der html code zu sehen ist?

Code Auswählen Erweitern

2013-08-28 22:40:32 readingsGroup test .PCA301_07F92F.power: <div style="color:green">134.5</div>
2013-08-28 22:40:32 readingsGroup test .PCA301_07F92F.consumption: <div style="color:green">0</div>
2013-08-28 22:40:32 readingsGroup test .PCA301_07F92F.consumptionTotal: <div style="color:green">0</div>
2013-08-28 22:40:32 PCA301 PCA301_07F92F power: 134.5
2013-08-28 22:40:32 PCA301 PCA301_07F92F consumption: 0
2013-08-28 22:40:32 PCA301 PCA301_07F92F consumptionTotal: 0
was aber jetzt noch mehr aufällt ist das im event monitor die zusätzlichen trigger der readingsGroup natürlich auch auftauchen. die sehen dann mit <div> und style so aus:
(siehe Anhang / see attachement)                                                                                                                                            
da die events der readings group im normalfall nicht wirklich interessieren könnte man sie ausblenden in dem man sie z.b. mit einem '.' anfangen lässt und im event monitor alle diese readings ausblendet.
                                                     
                                                                                     
ansonsten noch ein kleiner patch der eine {} version von devStateStyle einbaut so wie es für die values in der readingGroup auch möglich ist.

[rudolfkoenig]

Meiner Ansicht nach ist das nicht der richtige Weg, weil HTML nicht in die Events gehoert: wir sollten Daten und Darstellung nicht mischen.

Z.Zt. faellt mir nur ein FormatReadingsFn im Modul ein, was in FHEMWEB/FW_Notify vor dem lossenden des Nachrichts an das JavaScript aufgerufen wird, das wuerde auch das -ts Problem loesen. Was haeltst Du davon?

[justme1968]

an etwas wie FormatReadingsFn hatte ich auch schon gedacht. aber wieder verworfen weil zu dem zeitpunkt wo es aufgerufen würde zumindest bei der readingsGroup der zusammenhang zwischen dem wert auf der einen und dem original device und dem original reading namen eigentlich nicht mehr vorhanden ist sondern rückwärts wieder aus dem namen des zusammengebauten 'pseudo' reading geparsed werden müsste. ich bin mir nicht sicher ob das immer (eindeutig) möglich ist.

vielleicht mit einem eindeutigen trennzeichen. ich schaue es mir noch mal an. aber ich glaube dann lieber doch die javascript version von oben. das funktioniert ja ohne die nebenwirkung das html sichtbar wird.

das die events der readingsGroup im event monitor auftauchen und überflüssig sind passiert aber auf jeden fall. wie ist es mit dem ausblenden durch einen punkt am anfang?

edit: die eigentlich richtige lösung wäre nicht nur daten und darstellung nicht zu mischen sondern sogar beides explizit zu machen und zu trennen. d.h. CommandTrigger und später auch readingsBulkUpdate jeweils einen zusätzlichen optionalen paramter $readingHtml zu geben. dann könnte man in FHEMWEB/FW_Notify

Code Auswählen Erweitern

push @data, "$dn-$readingName<<$readingVal<<$readingHtml"; verwenden. leider habe ich keine idee wie man das mit dem augenblicklichen CHANGED hin bekommt da es nur ein string array und leider kein hash mit getrenntem $readingName und $readingVal ist das man einfach um $readingHtml erweitern könnte.

[rudolfkoenig]

> bei der readingsGroup der zusammenhang zwischen dem wert auf der einen und dem original device und dem original reading namen eigentlich nicht mehr vorhanden ist

Das gleiche Problem hat aber auch die JavaScript Loesung, oder?


> edit: die eigentlich richtige lösung wäre nicht nur daten und darstellung nicht zu mischen sondern sogar beides explizit zu machen und zu trennen

Interessante Gedanke, bin aber z.Zt (noch:) dagegen, da diese Loesung nur eine Art der Darstellung zulaesst, und den Umfang der Events fuer die meisten Faelle (logging/triggering) unnoetig aufblaest.

p.s. bitte nichts wichtiges per edit hinzufuegen, da ich sowas per E-Mail nicht mitkriege.

[justme1968]

die javascript version von oben hat das problem nicht weil ich den trigger genau da los senden kann wo ich alle informationen habe.

das explizite formatieren oder stylen hätte keinen overhead wenn der parameter nicht gesetzt ist. dann ist alles wie bisher. und auch wenn er gesetzt ist muss er nicht im notify auftauchen. ins log muss er nur im höchsten loglevel.

es laesst auch nicht nur eine darstellung zu. wenn der anwender eine feste farbe mit style angibt ist es natürlich diese farbe. es ist ja dass was angegeben ist. aber der mechanismus funktioniert auch mit class. und dann kann man z.b. class=warning verwenden und im stylesheet entscheiden wie das dann genau aussieht.

[rudolfkoenig]

>  die javascript version von oben hat das problem nicht weil ich den trigger genau da los senden kann wo ich alle informationen habe.

Das schon, aber bein einfaerben koennte es sein, das zwei Zeilen auf identisch gemapped sind.


> es laesst auch nicht nur eine darstellung zu.

Ich dachte eher an andere (nicht FHEMWEB) Frontends.
Je laenger ich darueber nachdenke, desto unlieber wird mir es...

[justme1968]

- das verstehe ich nicht.

- ein color:xxx oder class=warning sollte auch für andere frontends kein problem sein. css ist nicht unbedingt html spezifisch. und wenn ein frontend es nicht versteht muss es diesen teil ja nicht verwenden. es ersetz ja nicht den bisherigen normalen ascii value.

[rudolfkoenig]

>  - das verstehe ich nicht.

Vielleicht reden wir wieder aneinander vorbei :), aber ich stelle mir folgendes vor: Es gibt ein readingsGroup, da hat jemand mehrere Zeilen so gemapped, dass die identisch ausschauen. Das JavaScript hat deswegen ein Problem festzustellen, welche Zeile gemeint ist.

Wenn das kein Problem ist (weil eindeutige ids verwendet werden), dann verstehe ich nicht, wieso ein Perl-Funktionsaufruf nicht den gleichen Eintrag wiederfinden kann.

[justme1968]

den javascript aufruf triggere ich aus dem notify in der readingsgroup. da habe ich das direkt das originaldevice. da ist alles eindeutig.

die perlfunktion hätte aber nur den gemappten reading namen aus der readingsgroup und muss daraus rückwärts das device und das original reading bestimmen. das ist dann nicht mehr unbedingt eindeutig.

[rudolfkoenig]

Das verstehe ich wiederum nicht.

Du willst doch das JavaScript mit einem Event triggern, spezifizierst also im Event das Geraet, damit das Javascript es finden kann. Mit der gleichen Info muesste eine Perl-Funktion das Geraet doch auch wieder finden koennen, Perl ist ja nicht dummer als die Javascript Funktion.

Es sei denn du willst das zusaetzliche Info in den neuen Daten reinstecken.
Hast Du mal ein Beispiel fuer mich?

[justme1968]

der link steckt in der informId. die kann ich im notify ohne probleme eindeutig zusammenbauen. mit der perlfunktion die nicht im event kontext des original device aufgerufen wird sondern im context der readingsGroup aber nicht weil ich aus dem nicht eindeutig gemappten namen des 'virtuellen' readings auf das device und den original reading namen zurück kommen muss.

ich mach dir ein beispiel wenn ich zurück bin.

[justme1968]

kaum fährt man 5 stunden auto hat man auch schon wieder ein paar ideen. statt in FormatReadingsFn original device und original reading wieder aus dem 'fake' reading kann ich es mir ja auch in einem hash merken und gleich noch das passende valueFormat und valueStyle mit. das ist dann eindeutig und vielleicht sogar effizienter. vielleicht sogar so generell das es für alle readings in allen device detail ansichten verwendbar ist und nicht nur auf die readingsGroup.

ich probiere das mal und baue einen patch dafür zusammen. du kannst ja dann schauen wie dir das gefällt.

[justme1968]

gibt es eigentlich eine möglichkeit für module sich in das list kommando einzuängen?

dann könnte man die readingsGroup nicht mehr nur im web frontend nutzen sondern auch per telnet um mit list die aktuellen readings der gruppe anzuzeigen.

was hältst du von einer listFn?

[rudolfkoenig]

Z.Zt gibt list/XmlList/JsonList nur das aus, was in $hash zu finden ist, eigentlich auch rekursiv.

Kannst Du bitte _gut_ drueber nachdenken, ob das fuer readingsGroup nicht ausreichen koennte, und wenn nicht, dann muessen wir listFn fuer alle 3 Instanzen implementieren. Bitte aber erst nach 5.5

[justme1968]

der knackpunkt an der readingsGroup war ja genau keine kopien der readings zu halten. d.h. $hash ist komplett leer was das angeht und alles was nur $hash auswertet wird niemals etwas über die zusammengefassten devices erfahren.

[justme1968]

schau mal hier:Link. da hat noch jemand das probmel das es mit dem longpoll update nicht immer funktioniert.

wie weiter oben im thread steht habe ich das problem ja auch in manchen räumen. ich habe gerade die idee das es an den umlauten liegen könnte noch mal getestet. und scheinbar könnte es etwas damit zu tun haben: wenn ich das device aus dem beispiel von oben (ein HM-LC-SW4-DR) im raum garten habe in dem noch andere devices mit einem alias sind die umlaute haben funktioniert der update nicht. wenn ich das ding gleichzeitig in einem raum test habe in dem es keinen content mit umlauten gibt geht es.

d.h. beide räume offen, jeweils per webcmd ein und aus schalten. wenn ich in dem test raum schalte werden beide korrekt aktualisiert. erst der state mit set- und dann das on oder off icon. wenn ich das gleiche aus dem raum mit dem umlauten mache wird nur der test raum korrekt aktualisiert und der raum mit den umlauten nicht.

das device selber enthält keinen umlaut. nur andere devices in dem raum haben einen alias der einen umlaut enthält.

gruss
  andre

[rudolfkoenig]

Kann nicht nachvollziehen mit folgendem setup:

Code Auswählen Erweitern

define d dummy
attr d webCmd on:off
attr d room Icöns

Zwei Firefox (aktuelle Version) Fenster nebeneinander, mit fhem und Raum Icöns
Ich kann sowohl per telnet als auch vom browser aus den Zustand aendern (set d on, set d off). Komischerweise funktioniert "trigger d on" nicht.

Ich haette gerne einen aehnlichen Setupzum nachstellen, jedenfalls eins ohne Hardware.

P.S.: Sollten wir diesen Beitrag nicht mal schliessen, die Frage hat doch nichts mit FW_devState zu tun?

[rudolfkoenig]

Nachtrag: auch ein zweiter dummy mit

Code Auswählen Erweitern

define d2 dummy
attr d2 webCmd on:off
attr d2 room Icöns
attr d2 alias dzwö

ändert etwas, scheint erstmal alles zu funktionieren.

[justme1968]

es hat schon was mit devStateIcon zu tun weil das icon ja nicht richtig aktualisiert wird.

ich fürchte mit einem normalen dummy ist es nicht zu reproduzieren es passiert bei mir nur bei den devices die mehr als ein mal aktualisiert werden. also z.b. hm oder swap. also fhem setzt state z.b. auf set-on und dann kommt vom device erst das richtige on.


mal sehen ob man es mit einem kleinen dummy device reproduzieren kann. ich glaube immer noch das es daran liegt das beim klick auf ein webCmd (im gegensatz zum click auf das icon) die seite neu aufgebaut wird und dann das zweite update verloren geht.



gruss
  andre

[justme1968]

das mit den umlauten scheint tatsächlich irgendein zufall oder seiteneffekt zu sein aber nicht der grund.

wenn ich in fhemweb.js in zeile 36 das logging einschalte  dann sehe ich bei den meisten räumen das direkt nach dem seiten aufbau ein das doUpdate schon das erste mal aufgerufen wird. das sind die räume bei dennen es mit dem longpoll beim klick auf webCmd keine probleme gibt.

bei dem einen raum mit dem problem ist der erste aufruf von doUpdate direkt nach dem seitenaufbau aber leer. hier wird das icon dann auch nicht richtig aktualisiert.

bei den räumen die am anfang den fehler haben erscheinen dann nach und nach events für alle möglichen devices auf der debug console. auch devices die nicht in diesem raum sind.

bei räumen ohne problem sind auf der debug console nur events für die devices zu sehen die tatsächlich in dem raum sind.

ich glaube in FW_Notify geht beim zusammenbau der inform liste für das doUpdate manchmal etwas schief.

[justme1968]

so.... ich glaube ich habe es...

es passiert immer wenn in einem raum ein plot ist. durch den vorhandenen plot wird FW_longpoll zusätzlich wärend des seitenaufbaus getriggert. das bewirkt das ein XHR aufruf mit room=all gemacht wird. dieser überschreibt dann $FW_room mit 'all' was zur folge hat das für den raum in dem sich der plot befindet das FW_roomStatesForInform mit room all aufgerufen wird und nichts mehr passt.

wenn man in 98_SVG.pm im embed tag room=\"$FW_room\" mit einbaut und in FW_longpoll den check auf embed rausschmeisst wird in FW_roomStatesForInform wieder der korrekte raum verwendet und alles funktioniert.

[rudolfkoenig]

Ich verstehe deine Begruendung noch nicht: falls inform auf all steht, dann kommen beim JS hoechstens mehr Daten an, als gewuenscht, und sollte kein ein Seiten-Neuaufbau mit FW_roomStatesForInform bewirken. Selbst dann kriegt das JS nur den Status aller Geraete, was wiederum nicht schaedlich sein sollte.

Das SVG Problem ist aehnlich wie bei deinem readingsGroup: SVG zeigt Daten aus anderen Raeumen an, deswegen versucht fhemweb.js beim Vorhandensein von SVGs (fuer longpollSVG) an alle Daten zu kommen. Nach deinem "Patch" wuerde das nicht mehr funktionieren.

Die longpollSVG Implementierung gefaellt mir vom Prinzip nicht, und ich habe nichts dagegen es abzuschaffen, wenn es dadurch ein Bug behoben wird, ich sehe das aber noch nicht.

Es kann aber sein, dass durch Daten, die eigentlich nicht auf der Seite sichtbar sind, ein Bug getriggert wird: das sollten wir finden und fixen.

[justme1968]

gut. also schrittweise:

- wenn ich per devStateIcon schalte wird das kommando per XHR ausgeführt und danach das icon per longpoll aktualisiert. -> alles ok.

- wenn ich per webCmd schalte wird die seite komplett neu aufgebaut. -> das ist an sich schon unschön.

- bei räumen die 'korrekt' funktionieren sehe ich das direkt nach dem initialen seitenaufbau alle zustände ein mal komplett per inform zum browser geschoben werden und dann bei bedarf jeweils für die devices die auf der seite zu sehen sind.

- bei räumen die nicht funktionieren wird nach dem initialen seitenaufbau eine leere inform liste zum browser übertragen. und danach dann events für alle devices.

meine vermutung: bei devices die den zustand zweistufig ändern kommt die zweite stufe genau zwischen seitenaufbau und übertragen der leeren liste und geht verloren. wenn mit der vorgeschlagenen änderung die initiale inform liste nicht leer ist ist genau da die zweite stufe drin.

das svg daten aus anderen räumen braucht betrifft doch nur SVGlongpoll oder? dann sollte man vielleicht die devices die dafür relevant sind per attribut angeben damit man nicht auf alle zurück fallen muss. bei mir ist SVGlongpoll übrigens aus und das umschalten auf all garnicht nötig.

[justme1968]

das die initiale inform liste in den fehlerhaften räumen (die bei denen room durch die svg auf all gesetzt werden) leer ist liegt daran das devspec2array für room=all nichts zurückliefert. ich weiss nicht ob es seiteneffekte hat wenn man das in devspec2array ändert. alternativ würde auch ein $room = ".*" if( $room eq "all" ); in FW_roomStatesForInform als workaround helfen. oder in fhemweb.js in FW_longpoll room auf .* initialisiert und nicht auf all.

trozdem bin ich aber immer noch der meinung das ein svg das nicht SVGlongpoll verwendet den room auch nicht auf all setzen sollte.

wie wäre es wenn man SVGlongpoll nicht einfach auf 1 setzt sondern wirklich die liste der devices angibt die relevant sind. dann könnte man direkt die devices in die inform liste mit aufnehmen und müsste nicht auf all zurückfallen.

[rudolfkoenig]

>  ein svg das nicht SVGlongpoll verwendet den room auch nicht auf all setzen sollte.

Da bin ich auch deiner Ansicht, und es hat mich etwas gewundert, dass das nicht der Fall ist.
Ich werde es aendern, sobald ich ein bisschen freien Kopf dafuer habe.

[justme1968]

hallo rudi,

gibt es wegen dem longpoll und svg problem schon was neues? ich glaube das ist der grund warum wie im anderen thred erwähnt im raum everything der update per longpoll nicht geht. und spiff der gerade meine farbigen icons für sein dmx device verwendet hat auch ein problem sobald ein plot im gleichen raum ist.

gruss
  andre

[justme1968]

es gibt etwas neues zur nicht vollständigen aktualisierung per longpoll. schau mal hier:http://forum.fhem.de/index.php/topic,17913.msg118975.html#msg118975