FHEM Forum

Ich habe fhemweb.js umgebaut, damit man die widgets wie slider, time, etc. nicht doppelt (einmal in perl, einmal in JavaScript) implementieren muss.
Jquery & jquery-ui sind jetzt immer dabei, longpoll handling und loadScript habe ich auch verbessert.

Ein widget wird implementiert, indem man in www/pgm2/fhemweb_XXX.js eine (oder mehrere) createFn's definiert, Beispiele (textfield, select, slider, etc) sind in fhemweb.js zu sehen. Die bisherigen Methoden um Widgets anzulegen (d.h. in perl) sind zwar auch noch funktional, aber unerwuenscht.
createFn wird mit einer Reihe von Parametern aufgerufen, die nicht alle gefuellt sind, jenachdem ob man sich auf der Detailseite befindet und per set/get/attr die Widgets aufruft, oder diese wegen webCmd in der Raum-Ansicht dargestellt sind.

Ich habe es mit fhem.cfg.demo getestet, und ich meine da sind jetzt keine Probleme zu sehen, ich moechte aber die widgets von andre (colorpicker, readingsGroup, readingsHistory) geprueft haben, bevor es in trunk eingecheckt wird.
@andre: koenntest du in fhem.cfg.demo fuer diese widgets ein Beispiel einbauen?

Ich habe mein code in SVN nach /branches/FHEMWEB_JS_UMBAU eingecheckt.

ich schaue es mir an und baue beispiele für fhem.cfg.demo.

dazu gleich zwei fragen:

- im colorpicker wird für bestimte modi automatisch auf einen slider umgebogen und dieser passend parametrisiert. geht das mit der neuen js only version auch? bzw. wie stelle ich für diesen fall dann sicher das fhemweb_slider.js geladen ist?

- das zweite ist eine erweiterung von oben bei dem ich einen normalen slider verwende aber eine eigene/zusätzliche class geben um ihn im css extra zu behandeln. in der 'alten' perl version würde ich einfach per search/replace das class=... ersetzen/erweitern. wie würde das in der js version aussehen?

die anwendung dafür wäre z.b. einen slider zur auswahl von farbe, farbtemperatur oder helligkeit mit dem passenden hintergrund zu versehen und so einen hue-slider, ct-slider, ... zu bekommen ohne den kompletten slider neu zu implementieren. siehe hier: http://forum.fhem.de/index.php/topic,18958.msg237965.html#msg237965 (http://forum.fhem.de/index.php/topic,18958.msg237965.html#msg237965).

- Es werden alle fhemweb_XXX.js Dateien weiterhin geladen
- fhemweb_slider, time, multiple, noArg und textField habe ich in fhemweb.js integriert, damit der Browser nicht so viele Dateien beim (ersten) Anzeige einer FHEM Seite laden muss. Da fhemweb.js vor allen anderen fhemweb_XXX.js geladen wird, ist der Slider-code fuer alle vorhanden.
- wie man einen Slider fuer eigene Zewecke anlegt, sieht man auch in fhemweb.js/FW_createTime(). Hier eine Skizze angepasst fuer deinen Fall:
  var sl = FW_createSlider(undefined, devName+"Slider1", ["slider", min, step, max],
                currentValue, undefined, function(arg) { DoSomethingWithResult(arg) });
  $(colorpicker).append(sl);
  colorpicker.activateFn = function() { sl.activateFn() }
  $(sl).addClass("colorSlider");

Falls der Slider in einem "colorpicker" div ist, dann ist addClass eigentlich nicht notwendig, da man CSS Regeln fuer diesen kombinierten Fall erstellen kann:
div.colorpicker div.slider { color:green; }
... oder so.

   

bin gerade dabei die createFn einzubauen und in der cfg.demo zu verwenden. dabei sind mir schon zwei dinge aufgefallen:

- ich verwende die möglichkeit einem widget in den webCmd auch ein argument mit zu geben. also z.b. rgb:rgb ff0000. das zeigt dann einen normalen colorpicker und einen roten preset button hat. das geht zur zeit mit der neuen version nicht wegen 'webCmd "temp 30" should remain text'. ich würde vorschlagen das wie bisher im widget zu entscheiden. d.h. das widget blendet den text ein oder entcheidet das es nicht zuständig ist wenn es einen parameter gibt.

ich würde vorschlagen das:
- in FW_widgetFallbackFn return auf return auf if(!$values || $values eq "noArg"); zu beschränken
- der createFn einen zusätzlichen parameter args zu geben. nach reading und in reading nur den namen des readings zu haben
- in den createFn auf das vorhanden sein der args zu prüfen und gegebenenfalls nichts zu machen
- FW_replaceWidget genau so um args zu erweitern und dort  die informId nur auf das reading zu setzen
- das splitten schon in FW_widgetFallbackFn zu machen und als eigenes attribut zu übergeben oder wenn alles in einem attribut bleiben soll das attribut in set oder cmd umzubenennen und in FW_jqueryReadyFn nach set und args zu splitten.

ich habe zum testen schon einen teil davon umgesetzt. wenn du magst mache ich es fertig und poste es als patch.


- wenn man in der detail ansicht zwei mehr als ein mal auf den attribut namen geklickt hat wird anschliessend nicht der inhalt des text Feldes übernommen sondern immer eine 1

das setzen der inform id in FW_replaceWidget ist glaube ich zur zeit komplett falsch.

du setzt die informId immer auf devName. das muss doch eigentlich devName-reading sein.

das es mit der .cfg.demo geht ist zufall und liegt daran das bei den dort verwendeten devices state mehr oder weniger passt.

mit der richtigen reading abhängigen informid funktionieren die dropdown und slider für state in der .cfg.demo aber nicht mehr. da passt für state noch etwas nicht.

die informId sollte auch nur dann automatisch gesetzt werden wenn in der createFn noch keine gesetzt wurde.

edit: statt der informid devName-reading könnte man auch die dev und reading attribute der ersetzten fhemWidget übernehmen und damit arbeiten. ich weiss nicht was besser wäre.

rgp Parameter: Waere es nicht einfacher widgetOverride zu verwenden?
attr x webCmd rgb
attr x widgetOverride rgb:rgb,#ff00000
Sonst muss man im JavaScript zwei Arten uterstuetzten, Parameter an einem Widget zu uebergeben. Ist zwar fuer den Endanwender etwas komplexer, er lernt aber dann auch, wie man Widgets komplett umstellt.

Detail Attribut klicken: kann nicht nachvollziehen. Habs mit Chrome und Firefox getestet, und wie ein Irrer auf die Attribute geklickt.

informId: ich habe mit devName-reading angefangen, aber da haben die beiden Slider im Demo/Cinema nicht mehr funktioniert. Habe eine Weile ueberlegt, was wichtiger ist, mehrere unterschiedliche Reading-widgets pro Zeile zu unterstuetzen, oder eins, der auf alle Aenderungen reagiert, und da ich eher Letzteres haben will (damit die Leute es einfacher haben), habe informId auf devName gesetzt. Wenn du eine gute (und einfache :) ) Loesung fuer das Demo-Problem hast, dann lasse ich mich umstimmen.

Ich habe FW_replaceWidget angepasst, damit sie informId nur dann setzt, falls informId im zurueckgelieferten Baum noch nicht gesetzt ist.

widgetOverride ist nicht mehr einfacher wenn es mehr als ein oder zwei einträge mit parametern sind.

es funktioniert auch nur wenn alle gleichartigen parameter direkt nebeneinander im webCmd kommen. rückwärtskompatibel ist es auch nicht.

