Muster in Zahlenreihen erkennen; Intelligentes FHEM

[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.

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)

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.

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

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.
      

      
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.

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

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

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)

Diese Geräteerkennung anhand von Zählerdaten: war das nicht ein Feature, das die neuen "intelligenten" Stromzähler mitbringen sollten?

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  ).
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  .

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 ?  )

[KölnSolar]

Ich glaube, dass die zurzeit "übliche" KI (also neuronale Netze/ Deep Learning) eher das zweite tut.

Ja, da stimme ich Dir zu, was die allgemeine Definition von KI anbelangt. Nach der allgemeinen Definition ist meines Erachtens bereits jede Software KI. Um das dann deutlicher abzugrenzen, definiere ich für mich KI als etwas, was über event/notify/if_else hinausgeht. 

[KölnSolar]

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.

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

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.

Du hast mit all diesen Aussagen recht. Das macht es natürlich so schwierig. ABER:
- Die Verbraucher sind auf die 3 Phasen aufgeteilt und im Idealfall haben wir Leistungsdaten/Phase. Das vereinfacht die Analyse erheblich.
- Die meisten Verbraucher haben eine fast konstante Leistungsaufnahme oder schalten (fast) periodisch(Herd, Mikrowelle...) eine konstante Leistung
- Die Leistungsaufnahmen(Einschaltpeak) der Verbraucher variieren stark und sind selten (fast) gleich

[KölnSolar]

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).

Selbst das finde ich, neben Deinen weiteren Ausführungen, zu wissenschaftlich und komplex. In meinen Augen ein "Killer", um überhaupt mal das Thema anzugehen.

Anstatt einer "Signatur-Funktion" gibt es daher nur die o.g. "Eckpunkte".

Zwischenzeitlich habe ich meine 3 Phasen noch intensiver analysiert und mir diese "Eckpunkte" zu diversen Geräten dokumentiert. Dabei bin ich zu der Überzeugung gelangt, dass ich einerseits viel mehr Geräte erkennen können müsste, als ursprünglich angenommen, und andererseits, dass der Einschaltpeak das maßgebliche Kriterium für eine Erkennung sein muss, während der weitere Leistungsverlauf lediglich für eine Verifikation bzw. der Erkennung des Abschaltens dienlich ist.

Um meine Anforderung etwas deutlicher zu formulieren:
Im Ergebnis wird je device das obligatorische state = on/off mit timestamp geliefert. Dazu noch einige wenige readings. Ein "counter", der die Häufigkeit des Einschaltens dokumentiert, und vielleicht noch den Verbrauch des letzten Zyklus, sowie ein kumulierter Verbrauch.(als Internals dann noch die Daten, die zum letzten "Ansprechen"(der Erkennung) geführt haben.)
Was nicht gehen wird:
Kleinstverbraucher wie z.B. Smart-Home-Aktoren zu erkennen. Bei Smart-Home-Aktoren "nur" dessen angeschlossene Verbraucher(z.B. nicht Rolladenaktor, aber Rolladenmotor).

Bei einem Rechner kommt es darauf an, was er gerade macht.

Stimmt. Vielleicht bekommt man das aber wenigstens in groben "Stufen" hin, so dass man bei einem solch komplexeren Gerät(dessen Leistungsaufnahme) das allgemeine on-/off, Akku lädt/lädt_nicht, Bildschirm an/aus..... hinbekommt. Aber das würde ich als "Kür" betrachten. 

Und man wird natürlich niemals eine Erkennungsrate von 100% hinbekommen. Aber manchmal reicht einem auch weniger.  Anders ausgedrückt: Besser als nichts. 

[JoWiemann]

Hallo,

es gibt auch schon andere Lösungen:https://watt-analytics.com/de/geraete-erkennung/

Grüße Jörg

PS: Ich habe zu dem Thema auch mal an einem PoC von https://www.bidgely.com/ teilgenommen. Vor 4 Jahren war die Erkennung so lala.

[KölnSolar]

Hi Jörg,
ja, sowas meinte ich mit

Clouddienstleister, Smart-Home-Anbieter....

Interessant sind die Preise: ca. 200 EUR brutto aufwärts. Bei Cloudnutzung monatlich mind. 5 EUR(so mein Verständnis).

Und natürlich, dass selbst die Profis keine Computer, Kleinstverbraucher, Verbraucher mit variablem Verbrauch erkennen können. Wie auch. 

Grüße Markus

[Prof. Dr. Peter Henning]

