Aktion nur einmal pro 15 Minuten ausführen - einfache Frage

[Frood42]

Das wird jetzt bissl Multi und Off topic aber ok.
Den

Code Auswählen Erweitern


defmod di_venti_an

kann ich mit dem med beeinflussen, ja.

Aber der Wert selbst wird über das DB Modul direkt in die DB gesendet.
Ich habe immer noch keinen Weg gefunden an der Stelle den Ausreißer zu ignorieren.
Die Sensoren sind alle günstige IT oder Pearl Sensoren für Wetter Stationen die über Signalduino reinkommen.

[Otto123]

Naja aus meiner Sicht ein ähnliches Thema wie mit deinem do always - bloß am anderen Ende. Hier würde ich nicht im Nachgang Mittelwerte bilden, sondern offensichtliche Ausreißer an der Quelle eliminieren. Also am Sensordevice, beim loggen der der Werte also möglichst weit vorn entscheiden: der Wert passt oder den lass ich einfach weg.
Ein userReading mit Sinnfälligkeit, also if kleiner if größer und nur die Werte im Toleranzband nehmen.

Es gab da immer mal schon ähnliche Beiträge, als Beispiel für die Google Suche: site:forum.fhem.de ds1820 ausreißer

Gruß Otto

[Damian]

Code Auswählen Erweitern

defmod di_venti_an DOIF ([$SELF:temp] < 28) (set HM_6A9B69_fan_server off) DOELSEIF ([$SELF:temp] > 29) (set HM_6A9B69_fan_server on)

attr di_venti_an event_Readings temp: [temp_server:temperature:med]

Das Reading di_venti_an:temp kannst du gleichzeitig in der DB ohne Ausreißer ablegen

[Frood42]

Also am Sensordevice, beim loggen der der Werte also möglichst weit vorn entscheiden: der Wert passt oder den lass ich einfach weg.

Das würde ich liebend gerne machen. In der Prä-fhem Ära hat das mein Python Script einfach raus-ge-iffed.
Das mit der Google Suche habe ich auch gefunden, aber das mit den Subs sind mir zu high hanging fruits.
Ich würde lieber so etwas beim sensor device selbst pflegen

Code Auswählen Erweitern

set irgendetwas_reading:FILTER=temperature>10 and temperature < 40
(im Sinne von set room=kitchen:FILTER=STATE=on off)

[Frood42]

Das Reading di_venti_an:temp kannst du gleichzeitig in der DB ohne Ausreißer ablegen

Okay. Aber so wie es da steht geht es noch nicht in die DB, oder? Wie legt man denn aus dem DOIF heraus etwas in die DB? Das "temp" in den DB filter (define myDbLog DbLog ./db.conf .*:(temperature|valveposition|humidity).*) mit aufnehmen?

[Otto123]

Hi Frood42,

ich hatte sowas simples im Sinn, Beispiel mit dummy:

Code Auswählen Erweitern

define w1 dummy
attr w1 room Test
attr w1 userReadings temp  { my $val =ReadingsNum($name,'state',0);; if ($val > 15 and $val < 25) {fhem("setreading wert temp $val")}}
define wert dummy

Das Reading temp in wert nimmt so nur Werte innerhalb >15 <25 an.

Vielleicht geht das besser, aber mir fiel es jetzt nicht ein. 

Gruß Otto

[Damian]

Okay. Aber so wie es da steht geht es noch nicht in die DB, oder? Wie legt man denn aus dem DOIF heraus etwas in die DB? Das "temp" in den DB filter (define myDbLog DbLog ./db.conf .*:(temperature|valveposition|humidity).*) mit aufnehmen?

Reicht nicht das "temp" in die regex aufzunehmen?

[Frood42]

Also ähm. So ganz habe ich es nicht vertanden.
Beim Attribut userReadings pflegen beim Temperatur Sensor poppt eine schwarze Box ein, da habe ich das eingetragen:

Code Auswählen Erweitern

temperature { my $val = ReadingsNum($name,'temperature',0);; if ($val > 15 and $val < 27) {fhem("setreading $name temperature $val")}}