für die farb presets der lampen kommen schnell 5 oder 10 buttons zusammen. die nicht alle zum gleichen kommando gehören.

für den anwender wären es mit der widgetOverride zwei arten. ein mal direkt im 'temp 30' beispiel und ein mal wie von dir mit widgetOverride vorgeschlagen. das ist nicht nur komplex sondern auch verwirrend weil es dann vom widget abhängt wie er es angeben muss.

das im javascript zu unterstützen ist ein kein problem mit dem obigen vorschlag. die widgets die keine paramtere akzeptieren tun einfach nichts.


das attribut klicken:zwei mal auf den namen des gleichen attributs klicken und dann im text feld enter oder auf attr klicken. bei mir steht danach reproduzierbar immer ein 1 im attribut. mit safari und chrome zu 100% reproduzierbar.

devName-reading ist aber unbedingte voraussetzung um z.b. bei einem device mit zwei readings in webCmd einen slider für beide readings zu haben. oder auch für jedes device bei dem state nicht vom gerade verwendeten reading abhängt. mit der aktuellen version wird kein slider oder dropDown für homematic und hue funktionieren.

das problem an den beiden slidern in der .cfg.demo (und bei fs20) ist das es kein reading gibt das wirklich zum slider gehört. d.h. das kommando heisst dim xxx aber der longpoll update geht auf state. eigentlich ist das die ausnahme.

hier ist ja auch beim initialen seiten aufbau ein fallback eingebaut. wenn es das reading (das zum widget gehört) für current nicht gibt weichst du auf Value aus. eigentlich müsste man nur dafür sorgen das in der inform id device-state verwendet wird wenn es das reading nicht gab und statt dessen Value verwendet wurde.

die lösung (nicht nur für das demo problem sondern für die meisten devices :) ) ist das set (für das das widget definiert wurde) und das reading (aus dem der default wert kommt un das im fallback zu state wird) getrennt zu übergeben und nicht implizit davon auszugehen das beide identisch sind obwohl state als fallback verwendet wird.

ich habe eine version gebaut die den obigen vorschlag implementiert.

damit gehen die alten/fs20 demo slider und alle oben angesprochenen anderen devices.

ich hänge die version morgen mal hier an.

mir ist übrigens noch ein problem aufgefallen. beim ersten laden einer seite wenn noch nichts gecached ist funktioniert das timing für den aufruf von FW_jqueryReadyFn nicht. wenn man bei google danach sucht findet man auch das document.ready nicht dafür empfohlen/geeignet ist weil es genau diese timing probleme gibt.

> das attribut klicken...

Habs gefixt.

Zitatfunktioniert das timing für den aufruf von FW_jqueryReadyFn nicht.

Welches Timing? Ich habe es sowohl mit FHEMWEB (jquery wird vorher geladen), wie auch mit FLOORPLAN (jquery wird dynamisch geladen) getestet, mit jeweils vorher geloeschten Cache.

Ich habe in diesem Zweig dem SVG beigebracht, mehrere Quellen (FileLog/DbLog/logProxy) zu akzeptieren.

Syntax im gplotFile ist entweder wie bisher (#FileLog, #DbLog, etc), in diesem Fall wird die in der SVG definierte Quelle genommen, oder (neu) #<fhemDeviceName>, womit man die Quellen nach belieben mischen kann.

Der SVG-Editor unterstuetzt das auch (ueber eine neue Spalte in jeder Zeile kann man die Quelle auswaehlen), eine Aenderung der sampleDataFn in den Lieferanten (logProxy, DbLog) ist dafuer nicht notwendig. Allerdings habe ich SVG_sel um eine Klasse erweitert, damit das Ergebnis etwas ordentlicher ausschaut, sowas koennte man evtl. in logProxy/DbLog auch nachziehen.
Die Ausgabe von "Show preprocessed input" erfolgt jetzt in einem Dialog, da betateilchen sich beschwert hat.
Die angezeigten Beispiele haengen vom aktuellen Focus ab (wird per JS eingeblendet), und sinnvolle Spaltenwerte bzw. Beispiele bekommt man erst nachdem man die neue Quelle ausgewaehlt, und die Datei gespeichert hat, das ist nicht ganz intuitiv.

@andre: koenntest du in fhem.cfg.demo auch Beispiel(e) fuer logproxy eibauen, damit ich sowas einfacher testen kann?

anbei eine erweiterung der .cfg.demo um einen raum Color mit zwei farbigen lampen:

• die CT lampe lässt sich in der farbtemperatur verstellen und hat vier presets sowie on und off
• die RGB lampe lässt sich im farbton und der farbe verstellen und hat drei presets sowie on und off

testen kann man damit:

• die widgets funktionieren auch für readings. nicht nur für state.
  das ist unter anderem für homematic,hue,swap, alle(?) heizungen und fast alles ausser dummy und fs20 wichtig


• eine änderung von state ändert nicht mehr die widgets für andere readings


• bei der RGB lampe hängen die hue und rgb readings von einander ab.
  das setzen des einen wertes ändert auch den jeweils anderen. die widgets werden alle korrekt per longpoll aktualisiert


• für farbtemperatur und farbton verwendet der colorpicker einen passend parametrisierten slider mit entsprechendem hintergund.


• der colorpicker geht jetzt auch in der detail ansicht :)

damit es nach dem ersten starten auch schon funktioniert ist es wichtig das es die readings die zu den widgets gehören tatsächlich gibt. dafür ist fhem.save angepasst.
für die 'spezial' slider muss das hintergrundbild in den styles gesetzt werden. im patch ist nur defaultCommon.css angepasst. die anderen styles müssen noch nachgezogen werden.


der patch für alles ist angehängt. ich habe auch 'meine' files noch nicht eingecheckt weil ich die signatur der createFn erweitert habe und alles zusammen passen muss.

todo: readingsGroup, readingsHistory, logProxy


die änderungen an 01_FHEMWEB.pm und fhemweb.js im einzelnen:

• trennen von reading und set in FW_widgetFallbackFn für class fhemWidget
    -> informId wird korrekt auf 'device-reading' gesetzt. sonst funktionieren widgets nur für state und nicht für andere readings


• die reinen text kommandos wie 'dim 25' oder 'temp 30' werden nicht mehr in FW_widgetFallbackFn in 01_FHEMWEB.pm
  erzeugt sondern auch in FW_replaceWidget. sonst funktionieren die colorpicker presets nicht mehr.


• in FW_detailSelect für FW_queryValue bei cmd=set den gleichen fallback auf Value(devName) eingebaut wie in FW_widgetFallbackFn.
    -> fs20 dim slider sind auch in der detail ansicht passend initialisiert
    frage: ist Value für beide fälle wirklich der richtige fallback oder wäre ReadingsVal auf state besser?


• longpoll aktualisierung auch in der detail ansicht für die set widgets die zu echten readings gehören.
  für die widgets die zu einem kommando ohne eingenes reading (z.b. fs20 dim) gehören funktioniert das (noch) nicht weil der obige fallback die trennung von reading und set noch nicht kennt. dazu müsste man in FW_queryValue rausfinden ob der wert aus dem reading oder aus dem fallback kommt.


• für slider in der detail ansicht hat ein klick auf 'set' das jeweilige reading auf 0 gesetzt hat wenn der der slider vorher nicht bewegt wurde.
  das lag daran das bei aufruf der setValueFn durch FW_queryValue das value attribut nicht aktualisiert wurde.
    -> slider.nextSibling.setAttribute('value', currVal); in activateFn hinzugefügt

