Zustandsautomat für Licht

alanblack · 27 Juli 2020, 23:25:11

Hallo zusammen!

Ich überlege gerade an eine Umstellung meiner Lichtsteuerung herum.
Aktuell nutze ich Watchdogs, um nach dem Öffnen einer Tür oder nach dem Auslösen eines PIR das Licht im Raum für eine Mindestdauer anzuschalten und wenn nichts weiteres passiert, das Licht auch wieder auszuschalten. Die Mindestdauer hängt aktuell nur vom jeweiligen Raum ab. Das führt aber leider ab und zu dazu, dass man ungewollt im Dunkeln steht.

Nebenbei: kann jemand bitte mal prüfen, ob das hier aus der Commandref wirklich falsch ist?

ZitatEin generischer Watchdog (ein Watchdog, verantwortlich für mehrere Devices) ist derzeit nicht möglich.

Denn

Code Auswählen

defmod LichtWachhund watchdog (FlurTreppe_Tuer|Flur.*(Tuer|Tuer.|PIR.)):(open|motion) 00:02:30 SAME { &Mach_Etwas() }
scheint einwandfrei zu funktionieren.

Zurück zum Thema:
jetzt möchte ich das aufbohren, dass bspw.
- Tür geht auf => Licht (ab jetzt) min. 2 Minuten an
- Bewegung => Licht (ab jetzt) min. 5 Minuten an
- Tür zu => Licht () min. 5 Minuten an
- Bewegung => Licht min. 30 Min. an
usw. geht. Einer Schätzung nach bin ich bei 20-30 Watchdogs und Notifies pro Raum, die ich querbeet active und inactive setzen müsste. Dabei wäre noch nicht ein unterschiedliches Verhalten der Steuerung nach "im Haus anwesende Personen/Tageszeit/Dienstplan/..." berücksichtigt.

Meinen ersten Ansatz, jeweils ein AT und ein bis zwei NOTIFYs zu defmodden scheiterte daran, dass die Systemlast bei einem Raum selbst meinen XU4 ins Schwitzen bringt. Und ich wollte keinen High-End-PC nur für FHEM in den Keller stellen, damit alle Räume automatisch beleuchtet werden.

Hat jemand dazu eine Meinung?

DOIFs ist vielleicht ein Thema für mich, aber ich lese aus der Commandref nicht heraus, wie ich das damit umsetzen könnte.

Besten Dank im Voraus!

amenomade · 28 Juli 2020, 00:01:10

Zitat von: alanblack am 27 Juli 2020, 23:25:11
Nebenbei: kann jemand bitte mal prüfen, ob das hier aus der Commandref wirklich falsch ist?
Zitat

Ein generischer Watchdog (ein Watchdog, verantwortlich für mehrere Devices) ist derzeit nicht möglich.

Nebenbei: kann jemand bitte mal prüfen, ob das hier aus der Commandref wirklich falsch ist?Denn
Code Auswählen Erweitern
defmod LichtWachhund watchdog (FlurTreppe_Tuer|Flur.*(Tuer|Tuer.|PIR.)):(open|motion) 00:02:30 SAME { &Mach_Etwas() }
scheint einwandfrei zu funktionieren.

Ne, das ist nicht falsch. Wenn mehrere Devices durch regex1 und regex2 matchen, dann wird z.B. ein Event auf Device1 das Watchdog triggern und ein Event auf Device2 das Watchdog zurücksetzen. Nicht in jedem Szenario gewünscht. Aber für dein Anliegen scheint es zu passen, weil Du willst das jedes matchenden Event als "SAME" bewertet wird.

Dein Ding kann man sicher mit DOIF machen. Siehe
https://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung
https://fhem.de/commandref_DE.html#DOIF_wait
https://fhem.de/commandref_DE.html#DOIF_do_resetwait

Etwas wie DOIF (["event1"])(set on)(set off) DOELSEIF (["event2"])(set on)(set off) DOELSEIF (["event3"])(set on)(set off)
attr doifname wait 0,120:0,300:0,300

Und wenn man einen Zustandautomat will, der abhängig vom jetzigen Zustand schaltet, kann man die Bedingungen mit [?$SELF] eq "cmd_xx" erweitern.
https://fhem.de/commandref_DE.html#DOIF_cmdState

JoWiemann · 28 Juli 2020, 08:23:06

Hallo,

