neue Features: defaultvalue, readingList, Ereignisfilter, Attribut checkall

[Damian]

Verstehe. Was würdest Du empfehlen, um einerseits keine planbaren Aktionen zu haben und andererseits aus dieser "Falle" herauszukommen?

Das hängt immer vom Anwendungsfall ab. Das Beispiel aus der Commandref :

Code Auswählen Erweitern

define di_light DOIF ([([Fixtime]-[01:00]-int(rand(300))) - ([Fixtime]+[01:00]+int(rand(300)))]|7])
(set lampe on)
DOELSE
(set lampe off)


ist unkritisch trotz einer zufälligen Verlängerung des Intervalls, weil es keinen weiteren Trigger hier gibt, der in der Zwischenzeit zuschlagen könnte. Hier kann der Zustand also nicht toggeln.

Zufällige Schaltzeitpunkte würde ich, wie von Ellert vorgeschlagen, mit wait realisieren. Zumal man in wait inzwischen jede beliebige Berechnung vornehmen kann.


Auch diese Anwesenheitssimulation aus der Commandref ist unkritisch. Sie realisiert den zufälligen Ausschaltzeitpunkt  mit Hilfe des on-for-timers.

Code Auswählen Erweitern


define di_presence_simulation DOIF ([19:00-00:00])(set lamp on-for-timer {(int(rand(1800)+300))}) DOELSE (set lamp off)
attr di_presence_simulation repeatcmd rand(3600)+2200

[Yil]

Das kann ich alles sehr gut nachvollziehen und habe einen Teil meiner Umsetzung auch von dort ennommen.

Problematisch wird es durch den Zusatz "|7" bzw. "|8" - prinzipiell (soweit ich die Commandref) verstanden habe, ist es doch möglich, für unterschiedliche Tage unterschiedliche Steuerungen zu haben. Genau das habe ich gemacht. Ich erweitere damit mal Dein Beispiel aus der Commandref:

Code Auswählen Erweitern

define di_light DOIF ([([Fixtime]-[01:00]-int(rand(300))) - ([Fixtime]+[01:00]+int(rand(300)))]|7])
(set lampe on)
DOELSIF ([([Fixtime]-[00:30]-int(rand(200))) - ([Fixtime]+[00:30]+int(rand(200)))]|8])
(set lampe on)
DOELSE
(set lampe off)

Im Ergebnis würden dann zwei neue Trigger hinzukommen, die genau zwischen den Triggern der ersten Bedingung liegen und - so mein Verdacht und meine bisherige Beobachtung - für ein Abschaltender Lampe sorgen. Ist das dann nicht eigentlich ein Bug? Denn das gewünschte und erwartete Verhalten wäre ja, dass sich die Trigger werktags mit den Triggern für das Wochenende nicht ins Gehege kommen.

Ansonsten probiere ich mal den wait-Timer mit Zufallszahl aus.

[Damian]

Bei wochentagabhängigen Zeitintervallen gibt es noch ein Problem. Z. T. wird das Modul immer (also an allen Tagen, nicht nur an den angegebenen Wochentagen) an jeweiligen Zeiten getriggert und das Intervall wird geprüft und wenn es nicht wahr ist, wird der DOELSE-Fall ausgeführt. Das dürfte hier das Problem sein.

Auf meiner todo-Liste steht bereits:

1. Intervalle werden nur noch an den angegebenen Wochentagen getriggert, damit kann nicht unverhofft der DOELSE-Fall kommen.

ein zweiter Punkt, der hier zumindest unproblematisch ist, ist

2. Intervalle, wo die Anfangszeit mit der Endzeit identisch ist, werden nicht getriggert, das Intervall ist nicht wahr.

Vielleicht schaffe ich diese Punkte noch in die aktuelle Beta-Version einzubauen.


Edit:

Diese Angabe sollte zunächst dein Problem lösen:

Code Auswählen Erweitern

define di_light DOIF ([([Fixtime]-[01:00]-int(rand(300))) - ([Fixtime]+[01:00]+int(rand(300)))]|7] or
                              [([Fixtime]-[00:30]-int(rand(200))) - ([Fixtime]+[00:30]+int(rand(200)))]|8])
(set lampe on)
DOELSE
(set lampe off)


so gibt es nur zwei Zustände. Bei zusätzlichen Triggern wird nicht in DOELSE geschaltet, wenn eines der beiden Intervalle noch wahr ist.

[Yil]

Hi Damian,

danke für die Aufklärung. DA haben wir sie wieder - die berühmte DOELSE-Falle 