fragen:

• elName wird in FW_detailSelect zwar zusammengebaut aber nicht verwendet.
  der name kommt scheinbar immer noch aus 01_FHEMWEB. ist das absicht?
• gibt es einen grund das der slider in der detail ansicht einen anderen style hat?

 
vorschläge:

• wie wäre es in der detail ansicht auf das post zu verzichten und bei set/get/attr das kommando auch per xhr an fhem zu senden. damit würde der seitenaufbau vermieden und vor allem auch das zurückspringen der dropDowns auf den ersten wert.dazu müsste man noch ein bauen das die widgets ersetzt werden wenn sich die set/get/attr liste veränder hat.


• dazu könnte man den widgets auch eine getValueFn verpassen um den eingestellten wert zu bekommen und nicht implizit über ein value attribut zu gehen.


• wie wäre es neben der longpoll nachricht mit den durch << getrennten segmenten eine zweite nachricht z.b mit >> getrennt zu spendieren. und eine kleine api funktion in fhemweb um eine solche nachricht per longpoll zu senden. dann könnte ich damit die updates für readingsGroup und readingsHistory senden ohne events/DoTrigger zu verwenden und diese nachrichten könnte man im eventmonitor ausblenden.


• oder wenn wir beim umstellen sind: wie wäre es das format der longpoll nachrichten gleich auf z.b. json umzustellen?

Habe die beiden farbigen Lampen in fhem.cfg.demo ins Light room gepackt, und den restlichen Patch ohne wesentliche Aenderungen uebernommen. Der Patch ist aber noch nicht Fehlerfrei: wenn man in Light/Single Lights/Office auf Detail geht, dann steht "set Office blink off" in der ersten Zeile, und das ist Mumpitz. Loesungsvorschlag: ReadingsValue default leerlassen. Das habe ich aber nicht eingecheckt.

Weiss nicht genau was du mit elName meinst, das Auskommentierte (inzwischen entfernte) ist Zwischenstand beim Umbau gewesen.
Slider-Style: ich sehe kein Unterschied.

An den Vorschlaegen Arbeite ich noch.

in der detail ansicht auf das post zu verzichten: Habs programmiert, und erstmal auskommentiert, da weder die Internals (STATE), noch die Attribute neu gesetzt werden, und das finde ich sehr irritierend. Weiterhin erstellen manche Module bei einem neuen get ein Reading, andere nicht.

getValueFn: verstehe den Sinn nicht

zweite Nachricht z.b mit >>: Den Sinn von >> vs. << verstehe ich nicht, ich habe aber ein FW_directNotify gebaut, als Parameter muss man ein hash mit CHANGED Array uebergeben, dieser ruft dann alle FHEMWEBs die ein notify erwarten auf. Falls andere Frontends das auch haben wollen, dann kann ich das von FHEMWEB nach fhem.pl schieben.

format der longpoll nachrichten auf json umzustellen: habs umgestellt, bin aber noch nicht sicher, ob es besser ist.

P.S.: habe Value aus dem ReadingsValue Aufruf entfernt, hat zu sehr genervt :)

wenn die farbigen lampen im Light room sind kannst du sie auch gleich noch zur AllLights structure hinzufügen.

das mit dem slider style:
in defaultCommon.css gibt es
  .slider     { float:left; width:250px; height:26px; }
und
  .makeSelect .slider {background:#F0F0D8; border-radius:8px;} /* detail only */
das hat dann zur folge das ich für die abgeleiteten slider auch jeweils zwei einträge brauche.

das mit dem Value fallback ist schade. bei den dim slidern wäre es schön gewesen. aber das problem lässt sich vermutlich nicht lösen so lange es die kommandos ohne eigenes reading gibt.

das mit den internals stimmt leider auch. da würde es nur helfen wenn das frontend die werte erneut abfragt. auch nicht schön.

als 'kleine' lösung wäre es vielleicht gut wenn die set/get/attr drop down nach dem seiten aufbau wieder auf den gleichen zuletzt ausgewählten eintrag stehen würden. dazu müsste man das im post mit schicken und beim dann im FW_makeSelect wieder zurück geben.

ohne getValueFn 'weiss' fhemweb.js nicht wo es den aktuellen wert eines widget her bekommt. zur zeit ist es implizit das attribut value in einem versteckten input field. das wäre dann nicht mehr nötig. so lange es beim post bleibt ist es aber egal.

die zweite nachricht bzw. die umstellung auf json hat den hintergrund von fhem nachrichten ans frontend zu senden die nicht im eventmonitor auftauchen und ohne nebenwirkungen zu parsen und einem widget zuzuordnen sind.

für die readingsGroup (und auch readingHistory) wird html code und icons und formatierter text ans frontend gesendet der auch im eventmonitor auftaucht und da eigentlich nicht hin gehört und auch geloggt wird wenn die regex im log device passt. die idee für das api (FW_directNotify) wäre jetzt kein format vorzugeben sondern einen adressaten (per device namen) und die nachricht anzugeben. d.h. die eine longpoll verbinundung wird für unterschiedliche daten verwendet. die events/reading updates zum einen und 'private' nachrichten die z.b. eine readingsGroup nur an ihr zugehöriges wirdget im frontend senden kann und die nicht mit andere nachrichten vermischt werden. mir json könenn die nachrichten inhaltsunabhängig verarbeitet werden. nur das adress schema muss vorgegeben werden. z.b. 'fhemweb:longpoll' für das was bisher longpoll ist und 'readingsGroup:xxx' für die nachrichten für die nur die readingsGroup zuständig ist. das xxx wäre wieder modul spezifisch. ich würde hier den device namen rein stecken.

Zitatwenn die farbigen lampen im Light room sind kannst du sie auch gleich noch zur AllLights structure hinzufügen.

Erledigt

Zitatdas mit dem slider style:

Habe die zweite Variante entfernt.

Zitatnur das adress schema muss vorgegeben werden

Muss das? valueFn wird doch aufgerufen, da kann man anhand des Arguments entscheiden, was man machen will. Ich habe FW_directFn angepasst, damit das noch einfacher geht. Mit:
{ FW_directNotify("Livingroom", "dim20") }
landet dim20 als Argument im valueFn des passenden Sliders. Wenn das so nicht passt, melde dich.

Habe svg.js angepasst, damit es etwas zivilisertere Menues verwendet, und die Werte nicht aus der X/Y Koordinate des Klicks abliest, sondern aus den Daten (siehe Screenshot).

Andre: falls du mit deinen Sachen fertig bist, werde ich den Branch ins trunk mergen.

ich muss mir die readingsGroup noch vornehmen. zumindest schauen ob erst mal alles geht.

wenn es erst mal keine probleme gibt kann ich dein eigentlichen um umbau dann auch im trunk machen.

ich melde mich.

Ich würde mich freuen, wenn bei den SVG Plots mit automatischer Skalierung die Graphen nicht immer am oberen oder unteren Rand so direkt kleben würden, damit man die auch mal sehen kann. Ich hatte schonmal versucht dazu ein Patch zu erstellen, allerdings blicke ich da nicht wirklich durch.

schau mal in den thread hier: http://forum.fhem.de/index.php/topic,25618.msg186124.html#msg186124 wie das jetzt schon möglich ist. etwas handarbeit aber es funktioniert.

gruß
andre

Danke fuer den Hinweis, kannte ich auch nicht.
Und erinnert mich daran, dass ich min1/max1/etc bei Plots mit mehreren Quellen noch Umsortieren muss.

wie wäre es in den range anweisungen direkt einen perl ausruck zu erlauben der beide werte zurück geben muss. ohne den umweg über die label.

also etwa so: yrange [{return (0,$data{max1})}]

du immer mit deinen Perl-Expressions überall  ::)

