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 (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
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 ;)
jquery-ui gefällt mir, das könnte auch an anderen Stellen einzug halten ;-). Mal wieder eine sehr schöne Erweiterung. Danke.
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 FW_widgets['uzsuDropDown'] = {
createFn:FW_uzsuDropDownCreate,
};
auf?
Wie funktioniert das Zusammenspiel mit perl?
Danke.
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
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?
<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.
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.
@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 (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.
@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.
@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.
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!
ZitatKönnt Ihr Euch bitte dies hier mal ansehen
Nein, ich will nicht 1169 Beitraege durchlesen, um zu verstehen, worum es geht.
Zitat von: rudolfkoenig am 31 Januar 2015, 17:20:17
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!?
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.
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)
OK, bitte entschuldigt. Ich bin davon ausgegangen, dass wir schon soweit klar sind, möchte aber gern nachholen, was ich bisher verpasst habe:
In smarthome.py gibt es eine UniverselleZeitSchaltUhr, kurz UZSU.
In fhem gibt es mit at die Möglichkeit, beliebige Zeitschaltungen zu bauen, aber kein UI für komplexe Konfigurationen.
Im Projekt fronthem versuchen wir nun, das SV (SmartVISU)-widget für UZSU, das für smarthome.py gemacht worden ist, auch für fhem nutzbar zu machen.
Wir befinden uns in einem Zustand, wo das widget in SV funktioniert und als Ergebnis der Definition des Benutzers ein JSON Objekt ausgibt in der Form:
{"active":true,"list":[{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH","time":"23:00","value":1,"active":true}]}
Dies entspricht einer aktiven Zeitschaltuhr mit einer Schaltregel an den Wochentagen Mo, Die, Mi, Do um 23 Uhr, wo das verbundene fhem-device auf 1 geschaltet werden soll.
Ich versuche im Moment herauszufinden, wie die einfachste Architektur dafür sein könnte und habe folgendes gemacht:
Ein fronthem-Converter sorgt dafür, das das JSON Objekt als Userreading 'uzsu' an das zu schaltende fhem-device hinzugefügt wird.
Ein n_uzsu notify wartet auf events von Readings, die uzsu heißen
define n_uszu notify .*:uzsu:.* { UZSU_execute($NAME, $EVTPART1) }
und ruft dann die folgende Funktion (Prototyp, bisher ohne Schleife) aus 99_whatever.pm auf:
###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
my ($device, $uzsu) = @_;
my $result = Log(1, 'UZSU execute parameters: ' . $device . ', ' . $uzsu );
$uzsu = decode_json($uzsu);
#$result = Log(1, 'UZSU execute params: ' . $uzsu->{active} . ', ' . $uzsu->{list}[0]->{rrule} );
if ($uzsu->{active}){
fhem('delete a_'.$device.'_uzsu1');
fhem('define a_'.$device.'_uzsu1 at +*' . $uzsu->{list}[0]->{time} .' {fhem "set ' . $device . ' ' . $uzsu->{list}[0]->{value}.'"}');
}
else {
fhem('delete a_'.$device.'_uzsu1');
}
}
Damit lässt sich jetzt, nach und nach die Regeln aus dem JSON abarbeiten und in at-Befehle umsetzen. Wenn die ganze Zeitschaltuhr inaktiv ist, werden alle ats gelöscht.
Sollte doch soweit gehen, ich bin aber nicht sicher, ob das der richtige Ansatz ist, daher hier meine Nachfrage.
Ich danke Euch für Eure Nachsicht und bitte erneut um Eure Aufmerksamkeit!
Ich meine das ist nicht der richtige Ansatz.
"UZSU" heisst in FHEM WeekdayTimer, wenn man das aufhuebschen will, dann muesste man (fuer FHEMWEB) die Funktionen FW_summaryFn/FW_detailFn in WeekdayTimer erstellen.
Ich habe nun das Objekt WeekdayTimer verwendet und erhalte genau das Ergebnis, das ich mir gewünscht habe.
Wenn in der UZSU mehrere Zeilen definiert wurden, dann werden auch mehrere WeekdayTimer definiert. Das ist nicht ganz optimal, aber OK, denke ich, oder?
Vielen Dank!
Vielleicht könnt Ihr noch einen Blick auf meinen Code werfen und mir noch evtl. Verbesserungsvorschläge machen?
###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
my ($device, $uzsu) = @_;
$uzsu = decode_json($uzsu);
for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
my $weekdays = $uzsu->{list}[$i]->{rrule};
$weekdays = substr($weekdays,18,50);
fhem('delete wdt_'.$device.'_uzsu'.$i);
fhem('define wdt_'.$device.'_uzsu'.$i.' WeekdayTimer '.$device.' en '.$weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value});
if (($uzsu->{active}) && ($uzsu->{list}[$i]->{active})) {
fhem('attr wdt_'.$device.'_uzsu'.$i.' disable 0');
} else {
fhem('attr wdt_'.$device.'_uzsu'.$i.' disable 1');
}
}
}
Das macht aus
{"active":true,"list":[{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA","time":"20:00","value":1,"active":true},{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA","time":"21:00","value":0,"active":true}]}
dann
define wdt_Leselampe_uzsu0 WeekdayTimer Leselampe en MO,TU,WE,TH,FR,SA|20:00|1
attr wdt_Leselampe_uzsu0 disable 0
define wdt_Leselampe_uzsu1 WeekdayTimer Leselampe en MO,TU,WE,TH,FR,SA|21:00|0
attr wdt_Leselampe_uzsu1 disable 0
Perfekt, oder?
Ich bin noch verwirrt, es klingt fuer micht verkehrt herum: du kriegst eine Zeitspezifikation aus blauem Himmel, mit dem man mehrere Weekdaytimer anlegt. Normal waere fuer mich, dass der Benutzer erst ein Weekdaytimer anlegt, und dann die Einstellungen dazu anpasst.
Das hat mit der Verwendung von SmartVISU zu tun. Dort wird von einem Zeitschalt Uhr Widget der JSON String ausgegeben. Diesen richtig zu verarbeiten war mein Ziel.
Gesendet von iPhone mit Tapatalk
ich würde die einzelnen zeilen in den gleichen WeekdayTimer stecken. das problem dabei ist nur das man dann nicht selektiv disable setzen kann.
was auch noch fehlt ist einen bestehenden timer zu ändern statt neue zu erzeugen. in zusammenhang damit steht auch das zur zeit nur die angabe von festen zeitpunkten möglich ist. ein auf sunrise oder sunset basierender zeitpunkt würde verloren gehen wenn wir nicht im json eine kodierung dafür vorsehen.
da vermutlich die meisten schaltzeiten relativ zum sonnenauf- oder -untergang definiert werden halte ich das für sehr wichtig.
Hallo zusammen,
ich bin ja mehr als glücklich darüber, daß sich jemand dieses Themas annimmt. (> 40 weekday - timer manuell zu pflegen ist halt auch eine Aufgabe :) )
Vielleicht könnte man auch noch eine Lösung für die <condition> finden z.B. ein Devicestate true/false. Ich bräuchte das z.B. für die Jalousieen als Sperrobjekt, damit diese nicht runterfahren wenn die Terrassentür offen ist :)
vG
Wolfgang
Zitat:
Ich bräuchte das z.B. für die Jalousieen als Sperrobjekt, damit diese nicht runterfahren wenn die Terrassentür offen ist :)
Ich werte dazu aus:
1. Einen Türkontakt
2. einen auf der Terrasseinstallierten BWM.
3. Die Außenbeleuchtung
und erst wenn alle drei ok sind, wird das Rollo an der Terrassentür heruntergefahren, ansonsten wird der Auftrag um 10 Minuten verzögert erneut gestartet.
Aussperren gehört der Vergangenheit an.
Also für die Conditions kann man was vereinbaren, das ändert sich ja nicht sooo oft. Ein direktes Frontend ist dann ja vielleicht nicht nötig. Man könnte in SmartVISU die Zeiten konfigurieren und am fronthem Converter den String der Conditions als Parameter hinzufügen. Mal sehen.
Was die Sonne anbelangt, bin ich einen Schritt weiter gekommen.
Die SA+ Auswahl z. B. macht aus SA+ 00:30 ein {sunrise(1800)} als Zeit für die Regel. Zur Auswahl stehen --, SA+, SA-, SU+, SU-. Das könnte reichen, oder?
Gesendet von iPhone mit Tapatalk
Mal davon ab, der kundige Nutzer kann dies auch einfach genauso in das Time-Feld schreiben, würde auch funktionieren. Meint Ihr, dass das genügen würde?
Gesendet von iPhone mit Tapatalk
Hallo bgewehr,
das mit SA / SU paßt IMHO.
Conditions und der kundige Nutzer ;D ...
naja grundsätzlich das ist erst mal kein Problem, es hilft mir schon erst mal die weekday-timers zu organisieren.
Spätere Erweiterungen sind ja dadurch nicht ausgeschlossen.
vG
Wolfgang
Zitat von: justme1968 am 23 Januar 2015, 14:21:01
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.
Hallo,
ich wollte die widgets mal ausprobieren und bekomme es auch im Raum per webCmd und in der detail ansicht zum Laufen. Nun wollte ich eine ReadingsGroup bauen, aber das bekomme ich einfach nicht hin.
Mein Dummy (mit notify für die Readings):
--------------------------------------------------------------------------------
define XX.xx.RA.Player.Helper dummy
attr XX.xx.RA.Player.Helper setList DG.sz.RA.Player_sync:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player DG.wz.RA.Player_sync:uzsuSelect,DG.sz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player OG.ba.RA.Player_sync:uzsuSelect,DG.wz.RA.Player,DG.sz.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player OG.ez.RA.Player_sync:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,DG.sz.RA.Player,OG.ku.RA.Player OG.ku.RA.Player_sync:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,DG.sz.RA.Player
attr XX.xx.RA.Player.Helper webCmd DG.wz.RA.Player_sync
define XX.xx.RA.Player.Helper.not notify XX.xx.RA.Player.Helper:.* setreading XX.xx.RA.Player.Helper $EVENT Der Versuch einer ReadingsGroup:
define XX.xx.RA.Player.Helper.RG readingsGroup XX.xx.RA.Player.Helper:OG.ez.RA.Player_sync\
XX.xx.RA.Player.Helper:DG.wz.RA.Player_sync\
XX.xx.RA.Player.Helper:DG.sz.RA.Player_sync,!test\
attr XX.xx.RA.Player.Helper.RG commands { 'test' => 'DG.sz.RA.Player_sync:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player'} Was muss ich tun, um die Widgets in die ReadingsGroup zu bekommen?
Vielen Dank
Ronny
wie bei setList: vor dem : muss der name des readings stehen. nicht der device name.
attr XX.xx.RA.Player.Helper.RG commands { 'test' => 'test:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player'}
gruss
andre
Das hatte ich auch schon erfolglos probiert. Ich habe es dann mit einem anderen Dummy hinbekommen in dem ich das state-reading verwendet habe. Ich bekomme es aber leider nicht für einen Dummy mit mehreren Readings wie in meinem Beispiel hin...
das ist völlig unabhänig von der anzahl der readings.
define dd dummy
attr dd room rg2
define rg2 readingsGroup dd:r1,r2
attr rg2 commands { r1 => 'r1:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player', r2 => 'r2:uzsuSelect,a,b,c,d', }
attr rg2 room rg2
wie sieht es bei dir im browser aus? ist im log etwas zu sehen?
gruss
andre
Hallo André,
ich finde das super was du hier mal wieder machst. Mich würde nun interessieren wann diese Sachen denn regulär über das Update kommen?
Vielen Dank.
Gruß Daniel
so bald es geht :)
zur zeit hängt es noch am jquer-ui update und am handling der styles dafür.
gruss
andre
Zitat von: justme1968 am 04 Februar 2015, 15:53:00
das ist völlig unabhänig von der anzahl der readings.
define dd dummy
attr dd room rg2
define rg2 readingsGroup dd:r1,r2
attr rg2 commands { r1 => 'r1:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player', r2 => 'r2:uzsuSelect,a,b,c,d', }
attr rg2 room rg2
wie sieht es bei dir im browser aus? ist im log etwas zu sehen?
gruss
andre
Ich habe das Problem eingrenzen können: das Widget funktioniert in der ReadingsGroup nicht, wenn im Namen des Readings ein Punkt (.) drin ist - das benötige ich aber leider...
das liegt nicht am widget sondern war ein problem in der readingGroup und hat alle command mappings betroffen.
ist ab morgen behoben.
gruss
andre
Hallo zusammen,
ich wollte mal vorsichtig nachfragen, ob sich an der UZSU - Front etwas getan hat.
vG
Wolfgang
Für diejenigen, die SmartVISU verwenden, ja. Dort ist es soweit gediehen, dass bis auf Sunrise und Conditions schon mal alles läuft. Siehe dazu den fronthem Thread und http://GitHub.com/herrmannj/fronthem
Hallo,
ich habe die UZSU nach der Anleitung im Wiki eingerichtet (http://www.fhemwiki.de/wiki/Fronthem#Universelle_ZeitSchaltUhr_UZSU (http://www.fhemwiki.de/wiki/Fronthem#Universelle_ZeitSchaltUhr_UZSU)). D.h. ich habe die uzsu_widget.hrml in meinen pages-Ordner kopiert, die visu.js und die visu.css angepasst und folgendes in meine index.html geschrieben:
{% import "widget_uzsu.html" as visu %}
{{ visu.uzsu_icon('UZSUnum', gad_uzsu, '', '', '', '', 'bool', 'an', 'aus') }}
Das Icon mit der Uhr wird zwar jetzt angezeigt, allerdings öffnet sich das Popup beim Anklicken nicht. Leider finde ich den Fehler nicht.
Gruß, Sascha
Das Icon wird erst aktiv, wenn das fhem-device ein Reading uzsu besitzt. Du musst dieses Reading manuell anlegen mit setreading <device> uzsu {}
Außerdem musst Du das UZSU notify anlegen, wie im Wiki beschrieben.
Das FHEM device muss dann mit dem UZSU Converter aus der 99_fronthemUtils.pm an das uzsu Reading set und get gekoppelt werden. Dann geht's!
ich habe jetzt in diesem Verzeichnis /opt/fhem/www/fronthem die Datei 99_FronthemUtils.pm mit dem zweiten Code aus dem Wiki, und in diesem Verzeichnis /opt/fhem/FHEM die Datei 99_FronthemUtils.pm mit dem ersten Code.
In meiner fhem.cfg habe ich folgendes:
##########
#UZSU
#
define Garten_Zeitschaltuhr dummy
attr Garten_Zeitschaltuhr room Garten
define UZSU notify .*:uzsu:.* { UZSU_execute($NAME, $EVTPART1) }
#
##########
das zusätzlich Reading bei Garten_Zeitschaltuhr habe ich angelegt und ist auch eingetragen.
Das Popup erscheint weiterhin nicht. Auch erscheint kein UZSU-gad in meiner gad-Liste.
Gruß, Sascha
Die 99_fr... gehört NUR in FHEM!
Du darfst nicht ,gad_uzsu , schreiben! ALLE Parameter gehören in Anführungszeichen! Also ,'gad_uzsu', wobei ich Dir zu spezifischeren Namen raten würde, eher WZ.Deckenlampe.uzsu oder so.
Muß 99_fronthemUtils.pm klein oder 99_FronthemUtils.pm groß geschrieben werden. Im Wiki ist es groß geschrieben. Du schreibst es klein.
Wie ist denn dann folgendes zu verstehen wenn ich die Datei nur einmal brauche?:
Auszug aus dem Wiki:
3. folgenden Code in der 99_FronthemUtils.pm:
Im Package Main:
-----CODE-----
Im Package fronthem, selbe Datei:
-----CODE-----
So den Eintrag in meiner index.html habe ich jetzt wie folgt geändert.
{% import "widget_uzsu.html" as visu %}
{{ visu.uzsu_icon('UZSUnum','garten.zeitschaltuhr.beleuchtung', '', '', '', '', 'bool', 'an', 'aus') }}
Jetzt habe ich das Gad auch in miner Liste, kann aber bei Converter nicht UZSU auswählen (gibt es nicht).
Gruß, Sascha
Edit: Da ich gerade die komplette 99_fronthemUtils.pm im Git gefunden habe, habe ich jetzt verstanden was es mit Package Main und Package fronthem auf sich hat. Soweit habe ich jetzt alles am Laufen.
Hallo,
mal eine kleine Frage zwischendurch. Ist das Widget jetzt in FHEM verfügbar, oder noch in der Entwicklung? Ich würde es gerne benutzen, es sieht ja eigentlich fertig aus. Zumindest das optische auf den screenshots ;-)
es ist noch nicht eingecheckt weil fhem nich nicht auf die neue jquery ui version aktualisiert ist.
du kannst aber die files von oben runterladen und verwenden. die vertragen sich mit der aktuellen fhem version.
gruß
andre
Ich mag mich etwas blöd anstellen, die Installation klappt leider nicht :-D
Habe die fhemweb_uzsu.js nach fhem/www/pgm2/ kopiert.
Das Verzeichnis jquery-ui-1.11.2.custom ist unter fhem/www/ kopiert. (Oder muss auf diesem Archiv nur die jquery-ui.js nach www/pgm2 kopiert werden?
jquery-ui styles habe ich nicht direkt gefunden, oder sind das die css files aus dem Archiv file? Wohin damit?
Hallo,
ich habe noch ein kleines Problem mit dem UZSU-Widget. Die Einrichtung unter Smartvisu und Fhem scheint soweit in Ordung und vom Grundsatz her funktioniert auch alles. Allerdings wird das Device zur gewählten Uhrzeit nur angeschaltet (auf 1 gesetzt) und dann aber nicht zum nächsten Zeitpunkt ausgeschaltet (auf 0 gesetzt).
Im Weekdaytimer wird der state zum Zeitpunkt richtig auf 0 gesetzt allerdings wird es nicht auf das zu schaltende Dvice übertragen. D.h. der state des Device bleibt auf 1.
So sieht der von UZSU angelegt Eintrag in der fhem.cfg aus:
define wdt_Garten_Zeitschaltuhr_uzsu WeekdayTimer Garten_Zeitschaltuhr en TU,WE,TH|11:45|1 TU,WE,TH|11:50|0 MO,TU|14:40|1 MO,TU|14:45|0 SA|19:43|1 SA|20:00|0
Was kann das sein?
Gruß, Sascha
Ist mir auch schon aufgefallen, dass Value 0 ein Problem ist. Halte ich für einen Fehler im WeekdayTimer...
wie kann ich denn dann das UZSU-Widget nutzen wenn ich damit das Device nicht mehr auschalten kann?
Gruß, Sascha
Kommt ja aufs Device an, für Rolläden reicht ja 1 für oben und bei Schaltern gibt's ja Off...
ließe sich nicht noch eine Option in das Widget einbauen in der sich on und off über einen Switch einstellen lassen. Also quasi wie bei bool mit 0 und 1.
Dann ist mir noch aufgefallen, daß bei folgender Definition in Smartvisu {{ visu.uzsu_icon('UZSUnum', gad_uzsu, '', '', '', '', 'bool', 'an', 'aus') }} im Switch statt "aus" "undefined" steht. Bei "an" steht es richtig im Switch
Gruß, Sascha
Es muss heißen ...,'list', 'on,off')}}, dann geht's!
setzte mal an und aus in eckige Klammern... dann sollte es gehen...
'bool', ['an', 'aus'])
Gruß Kai
@Kai: Danke, das behebt den Fehler mit dem "undefined". Vielleicht sollt man das dann noch im Wiki unter Fronthem korrigieren.
@begewehr.: Auch Danke. Besser als "text" -> aber ein Flip wäre noch schöner... vielleicht wird ja mal der WeekdayTimer korrigiert um dann wieder "bool" nehmen zu können. Die Version 2.85 ist übrigens sehr gut geworden - insbesondere die Möglichkeit mit dem Sunset/Sunrise.
Gruß, Sascha
Zitat von: Cybers am 26 März 2015, 14:59:02
... vielleicht wird ja mal der WeekdayTimer korrigiert um dann wieder "bool"
Das fhem-wdt-Update von heute soll den Fehler mit dem 0-value im WDT beheben. Probier's mal aus, bitte!
Zitat von: bgewehr am 29 März 2015, 15:10:06
Das fhem-wdt-Update von heute soll den Fehler mit dem 0-value im WDT beheben. Probier's mal aus, bitte!
seit dem Update von WeekdayTimer ist das Problem mit dem 0-Wert behoben.
Gruß, Sascha
Hab eine aktuelle jquery version eingecheckt (1.11.2), samt aktuellen jquery-ui (1.11.4), und default/brightstyle/darkstyle etwas angepasst, damit Dialoge in etwa so wie die bisher ausschauen.
@andre: willst du fhemweb_uzsu.js einchecken, und mir ein patch fuer die Doku in 01_FHEMWEB.pm schicken? Kannst du mir sagen, welche Styles man verwenden sollte, damit es "ordentlich" ausschaut?
Ich werden als naechstes das Umorganisieren der Styles (Stichwort Unterverzeichnis) in Angriff nehmen.
sehr schön. danke.
die widgets checke ich ein und die doku kommt.
ich habe bis jetzt UI darkness verwendet. das ist auch auf den screenshots am anfang zu sehen. zum darkstyle passt das glaube ich ziemlich gut.
für die anderen fhem styles habe ich nicht nicht gesucht. aber wenn man auf der jqueryui themes seite in der gallery jeweils ein halbwegs passendes anklickt und dann auf roll your own zurück geht kann man von hand noch korrigieren was nicht zum fhem style passt und dann das ganze als style runter laden. das wären dann die files für die unterverzeichnisse.
Ich kenne die fhem UZSU Lösung leider noch nicht, aber vorab die Frage, wie Ihr mit Ferien und Feiertagen umgeht? Habt Ihr da schon eine Lösung?
Im GIt von mworion zur UZSU für SmartVISU (http://GitHub.com/mworion ) haben wir inzwischen einen stabilen Stand (RC3 im develop Branch), der auch schon Sunrise und Sunset vollständig verarbeiten kann, wie ist das hier gelöst?
anbei ein vorschlag für den commandref patch.
vermutlich wäre eine darstelung mit mehr beispielen und screenshots bald besser als die lange liste der möglichen widgets.
bei setList für dummys und readingsProxy wäre es vermutlich gut auch auf die möglichen widgets zu verweisen.
die widgets habe ich eben eingecheckt. aber ohne die styles ist die darstellung von uzsuToggle, uzsuSelect und uzsuSelectRadio noch schlecht. die aktiven buttons sind so gut wie gar nicht von den inaktiven zu unterscheiden. wie sollen wir hier weiter vorghen ?
@bgewehr: die fhemweb widgets sind zur zeit erst mal nur das frontend. zur zeit auch noch ohne die json nachricht. das uzsu device als backend wollte jörg angehen :). er wollte auch das format für sunrise und sunset in der json nachricht später erst festlegen. wenn ihr da schon was habt: wo genau finde ich die beschreibung?
gruss
andre
Zitatbackend wollte jörg angehen
verd.... ich dachte ich wär da raus. Mist. ;) Irgendwie bin ich da out-of sync. Na dann muss ich mal fix ...
jetzt, ich erinnere mich... ich wollte das Backend bauen und weil Bernd das dann über den weekdaytimer gemacht hat habe ich mich wieder hin gelegt.
Ich schreibe ein device:
Auf der einen Seite muss es zum sv-uzsu passen. (@Bernd: da kann ich mich an der fronthemUtils im git orientieren ?) Dann lass ich Platz für das JSON für fhemweb, am besten ein hash mit den Inhalten und eine sub dazu die das kapselt - dort übernimmst Du das Andre um das fhemwidget "einzupassen" ?
Würde das passen ? fhem device name "uzsu" ?
vg
jörg
so in etwas hatte ich mir das vorgestellt. ja.
wenn der weekdaytimer aber für euch funktioniert kann ich mich auch da dran hängen. das wollte ich sowieso uns unsbhängig von einem neuen device noch machen.
gruß
andre
ich hab das nicht im Einsatz. Ein dediziertes device kann schon besser sein, mal schauen was Bernd oder andere dazu sagen. Gibt es Defizite die durch ein spezielles device gelöst werden können ?
vg
jörg
Ganz kurz die aktuelle Architektur:
Im Frontend (SmartVISU) wird eine UZSU-Schaltfläche zu einem Device (Lampe, Rollladen) zugefügt.
Im Backend (fhem) wird dem entsprechenden Device (Lampe, Rollladen) ein User-Reading uzsu einmalig manuell hinzugefügt und mit {} initialisiert.
Im Frontend Interface (fronthem) wird über einen Converter "UZSU" das Ergebnis der Benutzerkonfiguration im Frontend als strigified JSON in das Reading uzsu des passenden fhem-Device geschrieben oder eben daraus gelesen. Damit ist die UZSU Einstellung persistent gesichert, absturz- und neustartsicher und leicht wieder zu finden.
Ein fhem notify wacht über *uzsu* events und erzeugt aus dem jeweiligen JSON-String einen Weekdaytimer UZSU_devicename, der die Einstellungen aus dem JSON erhält.
(Einziger Wermutstropfen: Änderungen an den UZSU-Settings, die durch einen Neustart ohne vorheriges save in den WDT verloren gegangen sind, sind zwar im uzsu-reading der devices gespeichert, aber sie müssen durch erneuten Aufruf der betroffenen UZSU im frontend in die WDT aktualisiert werden. Es ist also ein inkonsistenter Zustand nach Absturz/Neustart möglich, der manuell behoben werden muss/kann. Nicht schön, aber für mich auch nicht schlimm, da kein Datenverlust.)
Hier der notify:
define UZSU notify .*:uzsu:.* { UZSU_execute($NAME, $EVTPART1) }
Die Funktion USZU_execute() macht dann daraus Weekdaytimer:
use JSON;
###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
my ($device, $uzsu) = @_;
$uzsu = decode_json($uzsu);
fhem('delete wdt_'.$device.'_uzsu');
my $weekdays_part = " ";
for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
my $weekdays = $uzsu->{list}[$i]->{rrule};
$weekdays = substr($weekdays,18,50);
if (($uzsu->{list}[$i]->{active})) {
$weekdays_part = $weekdays_part.' '.$weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value};
}
}
fhem('define wdt_'.$device.'_uzsu'.' WeekdayTimer '.$device.' en '.$weekdays_part);
if ($uzsu->{active}){
fhem('attr wdt_'.$device.'_uzsu disable 0');
} else {
fhem('attr wdt_'.$device.'_uzsu disable 1');
}
}
Das läuft jetzt schon länger stabil bei mir und ist simpel.
Mit der offiziellen Version 2.0 der SV-UZSU kann zeitgesteuert geschaltet werden. Man kann bool, numeric oder list als Werteselektoren verwenden, jeweils mit einigen Parametern.
Mit dem Release Candidate 3.0 kann auch Sunrise und Sunset mit min, max und offset geschaltet werden. Dazu wurde der JSON-String erweitert so dass es leicht fällt, aus den JSONS wieder WDT zu erstellen.
Nun soll auch noch eine Lösung für Feiertage und Ferien her, was mit der letzten Erweiterung des WDT (Tage 7 und 8) nun leicht möglich sein sollte. Dies wird erst nach Veröffentlichung der Version 3 des SmartVISU UZSU-Widgets erfolgen.
JSON-String aus RC3:
{"active":true,"list":
[{"value":"0","time":"07:00<sunrise","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","active":true,"event":"sunrise","timeCron":"sunrise","timeMin":"07:00","timeMax":"","timeOffset":""},
{"value":"0","time":"09:00<sunrise","rrule":"FREQ=WEEKLY;BYDAY=SA,SU","active":true,"event":"sunrise","timeCron":"sunrise","timeMin":"09:00","timeMax":"","timeOffset":""},
{"value":"100","time":"20:00<sunset","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","active":true,"event":"sunset","timeCron":"sunset","timeMin":"20:00","timeMax":"","timeOffset":""},
{"value":"100","time":"21:00<sunset","rrule":"FREQ=WEEKLY;BYDAY=SA,SU","active":true,"event":"sunset","timeCron":"sunset","timeMin":"21:00","timeMax":"","timeOffset":""}]}
Dieser String definiert die UZSU aus dem Bildanhang.
Damit die Surise Daten ausgewertet werden können, muss die UZSU_execute() entsprechend angepasst werden:
###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
my ($device, $uzsu) = @_;
$uzsu = decode_json($uzsu);
fhem('delete wdt_'.$device.'_uzsu');
if ($uzsu->{active}){
my $weekdays_part = " ";
for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
my $weekdays = $uzsu->{list}[$i]->{rrule};
$weekdays = substr($weekdays,18,50);
if (($uzsu->{list}[$i]->{active})) {
if ($uzsu->{list}[$i]->{event} eq 'time'){
$weekdays_part = $weekdays_part.' '.$weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value};
}
else {
$weekdays_part = $weekdays_part.' '.$weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',"'.$uzsu->{list}[$i]->{timeMin};
if ($uzsu->{list}[$i]->{timeMax}) {
$weekdays_part = $weekdays_part.'","'.$uzsu->{list}[$i]->{timeMax};
}
$weekdays_part = $weekdays_part.'")}|'.$uzsu->{list}[$i]->{value};
}
}
}
fhem('define wdt_'.$device.'_uzsu'.' WeekdayTimer '.$device.' en '.$weekdays_part);
fhem('attr wdt_'.$device.'_uzsu room UZSU');
}
}
Damit werden dann die {sunrise_abs(...)} usw richtig gebildet.
Nächster Schritt ist die Einführung des Feiertags/Ferientags in V>3.0.
Siehe dazu auch http://github.com/mworion das USZU-Repo.
Mehr Aufwand mit noch mehr fhem Devices würde ich eigentlich nur ungern treiben... was meint Ihr?
Hi,
ich kann da gut mit leben andere Sachen zu machen. Plots und so :)
vg
jörg
Zitatanbei ein vorschlag für den commandref patch.
Eingecheckt.
Zitatvermutlich wäre eine darstelung mit mehr beispielen und screenshots bald besser als die lange liste der möglichen widgets.
Sowas kann man in der fhemwiki machen. Ich sehe eher zwei andere Baustellen, wozu ich aber noch keine konkreten Ideen habe: Abspaltung der widget-Beschreibung in einem separaten Dokument (doch eine Idee: hinten in den .js Dateien, analog zu den perl Modulen), und Aufspaltung der commandref, der wg. der 1.5MB selbst auf schnelleren Rechner eine merkbar lange Zeit zum Laden braucht. Allerdings kann man dann nicht mehr so einfach suchen.
Zitat von: rudolfkoenig am 09 April 2015, 10:22:54
... Aufspaltung der commandref, der wg. der 1.5MB selbst auf schnelleren Rechner eine merkbar lange Zeit zum Laden braucht. Allerdings kann man dann nicht mehr so einfach suchen.
<leicht off-topic>
Das mit der Suche hat noch eine andere Seite: viele (Such-)Begriffe tauchen bei mehreren Modulen auf und es passiert mir immer mal wieder, dass ich bei den Treffern dann nochmal "überprüfen" muss, ob ich wirklich noch in der Beschreibung zum "richtigen" Modul bin.
Das lässt sich allerdings seit ein paar Wochen (Monaten?) durch die Aufspaltung der Hilfe im Frontend (die möglicherweise vielen Benutzern noch nicht so geläufig ist) mittlerweile ganz gut handhaben.
<back-to-topic>
Peter
Wollte einfach mal Danke sagen für dieses Widget! Benutze es mit fronthem/smartVISU. Es in Betrieb zu nehmen hat einigermaßen gut funktioniert und ich konnte einen ganzen Haufen alter "at"s einfach löschen und jetzt mit der Zeitschaltuhr komfortabel ersetzen.
Super!
Was ich noch nicht so gut finde, ist dass vieles an unterschiedlichen Stellen liegt und steht:
- es gibt das mworion repo, dort ist wenn ich es richtig sehe die aktuellste Version vom Widget
- es gibt das repo von hermannj, dort gibt es auch das Widget, allerdings älter (?)
- ebenfalls von hermannj gibt es das fronthem repo, dort findet man eine Version der fronthemutils, die evtl. zu einem der beiden Widgets passt?
- dann gibt es hier im Thread gepostet Code für die Funktion UZSU_execute, die zur aktuellsten Version aus dem mworion repo passt, aber vermutlich nicht zu der im repo von herrmannj?
- dann gibt es einen Wiki-Eintrag, wo man auch Code findet, wo man dann durch sehr genaues lesen herausfinden kann, welche Version zu was passt. Die UZSU_execute zur aktuellsten Version vom Widget findet man aber scheinbar gar nicht in irgendeinem repo?
Die vielen Fragezeichen am Ende der Punkte sollen andeuten, dass ich mir das alles so denke, aber nicht sicher bin ;) Um das zu tun, muss man das Wiki lesen, hier den Thread lesen, und idealerweise noch einiges aus anderen smartVISU-Threads im Hinterkopf haben.
Ich fände es gut wenn man den ganzen Code der zu dem Widget gehört (inclusive dem, was in die fronthemUtils muss) in EIN repo packt und dort pflegt, und in einer ebenso dort abgelegten Datei beschreibt, was wo hin muss.
Mindestens sollte man den Code aus dem Wiki entfernen, denn der ist quasi per Definition veraltet, sobald jemand was in eins der Repos eincheckt. Es würde eigentlich reichen wenn man im Wiki die Repos und die readme verlinkt, und evtl. ein paar Beispiele hineinpackt, ähnlich wie es in der FHEM commandref gemacht ist.
Stimmt, da müssen wir mal Ordnung schaffen, ist irgendwie gewachsen.
Eins aber möchte ich noch graderücken:
Im fronthem Repo ist die aktuell releaste V2.0 der UZSU abgelegt, die ist stabil und intensiv getestet.
Die hier angesprochene V 2.94 oder der RC 3.0 ist develop, also teilweise ungetestet und nicht offiziell released. Daher die vielen Versionen, die hier und da rumschwirren. Dieses hier ist ein Developer Thread, deswegen reden wir hier über Developer Versionen! Den code im Wiki nehme ich am WE raus!
Hallo zusammen,
für meine Wochenprogramme möchte ich die uzsu verweden mit folgenden Einstellmöglichkeiten:
uzsuSelect,Wochentage
uzsuDropDown,Uhrzeit in 15 Minuten Abstufungen
uzssuToggle,Tag,Nacht
Mehrere Einträge
Bekomme ich das mit dem uzsu so hin? Habe nun schon einiges ausprobiert, im Prinzip müsste ja nur bei uzsu das enable,disable gemappt werden und die Uhrzeit verfeinert.
Grüße
igami
Im Dev 3.1 GitHub vom MWorion ist es wieder möglich, den Flip mit Textausgabe zu definieren, damit z. B. Homematic Schalter direkt mit on bzw. off versorgt werden können.
https://github.com/mworion/uzsu_widget/issues/13#issuecomment-122026789
Wer kann das mal testen?
Zitat von: bgewehr am 16 Juli 2015, 20:34:08
Wer kann das mal testen?
Funktioniert perfekt.
Ich habe es auch gerade eingebaut. Läuft super.
Damit kann ich jetzt sogar meine Jalousien-Zeitsteuerung über das UZSU-Widget mit verschiedenen Prozentwerten realisieren.
Der WAF von Smartvisu hat sich wieder erhöht...
Gruß, Sascha
Hallo, ich habe festgestellt, dass der neue Code für die UZSU_execute das Deaktivieren einer UZSU im SV nicht mehr korrekt in fhem umsetzt, das wdtdevice bleibt aktiv. Erwarten würde ich ein inaktives wdt mit den richtigen Zeiten usw. Also wundert Euch nicht! Der Zweig if UZSU active false muss noch ausgebaut werden! Wer hat Zeit (ich grade nicht)...?
Edit:
Ich hab's vom Handy aus gemacht:
https://github.com/herrmannj/fronthem/pull/11
Bitte um Tests und Bestätigung!
Zitat von: bgewehr am 19 Juli 2015, 12:04:24
Bitte um Tests und Bestätigung!
Funktioniert. Dem wdt device wird das Attribut disable 0/1 zugeweisen, wenn das gesamte UZSU aktiviert/deaktiviert wird. Das gleichnamige Reading wird ebenfalls aktualisiert.
Ok, danke!
@Jörg kannst Du bitte den PR mergen?
done. thnx
Hallo Zusammen,
zuerst einmal Kompliment und Danke für die bisher geleistete Arbeit hier.
Dank dem UZSU widget kann ich nun sehr komfortabel meine WeekdayTimer auch über SmartVisu bearbeiten. Doch leider bietet das widget ja (noch?) keine Möglichkeit die UZSU_WeekdayTimer mit Conditions zu verknüpfen. Deshalb helfe ich mir mit folgendem kleinen Workaround:
Die "Conditions" speichere ich 1zu1 in einem Reading (wdt_condition) und übergebe den Inhalt an die UZSU_execute()
Dazu wird das UZSU notify wie folgt erweitert:
define UZSU notify .*:uzsu:.* { UZSU_execute($NAME, $EVTPART1, ReadingsVal($NAME,"wdt_condition"," ")) }
die ersten Zeilen der UZSU_execute funktion in der 99_fronthemUtils.pm entsprechend angepasst:
sub UZSU_execute($$$)
{
my ($device, $uzsu, $condition) = @_;
sowie der Befehl zum Erstellen der WDT:
fhem('defmod wdt_uzsu_'.$device.' WeekdayTimer '.$device.' en '.$weekdays_part.' '.$condition);
Funktioniert bisher problemlos.
Gruß, Michael
Hallo, Michael!
Ich arbeite zusammen mit MWorion daran, die Bedingungen im UZSU Frontend editierbar zu machen.
Dein Ansatz hat einen deutlichen Nachteil, glaube ich: Du kannst nur eine Bedingung pro WDT definieren.
Das reicht vermutlich für viele Fälle, aber nicht für alle.
Deswegen wollen wir die Conditions in jeder Zeile separat pflegbar machen und in den commandstring der wdt Profile aufnehmen.
Damit kann dann jeder Schaltbefehl die gleiche oder auch andere Bedingungen haben.
Es würde helfen, wenn Du Deine Verwendung beschreiben könntest. Welche Bedingungen sind für Dich wichtig?
Stimmt, mein Ansatz erlaubt nur eine Bedingung bzw Bedingungskette pro WDT.
Das reicht, zumindest bei mir, z.Zt. in ca 90% der Fälle.
Die Conditions pro Zeile im UZSU Frontend zu verwalten ist ein guter Weg. Ideal wäre, wenn es keine vordefinierten Bedingungen gäbe, sondern individuell mittels Textfeld verwaltet werden (analog zu meinem Workaround reading). Würde für Euch Entwickler aber auch mehr Aufwand bedeuten hinsichtlich der Prüfung der Conditions auf mögliche Fehler. Vielleicht sollte man diese Möglichkeit auch nur in der Expertenansicht haben.
Zur Zeit setze ich die WDT für einfache sich wiederholende Schaltvorgänge ein, wie z.B. Licht zu bestimmten Zeiten an bzw ausschalten, aber nur wenn jemand Zuhause ist. Oder die Heizung im Arbeitszimmer hochzufahren, aber nur Mo-Fr, wenn ich ich Zuhause bin - kein Feiertag ist -keine Ferien/Urlaub sind. Standardkram halt.
Gruss,Michael
Also verwendest Du mehrere verkettete Bedingungen für eine UZSU?
Wir haben aktuell vorgesehen, drei Felder einzusetzen. Device, Komparator (< = > !=) und Wert.
Damit kann man aber keine Verkettungen machen.
Reicht der Ansatz nicht, müssen wir uns mehr einfallen lassen...
Ein weiterer Ansatz ist die Verkettung der Bedingungen in einem Dummy in fhem, dessen Wert dann für die UZSU verwendet wird.
Damit hat man sicher alle Möglichkeiten, da fhem ja darin sehr mächtig ist, Werte mit Bedingungen zu ermitteln.
In der UZSU würde dann nur der Status des einen Device abgefragt, dann reichen unsere drei Felder.
Was meint Ihr, ist das ein Plan?
Vereinzelt verwende ich schon mal mehrere verkettete Bedingungen und diese zum Teil auch noch UND|ODER verschachtelt.
Wie genau habt Ihr Euch bei den 3 Felder die Umsetzung für die Device Auswahl vorgestellt?
Wollt Ihr alle FHEM Devices in einer Liste anzeigen? Die dürfte unter Umständen ziemlich lang und 99% davon wohl auch nie benötigt werden.
Eventuell könnte man die Auswahl auf die Devices beschränken, die über ein entsprechendes Reading oder Attribut verfügen.
Auch die Auslagerung der Verkettungen in einen Dummy wäre ein gangbarer Weg.
Und wenn dann im Profimodus die Conditions auch direkt im Textfeld bearbeiten werden können, hätte man die volle Flexibilität.
Ehrlich gesagt hatten wir an Textfelder gedacht, nix Auswahl.
Devicename, komparator und Value als Listen zu gestalten wäre sehr fhem spezifisch und die UZSU ist für fhem UND smarthome.py.
Die drei Felder würden im Expert Bereich pro Zeile angezeigt.
Wenn ein Dummy die Verkettungslogik abbildet, muss dessen Logik in fhem bearbeitet werden, nicht in der UZSU.
Die Ansätze sind noch für beide Welten akzeptabel.
Könnt Ihr damit leben?
Textfelder sollten reichen.
Einen Vorschlag hätte ich aber noch :)
Man könnte im "Device" Feld ja die Möglichkeit einfacher Verkettungen anbieten.
Verketten kann man nur 2 (oder maximal 3) Devices die den gleichen Wertetyp liefern (0|1, true|false, present|absent, usw) und es sind nur einfache Verkettungen möglich, also keine UND/ODER Verschachtelungen.
Die Eingabe könnte wie folgt aussehen:
Device1&&Device2 bzw Device1||Device2||Device3
Ich denke damit wäre ein Großteil der Verknüpfungen abgedeckt ohne jedesmal einen separaten Dummy erstellen zu müssen.
Hm. Würde bedeuten, die Inhalte der Felder parsen und interpretieren zu müssen. Ist was für Version 5, einverstanden? Erst mal beginnen...
Version 5 nicht unbedingt.
Vorschlag:
Ihr setzt die Conditions im UZSU Frontend so um wie von Euch angedacht, also 3 Textfelder.
Die Funktion für die 99_fronthemUtils zum prüfen und auswerten der Werte sowie der Erstellung des ConditionString liefere ich.
In der UZSU_execute parst ihr die 3 Werte einfach an die Funktion und bekommt den ConditionString zurückgeliefert.
Vorteil der separaten Funktion wäre, das die (Weiter)Entwicklung losgelöst von Eurem Code laufen könnte, solange an der Grundstruktur der 3 Textfelder nichts geändert wird.
Hi,
wäre es nicht besser die conditions komplett in fhem abzubilden ? Mit diesen Vorschlägen wird ja doch (mMn!) eine ganze Menge "Programmierung" in das frontend gezogen ?
Vielleicht liese sich das so lösen das man an die USZU einen (in fhem frei definierten) Satz von Möglichkeiten gibt. Also zum Beispiel "an Schultagen", "in den Ferien", "im Urlaub", "zur Weihnachtszeit", "im Sommer bei schönem Wetter" ...
Was dann "zur Weihnachtszeit" bedeutet könnte (sollte) in fhem vom user aus-programmiert werden ...
vg
joerg
Hallo Jörg,
Soviel mehr an Code sehe ich da nicht, denn auch bei Deinem Vorschlag muss das ganze ja im Frontend verarbeitet werden. Der Ansatz mit den 3 Textfelder halte ich für einen gangbaren Weg mit überschaubarem Programieraufwand. Durch die Textfelder bleibt das ganze auch flexibel und erweiterbar.
In der von mir angedachten Funktion könnte dann z.B. auch geprüft werden, ob das Device denn überhaupt existiert oder ob der Operator (eq, le, ne, <, =, >, etc) stimmt.
Gruss
Michael
Hi Michael,
ne, ich dachte daran das dass im Backend verarbeitet wird. Muss es mMn sowieso, im fe wird ja nur die setting für die Zeitsteuerung erstellt. Ausgeführt werden muss ja in fhem.
Oder missverstehe ich das ?
vg
joerg
Keine Logik im Frontend lautet die Devise, nur ein- und Ausgaben.
Damit bleibt das Frontend neutral und kann in fhem und Smarthome.py ohne Änderung verwendet werden.
Ich möchte darauf hinweisen, dass eine separate Funktion eher hinderlich ist, weil die Bildung des commandstrings pro Zeile den Befehl zum Schalten beinhalten muss, wie hier diskutiert:
http://forum.fhem.de/index.php/topic,33868.msg315531.html#msg315531
Das passiert also mitten in der UZSU_execute, da sehe ich es als nicht förderlich an, noch in eine andere Funktion zu springen...
Hi,
Die komplette Logik natürlich im Backend. Vielleicht habe ich mich da etwas missverständlich ausgedrückt.
Wenn ich das richtig sehe, erfolgt die Bildung des commandstring doch in der UZSU_execute.
Ich sehe auf den ersten Blick jetzt mal keinen Grund den Conditionsteil in einer separaten Funktion abzuarbeiten.
Bin im Moment unterwegs und das tippen auf dem Smartphone ist in meinem fortgeschrittenen Alter doch etwas mühselig ;). Schreibe später mal wie ich mir das im Detail vorstelle.
Gruß
Michael
Ok, ich schau es mir dann an! Vielleicht finden wir einen simplen, guten Weg!
push. Oder falscher Thread?
Zitat von: igami am 16 Juli 2015, 07:45:18
Hallo zusammen,
für meine Wochenprogramme möchte ich die uzsu verweden mit folgenden Einstellmöglichkeiten:
uzsuSelect,Wochentage
uzsuDropDown,Uhrzeit in 15 Minuten Abstufungen
uzssuToggle,Tag,Nacht
Mehrere Einträge
Bekomme ich das mit dem uzsu so hin? Habe nun schon einiges ausprobiert, im Prinzip müsste ja nur bei uzsu das enable,disable gemappt werden und die Uhrzeit verfeinert.
Grüße
igami
Hallo, Igami,
wenn es den anderen genauso geht, wie mir, dann wirst Du deswegen keine Antwort bekommen haben, weil die Frage einfach nicht verstanden wird.
Versuch doch nochmal etwas ausführlicher zu beschreiben, was Du erreichen möchtest, dann wird es sicher auch eine Angwort geben.
Hallo Bgewehr,
möglicherweise habe ich ja etwas übersehen aber mal eine blöde Frage: Hast Du denn schon mal grundsätzlich getestet ob der WDT mit unterschiedlichen Bedingungen für die einzelnen Regeln umgehen kann? Aus der CommandRef geht das nämlich nicht hervor.
Sowas wie hier funktioniert:
dm.test.uzsu en MO,TU,WE,TH,FR|08:30|off
MO,TU,WE,TH,FR|{sunrise_abs("REAL",-3600,"04:45","05:00")}|on
SA,SU|{sunrise_abs("REAL",3600,"07:00","08:00")}|on SA,SU|09:30|off
MO,TU,WE,TH,FR,SA,SU|02:30|off
MO,TU,WE,TH,FR,SA,SU|17:00|on { fhem("set @ %") if( Value("Ferientag") eq"1" && Value("Urlaub") eq "1")) }
Wohingegen dies hier Fehler produziert
dm.test.uzsu en MO,TU,WE,TH,FR|08:30|off
MO,TU,WE,TH,FR|{sunrise_abs("REAL",-3600,"04:45","05:00")}|on
SA,SU|{sunrise_abs("REAL",3600,"07:00","08:00")}|on
SA,SU|09:30|off MO,TU,WE,TH,FR,SA,SU|02:30|off { fhem("set @ %") if( Value("Ferientag") eq"1" && Value("Urlaub") eq "1")) }
MO,TU,WE,TH,FR,SA,SU|17:00|on { fhem("set @ %") if( Value("Ferientag") eq"1" && Value("Urlaub") eq "1")) }
Gruss
Michael
@Michael: kannst Du diese Frage mal an Dietmar63 in dem anderen Thread stellen? Er ist der WDT Experte...
@bgewehr: Damit dies hier funktioniert:
ZitatDamit kann dann jeder Schaltbefehl die gleiche oder auch andere Bedingungen haben
müßte der WDT unterschiedlichen Bedingungen für die einzelnen Regeln zulassen.
So wie ich es sehe bietet das WeekdayTimer Modul diese Möglichkeit (derzeit) aber nicht.
Anfrage an Dietmar zur Klärung ist raus, zu mehr hat die Zeit heute leider nicht mehr gereicht.
vielleicht macht es doch Sinn ein dediziertes modul zu schreiben ?
vg
joerg
Zitat von: Muk.s am 26 Juli 2015, 20:06:02
SA,SU|09:30|off MO,TU,WE,TH,FR,SA,SU|02:30|off { fhem("set @ %") if( Value("Ferientag") eq"1" && Value("Urlaub") eq "1")) }
MO,TU,WE,TH,FR,SA,SU|17:00|on { fhem("set @ %") if( Value("Ferientag") eq"1" && Value("Urlaub") eq "1")) }
Da ist aber auch jeweils eine runde schließende Klammer zuviel...
Zitat von: dev0 am 27 Juli 2015, 09:12:27
Da ist aber auch jeweils eine runde schließende Klammer zuviel...
Stimmt, Tippfehler :) Aber auch ohne funktioniert es nicht wie von Dietmar bestätigt:
ZitatUnterschiedliche Bedingungen sind nicht möglich
http://forum.fhem.de/index.php/topic,33868.msg316538.html#msg316538
Damit die UZSU trotzdem mit unterschiedlichen Bedingungen funktioniert, müßte man also entweder Dietmar "nötigen" das Modul entsprechend anzupassen oder seperate UZSU_WDT definieren wenn ein UZSU Schaltbefehl eigene Bedingungen enthält.
Joerg: Ein dediziertes Modul macht natürlich unabhängig(er) und hätte den Vorteil, daß das UZSU widget direkt mit dem Modul kommunizieren könnte, aber braucht es das wirklich?
Im Grunde genommen wäre es ja nur ein etwas "aufgebohrtes" WeekdayTimer modul. Vielleicht wäre Dietmar ja auch bereit sein Modul etwas anzupassen.
Mein workaround ist ein wdt pro Profile. Das ist einfach und sicher. Da der Nutzer damit im Backend gar nichts zu tun hat, spricht meiner Ansicht nach nichts dagegen.
Wenn der WDT sich weiterentwickelt, kann man die Strategie jederzeit ändern.
Ich würde nicht einen zweiten WDT entwickeln, wenn es mit fast null Aufwand auch mit diesem geht.
Was meint Ihr?
ZitatMein workaround ist ein wdt pro Profile.
Vielleicht könnte man das wie folgt umsetzen: Zusätzlich zu den Conditions pro Schaltbefehl gibt es auch eine globale Condition. Im UZSU widget gibt es dafür einen zusätzlichen Parameter mit dem man festlegt ob Conditions pro Schaltbefehl oder eine (einzige) globale Condition im Frontend angezeigt wird. Bei Conditions pro Schaltbefehl wird ein wdt pro Zeile erstellt, wohingegen bei der globalen Condition nur ein wdt erstellt wird.
Wäre das ein gangbarer Weg?
Ich suche immer noch nach sinnvollen Anwendungsfällen, bei denen eine globale Regel sinnvoll ist, helft Ihr mir mal mit Euren Beispielen?
Urlaub, Wochenende und Feiertag sind doch mit $we und !$we ausreichend abgedeckt, oder nicht?
Dann mache ich mal den Anfang:
Ich steuere z.B. über einen wdt die Temperatur im Arbeitszimmer, aber nur wenn ich zu Hause arbeite (homeoffice == 1)
HZ_Arbeitszimmer Mo-Fr|07:00|Comfort Mo-Fr|16:00|Auto (Value("Homeoffice") eq "1")
Bei einem wdt pro UZSU profil wären das zwei wdt Einträge in der fhem.cfg. Damit könnte man noch leben.
Hier wären es aber schon 6:
dm.FBDECT_16.uzsu en MO,TU,WE,TH,FR,SA,SU|02:30|off MO,TU,WE,TH,FR|08:30|off SA,SU|10:00|off MO,TU,WE,TH,FR|{sunrise_abs("REAL",-7200,"04:15","05:15")}|on MO,TU,WE,TH,FR,SA,SU|{sunset_abs("REAL",-3600,"15:00","16:30")}|on SA,SU|{sunrise_abs("REAL",-3600,"06:00","07:00")}|on { fhem("set FBDECT_16 %") if( Value("VirtuellerBewohner") eq "active" ) }
Also gibt es wohl drei Fälle:
1. eine Condition für alle Profile (mit einem WDT)
2. je eine Condition pro Profil (mit je einem WDT pro Profile)
3. Attribut "delayedExecutionCond" für "Warte mit dem Befehl, bis dec true"
Das muss ich erst mal mit MWorion besprechen, weil es sehr fhem spezifisch ist...
Vielleicht kann man ja eins auch wegfallen lassen, wenn man einen Copy-Button an die Conditions anbringt, der die Werte der ersten Zeile in die gewählte Zeile kopiert.
Dass es dann immer mehrere WDT gibt, ist doch unkritisch, oder?
ZitatDass es dann immer mehrere WDT gibt, ist doch unkritisch, oder?
Bei verschiedenen Conditions muß ich heute ja auch mehrere wdt's anlegen. Sollte also unkritisch sein.
Mit uzsuSelectRadio kann ja nur ein Button aktiv sein. Leider kann ich den aktiv Button nicht nochmal anklicken, so dass der Zustand gleich nochmal gesendet werden kann. Ich würde das aber gerne tun, z.B. mit einem Volume+ und Volume- Befehl. Ist dafür eine Möglichkeit vorgesehen?
lg
aeronaut
das widget ist zur auswahl gedacht und nicht als taster. von daher ist das so nicht vogesehen. cmdIcon ist vermutlich eher das was du brauchst.
gruß
andre
Moin Andre, cmdIcon klingt dafür geeigneter, das Teil ging komplett an mir vorbei ..
Gehört hier zwar nicht hin, aber vielleicht weißt du, warum es so keine Icons angezeigt werden:
define test dummy
attr test cmdIcon on:control_centr_arrow_up off:control_centr_arrow_down
attr test setList state:on,off
attr test webCmd state
Zitat von: aeronaut am 31 Juli 2015, 16:05:04
Gehört hier zwar nicht hin, aber
Genau - also bitte separaten Fred aufmachen. Tut gar nicht weh :)
zum testen der widgets habe ich heute mal einen dummy erstellt, wie im ersten post beschrieben. leider sind die farben etwas schlecht, da die "aktiven" buttons von den "nicht-aktiven" buttons fast nicht zu unterscheiden sind.
(http://forum.fhem.de/index.php?action=dlattach;topic=32660.0;attach=35508;image)
ich habe keine dateien extra installiert, also alles dateien, die fhem mitbringt. browser ist firefox und als webif nutze ich pgm2 mit darkstyle in fhem. eigentlich hatte ich erwartet, dass die farbgestalltung den beispielen aus dem 1. post entsprechen würde. muss ich eventuell doch noch etwas installieren, oder ist das normal?
gruss frank
wenn du die farben aus dem ersten post möchtest musst die auch das style file aus diesem post installieren.
das problem ist das es noch keine methode gibt für jeden fhem style automatisch den passenden jquery-ui style zu laden.
hierzu gibt es schon eine idee und interne vorbereitungen aber es ist noch nicht fertig umgesetzt.
es ist also bis auf weiteres noch etwas handarbeit nötig.
gruss
andre
ps: der style alleine sollte reichen. alles andere ist inzwischen eingecheckt.
Zitatwenn du die farben aus dem ersten post möchtest musst die auch das style file aus diesem post installieren.
ok, danke.
ich gehe davon aus, dass es sich um jquery-ui.min.css handelt, da mir firebug dazu hinweise liefert. das ergebnis hat jetzt mehr kontrast, aber ...
(http://forum.fhem.de/index.php?action=dlattach;topic=32660.0;attach=35513;image)
dieses ergebnis hatte ich auch bereits mit dem style direkt von der homepage http://jqueryui.com. irgendwie vertragen sich fhem-style und jqueryui-style bei mir nicht, denn die style's von jqueryui.com werden in meinem fhem immer verändert. sogesehen ist die jquery-ui.min.css, die schon im trunk von fhem enthalten ist, bereits ein kleiner kompromiss. in der datei ist auch ein link, der auf jquerui.com einen style zum editieren generiert. der sieht dort auch wieder anders aus. hat vielleicht doch schon mal jemand versucht einen kompromiss zu finden.
schade eigentlich, das sich die styles gegenseitig "behindern".
Zitates ist also bis auf weiteres noch etwas handarbeit nötig.
sieht ganz danach aus. ;)
gruss frank
Hallo,
Ich bin neu hier und habe meine ersten Erfahrungen mit fhem gemacht.
Frage:
Wohin muss ich die Dateien von Justme1968 hinkopieren :-\ um die Widgets
Nutzen zu können?
Gruß
Stefan
wenn dein fhem up-to-date ist, müsste alles bereits vorhanden sein. ansonsten .../fhem/www/pgm2/
Einfach attr setlist state:uzsu
Und attr webCmd state setzen...
Gibt es schon etwas zu den wrappern bzw explizit für den weekdaytimer?
Gruß Steven
gab es :) ist aber noch nicht umgesetzt.
gruss
andre
ps: der thread hier hat das problem das es um zwei mehr oder weniger verschiedene dinge geht. zum einen um die widgets aus dem ersten beitrag. die sind für fhemweb gedacht und zur zeit 'nur' für eigene dinge bzw. mit etwas handarbeit für standard fhem komponenten verwendbar. das andere ist die verwendung mt frontem und wie das dortige uzsu widget mit weekday timer verwendet werden kann.
Nabend zusammen,
das meiste konnte ich bisher mit der Commandref und suchen im Forum loesen, aber nun finde ich keine Loesung. Oder ich uebersehe was einfaches.
Ich habe ein KNX Schalter so definiert:
define EIB_7701 EIB 7701
attr EIB_7701 IODev KNX
attr EIB_7701 alias Klima Buero NB An/Aus
attr EIB_7701 room EIB
attr EIB_7701 webCmd on:off:on-for-timer
attr EIB_7701 widgetOverride on-for-timer:uzsuSelect,300,600,1800,3600
Das sieht auch soweit gut aus und ist ziemlich das, was ich gerne haette.
Nun ist nur die Frage, kann ich zum einen die on-for-timer-buttons mit einer Ueberschrift versehen und zum anderen kann ich den Werten (300, 600, ...) eine andere Beschriftung verpassen, also das die Buttons zB 5 min, 10 min, 1/2 h, 1 h heissen?
Oder gibt es die Moeglichkeit schlicht (noch) nicht?
Installiert ist die aktuelle 5.6 Version, heute schon updates gemacht.
FHEM macht schon ziemlich viel Spass!
@Justme1968: Soll ich mit dem SmartVISU UZSU lieber in einen neuen Thread umziehen?
nein. etwas in der art ist nicht vorgesehen. die buttons sind auch eigentlich dafür den aktuelle zustand zu zeigen und änderbar zu machen.
das was du möchtest ist besser über webCmd und cmdIcon abgedeckt.
oder du nimmst eine readingsGroup und hast dann auch überschriften.
gruss
andre
@bgwehr: wenn die teile bei denen es nur um smartvisu geht in einem eigen thread sind hilft es bestimmt manchem das auseinander zu halten.
OK, danke.
Bei cmdIcon und webcmd sehe ich aber auch nicht direkt Beschriftungsmoeglichkeiten, also muss ich mir entweder Icons basteln, die einen Befehl bekommen oder mit eventMap das umformatieren, oder?
readingsgroup ist noch eine gute Idee, damit habe ich vorhin zum ersten mal herumgespielt (ja gut, mit FHEM auch erst 5 Tage...).
SmartVisu wollte ich mir noch anschauen, da weiss ich noch fast nichts von, daher mal ganz vorsichtig gefragt: Kann man da Ueberschriften und/oder Beschriftungen dazustellen?
Grundsaetzlich gefiel mir die Moeglichkeit die hier mit uzsu... und widgetoverride ohne viel Aufwand moeglich sind sehr gut, und ich musste mich auch erst einmal auslassen, wie man vielleicht erkennen kann... :-)
Zitat von: justme1968 am 04 August 2015, 20:48:49
gab es :) ist aber noch nicht umgesetzt.
Wo gab es das? :)
Theoretisch könnte ich doch auch den state eines dummys mit uzsu Attribut per modify auf den wdt setzen, oder? Vom Format her schein das, wenn ich nicht falsch geguckt habe, zu passen...
@bgewehr
Kannst du bitte mal noch n Link zum neuen Thread posten?
Wenn es soweit ist;)
@fidel: noch habe ich keinen angelegt!
die idee war ja auch das es so gut wie möglich passt.
ein notify auf state das dann alles anpasst ist vermutlich im augenblick die einfachste lösung.
gruss
andre
Hi Andre,
hab es jetzt per notify und modify so, dass ich gut damit weiter arbeiten kann...
Noch ne frage. In Post 113 von frank auf Seite 8 sind die ausgegrauten felder mit grauer Schrift. Ist bei mir zur Zeit auch so. Auf deinem ersten Post ist die Schrift weiß.
Hast du ne Ahnung wo der Fehler liegt? :D
Gruß Steven
die styles passen noch nicht ganz. wenn rudi mit den vorarbeiten fertig ist bringe ich das in ordnung.
gruss
andre
Moin,
nachdem ich mit eventMap woanders etwas umgesetzt habe, wollte ich nochmal an diese Stelle und schauen, ob das geht, was ich gerne haette. Dafuer habe ich gesetzt:
attr EIB_7701 eventMap /300:5min/600:10min/
attr EIB_7701 webCmd on:off:on-for-timer
attr EIB_7701 widgetOverride on-for-timer:uzsuSelect,300,600,1800,3600,5min,10min
(Ist natuerlich jetzt doppelt mit den 5 und 10 min gerade, aber ist ja test) und es sieht aus, wie im angehaengten, Bild, als ich kann schoen auf die 5min und 10min druecken.
Somit das, was ich gerne wollte an der Stelle (Ueberschriften koennen ja anders geloest werden).
Ich habe nur ein Brett vor dem Kopf, wie ich ein Leerzeichen zwischen 5 und min richtig setze/escape gerade, damit das uebernommen wird.
Kann mir da noch jemand einen Denkanstoss geben?
Hallo,
da ich ziemlich neu in fhem bin kann mir jemand ein Beispiel für den "uzsuTimerEntry" geben?
Das ich z.b. etwas schalten kann?Meine Heizungsregelung geht schon manuell möchte es jetzt aber über eine Zeitregelung machen
aber das ist etwas schweiriger.
Wie kann ich denn vergleichen ob die Bedingungen erfüllt sind?
# Schalter Manuell oder automatisch
define man_zeit dummy
attr man_zeit alias Manuell/Zeit
attr man_zeit setList state:uzsuToggle,Manuell,Zeit
attr man_zeit webCmd state
attr man_zeit group Regelung
attr man_zeit room Heizungsregelung
define Zustand_regelung notify man_zeit {\
my $state = Value("man_zeit");;\
if( $state eq "Manuell") {\
fhem ("set gpio_27 off") ;;\
}\
if ( $state eq "Zeit") {\
fhem ("set gpio_27 on") ;;\
}\
}
define Zeitschaltung dummy
attr Zeitschaltung room Heizungsregelung
attr Zeitschaltung setList state:uzsuTimerEntry
attr Zeitschaltung webCmd state
define Pumpe_ein notify Zeitschaltung {\
my $state = Value("Zeitschaltung");;\
{fhem ("set gpio_22 off");;}\
}
Hallo,
kann mir vielleicht einer einen Tip geben mit dem Timer auswertung.
Wäre echt dankbar weil bis jetzt geht alles ausser die Zeitsteuerung.
Gruss
stefan
Wenn du dich mit dem Thema selbst etwas beschäftigt hast und konkrete Fragen hast, dann wirst du sicher auch qualifizierte Antworten bekommen. Das ist wahrscheinlich nicht der Tipp den du lesen wolltest, aber so wird das mMn nichts.
da hast du recht, also wie kann ich den
tUZSU mit dem WeekdayTimer verknüpfen?
define tUZSU dummy
attr tUZSU room Test
attr tUZSU setList state:uzsu
attr tUZSU webCmd state
define WT WeekdayTimer zeit_schalten de mo,di,mi,do,fr,sa,so|21:06|An mo,di,mi,do,fr,sa,so|21:08|Aus
Hallo zusammen,
ich wollte eine uzsu definieren um damit Zeitpunkte einzustellen, wann welcher Radiosender abgespielt wird. Allerdings scheiter ich gerade daran, dass ich auch ein Dropdown zu sehen bekomme. Kann mir jemand sagen was ich falsch mache? Meiner Meinung nach ist alles so, wie im Posting beschrieben.
List:
Internals:
NAME tEntry
NR 341
STATE Mo,Di|05:00|enabled
TYPE dummy
Readings:
2015-11-12 08:02:12 state Mo,Di|05:00|enabled
Helper:
Bm:
Dummy_set:
cnt 49
dmx 0
max 6
tot 52
mAr:
HASH(0x34b6390)
tEntry
Mo,Di,Mi,Do|05:00|disabled
Mo,Di,Mi,Do|07:00|enabled
Attributes:
setList setList state:uzsu,uzsuDropDown,Radio1,Radio2,Radio3
webCmd state
Anstatt dem Button "enable" erwarte ich eigentlich ein Dropdown mit "Radio1, Radio2" etc.
Hat niemand sonst das Problem?
Hallo zusammen,
Ich habe mich gefragt, wie man diese schicken Widgets (speziell uzsu) mit dem WeekdayTimer verheiraten kann und war etwas erstaunt, dass dies so einfach nicht ist. Da bald Weihnachten ist, habe ich mal meine Wünsche geäußert 8)
Und ich habe auch einen Vorschlag definiert. Nun stellt sich mir jedoch die Frage, ob ich das Widget entspr. definieren kann, um die Daten dem WeekdayTimer mundgerecht zu servieren.
Wenn ich einfach mal ein Dummy definiere:define du_uzsu_test dummy
attr du_uzsu_test setList state:uzsu
attr du_uzsu_test webCmd stateDann bekomme ich ja Disabled/Enabled als schaltbare Option. Nun will ich aber evtl. on/off oder ein/aus haben? Oder brauche wie schon als Beispiel gezeigt eine Temperatur. Wen ich es richtig sehe geht das und ich habe nur noch nicht die richtige Definition gefunden - richtig? Aber wenn ich den WeekdayTimer richtig verstehe, muss vor den Wert noch der Name des Reading gesetzt werden, wenn ich nicht gerade das Standardreading des Zieldevices verändern will. Also im Fall Temperatur z.B. desiredTemp:21,5 Bekommt man das auch hin?
Hier geht es mal zu dem Thema (http://forum.fhem.de/index.php/topic,45979.msg377930.html#msg377930) - vielleicht ist es ja möglich, da etwas zusammen zu bringen.
zusammenführende Grüße
Niels
Hallo Niels,
Gerade erst deinen Beitrag hier gesehen. Habe just in deinem Threat etwas dazu geschrieben.
Gruß
Hans
Hallo,
Ich komm' nicht d'rauf:
Ist es möglich im uzsuTimerEntry auch Minuten zu wählen?
Gruß
Hans
Hallo,
Ich komm' nicht d'rauf:
Ist es möglich im uzsuTimerEntry auch Minuten zu wählen?
Gruß
Hans
Hallo,
möchte gerade meine Rollos mit Zeitsteuerung und uzsu Schalten bekomme es aber nicht hin :(
define wdt_Buero_Rolladen_uzsu WeekdayTimer Rolladen en MO,TU,WE,TH,FR,SA|00:10|off
attr wdt_Buero_Rolladen_uzsu setList state:uzsu
er nimmt das setList state:uzsu nicht an ?
vielleicht kann mir einer Helfen
kann ich auch? DOIF ([10:23-18:53|7] or [07:35-17:52|8]) (set Buero_Rolladen auf) DOELSE (set Buero_Rolladen zu)
anhängen oder geht die bei uzsu nicht
Danke
Wie muss ich welche CSS Datei einbinden um den Style wie aus dem Startpost zu bekommen?
(http://forum.fhem.de/index.php?action=dlattach;topic=32660.0;attach=25926)
Grüße
igami
Alle angehängten Dateien aus dem Startpost.
Gruß
Steven
Die ganzen angehängten Dateien sind schon unter www/pgm vorhanden.
Hallo
bin am verzweifeln das geht
attr OG.Buero_Schranklicht webCmd on:off:on-for-timer
attr OG.Buero_Schranklicht widgetOverride on-for-timer:uzsuSelect,300,600,1800,3600
warum geht das nicht damit ich Tage und Stunden und Minuten hab wie auf dem Bild von igami ?
attr OG.Buero_Schranklicht webCmd state
attr OG.Buero_Schranklicht widgetOverride setList state:uzsuTimerEntry
was mach ich für nen fehler ?
muss der dummy mit dran also so
define OG.Buero_Schranklicht IT F0F000FFFF FF F0 dummy (geht aber nicht)
finde aber auch nichts im forum wo ich weiterkomme oder ansetzen kann Startpost hab ich auch schon durch verstehs aber nicht? eins geht das andere nicht
Gruß
Hallo,
kann wirklich keiner ein beispiel oder eine Hilfe geben
jetzt hab ich
define licht IT 00F00FFF0F FF F0
attr licht webcmd state
dann
define tEntry dummy
attr tEntry setList state:uzsuTimerEntry
attr tEntry webCmd state
dann
define tEntryNotify Notify WeekdayTimer licht Mo-Fr|12:08|on Mo-Fr|00:13|off
dann im Notify licht on gewählt (nichts geht , hat keiner einen brauchbaren Schnipsel rumliegen?)
Nachdem ich mich nun länger nicht mehr mit UZSU beschäftigt habe wieder ein neues Problem:
define test dummy
attr test readingList uzsu
attr test room test
attr test setList uzsu:uzsuSelectRadio,off,auto,on
attr test stateFormat <no definition>
attr test webCmd uzsu
Wenn ich mich in der Detailansich des Device befinde wird der aktuelle Wert des Readings korrekt im uzsu widget angezeigt. Gucke ich mir jedoch das Device in der Raumansich an ist kein Feld des widget ausgewählt.
Edit: habe es grade mal mit einem uzsuSelect probiert, dort funktioniert alles wie erwartet
Grüße
igami
Ich verwende uzsuToggle schon seit längerem. Heute habe ich festgestellt, dass es im Firefox nicht mehr funktioniert. Im InternetExplorer geht es noch.
Meine Definition sieht so aus:
define Schaltpunkt_0_Frueh dummy
attr Schaltpunkt_0_Frueh comment Schaltzeitpunkte zwischen 04:00 - 07:45 im 15 Minutentakt
attr Schaltpunkt_0_Frueh devStateIcon on:general_an@green off:general_aus@red
attr Schaltpunkt_0_Frueh group Programm
attr Schaltpunkt_0_Frueh room 06_Heizung
attr Schaltpunkt_0_Frueh setList switch:on,off zeit:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00 zeit_we:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00 mode:boost,noboost
attr Schaltpunkt_0_Frueh stateFormat switch
attr Schaltpunkt_0_Frueh webCmd switch:zeit:zeit_we:mode
attr Schaltpunkt_0_Frueh widgetOverride switch:uzsuToggle,off,on mode:uzsuToggle,noboost,boost
Weder switch noch mode funktionieren. Es kann nicht mehr getoggelt werden. Aber nur im FireFox. Im IE funktioniert es noch. Ich habe auch das unter diesen https://forum.fhem.de/index.php/topic,64538.0.html (https://forum.fhem.de/index.php/topic,64538.0.html) beschriebene Problem bei meiner Installtion. Ggf. hängt das ja zusammen.
verwendet jemand noch die Zeitschaltuhr in Verbindung mit uzsu in einer readingsGroup und hat evl. ein list davon