[fhem-rnn] Neuronale Netzwerke zu Steuerung und Analyse

Begonnen von Pythonf, 16 Januar 2019, 14:51:18

Vorheriges Thema - Nächstes Thema

Pythonf

Hallo FHEM-Freunde,

ich hab mich in letzter Zeit etwas mit neuronalen Netzwerken auseinander gesetzt und dabei in Python ein Programm geschrieben, welches es erlaubt, das FHEM-LOG zu analysieren und darauf aufbauend Handlungen vorherzusagen. Es handelt sich aktuell um Python-Programm, welches fhem über telnet ansteuern kann. Im Vordergrund steht zur Zeit aber die Analyse der Daten und die Optimierung für konkrete Anwendungsfälle. Es handelt sich um ein noch nicht im Zusammenhang mit FHEM sinnvoll einsetzbares Programm

Was bisher funktioniert:
Die Daten werden über eine SQL Datenbank MariaDB (sqlite wird zukünftig ergänzt) ausglesen, entsprechend umstrukturiert und mit einem LSTM (Long Short Term Memory) Netzwerk ausgewertet.
Die zu analysierenden Daten können nach Device und Reading sortiert werden, es wird dabei unterschieden zwischen:

  • Steuerbaren Geräten wie Lampen mit großteils binären Eingaben (on, off)
  • Aktiven Sensoren, wie beispielsweise Bewegungsmelder, welche ebenfalls binäre Ausgaben liefern (open, closed)
  • Passiven Sensoren mit numerischen Daten (Licht, Temperatur)
Ausgegeben wird jeweils das am nächsten vermutete, zu schaltende Device mit dem entsprechenden Reading sowie dem State. Eine Ausgabe von mehr als einem zukünftigen Wert wird zeitnah implementiert.

Anwendungsszenarien
Neben dem aktuellen Hype um Neuronale Netzwerke (NN, verwirrend auch häufig mit Künstliche Intelligenz bezeichnet/verwechselt) bieten sich für die Zukunft hierbei einige interessante Anwendungsszenarien:

  • Realistische Anwesenheitssimulation auf Basis echter Personenbewegungen
  • Sicherheitsanalyse durch Abweichungen von NN-Vorhersagen
  • Einfachere Automation ohne Programmierkenntnisse durch Anpassung an die Gewohnheiten der Nutzer

TO-DO
Das bisherige Programm stellt lediglich eine Grundlage und Ausgangsbasis für weiter Analysen zur Verfügung. Die folgenden Punkte dienen als Anreiz zur Diskussion und Implementierung von Funktionen:

  • Bessere Analyse und Testung an mehreren Datenbanken
  • Implementierung weitere sinnvoller Daten, wie Zeitstempel, Wetterdaten, über die oben vorgestellten Daten hinausgehenden Datenstrukturen
  • Analyse von Zeitdifferenzen zur Vorhersage, wann eine Aktion vorraussichtlich eintreten wird
  • Auswertung von regressiven Größen wie das dimmen von Lampen oder die Temperatursteuerung von Heizungen

Ziel dieses Thema und mein damit verbundener Wunsch ist eine offene Diskussion über Neuronale Netzwerke im Zusammenhang mit  smartHome Steuerungen.
Bisher gibt es nur wenige Ansätze die Steuerung mit NN zu erweitern und die Möglichkeit dies ohne einen Cloud-Anbieter direkt in FHEM umzusetzen finde ich sehr reizvoll.
Neben den Anwendungsszenarien ist sicherlich die Sinnhaftigkeit dieses Projektes zum aktuellen Zeitpunkt nur schwer absehbar. Eine Ideensammlung an möglichen Szenarien stellt aber eine gute Ausgangsbasis dar, was auch der Grund war, weshalb ich diese sehr frühe Version veröffentlicht habe.
Ich freue mich auch, über inhaltliche Änderungs- und Ergänzungsvorschläge am Programm. Ich habe keinerlei berufliche oder hochschultechnische  Ausbildung zum Programmieren und kann deshalb nicht ausschließen, dass mir der ein oder andere faux pas unterlaufen ist.

https://github.com/PythonFZ/fhem-rnn

~Fabian

Thorsten Pferdekaemper

Hi,
ich hab's mir nicht im Einzelnen betrachtet, aber ich hatte auch mal so eine Idee. Es geht dabei um die Steuerung der Heizungsventile und der Vorlauftemperatur. Ich habe das einigermaßen im Griff, aber manchmal könnte es noch besser gehen. Hier könnte man vielleicht auch alle möglichen Parameter hernehmen (Außentemperatur/-Verlauf, Wetterbericht, An-/Abwesenheit(-svorhersage), Fenster-/Türsensoren, Raumtemperaturverlauf (in allen Räumen) etc.) und daraus dann Ventilstellungen sowie gewünschte Vorlauftemperatur berechnen. Ich kam dann auf "Reinforcement Learning", da man ja keine klassische Vorhersage trifft. Möglicherweise würde man das auch schon mit einem einfacheren Q-Algorithmus hinbekommen.
...aber dann hat mich FUIP etwas stärker beschäftigt und ich habe das bleiben lassen.

