widgets, zeitschalturen und baukästen

[justme1968]

anbei eine erste version diverser widgets mit denen sich im fhemweb frontend oberflächen für zeitschaltuhren erstellen lassen.

das ganze ist ein baukasten aus unterschiedlichen widgets die sich zum teil auch für andere zwecke einsetzen lassen.

• uzsuToggle: ein einfacher toggle button mit zwei möglichen zuständen.
  der button lässt sich mit widgetOverride in den webCmd jedes beliebigen device verwenden um zwischen
  zwei möglichen zuständen hin und her zu schalten. der erste zustand wird inaktiv dargestellt und ist der default, der
  zweite zustand wird aktiv dargestellt.
  
  define tToggle dummy
  attr tToggle setList state:uzsuToggle,123,xyz
  attr tToggle webCmd state
  
  



• uzsuSelect und uzsuSelect-radio:eine button leiste in der mehrere bzw. nur ein einziger button aktiv sein können.
  define tSelect dummy
  attr tSelect setList state:uzsuSelect,abc,123,456,xyz
  attr tSelect webCmd state
  
  



• uzsuDropDown: ein dropDownMenu
  define tTemp dummy
  attr tTemp setList state:uzsuDropDown,18,18.5,19,19.5,20,20.5,21,21.5,22,22.5,23
  attr tTemp webCmd state
  
  


• uzsuTimerEntry: ein widget das die drei widgets oben in eine zeile eines timers kombiniert
  define tEntry dummy
  attr tEntry setList state:uzsuTimerEntry
  attr tEntry webCmd state
  
  


• uzsu: ein widget das es ermöglicht beliebg viele schaltzeitpunkte per uzsuTimerEntry zusammen zu klicken
  define tUZSU dummy
  attr tUZSU setList state:uzsu
  attr tUZSU webCmd state

hinter uzsuTimerEntry und uzsu kann optional mit einem komma angehängt jedes beliebige fhemweb widget im widgetOverride
format angegeben werden. dieses wird dann verwendet um den schaltzustand auszuwählen.
... setList state:uzsu,slider,0,5,100                                                               -> ein slider
... setList state:uzsu,uzsuToggle,off,on                                                          -> ein on/off button
... setList state:uzsu,uzsuDropDown,18,19,20,21,22,23                                 -> ein dropDownMenü
... setList state:uzsu,knob,min:18,max:24,step:0.5,linecap:round,fgColor:red  -> das knob widget
... setList state:uzsu,colorpicker                                                                    -> der colorpicker
... setList state:uzsu,colorpicker,CT,2700,50,5000                                           -> ein slider für farbtemperatur

alle widgets funktionieren in der raum und in der detail ansicht. lassen sich per webCmd und readingGroup verwenden. die aktualisierung per longpoll funktioniert in allen drei einsatzbereichen.

wichtig: ab uzsuTimerEntry ist das ganze ist zur zeit nur frontend. um die eingestellen werte zu
verwenden sind noch folgende dinge nötig:

• wrapper um die tagesprofile der heizungsthermostaten in und vom format des frontends zu konvertieren
• wrapper für das WeekdayTimer format
• wrapper für die sonos alarm einstellungen inklusive titel auswahl
• wrapper z.b. für das disabledForIntervalls attribut
• ein neues fhem timer device das mit dem smart visu frontend und diesem hier vorgestellten zusammen arbeitet

die kommunikation zwischen backend/modul und frontend kann auch per json erfolgen. damit wird eine engere integration einfacher.
das habe ich aber nur kurz probiert und noch nicht weiter verfolgt da es für den rückweg (frontend -> fhemweb) noch keinen weg gibt.


weitere offene fragen:

• zur zeit werden alle einzelnen änderungen im frontend direkt live ns backend übertragen. das ist nicht bei allen geräten sinnvoll. wenn z.b. geänderte temperatur profile per funkt an die Thermostate gesendet werden sollte das erst nach einem gesonderten ok passieren. hier für ist noch ein mechanismus nötig.
• die vertikale ausrichtung der widgets ist noch nicht korrekt. vor allem wenn man grosse widgets zur kommando auswahl verwendet.
• es fehlt noch eine bessere zeit auswahl.
  das drop down menü ist dafür nicht wirklich geeignet. ich habe mir schon ein paar existierende jquery-ui widgets angeschaut aber es war noch kein wirklich gut passendes dabei.
