FHEM - Entwicklung > FHEM Development

Muster in Zahlenreihen erkennen; Intelligentes FHEM

(1/3) > >>

KölnSolar:
Hallo Ihr Lieben,

ich setze mich gerade mit dem Thema Mustererkennung in Daten auseinander. Also nicht Texte, wo Perl ja prädestiniert wäre, sondern Muster in Zahlenreihen. Konkret ist der Hintergrund, dass ich gerne aus meinen Stromleistungsdaten/Phase die Aktivzeit(Kühlphase) von Kühl-,Gefriergeräten erkennen möchte, ohne dass ich jetzt z.B. ein device zur Strommessung explizit am jeweiligen Gerät angeschlossen habe(die devices u./o. einen Rückkanal an Aktoren könnte man sich dann sparen). Betrachtet man die Plots der Leistungsreihen, so fällt dem intelligenten Menschen sofort auf, dass die Leistungsaufnahmen der einzelnen elektr. Geräte ein sich wiederholendes deutliches Muster(Details später)/Gerät aufweisen.

Nun hab ich mal ein wenig recherchiert und stellte fest, dass es in der Theorie einiges im Internet zu finden gibt. Hier bei uns in FHEM findet sich nichts, außer dass hier und da der Bedarf geäußert wird. Ich selber sehe den Nutzen primär in der Analyse von Stromleistungsdaten, aber sicherlich gibt es auch andere Felder, wo eine allgemeine Mustererkennung in FHEM Anwendung finden könnte. Mir kommt da z.B. die Erkennung von Großwetterlagen und Heizungssteuerung in den Sinn.

Im Sinne eines Pflichtenhefts, gilt es meiner Ansicht nach zwischen 2 allgemeinen Kernfunktionalitäten bei der Mustererkennung zu unterscheiden:
1. eigenständige erstmalige Erkennung von bisher unbekannten Mustern(also etwas, was ich als KI bezeichnen würde) aus beliebigen Datenreihen
2. Anwendung eines bekannten/definierten Musters, um dessen erneutes/wiederholtes Auftreten zu erkennen(das ist für mich kein KI, sondern "simple" Datenverarbeitung)

Wenn jemand einen Link auf Theorie oder gar Algorithmen, Code-Schnipsel beisteuern kann, freue ich mich über eine Dokumentation in diesem Thread.

Das oben unter 1. als "erstmalige Mustererkennung" bezeichnete, sehe ich erst einmal als nicht einfach u. schnell realisierbar an. Die Definition und Anwendung eines Musters halte ich hingegen in der FHEM-Umsetzung für realistisch. Dabei möchte ich mich über 2 beispielhafte Gerätetypen an das Ziel herantasten:
1. Kühl-/Gefrier-/Klimageräte, die aufgrund ihres Kompressors ein außergewöhnliches, typisches Muster erkennen lassen
2. Bewegungsmelder, die etwas schalten, was dann zu einem typischen Rechteckverlauf in den Daten führt

Zu 1.: Die Geräte haben eine typische Leistungsspitze nach dem Einschalten. Relativ schnell sinkt die Leistungsaufnahme ein wenig auf ein Niveau ab, das dann dauerhaft und fast gleichbleibend bis zum Abschalten gehalten wird
       Ein-/Ausschaltperioden sind relativ konstant und wiederholen sich zyklisch
Zu 2.: Viele elektr. Geräte weisen einen typischen Rechteckverlauf auf. Die Leistungsaufnahme ist über die Einschaltdauer konstant(Konstantverbraucher).
       Die Einschaltdauer beim BM ist in der Regel über einen Einstellmechanismus vordefiniert. Die Leistungsaufnahme über die direkt(oder per FHEM indirekt) angeschlossenen Verbraucher ist konstant. Die Ausschaltdauer ist undefiniert.
      
Wie könnte man das nun technisch in FHEM definieren/realisieren ?
Wir haben heute bereits devices, die über Attributdefinitionen in anderen devices ihre Funktionalität definieren. Mir kommt da als Erstes das Alarmmodul in den Sinn. Hier werden ja auch die funktionsspezifischen Eigenschaften über Attribute in den vorhandenen Sensor-/Aktor-devices definiert.(per UI zentral, aber technisch im jeweiligen device)