So ganz ehrlich verstehe ich schon nicht dass es mit "temperature {"  anfängt und nicht z.B. "temperature = {"  und dann steht da ReadingsNum und nicht ReadingsVal. Ich denke mal, dass $name der DeviceName ist. und $val device name:reading, das neuste (0).

temperature ist das echte reading, was ich ja irgendwie prüfen will und dann mitgebe aus $val - genau genommen würde ich es überschreiben bzw ersetzen, aber mit demselben Namen.

Da gibts ein 3447 mal gelesenes Posting dazu https://forum.fhem.de/index.php?topic=37289.0 - ich finde es ist doch recht beliebt. Aber eine Antwort die noch einfacher ist, bzw die man verstehen kann, sehe ich da leider auch nicht. Kann unter anderem daran liegen, dass ich kein Perl kenne.

[Otto123]

Moin,

nö liegt denke ich daran weil Du nicht in der Doku nachschaust.

$name ist der Gerätename in dem das userReadings aufgerufen / definiert wird.

Was Du jetzt programmieren willst ist eine Kombination aus Baron Münchhausen und einem CPU Heizprogramm für Deinen FHEM Server.
Falls die kurze Erklärung in der Doku nicht reicht kannst Du gern nachfragen: 

userReadings
A comma-separated list of definitions of user-defined readings. Each definition has the form:
<reading>[:<trigger>] [<modifier>] { <perl code> }
After a single or bulk readings update, the user-defined readings are set by evaluating the perl code { <perl code> } for all definitions and setting the value of the respective user-defined reading <reading> to the result. If <trigger> is given, then all processing for this specific user reading is only done if one of the just updated "reading: value" combinations matches <trigger>, which is treated as a regexp.

Gruß Otto

[Frood42]

Ich will ja echt nicht meckern, aber diese Dokus sind extrem wissenschaftlich und theoretisch.
Ein komplettes Beispiel würde mir persönlich reichen um es sofort (in Millisekunden) zu verstehen. 

Nachdem ich die Doku gelesen habe, muss ich aber sagen, dass es gar nicht so schlecht war.
Die Rekursiv rausgenommen, also ein eigenes Reading definiert, sollte das so gehen oder?

Code Auswählen Erweitern


myTemp { my $val = ReadingsNum($name,'temperature',0);; if ($val > 15 and $val < 27) {fhem("setreading $name temperature $val")}}

oder auch eindeutiger:

Code Auswählen Erweitern


attr HM_B76343_temp_sens userReadings myTemp { my $val = ReadingsNum(HM_B76343_temp_sens,'temperature',0);; if ($val > 15 and $val < 27) {fhem("setreading HM_B76343_temp_sens myTemp $val")}}


Was passiert denn in dem Fall mit dem echten Reading für "temperature", ist das dann auch noch da?

Und wenn man das User Reading myTemp definiert, was macht denn dann darin noch das {fhem("setreading HM_B76343_temp_sens theTemp $val")} ?
Müsste da nicht einfach sowas wie ReadingsVal stehen, was den Wert zurückgibt?

[Otto123]

Also ich finde die Doku ist häufig sehr minimalistisch auf den Punkt und alle Fälle kann man nicht in einem Beispiel beschreiben.

Jetzt hast Du immer noch das "Heizprogramm"! Warum?
-> Das userreadings wird getriggert wenn ein Reading des Gerätes getriggert wird, Du setzt innerhalb dieses Trigger wieder ein Reading des gleichen Gerätes.
Das wird eine Schleife!

Mein Beispiel oben war völlig anders! Da waren zwei Geräte im Spiel! Soviel dazu: 

Ein komplettes Beispiel würde mir persönlich reichen um es sofort (in Millisekunden) zu verstehen. 

Probier doch mein Beispiel per Hand, du wirst sehen wo der Unterscheid zwischen dem userReading temp in w1 und dem Reading temp in wert liegt!

Das userReading wird nämlich immer gesetzt, entweder mit dem temperature Wert oder mit nichts.
Das Reading temp im dummy wert wird entweder mit dem temperature wert gesetzt oder nicht.