Wenn man sich Literatur zu den NNs betrachtet, dann kann ich mir vorstellen, dass es allgemein relativ lange dauert, bis ein NN mit den Daten einer einzelnen FHEM-Instanz etwas brauchbares lernt. Ich meine damit, dass man ggf. ein paar Jahre Daten sammeln muss. Vielleicht müsste man dazu mal Daten verschiedener Installationen sammeln und das Netz damit vortrainieren.
Außerdem bin ich mir nicht so sicher, ob die übliche schwache Hardware (RasPi etc.) da nicht etwas überfordert ist. Möglicherweise muss man die Trainigsphase auf etwas schnellerem machen und das ganze dann in FHEM nur "benutzen".

Gru,
   Thorsten

FUIP

Wernieman

Dazu muß man aber eine config-db  und/oder logging-DB laufen haben?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Pythonf

#3
Zitat von: Thorsten Pferdekaemper am 16 Januar 2019, 15:13:03
Möglicherweise muss man die Trainigsphase auf etwas schnellerem machen und das ganze dann in FHEM nur "benutzen".

Da gebe ich dir recht, das Training dauert auf einem Raspberry Pi deutlich zu lange, wenn das Modell aber trainiert ist, dann funktioniert die Auswertung aber von der Geschwindigkeit her auch auf schwächerer Hardware. Ich werde mich mal mit den von dir vorgeschlagenen Algorithmen auseinander setzten.

Zitat von: Wernieman am 16 Januar 2019, 15:27:35
Dazu muß man aber eine config-db  und/oder logging-DB laufen haben?
Das ist richtig, Filelog wird aktuell nicht unterstützt und von meiner Seite aus ist auch keine Implementierung geplant.

Zitat von: Thorsten Pferdekaemper am 16 Januar 2019, 15:13:03
Wenn man sich Literatur zu den NNs betrachtet, dann kann ich mir vorstellen, dass es allgemein relativ lange dauert, bis ein NN mit den Daten einer einzelnen FHEM-Instanz etwas brauchbares lernt. Ich meine damit, dass man ggf. ein paar Jahre Daten sammeln muss.
Die Erwartung hatte ich auch, aber ich konnte feststellen, dass schon mit den Daten weniger Wochen am Beispiel der Lichtsteuerung vernünftige Werte ermittelt werden konnten.
Im konkreten ist bei mir Lichtsteuerung von der Umgebungshelligkeit abhängig und das Netzwerk hat gelernt, dass wenn es hell ist, es das Licht nicht einschalten soll. Aktuell handelt es sich vor allem um die Rekonstruktion bereits geschriebener notifys aber ich konnte auch feststellen, dass es wiederkehrendes Verhalten, wie beispielsweise wenn das Licht im Flur angeht, dann steigt die Wahrscheinlichkeit, dass auch das Licht in der Küche angeht erlernt hat. Meine aktuellen Daten umfassen ca. 4 Monate. Problematisch ist allerdings, dass die Devices vorausgewählt werden müssen und es sicherlich in anderen Haushalten zu ganz unterschiedlichen Erfolgen kommen kann.

Alcamar

NN bieten sich dort an, wo Nichtlineare Zusammenhänge gelten (vermutet) werden. Das scheint mir im Bereich der Hausautomation eher nicht der Fall zu sein. Um Zusammenhänge zu lernen, bedarf es geeigneter, relevanter Input-Daten, die über einen größeren Zeitraum vorliegen sollten. Man kann ein NN natürlich auch mit den Lottozahlen füttern, und es wird einen Zusammenhang zum Licht im Garten lernen. Die Frage ist, wie stabil das gelernte Wissen ist, wenn die Lichtverhältnisse geringfügig anders sind, als das bisher gelernte. Lernen dauert sehr lange. Auch das spricht gegen NN auf Rechnemaschinen wie RasPi & Co.
Die Idee finde ich ganz nett, aber mehr nicht. Ich habe mit NN ein wenig in anderen Bereichen experimentiert, wäre aber nie auf den Gedanken gekommen, sowas in fhem für Steuerung oder Analyse zu nutzen. :-)

Thorsten Pferdekaemper

Zitat von: Alcamar am 22 Januar 2019, 09:04:03NN bieten sich dort an, wo Nichtlineare Zusammenhänge gelten (vermutet) werden. Das scheint mir im Bereich der Hausautomation eher nicht der Fall zu sein.
Hast Du mal ein Beispiel eines linearen Zusammenhangs in der Hausautomation? Ich habe keinen gefunden, aber eine ganze Menge nichtlineare.
Zum Beispiel alles, was mit Heizung zu tun hat ist irgendwie exponentiell und "limitiert". Irgendwann ist das Ventil voll offen oder der Kessel auf 100%. Auf der anderen Seite schaltet man alles ab, wenn es warm genug ist. Eine negative Ventilöffnung gibt es nicht. Zwischen 0% und 100% ist das auch nicht linear, denke ich. (Vor Allem: Linear abhängig von was genau?)
Lichter schalten und Rollläden steuern kann auch nicht wirklich linear abhängig von irgendwas sein. Normalerweise hat man eher eine 0/1-Entscheidung. Das ist im Prinzip eine typische Klassifizierungsaufgabe, also schon was für NNs.
Ein Fenster-/Türkontakt liefert einen binären Wert. Hier könnte man ggf. einen trivialen linearen Zusammenhang konstruieren (Ventilstellung = ("Tür zu") * 100%), aber das wäre auch nicht wirklich sinnvoll, da man noch andere Parameter für die Ventilstellung hat.
...also ich glaube, in meiner Installation gibt's keinen linearen Zusammenhang.

