Moin zusammen,
Ich stehe mal wieder mächtig auf dem Schlauch oder sehe den Wald vor lauter Bäumen nicht oder habe schon wieder zu viel gelesen :-[
Nun gibt es den WeekdayTimer und die UZSU-Widgets (http://forum.fhem.de/index.php/topic,32660.0.html) von Andre. Diese baue ich per setList in mein Modul ein, was bei einem Dummy auch gut funktioniert hat. Aber was soll ein Dummy damit, also will ich das doch dem WeekdayTimer überziehen. Doch der kennt das Atribut setList nicht...
Und auch per Befehlseingabe lässt sich dem WeekdayTimer dieses Atribut nicht unterheben:attr wdt_Test setList state:uzsu
wdt_Test: unknown attribute setList. Type 'attr wdt_Test ?' for a detailed listMuss ich die Liste jetzt in einem Dummy erstellen und dann per Notify dem WeekdayTimer übergeben? Das wäre ja quasi ein Löschen und neu definieren des WeekdayTimer?!Oder gibt es da auch einen kurzen,direkten Weg?
blinde Grüße
Niels
Ach ja - klassisches FHEMWEB, nix SmartVisu
Nur dummys kennen setList.
widgetOverride könnte dir helfen.
Danke Marvin,
Das hat so spontan nicht geklappt. Ich muss ja auch an die Definition ran. Bekomme ich die überhaupt so zu fassen? Und davor steht dann ja noch das Device, auf welches der Timer wirken soll, sowie ggf. der Wert der gesetzt werden muss.
Globaler gefragt: Kann ich überhaupt die Definition verändern? Sei es per widgetOverride oder per notify? Das müsste ja auch ein Save nach sich ziehen...
grundlegende Grüße
Niels
Schau mal hier rein. Es gibt einen Wrapper. Ich habe mich aber nicht genauer damit beschäftigt.
http://forum.fhem.de/index.php/topic,32660.15.html
Danke Marvin,
Das hatte ich gelesen, aber auch dies dazu:
Zitat von: rudolfkoenig am 01 Februar 2015, 14:16:25
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.
Zitat von: rudolfkoenig am 02 Februar 2015, 07:44:36
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.
Zitat von: justme1968 am 02 Februar 2015, 12:30:13
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.
Aber scheinbar wollte ich die Essenz, das es da noch keine echte Lösung gibt nicht lesen :-\
Ich überlege ja schon, ob man da etwas mit meiner Lieblingswaffe DOIF bauen kann, aber im Moment überfordert mich das auch (allerspätestens bei mehreren Timer-Einträgen). Das wäre ja nochmal eine Herausforderung für Damian, so ein UZSU-Dummy zu parsen 8)
Aber am Einfachsten wäre es IMHO jedoch wenn Dietmar63 in seinem weekdayTimer eine Option einbaut, die es entweder erlaubt das UZSU-Widget zu verwenden oder aber die Timerdefinitionen von außen zu verändern (set myWeekdayTimer timespec Mo,Di,Mi,Do,Fr|11:00|enabled Mo,Di,Mi,Do,Fr|12:00|disabled).
mit dem Zaun winkende Grüße
Niels
Hallo,
Mit
defmod myWeekdayTimer WeekdayTimer Heizung Mo,Di,Mi,Do,Fr|11:00|enabled Mo,Di,Mi,Do,Fr|12:00|disabled
geht das doch eigentlich oder verstehe ich dich falsch?
Gruß
Hans
Moin Hans,
Nein, das verstehst Du goldrichtig. Alleine mir fehlten die Worte (Befehle). defmod scheint hier echt ein guter Ansatz zu sein, wenn es direkt nicht geht. Ein Dummy beherbergt den Zeitplan und sobald dieser sich ändert wird über ein notify das defmod getriggert, was wiederum den WeekdayTimer aktualisiert. Entweder belässt man es nun dabei und gibt dem User die Aufgabe die Konfig zu speichern oder man jagt aus dem Notify gleich ein save hinterher.
Ist zwar alles ein Krampf, aber klingt nach einem Plan 8)
verstandene Grüße
Niels
ich habe die Diskussionen nicht alle mitverfolgt, aber es gibt doch schon die Möglichkeit mit
modify jeden WD nachträglich zu verändern, dann muss man allerdings die herkömmliche Syntax des define verwenden.
Jo Dietmar,
So wie es Hans beschrieben hat geht es.
Aber da bald Weihnachten ist, wünsche ich mir mal, dass ich in Deinem Modul direkt UZSU-Widget anbinden kann, um den Umweg über Dummy und Notify zu umgehen 8)
Das wäre cool und einfach noch dazu ;)
vorweihnachtliche Grüße
Niels
Habe hierzu vorgestern auch was gebastelt
(gelöst) uzsu Zeitraum auswerten (http://forum.fhem.de/index.php?topic=45896.msg376681#msg376681)
Habe dazu einen Dummy für das widget
define uzsu_dummy dummy
attr uzsu_dummy readingList next program
attr uzsu_dummy setList program:uzsu
set uzsu_dummy next 12:00
und ein DOIF das die Auswertung macht
DEF
(
[[uzsu_dummy:next]] or
[uzsu_dummy:?program]
)(
{uzsu_interval("uzsu_dummy", "program", $wday, $hour, $min)}
)DOELSEIF([uzsu_dummy:?enabled])(
set uzsu_dummy enabled
)DOELSEIF([uzsu_dummy:?disabled])(
set uzsu_dummy disabled
)
attr uzsu_DOIF do alwas
Da ich hier auf defmod verzichte muss ich auch nicht auf das save achten.
So richtig zu frieden bin ich damit jedoch noch nicht.
Zitat von: Muschelpuster am 21 Dezember 2015, 16:02:56
dass ich in Deinem Modul direkt UZSU-Widget anbinden kann, um den Umweg über Dummy und Notify zu umgehen
Würde das nicht, auch wenn beide zugegebenermassen nahe verwandt sind, dem 'DOTADIW'-Prinzip widersprechen?
Mit
notifies kann ich doch individueller reagieren und habe mehr Freiheiten.
Gruß
Hans
Na ja, ich habe ja nicht geschrieben, dass das fest verheiratet werden soll, nur das es toll wäre die Option zu haben. Unterm Strich müsste dazu sicher der Zeitplan aus der Definition in ein Reading verlegt werden oder es ein Reading geben, was mit der Definition fest verheiratet ist. Eigentlich sicher nicht das Thema, das Problem ist da wohl eher das Upgrade bestehender Definitionen, was mit Variante 2 'erledigt' wäre.
Aber ich habe nur mal einen Wunsch geäußert, Dietmar muss sehen ob es geht und er da seine Zeit investieren möchte.
vorgeschlagene Grüße
Niels
Zitat von: Muschelpuster am 21 Dezember 2015, 16:02:56
Jo Dietmar,
So wie es Hans beschrieben hat geht es.
Aber da bald Weihnachten ist, wünsche ich mir mal, dass ich in Deinem Modul direkt UZSU-Widget anbinden kann, um den Umweg über Dummy und Notify zu umgehen 8)
Das wäre cool und einfach noch dazu ;)
vorweihnachtliche Grüße
Niels
und was müßte man tun, um WD direkt an UZSU anzubinden - will mir nicht alles erraten, dafür ist mir meine Zeit zu schade. Wenn ihr einen einfachen Vorschlag habt, versuche ich den Wunsch zu erfüllen. Wenn es bis Weihnachten zu knapp ist, dann vielleicht bis Ostern.
Zitat von: Dietmar63 am 21 Dezember 2015, 21:23:36und was müßte man tun, um WD direkt an UZSU anzubinden - will mir nicht alles erraten, dafür ist mir meine Zeit zu schade.
Zitat von: Muschelpuster am 21 Dezember 2015, 21:14:56Unterm Strich müsste ... es ein Reading geben, was mit der Definition fest verheiratet ist.
Sprich man kann den Zeitplan über ein Reading lesen und schreiben.
UZSU arbeitet per Default mit einem String entspr. folgendem Beispiel:
Mo,Di,Mi,Do,Fr,Sa|11:00|enabled Mo,Di,Mi,Do,Fr,Sa|12:00|disabled Sa,So|14:00|enabled Sa,So|15:00|disabledDas ist ja schon mal WeekdayTimer-kompatibel. Ich denke, dass man das enabled/disabled auch entsprechend modifizieren kann, um dort etwas mehr loszuwerden - das werde ich klären. Komplexe Funktionen wären in dieser Kombi sicher nicht das Ziel.
zusammengefasste Grüße
Niels
Ich hatte schon länger vor Andres uzus mal in Verbindung mit Dietmars WeekdayTimer zu nutzen.
Ein
widgetOverride state:uzsu,slider,15,.5,21,1
in einem Dummy kann mit einem rel. simplen notify zur Modifikation eines WeekdayTimers genutzt werden:
wd_testDummy {
my $dev = "Heizung";
my $wd = "wd_test";
my @uzus = split(/ /,Value("wd_testDummy"));
my $str = "";
foreach (@uzus){
my ($days,$time,$status,$cmd) = split(/\|/,);
if ($status eq "enabled") {
$str = $str." $days|$time|$cmd";
}
}
if ($str ne "") {
fhem("defmod $wd WeekdayTimer $dev $str");
}
}
Naja, sollte vielleicht doch als sub in eine MyUtils. Aber ist ja auch erst der Anfang.
Ein
userReadings wdt_cmd {my $a=Value($name);; $a=~s/\|(dis|en)abled//g;;return $a}
liefert einen direkt mit WeekdayTimer kompatiblen String wenn ich enable und disable nicht brauche.
Die Möglichkeiten sind nicht nur vielfältig sondern auch jetzt schon mit den Fähigkeiten von fhem recht einfach umzusetzen. Finde ich.
Just my 2cents.
Gruß
Hans
Erst einmal Danke für die Ansätze.
Zitat von: Hans Franz am 22 Dezember 2015, 00:35:49Die Möglichkeiten sind nicht nur vielfältig sondern auch jetzt schon mit den Fähigkeiten von fhem recht einfach umzusetzen. Finde ich.
Nur müssen die Fähigkeiten des Anwenders auch mit den Fähigkeiten des FHEM kompatibel sein. In FHEM kann oder will man leider nicht ohne Codezeilen Dinge zueinander kompatibel machen und es ist wie immer: Umso flexibler, umso anspruchsvoller in der Konfiguration.
inkompatible Grüße
Niels
Hier mal noch ein notify um UZSU Readings auf WeekdayTimer zu übertragen:
#
# Flat Export created by fhem.pl:12311/2016-10-10
# at 2016-10-22 07:49:31
#
### TYPE: notify
# File Rev Last Change
# 91_notify.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
define profile2WeekdayTimer notify .*(Mo|Di|Mi|Do|Fr|Sa|So)\|\d\d:\d\d\|(enabled|disabled).* {
my $profile = (split(": ", $EVENT, 2))[1];
return if(!$profile or $profile =~ /,\|/);
my @WeekdayTimer = devspec2array("TYPE=WeekdayTimer:FILTER=DEVICE=$NAME");
fhem("modify $_ $NAME $profile", 1) for(@WeekdayTimer);
fhem("save", 1) if(int(@structChangeHist) == int(@WeekdayTimer));
return;
}
Grüße
igami