Erste Ansätze zu Algorithmen bzw. notwendigen Attributen(oder nur eins, vergleichbar dem Alarmmodul ?)
Zu 1.(Kompressorgeräte): 
- Einschaltzeitpunkt(t0): Anstieg der Leistungsaufnahme um xW  (currentval = oldval + x  <==> x = currentval - oldval)
- Einschaltphase(t1-t0) beendet(t1): Absenkung der Leistungsaufnahme um yW  (y = z% * x ???)
- Aktivphase: relativ konstante Leistung x-y
  (diese Phase ist vergleichbar einem Konstantverbraucher)
- Abschaltung(t2; t2-t1): Leistungsaufnahme sinkt um xW-yW
- Ausschaltperiode t3: "Notfalleigenschaft" um ggfs. ein nicht erkanntes t0 zu übersteuern
 
Zu 2.(Konstantverbraucher primär BM)
- Einschaltzeitpunkt(t0): Anstieg der Leistungsaufnahme um xW  (currentval = oldval + x  <==> x = currentval - oldval)
- Aktivphase: relativ konstante Leistung x
- Abschaltung(t1): Leistungsaufnahme sinkt um xW
- Einschaltdauer Delta t: "Notfalleigenschaft" um ggfs. ein nicht erkanntes t1 zu übersteuern

Unter Idealbedingungen(z.B. nachts) ist die Erkennung noch realtiv einfach. Im normalen Tagesablauf wird die Erkennung durch permanentes An-/Abschalten von Verbrauchern, Nicht-Konstantverbrauchern(z.B. E-Herd, Mikrowelle, Wasch-/Spülmaschine) und Eigenerzeugern erschwert. Und manche Geräte schwanken ja auch mehr oder weniger in ihrer Leistungsaufnahme.
Deshalb bedarf es Filter, die den Verlauf glätten, die Leistungsaufnahme von Nicht-Konstantverbrauchern(in der Regel Leistungsaufnahmen > 0,5 kW) ausfiltern u. Abweichungen von konkret definierten Werten von devices "tolerieren".
Die ersten beiden Filterfunktionen sehe ich in einer zentralen Logik/device. "Toleranzparameter" zu jedem Leistungs- u. Zeitparameter als Attribut in dem jeweiligen device.

Last but not least ist die Performance zu berücksichtigen. Je besser und dann komplizierter eine Lösung wird, um so kritischer wird es für die Performance des Gesamtsystems. Es ist deshalb sicherlich sinnvoll den zentralen Abgleich der Daten per BlockingCall auszulagern. Längerfristig wird eine Lösung dauerhaft ausgelagert werden müssen, also sich Modulen wie Sub- oder CoProcess bedienen müssen.

Ich habe den Thread bewusst im Development-Forum eröffnet, weil es keine Frage von Bedarf u. nice-to-have Funktionalitäten ist, sondern die Problematik in der technischen Umsetzung liegt.

Jegliche Beiträge mit Anregung, Kritik, Ergänzung.... sind willkommen.

@pah:
falls Du den Beitrag liest, bin ich einerseits ganz besonders an Deiner Meinung interessiert, weil ich ja technisch eine Ähnlichkeit zu Deinem Alarm-Modul sehe, aber auch, weil Du immer wieder erwähnst, dass Deine Studenten sich mit FHEM beschäftigen (müssen ?). Wäre das nicht ein Thema für studentische Aktivitäten ? Vielleicht auch vom e.V. finanziell gefördert ?

Grüße Markus

Thorsten Pferdekaemper:
Hi,
ich bin zwar für keines der angesprochenen Themen Experte, finde es aber interessant und werde mal versuchen, etwas beizutragen.


--- Zitat von: KölnSolar am 16 Oktober 2021, 13:47:37 ---1. eigenständige erstmalige Erkennung von bisher unbekannten Mustern(also etwas, was ich als KI bezeichnen würde) aus beliebigen Datenreihen
2. Anwendung eines bekannten/definierten Musters, um dessen erneutes/wiederholtes Auftreten zu erkennen(das ist für mich kein KI, sondern "simple" Datenverarbeitung)

--- Ende Zitat ---
Ich glaube, dass die zurzeit "übliche" KI (also neuronale Netze/ Deep Learning) eher das zweite tut. In dem Fall würde man der KI in der Lernphase ein paar (viele) Stunden der Zeitreihe(n) hinwerfen, bei denen die interessanten Abschnitte markiert sind. Daraus würde die KI dann lernen, interssante Abschnitte zu erkennen. (Also so ungefähr.)
Für die erste Aufgabe müsste man erst einmal eine Zielfunktion definieren, die zu maximieren wäre. D.h. man müsste genauer definieren, was denn ein Muster ist. Mir würde dazu auch das Thema "Fourier-Transformation" einfallen.


