fhemweb.js Umbau

[justme1968]

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.

[betateilchen]

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

[justme1968]

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

[betateilchen]

Und ich hab grade die "Problemliste" aktualisiert.

[justme1968]

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?

[UliM]

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

[rudolfkoenig]

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

[betateilchen]

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.

[justme1968]

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.

[justme1968]

deine version ist noch nicht ganz vollständig. es fehlt noch der Eintrag in den css Files:

Code Auswählen Erweitern

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

[rudolfkoenig]

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.

[justme1968]

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.

[justme1968]

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.

[justme1968]

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

[betateilchen]

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