AttrVal -> TimeSpec

[remo]

Otto, mein Held.
Die Lösung war so einfach 

Wenn 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!

Code Auswählen Erweitern

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!

[Otto123]

Dadurch wird ein Standardwert zurückgegeben, wenn keiner da ist (richtig?).

So ist es.

[Beta-User]

Zur Ergänzung noch:

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

[remo]

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

Code Auswählen Erweitern

define at_BewaesserungAuto_VorneSeite at *{ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start','23:23')} { ... }

nämlich auf "23:23" - siehe Anhänge.

[remo]

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.

Code Auswählen Erweitern

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

Code Auswählen Erweitern

set at_BewaesserungAuto_VorneSeite modifyTimeSpec {(ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start',''))}

Über das FHEM-Eingabefeld "korrigiert" den STATE des ATs wieder ...

[Otto123]

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

[remo]

Das heißt dann:

Code Auswählen Erweitern

attr at_BewaesserungAuto_VorneSeite computeAfterInit 1

?

EDIT:

Code Auswählen Erweitern

attr at_BewaesserungAuto_.* computeAfterInit 1

Werde ich testen.
Im Moment bin ich vorsichtig optimistisch.

[betateilchen]

schade, ich bin grade nicht zuhause, deshalb muss Popcorn im Moment ausfallen...

[remo]

Dann hast du etwas worauf du dich freuen kannst wenn du dann zuhause bist.

[Beta-User]

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

[remo]

Ok. Inwiefern wird das schiefgehen?
Weil im Moment verhält sich eigentlich alles wie gewünscht..

[Beta-User]

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

defmod testat at *{sunrise()} {}
attr testat webCmd active:inactive
Setze 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...

[remo]

Gut. Ok.

zu z.B.:

Code Auswählen Erweitern

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