Zitat
Um Zusammenhänge zu lernen, bedarf es geeigneter, relevanter Input-Daten, die über einen größeren Zeitraum vorliegen sollten.
Das meinte ich auch. Mit einer einzigen FHEM-Installation kommt man da nicht weit. Wenn wir aber die Daten von fast allem Installationen hernehmen, dann könnte man damit die NNs vortrainieren und nur den individuellen Teil in der jeweiligen Installation selbst. So etwas macht man auch bei Gesichtserkennung, soweit ich weiß. Man nimmt ein NN her, in dem zumindest die unteren Schichten mit vielen Gesichtern vortrainiert sind und bringt dem dann noch seine eigenen Freunde und Bekannte bei.

ZitatMan kann ein NN natürlich auch mit den Lottozahlen füttern, und es wird einen Zusammenhang zum Licht im Garten lernen.
Da gebe ich Dir vollkommen Recht. Genau wie ein Mensch auch: An einem bewölkten Himmel erkennt man ja auch so einiges, was es dort definitiv nicht gibt.
Deshalb gibt es die Unterteilung in Trainings-, Validierungs- und Testdatenmenge. Klar, das Netz wird auch blödsinnige Zusammenhänge lernen. Die Validierungs-Zyklen werden dann aber etwas seltsam aussehen und spätestens, wenn man die Testdatenmenge auf das NN loslässt sollte man erkennen, dass es so nicht geht. Außerdem würde man das NN nur auf solche Daten loslassen, bei denen wir schon Zusammenhänge vermuten oder zumindest nicht vollständig ausschließen.

Gruß,
   Thorsten
FUIP

Alcamar

Großes Thema 8)
Natürlich ist Wetter alles andere als linear. Aber die relevanten Steuerimpulse bzw. Entscheidungen für eine Aktion sind meines Erachtens alle "linear". Dazu würde ich auch Null/Eins zählen. Wenn ein Schwellwert (oder ein Event) erreicht wird, dann wird immer geschaltet. Dafür würde mir der Einsatz von NN nicht spontan einfallen.
Du wirst in einem Raum einen Termometer haben, und das löst am Ende aus, ob die Heizung aufdreht oder nicht. Ein NN würde ich nutzen, wenn in dem Raum n Thermometer (inkl. Feuchtigkeitsmessung, etc.) sind und so fein messen, dass ein NN lernt bei welcher Thermometerkonstellation die Heizung tatsächlich schaltet. Das wird eine Großlaborsituation sein, aber eben eine in der ich NN mir vorstellen kann. Interessant natürlich auch die Fragen nach "Lehrer", Lern-Pattern und was man so alles braucht. Wie sinnvoll das ist... Es ist ja auch manchmal spannend sich theoretisch mit Dingen zu beschäftigen.  ;)
ZitatDeshalb gibt es die Unterteilung in Trainings-, Validierungs- und Testdatenmenge.
Wenn die Trainingsmenge zu klein, oder nicht geeignet ist, wirst Du u.U. ein NN finden, der Validierungs- und Testmengen optimal abbildet, aber in der Realität keine große Güte besitzt.
Letzlich hat man es mit einer Polynomfunktion zu tun mit der ich einen Zusammenhang hinreichend gut beschrieben kann. Je genauer ich werde, desto unbrauchbarer wird meine Funktion für andere Problemfälle. Man braucht also eine gewisse "Unschärfe" und das bekommen NN auch sehr gut hin (Beispiel Gesichtserkennung). Aber gerade diese Unschärfe lässt mich nicht spontan an NN denken, wenn ich deterministische Schaltungen ausführen will.  :)
Wie auch immer, ist das durchaus ein Thema mit dem man sich beschäftigen kann. Wenn ich die Wahl zwischen FUIP und NN hätte, dann wäre meine Entscheidung sehr einfach.  ;)

Pythonf

Sehr spannend, welche Meinungen hier vertreten werden. Viele Vorgänge im smartHome würde ich durchaus als binär Bezeichnen, die Zusammenhänge dagegen nur teilweise als linear. Mit einem einfachen Klassifizierungsmodell würde sich ein Licht durchaus einem Bewegungsmelder zuordnen lassen, nehmen wir aber noch die Helligkeit, die Anzahl der anwesenden Personen, die Uhrzeit, den Wochentag sowie die vorangegangen Ereignisse dazu, dann würde ich nicht mehr von einem einfachen linearen Modell sprechen.
Ich möchte an dieser Stelle auf die Thematik der Datenmenge eingehen, ich hatte beispielsweise das Problem, dass die Genauigkeit meines Netzwerkes rapide gesunken ist, da die Außentemperatur der Validierungsdaten von denen der Trainingsdaten deutlich abwich.  Solche Probleme werden in einem NN vermutlich häufiger auftreten und man müsste hier bereits bei der Wahl der Trainingsdaten eine eventuelle Klassifizierung einsetzten, aktuell ist das aber ein sehr spezielles, wenn auch wichtiges Problem.
Auch muss man zur Zeit und auch für spätere Modelle stets zwischen langsamen Änderungen wie z.B. der Temperatur und konkreten und schnellen Änderungen, wie dem Licht unterscheiden.
Ein bereits jetzt theoretisch umsetzbares Szenario wäre die helligkeitsabhängige Steuerung der Beleuchtung, ohne das ein konkreter Schwellenwert angegeben werden muss. Das Netzwerk ist - meiner Erfahrung nach - schon mit wenigen Tagen/Wochen an Hand des Nutzerverhaltens zu entscheiden, ob er das Licht bei aktivem Bewegungsmelder gerne an oder aus hätte!

