FW_devState() verwendung

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

Vorheriges Thema - Nächstes Thema

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

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

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

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

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

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

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

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

rudolfkoenig

Kann nicht nachvollziehen mit folgendem setup:
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
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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

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

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

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.

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

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

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

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

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

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

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

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