Die Oder-Verknüpfung macht natürlich Sinn, das leuchtet mir sofort ein. Kann ich innerhalb eines Commands abfragen, welche Bedingung die Schaltung ausgelöst hat - bei einer Oder-Verknüpfung also der erste oder der zweite Teil? Das wäre an einer anderen Stelle zur Steuerung von Dummys ganz hilfreich.

VG Yil

[yogiflop]

Guten Morgen,

ich habe da ein ähnliches Problem, siehe -> https://forum.fhem.de/index.php/topic,61228.0.html<- und wollte mal fragen wann denn immer getriggert wird. Wenn ich den Zufall ins wait lege, kann ich im Reading nicht mehr sehen, wann es nun genau an und aus geht.
Kurios finde ich auch, das bei einer festen Zeit, der Zufallswert sich nicht ändert (Spalte 1 und 4) aber bei den Werten die vom Twilight abhängen schon. Obwohl sich der Twilightwert an sich ja auch nicht geändert. Es mag sein, das sich der Twilightwert beim erreichen des Zeitpunktes einmal am Abend ändert, aber doch nicht vier mal wie in meinem Beispiel. Die Bilder sind alle innerhalb einer halben Stunde aufgenommen.

Marc

[Damian]

Guten Morgen,

ich habe da ein ähnliches Problem, siehe -> https://forum.fhem.de/index.php/topic,61228.0.html<- und wollte mal fragen wann denn immer getriggert wird. Wenn ich den Zufall ins wait lege, kann ich im Reading nicht mehr sehen, wann es nun genau an und aus geht.
Kurios finde ich auch, das bei einer festen Zeit, der Zufallswert sich nicht ändert (Spalte 1 und 4) aber bei den Werten die vom Twilight abhängen schon. Obwohl sich der Twilightwert an sich ja auch nicht geändert. Es mag sein, das sich der Twilightwert beim erreichen des Zeitpunktes einmal am Abend ändert, aber doch nicht vier mal wie in meinem Beispiel. Die Bilder sind alle innerhalb einer halben Stunde aufgenommen.

Marc

Der "Zufall" ändert die Zeit, wenn der Timer getriggert wird und die neue Zeit berechnet wird. Für Twilight gilt das, was ich schon in der Commandref dazu geschrieben habe:

http://fhem.de/commandref_DE.html#DOIF_checkReadingEvent Stichwort checkReadingEvent

[Brockmann]

Wäre es möglich, dass DOIF neben Readings und Internals auch Attribute verwenden kann?

Im Zusammenhang mit der Generalisierbarkeit wäre das nützlich. Wenn man seine Geräte wie oft empfohlen systematisch benennt, sind die Namen oftmals suboptimal für einfache Messages (WAF!) oder Sprachausgabe. Dann wäre es prima, wenn man etwa bei einer Battery- oder Fenster offen-Warnung auf den Alias oder auch die Room-Angabe zurückgreifen könnte. Oder auch ein extra für diesen Zweck angelegtes userattr.

Wenn man das ganze auch in Konditionen verwenden könnte, hätte man außerdem die Möglichkeit, schon in den Bedingungen zu prüfen, ob ein Gerät beispielweise zu einer bestimmten Gruppe oder in einen bestimmten Raum gehört. So ließen sich Generalisierungen auch wieder gezielt auf eine bestimmte Gruppe von Geräten einschränken.

[igami]

Wäre es möglich, dass DOIF neben Readings und Internals auch Attribute verwenden kann?

Genau das hätte ich gestern gebraucht
Die Frage ist nur welches Zeichen man dafür verwenden sollte.

[Per]

Oder auch ein extra für diesen Zweck angelegtes userattr.

Du kannst ja ein Userreading erstellen. Das geht ja jetzt schon auszuwerten.

[Damian]

Ich glaube das Thema hatten wir schon mal. Man müsste ein Zeichen nehmen, was im Device nicht vorkommen kann. § haben wir noch nicht !$@ haben oft schon andere Bedeutung.

Man kann in der Bedingung aber auch die AttrVal-Funktion nutzen ohne Triggerfunktionalität.


Ich habe allerdings  auf der todo-Liste noch andere Sachen stehen und gerade etwas wenig Zeit.

Gruß

Damian

[Damian]

Version 0.9

Änderung:

A-Z_<persistent user defined readingname>
benutzerdefinierte Readings beginnend mit einem Großbuchstaben mit Unterstrich als Präfix überdauern ein Modify

Interne Funktionsaufrufe weiter optimiert (interne Perl-Bedingungen in der list-Übersicht sind kürzer und damit besser bei Analysen lesbar)

[Ellert]

Version 0.9

Änderung:

A-Z_<persistent user defined readingname>
benutzerdefinierte Readings beginnend mit einem Großbuchstaben mit Unterstrich als Präfix überdauern ein Modify

