Hallo,
ich hab ne mysql-Datenbank am laufen, in die ich alle 5 Minuten die Daten meiner Wettersensoren eintrage. Dummerweise aktualisieren diese nicht regelmässig (sei es wegen Funkstörungen oder weil mal wieder ne Batterie leer ist). Jetzt kam mir der Gedanke, die Daten nur einzutragen, wenn diese auch aktualisiert wurden. Nur wie realisiere ich das am geschicktesten?
Vielleicht könnt ihr mir da ja weiterhelfen!
schöne Oster-Grüße aus Oberfranken
jgoller
Feuer dein SQL-Statement doch in einem Script ab, dass du auf onChange triggerst.
Gruß,
Toni
Hallo Toni,
ich kriegs irgendwie nicht hin. Was muss ich denn wohin schreiben oder eintragen, das das funktioniert?? ich hab das mit dem Timer/Trigger Editor probiert und im Timer Script steht jetzt folgendes:
//test
if(onChange(IPS_GetUpdateTime(KS300_Luftdruck))) {
echo "Timer [test] Triggered";
IPS_RunScriptEx("test", Array("TWZ_LASTTIMER"=>$lasttimer));
}
Das gibt aber leider eine Fehlermeldung.
Kannst du mir da nochmal detailierter weiterhelfen, bitte?
Gruss
jgoller
Nee, so wird das nix…
Du legst ein neues script an und klickst oben rechts auf events. Dort findest du onChange (siehe Bild) und verknüpfst es mit der variable, die es überwachen soll. Das Script wird nun immer ausgeführt wenn diese Variable sich ändert.
Im Script schreibst du dann was passieren soll wenn sich die Variable ändert. Also dein „SQL-Zeugs“
Gruß,
Toni
Entschuldige, wenn ich auf die Nerven gehe!
Aber es funktioniert immer noch nicht. Time Intervall muss auf 0 bleiben? Muss ich im Timer/Trigger-Dingens [F6] noch irgendwas angeben oder einstellen???
Wäre ja zu einfach gewesen, wenns gleich funktioniert hätte!
Gruss
jgoller
OK, jetzt scheint es zu funktionieren. Man sollte halt auch mal ins IPS-online-Handbuch schauen!!!
Ich hab jetzt das Timer-Event „OnUpdate“ verwendet. Dieser löst das Skript aus, wenn die Variable aktualisiert wird, auch wenn der Wert gleich bleibt.
Vielen Dank für die Hilfe, auch wenn ichs -fast- selbst gelöst hab.
Ihr seid super, macht weiter so!!
Gruss
jgoller
Hi jgoller,
das Prinzip mit den Events funzt auch prima mit einigen 100 unterschiedlichen Event-Variablen an einem Script. Das Schreib-Verriegeln macht dann ja der DB-Server
Aber Erfahrungswert: Nimm, wo immer du kannst „onChange“, zusammen mit einem Zeitstempel (z.B. als Defaultwert / Not NULL an einer Spalte deiner SQL-Table, dann gehts immer von alleine)
Vorteil: Erheblich weniger Daten(müll) im SQL-Server. Da werden dann nur die Werte eingetragen, die neue Inhalte haben. Der Zeitstempel sagt zusätzlich „gültig ab diesem Zeitpunkt“. Wenn du dagegen „onUpdate“ einträgst, bekommst du zwar mehr „Stützwerte“, aber ohne Informationsgewinn. Denn zusätzlich wären ja nur die drinne, die keine neuen Werte annehmen, und die hast du ja sowieso schon durch das „gültig ab“ im Zeitstempel.
So schnell ändern sich z.B. Temp- oder Feuchte-Werte in der Praxis nicht. Aber alle paar Minuten kommen neue Funktelegramme, gerade bei HMS100 oder Wetterstationen. Bei Indoor (Heizungen / FHT) sind die realen Schwankungen noch geringer.
Weiterhin passt dieses Prinzip am Besten zu den sowieso „stochastisch“ reinkommenden Werten der Sensoren, wo sowieso sinnvollerweise eine „Annahme, dass die Werte dazwischen gleich waren“ gelten muß.
Ausnahmen (bei mir), wo anderes als „onChange“ sinnvoll ist zu triggern:
onUpdate
- Windgeschwindigkeit
Die schwankt normalerweise so sehr (Böen), da ist es gerade interessant, wenn die „immernoch exakt gleichen Wert liefert“ (z.B. brauchbar für Erkennung „Sensor verloren“)
Edit:
Aber: Ich wohne an der Küste, da ist fast immer Wind und „onChange“ de facto identisch zur Wertemenge bei „onUpdate“!
onValue
-
Piri (Bewegungsmelder, z.B. FS20 PIRI2) : true
nur steigende Flanke. Der Status bleibt bei den Dingern bis zum manuellen / per Script zurücksetzen gesetzt. Fallende Flanke hätte nichts mehr mit Auslöseereignis zu tun
-
dto. bei HMS100- und FHT-Batteriewarnungs-Signalen
-
SR (Regensensor) getrennte abgeleitete Variablen für Beginn/Ende-Zeitpunkt des Regens; deren fallende / steigende Flanke. Grund ist, daß mir der Sensor zwischendurch zu sehr „flattert“ (kurzzeitige Aussetzer des Regens z.B. bei Niesel), was per Script ausgeglichen wird. Also erst Pausen länger Zeitraum x werden als Regenende akzeptiert und nachträglich als solche zugewiesen
Aber das ist dann je nach Wert und Verarbeitungsziel individuell zu entscheiden. Bei allen anderen Werten reicht onChange.
Das nur mal so als Praxiserfahrung. Vielleicht hilft dir das ja.
Gruß Gerd