Abend zusammen,
ich weiß gerade nicht genau, wie ich am besten an ein kleines Problem herangehe. Vielleicht hat jemand einen Vorschlag, wie ich das Gesuchte am besten umzusetzen kann.
Ich habe ein Device, das Temperatur und Feuchtigkeits Readings bekommt. Diese treffen aber unabhängig voneinander ein, d.h. manchmal nur Temp und Hum erst einige Minuten später. Manchmal allerdings auch beide "gleichzeitig" also innerhalb 1 Sekunde.
Ich berechne mir bei einem eingehenden Event den Taupunkt über folgendes userreading:
attr <device> userReadings dew:(temperature|humidity).* { dewpoint($name) }
Dadurch wird allerdings nun der Taupunkt doppelt berechnet, wenn die beiden Readings zur selben Zeit eintreffen. Vor allem wenn sich Temp und Hum in kurzer Zeit stark geändert haben (z.b. Badezimmer) beinhaltet die erste Berechnung dann einen großen Fehler.
Ich suche jetzt die beste Möglichkeit, wie ich diese Doppelberechnung verhindern könnte. Die Berechnung müsste also ausgelöst werden, sowohl wenn nur eines der Readings auftritt, als auch wenn beide gleichzeitig kommen, dann allerdings eben nur einmalig.
Grüße,
Christian
Leg doch beide werte-updates in userreadings und mach ein zyklisches at mit dem fct-aufruf mit diesen userreadings. Damit bist du unabhängig wann die werte aktualisiert werden
Gesendet von meinem GT-I9301I mit Tapatalk
wenn humidity immer als zweites kommt nimm das als trigger. wenn die reihenfolge unbestimmt ist nimm irgend eines der beiden als trigger. wenn die werte nicht gleichzeitig kommen ist der berechnete wert sowieso nie aktuell. die abweichung sollte so minimal sein das es egal ist.
es gibt kein gleichzeitig. die events kommen immer nacheinander. wenn du beim ersten event etwas tust weisst du nicht ob es gleich noch das andere gibt.
und was spricht gegen das dewpoint modul ?
gruss
andre
Danke euch beiden schonmal für die schnellen Antworten. Das mit dem zyklischen berechnen ist schonmal ein guter Ansatz.
@justme1968 Das ist ja im Endeffekt genau das was ich geschrieben habe :). Sehe jetzt nicht, wie das mein Problem lösen sollte.
Zitat
wenn humidity immer als zweites kommt nimm das als trigger. wenn die reihenfolge unbestimmt ist nimm irgend eines der beiden als trigger. wenn die werte nicht gleichzeitig kommen ist der berechnete wert sowieso nie aktuell. die abweichung sollte so minimal sein das es egal ist.
Temp und Hum werden vom Sensor schon im gleichen Zyklus gemessen. Hat sich aber Temp oder Hum im Vergleich zum letzten gesendeten Wert nicht verändert, wird eben nur einer bzw. garkein Wert geschickt. Deswegen kann ich nie davon ausgehen, dass Hum als Zweiter ankommt, weil manchmal eben nur die Temperatur gesendet wird. Deswegen sind die Werte allerdings schon korrekt, auch wenn eben nur ein Reading aktualisiert wird.
Zitat
es gibt kein gleichzeitig. die events kommen immer nacheinander. wenn du beim ersten event etwas tust weisst du nicht ob es gleich noch das andere gibt.
Das es kein gleichzeitig gibt ist mir schon klar. Das sollten die Anführungszeichen und das "also innerhalb 1 Sekunde" andeuten ;)
Zitat
und was spricht gegen das dewpoint modul ?
Habe ich damit nicht das selbe Problem ?
wie oft senden deine sensoren denn? das schlimmste was passiert ist das der dewpoint erst beim nächsten senden aktualisiert wird. warum ist es dir so wichtig das du die änderung im dewpoint so schnell bemerkst? reicht nicht einfach der nächste sende zyklus? wenn nichts gesendet wird heisst das doch es hat sich auch nichts geändert und dewpoint kann sich nicht geändert haben. andererseits bewirkt fenster auf oder duschen ziemlich sicher eine temperatur änderung bevor sich die feuchte ändert.
wenn die werte nicht gleichzeitig gemessen sind passt der dewpint wert doch sowieso nicht exakt. und wenn er sich im nächsten zyklus ändert sollte das für alle anwendungen im haus doch reichen.
warum sollte das zyklische berechnen besser sein als sich an einen der beiden messwerte zu hängen. genauer ist das nicht. nimm den messwert der sich vermutlich öfter ändert.
ich glaube du versuchst eine genauigkeit zu erreichen die deine sensoren garnicht her geben.
ja. mit dewpoint hast du das problem wenn die werte nicht gleichzeitig vom sensor kommen.
gruss
andre
Der Sensor misst jede Minute einmal Temp und Hum. Ändert sich ein Wert nicht um einen bestimmten Wert zum letzten geschickten, wird dieser erst nach 60 min spätestens erneut geschickt. Würde ich die Berechnung also nur auf ein Reading hängen, könnte die Berechnung im worst case eben um bis zu 60 min verzögert sein.
Ja du hast vollkommen Recht, wenn du sagst, dass das eh nicht vorkommt. Ich wollte halt eine möglichst perfekte Lösung haben :). Prinzipiell ist das nicht wirklich wichtig und total übertrieben ;), das stimmt schon.
die perfekt lösung wäre einen anderen sensor zu kaufen der immer sendet :)
Das sind MySensors Sensoren .. also selbst programmiert :). Dabei gehts nur ums Batterie und Funktraffic sparen.
jetzt bin ich aber neugierig :)
hast du mal gemessen ob immer beides (temp+hum) zu senden wirklich mehr batterie braucht als jedes mal den zusätzlichen code zu durchlaufen der bestimmt was gesendet wird?
wie oft passiert es das sich einer der beiden ändert und der andere nicht genug?
sind die nachrichten wirklich so kurz das der zusätzliche wert ins gewicht fällt?
oder bedeutet die eine sekunde unterschied das der sensor auf jeden fall beides nacheinander sendet und nicht in einer einzigen nachricht? dann würde ich hier optimieren.
Ne also gemessen hab ich da nix ^^ Da bräuchte man schon sehr genaue Messungen um da wirklich Unterschiede festzustellen.
Ich bin mir aber sehr sicher, dass das Senden der Nachrichten auf jeden Fall am teuersten ist. Grundsätzlich braucht Funk halt die meiste Energie und da die Funkfrequenz bei den Dingern ja 2,4 GhZ ist und in meinem Mietshaus hier das Band durch die vielen WLANs eh schon am platzen is, muss ich die Nachrichten teilweise bis zu 3 oder 4 mal wiederholen bis sie ankommen.
Ob man die Nachrichten zusammenfassen kann weis ich nicht.
Lösung wär natürlich, dass die dew-Berechnung bei nem Hum Event ausgelöst wird und Hum einfach immer geschickt wird, wenn Temp geschickt wurde.
Allerdings is mir auch grad noch was eingefallen. Sollte es nicht gehen, wenn idh mit nem Notify auf das Temp oder Hum Event reagiere und dann ein At absetzt, das die Berechnung dann paar Sekunden später ausführt.
Was passiert denn, wenn ein At defined wird, das noch nicht abgelaufen ist ?
du kannst das alte at mit defmod überschreiben, du kannst ein sleep verwenden und löschen falls es schon da ist, du kannst einen watchdog verwenden.
aber ich denke all das ist übertrieben wenn die messung an sich nicht schon viel genauer ist
Klar isses übertrieben 8).
Aber vielen Dank ! Defmod und At ist perfekt. Genau nach sowas hab ich gesucht.
Gute Nacht wünsch ich dir noch :)
Fein, erfahrungsaustausch bringt alle voran!
Gesendet von meinem GT-I9301I mit Tapatalk