--- Zitat ---Das oben unter 1. als "erstmalige Mustererkennung" bezeichnete, sehe ich erst einmal als nicht einfach u. schnell realisierbar an. Die Definition und Anwendung eines Musters halte ich hingegen in der FHEM-Umsetzung für realistisch. Dabei möchte ich mich über 2 beispielhafte Gerätetypen an das Ziel herantasten:
1. Kühl-/Gefrier-/Klimageräte, die aufgrund ihres Kompressors ein außergewöhnliches, typisches Muster erkennen lassen
2. Bewegungsmelder, die etwas schalten, was dann zu einem typischen Rechteckverlauf in den Daten führt

Zu 1.: Die Geräte haben eine typische Leistungsspitze nach dem Einschalten. Relativ schnell sinkt die Leistungsaufnahme ein wenig auf ein Niveau ab, das dann dauerhaft und fast gleichbleibend bis zum Abschalten gehalten wird
       Ein-/Ausschaltperioden sind relativ konstant und wiederholen sich zyklisch

--- Ende Zitat ---
Wenn man das aber nicht direkt am Kühlschrank misst, dann wird es spätestens dann schwierig, wenn man zwei davon hat. Außerdem erzeugen eine ganze Menge andere Verbraucher möglicherweise ähnliche Signale. Auf der anderen Seite müsste es schon möglich sein, das Signal so einzudampfen, dass brauchbare Signaturen dabei herauskommen.
      

--- Zitat ---      
Zu 2.: Viele elektr. Geräte weisen einen typischen Rechteckverlauf auf. Die Leistungsaufnahme ist über die Einschaltdauer       konstant(Konstantverbraucher).
Die Einschaltdauer beim BM ist in der Regel über einen Einstellmechanismus vordefiniert. Die Leistungsaufnahme über die direkt(oder per FHEM indirekt) angeschlossenen Verbraucher ist konstant. Die Ausschaltdauer ist undefiniert.

--- Ende Zitat ---
Aber hier hat man doch definitiv in der Regel mehrere Verbraucher mit einer sehr ähnlichen Signatur, oder?       
      

--- Zitat ---Erste Ansätze zu Algorithmen bzw. notwendigen Attributen(oder nur eins, vergleichbar dem Alarmmodul ?)
Zu 1.(Kompressorgeräte): 
- Einschaltzeitpunkt(t0): Anstieg der Leistungsaufnahme um xW  (currentval = oldval + x  <==> x = currentval - oldval)
- Einschaltphase(t1-t0) beendet(t1): Absenkung der Leistungsaufnahme um yW  (y = z% * x ???)
- Aktivphase: relativ konstante Leistung x-y
  (diese Phase ist vergleichbar einem Konstantverbraucher)
- Abschaltung(t2; t2-t1): Leistungsaufnahme sinkt um xW-yW
- Ausschaltperiode t3: "Notfalleigenschaft" um ggfs. ein nicht erkanntes t0 zu übersteuern
 
Zu 2.(Konstantverbraucher primär BM)
- Einschaltzeitpunkt(t0): Anstieg der Leistungsaufnahme um xW  (currentval = oldval + x  <==> x = currentval - oldval)
- Aktivphase: relativ konstante Leistung x
- Abschaltung(t1): Leistungsaufnahme sinkt um xW
- Einschaltdauer Delta t: "Notfalleigenschaft" um ggfs. ein nicht erkanntes t1 zu übersteuern

--- Ende Zitat ---
Und was passiert, wenn beides zusammen passsiert? ...oder alles zusammen? Z.B. könnte man eine Elektroheizung haben, zwei Kühlschränke und drei Bewegungsmelder. Dazu noch diverse Lampen, Rechner und einen Elektroherd. Dann hätte man sozusagen für jedes einzelne Gerät (bzw. für jeden einzelnen Zustand jedes Geräts) eine eigene Signatur (oder Funktion in der Zeit), der die "normale" Leistung anzeigt. Mit dem Zustand meine ich z.B. dass ein Elektroherd vier Platten hat, die alle unterschiedliche Einstellungen haben können. Außerdem kommt es darauf an, was gerade draufsteht. (Zumindest bei Induktion.) Bei einem Rechner kommt es darauf an, was er gerade macht.
Bei manchen Geräten findet man vielleicht auch so heraus, was sie gerade treiben. In der Regel wissen wir ja z.B. für die meisten Lampen, ob sie an oder aus sind und manche "smarte" Elektrogeräte sagen uns auch, ob sie an oder aus sind. Das könnte man dann schon einmal herausrechnen.