Darüber hinaus ist noch wichtig, dass es sich um ein LSTM-NN handelt, dass heißt es wird aufbauend auf Handlungsabläufen entschieden. Dies finde ich gerade in einem smartHome-Szenario durchaus interessant und lässt sich mit anderen Modellen meines Wissens nach nicht so einfach umsetzten.
Eine Sammlung von Trainingsdaten wäre ebenfalls sehr spannend, technisch und vom Datenschutz her aber vermutlich anspruchsvoll.

Lg
Fabian

P.s. Mein Tipp für die Lottozahlen 1, 11, 22, 33, 44, 49 und die 7 (Wahrscheinlichkeit 98.7834 %)

Alcamar


Thorsten Pferdekaemper

Zitat von: Alcamar am 22 Januar 2019, 10:39:38Natürlich ist Wetter alles andere als linear. Aber die relevanten Steuerimpulse bzw. Entscheidungen für eine Aktion sind meines Erachtens alle "linear".
Gib mir mal ein einziges Beispiel dafür.

ZitatDazu würde ich auch Null/Eins zählen.
Ok, Du kannst natürlich Begriffe irgendwie umdefinieren, aber dann wird die Kommunikation eher schwierig. "Null/Eins" sind zwei Zahlen oder meinetwegen auch Wahrheitswerte. Die können per se erst einmal nicht linear, exponentiell, polynomial oder sonstwas sein. "Linear" ist ein Begriff, der sich auf Funktionen bezieht. (Oder auch auf den Zusammenhang zwischen zwei Parametern, was aber im Endeffekt dasselbe ist.) Eine Funktion ist linear, wenn man sie in der Form "x -> a*x + b" schreiben kann, wobei a und b konstant sind. Dabei ist egal, ob x, a und b Zahlen sind, Vektoren oder Matrizen oder sonst irgendwas, was man addieren und multiplizieren kann. "Null/Eins" ist einfach die falsche begriffliche Kategorie, um das Adjektiv "linear" darauf anzuwenden.

ZitatWenn ein Schwellwert (oder ein Event) erreicht wird, dann wird immer geschaltet.
Das z.B. kann man als eine Funktion interpretieren: "x -> 0, falls x < a; sonst 1". Das ist aber alles andere als linear. Z.B. müsste bei einem kontinuierlichen x (wie z.B. einer Temperatur) und einer linearen Funktion, auch das Ergebnis ein Kontinuum sein. Das ist hier aber nicht der Fall. 

ZitatDafür würde mir der Einsatz von NN nicht spontan einfallen.
Du wirst in einem Raum einen Termometer haben, und das löst am Ende aus, ob die Heizung aufdreht oder nicht. Ein NN würde ich nutzen, wenn in dem Raum n Thermometer (inkl. Feuchtigkeitsmessung, etc.) sind und so fein messen, dass ein NN lernt bei welcher Thermometerkonstellation die Heizung tatsächlich schaltet. Das wird eine Großlaborsituation sein, aber eben eine in der ich NN mir vorstellen kann.
Klar, wenn man einfach einen Zwei- oder Dreipunkt-Regler haben will, dann braucht man kein NN. Allerdings ist schon eine "einfache" Heizungssteuerung komplexer. Wenn ich mir überlege, von was der optimale Ventilöffnungsgrad abhängt (oder abhängen könnte), dann fallen mir spontan ein: Vorlauftemperatur (inklusive Vorhersage), bisheriger Temperaturverlauf (nicht nur die aktuelle Temperatur), Außentemperatur (inklusive Verlauf und Vorhersage), Wind, Sonneneinstrahlung (inklusive Vorhersage), Luftfeuchtigkeit, Solltemperatur (inklusive Vorhersage), Anzahl Personen im Raum, Fenster-/Türöffnung, der Zustand anderer (benachbarter) Räume etc. Dazu kommt dann noch, dass man ja nicht nur die optimalen Ventilöffnungsgrade bestimmen möchte, sondern auch die optimale Vorlauftemperatur (oder ob man den Brenner jetzt gerade einschalten möchte oder nicht).
...und bestimmt habe ich noch einiges vergessen.

ZitatWie sinnvoll das ist... Es ist ja auch manchmal spannend sich theoretisch mit Dingen zu beschäftigen.  ;)
Genau das machen wir hier im Moment. Inwiefern das praktisch notwendig oder sinnvoll ist? Keine Ahnung, aber ich habe mir manchmal schon ein etwas intelligenteres Regelverhalten gewünscht.

ZitatWenn die Trainingsmenge zu klein, oder nicht geeignet ist, wirst Du u.U. ein NN finden, der Validierungs- und Testmengen optimal abbildet, aber in der Realität keine große Güte besitzt.
Klar, wenn man es falsch macht, dann macht man es falsch... Das ist aber unabhängig von der Methode so. Man kann auch einen PID-Regler dazu bringen, kompletten Müll zu fabrizieren.