Ich würde es eher begrüßen, wenn das durch das Modul automatisch gehandelt wird. Also auch bei mehrfachen graphen die richtige Skalierung plus einem gewissen Abstand unten (z.B. 5 Pixel) und einem Abstand entsprechend der Graphenbeschriftung oben (Die gesamte Höhe der Graphenbeschriftung).

Momentan finde ich es sehr nervig, wenn die Graphen durch die Beschriftung durchgehen.

Ich hab natürlich nichts dagegen, wenn man als fortgeschrittener User da individuell eingreifen möchte, aber es sollte auch ohne manuellen Eingriff einigermaßen "hübsch" aussehen.

Viele Grüße

Markus

ich hatte angefangen mir einen automatischen weg zu überlegen aber das wird sehr schnell sehr schwierig das automatisch zu machen. vor allem wenn man mehr als eine kurve in der grafik hat.

oben und unten x pixel frei zu lassen wäre recht einfach. den platz für die beschriftung automatisch frei zu lassen funktioniert z.b. nur wenn es nur ein oder höchstens zwei kurven sind. eigentlich müsste die legende optional rechts neben den plot.

das beste was mir eingefallen ist war den kleinsten min und größten max werte aller kurven die zu einer einer achse gehören zu nehmen und auf die spanne oben und unten jeweils 2.5% drauf zu schlagen.

gruss
  andre

anbei ein patch der einen modifier textField-long ergänzt.

für textField-long wird beim klick auf das text feld ein dialog mit einem textarea auf gemacht in dem mehr platz zum editieren ist.

zusätzlich ist beim normalen textField noch ein doppelklick auf das öffnen des dialogs gemapped. ich weiss aber noch nicht ob das vielleicht unerwünschte seiteneffekte hat.

im gegensatz zum select dialog habe ich closeOnEscape auf true gesetzt. ich fände das auch für alle anderen dialog praktisch.

anbei eine erste version eines fhemweb_knob.js widget.

die ursprünglichen threads waren hier: http://forum.fhem.de/index.php/topic,14753.msg95363.html#msg95363 (http://forum.fhem.de/index.php/topic,14753.msg95363.html#msg95363) und hier: http://forum.fhem.de/index.php/topic,20738.0.html (http://forum.fhem.de/index.php/topic,20738.0.html).

das interface ist erst mal kompatibel zum slider und der knob kann überall statt einem slider verwendet werden.

noch zu klären ist:
- wie und wo wird $data{FWEXT}{knob}{SCRIPT} passend gesetzt
- eigentlich heisst das js file jquery.knob.js. mit diesem namen wird es aber nicht über die FWEXT/SCRIPT schleife geladen weil alles mir pgm2/jquery im namen ausgelassen wird.
- unter welchem namen und wo wird das knob.js file eingecheckt.
- wie macht man die anderen optionen des knob verfügbar? nur per css? oder auch per setList/widgetOverride

Das mit "$data{FWEXT}{knob}{SCRIPT}" verstehe ich nicht.

Falls ein widget weitere Scripte benoetigt, dann sollte es mit loadScript laden, diese Funktion habe ich (hoffentlich) gefixt. Wenn es Probleme geben sollte, dann melden.
Man kann sowohl alles in www/pgm2 einchecken, dann wird fhemweb_knob.js automatisch laden. Oder man packt es nach www/knob, dann muss der Anwender das FHEMWEB JavaScripts Attribut spezifizieren. Auf diesem Weg kann man auch FHEM-Attribute spezifizieren (XXXParam, wobei XXX.js das spezifizierte JavaScript is), das ist mAn aber gar nicht notwendig, weil man die Parameter besser nach dem "knob" spezifizieren kann.

wegen den js files für den knob: es sind ja zwei. ein mal das fhemweb_knob.js das sollte natürlich nach www/pgm2. aber das js file aus dem knob packet selber muss ja auch irgendwohin. beim colorpicker hatten wir jscolor als eigenes verzeichnis. beim knob ist es aber nur ein file jquery.knob.js bzw. jquery.knob.min.js

jquery.knob.js bzw in knob.js umbenannte file habe ich nicht geschafft aus fhemweb_knob.js mit loadScript zu laden. ich sehe zwar das es geladen ist aber ich kann die funktionalität in der fhemweb_knob.js createFn nicht nutzen. ich habe noch nicht gefunden woran es liegt. deshalb habe ich noch die alte methode mit $data{FWEXT}{knob}{SCRIPT} = "/pgm2/knob.js" verwendet.

readingsGroup und readingHistory funktionieren beide erst mal im UpdateLine kompatibilität modus. wenn du es eilig hast mit dem mergen kann ich die änderungen aufs neue api auch danach machen.

der hintergrund für den colorpicker muss nicht in die anderen styles. am besten in darkCommon.css oder?
.colorpicker_ct .slider { background: url(../jscolor/ct_background.svg); }
.colorpicker_hue .slider { background: url(../jscolor/hue_background.svg); }

Zitat von: rudolfkoenig am 03 Januar 2015, 14:12:02
Ich habe in diesem Zweig dem SVG beigebracht, mehrere Quellen (FileLog/DbLog/logProxy) zu akzeptieren.

Zu meinem Verständnis: erfolgt das Rendern des SVG-Bildes mit diesen Neuerungen nun im Client?

Viele Grüße
Boris

Nein, mit jsSVG bin ich noch nicht weitergekommen.

- Habe fuer range Perl Expression erlaubt. Allerdings leicht anders implementiert, das Format ist folgendes: { "[0:10]" }. Ist etwas komplizierter zum spezifizieren, dafuer aber "Zukunftssicher".
- es gibt ein $data{maxAll}/$data{minAll}, allerdings ist das nicht Achsenspezifisch.
- textField-long hinzugefuegt, die Doppelklick-Aktivierung fuer textField ausgebaut.
- fhemweb_knob.js hinzugefuegt & in FHEMWEB widgetOverride Abschnitt dokumentiert. Beispiel:
attr dimmer widgetOverride dim:knob,min:1,max:100,step:1,linecap:round,fgColor:red

Ich wuesste gerne, ob man die Farben auch per CSS setzen kann.

Ich bau das jetzt ins svn-trunk ein, und melde die Aenderungen in Ankuendigungen.

ist $data{maxAll}/$data{minAll} wirklich sinnvoll wenn es nicht achsenspezifisch ist? um es in einer expression für range zu verwenden funktioniert es nur wenn es nach achsen getrennt ist. wie wäre ein $data{maxAxis-n}/$data{minAxis-n}?

den knob per css zu stylen scheint leider nicht zu gehen.

baust du bitte die den hintergund für die ct und hue slider noch in den dark style ein..colorpicker_ct .slider { background: url(../jscolor/ct_background.svg); }
.colorpicker_hue .slider { background: url(../jscolor/hue_background.svg); }

mir ist gerade noch etwas aufgefallen:

mit safari 6 muss ich in svg.js in den zeilen 125-138 die alle drei html() aufrufe zum ändern der überschriften beim ein- und ausblenden einer kurve gegen text() austauschen. sonst bekomme ich einen js fehler und es wird nichts ausgeblendet.