vielleicht hilft Dir auch der Thread noch weiter: https://forum.fhem.de/index.php?topic=49109.0

Grüße Jörg

rudolfkoenig · 28 Juli 2020, 08:59:22

Alternative: notifies, die jeweils ein "set X on-for-timer Y" ausloesen. Diese kann man auch zusammenfassen, und per Perl-Code das Y im Abhaengigkeit vom ausloesenden Element ($NAME) abhaegig machen.

ZitatMeinen ersten Ansatz, jeweils ein AT und ein bis zwei NOTIFYs zu defmodden scheiterte daran, dass die Systemlast bei einem Raum selbst meinen XU4 ins Schwitzen bringt.

Vermutlich ging da etwas schief, FHEM sollte auf so einem System ein Event/notify in unter einem ms Bereich abarbeiten.

Bei vielen notifes/FileLog/DOIF/etc kann man das weiter optimieren, wenn man darauf achtet, dass ein NOTIFYDEV Internal in den Details erscheint. Dazu sollte bei notify/FileLog der Regexp als NAME, NAME:EVENT.*, oder NAME.*:EVENT.* formuliert werden. Solche Ausdruecke kann man mit | aneinanderhaengen. Die DOIF Regeln dafuer kenne ich nicht.

alanblack · 28 Juli 2020, 18:52:58

Zitat von: amenomade am 28 Juli 2020, 00:01:10
Ne, das ist nicht falsch. Wenn mehrere Devices durch regex1 und regex2 matchen, dann wird z.B. ein Event auf Device1 das Watchdog triggern und ein Event auf Device2 das Watchdog zurücksetzen.

Ok, dann ist es in der Commandref nur ungenau beschrieben. Sollte dann eher so lauten

ZitatEin generischer Watchdog (ein Watchdog, verantwortlich für mehrere Devices) ist derzeit nur insoweit möglich, dass <regexp1> und <regexp2> zwar als reguläre Ausdrücke mehrere Devices überwachen können, aber es nicht das selbe Device sein muss, dass den Watchdog erst triggert und dann zurücksetzt.

(Nur meine 5 Cents.)

ZitatDein Ding kann man sicher mit DOIF machen. Siehe

Ich schaue es mir noch einmal genauer an, fürchte aber dass das DOIF ziemlich unübersichtlich groß werden würde.

Zitat von: JoWiemann am 28 Juli 2020, 08:23:06
Hallo,

vielleicht hilft Dir auch der Thread noch weiter: https://forum.fhem.de/index.php?topic=49109.0

Grüße Jörg

Das vereinfacht zumindest das resultierende DOIF. In der einfachsten Form, die ich gerne umsetzen würde hat der Zustandsautomat sieben Zustände mit je bis zu fünf Events; oder halt 26 DOELSEIF... wenn es funktioniert.

Zitat von: rudolfkoenig am 28 Juli 2020, 08:59:22
Alternative: notifies, die jeweils ein "set X on-for-timer Y" ausloesen. Diese kann man auch zusammenfassen, und per Perl-Code das Y im Abhaengigkeit vom ausloesenden Element ($NAME) abhaegig machen.

Ich sollte mal probieren, was passiert, wenn ich "set Lampe1 on-for-timer 120" und nach 63 Sekunden "set Lampe1 on-for-timer 240" abschicke. Teste ich gleich mal im Anschluss.
Danke, hilft aber nur bedingt, weil ich eher mit "set x pct y : transitiontime z" arbeite.

[zuviel Systemlast]

ZitatVermutlich ging da etwas schief, FHEM sollte auf so einem System ein Event/notify in unter einem ms Bereich abarbeiten.

Die Ausführung von ATs und NOTIFYs ist unkritisch, aber ich schrieb von "defmodden". Also bspw. "defmod AT +00:02:00; defmod NOTIFY mach1", vor Ablauf ein "defmod AT +00:05:00; defmod NOTIFY mach2" usw. Das Modifizieren von Devices zur Laufzeit dauert AFAIK deutlich länger, so dass bei zu vielen Events die Last recht groß wurde. Ich hatte diese Konstrukte aus meinen Anfängen mit FHEM mal alle ausgebaut, als FHEM noch auf einem raspi lief.
Wenn Du sagst, dass es dies nicht sein kann, krame ich mal in meinem Archiv, und schicke die die LISTs, wo dort mein Fehler lag.

