Hallo zusammen,
ich möchte gerne ein FileLog übersichtlicher gestalten und die gemessenen und berechneten Klima-Werte jeweils einzeilig im FileLog haben.
Ich habe ein MQTT-Device, das mir einzeln, aber zeitgleich innerhalb einer Sekunde "Temperature", "Humidity" und "Pressure" liefert. Daraus berechne ich noch mit der Funktion dewpoint den "Dewpoint" und die "absoluteHumidity".
Standardmäßig landet ja jeder Wert in einer eigenen Zeile im FileLog. Das bläht es meiner Meinung nach unnötig auf.
Darum habe ich mir überlegt ein userReading zu erstellen. Dazu benutze ich folgenden Code:
mystate:.* {"T: ".ReadingsVal("Sensor","Temperature",0).
" H: ".ReadingsVal("Sensor","Humidity",0).
" D: ".ReadingsVal("Sensor","Dewpoint",0).
" A: ".ReadingsVal("Sensor","absFeuchte",0).
" P: ".ReadingsVal("Sensor","Pressure",0)}
Das Ergebnis ist dann etwas in der Art:
mystate T: 23.6 H: 54.7 D: 14.1 A: 11.7 P: 1010.4
Meine Idee war, nur noch "mystate" ins Log zu schieben.
Am liebsten hätte ich nur alle x Minuten eine Zeile, oder vorher, wenn sich mindestens ein Wert geändert hat.
Leider ist das Ergebnis, dass sich zu einem ganz bestimmten Zeitpunkt immer mehrere Zeilen ins Log schreiben.
2019-10-12_20:37:37 Sensor mystate: T: 23.6 H: 54.5 D: 13.9 A: 11.6 P: 1010.6
2019-10-12_20:37:37 Sensor mystate: T: 23.6 H: 54.4 D: 13.9 A: 11.6 P: 1010.6
2019-10-12_20:37:37 Sensor mystate: T: 23.6 H: 54.4 D: 13.9 A: 11.5 P: 1010.6
2019-10-12_20:37:37 Sensor mystate: T: 23.6 H: 54.4 D: 13.9 A: 11.5 P: 1010.7
Das beruht sicherlich darauf, dass mehrere Ereignisse das Bilden des Userreadings triggern. Und auch schon vorher mehrere die Berechnung des Taupunktes. Somit wird bei jeder einzelnen Änderung der "mystate" immer wieder neu berechnet.
Hat jemand vielleicht eine kluge Idee, wie man das Userreading vielleicht erst zum Abschluss einer "Trigger-Welle" aufbauen lassen kann?
Oder vielleicht eine andere viel einfachere und elegantere Lösung :)
mseclog setzten, um zu gucken, welches Reading immer als letzes kommt
Dann dein Trigger fürs userReading entspr. anpassen.
Falls die Reihenfolge immer unterschiedlich ist, würde ich mit event-on-change-reading und event-min-interval die Anzahl Events reduzieren.
Ich habe schon versucht mit event-on zu spielen. Vorher hatte ich noch häufiger so viele Zeilen. Aber es ist halt immer noch nicht "sauber".
Du meinst mal auf millisekunden-Basis zu loggen und falls sich eindeutig eine Reihenfolge erkennen lässt, dann nicht "event-on-change", sondern "event-on-update" auf genau diesen einen Wert?
Muss ich mir morgen mal anschauen. Danke schon mal :)
Zitat von: Gast45 am 12 Oktober 2019, 21:36:01
Du meinst mal auf millisekunden-Basis zu loggen und falls sich eindeutig eine Reihenfolge erkennen lässt, dann nicht "event-on-change", sondern "event-on-update" auf genau diesen einen Wert?
Nein, wenn dann, dein Trigger in dem Attribut userReading anpassen, damit er nicht auf allen Readings triggert (wie jetzt ".*") sondern auf dem richtigen.
ZitatNein, wenn dann, dein Trigger in dem Attribut userReading anpassen, damit er nicht auf allen Readings triggert (wie jetzt ".*") sondern auf dem richtigen.
Das funktioniert leider nicht. Ich hatte es schon auf "Temperature|Humidity" eingeschränkt. Führt aber leider dazu, wenn sich beide Werte ändern, dass nur einer der beiden im Userreading erscheint und der andere alt bleibt. Außerdem blieben glaube ich auch die berechneten Taupunkt und absolute Feuchte außen vor :(
Zitat von: Gast45 am 12 Oktober 2019, 21:46:58
Das funktioniert leider nicht. Ich hatte es schon auf "Temperature|Humidity" eingeschränkt. Führt aber leider dazu, wenn sich beide Werte ändern, dass nur einer der beiden im Userreading erscheint und der andere alt bleibt.
Entweder war deine Regex falsch, oder es ist wiederum eine Frage von Reihenfolge
Zitat von: Gast45 am 12 Oktober 2019, 21:46:58
Außerdem blieben glaube ich auch die berechneten Taupunkt und absolute Feuchte außen vor :(
Hat nichts damit zu tun. Das ist nur der Trigger des userReadings. Der Rest bleibt gleich.
So, hab jetzt mal 4 Zyklen geloggt.
Im Moment habe ich die Events im Device "Sensor" wie folgt eingeschränkt:
event-min-interval mystate:15
event-on-change-reading Humidity,LWT,Temperature,mystate
Nach meinem Verständnis entscheidet das darüber, ob "dewpoint", das Logging allgemein und die Erstellung der Userreadings überhaupt angestoßen wird.
Bei den gemessenen 4 Zyklen (getrennt durch Leerzeilen) wird nur im ersten und vierten getriggert. Beim zweiten und dritten keine Änderung bei T und H und somit "stillhalten":
2019.10.13 10:39:04.720 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Temperature:23.1
2019.10.13 10:39:04.721 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Temperature\00023.1
2019.10.13 10:39:04.722 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Temperature => Temperature
2019.10.13 10:39:04.819 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Humidity:57.4
2019.10.13 10:39:04.820 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Humidity\00057.4
2019.10.13 10:39:04.822 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Humidity => Humidity
2019.10.13 10:39:04.826 5: Starting notify loop for Sensor, 2 event(s), first is Humidity: 57.4
2019.10.13 10:39:04.827 4: dewpoint_notify: cmd_type=dewpoint devname=Sensor dewname=dew_state_ESP_1, dev=Sensor, dev_regex=Sensor temp_name=Temperature hum_name=Humidity
2019.10.13 10:39:04.828 5: dewpoint_notify: s='Humidity: 57.4'
2019.10.13 10:39:04.828 5: dewpoint_notify: evName='Humidity:' val=57.4'
2019.10.13 10:39:04.828 5: dewpoint_notify: humidity! dev=Sensor, hum_name=Humidity, hum=57.4
2019.10.13 10:39:04.828 5: dewpoint_notify: s='mystate: T: 23.1 H: 57.4 D: 14.2 A: 11.9 P: 1010.3'
2019.10.13 10:39:04.828 5: dewpoint_notify: evName='mystate:' val=T:'
2019.10.13 10:39:04.829 5: dewpoint_notify: max_timediff=1
2019.10.13 10:39:04.829 5: >dev=Sensor, temp_name=Temperature, reference temperature=23.1 (0), hum=57.4
2019.10.13 10:39:04.830 5: dewpoint_notify: dewpoint=14.2
2019.10.13 10:39:04.831 5: dewpoint_notify: absFeuchte= 11.8
2019.10.13 10:39:04.833 5: dewpoint_notify: rval=14.2
2019.10.13 10:39:04.836 5: End notify loop for Sensor
2019.10.13 10:39:04.920 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Pressure:1010.3
2019.10.13 10:39:04.922 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Pressure\0001010.3
2019.10.13 10:39:04.924 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Pressure => Pressure
2019.10.13 10:42:04.731 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Temperature:23.1
2019.10.13 10:42:04.732 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Temperature\00023.1
2019.10.13 10:42:04.734 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Temperature => Temperature
2019.10.13 10:42:04.829 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Humidity:57.4
2019.10.13 10:42:04.831 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Humidity\00057.4
2019.10.13 10:42:04.833 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Humidity => Humidity
2019.10.13 10:42:04.930 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Pressure:1010.1
2019.10.13 10:42:04.931 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Pressure\0001010.1
2019.10.13 10:42:04.933 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Pressure => Pressure
2019.10.13 10:45:04.742 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Temperature:23.1
2019.10.13 10:45:04.744 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Temperature\00023.1
2019.10.13 10:45:04.745 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Temperature => Temperature
2019.10.13 10:45:04.840 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Humidity:57.4
2019.10.13 10:45:04.842 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Humidity\00057.4
2019.10.13 10:45:04.844 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Humidity => Humidity
2019.10.13 10:45:04.943 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Pressure:1010.2
2019.10.13 10:45:04.945 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Pressure\0001010.2
2019.10.13 10:45:04.946 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Pressure => Pressure
2019.10.13 10:48:04.751 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Temperature:23.1
2019.10.13 10:48:04.753 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Temperature\00023.1
2019.10.13 10:48:04.754 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Temperature => Temperature
2019.10.13 10:48:04.849 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Humidity:57.5
2019.10.13 10:48:04.850 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Humidity\00057.5
2019.10.13 10:48:04.852 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Humidity => Humidity
2019.10.13 10:48:04.856 5: Starting notify loop for Sensor, 2 event(s), first is Humidity: 57.5
2019.10.13 10:48:04.857 4: dewpoint_notify: cmd_type=dewpoint devname=Sensor dewname=dew_state_ESP_1, dev=Sensor, dev_regex=Sensor temp_name=Temperature hum_name=Humidity
2019.10.13 10:48:04.857 5: dewpoint_notify: s='Humidity: 57.5'
2019.10.13 10:48:04.857 5: dewpoint_notify: evName='Humidity:' val=57.5'
2019.10.13 10:48:04.858 5: dewpoint_notify: humidity! dev=Sensor, hum_name=Humidity, hum=57.5
2019.10.13 10:48:04.858 5: dewpoint_notify: s='mystate: T: 23.1 H: 57.5 D: 14.2 A: 11.8 P: 1010.2'
2019.10.13 10:48:04.858 5: dewpoint_notify: evName='mystate:' val=T:'
2019.10.13 10:48:04.858 5: dewpoint_notify: max_timediff=1
2019.10.13 10:48:04.859 5: >dev=Sensor, temp_name=Temperature, reference temperature=23.1 (0), hum=57.5
2019.10.13 10:48:04.859 5: dewpoint_notify: dewpoint=14.2
2019.10.13 10:48:04.860 5: dewpoint_notify: absFeuchte= 11.9
2019.10.13 10:48:04.861 5: dewpoint_notify: rval=14.2
2019.10.13 10:48:04.867 5: End notify loop for Sensor
2019.10.13 10:48:04.949 4: myBroker_192.168.x.y_49156 ESP_1 PUBLISH /ESP_1/THP1/Pressure:1010.2
2019.10.13 10:48:04.951 5: myBroker: dispatch autocreate=simple\000ESP_1\000/ESP_1/THP1/Pressure\0001010.2
2019.10.13 10:48:04.952 4: MQTT2_DEVICE_Parse: Sensor /ESP_1/THP1/Pressure => Pressure
Kann mir vielleicht jemand nur ganz knapp die wesentlichen Punkte erläutern?
Zunächst kommen die Werte für T und H. dann beginnt ein "notify loop". Irritierend finde ich hier, wieso da zwei Events steht, denn nur Humidity hat sich geändert. Und was passiert mit den weiteren Events? bleiben die außen vor?
Wie muss ich den Abschnitt notify loop insgesamt verstehen? Findet das alles innerhalb der "depoin"-Routine statt? Also auch die Erstellung des Userreadings mystate?
"Starting notify loop for XXX" und "End notify loop for XXX" wird in fhem.pl ausgegeben, und hat mit dem notify Modul selbst nichts zu tun.
Zwischen diesen beiden Aufrufen werden alle Instanzen aufgerufen, die sich fuer diese Events interessieren, in dem abgebildeten Beispiel war das eine dewpoint Instanz.
Ich wuerde userReadings auf genau ein Event begrenzen, und kein event-* Attribut setzen, es sei denn man versteht genau, was die tun.
Ich kann das von mir nicht behaupten.
Danke dafür, das hilft schon mal beim lesen der Logs.
Das Problem ist aber leider, dass sich verschiedene oder gar mehrere Werte bei mystate verändern können, bzw. Einfluss auf die Berechnungen nehmen. Damit wird es schwierig sich nur auf ein Event festzulegen. Im Zweifel passt dann die Kombination der im mystate angezeigten Wertekombinationen nicht zusammen.
Am coolsten wäre, wenn man den Aufbau des Userreading zeitlich verschieben könnte. Im Prinzip dürfte es nur ausgeführt werden, wenn die Routine "dewpoint" tatsächlich aufgerufen wurde. Ich denke ich werde mir vielleicht ein dummy bauen, in das ich alle paar Sekunden die aktuellen Werte hinein kopiere.
Während ich das schreibe fällt mir gerade was auf. Vielleicht hilft als Trigger beim userreading eben genau das Rechenergebnis "Dewpoint" aus der Routine "dewpoint"?
ZitatVielleicht hilft als Trigger beim userreading eben genau das Rechenergebnis "Dewpoint" aus der Routine "dewpoint"?
Genau das scheint es gewesen zu sein :)
Zusätzlich muss man vielleicht noch wissen:
event-on-change-reading Humidity,LWT,Temperature,mystate
event-on-update-reading Dewpoint