das zeigen der plot werte funktioniert mit diesem browser auch nicht weil scheinbar die mausmove events nicht ankommen.

ich weiss nicht wie wichtig dir diese recht alte browser version ist.

anbei ein patch der die in dem anderen thread vorgeschlagene möglichkeit die legende nach links zu plazieren implementiert.

ich habe es nicht über den plot editor sondern über ein attribut captionLeft eingebaut weil es logisch zum endPlotNow attribut gehört. konsequenter weise müsste es aber dann auch ein FHEMWEb attribut sein...

safari6 ist mir zwar nicht wichtig, aber ich habe es umgebaut. Wuesste aber gerne, was das eigentliche Problem ist (also mehr Details, als nur "geht nicht").

captionLeft habe ich eingebaut UND DOKU GESCHRIEBEN. Bin nicht sicher ob der Name mir gefaellt, das Wort wird sonst nicht verwendet.

die genaue meldung istTypeError: 'undefined' is not an object (evaluating 'b.innerHTML.replace')  in jquery.min.js:3

caption wird zumindest im code als kommentar für die legende verwendet und ist auch eine korrekte übersetzung dafür.

die doku hätte ich geschrieben sobald du sagst der patch ist ok. am ende gefällt dir der name oder die tatsache das es ein attribut ist nicht...

anbei ein patch der den floorplan auf den aktuellen stand bezüglich jquery, widgets & co bringt:

- css und js laden an die aktuelle fhemweb version angepasst
- widgetOverride eingebaut
- widget handling aktualisiert und auf mehr als das erste widget in der webCmd liste erweitert
- colorpicker (und presets) repariert
- longpoll eingebaut
- utf-8 encoding im page header für longpoll updates gesetzt

es wäre gut wenn jemand mit einem umfangreicheren floorplan testen kann ob es irgendwelche seiteneffekte gibt.

die hue und ct slider haben im floorplan noch nicht den richtigen hintergrund. da die slider im floorplan schmaler sind als in fhemweb muss ich auch noch schauen wie ich das svg für den hintergrund automatisch in der breite anpassen kann.

ich habe noch ein problem mit der readingsGroup bemerkt:

die readingGroup kann ja für die readings aus einem device auch das widget der zugehörigen set funktion einblenden. in diesem fall ist es aber nötig das die inform id des widgets nicht mehr vom device namen und reading des original device vorgegeben wird sondern von der readingGroup besimtmt wird da diese sichtbar ist und die events erzeugt.

bisher wurde das durch einfaches ersetzen in dem durch die webCmdFn zurückgelieferten html code gemacht. das geht jetzt nicht mehr da hier jetzt nur der stub code für ein fhemWidget zurück kommt das erst später durch js ersetzt wird. ich brauche also eine möglichkeit diesem fhemWidget mitzugeben welche informId es haben soll.

mit dem angehängten patch wird FW_replaceWidget um einen optionalen zusätzlichen paramter ergänzt. dieser wird in der FW_jqueryReadyFn aus den attributen der class fhemWidget geholt.

wenn dieses attribut nicht gesetzt ist bleibt alles wie bisher, wenn die readingGroup diese attribut für das fhemWidget setzt wird wird die informId aus dem attrubut genommen.

Zitatbisher wurde das durch einfaches ersetzen in dem durch die webCmdFn zurückgelieferten html code gemacht.

Koenntest du das nicht auch jetzt? Diesmal mit Javascript:
$("#readingsName").find("[informid]").each(function(){
  $(this).attr("informid", "mynewinformid");
})
oder so.

Btw. kannst du bitte im fhem.cfg.demo ein readingsGroup mit so ein set einbauen, damit ich auch sehe, wovon wir reden?

Zitat von: justme1968 am 10 Januar 2015, 22:50:41
anbei ein patch der den floorplan

Hi André,
super, vielen Dank dafür. Leider bin ich diese Woche wiedermal unterwegs und werde weder testen noch einchecken können.
Wenn Du feedback auf den patch erhältst und das stabil ist, kannst Du's gern einchecken.

LG, Uli

@rudi: ich habe jetzt eine javascript lösung gebaut und eingecheckt.

readingsGroup, logProxy und auch readingHistory für die demo kommen noch.

@UliM: mal sehen wann feedback kommt. scheinbar gibt es auch noch layout/css probleme. ich weiss nicht ob der patch auch hier hilft.

@andre bzw. FLOORPLAN Patch: bitte die Reihenfolge "FW Extensions" und "Other JavaScripts + their Attributes" umtauschen, das gefaellt mir so besser, und loest das Problem mit fronthemEditor.js. Sonst sind alle Anpassung sinnvoll, es macht einige Ausnahmen in fhemweb.js ueberfluessig. Warum hast du die CssFiles Schleife nicht uebernommen?

Ich wuesste gerne, woher die Positionsprobleme in FLOORPLAN kommen, das alte FLOORPLAN von Uli schaut bei mir ok aus, habs ja auch beim Umbau getestet.

fronthemEditor.js nimmt das zweite jquery wieder raus wenn keine Beinflussung mehr durch dashboard und co sind. ich teste.

Scheint zu laufen, habs rausgeworfen. Danke!

anbei eine überarbeitete version des floorplan patches.

ich habe die reihenfolge vertausch.

die css schleife war nicht drin weil ich fürchte das es nicht kompatibel zu bestehenden installationen ist da der floorplan ja eigene style hat und vermtutlich einiges anders ausschaut wenn die fhemweb files geladen werden.

ich habe aber jetzt das CssFiles und JavaScripts attribut auch für den floorplan eingebaut und die beiden schleifen darauf aktiviert.

Habe die Aenderungen angeschaut, mit dem alten (2012-11) Floorplan von Uli getestet, eingecheckt und fuer update zur Verfuegung gestellt. Ich glaube nicht, dass sie die Probleme in den gemeldeten Faellen loesen, sie machen aber einige Workarounds in den anderen Modulen unnoetig, und erleichtern damit das debuggen.

ich bin heute dazu gekommen etwas mit FW_directNotify zu spielen. als beispielanwendung habe ich in fhemweb eingebaut das der 'Save config' menü eintrag rot wird wenn es nicht gespeicherte änderungen gibt. wenn gespeichert wird ändert sich die farbe wieder auf normal.

so ganz glücklich bin ich noch nicht mit der umsetzung weil es an zwei drei stellen noch mit workarounds arbeitet. aber vielleicht ist es ja trotzdem nützlich. das ganze besteht im prinzip aus vier kleinen teilen:
- über $lastSavedChange feststellen ob es änderungen gab
- beim seitenaufbau den link passend parametrisieren
- per longpoll auf änderungen reagieren
- die css änderungen für die farbe

dabei sind mir noch ein paar dinge aufgefallen die in zusammenhang mit der FW_directNotify noch nicht funktionieren:

- nachrichten lassen sich nur ans frontend senden wenn es ein zur nachricht gehörende device in $ntfy->{inform}{devices} gibt.
  ich habe in diesem vorschlag hierfür ein pseudo device "#FHEMWEB:$FW_wname" in die liste eingefügt damit fhemweb sich
  nachrichten 'out of band' an sich selber (von per zu js seite) senden kann.
  die idee ist das # in keinem device namen auftauchen kann, danach der modul name und das device.

  ich denke es sollte ein weg geben mit dem der frontend js code events anfordern kann die zu nicht dargestellten devices gehören.
  in diesem fall wäre das global.