Damian · 28 Juli 2020, 20:38:47

Ich würde das heute generisch so lösen:

Beispiel:

Code Auswählen

defmod di_licht_bm DOIF DEF TPL_licht (\          ## Template für einen Lichtautomaten
{if ([$1:state] eq "auf" or [$2:"motion"]) {      ## wenn Tür auf oder Bewegung\
  if (get_Exec("timer_$1") == 0) {                ## Wenn kein Timer läuft\
    fhem_set("$3 on");;                           ## Lampe an\
  }\
  set_Exec("timer_$1",$4,"fhem_set('$3 off')");;  ## Timer zum Lampe aus setzen oder verzögern\
}\
}\
)\
TPL_licht (Kueche,BM_Kueche,Lampe_Kueche,30)             ## Steuerung für die Küche \
TPL_licht (Wohnzimmer,BM_Wohnzimmer,Lampe_Wohnzimmer,60) ## Steuerung für's Wohnzimmer\
## usw.

Hier arbeiten beliebig viele unabhängige Lichtautomaten innerhalb eines Moduls. Für einen weiteren Lichtautomaten braucht man jeweils nur eine Zeile am Ende hinzufügen mit den Parametern des Zimmers (Schalter, Bewegungsmelder,Lampe, Zeit). Das Beispiel lässt sich natürlich beliebig erweitern, siehe auch:
https://wiki.fhem.de/wiki/DOIF/Templates
https://wiki.fhem.de/wiki/DOIF/Automatisierung

alanblack · 28 Juli 2020, 22:06:01

Zitat von: Damian am 28 Juli 2020, 20:38:47
Ich würde das heute generisch so lösen:

Ist eine elegante Form von meiner aktuellen Watchdog-Lösung. Du machst mit einem Template und einer Zeile pro Raum das, was ich mit zwei Zeilen (ein Notify und ein Watchdog) pro Raum ohne Template mache.

Davon möchte ich aber weg. Ein Event startet einen Timer - die Dauer hängt vom Event ab ebenso davon, was vorher passiert ist... und davor... geht IMHO nur mit einem Zustandsautomaten.

Zitat von: alanblack am 28 Juli 2020, 18:52:58
Ich sollte mal probieren, was passiert, wenn ich "set Lampe1 on-for-timer 120" und nach 63 Sekunden "set Lampe1 on-for-timer 240" abschicke. Teste ich gleich mal im Anschluss.

Ok, die Lampe1 bliebe im Beispiel 303 Sekunden an.
@rudolfkoenig
Kannst Du "mal eben" ein pct-x-for-timer in FHEM einbauen?

amenomade · 28 Juli 2020, 22:18:31

Wenn -for-timer nicht funktioniert (das ist nicht "in FHEM" sondern abhängig vom Modul) kann man das anders machen. Dir wurden schon im Thread 2 unterschiedliche Wege gegeben. Hier einen dritten: "set pct irgendwas;sleep 10;set off".

Warum fängst Du nicht an, etwas zu implementieren, damit wir dir evtl. helfen können? Oder erwartest Du, dass die Lösung fertig-kodiert hier landet, ohne dass wir genau wissen, was Du machen möchtest, abhängig von was und mit welchen Bedingungen?

alanblack · 28 Juli 2020, 22:53:35

Zitat von: amenomade am 28 Juli 2020, 22:18:31
Wenn -for-timer nicht funktioniert (das ist nicht "in FHEM" sondern abhängig vom Modul) kann man das anders machen. Dir wurden schon im Thread 2 unterschiedliche Wege gegeben. Hier einen dritten: "set pct irgendwas;sleep 10;set off".

Warum fängst Du nicht an, etwas zu implementieren, damit wir dir evtl. helfen können? Oder erwartest Du, dass die Lösung fertig-kodiert hier landet, ohne dass wir genau wissen, was Du machen möchtest, abhängig von was und mit welchen Bedingungen?

Nee, ich lese noch die ganzen Verweise, die ich von Euch erhalten habe. Besten Dank dafür! Hier https://forum.fhem.de/index.php/topic,49109.msg410525.html#msg410525 hatte ich die Hoffnung, dass dieser Vorschlag von irgendwem gecoded wurde. Wenn, dann habe ich die Syntax noch nicht in der Doku gefunden.