ZitatLetzlich hat man es mit einer Polynomfunktion zu tun mit der ich einen Zusammenhang hinreichend gut beschrieben kann.
Wieso denn Polynom? Ich hatte bisher den Eindruck, dass ein NN ein bisschen allgemeiner ist. (...oder meinst Du jetzt die Hausautomation?) Für NNs braucht man halt etwas "einigermaßen" differenzierbares, sonst klappt das Gradientenabstiegsverfahren nicht so richtig. ...aber Polynom? Das glaube ich im Allgemeinen nicht. 

ZitatJe genauer ich werde, desto unbrauchbarer wird meine Funktion für andere Problemfälle. Man braucht also eine gewisse "Unschärfe" und das bekommen NN auch sehr gut hin (Beispiel Gesichtserkennung). Aber gerade diese Unschärfe lässt mich nicht spontan an NN denken, wenn ich deterministische Schaltungen ausführen will.  :)
Du sprichst hier vermutlich von Überanpassung. Dafür gibt es ja gerade die Sache mit Training/Validierung/Test. Außerdem merkt man das später recht schnell.
Bei der Sache mit den "deterministischen Schaltungen" stimme ich voll zu. Wenn ich auf einen Taster drücke, dann will ich, dass das Licht angeht. Da brauche ich kein NN, welches unter Umständen auf Basis der Lottozahlen entscheidet. Aber z.B. für Heizungsregelung oder Anwesenheitssimulation halte ich es für interessant.

ZitatWie auch immer, ist das durchaus ein Thema mit dem man sich beschäftigen kann. Wenn ich die Wahl zwischen FUIP und NN hätte, dann wäre meine Entscheidung sehr einfach.  ;)
Für mich ist NN auch eher ein Laber-Thema. Praktische Erfahrung habe ich dazu fast Null.

Zitat von: Pythonf am 22 Januar 2019, 18:16:24Viele Vorgänge im smartHome würde ich durchaus als binär Bezeichnen, die Zusammenhänge dagegen nur teilweise als linear.
Hä? "Binär" und "Linear" schließt sich meiner Auffassung nach fast immer aus.

ZitatIch möchte an dieser Stelle auf die Thematik der Datenmenge eingehen, ich hatte beispielsweise das Problem, dass die Genauigkeit meines Netzwerkes rapide gesunken ist, da die Außentemperatur der Validierungsdaten von denen der Trainingsdaten deutlich abwich.  Solche Probleme werden in einem NN vermutlich häufiger auftreten und man müsste hier bereits bei der Wahl der Trainingsdaten eine eventuelle Klassifizierung einsetzten, aktuell ist das aber ein sehr spezielles, wenn auch wichtiges Problem.
Also eigentlich ist das kein spezielles Problem. Es ist beim Training von NN wichtig, dass sich die Trainings- und Validierungsdaten zwar unterscheiden, aber eine ähnliche Struktur haben. Am besten, man teilt das ganze zufällig auf. Ein (intelligenter) Mensch kann die Grenzen der gelernten Regeln kennen, aber ein NN hat damit heutzutage noch Probleme. Anders gesagt: NNs mögen keine Überraschungen.

ZitatDarüber hinaus ist noch wichtig, dass es sich um ein LSTM-NN handelt, dass heißt es wird aufbauend auf Handlungsabläufen entschieden. Dies finde ich gerade in einem smartHome-Szenario durchaus interessant und lässt sich mit anderen Modellen meines Wissens nach nicht so einfach umsetzten.
Das mit den LSTMs habe ich noch nicht so ganz durchblickt. Hast Du dazu irgendwo eine gute Erklärung?

ZitatEine Sammlung von Trainingsdaten wäre ebenfalls sehr spannend, technisch und vom Datenschutz her aber vermutlich anspruchsvoll.
Naja, es muss ja keiner sagen, wo sie herkommen. Ich kann mir schon vorstellen, dass es einige Forums-Benutzer gibt, die damit herausrücken würden.

Gruß,
   Thorsten
FUIP

Pythonf

ZitatDas mit den LSTMs habe ich noch nicht so ganz durchblickt. Hast Du dazu irgendwo eine gute Erklärung?

Ein "normales" NN hat als Input einen Vektor aus n Werten (bsp. aktueller IST-Zustand) und als Ziel ebenfalls einen Vektor aus m Werten, der im Falle der Sigmoid-Funktion in Summe 1 ergibt.
Bei einem LSTM haben wir als Input eine Matrix aus k*n Werten, wobei n grob gesagt den Zustand zum Zeitpunkt k angibt. Der Zielvektor ist dabei ebenfalls ein m-dimensionaler Vektor aus dem gewünschten Folgezustand. Es wird also anstatt eines einfachen Zustandes eine Abfolge übergeben.
Ein gutes Beispiel aus dem Alltag ist die Autovervollständigung, hier wird nicht nur das vorherige Wort, sondern mehrere vorangegangen Wörter übergeben:

Dein Essen [war] [gut]
Lass uns Essen [gehen]

Das Modell kann somit aus dem Kontext der vorangegangenen Ereignisse die Wahrscheinlichkeiten besser berechnen.

curt

