Hallo zusammen,
ich bin gerade dabei meine FHEM-Configs zu "optimieren"...
Ich hätte da mal eine Frage:
ist es möglich ein
{AttrVal('dummy_TimeCons','heute_daemmerung',undef)}
in ein TimeSpec zu parsen, sodass ich ein at ausführen lassen kann?
Ungefähr so hier meine ich das:
define at_Licht_Laterne_EIN at *{AttrVal('dummy_TimeCons','heute_daemmerung',undef)} { ...
Dankeschön.
Hi,
klar geht das https://fhem.de/commandref_DE.html#at
Aber ich hoffe nicht wirklich über ein Attribute?
Wäre doch ganz einfach wie in einem der Beispiele?
Zitat# Lampe von Sonnenuntergang bis 23:00 Uhr einschalten
define a9 at +*{sunset_rel()} set lamp on
define a10 at *23:00:00 set lamp off
# Elegantere Version, ebenfalls von Sonnenuntergang bis 23:00 Uhr
define a11 at +*{sunset_rel()} set lamp on-till 23:00
# Nur am Wochenende ausführen
define a12 at +*{sunset_rel()} { fhem("set lamp on-till 23:00") if($we) }
# Schalte lamp1 und lamp2 ein von 7:00 bis 10 Minuten nach Sonnenaufgang
define a13 at *07:00 set lamp1,lamp2 on-till {sunrise(+600)}
# Schalte lamp jeden Tag 2 Minuten nach Sonnenaufgang aus
define a14 at *{sunrise(+120)} set lamp on
# Schalte lamp1 zum Sonnenuntergang ein, aber nicht vor 18:00 und nicht nach 21:00
define a15 at *{sunset(0,"18:00","21:00")} set lamp1 on
Gruß Otto
Zitat von: remo am 10 Februar 2021, 14:00:49
ich bin gerade dabei meine FHEM-Configs zu "optimieren"...
oje
Nix Oje.
Mache ich seit Anfang an so. Ohne Probleme.
Coden ist mir auch nicht gänzlich fremd.
Ich stolpere nur ab und an mal über perl'sche Eigenarten.
Trotzdem Dankeschön für deine ,,Hilfestellung".
Liebe Grüße
@Otto
Der Hintergrund ist, dass ich mir Konstanten definiere mit Zeitangaben/Uhrzeiten.
Ich habe relativ viele at-Defines (Licht, Rollläden,...).
Ich möchte die at möglichst konsistent definieren, heißt, statt für jeden at eine Uhrzeit anzugeben, möchte ich den Wert aus meinem Konstanten-Dummy auslesen.
Somit brauche ich nur noch an einer Stelle die Uhrzeit anpassen und alle ats haben automatisch den neuen Wert.
Das Auslesen mit AttrVal klappt nur ist es kein TimeSpec was dort ausgelesen wird. Daher meine Frage, ob man das parsen kann.
betateilchens ,,oje" hilft mir da leider nicht viel...
Zitat von: remo am 10 Februar 2021, 15:07:13
Somit brauche ich nur noch an einer Stelle die Uhrzeit anpassen und alle ats haben automatisch den neuen Wert.
Sowas macht man aber nicht über ein Attribut, sondern - wenn überhaupt - über ein Reading.
Zitat von: remo am 10 Februar 2021, 14:49:54
Coden ist mir auch nicht gänzlich fremd.
Der Unterschied zwischen Attribut und Reading ist an dieser Stelle keine "perl'sche Eigenart".
Zitat von: remo am 10 Februar 2021, 15:07:13
Somit brauche ich nur noch an einer Stelle die Uhrzeit anpassen und alle ats haben automatisch den neuen Wert.
Wie sollen die at den neuen Wert bekommen, nur weil/wenn du das Attribut änderst?
Davon kriegt doch eine bereits erstellte at-DEF nichts mit.
Deine AttrVal-Abfrage wird ja nur beim define von at ausgeführt.
Dann damit das at erstellt und: das war's...
(sofern ich nicht [komplett] daneben liege)
Gibt's da nicht ein Modul für? ;)
WeekdayTimer?
(also nutze ich nicht, habe nur davon gehört)
Gruß, Joachim
Dankeschön betateilchen.
Bin ja für Anregungen sehr dankbar.
Welche Möglichkeiten hätte ich denn einen dummy mit benutzerdefinierten Readings zu definieren und zu ,,füllen"?
Ich verstehe immer noch das Problem nicht :-[
Warum ist ein Attribute besser als ein Reading?
Warum kann man da keine Zeit rein schreiben?
Ich hatte das doch erst: komplettes Beispiel: https://forum.fhem.de/index.php/topic,118245.msg1127413.html#msg1127413
Allerdings geht es um - Zitat "heute_daemmerung" - da macht es doch keinen Sinn einen festen Wert in einen Dummy zu schreiben?
Gruß Otto
@Otto nicht aufregen :)
Es gibt halt immer noch User, die den korrekten Einsatz von FHEM devices unterschiedlichen Types noch nicht verstanden haben.
Zitat von: remo am 10 Februar 2021, 15:24:54
Welche Möglichkeiten hätte ich denn einen dummy mit benutzerdefinierten Readings zu definieren und zu ,,füllen"?
Aber dass jemand nicht weiß, wie man mit Readings umgeht, ist schon sehr bedenklich.
Das steht doch im Kapitel "Einführung zu FHEM" vermutlich schon im Klappentext...
setreading <dummyName> <readingName> <readingWert>
Den Unterschied kenne ich sehr wohl.
Ich habe mich an einem Beispiel aus diesem Forum orientiert.
,,Bedenklich" finde ich eher andere Dinge.
Wie zum Beispiel, dass User im Anfänger-Forum runtergemacht werden, für Fragen, die von den Profis leicht zu beantworten sind.
Ich habe hier schon viel Hilfe erhalten und dafür bin ich sehr dankbar.
Aber, dass betateilchen oft erstmal etwas Erniedrigendes zum Besten geben muss bevor ein produktiver Ratschlag kommt, nervt mich.
Auch wenn ich mit Softwareentwicklung vertraut bin, habe ich dennoch ab und an Probleme mit FHEM und der Funktionsweise. Und wohin soll ich mich wenden, wenn nicht ans Forum?!
Gruß
Zitat von: remo am 10 Februar 2021, 16:28:02
Und wohin soll ich mich wenden, wenn nicht ans Forum?!
Vielleicht zwischendurch auch einfach mal
vor dem Fragen einen Blick in die Dokumentation werfen?
Oder die Suchfunktion des Forums benutzen?
Dann braucht man nicht zum 3482. Mal die einfachsten Fragen stellen ("wie fülle ich ein reading in einem dummy?"), nur weil Fragen viel bequemer ist.
Offenbar kennen einige User den Unterschied zwischen "Um Hilfe bitten" und "Die Gutmütigkeit anderer Forummitglieder ausnutzen" nicht mehr.
Und
das nervt
mich.
ZitatDas Auslesen mit AttrVal klappt nur ist es kein TimeSpec was dort ausgelesen wird. Daher meine Frage, ob man das parsen kann.
Ist dieses Frage jetzt eigentlich mit meinem Beispiel beantwortet?
Weil: unterm Strich ist es Wurst ob Du AttrVal oder ReadingsVal nimmst, das Ergebnis sollte gleich sein.
Ich habe das Problem: "Es ist kein TimeSPec" - nicht verstanden, allerdings hast Du auch überhaupt keine Infos dazu geliefert.
Nützlich zu meinem Verständnis wäre z.B. ein list dummy_TimeCons gewesen ;) siehe auch hier (https://forum.fhem.de/index.php/topic,71806.0.html)
Zitat von: betateilchen am 10 Februar 2021, 17:44:52
Vielleicht zwischendurch auch einfach mal vor dem Fragen einen Blick in die Dokumentation werfen?
Oder die Suchfunktion des Forums benutzen?
Dann braucht man nicht zum 3482. Mal die einfachsten Fragen stellen ("wie fülle ich ein reading in einem dummy?"), nur weil Fragen viel bequemer ist.
Offenbar kennen einige User den Unterschied zwischen "Um Hilfe bitten" und "Die Gutmütigkeit anderer Forummitglieder ausnutzen" nicht mehr.
Und das nervt mich.
Du hast recht.
Ich entschuldige mich für meine plumpe Reaktion.
Ich habe viele Ansätze gefunden, es schien aber keiner für mich zu passen.
Und auch nach Anpassungsversuchen bin ich nicht zum Ziel gekommen - deshalb meine Frage.
Schwamm drüber. Wenn du nicht nachtragend bist, bin ich es auch nicht ;)
Zitat von: Otto123 am 10 Februar 2021, 18:09:50
Ist dieses Frage jetzt eigentlich mit meinem Beispiel beantwortet?
Weil: unterm Strich ist es Wurst ob Du AttrVal oder ReadingsVal nimmst, das Ergebnis sollte gleich sein.
Ich habe das Problem: "Es ist kein TimeSPec" - nicht verstanden, allerdings hast Du auch überhaupt keine Infos dazu geliefert.
Nützlich zu meinem Verständnis wäre z.B. ein list dummy_TimeCons gewesen ;) siehe auch hier (https://forum.fhem.de/index.php/topic,71806.0.html)
Stimmt.
Ein paar Eckdaten wären sicherlich hilfreich gewesen.
Dein Beispiel scheint geholfen zu haben.
Werde ich morgen früh sehen, ob meine Rollläden hochfahren.
Nachdem ich noch einmal über mein Konstrukt nachgedacht habe, ist mir eine andere Lösung eingefallen.
Dennoch, meine Einstiegsfrage, ob man parsen kann, ist geblieben und wurde mit deinem Post aus dem anderen Thread beantwortet.
Dankeschön Otto (mal wieder).
Ich wünsche einen schönen Abend.
Hallo,
leider muss ich euch noch einmal behelligen.
Ich habe drei Dummys
define dummy_TimeConst_Morning_wo dummy
set dummy_TimeConst_Morning_wo 06:32
und
define dummy_Sonnenaufgang dummy
define dummy_Sonnenuntergang dummy
define at_Sonne1 at +*01:00 { my $s = sunrise_abs();; fhem("set dummy_Sonnenaufgang $s");; $s = sunset_abs();; fhem("set dummy_Sonnenuntergang $s");; }
Ein
{ReadingsVal('dummy_TimeConst_Morning_wo','state','')}
{ReadingsVal('dummy_Sonnenaufgang','state','')}
{ReadingsVal('dummy_Sonnenuntergang','state','')}
Über das FHEM-Textfeld spuckt auch die korrekten Werte aus.
Nun möchte ich mir ats daraus erzeugen:
define AT_TEST1 at *{ReadingsVal('dummy_TimeConst_Morning_wo','state','')} {}
-> Fuktioniert!
define AT_TEST5 at *{ReadingsVal('dummy_Sonnenaufgang','state','')} {}
define AT_TEST5 at *{ReadingsVal('dummy_Sonnenuntergang','state','')} {}
-> Fehlermeldung: the function "ReadingsVal('dummy_Sonnenaufgang','state','')" must return a timespec and not .
Womit wir wieder beim Parsen wären.
list dummy_TimeConst_Morning_wo:
Internals:
CFGFN ./FHEM/000_wetter.cfg
FUUID 60253e93-f33f-1ce0-efd3-ec0152b6719c8e9a
NAME dummy_TimeConst_Morning_wo
NR 117
STATE 06:32
TYPE dummy
READINGS:
2021-02-11 15:26:27 state 06:32
Attributes:
list dummy_Sonnenaufgang:
Internals:
CFGFN ./FHEM/000_wetter.cfg
FUUID 60253e93-f33f-1ce0-cecd-67107f78c6e206db
NAME dummy_Sonnenaufgang
NR 112
STATE 06:52:26
TYPE dummy
READINGS:
2021-02-11 14:13:30 state 06:52:26
Attributes:
Folgenden Lösungsansatz habe ich gefunden:
https://forum.fhem.de/index.php?topic=113074.0
...war für mich aber nicht hilfreich, oder ich stehe wieder auf dem Schlauch...
@Otto:
Dein Beitrag aus dem anderen Thread half mir zumindest schon einmal für dummy_TimeConst_Morning_wo
Dürfte ich um einen Denkanstoß bitten?
Hi,
ist erstmal nicht logisch und leider durch mich nicht nachvollziehbar. Funktioniert bei mir 1:1 mit deinem Code:
define dummy_Sonnenaufgang dummy
define dummy_Sonnenuntergang dummy
define at_Sonne1 at +*01:00 { my $s = sunrise_abs();; fhem("set dummy_Sonnenaufgang $s");; $s = sunset_abs();; fhem("set dummy_Sonnenuntergang $s");; }
set at_Sonne1 execNow
define AT_TEST5 at *{ReadingsVal('dummy_Sonnenaufgang','state','')} {}
Ergebnis
Internals:
CFGFN
COMMAND {}
DEF *{ReadingsVal('dummy_Sonnenaufgang','state','')} {}
FUUID 6025449b-f33f-27f7-8d3c-b410587d16c9c7c7
NAME AT_TEST5
NR 508624
NTM 06:57:54
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 06:57:54
TIMESPEC {ReadingsVal('dummy_Sonnenaufgang','state','')}
TRIGGERTIME 1613109474
TRIGGERTIME_FMT 2021-02-12 06:57:54
TYPE at
READINGS:
2021-02-11 15:52:11 state Next: 06:57:54
Attributes:
Kein Fehler.
Muss irgendwie an Deinem Setup liegen?
Allerdings kannst Du doch einfach direkt at mit sunrise und sunset definieren?
Gruß Otto
Hallo Otto,
mit
set at_Sonne1 execNowfunktioniert die Definition von
define AT_TEST5 at *{ReadingsVal('dummy_Sonnenaufgang','state','')} {}bei mir auch ohne Probleme - ohne nicht.
Sollte ich dann vor jedem at-define ein
set at_xxx execNow ausführen?
ZitatAllerdings kannst Du doch einfach direkt at mit sunrise und sunset definieren?
Das ist richtig.
Hatte ich bisher auch.
Aber wenn für meine Bedürfnisse der "Sonnenaufgang" mal zu einer anderen Zeit stattfinden soll brauch ich nur an einer Stelle den Reading-Wert ändern und
meine gesamten Devices, deren
ats davon abhängen ändern sich automatisch.
"Sonnenaufgang" ist in diesem Fall vielleicht nicht das repräsentativste Beispiel. Ich möchte das selbe Konstrukt auch noch für Dämmerung verwenden...
Naja execNow löst doch nur das Schreiben in den Dummy aus. solange der noch leer ist kann es ja nicht funktionieren!? Ich wollte keine Stunde warten.
Nachdem es jetzt ein paar Stunden so gelaufen ist und der dummy durch DEIN at mehrfach überschrieben wurde, funktioniert es immer noch. ;D
ZitatIch wollte keine Stunde warten.
Nicht?! :D
{ReadingsVal('dummy_Sonnenaufgang','state','')}Als Eingabe in das FHEM-Textfeld gibt aber den passenden Wert aus.
Auch ohne
execNow ... ?!
Aber set Dummy ist set Dummy, wer das ausführt ist egal :o
BTW Sonnenaufgang und Dämmerung sind für mich ziemlich gleich gelagert - aber egal. Du willst es über Dummies - so sei es.
ZitatAber set Dummy ist set Dummy, wer das ausführt ist egal
Richtig, deshalb bin ich verwundert. Doch nun scheint es zu funktionieren. Abwarten ...
ZitatSonnenaufgang und Dämmerung sind für mich ziemlich gleich gelagert
Auch richtig.
Aber guck mal:
define dummy_Sonne_schummer dummy
define dummy_Sonne_daemmer dummy
define at_Sonne2 at +*01:00 { my $s = sunset_abs("HORIZON=-0.50",0);; fhem("set dummy_Sonne_schummer $s");; $s = sunset_abs("HORIZON=-3.79",0);; fhem("set dummy_Sonne_daemmer $s");; }Ein Teil meiner Rollläden fahren um
sunset_abs("HORIZON=-0.50",0) und der Rest um
sunset_abs("HORIZON=-3.79",0)Bekannterweise ändern sich die Uhrzeiten täglich - Richtung Sommer später, Richtung Winter früher.
Ich hab 12 Rollläden.
Bei 4 Rollläden habe ich das at bisher mit
define at_xxx at *{sunset_abs("HORIZON=-0.50",0)} {..} definiert, bei den restlichen 8 mit
define at_xxx at *{sunset_abs("HORIZON=-3.79",0)} {..}Sechs (Außen)Lampen hängen dort auch noch mit dran.
Soll heißen, wenn mir das Einschalten der Lampen / das Fahren der Rollläden zu früh oder spät ist, musste ich bisher 18
ats editieren.
Nun definiere ich die 18
ats einmalig neu mit z.B.:
define AT_TEST7 at *{ReadingsVal('dummy_Sonne_schummer','state','')} {}
define AT_TEST8 at *{ReadingsVal('dummy_Sonne_daemmer','state','')} {}Wenn mir JETZT die Uhrzeiten nicht passen brauche ich nur noch die
HORIZON-Werte an einer einzigen Stelle, nämlich in
at_Sonne2 abändern und alle anderen 18
ats bekommen das automatisch mit.
Puh, ich hoffe das war halbwegs verständlich erklärt?! :o
EDIT:
allzu oft passt man die Zeiten ja nicht an. Das stimmt schon. Wenn es einmal passt, passt es eben.
Mir geht es dabei hauptsächlich um Konsistenz. Und wenn man mal etwas ändern muss, tut man das eben an einer bis zwei Stellen, statt an 18 ...
Ich weiß Dummies kosten kein Geld :)
Aber zur Übersichtlichkeit tragen sie nicht unbedingt bei. Denk mal drüber nach, einen Dummy mit mehreren Readings auszustatten, anstatt nur den state zu setzen. Entweder mit setreading oder mit setList und readingList ...
Oder man könnte die readings auch an dem Zentralen at schreiben ...
Ok. Danke für den Hinweis!
Ich werde jetzt erstmal zwei-drei Tage beobachten, ob das Verhalten meinen Erwartungen entspricht.
Dann werde ich noch einmal über die Optimierung nachdenken.
Ich danke für deine Hilfe und wünsche einen schönen Abend ;)
Hallo,
so, der Test war bedingt erfolgreich.
die Dummies selbst:
dummy_Sonne_daemmer
dummy_Sonne_schummer
werden automatisch und korrekt gesetzt.
Getestet mit:
{ReadingsVal('dummy_Sonne_daemmer','state','')}
{ReadingsVal('dummy_Sonne_schummer','state','')}
Die ats wiederum haben sich nicht selbstständig aktualisiert:
define AT_TEST8 at *{ReadingsVal('dummy_Sonne_daemmer','state','')} {}
define AT_TEST7 at *{ReadingsVal('dummy_Sonne_schummer','state','')} {}
Bei beiden stehen bei Next: noch die "alten" Uhrzeiten von gestern drin.
Ich habe die Defines der ats direkt in der fhem.cfg und erst wenn ich Save fhem.cfg klicke (also die Defines neu ausgeführt werden) ändern sich auch die entsprechenden Uhrzeiten unter Next:
... Ist das normales Verhalten?
Zitat von: remo am 12 Februar 2021, 10:40:13
... Ist das normales Verhalten?
Ja.
Habe ich ja hier bereits geschrieben: https://forum.fhem.de/index.php/topic,118660.msg1130980.html#msg1130980
Du brauchst noch "irgendwas" (z.B. notify), was beim Verändern der Uhrzeit im dummy eben das at neu anlegt/ändert: defmod...
Gruß, Joachim
Gut. Ok.
Klingt plausibel.
Ich habe zu defmod auch nochmal in der Doku nachgelesen.
defmod AT_TEST7 at *{ReadingsVal('dummy_Sonne_schummer','state','')} {}
defmod AT_TEST8 at *{ReadingsVal('dummy_Sonne_daemmer','state','')} {}
Schmeißt erst einmal keine Fehler.
Reicht das so aus oder habe ich defmod falsch verstanden?
Daran habe ich gestern auch noch gedacht, aber: Was ist denn der Unterschied zu der Form mit *{sunrise()}. Da wird doch auch jeden Tag ein neues at gesetzt? Siehe mein Zitat aus #1 bzw. Doku zu at. Das at weiß das es bei {sunrise} etwas anderes machen muss - kann sein?
Was wiederum für meine Variante sprechen würde. Man kann ja das at mit sunrise definieren und die Parameter von sunrise aus einem Dummy lesen :) - falls man wirklich ständig den Sonnenaufgang manipulieren will :)
BTW: die Verwendung der abs Funktionen im at (siehe #20) erscheint zwar irgendwie "optisch" gut, ist aber für die Abläufe des Wechsel der Sonnenläufe (Winter und Sommersonnenwende) falsch.
Zu #25 Da wäre modify auch ein probates Mittel https://fhem.de/commandref_DE.html#modify
Dankeschön für den Input.
Ich wünsche ein schönes Wochenende!
Hallo,
ich muss dieses Thema nochmals aufgreifen.
Bezugnehmend auf meine Bewässerungssteuerung:
https://forum.fhem.de/index.php/topic,116443.105.html
Ich habe einen Dummy mit selbst angelegten Readings:
Internals:
CFGFN ./FHEM/004_bewaesserung.cfg
FUUID 606ee4ad-f33f-1ce0-6906-73363ca3f3c75138
NAME dummy_BewaesserungAuto_VorneSeite
NR 447
STATE off
TYPE dummy
READINGS:
2021-04-08 13:13:07 duration 45
2021-04-08 13:13:12 fri X
2021-04-08 13:13:08 mon X
2021-04-08 13:13:13 sat -
2021-04-08 13:13:05 start 00:15
2021-04-08 13:10:37 state off
2021-04-08 13:13:14 sun X
2021-04-08 13:13:11 thu -
2021-04-08 13:13:09 tue X
2021-04-08 13:13:10 wed -
Attributes:
alias vorne + Seite
devStateIcon on:ios-on-green:off off:ios-off:on .*:ios-NACK:off
group 01_Zeitprogramme (autom. sprengen/wässern)
readingList state start duration mon tue wed thu fri sat sun
room BEWÄSSERUNG
setList state:on,off
start: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,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,00:00
duration:15,30,45,60,90,120,180 mon:X,- tue:X,- wed:X,- thu:X,- fri:X,- sat:X,- sun:X,-
sortby 1
webCmd :start:duration:mon:tue:wed:thu:fri:sat:sun
webCmdLabel :Start:Dauer:Mo:Di:Mi:Do:Fr:Sa:So
So weit. So gut.
Dann erzeuge ich mir ein at:
define at_BewaesserungAuto_VorneSeite at *{ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start','')} { magic }
Bei jedem save oder Save fhem.cfg erhalte ich allerdings folgende Fehlermeldung:
"ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start','')" must return a timespec and not .
Füge ich in meine Config vor Erzeugung des at ein setreading dummy_BewaesserungAuto_VorneSeite start 23:00 ein,
speichert FHEM ohne Fehlermeldung -
kommentiere ich das setreading ... wieder heraus, bringt FHEM wieder o.g. Fehlermeldung.
Das setreading dummy_BewaesserungAuto_VorneSeite start 23:00 kann ich in meiner Config aber nicht stehen lassen,
da sich sonst jedes Mal wenn ich eine Änderung speichere (save oder Save fhem.cfg) der Wert des Readings start des Dummys
wieder auf den festen Wert 23:00 zurücksetzt.
Ich benötige das für meine Steuerung aber dynamisch und möchte nicht / kann nicht jedes Mal die Zeiten wieder von Hand korrigieren.
Ich hoffe ich habe das Problem halbwegs verständlich schildern können.
Liebe Grüße
Naja das Problem wird mir klar:
Beim define wird der Wert aus dem Dummy ausgelesen und fertig. Damit das funktioniert muss er zu dieser Zeit drinstehen.
Wenn z.B. in der config erst das at und dann der dummy definiert wird funktioniert das beim start von FHEM nicht.
Der Fehler mit dem save ist bei mir nicht nachvollziehbar. Aber Du editierst ja direkt - da ist alles anders :)
ersatzweise musst Du sowas definieren:
ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start','11:11')
Wie das Ganze aber dynamisch funktioniert ist mir schon wieder unklar geworden.
Otto, mein Held.
Die Lösung war so einfach :-X
ZitatWenn z.B. in der config erst das at und dann der dummy definiert wird funktioniert das beim start von FHEM nicht.
Das war es nicht - darauf hab ich geachtet!
define at_BewaesserungAuto_VorneSeite at *{ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start','23:23')} { ... }das
'23:23' war es gewesen - daruf hätte ich auch echt selbst kommen können,
aber manchmal ist man einfach blind.
Dadurch wird ein Standardwert zurückgegeben, wenn keiner da ist (richtig?).
Dann definiert sich das
at ersteinmal sauber (auch wenn vorläufig, aber einmalig) mit dem "falschen" Standardwert.
Danach kann ich über das Dropdown die mir passende Zeit einstellen (
at aktualisiert sich auch).
Der neu eingestellte Wert überlebt jetzt auch einen Neustart von FHEM und ein
save.
Sieht gut aus - ich teste noch etwas ...
Gruß und Dankeschön!
Zitat von: remo am 08 April 2021, 14:08:45
Dadurch wird ein Standardwert zurückgegeben, wenn keiner da ist (richtig?).
So ist es. ;)
Zur Ergänzung noch:
ZitatcomputeAfterInit
If perlfunc() in the timespec relies on some other/dummy readings, then it will return a wrong time upon FHEM start, as the at define is processed before the readings are known. If computeAfterInit is set, FHEM will recompute timespec after the initialization is finished.
Damit bekommt man es auch geregelt, ohne die Reihenfolge in der cfg zu manipulieren.
Kommando zurück :(
Nach Save fhem.cfg oder shutdown restart setzt sich der STATE des at wieder zurück auf den Standardwert, wie er im at definiert ist
define at_BewaesserungAuto_VorneSeite at *{ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start','23:23')} { ... }
nämlich auf "23:23" - siehe Anhänge.
Ergänzung:
Nach dem Neustart von FHEM setzt sich das at ja wieder auf die Standardzeit zurück (23:23).
Das Reading "start" im Dummy bleibt aber erhalten.
Setze ich nun das at mittels inactive auf deaktiviert und danach mit active wieder auf aktiviert,
erhält der STATE des at wieder den passenden Wert des "start"-Readings des Dummys.
define notify_BewaesserungAuto_VorneSeite_EIN notify dummy_BewaesserungAuto_VorneSeite.on { fhem ("set at_BewaesserungAuto_VorneSeite active") }
define notify_BewaesserungAuto_VorneSeite_AUS notify dummy_BewaesserungAuto_VorneSeite.off { fhem ("set at_BewaesserungAuto_VorneSeite inactive") }
define notify_BewaesserungAuto_VorneSeite_START notify dummy_BewaesserungAuto_VorneSeite { \
fhem ("set at_BewaesserungAuto_VorneSeite modifyTimeSpec {(ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start',''))}") }
Auch ein
set at_BewaesserungAuto_VorneSeite modifyTimeSpec {(ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start',''))}
Über das FHEM-Eingabefeld "korrigiert" den STATE des ATs wieder ...
Zitat von: remo am 08 April 2021, 14:57:09
Nach dem Neustart von FHEM setzt sich das at ja wieder auf die Standardzeit zurück (23:23).
Das Reading "start" im Dummy bleibt aber erhalten.
Mit dem von Beta-User erwähnten Attribute wird es ordentlich beim Neustart gesetzt. Schön wäre bei der Beschreibung des Attributes noch der notwendige Inhalt gewesen - aber 1 funktioniert :)
Das heißt dann:
attr at_BewaesserungAuto_VorneSeite computeAfterInit 1
?
EDIT:
attr at_BewaesserungAuto_.* computeAfterInit 1
Werde ich testen.
Im Moment bin ich vorsichtig optimistisch.
schade, ich bin grade nicht zuhause, deshalb muss Popcorn im Moment ausfallen...
Dann hast du etwas worauf du dich freuen kannst wenn du dann zuhause bist.
...hatte bei meiner Bemerkung nur gesehen, worin das Problem bei dem einen dummy->at-Ding lag.
Nach dem Popcorn-Zwischenruf habe ich mir den ganzen Thread mal angesehen. Kann betateilchen im Moment nur zustimmen: Das ganze sieht mir nach einem unreitbaren Drachen aus, den du da zu konstruieren versuchst, das kann im Ergebnis eigentlich nur schiefgehen...
Ok. Inwiefern wird das schiefgehen?
Weil im Moment verhält sich eigentlich alles wie gewünscht..
Es mag schon sein, dass das irgendwie grade zufällig funktioniert, aber insgesamt ist das eher "Weichen von Hand" stellen und keine wirkliche Automatisierung, was aus den paar Zeilen an Kaffesatz zu erkennen ist:
Denn bei sowas wie
Zitat von: remo am 08 April 2021, 14:57:09
define notify_BewaesserungAuto_VorneSeite_EIN notify dummy_BewaesserungAuto_VorneSeite.on { fhem ("set at_BewaesserungAuto_VorneSeite active") }
define notify_BewaesserungAuto_VorneSeite_AUS notify dummy_BewaesserungAuto_VorneSeite.off { fhem ("set at_BewaesserungAuto_VorneSeite inactive") }
define notify_BewaesserungAuto_VorneSeite_START notify dummy_BewaesserungAuto_VorneSeite { \
fhem ("set at_BewaesserungAuto_VorneSeite modifyTimeSpec {(ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start',''))}") }
fragt man sich, warum das active/inactive nicht einfach Knöpfe am at sind:
defmod testat at *{sunrise()} {}
attr testat webCmd active:inactiveSetze man ein aktives at nochmal auf "active", wird auch die Zeit aktualisiert/ausgewertet... (wenn man das via Knopf machen muss/will).
Und für "diverse Sonnenaufgänge" kann man z.B. auch Twilight verwenden. Das triggert dann einfach zu diversen Zeitpunkten, was man dann z.B. auch wieder per notify abgreifen könnte (oder die Zeiten eben für "modify"/set active verwenden).
Das nur als Rückmeldung aus den paar Zeilen...
Gut. Ok.
zu z.B.:
define notify_BewaesserungAuto_VorneSeite_EIN notify dummy_BewaesserungAuto_VorneSeite.on { fhem ("set at_BewaesserungAuto_VorneSeite active") }
define notify_BewaesserungAuto_VorneSeite_AUS notify dummy_BewaesserungAuto_VorneSeite.off { fhem ("set at_BewaesserungAuto_VorneSeite inactive") }
define notify_BewaesserungAuto_VorneSeite_START notify dummy_BewaesserungAuto_VorneSeite { \
fhem ("set at_BewaesserungAuto_VorneSeite modifyTimeSpec {(ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start',''))}") }
Kann ich nur sagen, dass ich dieses Konstrukt mehrfach verwende.
Ich nutze FHEM inzwischen seit ca. fünf Jahren.
Angefangen habe ich mit einfachen Lichtschaltern und Rollladen-Aktoren ohne Automatisierung - nur stures Schalten über das Web oder TabletUI.
Nach und nach habe ich dann angefangen zeitgesteuerte Ereignisse auszulösen.
Später dann auch in Abhängigkeit vom Sonnenstand, Temperatur usw.
Mit fortschreitender Komplexität der Automatisierungen stiegen dann auch meine Anforderungen, eben diese Automatisierungen weiter zu beeinflussen und
von weiteren Bedingungen abhängig zu machen.
Dabei habe ich viel "versucht", Tutorials gelesen/geschaut und auch im Handbuch nachgelesen.
Viele Lösungen habe ich auch hier im Forum finden können.
Dabei sind dann solche Konstrukte wie oben entstanden.
Ich muss ehrlich sagen, dass ich in Sachen Zuverlässigkeit oder Leistung von FHEM keinerlei Probleme hatte.
Es gibt ja inzwischen massenhaft alternative Plattformen - welche, die vielleicht auch etwas hübscher sind oder nicht auf Perl-Module angewiesen sind oder oder oder ...
Ich habe aber niemals das Bedürfnis verspürt zu wechseln, gerade weil FHEM so stabil läuft, trotz meiner eigenartigen Ansätze (das spricht wahrscheinlich noch einmal mehr für FHEM).
Auf der anderen Seite habe ich aber auch die Erfahrung gemacht, dass man in FHEM ziemlich "genau arbeiten" sollte, weil schnell etwas schieflaufen kann.
Trotzdem funktionieren meine Notifies und ATs bisher problemlos.
Die neue Herausforderung kam dann mit meiner Bewässerung, wo ich mich neuen Hürden stellen muss.
Aber wie erwähnt: bisher ist alles iO ...
(Auch die Lösung aus diesem Thread)
Ich nehme konstruktive Kritik gerne an.
Ich bin ebenfalls gewillt die Dinge zu verstehen und auch zu optimieren.
In jedem Fall bedanke ich mich für Posts wie die von Beta-User oder Otto123 !
Ihr seid sachlich, höflich, nachsichtig und geduldig.
Macht weiter so und überlasst unangebrachte Arroganz Anderen.
Allerbeste Grüße