Ok, Zustandsautomaten sind nicht ganz einfach zu verstehen oder zu handhaben; siehe ungewollte Loops etc. Wenn es in FHEM so ein Zustandsautomaten-Device gäbe, könnte ich einigen Code vereinfachen.

Siehe Watchdog: ich hatte einige Stellen, an denen ich ATs zur Laufzeit modifiziert hatte, bis ich über Watchdogs stolperte, welche das ohne "rotes Fragezeichen" und mit weniger Systemlast erledigen.

Nebenbei schreibe ich in Pseudocode gerade einen exemplarischen DOIF für einen Zustandsautomaten für mein Wohnzimmer. Das macht - Stand jetzt - nicht wirklich Spass, weil in jedem DOELSEIF-Zweig eine mehr oder weniger lange Kette von (([doif] eq "Zustand1") or ([doif] eq "Zustand5") or...) steht.

Zu Deinem dritten Vorschlag: was passiert wenn
NOTIFY TürAuf set pct irgendwas;sleep 10;set off
NOTIFY Bewegung set pct irgendwas;sleep 20;set off
die Tür aufgeht und 8 Sekunden später der PIR eine Bewegung meldet?

Wenn es Dich stört, dass ich nachdenke, bevor ich anfange, zu coden, kannst Du mir das gerne zum Vorwurf machen. Mea Culpa!

Edit:was ich umsetzen will, habe ich mal grafisch beigefügt.

Damian · 28 Juli 2020, 23:29:49

Zitat von: alanblack am 28 Juli 2020, 22:06:01
Ist eine elegante Form von meiner aktuellen Watchdog-Lösung. Du machst mit einem Template und einer Zeile pro Raum das, was ich mit zwei Zeilen (ein Notify und ein Watchdog) pro Raum ohne Template mache.

Davon möchte ich aber weg. Ein Event startet einen Timer - die Dauer hängt vom Event ab ebenso davon, was vorher passiert ist... und davor... geht IMHO nur mit einem Zustandsautomaten.

Du kannst natürlich auch in einem Template dir entsprechende Zustände in einer "Instanzvariablen" pro Szenario mit $VAR{$1}="Zustand X" ablegen und mit if ($VAR{$1} eq "Zustand X") abfragen. Und wenn du nun eine für dich zufriedenstellende Lösung gefunden hast, dann bist du fertig und brauchst nicht die Steuerungslogik X-mal für alle Zimmer zu kopieren.

amenomade · 29 Juli 2020, 00:40:38

Mich stört nix, aber erst jetzt können wir verstehen, was Du genau machen willst.

Ich finde es fragil, egal die Lösung. Es reicht einen unvorgesehenen Event, und das ganze ist desynchronisiert.

Ergänzende Fragen zu meinem Verständnis:
- wie weisst Du, wenn die Tür auf und zu geht, ob jemand den Raum verlassen hat, oder ob jemand dazu reingekommen ist?
- wie sind die Pfeile mit "Licht aus" zu verstehen? Manuelles Ausschalten, oder Ende des Timers?
- was hat die untere lange Pfeile für eine Beschrifftung/Event
- was bedeutet "Tür auf/zu"? Du hast schon andere Ausgangspfeile mit Tür zu

MadMax-FHEM · 29 Juli 2020, 01:01:34

Ich bin mir ja bei dem ganzen "Pfeil-Wirrwarr" auch nicht sicher, ob das "lückenlos" ist (und bis ganz zu Ende durchdacht)...
EDIT: gut vielleicht in deinem Kopf

EDIT: genau genommen kann das so nicht gehen. In einer State-Machine kann man mit einem Ereignis aus einem Zustand nur in einen bestimmten anderen kommen. Wenn man (theoretisch) mit DEMSELBEN Ereignis (z.B. Tür zu) von einem Ausgangszustand in 2 Zustände kommen kann -> wie soll das gehen bzw. in welchem landet man dann nun!? Bzw. was bedeuten die Übergänge "Tür auf/zu" vom Zustand zu "sich selbst"!?

Sieht auf jeden Fall sehr kompliziert aus...

Evtl. ist das ja auch eine Variante: https://forum.fhem.de/index.php/topic,98594.0.html

Viel Erfolg, Joachim

amenomade · 29 Juli 2020, 01:39:58

Also, bis auf Korrekturen wegen Unstimmigkeiten und fehlenden Informationen im Bild (siehe Fragen oben), würde es prinzipiell so ungefähr aussehen:

