FHEM Forum

Das scheint eine einfache Frage, aber trotz Brain 2.0 kann ich nach 2-3 Tagen nicht sagen, dass ich die optimale Lösungen gefunden habe.

Da ist ein Ventilator im Schrank und ein Temperatur Sensor.
Wenn die Temperatur > 28 ist, soll der Ventilator angehen, sonst aus.
Das macht der auch andauernd, für mich zu oft, so ca 10 mal die Stunde an und aus. Das muss ja nicht sein.
So sieht das aktuell aus:

define di_lamp DOIF ([temp_schrank:temperature] > 28) (set venti on) DOELSE (set venti off)
attire di_lamp do always

Jetzt würde es reichen, den Ventilator nur alle 15 Minuten an oder auszuschalten. Es kann auch passieren, dass der Ventilator zwo mal hintereinander, also um 10:15 und 10:30 angeschaltet wird, das ist auch ok.
D.h. die Bedingung sollte nur alle 15 Minuten überprüft werden.
Oder soll die Aktion an/ausschalten nur nach 15 Minuten durchgeführt werden und nicht mehrmals innerhalb 15 Minuten?

Ein do always scheint ungeeignet - alleine.
So hatte ich auch

([+600] and [temp_schrank:temperature] > 28)

ausprobiert und Sachen mit
attr di_push wait 600
attr di_push do resetwait

oder auch

attr di_push  repeatsame 3

Aber irgendwie bin ich mir nicht sicher.

Was ist denn die empfohlene Vorgehensweise?

In erster Linie würde ich hier mit schwellwerten arbeiten , da es vermutlich darum geht zu 'kühlen'. Also an bei >28 und aus bei <27 z.b. . Damit solltest du das gröbste 'flattern' schonmal in den griff bekommen.



Gruss Byte09



Gesendet von meinem SM-G900F mit Tapatalk

Hi,

Vorschlag für das was Du sagst - ungetestet:
define di_lamp DOIF ([+:15] and [?temp_schrank:temperature] > 28) (set venti on) DOELSE (set venti off)
attr di_lamp do always

Allerdings würde ich eigentlich für so etwas THRESHOLD nehmen, dass ist dafür gemacht. Und dann wie byte08 (09) (der spielt heute Jekyll & Hide) ;D ;D ;D schon sagt: regelt die Hysterese das Meiste :)

Gruß Otto

ok, also das mit <27.5 und > 28.5 ist schon ganz gut glaube ich.

Was bedeutet denn das Fragezeichen vor dem ?temp_schrank ? Das kommt mir öfters unter, aber habe nicht gefunden was es ist.
Heisst das, dass 28 exkludiert ist?

THRESHOLDS muss ich mal ankucken. Hat denn THRESHOLDS diese 15 Minuten delay drinne?

THRESHOLD kennt keine delay-Zeit, sondern eine Hysterese.

define di_lamp DOIF ([temp_schrank:temperature] > 28.5) (set venti on)  DOELSEIF  ([temp_schrank:temperature] < 27.5) (set venti off)

do always nicht setzen, die Hysterese bei diesem DOIF-Beispiel beträgt übrigens 1 Grad

Zitat von: Frood42 am 02 April 2019, 16:18:27
Was bedeutet denn das Fragezeichen vor dem ?temp_schrank ? Das kommt mir öfters unter, aber habe nicht gefunden was es ist.

Dann Doku gucken, ctrl+f im Browser nutzen einfach nach [? suchen, der zweite Treffer erklärt:
https://commandref.fhem.de/commandref_DE.html#DOIF_Zeitintervalle_Readings_und_Status_ohne_Trigger

Zitat von: Damian am 02 April 2019, 17:34:34
do always nicht setzen, die Hysterese bei diesem DOIF-Beispiel beträgt übrigens 1 Grad

Früher hatte ich schlechtere Schaltsteckdosen, da hatte ich lieber immer geschaltet, besser als gar nicht... just in case...
Jetzt läuft es so:
defmod di_venti_an DOIF ([temp_server:temperature] < 28]) (set HM_6A9B61_fan_server off) DOELSEIF ([temp_server:temperature] > 29)) (set HM_6A9B61_fan_server on) 
attr di_venti_an do always
attr di_venti_an waitsame 60