Also zunächst einmal oute ich mich damit, das Thema schon länger zu verfolgen (diverse Abschlussarbeiten vergeben).

Weiterhin: Ich bin derzeit Mitglied des Kompetenzzentrums "KARL - KI für Arbeiten und Lernen" hier in der Region. Zum Teil hat das damit zu tun, dass ich seit 2012 an regelbasierten KI-Systemen arbeite (nicht alles sind neuronale Netze...), und auch FHEM damit verbunden habe, um meine Sprachsteuerung zu realisieren. Auf Grund der vielfältigen Aktivitäten in KARL kenne ich mich auch auf den anderen Gebieten der KI inzwischen ganz gut aus.

Jetzt zum Thema: Neuronale Netze sind sehr gut geeignet, um solche Muster zu erkennen. Beispielsweise gab es bei uns vor etlichen Jahren schon ein Projekt, um die Qualität von Punktschweißvorgängen an der Stromverbrauchskurve während des Schweißens zu erkennen.

Das wesentliche ABER: Dazu muss das Muster komplett vorliegen - Teilmuster reichen eben nicht aus. Beispiel ist der Wasserverbrauch, über den Tag in 1l-Genauigkeit gemessen. Trainiere ich das Netz mit dem Gesamtmuster eines Tages, kann ich sehr schöne Aussagen treffen. Etwas: "Niemand zu Hause", "Alles OK". Oder, über ein paar Stunden gemessen: "Person X hat gerade geduscht". Ich kann also nicht mit Zeitreihen arbeiten. Eine Bachelor-Arbeit hat als tolles Resultat erbracht, dass mit höchster Wahrscheinlichkeit der nächste Messwert einer solchen Zeitreihe immer "Null" ist...

Als Beispiel die heutige Wasserverbrauchskurve (inklusive des gleitenden Mittelwertes). Um 8:30 haben 2 Personen geduscht, soeben ist eine Waschmaschine durchgelaufen.

Der Wasserverbrauch wird auch mit einem THRESHOLD überwacht, seit meine schon sehr alte Mutter einmal einen Wasserhahn laufen ließ, bevor wir für einige Stunden aus dem Haus gingen...

LG

pah

[KölnSolar]

Interessant.

Also zunächst einmal oute ich mich damit, das Thema schon länger zu verfolgen (diverse Abschlussarbeiten vergeben).

Das wesentliche ABER: Dazu muss das Muster komplett vorliegen - Teilmuster reichen eben nicht aus.

Genauso hatte ich mir das gedacht. Daher auch mein Gedanke, dass das etwas für "Deine Studenten" sein könnte u. ggfs. durch den e.V. gefördert werden könnte. Was meinst Du dazu ?

Was ich in der angedachten "Einfachlösung" anstrebe, ist natürlich etwas anderes. Da sollte es (nach meinen bisherigen Analysen bei mir) genügen die Einschaltleistung u. ggfs. den besonderen Verlauf(wie bei Kompressoren) zu betrachten.

Meinst Du, dass ein ähnlicher struktureller Aufbau wie bei Deinem Alarm-Modul Sinn machen würde ?

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 ?)

Und ich meinte natürlich zur Pflege eine "spezielle" Benutzeroberfläche vergleichbar dem Alarm-Modul.

Grüße
Markus

[optimizer]

Hi,
interessantes Thema. Das hätte ich mir auch schon lange gewünscht. Bin immer noch am überlegen, ob ich noch einige Stromzähler (Sicherungen mit integriertem Zähler habe ich noch nicht gefunden) in der Verteilung installiere - eine Softwarelösung hätte mehr Charm.
Auch wenn man nur die Grundlastgeräte erkennt und am Ende des Tages einzeln den Verbrauch aufschlüsselt wäre schon ein Erfolg.

Zur Zeit messe ich alle 2 Minuten - auch hier sind kleine Lastspitzen (Kühl-/Gefrierschrank) in der Nacht gut erkennbar. Bei sekundengenauer/phasengenauer Messung müsste die Signatur eindeutig erkennbar sein.
Das "Einlernen" müsste idealerweise pro Gerät stattfinden - ein Gerät nach dem anderen anstecken und ein Profil dazu abspeichern. Eine Gerätedatenbank mit Profilen wäre ideal. Gibt es eine Idee wie so ein auswertbares Profil aussieht?

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!

Hier gibts eine Demo eines MSB mit zuschaltbarer Geräteerkennung: https://my.discovergy.com/dashboard?0
Ob der Code auch unter OpenEMS veröffentlicht wird?

Gruß
optimizer