Code Auswählen

(["Bewegung"] and [?$SELF] =~ "cmd1|cmd_6|init")
  (Licht an)(Licht aus) 
DOELSEIF
(["Bewegung"] and [?$SELF] =~ "cmd2|cmd3" or ["Tür auf"] and [?$SELF] =~ "cmd1|cmd2")
  (Licht an)(Licht aus) 
DOELSEIF
(["Tür auf"] and [?$SELF] =~ "cmd_6|cmd4|cmd3|cmd5|cmd_7|init")
  (Licht an)(Licht aus) 
DOELSEIF
(["Tür zu"] and [?$SELF] =~ "cmd3|init")
  (Licht an)(Licht aus) 
DOELSEIF
(["Tür zu"] and [?$SELF] =~ "cmd_7")
  (Licht aus) 
DOELSEIF
(["Tür zu"] and [?$SELF] =~ "cmd2")
  (Licht an)(Licht aus) #Zustand2
DOELSE(IF ?? ??)
  (Licht an o. aus?)


attr wait 0,1800:0,300:0,300:0,120:0:0,120:0
attr do always

Damian · 29 Juli 2020, 08:39:02

Abgesehen vom wissenschaftlichen Ansatz - ich glaube nicht, dass dein Ansatz verhindert, dass du im Dunkeln sitzt.

Ich würde mehr Energie investieren, eine zuverlässige Anwesenheitserkennung im Raum zu installieren, denn ohne diese nützen dir die besten Zustandsautomaten nichts, die die Sache nur unnötig verkomplizieren und schwer pflegbar machen.

Ich habe meine Lichtautomatik mit Bewegungsmeldern im Wohnzimmer längst deaktiviert, denn spätestens, wenn einer länger auf der Couch einen Film geschaut hat, saß er am Ende im Dunkeln.

alanblack · 29 Juli 2020, 20:52:57

Sorry, aber ich habe jetzt erst wieder etwas Zeit.

Zitat von: amenomade am 29 Juli 2020, 00:40:38
Ich finde es fragil, egal die Lösung. Es reicht einen unvorgesehenen Event, und das ganze ist desynchronisiert.

Naja, einem Zustandsautomaten sind nicht definierte Zustände oder Übergänge egal; er macht dann einfach nix. Dies ist auch eine minimale Lösung. In jedem Zustand stehen ja noch Details, unter anderem "Automatik an" und "alle Fenster zu". Weiter oben schrieb ich etwas von "anwesende Personen" und "Dienstplan", was hier gar nicht erscheint.

Zitat
Ergänzende Fragen zu meinem Verständnis:
- wie weisst Du, wenn die Tür auf und zu geht, ob jemand den Raum verlassen hat, oder ob jemand dazu reingekommen ist?

Reed-Kontakte an jeder Tür.

Zitat
- wie sind die Pfeile mit "Licht aus" zu verstehen? Manuelles Ausschalten, oder Ende des Timers?

Für DIESEN Automaten ist es egal, ob der Timer oder eine Hand am Schalter das Licht ausmacht. Es gibt kein "Licht an", weil das auf "Automatik aus" hinauslaufen würde. Damit wäre der Automat gut doppelt so groß.

Zitat
- was hat die untere lange Pfeile für eine Beschrifftung/Event

Sorry, schlecht geschnitten! Da steht "Bewegung" dran.

Zitat
- was bedeutet "Tür auf/zu"? Du hast schon andere Ausgangspfeile mit Tür zu

Ich hatte angefangen, das Zustandsdiagramm zu bauen mit "Tür auf" und "Tür zu", bis mir einfiel, dass ich Räume mit mehr als einer Tür auch berücksichtigen muss. In den meisten "Pfeilen"... äh... Fällen wäre ein "erste Tür auf" und "letzte Tür zu" richtiger. Daher die Einträge in den Zuständen "alle Türen zu" bzw. "min. 1 Tür offen". Ich kann nur bei einem Bewegungsevent in einem Raum mit allen Türen geschlossen annehmen, dass eine Person im Raum ist. Ob eine oder zwei oder gar mehr Türen offen sind, ist aber egal, da durch jede offene Tür Personen in den oder aus dem Raum gehen können. Ist also schon eine Tür offen, ist es egal, ob ein Event von einer anderen Tür kommt. Der vollständige endliche Zustandsautomat für mein Treppenhaus müsste Zustände für 0 bis 11 Türen offen haben... nööööööö.