Vorab zusammenfassend darf ich anmerken,
dass es kein super Rezept für diese Anforderung gibt, sondern [+:15] soweit das ausgefeilteste war. Ansonsten muss man nur das DOIF anpassen, dass sich im Kontext des Temperaturverlaufs weniger oft eine Schaltung ergibt.

Danke und Grüße,
Frood

Ansonsten verwendet man den THRESHOLD.

Zitat von: Frood42 am 02 April 2019, 20:49:22
Früher hatte ich schlechtere Schaltsteckdosen, da hatte ich lieber immer geschaltet, besser als gar nicht... just in case...

Das löst man doch nicht mit do always!?

Wenn die Steckdose das Signal nicht immer empfängt oder verarbeitet, ist es doch besser, wenn es mehrfach gesendet wird, also bei jedem reading.
Mit do always: "Befehle werden wiederholt im bestehenden Status ausgeführt."
Bei HM passiert glaub gar nichts an der Steckdose wenn sie an ist und nochmal an geschaltet wird. Ausser dem Stromverbrauch schadet es da erst mal wenig.

Zitat von: Frood42 am 03 April 2019, 08:41:06
Mit do always: "Befehle werden wiederholt im bestehenden Status ausgeführt."

Wunschlesemodus und Dünnbrettbohrer aktiv  ;D
Das das DOIF wiederholt auf Events reagiert, obwohl sich der Status der Bedingung nicht ändert, hat doch nichts damit zu tun, dass im Ausführungsteil die Kommandos beim Empfänger nicht ankommen.
Lieber zuviel machen weil ich das Ziel verfehlen könnte ist für mich keine Lösungsstrategie. Aber leider ist das der Grundansatz der meisten Menschen, nicht nur in der Hausautomatisierung.  ::)

Ich entschuldige mich für Off Topic
Otto

Vielen Dank für den Hinweis.
Dennoch ist diese Art von destruktiver Kritik zu persönlich und unbegründet. Und unterstützt in keiner Weise eine intelligente oder sinnvolle Lösungsstrategie.
Falls das nicht ankommt, muss ich es noch mal wiederholen  ;D Das wäre dann so wie bei den miserablen PCA301 Funksteckdosen, die da mal in Betrieb waren, aber nun in Rente geschickt wurden. 

Du, persönlich habe ich das nicht gemeint - destruktiv sollte das auch nicht sein.  :D
Du hast Recht, ist bei Dir so angekommen - Entschuldigung dafür.

Aber, es war auch viel allgemeiner gemeint:

• Wenn die Steckdosen miserabel sind kann ich entweder damit leben oder diese aussortieren. Sperrfeuer löst doch das Problem nicht.
  
• Und do always klingt zwar so, aber wiederholt doch nicht von sich aus. Nur wenn ein zweiter Event kommt, wird auch nochmal die Ausführung wiederholt. do always erzeugt also nicht das scheinbar gewünschte Sperrfeuer. Ich müsste (wenn gewollt) Sperrfeuer im Ausführungsteil erzeugen  ;D
  

Das Attribut waitsame macht hier aber wenig Sinn. Wenn du schon mit do always wiederholen willst, dann würde ich dir das Attribut cmdpause empfehlen. Bei schlechtem Empfang wiederhole ich bewusst, indem ich den set-Befehl dopple, das reicht meistens schon aus, statt alle paar Minuten etwas wiederholt zu schalten (erhöhte Kollisionswahrscheinlichkeit bzw. 1%-Regel).

Ok, also interessanterweise ist das jetzt stark reduziert und bis auf waitsame ohne besondere Attribute.
defmod di_venti_an DOIF ([temp_server:temperature] < 28) (set HM_6A9B69_fan_server off) DOELSEIF ([temp_server:temperature] > 29) (set HM_6A9B69_fan_server on)
attr di_venti_an waitsame 60

Den waitsame braucht man wahrscheinlich auch nicht mehr.
Eigentlich hatte ich den Thread aufgemacht um die Attribute besser zu verstehen. Stattdessen sind sie beseitigt. So muss ich sie nicht mehr verstehen. Mh  ::)

Leider kann ich den Verlauf heute nicht so gut kontrollieren, da Ausreisser dabei sind - da weiß ich leider auch noch nicht wie man die filtert.

Es ist immer gut die Bedeutung der Attribute zu verstehen, denn gerade beim DOIF können sie eine Steuerung komplett auf den Kopf stellen.

Ausreißer kannst du mit Median elegant ausmerzen: https://fhem.de/commandref_DE.html#DOIF_Reading_Funktionen

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

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.

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

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 ;)