Dann könnte man für jedes Gerät (welches man beobachten will) eine "Signatur-Funktion" bereitstellen (bzw. ermitteln). Wie gesagt müsste das auch etwas mit dem Zustand des Geräts zu zun haben. Zusätzlich dann noch erlaubte Zustands-Übergänge.
Als Beispiel Dein Kühlschrank: Der Kühlschrank hat so wie Du es beschreibst 4 Zustände: Aus, Einschalten, Aktiv, Ausschalten. Jeder dieser Phasen kann man eine Funktion t -> P zuordnen. Für "Aus" ist f(t) = 0. Für "Aktiv" ist f(t) = const. Für "Ausschalten" ist f eine kurze Gerade abwärts. Für Einschalten entsprechend eine längere Gerade aufwärts und dann eine kurze abwärts (oder so).
Zusätzlich gibt es noch weitere Nebenbedingungen, wie die Zustände zusammenhängen.
...und jetzt könnte man die folgende Optimierungsaufgabe lösen: Welche Zustände (z.B. der letzten Stunde) der beobachteten Geräte stimmen am besten mit dem tatsächlichen Leistungsverlauf überein?

Möglicherweise könnte man das ganze auch probabilistisch formulieren. Das würde dann auch bei Unsicherheiten helfen. (So ähnlich wie bei Robitik-Anwendungen, bei denen sich der Roboter auch mit nicht ganz so perfekten Sensordaten in seiner Umwelt zurechtfinden muss.)

Also vielleicht ungefähr so: Man fängt an wie oben, idem man sich überlegt, welches Gerät in welchem Zustand nach welcher Zeitspanne wieviel Leistung verbrauchen müsste. Das formuliert man dann als Verteilung, also nicht absolut. ...und dann macht man eine Art Monte-Carlo-Simulation. Man fängt mit einem zufälligen Zustand an, aber nicht nur einmal, sondern sagen wir mal 10000 mal parallel. (D.h. das System weiß erstmal gar nichts und nimmt so ziemlich jeden Fall als gleich wahrscheinlich an.) Für jeden dieser 10000 Zustandskombinationen berechnet das System dann die erwartete Leistung (oder eher die Verteilungsfunktion der erwarteten Leistung). Dann sortiert man die Zustände nach der Differenz des Ergebnisses zur tatsächlich gemessenen momentanen Leistung. (Bzw. nach der Wahrscheinlichkeit, dass die gemessene Leistung durch den "simulierten" Zustand erzeugt werden kann.) Der Zustand mit der kleinsten Differenz (bzw. der größten Wahrscheinlichkeit) wird dann erst einmal als Wahrheit betrachtet. Natürlich kann man noch verlangen, dass die Wahrscheinlichkeit über einem bestimmten Wert liegt, aber das dürfte zweitrangig sein.
Die Methode mit der Wahrscheinlichkeit ist wahrscheinlich besser. Damit kann man z.B. leicht formulieren, dass unter einer gemessenen Leistung von x Watt der Kühlschrank aus ist. ...wobei man nie eine Wahrscheinlichkeit von 0 oder 1 angeben sollte, da das System dann keine Fehler mehr zulässt.

Soweit wäre das ganze noch nicht besonders schlau. Jetzt kommt aber der nächste Schritt. Wenn die nächste Leistungsmessung reinkommt oder der Rechner wieder Zeit dafür hat (was auch immer später passiert), dann werfen wir erst einmal die schlechtesten 5000 (oder so) simulierten Zustände weg und ersetzen sie durch neue. Diese neuen Zustände werden im Wesentlichen aus den 5000 verbliebenen Zuständen ermittelt. Im Prinzip kann man einfach zufällig Zustände kopieren. Die Verteilung dabei sollte so gewählt sein, dass "wahrscheinlichere" Zustände auch mit größerer Wahrscheinlichkeit kopiert werden. Zusätzlich würfelt man noch ein paar Zustände komplett zufällig dazu.
Jetzt verschiebt man die ganze Simulation (bzw. die 10000 Simulationen) in der Zeit. D.h. man lässt die Zeit fortschreiten und lässt die Geräte die möglichen Statusübergänge durchführen, und zwar wieder (ein bisschen) zufällig. Dabei muss die Verteilung auch wieder vernünftig gewählt sein. Ein Kühlschrank, der gerade noch "Aus" war, wird wahrscheinlich jetzt nicht im Status "Ausschalten" sein. Wenn er allerdings im Status "Aktiv" ist, dann könnte es darauf ankommen, wie lange er schon "Aktiv" war. Komplett ohne Zufall sollte man hier auch nicht vorgehen.