Interne Funktionsaufrufe weiter optimiert (interne Perl-Bedingungen in der list-Übersicht sind kürzer und damit besser bei Analysen lesbar)

Auch die Version 0.9 läuft seit heute mittag problemlos im Wirkbetrieb.
Die persistenten Readings [A-Z]_ sind dauerhaft und die mit _ verschwinden nach einem Modify, die Timer-Readings werden korrekt zweistellig angezeigt und die alten Timer-Readings wurden gelöscht. Das Wiki ist angepasst, ich warte nur noch darauf, den Hinweis auf die Beta-Version entfernen zu können 

[Damian]

Auch die Version 0.9 läuft seit heute mittag problemlos im Wirkbetrieb.
Die persistenten Readings [A-Z]_ sind dauerhaft und die mit _ verschwinden nach einem Modify, die Timer-Readings werden korrekt zweistellig angezeigt und die alten Timer-Readings wurden gelöscht. Das Wiki ist angepasst, ich warte nur noch darauf, den Hinweis auf die Beta-Version entfernen zu können 

Gut, mein Haus steht auch noch

Dann werde ich es einchecken und dann schauen wir mal, was morgen passiert.

Mehr will ich erst mal nicht rein packen.

Gruß

Damian

[iamandy]

Ehrlich gesagt, ich habe für mich noch nichts gefunden, um checkall einzusetzen.

Ich hätte vielleicht einen Fall für "Checkall". Ich habe ein DOIF das mich alarmiert wenn gewisse werte älter als x sind. Dann gehe ich davon aus das irgendetwas nicht stimmt und schicke mir einen Alarm. Also ein läuft mein System noch richtig Check...

Mir ist aufgefallen das

Code Auswählen Erweitern

[HeizThermo.Wohnzimmer:temperature:sec]   > 28800 nicht zwingend funktioniert, wenn ich dazu ein

Code Auswählen Erweitern

[+:11] nehme dann klappt es, denn dann erzeuge ich mir ja das nötige Event. Ich habe einige DOELSEIFs...

Jetzt zum Checkall. Ich würde mir vorstellen das ich bei Checkall = 1 nur ein mal

Code Auswählen Erweitern

[+:11] beim DOIF benötige und dieses nicht für jedes DOELSEIF benötige...

Hier ein Codeausschnitt...:

Code Auswählen Erweitern

DOIF
(      [+:11] and
       [HeizThermo.Wohnzimmer:temperature:sec]   > 28800   ## MAX Check
)(     set pushandy msg 'Alarm' 'Curren Value Check - MAX'     )

DOELSEIF
(      [+:11] and
       [Arbeitszimmer.Temp:temperature:sec]      > 14400    ## AZ Check
)(     set pushandy msg 'Alarm' 'Curren Value Check - AZ'      )


[Damian]

Ich hätte vielleicht einen Fall für "Checkall". Ich habe ein DOIF das mich alarmiert wenn gewisse werte älter als x sind. Dann gehe ich davon aus das irgendetwas nicht stimmt und schicke mir einen Alarm. Also ein läuft mein System noch richtig Check...

Mir ist aufgefallen das

Code Auswählen Erweitern

[HeizThermo.Wohnzimmer:temperature:sec]   > 28800 nicht zwingend funktioniert, wenn ich dazu ein

Code Auswählen Erweitern

[+:11] nehme dann klappt es, denn dann erzeuge ich mir ja das nötige Event. Ich habe einige DOELSEIFs...

Jetzt zum Checkall. Ich würde mir vorstellen das ich bei Checkall = 1 nur ein mal

Code Auswählen Erweitern

[+:11] beim DOIF benötige und dieses nicht für jedes DOELSEIF benötige...

Hier ein Codeausschnitt...:

Code Auswählen Erweitern

DOIF
(      [+:11] and
       [HeizThermo.Wohnzimmer:temperature:sec]   > 28800   ## MAX Check
)(     set pushandy msg 'Alarm' 'Curren Value Check - MAX'     )

DOELSEIF
(      [+:11] and
       [Arbeitszimmer.Temp:temperature:sec]      > 14400    ## AZ Check
)(     set pushandy msg 'Alarm' 'Curren Value Check - AZ'      )


checkall funktioniert nur bei Ereignissen. Zeittrigger sind nur zum Triggerzeitpunkt wahr und sonst nicht, deswegen macht es auch keinen Sinn die Bedingungen zu prüfen, wo der Zeittrigger nicht ausgelöst hat.

Edit: Ich sehe gerade, dass du natürlich die anderen Zeittrigger weglassen willst. Es wird wohl dennoch nicht funktionieren, da checkall z. Zt. nur bei Events funtioniert.