Waschmaschine fertig

[Damian]

In den Tiefen des Wiki's habe ich die Lösung gefunden. Das Attribut heisst "timestamp-on-change-reading" . Dadurch wird eine Aktualiserung des Timestamp des Readings unterdrückt wenn kein Event ausgelöst wird. Genial 

Wäre da nicht besser event-on-change-reading zu setzen? Da wird auch kein Timestamp gesetzt, vor allem wird kein Event erzeugt, wenn sich das Reading nicht ändert.

[romakrau]

Hallo Damian,

Danke das Du dir nochmals Gedanken gemacht hast. Der Sachverhalt ist nicht ganz einfach und ich versuche es mal so zu erklären wie ich es verstanden habe.

Das MQTT-Device "Trockner" wird alle 30 Sekunden von der Messdose aktualisiert wobei der Timestamp immer neu gesetzt. Es wird aber kein "Event" erzeugt da "event-on-change-reading" gesetzt ist. Die Abfrage "[?Trockner:SENSOR_ENERGY_Power:sec] > 300" konnte also niemals > 30 werden. Außerdem ist zum Auslösen des Kommandos immer ein Event in Verbindung mit der Abfrage des Alters des Timestamps vonnöten. Das mit dem Fragezeichen lt. Commandref erwies sich auch als falsch. Durch das Setzen des Attributs "timestamp-on-change-reading" konnte die Aktualisierung des Timestamps unterbunden werden. Theoretisch funktioniert es mittels Setzen des cmd_3 jetzt. Praktisch muss sich noch erweisen, da ich nicht die Hausbewohner wecken wollte  . Das DOIF sieht mittlerweile so aus:

Code Auswählen Erweitern

([Trockner:SENSOR_ENERGY_Power] > 0.9 and ([DF_Trockner:state] eq "cmd_4" or [DF_Trockner:state] eq "initialized"))
(set $SELF Status an, set $SELF Dauer 0, set $SELF Startkw [Trockner:SENSOR_ENERGY_Total] , ({Log 3, "Trockner: Ein"}))
DOELSEIF
([Trockner:SENSOR_ENERGY_Power] > 20 and [DF_Trockner:state] eq "cmd_1")
(set $SELF Status ProgStart, ({Log 3, "Trockner: Programmstart"}))
DOELSEIF ([Trockner:SENSOR_ENERGY_Power] < 1 and [DF_Trockner:state] eq "cmd_2")
(set $SELF Dauer {(split(' ', gmtime(ReadingsAge("$SELF","Status",0))))[3]}, set $SELF Status ProgEnde, set $SELF Endkw [Trockner:SENSOR_ENERGY_Total], set DY_Trockner on, ({Log 3, "Trockner: Programmende"}))
DOELSEIF
((([+00:03] and [Trockner:SENSOR_ENERGY_Power:sec] > 300) or [Trockner:SENSOR_ENERGY_Power] > 20 )and [DF_Trockner:state] eq "cmd_3" )
(set $SELF Status aus, set DY_Trockner off, ({Log 3, "Trockner: Aus"}))

Gruß
Roman

[Damian]

Naja, ich sehe hier:

([+00:03] and [Trockner:SENSOR_ENERGY_Power:sec] > 300)..

eine Angabe, die über einen Timer triggert, daher braucht die Abfrage der Zeit nicht zu triggern, also

([+00:03] and [?Trockner:SENSOR_ENERGY_Power:sec] > 300)..

bei den anderen Abfragen, z. B.:

[Trockner:SENSOR_ENERGY_Power] > 20

braucht man auch keinen Trigger, wenn sich der Wert von SENSOR_ENERGY_Power nicht ändert.

Daher, sollte event-on-change auf das Reading kein Problem darstellen.

[romakrau]