- es wäre gut FW_directNotify einen dritten parameter zu spendieren der im dritten paramter von FW_longpollInfo landet

- es wäre gut wenn noch etwas mehr kontrolle über das FW_directNotify zu haben und auch selbst codiertes json übergeben zu können.

- die änderung in fhem.pl wäre nicht nötig wenn $lastDefChange ein timestamp und kein counter wäre.

mit 1. wäre es möglich den patch mit etwas weniger abhängigkeiten zwischen perl und js teil zu halten

2. und 3. werden wichtig um mehr informationen zwischen backend und frontend auszutauschen sobald es komplexere widgets gibt. dazu demnächst mehr.

Funktioniert prinzipiell gut,

• das Save config ist direkt nach dem fhem-Start auch jedesmal rot.
• das "Save config" bleibt auch dann rot, wenn "save" über die Kommandozeile ausgeführt wird.
• das "Save config" wird auch dann rot, wenn ich einen beliebigen Raum aufrufe oder zum Beispiel nur auf "Everything" klicke

ich hab oben den fhem.pl.patch noch mal aktualisiert. jetzt stimmt der status auch nach einem neustart.

ein 'bekanntest' problem gibt es noch: nach einem neustart werden bestehende browser fenster nicht aktualisiert falls sie rot waren. das ist aber kein prinzipielles problem sondern das baue ich ein wenn ein patch dieser art akzeptiert wird :)

Und ich hab grade die "Problemliste" aktualisiert.

damit beim save von der kommandozeile die farbe wieder auf normal wechselt ist js nötig. das ist aber eingebaut und geht bei mir. was sagt deine js console?

beim wechsel zwischen räumen ändert sich der zustand bei mir nicht. was siehst du hier auf de js console?

Zitat von: rudolfkoenig am 17 Januar 2015, 08:55:26
Habe die Aenderungen angeschaut, mit dem alten (2012-11) Floorplan von Uli getestet, eingecheckt und fuer update zur Verfuegung gestellt. Ich glaube nicht, dass sie die Probleme in den gemeldeten Faellen loesen, sie machen aber einige Workarounds in den anderen Modulen unnoetig, und erleichtern damit das debuggen.

Hallo André, hallo Rudi,
Habe grad ein update gefahren incl. der neuen FP-Version - bei mir sieht alles gut aus.
Vielen Dank für eure Änderungen!
Mal schauen ob noch weitere Meldungen bzw. offene Punkte der user kommen.
Gruß, Uli

@andre: ich habe deine Idee aufgegriffen und etwas verallgemeinert: Ein Event fuer das #FHEMWEB Device fuehrt das Argument als JavaScript Code im Browser aus.

Ich gehe davon aus, dass das rote "Save config" etliche Fragen ausloesen wird.

Bezüglich FHEMWEB Fehler: Kommando zurück. Ich hatte vergessen, die fhem.pl auch zu aktualisieren.

Jetzt kann ich alles wieder fehlerfrei starten. Aber rot wird bei mir nach Änderungen nichts.

die idee das so rum zu machen ist gut. generell js an den browser zu senden ist noch für eine ganze reihe anderer dinge nützlich. das ein- und ausblenden und das auf- und zu klappen von elementen oder wechseln von seiten und anzeigen von hinweisen und und und.

wenn man das rücksetzen von changed noch im longpoll reconnect einbaut ist auch das problem von oben das nach einem fhem restart der browser noch den alten zustand anzeigt behoben.

deine version ist noch nicht ganz vollständig. es fehlt noch der Eintrag in den css Files:.changed a { color:red; }

zumindest mit safari fehlt sonst beim raum wechseln die farbe da es kein normaler text sondern ein link ist.

warum der live update trotzdem geht vertstehe ich nicht ganz...

edit:
das problem ist das beim seiten aufbau der style für das div element über dem <a> link gesetzt wird und per js wird der style im <a> element direkt geändert.

für ersteres müssen die css Files angepasst werden bei letzterem greift der bestehende changed eintrag aus dem css file.

also entweder immer auf das <div> gehen und alle css files anapssen oder auf das <a> gehen und auch beim seitenaufbau die class dafür setzen.

Ich hab den Eintrag in *.css gemacht, obwohl ich das vermeiden wollte.
Die Alternative, jedem a Tag um FW_pH auch eine Klasse zu vergeben kam mir noch schlimmer vor.

eine möglichkeit wäre eine zweite version von FW_pH die die klasse auch im link setzt würde ohne änderung am css und ohne änderung an allen anderen stellen funktionieren.

mir ist eben noch ein problem aufgefallen:

wenn es einen room gibt der genau so heisst wie ein fhemwidget wird jetzt an dieser stelle manchmal ein halbes widget eingeblendet. beim slider ist es am auffälligsten.

das liegt am setzen der klasse auf den namen für die menu zeilen. ein prefix wie room_ würde glaube ich helfen.

und leider noch eines:

das einfärben geht mit dem dark style in dieser variante nicht weil es da eine css definition für  table.room a gibt die vorrang hat.

ich glaube diese zeile kann einfach weg da sie das gleiche spezifiziert wie die normale a definition weiter oben

das Weglassen sorgt aber trotzdem nicht dafür, dass die Rotfärbung korrekt funktioniert.

hmmm. default geht bei mir out of the box und dark nach entfernen der zeile. sowohl mit safari als auch mit chrome.

geht es noch bei jemandem ausser mir ?

Habe darkstyle.css modifiziert (color:red!important), und Ein menu_ Praefix bei der Klasse hinzugefuegt.

Nich nur at Befehle haben ein Problem mit der Rotfaerbung, auch manche Module wie Dashboard, die Zeitverzegert nach dem start Attribute setzen. Generell passt mir die Idee nicht, dass Module dem Benutzer automatisch Attribute unterjubeln.

wenn man neben TEMPORARY auch noch VOLATILE beim hochzählen von lastDefChange ausnimmt hätte man eine grossen teil der 'falsch positiven' at erschlagen.

ich finde es gut wenn module attribute mit sinnvollen defaults versehen. aber das geht auch ohne das lastDefChange sich ändert.

vielleicht wäre aber hierfür doch ein 'richtiger' mechanismus sinnvoll.

Zitat von: justme1968 am 19 Januar 2015, 14:24:54
default geht bei mir out of the box und dark nach entfernen der zeile. sowohl mit safari als auch mit chrome.

geht es noch bei jemandem ausser mir ?

Auf einem "nackten" fhem funktioniert es nun auch bei mir. Aber auf meinem Produktivsystem bekomme ich das bis jetzt noch nicht zum Laufen.

ich bin gerade über ein problem im makeSelect mechanismus gestolpert:

wenn das (alphabetisch) erste kommando in der setList mit :noArg definiert ist dann wird in der detail ansicht beim auswählen eines anderen kommandos das tatsächlich ein widget einblendet dieses widget nicht in der gleichen zeile sondern in der zeile darunter eingeblendet und beim klick auf 'set' werden die werte des widgets (z.b. der inhalt eines textField) ignoriert.

zum reproduzieren:define d dummy;
attr d setList a:noArg b:textField
wenn man in der detail ansicht set b auswählt erscheint das text feld in der nächsten zeile und bei klick auf set wird der eingegebene text ignoriert.

da bist Du nicht als Erster drüber gestolpert, das ist genau das hier beschriebene Problem:

http://forum.fhem.de/index.php/topic,32463.0.html

den thread hatte ich nicht gesehen.