Zitat von: Otto123 am 04 April 2019, 16:32:06
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
set irgendetwas_reading:FILTER=temperature>10 and temperature < 40
(im Sinne von set room=kitchen:FILTER=STATE=on off)

Zitat von: Damian am 04 April 2019, 17:22:26
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?

Hi Frood42,

ich hatte sowas simples im Sinn, Beispiel mit dummy:
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

Zitat von: Frood42 am 05 April 2019, 09:26:45
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?

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

Moin,

nö liegt denke ich daran weil Du nicht in der Doku  (https://commandref.fhem.de/#readingFnAttributes)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:  ;)

ZitatuserReadings
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

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?


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

oder auch eindeutiger:

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?

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:  ;D ;D ;D

ZitatEin 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

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.


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.

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


Gruß Otto

I see. Mit {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: 

Zitatdefine 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
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  :o

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

im event monitor steht

2019-04-12 19:06:22 SD_WS07 temp_kitchen T: 24 H: 19
2019-04-12 19:06:22 SD_WS07 temp_kitchen temperature: 24
2019-04-12 19:06:22 SD_WS07 temp_kitchen humidity: 19


das notify:
defmod temp_sens_korrektur notify temp_ki.*:temperature {if ($EVTPART1 > 15 and $EVTPART1 < 40) {fhem("setreading $NAME korrTemp $EVTPART1")}}

müsste denn nun nicht auch im event monitor irgendetwas zu korrTemp zu sehen sein??

Viele Grüße,
Frood

YES!
so gehts: (Frood hat nachgelesen  :o :o :o :o)
define temp_sens_korrektur notify temp_ki.*:temperature:.* {if ($EVTPART1 > 15 and $EVTPART1 < 40) {fhem("setreading $NAME tempKorr $EVTPART1")}}
(nach so viel regExp brauche ich jetzt erst mal eine regExp Pause bis morgen, sonst kriege ich regExpKater)


2019-04-12 20:07:10 SD_WS07 temp_kitchen T: 23.9 H: 19
2019-04-12 20:07:10 SD_WS07 temp_kitchen temperature: 23.9
2019-04-12 20:07:10 SD_WS07 temp_kitchen humidity: 19
2019-04-12 20:07:10 SD_WS07 temp_kitchen tempKorr: 23.9


Perfekt! Dass das echte temperature reading erhalten bleibt, ist ja auch ok, als Kontrolle zum Beispiel.
Ich lasse das mal laufen und melde dann den Grafana Graphen.

Vielen Dank!!


Da war aber noch was mit der DB?

Internals:
   REGEXP     .*:(temperature|humidity|voltage|frequency|power|motion|brightness|tempKorr).*


tempkorr landet irgendwie nicht in der DB, ich habe nur "|tempKorr" hinzugefügt.

ich sehe da auch keinen Fehler.

shutdown restart, alles gemacht. tempkorr alles klein geschrieben.  (./db.conf .*:(tempkorr|temperature|humidity|voltage|frequency|power|motion|brightness).*)
Kommt immer wieder in den logs

2019-04-12 21:11:46 SD_WS07 temp_kitchen T: 24.5 H: 19
2019-04-12 21:11:46 SD_WS07 temp_kitchen temperature: 24.5
2019-04-12 21:11:46 SD_WS07 temp_kitchen tempkorr: 24.5

Aber nicht in der DB. komisch.  :o

naja jetzt ist es klein? tempkorr
Vorhin war es groß tempKorr

Es hieß auch schonmal korrTemp  ;D

Gruß Otto

ja, gerade hinzugefügt die Info

Zitattempkorr alles klein geschrieben.  (./db.conf .*:(tempkorr|temperature|humidity|voltage|frequency|power|motion|brightness).*)

und
defmod temp_sens_korrektur notify temp_ki.*:temperature:.* {if ($EVTPART1 > 15 and $EVTPART1 < 40) {fhem("setreading $NAME tempkorr $EVTPART1")}}

soll ich mal einen neuen thread aufmachen? MIt den 15 Minuten hat das nichts mehr zu tun....

Bisschen schrill ist das ganze ja. Ich habe schon 100 mal das DB log angepasst, mal humidity hinzugefügt und schnapp war das aus dem reading aller devices gespeichert in der DB.

Mit dem defmod notify oben geht das bis jetzt wirklich gar nicht.

Daher fall back - und das neue Dummy Device gemacht. Funzt, alles prima, nur: Wieso 4-5 mal mit demselben Zeitstempel?
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   group      01_Sensor_Temp
   room       EG_KITCHEN_ROOM
   userReadings trashTemp { my $val = ReadingsNum('temp_kitchen','temperature',0);  if ($val > 15 and $val < 37) {fhem("setreading temp_kitchen_corr temperature $val")}}
   userattr   max-deviation-hum:1,2,3,4,5,6,7,8,9,10,15,20,25,30,35,40,45,50 max-deviation-temp:1,2,3,4,5,6,7,8,9,10,15,20,25,30,35,40,45,50 offset-hum:slider,-50,1.0,50 offset-temp:slider,-25,1.0,25


Ich ignoriere auch gepflegt das "max-deviation-temp" und hoffe, dass das nicht sowieso schon für meine Zwecke gedacht war  ::)


SELECT * FROM `history` WHERE DEVICE = "temp_kitchen_corr"

TIMESTAMP DEVICE TYPE EVENT READING VALUE UNIT
2019-04-13 10:46:52 temp_kitchen_corr DUMMY temperature: 24.9 temperature 24.9
2019-04-13 10:46:52 temp_kitchen_corr DUMMY temperature: 24.9 temperature 24.9
2019-04-13 10:46:52 temp_kitchen_corr DUMMY temperature: 24.9 temperature 24.9
2019-04-13 10:46:52 temp_kitchen_corr DUMMY temperature: 24.9 temperature 24.9
2019-04-13 10:46:52 temp_kitchen_corr DUMMY temperature: 24.9 temperature 24.9


Das reading temperature kam früher definitiv nur einmal vor - laut event monitor.
2019-04-13 10:57:19 dummy temp_kitchen_corr temperature: 24.8
2019-04-13 10:57:19 dummy temp_kitchen_corr temperature: 24.9
2019-04-13 10:57:19 dummy temp_kitchen_corr temperature: 24.9
2019-04-13 10:57:19 dummy temp_kitchen_corr tempkorr: 24.8
2019-04-13 10:57:19 dummy temp_kitchen_corr tempkorr: 24.9
2019-04-13 10:57:19 dummy temp_kitchen_corr tempkorr: 24.9
2019-04-13 10:57:19 SD_WS07 temp_kitchen T: 24.9 H: 21
2019-04-13 10:57:19 SD_WS07 temp_kitchen temperature: 24.9
2019-04-13 10:57:19 SD_WS07 temp_kitchen batteryState: low
2019-04-13 10:57:19 SD_WS07 temp_kitchen tempkorr: 24.9

Der scheint mir irgendwie für alle readings des devices das UserReading zu machen, oder? (das tempkorr ist auch noch drin, aber landet ja nicht in der DB)

ZitatWieso 4-5 mal mit demselben Zeitstempel?

Weil jede änderung an dem Device das userreading triggert.
Dann musst Du für das userreading einen trigger definieren. userReadings trashTemp:temperature.*
Ich bin nicht sicher mit dem Trigger

Ich versteh nicht, warum das notify schuld sein soll.  :D
Oder versuch mal in dem notify den Befehl zu ergänzen
{fhem("sleep 0.1;setreading $NAME tempkorr $EVTPART1")} da war doch was ...

Zitatsetreading
[EN DE]
setreading <devspec> <reading> <value>

Set the reading <reading> for the device <name> to <value> without sending out commands to the device, but triggering events and eventMap/stateFormat transformations as usual. See the set command documentation for replacement description.

Examples:
setreading lamp state on
Note: setreading won't generate an event for device X, if it is called from a notify for device X. Use "sleep 0.1; setreading X Y Z" in this case.

Super, vielen Dank!
Das ist ja aber auch schon etwas spezial, nech!

Das mit dem
userReadings trashTemp:temperature.*
hat nicht gut geklappt. habe auch an der Stelle ein sleep probiert, aber die temp* readings kommen zumindest immer noch doppelt rein.

Das notify mit dem sleep ist das beste. Klappt! Nicht ganz so ein selbsterklärender Einzeiler aber immerhin geht es.

defmod temp_sens_server_korrektur notify temp_se.*:temperature:.* {if ($EVTPART1 > 22 and $EVTPART1 < 38) {fhem("sleep 0.1;; setreading $NAME tempkorr $EVTPART1")}}

Viele Grüße,
Frood