Zitat von: Pythonf am 16 Januar 2019, 15:47:55
Das ist richtig, Filelog wird aktuell nicht unterstützt und von meiner Seite aus ist auch keine Implementierung geplant.

Das ist schon mal sehr schade. Würde ein Kasten Bier Dich umstimmen können?

Darf ich bitte grundsätzliche Verständnisfragen stellen?
Also ich habe (nachdem ich vor 30 Jahren mein Diplom zum Thema KI erwarb) immer einen großen Bogen um KI, NN (und Datenbanken) gemacht - das zu meinem Wissensstand.

Sind denn neuronale Netze immer noch als "viele Server" definiert? Sprich: Habe ich dann viele kleine RPi zusätzlich? Oder sind NN neuerdings nur noch ein Konzept, was auf EINER Maschine läuft?

Um hier mitzutun - da muss man dann Python auch können?

Eine Anmerkung zu linear/nichtlinear:
Ich habe einige Semester Thermodynamik, Strömungslehre und Automatisierungstechnik schlafend verbracht. In den wenigen wachen Momenten:

Also wenn wir hier mehr als zwei analoge Eingangsgrößen haben, wird es schnell komplex und tendiert zu nichtlinear. Das ist mal der erste Punkt.

Und alles was mit Wärme und Wasser zu tun hat - auch nichtlinear. Gleiches gilt für Strömungen von Flüssigleiten oder Gasen, aber gut: Da wollen wir wohl nicht hin.

Abschließend möchte ich ganz vorsichtig erwähnen, dass wir da relativ schnell die Vokabeln Steuerung und Regelung einführen müssen. Und dann sehr genau schauen, ob da real eine Steuerung oder eine Regelung vorliegt.

Ja, das Projekt klingt auf den ersten Blick schon spannend.
RPI 4 - Jeelink HomeMatic Z-Wave

Thorsten Pferdekaemper

Zitat von: Pythonf am 22 Januar 2019, 22:40:55
Bei einem LSTM haben wir als Input eine Matrix aus k*n Werten, wobei n grob gesagt den Zustand zum Zeitpunkt k angibt. Der Zielvektor ist dabei ebenfalls ein m-dimensionaler Vektor aus dem gewünschten Folgezustand. Es wird also anstatt eines einfachen Zustandes eine Abfolge übergeben.
[...]
Das Modell kann somit aus dem Kontext der vorangegangenen Ereignisse die Wahrscheinlichkeiten besser berechnen.
Ok, danke für die Zusammenfassung. Ich habe jetzt auch nochmal nachgelesen und vielleicht besser verstanden.
Allerdings lernt das NN damit nicht unbedingt "sinnvolle" Handlungen, sondern halt nur "wahrscheinliche" Handlungen. Interessanter (oder auch interessant) fände ich, wenn das System aus einer Zielfunktion und den möglichen Handlungen selbst lernt, was im Moment die beste Handlungsalternative ist. Daher die Sache mit dem Reinforcement Learning.

Zitat von: curt am 23 Januar 2019, 00:45:31
Also ich habe (nachdem ich vor 30 Jahren mein Diplom zum Thema KI erwarb) immer einen großen Bogen um KI, NN (und Datenbanken) gemacht - das zu meinem Wissensstand.
Vor 30 Jahren war die Hardware einfach zu schwach, um NNs auch außerhalb einer Uni interessant zu machen. Damals (Anfang der 90er) meinte man mit "KI" wohl eher noch Expertensysteme und deduktive Datenbanken. 

ZitatSind denn neuronale Netze immer noch als "viele Server" definiert? Sprich: Habe ich dann viele kleine RPi zusätzlich? Oder sind NN neuerdings nur noch ein Konzept, was auf EINER Maschine läuft?
Man muss hier stark unterscheiden zwischen der Trainingsphase und dem "benutzen" des trainierten Netzes. Letzteres kann durchaus auf einem Pi laufen (wie schon hier gesagt). Um ein (ernst zu nehmendes) Netz zu trainieren braucht man aber schon etwas mehr Kick. Ich konnte auf meinem i7-Notebook zumindest mal ein paar Versuche machen, aber schon so eine Maschine war Anfang der 90er total utopisch, glaube ich. Ansonsten läuft das Training von NNs "professionell" heutzutage meistens auf Grafikkarten. Die Dinger arbeiten massiv parallel, was beim Training sehr nützlich ist. Ich glaube, es gibt inzwischen sogar Grafikkarten, an die man gar keinen Monitor anschließen kann.

ZitatUm hier mitzutun - da muss man dann Python auch können?
Ich "befürchte" es fast. In dem Bereich ist Python ziemlich verbreitet. Siehe Keras und TensorFlow.

Zitat
Also wenn wir hier mehr als zwei analoge Eingangsgrößen haben, wird es schnell komplex und tendiert zu nichtlinear. Das ist mal der erste Punkt.
Meiner Meinung nach entsteht die Komplexität hier eher dadurch, dass man eben keine (oder wenige) analogen Eingangsgrößen hat. Ein digitaler Parameter irgendwo und das ganze ist nicht mehr differenzierbar (nicht einmal mehr stetig). Deshalb wird das bei NNs mit Sigmoids oder Tanh angenähert. ...was aber auch nicht gerade linear ist.