• das ganze ist noch nicht mit dem floorplan getestet
• es wird noch eine möglichkeit hinzukommen das ganze zusammen zu klappen und auch per popup z.b. aus einer thermostat readingGroup (http://forum.fhem.de/index.php/topic,27353.msg228670.html#msg228670) zu verwenden.

was wird benötigt:

• ein aktuelles jquery-ui.js -> ist angehängt und wird demnächst in fhem integriert
• die passenden jquery-ui styles -> ein beispiel das zum darkstyle passt ist angehängt,
                                      eine in fhem integrierte lösung wird noch gesucht
                                      eigene styles lassen sich auf der jquery-ui web seite zusammenklicken
• das fhemweb_uzsu.js file -> ist angehängt und wird demnächst integriert

gruss
  andre

[Blackcat]

Wow schön geworden

Man kann doch in css ein Import machen für die ui Erweiterungen so wie z.b. Es beim Dashboard der fall ist

[strauch]

jquery-ui gefällt mir, das könnte auch an anderen Stellen einzug halten . Mal wieder eine sehr schöne Erweiterung. Danke.

[Risiko]

Hallo Andre,

könntest du bitte kürz erklären wie der Mechanismus funktioniert bzw. wo ich dazu was finden kann.
Wenn man fhemweb_uzsu.js nicht hat, dann sind z.B. bei tTemp setList state:uzsuDropDown,18,18.5,19,...  'uzsuDropDown' der erste Eintrag in der Dropdownbox. So wie man es auch erwartet.

Wer ruft den nun die Create-Funktionen

Code Auswählen Erweitern

FW_widgets['uzsuDropDown'] = {
  createFn:FW_uzsuDropDownCreate,
};
auf?

Wie funktioniert das Zusammenspiel mit perl?

Danke.

[justme1968]

das geht alles automatisch über die modifier die hinter set, get und attr namen bei setList oder widgetOverride angegen werden können. genau so wie slider, textField, colorpicker und die anderen.

implementiert ist das in fhemweb.js und wird durch html elemente mit class fhemwidget aus fhemweb getriggert.

das drop down erscheint als default wenn sich kein anderes widget zuständig fühlt. also auch in dem fall das das ja file nicht installiert ist.

gruß
  andre

[Risiko]

Hallo.

Ok. Danke. Habe ich soweit verstanden. Könnte nun neue Widgets z.B. für Wochenprofile  "editWeekProfile", "showWeekProfile" bauen.
Wenn man nun Daten von mehreren Readings an ein Widget bekommen möchte, was wäre da der beste Weg?

Gehen würde es ja über arg oder cmd. Oder sehe ich da noch was falsch?

Code Auswählen Erweitern


<div class='fhemWidget' arg='editWeekProfile,<hier weitere Daten>' cmd='weekProfile <oder hier>' dev='MAX_FAKE_WT'></div>


Das hinter cmd kommt beim Widget ja als params an und das arg definiert das Widget selbst + weitere Attribute (vArr[1..n]).

Noch eine Frage zu den Wrappern.
Wo wären die deiner Meinung nach angesiedelt - sicherlich in perl - im Modul?

Risiko.

[rudolfkoenig]

Das neue jquery-ui benoetigt leider andere Bilder aus images, und einige Anpassungen in den bisherigen FHEM .css Dateien, damit Menu und Dialog weiterhin "normal" ausschauen. Seufz.

[justme1968]

@Risiko:ich denke man sollte keine unterschiedlichen widgets für show und edit bauen sondern das gleiche widget verwenden das eventuell einen extra parameter bekommt. schau mal ob die widgets oben nicht schon ausreichen für ein wochenprofil. in der regel sind es ja nicht für jeden tag unterschiedliche zeiten sondern die meisten schaltzeiten sind an mehreren tagen gleich und es gibt ein paar ausnahmen oder ergänzungen. auch wenn es so keine 1:1 abbildung auf das tatsächliche profil das im thermostat gesetzt wird gibt sondern hin und her konvertiert werden muss ist es so glaube ich benutzerfreundlicher da sich z.b. mit einem klick ein zeitpunkt in allen tagen ändern lässt.

bei einem tages oder sogar wochenprofil kommen recht viele daten zusammen. die würde ich nicht mehr über die argumente des fhemwidget übergeben zumal  es über den normalen longpoll/event/reding mechanismus ein paar einschränkungen gibt was die erlaubten zeichen angeht. in den beispielen oben geht noch. ist aber grenzwertig.

wichtig ist auch das es hier immer eine 1:1 zuordnung von widget zu reading gibt.

ich denke es ist besser die daten ans frontend über das neue FW_directNotify direkt per json zu übertragen. einen vorschlag wie das aussehen könnte gibt es hier: http://forum.fhem.de/index.php/topic,30909.msg245300.html#msg245300 im smartvisu thread. hier gibt es dann auch diese 1:1 zuordnung nicht mehr.

mit einem solchen wrapper der das device spezifische format von und nach ein device unabhängiges (json) format konvertiert lassen sich dann im frontend auch unterschiedliche visualisierungen einsetzen bzw. eine visualisierung dann für unterschiedliche fhem device typen.

ob die wrapper auf perl oder js seite sitzen hängt denke ich davon ob wie viel zugriff sie auf die internes der perl seite brauchen. vermutlich wird es meist die perl seite sein.

[justme1968]

@rudi:das mit den anderen bildern hängt eventuell nur mit dem anderen style zusammen. die farben der icons müssen ja zum style passen und sind bei den png nicht dynamisch sondern im über den rgb wert im file namen codiert.

wie menü und dialog ausschauen hängt denke ich auch vom style ab.

welche änderungen waren bei dir am css nötig? ich meine bei mir sehen dialog und menü mit den angehängten files vernünftig aus.

[Risiko]

@Andre.
Vielen Dank für die Ausführungen.
FW_directNotify konnte ich mir noch nicht ansehen - leider nicht so viel Zeit.
Wenn man ein  Device unabhängiges (json) Format für das frontend macht, sollte dies aber trotzdem einheitlich sein - z.B. kompatibel zu fronthem, smartVISU?!
Weiß jetzt gar nicht, ob die sich für json entscheiden haben.

Insgesamt ist da sicherlich noch Einiges zu tun - habe aber auch nicht den Überblick, gerade bei der rasanten Entwicklung des fronthem, smartVISU

Risiko.

[bgewehr]

Hallo!

Könnt Ihr Euch bitte dies hier mal ansehen, und mir Eure Gedanken dazu sagen?

http://forum.fhem.de/index.php/topic,30909.msg254644.html#msg254644

Ich will mir nicht unnötig diese Arbeit machen, wenn Ihr das alle anders seht...

Danke!

[rudolfkoenig]

Könnt Ihr Euch bitte dies hier mal ansehen

Nein, ich will nicht 1169 Beitraege durchlesen, um zu verstehen, worum es geht.

[bgewehr]

Nein, ich will nicht 1169 Beitraege durchlesen, um zu verstehen, worum es geht.

Ich habe auch nur den einen, konkreten Beitrag gemeint, der in sich eine verständliche Herangehensweise beschreibt.

Ok, vielleicht ist dies hier auch noch sinnvoll:
http://forum.fhem.de/index.php/topic,30909.msg254562.html#msg254562

Es geht um die Frage, ob wir ein bisschen UZSU an jedem device machen oder ein großes zentrales UZSU device für alle fhem Devices.

Dazu kann man doch auch mal eben seine Meinung sagen, ohne alle anderen Beiträge zu lesen!?

[rudolfkoenig]

Ich habe die beiden Beitraege gelesen, habe aber nicht genug verstanden, um daraus eine Meinung bilden zu koennen.
Ich weiss ja nicht mal genau, was man mit einem UZSU meint, ich rate nur wild herum. Und die meisten schlechten Ratschlaege kommen von falsch verstandenen Problembeschreibungen.

[Blackcat]

Uzsu meint eine universelle Zeitschaltuhr.
Wie früher diese Dinger für die Steckdose, nur jetzt eben digital und wochentagsabhängig für fhem.

Und sowie ich Andre verstanden habe kann man die an jedes fhem Objekt hängen, also müsstest du dir einen Dummy bauen der alledevices betrifft du du gleichzeitig damit steuern willst (im Extremfall alle)