der knackpunkt ist glaube ich das :noArg im alphabetisch zuerst kommenden set kommando.

ich tippe mal das dadurch beim umschalten die widgets so an einen falsche stelle im layout gesetzt werden das sie hinterher beim post der wert ignoriert wird.

eventuell hilft es beim :noArg ein hidden textField zu verwenden.

hab es kurz getestet.

mit einem FW_createNoArg das so ausschaut:  var newEl = $('<div style="display:inline-block">').get(0);
   if(elName)
     $(newEl).append('<input type="hidden" name="'+elName+ '" value="">');
   return(newEl);

funktioinert es.

aber es gibt ein unschönes flackern bei seitenaufbau.

Das ist doch wieder eine Krücke und keine Lösung.

Ich hasse JavaScript. Sagte ich das schon?

das sollte auch keine lösung sein sondern nur die bestätigung das tatsächlich daran liegt das etwas das layout so durcheinander bringt das beim post die werte nicht gefunden werden.

ok.

@andre: Danke fuer die Analyze und den Patch-Vorschlag, ich habs leicht geaendert (display:none) eingecheckt, und ich sehe kein Flackern.

spricht etwas dagegen auf eine aktuelle jquery-ui version zu aktualisieren ?

ich würde gerne das selectmenu verwenden.

wie wäre es für die fhemweb styles auch automatisch ein passenden jquery-ui style zu verwenden? zu default und dark und ios gibt es recht gut passende defaults auf der jquery-ui seite.

ich bin gerade dabei widget für eine allgemeine zeitschaltuhr zu bauen. dabei fallen auch die einzelnen widgets für zeit- und wochentags auswahl sowie ein toggle button mit ab. die wochentags auswahl ist so allgemein das man jede n aus m auswahl damit abbilden kann die auf ein mal sichtbar sein soll.

vielleicht wäre es gut widgets nur bei bedarf zu laden und nicht mehr alles das mit fhemweb_ anfängt ?

Jquery-UI- update: gerne.
Passende jquery-ui styles: von mir aus auch, hast Du einen Vorschlag? Ich will von dem "gelogenen" Stylenamen (style.css) weg, da es Probleme verursacht.
Beim bedarf laden: hast Du eine Idee, wie man ein unbekanntes widget von dem default (select) unterscheiden soll?

zu den styles: wie wäre es für jeden fhemweb style ein unterverzeichniss zu haben. hier könnte man dann alle files die zu einem style gehören ohne namenskonflikte zwischen den styles halten. es könnte dann jeweils ein common.css, ein fhemweb.css, ein floorplan.css, ein jquery-ui.css, ein codemirror.css, ... geben. fhemweb würde alles laden was im verzeichnis für den aktuellen stylesheetPrefix liegt.

zum laden: man könnte alles automatisch laden das mit fhemweb_ anfängt, alle zusätzlichen widgets aber fhemwidget...js nennen. und dann in FW_jqueryReadyFn vor dem ersetzen aller fhemwidgets das jeweilige fhemwidget_....js file laden wenn es noch keinen eintrag in FW_widgets gibt. damit hätte man dinge die immer geladen werden sollen von den widgets getrennt die nur geladen werden wenn sie auch tatsächlich auf der seite vorhanden sind.

hier: http://forum.fhem.de/index.php/topic,32430.msg249776.html#msg249776 (http://forum.fhem.de/index.php/topic,32430.msg249776.html#msg249776) gibt es zwei beispiel plots für die .cfg.demo.

der sonnauf- und -untergang funktioniert mit der aktuellen version des svg moduls, das spinnennetzdiagramm noch nicht. aber ich denke eki findet noch woran es liegt.

gruss
  andre

So einen style Ordner fände ich auch sinnvoll auch um dort style spezifische js mit einbinden zu können.

PS: kommt jquery jetzt immer in fhemweb oder muss es immer noch gezielt importiert werden?

Das Problem mit dem Ordner ist, dass das Verschieben beim update nicht so reibungslos durchzufuehren ist, insb. mit benutzerdefinierten Styles.

Jquery+Jquery-UI wird beim FHEMWEB und FLOORPLAN Aufruf automatisch als erstes geladen.

es müsste beim update ja nur das verschoben werden was zu den standard styles gehört. wenn es zu einem style kein directory gibt könnte man den bisherigen weg als fallback erst mal drin lassen.

hier: http://forum.fhem.de/index.php/topic,32670.msg250583.html#msg250583 (http://forum.fhem.de/index.php/topic,32670.msg250583.html#msg250583) ist mal wieder ein problem aufgetaucht weil sich das state reading nicht eindeutig unterscheiden lässt.

sollten wir nicht versuchen das zumindest für die longpoll updates zu beheben? hier könnte man doch state eindeutig als state: versenden und eine passende informId verwenden.

die events für die notifys wären davon nicht weiter betroffen.

Meinst Du, dass das state-Reading eine Sonderbehandlung erfährt und nicht als state:foo in den Event-Mechanismus geschleust wird? Das ist mir heute auch schon auf die Füße gefallen.
bn

ja. genau.

das kann schon für events  probleme machen. auch wenn es hier praktische  gründe und die rückwärts kompatibiliät gibt .

aber für die longpoll updates ist es unnötig und nur probleme.

bin da auch sehr dafür, im Zweifel auch bei Events.

Zitat von: Dr. Boris Neubert am 24 Januar 2015, 16:51:45
Das ist mir heute auch schon auf die Füße gefallen.
bn

vtml dito
http://forum.fhem.de/index.php/topic,30909.msg251065.html#msg251065

vg
jörg

Mir ist die gestrige changed Änderung heute auf die Füße gefallen, da ich Links als Block rendere (besser klickbar auf Touchgeräten).
Da HTML technisch kein Link benötigt wird, würde ich deshalb folgenden Patch vorschlagen:
Nutzen eines Span statt a, hat das gleiche Ergebnis nur sauberer.

Zudem fand ich die übergreifende Klasse ganz nett um das Icon auch umzufärben, deshalb würde ich sie gerne behalten aber unter einem anderen Namen (changedicon)

Index: 01_FHEMWEB.pm
===================================================================
--- 01_FHEMWEB.pm (revision 7706)
+++ 01_FHEMWEB.pm (working copy)
@@ -1268,6 +1268,9 @@
         my $class = "menu_$l1";
         $class =~ s/[^A-Z0-9]/_/gi;

+        $class .= ($lastDefChange>$lastSavedChange) ? " changedicon" : ""
+                        if($l1 eq "Save config");
+
         # image tag if we have an icon, else empty
         my $icoName = "ico$l1";
         map { my ($n,$v) = split(":",$_); $icoName=$v if($l1 =~ m/$n/); }
@@ -1276,8 +1279,8 @@
                         FW_makeImage($icoName,$icoName,"icon")." " : "";

         if($l1 eq "Save config") {
-          $l1 .= '</a> <a id="saveCheck" class="changed" style="visibility:'.
-                      (int(@structChangeHist) ? 'visible' : 'hidden').'">?</a>';
+          $l1 .= ' <span id="saveCheck" class="changed" style="visibility:'.
+                      (int(@structChangeHist) ? 'visible' : 'hidden').'">?</span></a>';
         }

         # Force external browser if FHEMWEB is installed as an offline app.

