Moin zusammen,
Ich wollte die Daten in meinem Log etwas reduzieren, indem ich nur schreibe, wenn Änderungen der Temperatur anliegen. Was liegt da erst einmal näher, als das Atribut event-on-change-reading zu setzen? Leider sehe ich dann überhaut keine Events mehr und demzufolge werden auch keine Einträge mehr im Filelog erstellt.
Aber eigentlich war das auch nur der 1. Versuch, denn ich brauche keine Temperaturdifferenzen in der 3. oder 4. Nachkommastelle. Mir würde eine Auflösung von 0,5° ausreichen. Einfacher gerundet also auf 0,1°.
Leider habe ich hier nichts zum Runden gefunden und habe nur eine Idee, die vermutlich aber viel zu kompliziert ist: Ich baue pro Sensor ein Notify und ein Dummy. Mit den Notify's schreibe ich dann die gerundeten Werte in die Dummy's.
Kann ich alternativ auch die Definitionen OWDevice in OWMULTI wandeln, aber auch da kommt bei gesetztem Atribut event-on-change-reading nix raus.
Oder gibt es da noch einen kürzeren/besseren Weg?
ungekürzte Grüße
Niels
Attr gemäß commandref gesetzt?
Ohne listing können wir leider nur spekulieren!
wie sieht den das device von den readings aus und wie deine event-on-change-reading definition?
mit userReadings könntest du zb die werte runden / auf eine nachkommastelle kürzen was auch immer da du auch perl code mit eingebunden werdne kann. dann diese usewrreadings in event-on-change-reading aufnehmen
wenn du ds18b20 verwendest kannst du resolution passend setzen. auf 9 oder 10. das vermindert die anzahl der nachkomma stellen und beschleunigt das auslesen.
der ds18s20 kann das glaube ich nicht und du musst über ein user reading gehen.
du musst event-on-change-reading nicht auf 1 setzen sondern auf den namen des readings um das es geht.
schau dir neben event-on-change-reading auch noch event-min-interval und event-aggregator
an.
gruß
andre
Danke für Eure Hilfe!
Zitat von: justme1968 am 21 Mai 2015, 09:19:06du musst event-on-change-reading nicht auf 1 setzen sondern auf den namen des readings um das es geht.
OK, hier ist also schon mal mein grundsätzlicher Fehler! Den Rest muss ich nochmal genießen, wenn ich wieder auf meine Büchse komme.
grundsätzlich fehlerhafte Grüße
Niels
Ahh, Dank Eurem Schubs in die richtige Richtung habe ich das dann auch alles gefunden (hoffe ich zumindest):define 1Wire_TerraTemp_RU OWDevice 10.8653B3020800 30
attr 1Wire_TerraTemp_RU IODev localOWServer
attr 1Wire_TerraTemp_RU alias E.T. rechts unten
attr 1Wire_TerraTemp_RU event-on-change-reading Temperatur
attr 1Wire_TerraTemp_RU model DS18S20
attr 1Wire_TerraTemp_RU room OWDevice,Terrarium
attr 1Wire_TerraTemp_RU userReadings Temperatur { int ( 10 * ReadingsVal("1Wire_TerraTemp_RU","temperature",0) + 0.5 ) / 10 }
Aber natürlich wecken diese direkten, einfachen Wege bei mir wieder Begehrlichkeiten ::)
Nun will ich im Listing der Devices, wenn ich den Raum aufrufe, natürlich auch nicht mehr 'E.T. rechts unten
temperature: 17.8125 alarm: 0' sehen, sondern 'E.T. rechts unten
Temperatur: 17.8'.
Da gibt es doch sicher auch wieder was ganz kurzes Geniales, wo ich nur zu blöd bin, das zu finden :'(
Ach ja, und auf die unwahrscheinliche Gefahr hin, dass jetzt die Temperatur lange konstant ist, wäre es natürlich noch cool, stündlich ein Event zu erzwingen...
blinde Grüße
Niels
dazu gibt es stateFormat (wenn es dir nur um die anzeige geht reicht das übrigens. ganz ohne user reading) und für das trozdem erzeugen event-min-interval.
Hey super - Danke ;D
Ich wusste, dass das viel zu einfach geht :P <*duckundwech*>
Dabei habe ich jetzt auch gleich noch gelernt, dass man über die Command-Line allen Sensoren ein Attribut mit einem Schlag verpassen kann, wenn man sie vorher vernünftig benannt hat und dann mit einem regulären Ausdruck zu fassen bekommt. Genial!
begeisterte Grüße
Niels
Zitat von: justme1968 am 21 Mai 2015, 15:05:47... und für das trozdem erzeugen event-min-interval.
Da ist die Command-ref alledings andere Meinung:
ZitatDieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind.
Oder bedeutet das, dass ein anderer Wert im Event trotzdem das Event auslöst und nur bei gleichem Wert die Auslösung unterdrückt wird? Das kann ich weder in den englischen noch den deutschen Text rein interpretieren...
zitierte Grüße
Niels
wo siehst du den wiederspruch?
wenn event-on-change-reading gesetzt ist wird ein event nur dann erzeugt wenn sich der wert geändert hat
wenn event-min-interval gesetzt ist wird ein event nur erzeugt wenn seit dem letzen event die minimale zeit vergangen ist
wenn beide gesetzt sind wird ein event erzeugt wenn sich der wert geändert hat oder die minimale zeit vergangen ist. das ist doch genau das was du willst...
gruss
andre
Ahh, jetzt ja! Ich hatte erwartet/interpretiert, dass sich die beiden Atribute sozusagen gegenseitig aushebeln, nachdem es nicht funktionierte. Nun habe ich sie wieder drin, mal sehen ob es jetzt klappt. Vielleicht hatte ich erst noch einen Fehler drin...
Dann bin ich jetzt hier angelangt:define 1Wire_TerraTemp_RU OWDevice 10.8653B3020800 240
attr 1Wire_TerraTemp_RU IODev localOWServer
attr 1Wire_TerraTemp_RU alias E.T. rechts unten
attr 1Wire_TerraTemp_RU event-min-interval Temperatur:1200
attr 1Wire_TerraTemp_RU event-on-change-reading Temperatur
attr 1Wire_TerraTemp_RU group Messwerte
attr 1Wire_TerraTemp_RU model DS18S20
attr 1Wire_TerraTemp_RU room OWDevice,Terrarium
attr 1Wire_TerraTemp_RU sortby 60
attr 1Wire_TerraTemp_RU stateFormat Temperatur°C
attr 1Wire_TerraTemp_RU userReadings Temperatur { int ( 10 * ReadingsVal("1Wire_TerraTemp_RU","temperature",0) + 0.5 ) / 10 }
fehlinterpretierte Grüße
Niels
wie gesagt... wenn es dir nur um die nachkommt stellen bei der anzeige geht würde ich auf das user reading verzichten und die angezeigten nachkommastellen per attr 1Wire_TerraTemp_RU stateFormat{sprintf("%.1f",ReadingsVal($name,"temperature",0))."°C"}formatieren. dann bleibt ansonsten alles beim 'standard' reading temperature.
gruss
andre
So, jetzt sieht es wohl gut aus 8)
Zitat von: justme1968 am 21 Mai 2015, 20:28:36wie gesagt... wenn es dir nur um die nachkommt stellen bei der anzeige geht würde ich auf das user reading verzichten
JIst gespeichert, aber in diesem Fall sieht die Kurve im Plot auch besser aus, wenn sie nicht so zittert.
geglättete Grüße
Niels
Ich kann nicht glauben, dass in in ordentlichen Abständen genommene Temperaturkurve "zittert" - dazu ist die Wärmeträgheit des gemessenen Systems viel zu groß.
Im OWTHERM-Modul ist übrigens ein einigermaßen intelligente Rundung eingebaut.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 21 Mai 2015, 21:35:23
Ich kann nicht glauben, dass in in ordentlichen Abständen genommene Temperaturkurve "zittert" - dazu ist die Wärmeträgheit des gemessenen Systems viel zu groß.
Das ist bei genauerer Betrachtung wohl wahr. Die Linie wird sich nach dem Testlauf definitiv noch relativieren. Ich lasse die Y-Achse automatisch skalieren und im Moment ist die Temperatur recht stabil, da das Terrarium noch im Keller steht und sich im Bau befindet. So reicht die Skala momentan nur von 17°C bis 19°C. Im Betrieb wird diese sich zwischen 20°C und 50°C bewegen. Damit werden die Linien dann natürlich auch extrem glatt gebügelt.
Unterm Strich ist die Reduktion der Log-Informationen und der damit verbundene Performanceschub beim Aufbau des Plots der größte Vorteil der Rundung.
relative Grüße
Niels
Ich glaube ebenfalls nicht, dass sich die Anzahl der Nachkommastellen signifikant auf die Darstellungsgeschwindigkeit auswirkt.
LG
pah
Nein, die Anzahl der Nachkommastellen wohl kaum. Aber die Anzahl der Werte! Hier ist deutlich zu beobachten, wie die Geschwindigkeit mit wachsender Dateigröße sinkt und ich habe nur ein Leseintervall von 240 Sekunden, aber eben auf 6 Werte. Umso mehr Nachkommastellen, umso größer ist die Wahrscheinlichkeit einer Änderung zwischen 2 Messungen. Daher reduziert sich die Datenmenge schon deutlich, wenn man das event-on-change-reading auf den gerundeten Wert anwendet.
Alternativ könnte man evtl. noch die monatliche Logdatei auf täglich oder wöchentlich umstellen, zumal in diesem Fall eine Aufbewahrung von 1-2 Monaten völlig ausreicht. OK, täglich ist vermutlich kein Problem, aber geht auch wöchentlich (nur ml so aus purem Interesse gefragt)?
Eine weitere Alternative ist, alles auf Datenbank umzustellen, aber das steht eigentlich deutlich weiter hinten auf meiner Roadmap und ich mag aus Zeitgründen hier nun keine weitere Baustelle aufreißen. Dazu möchte ich erst einmal mehr Sicherheit im Umgang mit FHEM bekommen.
runde Grüße
Niels
Das ist, pardon das direkte Wort, immer noch Unsinn. Natürlich dauert es eine ganze Weile, aus einigen zehntausend Werten die paar herauszusuchen, die man für einen kurzen Plot benötigt - das macht das FileLog Modul, das vom SVG-Modul mit den Suchparametern aufgerufen wird.
Aber erstens ist es tatsächlich Unsinn, minütliche Temperaturwerte über einen ganzen Monat aufzuzeichnen - die schaut niemand jemals wieder an.
Und zweitens ist es für Langzeitaufzeichnungen Unsinn, jeden Sensor in eine eigene Zeile zu schreiben. Dafür macht man eine ReadingsGroup auf und lässt diese über einen zyklischen Timer z.B. alle 5 Minuten abfragen. Hat somit alle z.B. Temperaturen zu einem gegebenen Zeitpunkt in einer Zeile, und die Abfrageintervalle der Einzelsensoren sind vollkommen irrelevant.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 22 Mai 2015, 07:51:26Das ist, pardon das direkte Wort, immer noch Unsinn.
Wenn es so ist, dann ist es so ;)
Zitat von: Prof. Dr. Peter Henning am 22 Mai 2015, 07:51:26Und zweitens ist es für Langzeitaufzeichnungen Unsinn, jeden Sensor in eine eigene Zeile zu schreiben. Dafür macht man eine ReadingsGroup auf und lässt diese über einen zyklischen Timer z.B. alle 5 Minuten abfragen. Hat somit alle z.B. Temperaturen zu einem gegebenen Zeitpunkt in einer Zeile, und die Abfrageintervalle der Einzelsensoren sind vollkommen irrelevant.
Hey, genau der Hinweis auf die ReadingGroups hat mir gefehlt! Schon studiert und in der Umsetzung ;D
Dank vernünftiger Benennung der Sensoren ist das auch gut zu greifen:
define Terrarium_reading_grp readingsGroup 1Wire_Terra.*:(Temperatur)|(Luftfeuchte)
Nun muss ich nur noch kapieren, wie ich das zyklisch logge...
Ich bin begeistert, nur fällt es mir noch sehr schwer, die passenden Optionen zu finden, da die Möglichkeiten unglaublich sind. Ich denke da immer noch zu stark in den Dimensionen meiner Buyware-Büchse, bei der man alles aus den wenigen zur Verfügung stehenden Modulen bauen muss. FHEM hingegen bietet ja für jede Lebenslage das passende Modul, man muss es nur kennen bzw. die passenden (Such)worte formulieren können um es zu finden.
begeisterte Grüße
Niels
Mit einem at oder DOIF einen Event generieren und den zuerst im Event Monitor überprüfen und dann in einem FileLog abfangen.
LG
pah
OK, Teil 1 war mir klar, ein Event schlechthin zu erzeugen ist auch nicht das Thema. Doch welches Event beinhaltet alle Messwerte? Da ist meine Suche erfolglos geblieben, oder soll das Event wirklich nur ein Trigger sein und ich muss im Filelog die Werte aktiv lesen (so das überhaupt geht...)?
unklare Grüße
Niels