Ich hoffe Du verstehst mein Wortspiel.

Gruß Otto

[Frood42]

Oh man, das ist ja wie eine Schnitzeljagd. Oder wie bei Hänsel und Gretel mit den Brotkrumen. Ich weiß nur nicht ob ich Hänsel oder Gretel bin...

Also, anders ausgedrückt mache ich nur ein UserReading muellTemp zum Spaß sozusagen. Das wird selbst gar nicht weiterverarbeitet.
Ich mache es nur um dadurch das Reading (someTemp) eines neuen Dummy Gerätes (HM_dummy_temp_sens) zu setzen.

Jetzt müsste ich someTemp in die DB log regExp aufnehmen, aber ich könnte statt someTemp auch einfach temperature auf dem neuen dummy Gerät setzen. Das geht eh schon in die DB.

Code Auswählen Erweitern


attr HM_B76343_temp_sens userReadings muellTemp \
   { my $val = ReadingsNum(HM_B76343_temp_sens,'temperature',0);; \
   if ($val > 15 and $val < 27) \
   {fhem("setreading HM_dummy_temp_sens someTemp $val")}}

define HM_dummy_temp_sens dummy


Konsequenterweise müsste ich dann noch das reading temperature vom echten Sensor umbenennen, dass es nicht mehr in die DB geht, aber das geht nicht laut Doku, ne. Bissl DB sparen wäre schon gut.

Am Ende des Tages wird dann aber für mich nur noch HM_dummy_temp_sens:temperature (oder someTemp) relevant verwendet.

[Otto123]

naja, wie Du das Reading im Dummy benennst ist egal, das kannst Du ruhig temperature nennen.

Macht es denn so was Du willst? Du kannst auch statt des userReadings ein notify nach gleichem Schema nehmen und das neue Reading in das Sensor Device schreiben. Da hättest Du das Schleifenthema nicht. Bei mehreren Sensoren (hattest Du das irgendwo gesagt) könntest Du sicher mit einem notify alle Sensoren mit korrigierten Werten "beschicken".

So nach dem Schema (jetzt nur mal angedacht und nicht getestet)

Code Auswählen Erweitern

define n_korrektur notify cheepSensor.*:temperature {if ($EVTPART1 > 15 and $EVTPART1 < 27) {fhem("setreading $NAME someTemp $EVTPART1")}}


Gruß Otto

[Frood42]

I see. Mit

Code Auswählen Erweitern

{fhem("setreading $NAME someTemp $EVTPART1")} wird nun ein neues Reading namens someTemp am Original Sensor gesetzt, da müsste ich someTemp in die DB regExp hinzufügen.

Aaaaaaber: 

define n_korrektur notify cheepSensor.*:temperature

der . (Punkt) bedeutet > ein beliebiges Zeichen - aber NICHT kein Zeichen.
der * (Stern) bedeutet > beliebige Wiederholung des vorstehenden Zeichens - auch keine Wiederholung.

Wenn meine temp Sensoren in der Tat immer mit temp_ anfangen (temp_kitchen, temp_dining,...) wäre das

Code Auswählen Erweitern

define n_korrektur notify temp_.*:temperature {if ($EVTPART1 > 15 and $EVTPART1 < 27) {fhem("setreading $NAME someTemp $EVTPART1")}}

Korrekt?

Da ich verdammt viele von den Sensoren habe (Günstig mit Jeelink & Signalduino) wäre das eine feine Sache!
Allerdings hätte ich dann mein Brain upgegradet mit dem userReadings und würde es gar nicht mehr verwenden. Mh. Alleine deswegen sollte ich userReadings machen 

[Otto123]

Ja Du siehst das richtig. Einzig ob in $EVTPART1 wirklich bei Dir die Temperatur drin steht weiß ich nicht. Siehst Du aber im Eventmonitor.

Und userReadings sind eine feine Sache, vielseitig verwendbar - deswegen kannst Du das erworbene Wissen irgendwo anders nachnutzen.

Gruß Otto