An der Stelle fängt man dann wieder von vorne an. Nach ein paar Zyklen müsste sich das ganze so eingependelt haben, dass es von den wahrscheinlichen Zuständen sehr viele gibt, aber immer auch noch ein paar unwahrscheinliche. Man kann sich das so vorstellen, dass sich um die wahrscheinlicheren Punkte im Lösungsraum mehr (also sehr viele) simulierte Zustände versammeln.   
Den besten simulierten Zustand kann man dann als die Wahrheit interpretieren.

...so oder so ähnlich.

Gruß,
   Thorsten

Thorsten Pferdekaemper:
Hi,
ich glaube, ich habe oben (mindestens) zwei Fehler gemacht:
1. Man wirft nicht die Hälfte der Samples weg, sondern macht ein komplettes Resampling. D.h. man wählt aus allen 10000 zufällig immer wieder eins aus, so dass sich eine Verteilung ergibt, die den ermittelten Werten (Differenzen oder Wahrscheinlichkeiten) entspricht.
2. Es ist nicht das momentan "beste" Sample als Wahrheit zu betrachten, sondern der Zustand, in dessen Nähe sich die meisten Samples versammeln. Sonst kann es dazu kommen, dass ein verrauschtes Signal ganz üble Schwankungen verursacht.
Gruß,
   Thorsten

zap:
Diese Geräteerkennung anhand von Zählerdaten: war das nicht ein Feature, das die neuen "intelligenten" Stromzähler mitbringen sollten? Wie auch immer: ich habe 2 von den Teilen und kann bestätigen, dass sie es NICHT können ;)

Insofern finde ich die Idee sehr gut!

KölnSolar:
Guten Morgen,
danke für Eure Beiträge. Ich antworte mal in mehreren Posts, um das Lesen für Dritte etwas zu vereinfachen bzw. übersichtlicher zu gestalten.

Zuerst noch einmal zur Ausgangssituation und meinem konkreten Interesse, dem Stromzähler (Wobei die Erkennung nicht auf Stromzählerdaten beschränkt sein soll)
--- Zitat ---Diese Geräteerkennung anhand von Zählerdaten: war das nicht ein Feature, das die neuen "intelligenten" Stromzähler mitbringen sollten?
--- Ende Zitat ---
Nicht ganz. Daher hier die Info zu den Möglichkeiten von Stromzählern.

Grundsätzlich wird jeder Netzanschluss zukünftig von den alten schwarzen Ferraris-Stromzählern "befreit" und es wird ein digitaler(Gesetzestext: "moderne Messeinrichtung") Zähler installiert werden. Diese Zähler haben für uns die nette Eigenschaft, dass sie über 2 IR-Schnittstellen Daten liefern. Die hintere ist dem Messstellenbetreiber vorbehalten und für den Kunden (in der Regel) nicht zugänglich. Die Schnittstellen lassen sich über einen IR-Lesekopf, RS485, RS485-USB-Wandler nutzen und die Daten per OBIS-Modul an FHEM übergeben. Je nach Hersteller/Typ liefern die Zähler einen unterschiedlichen Datenumfang. Meiner z.B. leider keine detaillierten Phasendaten an der Kundenschnittstelle(ich bediene mich daher der MSB-Schnittstelle  8) ).
Manche von uns werden mit der jährlich teureren sogenannten "intelligenten Messeinrichtung"(Gesetzestext  ::)) zwangsbeglückt.  :'( Das betrifft ALLE Eigenerzeuger ab einer Nennleistung 7 kWP und Kunden mit hohem Verbrauch(vermutlich z.B. viele "Strom-Heizer"). Die "intelligente Messeinrichtung" ist nichts anderes, als derselbe digitale Zähler, aber zusätzlich mit einem Gateway(interne Kommunikation über die hintere IR-Schnittstelle) ausgestattet, das die Daten permanent an den Messstellenbetreiber übermittelt  :o :'(.

Und nun soll es MSB's, Clouddienstleister, Smart-Home-Anbieter.... geben, die genau das versuchen, was ich hier versuchen möchte: in diesen Daten Muster erkennen und gar aufgrund von typischen Mustern konkrete Verbraucher ausfiltern/identifizieren. Mein MSB bietet es nicht an.(Oder liegt es daran, dass ich ihm nur die weniger detaillierten Daten der Kundenschnittstelle zur Verfügung stelle ?  :-\ 8))

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln