FW_devState() verwendung

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