@Blackcat: Lustigerweise war Dein Vorschlag auch mein erster Versuch, ziemlich genau so :) Ich habe danach noch relativ lange experimentiert, bis ich eine (fuer mich) befriedigende Loesung gefunden habe. Die Haken mit dieser Version:
- das span _IM_ <a> der FP_pH fuehrt dazu, dass ein Click auf das Fragezeichen auch ein save ausloest.
- ich muesste alle Styles anpassen, und das nervt, wg. den Leuten mit eigenen Styles.
Heisst nicht, dass ich nicht offen fuer Aenderungen bin.
Btw. lastSavedChange ist seit gestern Geschichte, und das '</a>' am Ende ist ueberfluessig, bzw. ein Fehler.

ah jetzt habe ich es gesehen, da kann man ja auch noch ein Fenster öffnen. Schick wäre natürlich, wenn man anstatt dem ? einen Änderungscounter hätte :) (kleine Spinnerei am Rande)

Dann muss ich jetzt mal schauen, wie ich den Savechanges Link verbreitere und gleichzeit mir nicht das ? wegrutscht ;)

Zitat von: Blackcat am 25 Januar 2015, 13:49:46
Mir ist die gestrige changed Änderung heute auf die Füße gefallen, da ich Links als Block rendere (besser klickbar auf Touchgeräten).

Ging mir heute mit dem ios7Style gleich :)

Ich hab es erstmal mit einer absoluten position gelöst.
#saveCheck { position: absolute; top: 5px; right: 10px; }


Grüße

danke :) das sieht schon besser aus

@andre: wenn ich es richtig verstanden habe, muessten wir verhindern dass in
CHANGEDWITHSTATE das state Reading ohne Prefix reinkommt.  Vermutlich wuerde
dazu reichen addEvent einen optionalen zweiten Parameter zu spendieren, um
CHANGEDWITHSTATE zu fuellen. Ich frag mich nur, ob das Fehlen des state Events
ohne Prefix nicht irgendwelche Nebeneffekte beim Aktualisieren auf der
Raumuebersicht hat.

@Jörg: verwendest du auch deviceEvents()?

@Jörg: verwendest du auch deviceEvents()?

Nein, ich hänge am notify weshalb ich in "fhemweb.js Umbau" vmtl auch leicht off-topic bin.

ZitatSonderbehandlung erfährt und nicht als state:foo in den Event-Mechanismus

Das war der Punkt - die Unterscheidung in den events ob es reading oder state ist basiert aktuell auf intelligentem Raten.

Würde mir deviceEvents helfen ?

vg
jörg

NotifyFn wird mit $hash aufgerufen, der ein $CHANGED Feld enthaelt mit allen Events (ohne das Wort "state").
deviceEvents liefert ein anderes Feld zurueck, das den Eintrag mit dem Wort "state" enthaelt. deviceEvents wird u.A. in FHEMWEB verwendet.

ich habe den Aufruf noch nicht durchschaut. Ich müsste dann in der notifyFn des Moduls "von Hand" deviceState() aufrufen ? In einem äteren post dazu habe ich gefunden das die enddevice-module das (per attr) akiv unterstützen müssen, hat das noch bestand ?

Attr sagt mir nichts, allerdings funktioniert das nur bei Modulen die readings*Update verwenden.
Wer das noch nicht tut, der soll sein Modul anpassen.

es gibt zwei informids die in zusammenhang mit state relevant sind:

- <device> ist für das device icon in der raum übersicht
- <device>-state ist für das state reading in der detail ansicht.

die longpoll nachricht für <device> wird unabhängig von den einträgen in $events immer anhand von STATE erzeugt.
die longpoll nachricht für <device>-state wird ganz normal durch das state: eintrag in CHANGED erzeugt.

für den fall das state keinen : enthält steht in $events:$VAR1 = [
          'test',
          'state: test'
        ];
und werden genau drei longpoll nachrichten erzeugt. für das icon (unabhängig von $events), für state und für den state timestamp.
der eintrag für state ohne präfix erzeugt keine longpoll nachricht und bewirkt auch sonst nichts weiter.

sobald state einen : enthalt taucht in $events etwas auf das beim split dann fälschlicherweise für ein event auf ein reading gehalten wird das es aber gar nicht ist:$VAR1 = [
          'a: on b:off',
          'state: a: on b:off'
        ];
dieses erzeugt dann die falsche longpoll nachricht.

wenn der falsche eintrag vorher schon rausgefiltert wird und gar nicht erst in CHANGEDWITHSTATE landet sollte eigentlich alles gut sein und diverse 'fehlinterpretationen' werden vermieden.

deviceEvents sollte nicht nur state: hinzufügen sondern auch das state reading ohne präfix nicht mehr mit zurück liefern.

Ist das eigentlich beim Aufruf von "update" so gedacht?

Events (global only):
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:13.888 Global global RMDIR: /usr/local/FHEM/share/fhem/restoreDir/2015-01-24
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:14.351 Global global UPD FHEM/00_SONOS.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:14.759 Global global UPD FHEM/00_THZ.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:15.017 Global global UPD FHEM/00_ZWDongle.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:15.159 Global global UPD FHEM/01_FHEMWEB.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:15.463 Global global UPD FHEM/10_EnOcean.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:16.060 Global global UPD FHEM/10_ZWave.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:16.271 Global global UPD FHEM/21_SONOSPLAYER.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:16.611 Global global UPD FHEM/33_readingsGroup.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:16.825 Global global UPD FHEM/33_readingsProxy.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:16.972 Global global UPD FHEM/70_ENIGMA2.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:17.292 Global global UPD FHEM/70_ONKYO_AVR.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:17.508 Global global UPD FHEM/70_PHTV.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:17.837 Global global UPD FHEM/70_XBMC.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:18.041 Global global UPD FHEM/98_copy.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:18.148 Global global UPD FHEM/98_logProxy.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:18.336 Global global UPD FHEM/98_structure.pm
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:18.522 Global global UPD docs/commandref.html
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:19.617 Global global UPD docs/commandref_DE.html
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:20.451 Global global
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:20.482 Global global update finished, "shutdown restart" is needed to activate the changes.
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:20.537 Global global
#FHEMWEB:WEB<<$('#saveCheck').css('visibility','hidden')<< 2015-01-28 17:28:25.709 Global global fheminfo server response: ==> ok

Im normalen Event-Monitor sieht alles gut aus. Nur wenn man ein update mit updateInBackground durchführt, habe ich solche Ausgaben. Ist das bei anderen auch so?

Dieses Problem habe ich gestern eigentlich gefixt.

ich habe für den farbtemperatur slider jetzt auch einen gespiegelten hintergrund eingecheckt der verwendet wird wenn die farbtemperatur in mired statt in kelvin angegeben wird.

ich habe mir erlaubt die ergänzung in deinen styles gleich mit ein zu checken. ich hoffe das war ok.

bevor ich ein eigenes image eingecheckt habe wollte ich das vorhanden image per js spiegeln. das funktioniert aber leider nur bei embeded svg und nicht bei referenzierten.

bei meinen versuchen ist mir aber noch etwas anderes aufgefallen: ich wollte das spiegeln in der activateFn erledigen. das wäre aber nur mit klimmzügen gegangen da der slider die activateFn bei jeder änderung selber aufruft und nicht nur ein mal wenn das element in den dom baum eingefügt ist.

sauberer wäre zum setzen der änderungen nicht die activateFn zu 'missbrauchen' sondern jeweils eine eigene interne funktion anzuspringen.

Habe FW_directNotify mit einem optionalen ersten Parameter "FILTER=room=XXX" erweitert, siehe http://forum.fhem.de/index.php/topic,48736.msg404497.html#msg404497