Zitat
Abschließend möchte ich ganz vorsichtig erwähnen, dass wir da relativ schnell die Vokabeln Steuerung und Regelung einführen müssen. Und dann sehr genau schauen, ob da real eine Steuerung oder eine Regelung vorliegt.
Kann es sein, dass das in eine ähnliche Richtung geht, wie ich am Anfang dieses Posts angedeutet habe? Bei einer Steuerung kann man höchstens die nächste wahrscheinliche Aktion vorhersehen, während bei einer Regelung das Netz selbständig lernen kann (zumindest theoretisch).

Gruß,
   Thorsten
FUIP

Alcamar

#13
ZitatBegriffe irgendwie umdefinieren, aber dann wird die Kommunikation eher schwierig
Sorry, war nicht meine Absicht. Die Kommunikation im Thread ist schon schwierig genug.

ZitatGib mir mal ein einziges Beispiel dafür
Meine (einfache) Welt in einem Beispiel:
Ich sitze abends im Sommer auf der Terrasse und will bei bestimmten Lichtverhältnissen und Bedingungen eine adäquate Beleuchtung haben.
Inputparameter:

  • Die Funktion Sonnenlicht ist stetig (in meiner Welt auch als lineare Funktion hinreichend beschrieben, obwohl das nicht für den gesamten Verlauf der Funktion gilt).
  • Bewölkung. Natürlich nichtlinear. Brownsche Bewegung? Keine Ahnung, jedenfalls chaotisch.
  • Aussentemperatur. Linear? Ein Mathematiker würde vermutlich Nein sagen. Den Bereich der Temperaturfunktion, der für meine Beleuchtung relevant ist, würde ich als Nichtmathematiker mit einer linearen Funktion hinreichend gut beschrieben sehen. 
  • Terrassentür geöffnet (Ja/Nein). Einfach eine boolsche Variable. Keine Funktion.
  • Anwesenheitserkennung. Ebenfalls eine boolsche Variable.
ZitatDas ist aber alles andere als linear. Z.B. müsste bei einem kontinuierlichen x (wie z.B. einer Temperatur) und einer linearen Funktion, auch das Ergebnis ein Kontinuum sein. Das ist hier aber nicht der Fall.
Wäre es das nicht im Beispiel oben, wenn das Licht gedimmt wird? Ein kontinuerliches Ergebnis natürlich innerhalb gewisser Grenzen.
@Thorsten: Du wirst Dich bestätigt fühlen. Von den Boolschen Variablen abgesehen, alles nichtlineare Funktionen.
Ergo sind NN ein potentielles Instrument für den beschriebenen Anwendungsfall.

Dem könnte ich nicht wiedersprechen und doch würde ich (noch)  :) an meinen Standpunkt festhalten. Die relevanten Bereiche der nichtlinearen Funktionen sind linear hinreichend gut beschrieben. Wenn das nicht so sein sollte, sind vielleicht meine Inputparameter nicht die richtigen.
In dem Fall oben habe ich die beiden Inputs (Sonnenlicht und Bewölkung) auf den Helligkeitswert eines Lichtsensors auf der Terrasse reduziert.
Linear oder Nichtlinear? Dimmer = a / Helligkeit + b

Die Heizungssteuerung ist "komplexer" denke ich. Habe mich nie damit befasst. Ich würde aber die gleiche Systematik dahinter vermuten.
Die Komplexität lässt sich vermutlich reduzieren, in dem man die relevanten Inputs auswählt. Bei NN kennt man die Inputs nicht unbedingt, trotzdem ist wichtig, dass sie untereinander möglichst funktional unabhängig sind. Die Eingangsvektoren stehen optimalerweise orthogonal zueinander, meine ich mich noch dunkeln zu erinnern. Jeder Input beschreibt einen relevanten Sachverhalt und wiederholt sich nicht in anderen Inputs.

Wir schauen von zwei Welten/Seiten auf die NN. Deswegen finde ich die Unterhaltung hier interessant. Du schaust aus der Automation auf die NN. Ich schaue von den NN auf die Automation.
Wenn ich x nichtlineare Inputs (Stellschrauben) habe, dann ist ein NN ein geeignetes Instrument, um die Parametrisierung für gewünschte Outputs vorzunehmen, wenn ich nicht weiß, welcher Input was bewirkt bzw. in meine Steuerung eingeht. Aber wenn die Konstellationen (Mechanismen), die für die gewünschten Outputs bekannt sind, dann würde ich kein NN das lernen lassen, was ich schon weiß.
Die Heizungssteuerung werde ich mir zum Gehirnjogging nochmal selbst ein wenig zu Gemüte führen um potentielle NN-Nutzen zu identifizieren. Denke aber, dass Zeit mit FUIP besser investiert ist.  ;)

NN sollen nach Vorbild des menschlichen Gehirns arbeiten. Naja, so gut es geht. Da ist es es sekundär, ob die Neuronen mit Hardware oder Software modelliert werden. "Sekundär" heißt nicht "unwichtig".  Es kommt auf den Anwendungsfall an. Die Philosophie oder Eigenschaften der Netze ist im Kern die gleiche. Gradientenabstiegverfahren gilt in beiden Ausführungen zur Grundlage. Inklusive der damit verbundenen Probleme. Leistung zum Lernen wird immer gebraucht. Anders als vor 30 Jahren, kann man Netze heute auf Grafikkarten trainieren und nicht mehr im Großrechenzentrum der Uni.

