Ausgangssituation
Oft sind die Sensorsignale-Signale sehr dynamisch und mit regellosen Störsignalen überlagert, so daß es manchmal ganz hilfreich sein kann , wenn man diese Messsignale „glättet“. Der Elektroniker macht das meistens mit einem Tiefpass in Form eines sehr einfachen RC-Gliedes. Bei SmartHome Steuerungen liegen die Signale aber meistens als Information auf dem Controller vor, so daß es nicht möglich ist, die Signale hardwaremäßig zu glätten. Die Lösung ist in diesem Fall mit Software-Methoden anzustreben.
Lösungsansätze
Wenn man die KI-Suchmaschine Bing befragt: „wie kann man Messsignale glätten?“ , dann erhält man folgende hilfreiche Antwort:
Es gibt verschiedene Methoden, um Messsignale zu glätten, die je nach Art und Zweck des Signals angewendet werden können.
Eine häufige Methode ist die Verwendung eines RC-Tiefpasses, der ein elektronisches Filter ist, das nur niedrige Frequenzen durchlässt und hohe Frequenzen unterdrückt. Das Rauschen ist meist eine hochfrequente Störung, die sich dem Messsignal überlagert. Durch einen RC-Tiefpass kann das Rauschen reduziert und der Mittelwert des Messsignals ermittelt werden.
Eine andere Methode ist die Fouriertransformation, die ein mathematisches Verfahren ist, das ein Messsignal in seine spektralen Komponenten zerlegt. Das Spektrum zeigt an, welche Frequenzen in dem Signal enthalten sind und wie stark sie sind. Durch eine Fouriertransformation kann man das Signal vom Rauschen trennen, indem man nur die gewünschten Frequenzbereiche berücksichtigt und die anderen ignoriert.
Eine weitere Methode ist die Derivativ-Methode oder Ableitungs-Methode, die eine mathematische Operation ist, die die Änderungsrate eines Signals bestimmt. Durch eine Ableitung kann man überlappende Signale auflösen, indem man zusätzliche Extrema erzeugt. Zum Beispiel kann man zwei Absorptionsbanden in einem Spektrometer unterscheiden, indem man die erste oder zweite Ableitung des Signals bildet.
Es gibt noch andere Methoden, wie z.B. den gleitenden Mittelwert, den exponentiell geglätteten Durchschnitt oder den linear gewichteten gleitenden Durchschnitt, die das arithmetische Mittel von einer festen oder variablen Anzahl von Datenpunkten berechnen, die sich mit dem Signal verschieben oder alle bisherigen Datenpunkte berücksichtigen. Diese können gleichgewichtet oder gewichtet sein, um den neueren oder älteren Daten mehr oder weniger Bedeutung zu geben.
Der „Softwerker“ ist schnell dabei, mit dem gleitenden Mittelwert das Problem zu lösen. Der „Hardwerker“ ist mit dem Lötkolben und wenigen elektronischen Bauteilen mit einem RC-Tiefpass schnell am Ziel. Entsprechende Lösungsansätze für die Verwendung in Verbindung mit der Homematic kann man u.a. in den entsprechenden Foren finden.
Hier möchte ich einen besonders einfachen Ansatz zeigen, bei dem ein RC-Tiefpass durch eine mathematische Simulation näherungsweise nachgebildet wird.
Grundlagen zur Nachbildung eines RC-Tiefpasses
Mit der Homematic kann man rechentechnisch Informationen nur mit einem HM-Skript bearbeiten. Das reicht aber aus, um einen RC-Tiefpass nachzubilden. Bei dem Skript hat man ein ungefiltertes Eingangssignal „signal_in“ , das von einem Sensor oder Aktor kommen kann. Dieses „signal_in“ kann man mit folgender Formel zu dem geglätteten neuen „signal_avg“ mit folgender Formel umrechnen :
signal_avg = signal_avg + ( k * (signal_in – signal_avg) )
Dabei wird diese Formel zyklisch in einem bestimmten Zeitabstand (delta) ausgeführt. Während beim Hardware-RC-Glied die sog. Zeitkonstante sich mit T = R*C berechnet, ist beim dieser Nachbildung die Zeitkonstante näherungsweise T = delta / k. Die Konstante k ist 1, wenn keinerlei Tiefpasswirkung erreicht werden soll. Je kleiner diese Konstante k wird, desto stärker ist die Tiefpasswirkung. Üblicherweise liegt k zwischen 0.02 (starke Mittelung) und 0.5 (schwache Mittelung) bzw. 1.0 (keine Mittelung). Die Abtastrate delta liegt bei den typischen Homematic-Signalen (z.B. Temperatur) bei 1 bis 3 Minuten. Man sollte nicht kleiner als 1 min werden, weil das die CCU nur unnötig belastet.
Umsetzung auf der CCU
Das HM-Skript wird zyklisch (bei mir alle 2 min) ausgelöst. Das zugehörige WebUI-Programm sieht so aus:
Das HM-Skript muß natürlich den speziellen eigenen Anforderungen angepasst werden. Das ist mit den auskommentierten Erklärungen im Skript (Zeilen beginnen mit ! ) aber ganz leicht. Und nicht vergessen, zur Ausgabe des gemittelten Messsignals vorher auf der CCU eine Systemvariable „signal_avg“ vom Typ Zahl anlegen:
!stall.biz >> HM-Skript zur Glaettung von Messsignalen
!vorher auf der CCU eine Systemvariable „signal_avg“ vom Typ Zahl anlegen
!dieses Skript zyklisch aufrufen >> z.B. alle 2min
!Zeitkonstante T = Abtastzeit / k
!############ Hinweis #########################################
! Um das Signal_von den verschiedenen HM-Produkten/Datenquellen zu holen, muss man leider so abfragen:
! dom.GetObject(„BidCos-RF.HEQ08155716:1.DATENPUNKT“).Value() >> fuer HM Funk
! dom.GetObject(„HmIP-RF.000BC081516A:0.DATENPUNKT“).Value() >> fuer HM IP Funk
! dom.GetObject(„BidCos-Wired.AB081516:0.DATENPUNKT“).Value() >> fuer HM wired
! dom.GetObject(„HmIP-RF.0001151617HG:0.DATENPUNKT“).Value() >> fuer HM IP wired
! dom.GetObject(„name_systemvariable“).Value() >> fuer Systemvariable
!############ HM-Skript #########################################
real k = 0.05; !Werte zwischen 0.02 und 1.0 je nach Mittelung
real signal_in = dom.GetObject(„BidCos-RF.IEQ0405570:1.TEMPERATURE“).Value(); !Holen des zu glaettenden Messwertes
real signal_avg = dom.GetObject(„signal_avg“).Value(); ! letzten gemittelten wert von „signal_avg“ holen
signal_avg = signal_avg + ( k * (signal_in – signal_avg) ); !neue mittelung
dom.GetObject(„signal_avg“).State(signal_avg); !gemittelten Wert in Systemvariable signal_avg zuruck
!WriteLine(‚hallo Welt‘);
Dieses Skript verwendet im Gegensatz zur gleitenden Mittelwertberechnung sehr wenig Resourcen, so daß man ohne weiteres die Mittelung auch bei mehreren Messignalen anwenden kann. Notwendig ist die Definition nur einer zusätzlichen Systemvariablen, die auch gleichzeitig der Ausgangswert ist. Insbesondere bei kleinen Abtastzeiten bis 1min kann es sinnvoll sein, den CuxD-Timer für die regelmässige Auslösung des Skriptes zu verwenden, weil der Standard-Timer der CCU manchmal Zuverlässigkeitsprobleme hat. Ich selbst hatte damit bisher keine Probleme, aber in Foren wird manchmal darüber berichtet.
Ich verwende diese Mittelwertbildung beispielsweise bei diesem einfachen Sonnensensor oder bei diesem beim mir schon 10 Jahre sehr gut funktionierenden Sonnensensor. Deren Temperatur schwankt bei wolkigem Himmel sehr stark, so daß die von diesem Wert gesteuerten Beschattungsmaßnahmen manchmal sehr „unruhig“ agieren. Mit der hier dargestellten Mittelwertbildung werden diese Aktionen weitaus ruhiger. Die folgenden Aufzeichnungen zeigen das originale Temperatursignal und das gemittelte Signal mit einer Abtastrate von 2min und einem k-Wert von 0.05 was einer Mittelungszeit T von etwa 40min entspricht.