Zitat von: MadMax-FHEM am 29 Juli 2020, 01:01:34
Ich bin mir ja bei dem ganzen "Pfeil-Wirrwarr" auch nicht sicher, ob das "lückenlos" ist (und bis ganz zu Ende durchdacht)...
EDIT: gut vielleicht in deinem Kopf

Nicht einmal ist es lückenlos; siehe oben.

ZitatEDIT: genau genommen kann das so nicht gehen. In einer State-Machine kann man mit einem Ereignis aus einem Zustand nur in einen bestimmten anderen kommen. Wenn man (theoretisch) mit DEMSELBEN Ereignis (z.B. Tür zu) von einem Ausgangszustand in 2 Zustände kommen kann -> wie soll das gehen bzw. in welchem landet man dann nun!? Bzw. was bedeuten die Übergänge "Tür auf/zu" vom Zustand zu "sich selbst"!?

Falsch! Ein Zustandsautomat kennt mindestens ein NOP.
Wo Du hinkommst, steht ja in den Zuständen. Ich habe das FHEM-mäßig dahin gehend schon vorbereitend vereinfacht, dass jeder Raum eine STRUCTURE für die Türen bekommen hat. Wenn ich diese in das Zustandsdiagramm schreibe, fliegen die meisten Pfeile von einem Zustand auf sich selbst raus.

ZitatEvtl. ist das ja auch eine Variante: https://forum.fhem.de/index.php/topic,98594.0.html

Homezone ist nach kurzem Anlesen dergleiche Ansatz. Lese ich auch mal genauer, ist aber noch kein offizielles Modul. Trotzdem schaue ich mal drauf. Hatte ich noch nicht gefunden. Danke!

Zitat von: amenomade am 29 Juli 2020, 01:39:58
Also, bis auf Korrekturen wegen Unstimmigkeiten und fehlenden Informationen im Bild (siehe Fragen oben), würde es prinzipiell so ungefähr aussehen:

Ich glaube, es wäre wenn mit DOIF eher sinnvoll, die Zustände über einen Dummy abzubilden. denn ein reines DOIF wird mit

Code Auswählen

and [?$SELF] =~ "cmd_6|cmd4|cmd3|cmd5|cmd_7|init"
doch schnell unübersichtlich. Aber das Konstrukt könnte funktionieren. Teste ich zeitnah. Thx!

Zitat von: Damian am 29 Juli 2020, 08:39:02
Abgesehen vom wissenschaftlichen Ansatz - ich glaube nicht, dass dein Ansatz verhindert, dass du im Dunkeln sitzt.

Sooo wissenschaftlich ist ein Zustandsautomat nur auch wieder nicht. Und manchmal ist auch der Weg das Ziel.
Scherz beiseite! Da diese ganze Hausautomation per se und insbesondere über Funk viele Fehlerquellen hat, kann und will ich nichts lückenlos implementieren. Es gibt immer auch normale Schalter für den Fall der Fälle usw. Und wenn ich ein oder zweimal im Monat auf der Couch oder wo auch immer den Arm heben muss, damit einer der 38 PIRs das erkennt und das Licht wieder angeht, ist mir das egal. Meine Frau und meine Tochter finden es Klasse, dass sie nachts auf dem Weg zur Toilette keine Lichtschalter suchen müssen, trotzdem überall etwas sehen aber auch nirgends geblendet werden.

ZitatIch würde mehr Energie investieren, eine zuverlässige Anwesenheitserkennung im Raum zu installieren, denn ohne diese nützen dir die besten Zustandsautomaten nichts, die die Sache nur unnötig verkomplizieren und schwer pflegbar machen.

Kennt Du Präsenzmelder, die günstig, kabellos und FHEM-kompatibel sind? Ich habe noch keine gefunden.
Die Überlegung zu diesem Zustandsautomaten ist hieraus und aus der Überlegung geboren, dass meine Tochter sicher nicht ständig ein BT-Token mit sich herumtragen wird. Sonst hätte ich ein paar Raspis verteilt und mich in dreidimensionaler Triangulation versucht.

EDIT: wenn ein Film läuft, erkennt FHEM das an KODI und lässt das Licht an.