Pythonf

#14
Ich hab mich in letzter Zeit etwas an Reinforcement-Learning / DQN  gewagt. Allerdings bisher nicht im Zusammenhang mit FHEM, da ich hier programmiertechnisch noch überfordert wäre.
Dabei sind mir einige Ideen und Fragen aufgekommen. Zuerst einmal wäre die Verwendung eines DQN sinnvoller, als der Einsatz des von mir vorgestellten LSTM-RNN, da auf Änderungen besser reagiert werden kann. Als kurze Erklärung dazu:
In meinem LSTM-RNN werden als Trainingsdaten die vergangenen Handlungen der Nutzer ohne jegliche Gewichtung verwendet. Das bedeutet, wenn das Modell einmal etwas Falsches gelernt hat oder eine Änderung im Setup auftritt, wird es eine Herausforderung dieses Verhalten zu überschreiben! Darüber hinaus sollte das Modell in der Lage sein, sich an das Verhalten des Nutzers anzupassen. Dies ist theoretisch möglich, allerdings für diese Art von NN nicht optimal.

Zum Thema DQN:
Bei einem Deep Q-Network handelt es sich um die Verbindung von Reinforcement-Learning (Stichwort Q-Table) und Deep neuronal Networks. Stark vereinfacht wird ein NN verwendet, um die Werte der Q-Table zu approximieren, da eine sehr große Anzahl an möglichen Zuständen (states) eine Q-Table sehr groß werden würde und damit impraktikabel wäre.

Hier ein Erklärungsversuch zu DQN:
Das Modell bekommt einen Zustand, beispielsweise alle vorhandenen Informationen zum aktuellen Zeitpunkt (und eventuell relevante vorangegangene Daten) übergegeben. Aus diesem State heraus berechnet das Modell aus allen möglichen Handlungen (Actions, z.B. : Licht1 an, Licht2 aus, etc..) die Wahrscheinlichste. Diese wird dann mit einer Belohnungsfunktion (hier muss ich wirklich stark vereinfachen) verglichen. Hat das Modell richtig entschieden bekommt es eine Belohnung (+1 Punkt) und hat es falsch entschieden wird abgezogen (-5 Punkte).

An dieser Stelle stellt sich mir die Frage, wie sich dieses Prinzip auf FHEM übertragen lassen könnte. Hier sind mir verschiedene Szenarien in den Sinn gekommen, welche sich möglicherweise auch kombinieren lassen:

  • Das Modell wird anhand des Logs, ähnlich dem LSTM-RNN trainiert
  • Der Nutzer gibt direkt Feedback ob eine Aktion sinnvoll ist: z.B. Das Modell schickt eine Telegramnachricht, was es jetzt tun würde und der Nutzer kann diese Aktion bewerten. Wenn das Verhalten passend scheint können einzelne Geräte zur Steuerung durch das Netzwerk freigegeben werden.
  • Wenn der Nutzer der Handlung des NN direkt entgegen wirkt, dann wird ein stark negativer Reward gesetzt (z.B. System schaltet das Licht an, der Nutzer schaltet das Licht in einem Zeitraum nach Einschalten wieder aus. Die Bestrafung ist abhängig von der Zeit, welche der Nutzer braucht um dem System entgegen zu wirken). Dies sollte im Optimalfall sehr selten auftreten, würde aber zu einer schnellen Anpassung an falsches/geändertes Verhalten führen.
  • Wenn das System keine Handlung vorhersagt, der Nutzer aber eine Aktion durchführt, dann muss ebenfalls ein stark negativer Reward ausgesprochen werden um das System an das neue Verhalten anzulernen

Wenn wir eine sinnvolle Sammlung von Belohnungsfunktionen finden, dann ließe sich daraus möglicherweise ein sehr interessantes Modell für verschiedenste Szenarien erstellen.

ZitatWenn wir aber die Daten von fast allem Installationen hernehmen, dann könnte man damit die NNs vortrainieren und nur den individuellen Teil in der jeweiligen Installation selbst. So etwas macht man auch bei Gesichtserkennung, soweit ich weiß. Man nimmt ein NN her, in dem zumindest die unteren Schichten mit vielen Gesichtern vortrainiert sind und bringt dem dann noch seine eigenen Freunde und Bekannte bei.
Dieser Aspekt des "transfer learning" wäre mit einem DQN, soweit mir bekannt, ebenfalls deutlich besser umsetzbar und wäre ein weitere Schritt um Rechenleistung zu minimieren und noch bessere Ergebnisse zu erzielen. Sollte es dazu kommen, dass wir ein großteils FHEM kompatibles und nicht zu komplex aufzusetzendes System bekommen, wäre dies in jedem Fall sehr spannend!

Wie immer möchte ich aber gerade hier nochmals betonen, dass es zunächst vor allem um mögliche Theorien geht. Ob diese sinnvoll wären und zu einem gesteigerten Wohngefühl beitragen lässt sich diskutieren und bringt sicherlich auch verschiedenste Meinungen hervor, soll aber nicht Kernthema dieses Threads werden.

Liebe Grüße und mit Interesse auf weiter Antworten
Fabian

# EDIT
Eventuell wäre das Thema im Unterforum Automatisierung mittlerweile besser aufgehoben?