Hi,
ich habe mir eine kleine exponentielle Glättung gebastelt, dabei ist mir aufgefallen dass userReadings unter Umständen doppelt ermittelt werden, aber nur einmal im FileLog landen.
Hier ist meine Definition:
attr og_ku_HeizungOp userReadings test { 1 + ReadingsVal($name,"test",0);}
Dazu noch ein entsprechendes FileLog, in dem erwartungsgemäß das hier landet:
2014-01-21_19:02:22 og_ku_HeizungOp test: 1
2014-01-21_19:05:09 og_ku_HeizungOp test: 2
2014-01-21_19:07:40 og_ku_HeizungOp test: 3
2014-01-21_19:09:58 og_ku_HeizungOp test: 4
Das "og_ku_HeizungOp" ist der channel 04 (Clima) eines HM-CC-RT-DN. Wenn ich die selbe userReadings-Definition auf den HM-CC-RT-DN selbst loslasse, dann erscheint Folgendes im FileLog:
2014-01-21_19:14:53 og_ku_Heizung test: 2
2014-01-21_19:17:31 og_ku_Heizung test: 4
2014-01-21_19:19:55 og_ku_Heizung test: 6
2014-01-21_19:22:04 og_ku_Heizung test: 8
Anscheinend wird das Coding des userReadings zweimal ausgewertet, aber nur einmal ins FileLog geschrieben.
Woran könnte das liegen?
Falls sich jemand wundert, warum ich sowas mache: Die eigentliche Definition meines userReadings sieht so aus:
smoothActuator { my $old = ReadingsVal($name,"smoothActuator",0); my $curr = ReadingsVal($name,"actuator", $old."%"); (149 * $old + $curr) / 150; }
D.h. ich will eine exponentielle Glättung der Ventilstellungen machen.
Das Problem an den Logs, die dabei rauskommen, zu erkennen ist allerdings etwas schwierig.
Gruß,
Thorsten
Vermutlich ruft das HM Modul in der Parse Funktion zweimal readingsSingleUpdate auf.
Die Auswertung der userreadings erfolgt im readingsEndUpdate, die notitfy/FileLog-Benachrichtigung nach der Parse Funktion.
Fix: CUL_HM umstellen auf readingsBeginUpdate, 2x readingsBulkUpdate, readingsEndUpdate.
...also ein Homematic-Problem. Könnte jemand diesen Thread entsprechend verschieben?
generell wird bulk schon genutzt. Es gibt aber Fälle, da bietet es sich m.E. nicht an.In diesem Fall ist es wohl die Protokoll-auswertung, die quasi getrennt läuft.
Machbar ist dies sicher, würde aber bedeuten, dass das ganze halten der Änderungen über funktionen und logische Gruppen hinweg nachgebildet werden muss - unschön.
Würde deine Funktion den überhaupt funktionieren? Du willst doch nur arbeiten, wenn "actuator" geändert wird, nicht wenn irgend ein Reading geschrieben wird.
Ich werden erst einmal nicht ändern, scheint nicht sinnvoll
Gruss Martin
Zitat von: martinp876 am 22 Januar 2014, 09:10:31Würde deine Funktion den überhaupt funktionieren? Du willst doch nur arbeiten, wenn "actuator" geändert wird, nicht wenn irgend ein Reading geschrieben wird.
Ja, meine Funktion funktioniert gut, wenn ich sie in den Clima-Channel einbaue statt direkt ins Device. Die Funktion muss auch dann was tun, wenn nichts geändert wird. Nehmen wir mal an, dass ein Ventil zuerst auf 0% steht und dann dauerhaft auf 100%. Dann erwarte ich ja, dass die geglättete Version der Ventilstellung sich auch so langsam an 100% annähert. Wenn ich nur auf Änderungen reagieren würde, dann bekäme ich in meinem userReading gar keine Werte mehr.
Da ich eine exponentielle Glättung verwende, funktioniert das nur einigermaßen richtig, wenn ich annehme, dass die Readings einigermaßen gleichmäßig (über die Zeit) reinkommen. Das ist aber gegeben.
Ich könnte natürlich auch mit ReadingsTimestamp nachlesen, ob tatsächlich eine neue Messung vorhanden ist und nur dann wirklich was tun. Ich denke aber, dass es zumindest seltsam ist, wenn sich Werte "intern" ändern, aber nicht ins FileLog geschrieben werden.
(Ich weiß, dass ich um eine wirklich korrekte Glättung hinzubekommen eigentlich über die Zeit integrieren und dann durch die Zeit dividieren müsste. Dazu müsste ich mir aber die Messwerte für die letzte Stunde (oder wie lange das Intervall auch sein soll) merken oder jedesmal das FileLog nachlesen. Ich kann mir aber vorstellen, dass dann irgendwann das System (FritzBox...) in die Knie geht.)
Zitatwenn ich annehme, dass die Readings einigermaßen gleichmäßig (über die Zeit) reinkommen
genau das ist der Punkt (alles andere ist mir klar)
du gehst davon aus, dass IMMER wenn IRGENDEIN reading geändert wird eine Kalkulation gestartet wird. ok, nir einmal bei einem "Reading block".
Deine Funktion triggert also auch, wenn ein regSet oder ein getConfig auf den Kanal ausgeführt wird - das sehe ich als generelles Problem. Auch wenn die temp am Rad geändert wird, der mode umgeschaltet.....
Da dies aber selten stattfindet... da ist es einfach deine private Sache, dies zu berücksichtigen oder nicht
Da man, um eine gescheite Glättung zu erreichen, jeden einzelnen Wert sowieso nur mit einem kleinen Faktor berücksichtigen kann, macht das nichts. Die Abweichung, die sich dadurch ergibt, ist so bei 1%. Da muss man schon viel am Rad drehen...
Für mich selbst ist das auch gar nicht so wild. Ich komme auch so zurecht. Ich dachte nur, dass es vielleicht andere Anwendungen gibt (z.B. irgendwas zählen), bei denen das wichtiger ist.
Speziell wundere ich mich darüber, dass es offensichtlich Änderungen bei Readings gibt, die nicht im FileLog auftauchen.
ZitatIch dachte nur, dass es vielleicht andere Anwendungen gibt (z.B. irgendwas zählen)
was du zählst ist die Anzahl der Aufrufe einer Funktion. Der User sollte davon tunlichst nichts ableiten - das ist eigene Gefahr. es wird eben "irgendetwas" gewählt.
Rudis einwand ist berechtigt - ergonomische SW, weniger Aufrufe... aber in diesem Fall halte ich es für gerechtfertigt. Kann man drüber streiten... wie meist.
Zitatdass es offensichtlich Änderungen bei Readings gibt, die nicht im FileLog auftauchen.
ist das so? welche fehlen den?
Ist das Problem nicht einfach, dass eine message mehrere write2Reading auslösen kann?
Und ja, man kann readings setzen ohne einen trigger zu generieren. Ich versuche das so gering wie möglich zu halten... aber ein trigger ist immer auch CPU-aufwand
Gruss Martin
Hi,
das heißt also anders herum betrachtet, dass man mit dem Coding im User Reading vorsichtig sein muss. Man darf nicht einfach dumm das machen, was ich gemacht habe. Im Prinzip sollte man über den Timestamp prüfen, ob es sich tatsächlich um ein neues Reading handelt.
...mal sehen, vielleicht gelingt es mir noch, einen ordentlichen gleitenden Mittelwert zusammenzubasteln. Dann erledigt sich das Problem von selbst.
Gruß,
Thorsten
hi Thorsten,
ZitatMan darf nicht einfach dumm das machen, was ich gemacht habe.
Du solltest immer wissen, was du tust. Das Zählen der Aufrufe ist eben das zählen der Aufrufe - für den User normal keine aussage.
ZitatIm Prinzip sollte man über den Timestamp prüfen, ob es sich tatsächlich um ein neues Reading handelt.
Notifies sind hier auch möglich - die triggern und filtern. Du wolltest ja nicht bei jedem setzen irgend eines Readings reagieren sondern beim setzen eines bestimmten Wertes - das ist so nicht gegeben.
Gruss Martin
Du meinst es wäre besser, das über einen notify zu lösen, der dann (per setreading oder so) den entsprechenden Wert setzt?
ist zumindest eine Option. das kommt dann immer dran, wenn der gesuchte Wert besetzt wird (event-on-reading-update setzen - aber nur für dieses Reading)
einen percormance test habe ich nicht gemacht - aber in deiner Anwendung musst du (eigentlich) selbst auswerten, was geändert wurde.
Das ist dann ein dokumentiertes und gemaintaintes feature von FHEM (quasi einklagbar...)
Im anderen Fall kannst du nicht meckern, wenn jemand den Ablauf ändert und es dann nicht mehr klappt.