FW_devState() verwendung

Begonnen von justme1968, 11 Juli 2013, 11:05:57

Vorheriges Thema - Nächstes Thema

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 :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

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?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

UliM

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.
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

justme1968

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

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

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

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

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?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

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