Das mit dem [? funktioniert nicht bei mir. Weisst du warum.

[Damian]

Das mit dem [? funktioniert nicht bei mir. Weisst du warum.

nein, wahrscheinlich ist der Wert nicht über 300

[Rheingold]

Code Auswählen Erweitern

## 3
DOELSEIF (["^PIR2(4|5)$:^Counter: "] and [?Waschmaschine_Pwr:power] < 0.1 and [?$SELF] eq "cmd_2")
   (set sag1 tts :gong: Die Waesche ist gewaschen und geschleudert)

Mal ganz blöd gefragt, was macht das " ["^PIR2(4|5)$:^Counter: "] "? 

[Damian]

Mal ganz blöd gefragt, was macht das " ["^PIR2(4|5)$:^Counter: "] "? 

Wenn das Device "PIR24" oder "PIR25" beginnend mit dem Event  "Counter:" triggert ...

[superverbleit]

Servus, ich hätte mal eine Frage.
Und zwar zum DOIF im Zusammenhang mit meinem Statusautomat und Leistungsermittlung mit meinem Trockner.

Hier mein Code

Code Auswählen Erweitern

([UG.Technik.Trockner.SchaltLeistung:state:d] > 4 and [?Trockner] =~ "cmd_5|initialized|initialize")
  (({Log 3, "Trockner: Ein"}))
  (set Stefan_Pushnachricht msg 'Trockner: Ein')
DOELSEIF ([UG.Technik.Trockner.SchaltLeistung:state:d] > 100 and [?Trockner] eq "cmd_1")
  (({Log 3, "Trockner: Programmstart"}))
  (set Stefan_Pushnachricht msg 'Trockner: Programmstart')
DOELSEIF ([UG.Technik.Trockner.SchaltLeistung:state:d] > 100 and [?Trockner] =~ "cmd_2|cmd_3")
  (({Log 3, "Trockner: Doch noch nicht fertig"}))
  (set Stefan_Pushnachricht msg 'Trockner: Doch noch nicht fertig')
DOELSEIF ([UG.Technik.Trockner.SchaltLeistung:state:d] < 5 and [?Trockner] =~ "cmd_2|cmd_3")
  (({Log 3, "Trockner: Programmende"}))
  (set Stefan_Pushnachricht msg 'Trockner: Programmende')
DOELSEIF ([UG.Technik.Trockner.SchaltLeistung:state:d] < 2 or [UG.Technik.Trockner.SchaltLeistung:state:d] > 100 and [?Trockner] eq "cmd_4")
  (({Log 3, "Trockner: Aus"}))
  (set Stefan_Pushnachricht msg 'Trockner: Aus')

Was ich gerne hätte, das der Start mit Leistungsabfrage 2x (oder halt x mal) über dem Wert von 4 sein sollte und das erst dann in den nächsten Zustand gewechselt werden soll.
Geht das über eine Hilfsvariable, oder gibt es ein passendes Attribut?

2x über 4, bedeutet dann auch, das es nicht der gleiche Wert sein soll, sondern 2 Messungen über 4 sein sollten.
Ein kleiner Tipp wäre für mich wäre klasse.
Danke euch schon mal.

[JudgeDredd]

Warum fügst Du nicht ein weiteres DOELSEIF ein ?

Code Auswählen Erweitern

([UG.Technik.Trockner.SchaltLeistung:state:d] > 4 and [?$SELF] =~ "cmd_1")
Aber möglicherweise geht es auch über ein Attribut, das kann vielleicht Jemand anderes besser.

[superverbleit]

Hey.
Da würde ich doch dann auch beim nächsten Schleifendurchgang durchkommen, oder?
Oder verstehe ich das falsch...

Vielleicht wäre auch ein Ansatz zu sagen, 2 Minuten oder Zeit x über 4, erst dann den Zustand wechseln.
Aber wie ginge das?

[JudgeDredd]

Da würde ich doch dann auch beim nächsten Schleifendurchgang durchkommen, oder?

In der Bedingung ist doch der aktuelle Status des DOIF mit drin.

Wenn das erste Event mit einer größeren Schaltleistung als 4 passiert, wird dieser Zweig getriggert:

Code Auswählen Erweitern

([UG.Technik.Trockner.SchaltLeistung:state:d] > 4 and [?Trockner] =~ "cmd_5|initialized|initialize")Wenn das zweite Event mit einer größeren Schaltleistung als 4 passiert, wird dieser Zweig getriggert:

Code Auswählen Erweitern

([UG.Technik.Trockner.SchaltLeistung:state:d] > 4 and [?$SELF] =~ "cmd_1")
Du musst dann natürlich bei den nachfolgenden Zweigen, den Abfragestatus des DOIF entsprechend anpassen.
"cmd_1" wäre dann eben "cmd_2" usw.

Vielleicht wäre auch ein Ansatz zu sagen, 2 Minuten oder Zeit x über 4, erst dann den Zustand wechseln.

Verstehe ich nicht, was Du meinst.
Wenn Du irgendwelche Verzögerungen haben möchtest, dann mit dem Attribut "wait"

[tobi01001]

Hi,

spontan hätte ich gesagt (aus der Hilfe):

Ausführung eines Kommandos nach einer Wiederholung einer Bedingung   back

Mit dem Attribut waitsame <Zeitspanne in Sekunden für cmd_1>:<Zeitspanne in Sekunden für das cmd_2>:... wird ein Kommando erst dann ausgeführt, wenn innerhalb einer definierten Zeitspanne die entsprechende Bedingung zweimal hintereinander wahr wird.
Für Kommandos, für die waitsame nicht gelten soll, werden die entsprechenden Sekundenangaben ausgelassen oder auf Null gesetzt.

Anwendungsbeispiel: Rollladen soll hoch, wenn innerhalb einer Zeitspanne von 2 Sekunden ein Taster betätigt wird

define di_shuttersup DOIF ([Button])(set shutters up)
attr di_shuttersup waitsame 2
attr di_shuttersup do always

oder

Durchschnitt, Median, Differenz, Änderungsrate, anteiliger Anstieg   back

Die folgenden Funktionen werden auf die letzten gesendeten Werte eines Readings angewendet. Das angegebene Reading muss Events liefern, damit seine Werte intern im Modul gesammelt und die Berechnung der angegenen Funktion erfolgen kann.

Syntax

[<device>:<reading>:<function><number of last values>]

<number of last values> ist optional. Wird sie nicht angegeben, so werden bei Durchschnitt/Differenz/Änderungsrate/Anstieg die letzten beiden Werte, bei Median die letzten drei Werte, ausgewertet.

Durchschnitt

Funktion: avg

Bsp.:

define di_cold DOIF ([outdoor:temperature:avg5] < 10)(set cold on)

Wenn der Durchschnitt der letzten fünf Werte unter 10 Grad ist, dann wird die Anweisung ausgeführt.

Hängt ein bisschen vom Verhalten der Leistung des Trockners ab.

Gruß,
Tobias

[superverbleit]

Jetzt muss ich nochmals generell zum DOIF nachfragen.

Das DOIF wird doch stetig kontinuierlich (zyklisch zur Zeit x) irgendwo im Hintergrund ausgeführt. Richtig? So kenne ich das halt von C/C++.
Oder wird es durch das Reading (Veränderung des Werts von UG.Technik.Trockner.SchaltLeistung:state:d ausgelöst, das wäre eleganter.

Somit würde doch der Vorschlag JudgeDredd mit einem weiteren DOELSEIF folgendermaßen ablaufen.
Wenn die Leistung durch das Reading größer 4 wird, durchlaufe ich die erste Bedinung.
Ein weiteres Reading passiert erst so ungefähr 1 Minute später, der Wert bleib also gleich, sagen wir 4,3.
Beim nächsten Durchlauf der States (wird ja im Millisekundenbereich liegen, somit komme ich dann durch die 2. Bedingung mit dem selben Reading durch.
Das wäre dann genau das, was ich nicht will.
Liege ich mit dieser Annahme richtig?

Das Attribut wait, habe ich in einem anderen Anwendungsfall schon im Einsatz, verzögert ja nur die Aktionen innerhalb eines States. Richtig?

Das Attribut waitsame (Idee von tobi01001) hört sich richtiger an, habe ich da jedoch nicht das gleiche Problem wie mit einem weiteren DOELSEIF?
Oder werden da mindestens 2 Readings (Unterschiedliche Werte von UG.Technik.Trockner.SchaltLeistung:state:d zur Auswertung herangezogen?

Das sind mal die generellen Fragen hierzu, werde das mit dem waitsame auch nochmals ausprobieren.

Das mit dem Durchschnitt (Idee von tobi01001)  probiere ich gleich mal aus, das könnte auf Anhieb funktionieren.

Danke schon mal für eure Hilfe. 

[JudgeDredd]

Das DOIF wird doch stetig kontinuierlich (zyklisch zur Zeit x) irgendwo im Hintergrund ausgeführt.

Devices reagieren durch triggern auf erzeugte Events, da wird nix im Hintergrund abgefragt oder ausgeführt.

Wirf doch mal einen Blick in den Eventmonitor, da siehst Du alle Events die getriggert werden könnten.
Welche getriggert werden entscheidest du im Device (z.B. DOIF, Notify, etc ...) via einer Regex.

Also um die Funktionsweise von FHEM zu verstehen, sollten Begriffe wie:

• Modul
• Device
• Reading
• Attribut
• Event
• Trigger
• Regular Expression (RegEx)

unbedingt klar sein.

Wie der spezielle Fall hier mit Attributen zu lösen ist, kann ich nicht im Detail sagen, da ich DOIFs nur in absoluten Ausnahmefällen verwende und der Funktionsumfang von DOIF doch recht umfangreich ist.

Hast Du denn das vorhandene Device zur Waschmaschinen-Abfrage selbst kreiert oder ist das nur von irgendwo kopiert ?

[superverbleit]

Das Grundkonstrukt kommt aus dem Beitrag hier, ich habe es halt noch meinen Bedürfnissen angepasst.

Das mit dem Eventmonitor schaue ich mir an.
Danke für deine Hilfe.