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
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!
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
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
Hallo,
vielleicht hilft Dir auch der Thread noch weiter: https://forum.fhem.de/index.php?topic=49109.0
Grüße Jörg
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.
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.
Ich würde das heute generisch so lösen:
Beispiel:
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
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? ::)
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?
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.
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.
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
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
Also, bis auf Korrekturen wegen Unstimmigkeiten und fehlenden Informationen im Bild (siehe Fragen oben), würde es prinzipiell so ungefähr aussehen:
(["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
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.
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
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.
Zitatwie 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.
Meine Frage war: Tür auf dann Tür zu => ist jemand dazu reingekommen und befinden sich jetzt 2 Personen im Raum, oder hat der einzige Bewohner den Raum verlassen, oder hat jemand einfach die Tür auf und zu gemacht aber hat sich dann anders überlegt...
ZitatFü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ß.
Das ist eben in einem DOIF nicht egal, weil abhängig davon muss der DOIF sich selbst triggern oder nicht. Also ich nehme an: beides. Dann müsste natürlich das Ding entspr angepasst werden.
ZitatIch 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.
Eben, siehe Frage oben. Also letztendlich ist es nur durch Bewegung getriggert, da Du grundsätzlich nicht weisst nach Tür Event, wieviele Leute im Raum sind. Warum dann so kompliziert?
Also... das wird (zumindest mir) tatsächlich mit einem DOIF zu kompliziert. Aber ich befürchte, es wird mit anderen on-board Lösungen genauso kompliziert sein, wenn Du dein Zustandsautomat nicht vereinfachst.
Zitat von: amenomade am 29 Juli 2020, 21:51:02
Meine Frage war: Tür auf dann Tür zu => ist jemand dazu reingekommen und befinden sich jetzt 2 Personen im Raum, oder hat der einzige Bewohner den Raum verlassen, oder hat jemand einfach die Tür auf und zu gemacht aber hat sich dann anders überlegt...
Du gehst davon aus, dass ich auf ein Ergebnis "Raum leer" <=> "Raum nicht leer" hinaus will. Würde ich gerne, habe ich aber außer mit Präsenzmeldern oder mit Ortung von Handys/Token noch keine 100%- oder wenigstens 98%-ige Lösung gefunden. Und die scheiden wie gesagt aus verschiedenen Gründen aus.
ZitatEben, siehe Frage oben. Also letztendlich ist es nur durch Bewegung getriggert, da Du grundsätzlich nicht weisst nach Tür Event, wieviele Leute im Raum sind. Warum dann so kompliziert?
Dir ist nicht aufgefallen, dass die verschiedenen Zustände unterschiedlich lange Einschaltzeiten beinhalten? Das ist quasi eine Abbildung der Wahrscheinlichkeit für die Anwesenheit einer Person im Raum.
ZitatAlso... das wird (zumindest mir) tatsächlich mit einem DOIF zu kompliziert. Aber ich befürchte, es wird mit anderen on-board Lösungen genauso kompliziert sein, wenn Du dein Zustandsautomat nicht vereinfachst.
Ich neige nicht dazu, die zu erledigende Arbeit einem Werkzeug anzupassen. Ich schlage keine Schraube mit dem Hammer in ein Brett.
Zitat von: alanblack am 30 Juli 2020, 08:23:01
Dir ist nicht aufgefallen, dass die verschiedenen Zustände unterschiedlich lange Einschaltzeiten beinhalten? Das ist quasi eine Abbildung der Wahrscheinlichkeit für die Anwesenheit einer Person im Raum.
Hmmm, ist das nicht das was homezone auch berücksichtigt!?
Also nicht, dass ich mich weiter damit beschäftigt hätte...
...wollte ich mal immer...
Aber: leider keine Zeit (bzw. wichtigere Dinge ;) )...
Zitat von: alanblack am 30 Juli 2020, 08:23:01
Ich neige nicht dazu, die zu erledigende Arbeit einem Werkzeug anzupassen. Ich schlage keine Schraube mit dem Hammer in ein Brett.
Aber dann musst du entweder die Arbeit (Schraube -> Nagel) anpassen (wie amenomade meint) oder aber das Werkzeug anpassen (Hammer -> Schraubendreher)...
Vielleicht ist halt DOIF nur ein Hammer (ohne DOIF nahe treten zu wollen!! ;) )...
Viel Erfolg, Joachim
ZitatDir ist nicht aufgefallen, dass die verschiedenen Zustände unterschiedlich lange Einschaltzeiten beinhalten? Das ist quasi eine Abbildung der Wahrscheinlichkeit für die Anwesenheit einer Person im Raum.
Das ist mir natürlich aufgefallen, ich habe es sogar im wait Attribut implementiert. Und ich verstehe, was Du damit machen willst. Ich kann dir nur wie Damian sagen: sowas wird nicht verhindern, dass Du irgendwann im Dunkel sitzt. Insbesondere weil die Tür auf/zu einen Einfluss auf die Zeit haben.
Willst Du Beispiele?
- Anfangssituation: 2 Personen P1 und P2 im Raum, Status 1
Fall1: P1 verlässt den Raum und lässt die Tür auf (Status 4). Ab dem Moment muss P2 alle 5 Minuten den Bewegungsmelder triggern, sonst sitzt er im Dunkel.
Fall2: P1 verlässt den Raum, (Status 4) macht die Tür zu (Status 2), macht kurz wieder auf weil er vergessen hat, etwas P2 zu sagen (Status 5) und wieder zu (Status 3). In 120 Sekunden sitzt P2 im Dunkel und das kann er nicht verhindern.
Das sind nur schnell 2 Beispiele. Ich bin sicher, dass man noch viele finden kann. Aber erfahrungsmässig reichen 2x im Dunkel im schlechten Moment zu sitzen, um den WAF auf 0 zu setzen. Und das ist mit nur einer Tür im Raum, und angenommen, dass dein Bewegungsmelder zuverlässig die kleinste Bewegung merckt.
Ich bin der Meinung, das ganze ist nicht wirklich besser als:
- Tür auf => 300 Sekunden
- Bewegung 1 => 300 Sekunden
- Bewegung 2 und folgende => 1800 Sekunden
Letztendlich ist es nicht besser als eine reine bewegungsgesteuerte Präzenz: 1. Bewegung = 300s, weitere Bewegungen = 1800s
Zitat von: MadMax-FHEM am 30 Juli 2020, 08:40:08
Hmmm, ist das nicht das was homezone auch berücksichtigt!?
Ich hatte zuvor schon geschrieben, dass ich mich mal damit beschäftigen werde. Derzeit sind drei "homezones" zu 100% mit mindestens einer Person belegt. Das Problem ist, dass ich alleine im Haus bin. Ich bin noch nicht sicher, warum dieses Modul daneben liegt, aber es scheint, dass, wenn die (letzte) Tür geschlossen wird und wegen Bewegung die Wahrscheinlichkeit noch auf 100% steht, das leider so bleibt.
Zitat
Aber dann musst du entweder die Arbeit (Schraube -> Nagel) anpassen (wie amenomade meint) oder aber das Werkzeug anpassen (Hammer -> Schraubendreher)...
Vielleicht ist halt DOIF nur ein Hammer (ohne DOIF nahe treten zu wollen!! ;) )...
Viel Erfolg, Joachim
Oder schlimmstenfalls mir das Werkzeug selbst bauen - es wäre nicht das erste Modul.
Zitat von: amenomade am 30 Juli 2020, 19:19:50
Ich kann dir nur wie Damian sagen: sowas wird nicht verhindern, dass Du irgendwann im Dunkel sitzt.
Das weiß ich.
Zitat
Willst Du Beispiele?
Ich kenne die Lücken.
ZitatIch bin der Meinung, das ganze ist nicht wirklich besser als:
- Tür auf => 300 Sekunden
- Bewegung 1 => 300 Sekunden
- Bewegung 2 und folgende => 1800 Sekunden
Das dürfte zu recht häufige unnötig beleuchteten Räumen führen.
Zitat
Letztendlich ist es nicht besser als eine reine bewegungsgesteuerte Präzenz: 1. Bewegung = 300s, weitere Bewegungen = 1800s
Das führt sicher häufiger zu unnötig beleuchteten Räumen.
Deine Meinung in Ehren. Ich für meinen Teil suche nach einem Lösungsansatz für eine möglichst weit gehende Automatisierung einer Beleuchtungssteuerung.
Solange ich meiner Frau und meiner Tochter keinen was-und-wie-auch-immer-Transmitter umhängen kann, werde ich 100% sicher nie erreichen.
Bspw. morgens im Flur an Tagen, wenn meine Frau Dienst hat, im Zeitraum Dientsbeginn - Fahrzeit -(20Min - 0 Min) die Beleuchtung nach einem Bewegungsevent zwei Minuten länger an zu lassen, hat den WAF schon einiges nach oben geschraubt.
Obwohl meine Frau weiß, dass "an = an" und "aus = aus" ist, ignoriert sie doch recht häufig die Lichtschalter.
Die Idee war nun, dass in FHEM irgendeine modulseitige Unterstützung für einen Zustandsautomaten steckt, die ich noch nicht gefunden hatte.
Es macht aber keinen Sinn, hier das Modell eines vollständigen endlichen Zustandsautomaten für Beleuchtung eines Raumes zu entwickeln, wenn die Technik mit zu grobem Zeitraster und die Programmierumgebung die Umsetzung dieses Automaten nicht in kleiner-NP Aufwand erlauben.
Vielleicht kannst Du sowas anpassen?
https://forum.fhem.de/index.php/topic,51796.msg435083.html#msg435083