Hallo zusammen,
Seit dem o.g. Update wird mit
define dew_state dewpoint dewpoint Aussen_1 T H D
nicht immer, aber immer mal wieder im Device ein Reading ,,D" mit dem Taupunktwert angelegt. Manchmal wird nur der STATE um den Taupunkt erweitert, und manchmal zusätzlich dieses Reading.
(stateFormat zu dieser Zeit nicht definiert)
Da ich aber eigentlich stateFormat nutze
stateFormat state D: dewpoint A: absFeuchte
wird mir dieses Format zerschossen, sobald das erste mal das Reading ,,D" erzeugt wird, weil dann das D durch den Wert des Readings ersetzt wird.
Hat das Problem noch jemand?
Schaue mal hier.
https://r.tapatalk.com/shareLink?url=https%3A%2F%2Fforum%2Efhem%2Ede%2Findex%2Ephp%3Ftopic%3D87916%2E0&share_tid=87916&share_fid=75100&share_type=t
Dewpoint legte nach Update vom 17.05.2018 keine Taupunkt und absFeuchte an
(https://r.tapatalk.com/shareLink?url=https%3A%2F%2Fforum%2Efhem%2Ede%2Findex%2Ephp%3Ftopic%3D87916%2E0&share_tid=87916&share_fid=75100&share_type=t%3Cbr%20/%3E%3Cbr%20/%3EDewpoint%20legte%20nach%20Update%20vom%2017.05.2018%20keine%20Taupunkt%20und%20absFeuchte%20an)
Gesendet von meinem E6653 mit Tapatalk
Ja, soweit so gut, nur wird das Reading D nicht regelmäßig aktualisiert. Die absFeuchte wird öfter aktualisiert, obwohl beides ja zeitgleich berechnet wird.
Außerdem wäre ein anderer Reading-Name statt D schöner, weil man dann ein schönes knappes stateFormat mit u.a. ,,D:" als Bezeichnung machen kann, ohne dass diese mit dem Wert des Readings überschrieben wird.
Mal ein aktueller Auszug:
DeviceOverview T: 25.5 H: 52.0 D: 14.9 A: 12.3
D 13.9 2018-05-24 20:07:03
absFeuchte 12.4 2018-05-25 17:43:43
state T: 25.6 H: 52.0 2018-05-25 17:44:23
Es gibt hier kein stateFormat und wie man sieht ist D von gestern, absFeuchte aktuell und der Overview weicht von allem nochmal ab. Unschön sag ich mal....
Das Reading heißt D, weil du das in deiner Definition so nennst. Siehe doch bitte in den anderen Thread oder die online Hilfe, da ist das beschrieben.
Gesendet von meinem Nexus 5X mit Tapatalk
Sorry, ja stimmt mit dem Namen, war mir klar, hatte ich nur verdrängt. Aber mein ergänzter Satz oben zeigt weitere Diskrepanzen auf.....
Setze im dewpoint mal verbose auf 5. Dann wird sehr detailliert geloggt, wie die Werte zu Stande kommen.
Gesendet von meinem Nexus 5X mit Tapatalk
Hier das Ergebnis, das meiner Meinung nach meine Schilderungen stützt.
Zunächst der Output im Log:
2018.05.25 18:45:23 4: dewpoint_notify: cmd_type=dewpoint devname=SensorAussen dewname=dew_state_Aussen, dev=SensorAussen, dev_regex=SensorAussen temp_name=T hum_name=H
2018.05.25 18:45:23 5: dewpoint_notify: s='T: 25.0 H: 56.0'
2018.05.25 18:45:23 5: dewpoint_notify: evName='T:' val=25.0'
2018.05.25 18:45:23 5: dewpoint_notify T: H:, temp=25.0 hum=56.0
2018.05.25 18:45:23 5: dewpoint max_timediff=1
2018.05.25 18:45:23 5: dewpoint_notify: dewpoint=15.6
2018.05.25 18:45:23 5: dewpoint absFeuchte= 12.9
2018.05.25 18:45:23 5: dewpoint_notify: current=T: 25.0 H: 56.0 D: 15.6 A: 12.9
Die Werte der letzte Zeile landen auch im File_LOG. Soweit so gut. Aber die Werte im Device sehen zu der Zeit leider so aus:
DeviceOverview T: 25.0 H: 56.0
STATE T: 25.0 H: 56.0
D 13.9 2018-05-24 20:07:03
absFeuchte 12.9 2018-05-25 18:45:23
Ich habe noch einen Satz mitgeschrieben, weil hier der STATE vervollständigt wurde, was im vorherigen Beispiel irgendwie nicht der Fall war....
Log:
2018.05.25 19:14:43 4: dewpoint_notify: cmd_type=dewpoint devname=SensorAussen dewname=dew_state_Aussen, dev=SensorAussen, dev_regex=SensorAussen temp_name=T hum_name=H
2018.05.25 19:14:43 5: dewpoint_notify: s='T: 24.3 H: 58.0'
2018.05.25 19:14:43 5: dewpoint_notify: evName='T:' val=24.3'
2018.05.25 19:14:43 5: dewpoint_notify T: H:, temp=24.3 hum=58.0
2018.05.25 19:14:43 5: dewpoint max_timediff=1
2018.05.25 19:14:43 5: dewpoint_notify: dewpoint=15.5
2018.05.25 19:14:43 5: dewpoint absFeuchte= 12.8
2018.05.25 19:14:43 5: dewpoint_notify: current=T: 24.3 H: 58.0 D: 15.5 A: 12.8
Device:
DeviceOverview
SensorAussen T: 24.3 H: 58.0 D: 15.5 A: 12.8
STATE T: 24.3 H: 58.0 D: 15.5 A: 12.8
D 13.9 2018-05-24 20:07:03
absFeuchte 12.8 2018-05-25 19:14:43
state T: 24.3 H: 58.0 2018-05-25 19:14:43
Edit:
Der erste Datensatz kann glaube ich ignoriert werden. Ich übertrage alle 20 Sekunden die Temperatur und Luftfeuchte von einem Gerät in das Device SensorAussen. Dadurch kann ich alle Konfigurationen an SensorAussen binden und habe es leichter bei einem Batteriewechsel, denn da erscheinen die Sensoren immer als völlig neues Gerät, das ich auf diese weise nicht aufwändig umprogrammieren muss. Dadurch verschwinden aber immer wieder Taupunkt und absFeuchte aus dem STATE.
Es sieht so aus, dass Du genau das Problem hast, wegen dem ich die Änderung in dewpoint gemacht habe. Die ist bei Dir nicht aktiv, weil du kein stateFormat benutzt.
Das ändern im STATE eines anderen devices muss (dewpoint ändert state im Sensor) ist problematisch.
Damit es richtig und deterministisch funktioniert, rate ich dir dringend zum Vorgehen mit stateFormat, wie hier https://forum.fhem.de/index.php?topic=87916.0 (https://forum.fhem.de/index.php?topic=87916.0) und in der Doku von dewpoint beschrieben.
Gruss
Holger
Hi hotbso,
danke für deine Rückmeldung und schon mal sorry für den folgenden langen Text :)
Eigentlich hatte ich gedacht, dass ich es verstehe. Vor dem letzten Update hatte ich stateFormat genutzt, weil bei meiner Konfiguration im STATE immer nur T und H auftauchten, außer es kam zu einer Berechnung von D und A, dann kamen diese Werte für 20 Sekunden (s.u. at-Befehl) dazu.
Ich hatte da etwas getrickst: Durch das stateFormat (attr SensorAussen stateFormat state D: dewpoint A: absFeuchte) hatte ich erreicht, dass, wenn die Werte D/A nicht berechnet werden, der STATE nach dem stateFormat gebildet wird. Für "dewpoint" hatte ich ein userReading angelegt mit dem Wert "n.V.". Dadurch wußte ich, ob es aktuell berechnete Werte waren (D-Wert liegt durch 98_dewpoint vor) oder alte Werte (D-Wert ist "n.V." aus dem userReading), aber ich konnte zahlenmäßig immer den letzten Wert für absFeuchte lesen.
Nach dem Update blieben die Werte D/A komplett aus und ich habe stateFormat erstmal entfernt. Damit waren die Werte zumindest wieder im FileLog und damit in den Grafiken.
Also zur Erkläung im Detail mache ich vom Prinzip her folgendes:Der Klimasensor liefert seine Daten (T/H) mal zeitnah mal weniger zeitnah und vereinzelt an ein Device vom Typ CUL_TX mit Namen "SensorAussenQuelle". Damit ich bei einem Batteriewechsel möglichst wenig Arbeit habe, passiert hier absolut nichts weiter.
Per at-Befehl kopiere ich alle 20 Sekunden die gerade vorliegenden Werte für T/H in den state von "SensorAussen". Zwar können die Werte in der Quelle zeitlich weiter auseinander liegen, aber davon weiß "SensorAussen" so natürlich nichts.
+*00:00:20 { my $temp= ReadingsVal("SensorAussenQuelle","temperature",0) ;
my $hum= ReadingsVal("SensorAussenQuelle","humidity",0) ;
fhem("set SensorAussen T: $temp H: $hum");}Um nicht alle 20 Sekunden unveränderte Werte ins FileLog zu schreiben, werden Events nur ausgelöst, wenn der state sich ändert, aber mindestens alle 5 Minuten.
attr SensorAussen event-min-interval .*:300
attr SensorAussen event-on-change-reading stateMit der ursprünglichen stateFormat Definition kann ich jetzt ohne Änderungen nichts mehr erreichen
attr SensorAussen stateFormat state D: dewpoint A: absFeuchteIm Ergebnis würde bei mir jetzt "state", "D", "dewpoint" und "absFeuchte" durch die Readings ersetzt, wobei "D", wie du siehst nur einmal erzeugt und dann nie wieder aktualisiert wird.
T: 35.1 H: 33.0 13.9: n.V. A: 13.1Ich könnte mir mit der jetzigen Philosophie von 98_dewpoint ja wieder mit stateFormat behelfen. Aber leider wird D offensichtlich nicht aufgefrischt.
Leider verstehe ich nicht, was du mit
ZitatDas ändern im STATE eines anderen devices muss (dewpoint ändert state im Sensor) ist problematisch.
meinst.
Ich ändere ja nach meinem Verständnis nichts in einem
anderen Device? Aus SensorAussen wird Event-gesteuert dewpoint aufgerufen und sonst nichts weiter eigentlich. Und das ist doch auch Sinn und Zweck von 98_dewpoint?
define dew_state_Aussen dewpoint dewpoint SensorAussen T H D
Ja, aber dewpoint ist ja ein selber ein Gerät, nämlich ein anderes Gerät als dein Sensor SensorAussen. Mit define legt man ja ein Gerät im Sinne von FHEM an. Und das Gerät dewpoint soll den STATE deines Geräts AussenSensor ändern. Das tun bei Dir aber noch jede Menge andere Akteure.
Deshalb schlage ich vor:
Wie auch immer erzeuge die Readings temperature und humidity in deinem AussenSensor und sorge dafür, dass events generiert werden.
Definiere dewpoint mit
define dew_state_Aussen dewpoint dewpoint SensorAussen temperature humidity dewpoint
Wenn dann events für temperature/humidity erzeugt werden, legt dewpoint verläßlich die Readings dewpoint und absFeuchte an und löst die Events dafür aus.
Dein stateFormat vom AussenSensor wird getriggert und formatiert den state nach deinen Wünschen.
Das funktioniert dann deterministisch.
Ich habe jetzt folgendes getan:
T/H alle 20 Sekunden kopieren:
+*00:00:20 { my $temp= ReadingsVal("SensorAussenQuelle","temperature",0) ;
my $hum= ReadingsVal("SensorAussenQuelle","humidity",0) ;
fhem("setreading SensorAussen temperature $temp");
fhem("setreading SensorAussen humidity $hum");}
Events auslösen:
attr SensorAussen event-min-interval .*:300
attr SensorAussen event-on-change-reading humidity,temperature
Taupunktberechnung:
define dew_state_Aussen dewpoint dewpoint SensorAussen temperature humidity dewpoint
STATE formatiert:
attr SensorAussen stateFormat T: temperature H: humidity D: dewpoint A: absFeuchte
Scheint soweit zu funktionieren, nur leider laufen die Werte jetzt nicht mehr ins FileLog. Das verstehe ich jetzt gerade noch nicht so recht, weil ich dachte, dass der STATE ins FileLog geschrieben wird. Damit die Files nicht so lang werden, hatte ich bisher folgendes Fileformat erzeugt:
2018-05-26_14:24:03 SensorAussen T: 36.6 H: 29.0 D: 15.7 A: 12.4
2018-05-26_14:28:03 SensorAussen T: 36.2 H: 29.0 D: 15.3 A: 12.2
2018-05-26_14:30:03 SensorAussen T: 36.3 H: 29.0 D: 15.4 A: 12.2
Dazu hatte ich folgende Definition für REGEXP im FileLog:
SensorAussen:T:.*
Ich vermute mal, Du musst addStateEvent setzen. Bin aber kein Experte für Filelog.
Danke für den Tipp. Manchmal braucht man einen Anstoß, in welche Richtung es Sinn macht weiter zu lesen. Leider komme ich im Moment nicht dazu..... melde mich aber, ob es geholfen hat :)
Ne, das hat leider nicht geholfen.....
Kann ich bestätigen.
Müsste nach der Umstellung im Modul jetzt jedes reading einzeln loggen. Habe auch das SVG umgestellt.
Wollte mir den state;T:.* die logs etwas kleiner halten.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Beruhigend, dass ich nicht allein das Problem habe :)
Ich habe aber noch die Hoffnung, das irgendwie wieder hin zu bekommen....
Wenn ich mal irgendwann Zeit habe. Das Probieren frisst ja schon ordentlich Zeit.
Ich habe eine Lösung, die mir zwar auch noch nicht 100%-ig gefällt, aber es kommt dem vorherigen wieder nahe. Auch muss man hier trotzdem jedes SVG wieder anpassen, weil die Werte eine Position nach hinten verschoben sind.
Ich habe einfach ein userReading angelegt
attr <device> userReading all {sprintf("T: %.1f H: %.1f D: %.1f A: %.1f", ReadingsVal("<device>","temperature",0),ReadingsVal("<device>","humidity",0),ReadingsVal("<device>","dewpoint",0),ReadingsVal("<device>","absFeuchte",0))}
<device> natürlich duch das individuell genutzte ersetzen.
Dass die Position im Log gleich bleibt und somit die SVG's nicht angepasst werden müssen, kann man bestimmt wie folgt machen:
attr <device> userReading T {sprintf("%.1f H: %.1f D: %.1f A: %.1f", ReadingsVal("<device>","temperature",0),ReadingsVal("<device>","humidity",0),ReadingsVal("<device>","dewpoint",0),ReadingsVal("<device>","absFeuchte",0))}
Das Reading heißt hier T und dafür steht T nicht mehr direkt im Reading.
@Gast45
mir geht es genauso, deswegen
attr global exclude_from_update 98_dewpoint.pm
Zitatattr global exclude_from_update 98_dewpoint.pm
Bewirkt das, dass 98_dewpoint auf der eigenen Installation von Updates ausgenommen wird?
Ich bin kein Freund davon, auf immer und ewig auf einer alten Version hängen zu bleiben. Spätestens wenn man mal ganz neu installieren muss, läuft man hinter der richtigen alten Version hinterher, oder nicht? :)
Das Exclude wäre auch ne Möglichkeit gewesen. Ich möchte auch das System eigentlich immer aktuell halten.
Habe deswegen auch die FileLogs alle umgestellt, so dass jedes reading einzeln geschrieben wird.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Naja, das alte Modul macht das was es soll, ich habe einfach keine Lust meine SVGs und FileLogs der letzten Jahre (7) zu ändern,
für null Vorteile der neuen Version.
die alten Versionen kann man sich auch aus dem SVN ziehen, oder man hat sie in seinen backups.
es gibt ja mehrere Developer die so einen Hauruck update machen, wo die Installation dann nicht mehr so läuft wie gehabt :(
so als Bsp OWSERVER , das geht gar nicht.
Ich glaube meine in Antwort #17 geschilderte Lösung hat noch einen Haken. Wenn sich Werte ändern, dann erscheinen zwei Einträge im FileLog.
Einmal mit den neuen Messwerten, aber noch alte Werte für D und A.
Und einmal mit neuen Messwerten und aktuell berechneten Werte für D und A.
Der erste Eintrag ist natürlich total unnütz, weil die Werte nicht zusammenpassen.
Wenn ich Zeit finde, gucke ich morgen nochmal..... :(
Hallo zusammen,
ich versuche immer noch die Darstellung von Klimadaten wieder so herzustellen, wie es vor dem letzten Update funktionierte. Insbesondere hätte ich gerne wieder Folgendes erreicht:
1. Ein relativ kompaktes FileLog nach folgendem Schema:
2018-05-22_14:40:08 SensorAussen T: 28.5 H: 38.0 D: 12.8 A: 10.6
2018-05-22_14:42:08 SensorAussen T: 28.4 H: 38.0 D: 12.7 A: 10.5
2018-05-22_14:44:08 SensorAussen T: 28.3 H: 38.0 D: 12.6 A: 10.5
2018-05-22_14:46:08 SensorAussen T: 28.2 H: 38.0 D: 12.5 A: 10.4
Es sollen dabei nur geänderte Werte erfasst werden, aber mindestens alle 3 Minuten soll auf jeden Fall ein Eintrag erfolgen.
--> userReading und event-on-....
2. Der STATE soll ebenfalls nach diesem Schema aufgebaut sein:
T: 28.5 H: 38.0 D: 12.8 A: 10.6
--> stateFormat
Lösungsversuch:
Nach vielen Versuchen bin ich der Meinung, dass diese Konfiguration den Wünsche am nähesten kommt:
Internals:
CHANGED
NAME SensorAussen
NR 41
STATE T: 22.0 H: 74.0 D: 17.1 A: 14.3
TYPE dummy
OLDREADINGS:
READINGS:
2018-02-04 12:12:25 Batteriewechsel 0
2018-06-03 10:52:32 absFeuchte 14.3
2018-06-03 10:52:32 dewpoint 17.1
2018-06-03 10:52:52 humidity 74.0
2018-06-03 10:52:52 state T: 22.0 H: 74.0 D: 17.1 A: 14.3
2018-06-03 10:52:52 temperature 22.0
Attributes:
event-min-interval .*:175
event-on-change-reading humidity,temperature,state
group Sensordaten clonen – verarbeiten – loggen
icon temperature_humidity
room Sensoren
stateFormat {sprintf("T: %.1f H: %.1f D: %.1f A: %.1f", ReadingsVal("SensorAussen","temperature",0),
ReadingsVal("SensorAussen","humidity",0),
ReadingsVal("SensorAussen","dewpoint",0),
ReadingsVal("SensorAussen","absFeuchte",0))}
userReadings state {sprintf("T: %.1f H: %.1f D: %.1f A: %.1f", ReadingsVal("SensorAussen","temperature",0),
ReadingsVal("SensorAussen","humidity",0),
ReadingsVal("SensorAussen","dewpoint",0),
ReadingsVal("SensorAussen","absFeuchte",0))}
Und FileLog gefiltert nach:
REGEXP SensorAussen:T:.*
Allerdings ergibt sich da ein Problem im FileLog:
2018-06-03_10:49:52 SensorAussen T: 22.0 H: 74.0 D: 17.1 A: 14.3
2018-06-03_10:52:52 SensorAussen T: 22.0 H: 74.0 D: 17.1 A: 14.3
2018-06-03_10:53:52 SensorAussen T: 25.0 H: 74.0 D: 17.1 A: 14.3
2018-06-03_10:53:52 SensorAussen T: 25.0 H: 74.0 D: 20.0 A: 17.0
Wie man sieht erscheinen bei Änderungen zwei Zeilen im FileLog. Die letzte Zeile ist in Ordnung, weil sie konsistente Daten enthält. Die vorletzte Zeile jedoch enthält noch die alten Werte für D und A, aber schon die neuen für T und H. Die Werte dieser Zeile passen somit nicht zusammen.
Gibt es hier noch einen Trick, wie ich das verhindern kann?
Ich glaube ja, dass die von mir eingebrachte Idee das pauschal ändern/vereinfachen könnte:
https://forum.fhem.de/index.php/topic,88336.0.html (https://forum.fhem.de/index.php/topic,88336.0.html)