Lampe an der Haustüre und Abwesenheit

[mendikant]

Hallo zusammen!

Meine Javascript Kenntnisse wachsen, bisher reichten mir if Verzweigungen, eigene Datenpunkte und mal nen setStatedelayed.
Aber jetzt komme ich mit meiner Erfahrung an meine Grenzen, daher frage ich hier mal nach.
In der aktuellen Version des Skriptes sind keine Syntaxfehler enthalten, es läuft so durch.

Ich will bei Dunkelwerden die Lampe an der Haustüre einschalten, falls einer von zwei Bewohnern nicht zuhause ist.
Das Skript soll dann in eine While Schleife gehen und die Lampe wieder abschalten, wenn die Bewohner wieder zuhause sind:
Meine "Probleme":

• Ist eine While Schleife hier sinnvoll, auf den ersten Blick finde ich es charmant, weiß aber nicht, ob die Kombination mit dem on id sinnvoll ist
  -Ich musste die Dockingstation meiner Frau in FB-Presence aufnehmen, um das Licht in Ihrem Arbeitszimmer zu steuern. Ich muss also noch den Fall abfangen: ich bin weg, sie sitzt im Arbeitszimmer und die Dockingstation ist Präsent (aber das ist machbar)
• Was passiert, wenn wir beide gleichzeitig nachhause kommen
• Was passiert wenn wir beide unterwegs sind und unterschiedlich nachhause kommen..
  die letzten Beiden Fälle könnte ich auch mit if und on id abfangen.. aber ob das funktioniert?

code_text
//Bei Sonnenuntergang angehen, wenn eine Person außer Haus

schedule({astro: "sunset", shift: -20 }, function () {
    if(getState('fb-checkpresence.0.familyMembers.Familie.absentCount') >  1)
        {   //Lampe an der Haustüre wird eingeschaltet
             setState('zigbee.0.7cb03eaa0a0381c2.state', true);
        };
        do {

     //Kerstin Kommt nach Hause
         on:({id: 'fb-checkpresence.0.familyMembers.Familie.Kerstin.presence', change: "ne"}, function (obj) 
            { 
            //setState flurlicht oben an
            //Lampe an der Haustüre aus
            setStateDelayed('zigbee.0.7cb03eaa0a0381c2.state', false, 600000);      
            }
            );
 
 
         //Christian Kommt nach Hause
          on:({id: 'fb-checkpresence.0.familyMembers.Familie.Christian.presence', change: "ne"}, function (obj) 
            {
            //setState flurlicht oben an
            //Lampe an der Haustüre aus
            setStateDelayed('zigbee.0.7cb03eaa0a0381c2.state', false,600000);
            }
            ); 
            setTimeout(300000);
         }
        while (getState('zigbee.0.7cb03eaa0a0381c2.state') == true);
        });

Herzlichen Dank für Euer Input

Christian

[mickym]

@mendikant Ich arbeite zwar mit Node Red und nicht mit JS - aber im Prinzip geht es hier um Logik. While Schleifen innerhalb eines Triggers solltest Du grundsätzlich vermeiden. Ein do mit einem Trigger ist einfach unsinnig - weil ein Trigger immer triggert egal was da drum rum ist. Ein While während die Lampe true ist - lässt Dein Skript in einer Endlosschleife laufen und legt Dein System lahm bzw. sowas frisst unsinnig Ressourcen. Vergiss sowas generell.
Die Trigger sind deshalb genial, weil man aktiv benachrichtigt wird und man nicht pollt - also zyklisch Zustände abfrägt. Das macht wenn das System oder der Adapter, aber Du solltest das in der Regel nicht machen!!!

Meines Erachtens sind die Trigger falsch gesetzt. Anstelle über die Zeit - also Astro - zu triggern, solltest Du über Deine Anwesenheit zuerst triggern und da Deine ganzen Bedingungen abfragen (einer, keiner, beide zuhause). Erst wenn diese Prüfung ein potentielles Einschalten erlaubt, würde ich die Zeit überprüfen.

Sprich Du prüfst erst eine über den Scheduler gesetzte Variable oder Datenpunkt, ob das Licht potentiell eingeschaltet werden soll.

Ggf. kann man mit dem Scheduler nochmals zusätzlich triggern, wenn sich die Präsenz nicht selbstständig zyklisch aktualisiert.

Die Bedingung entspricht im Prinzip einer XOR Verknüpfung:

Also wenn ich Anwesenheit der Person als true nehme (sprich Christian == true and Kerstin == true) sind beide anwesend, müsst Dein positiv Szenario lauten, dass beide nicht identisch sein dürfen. (EDIT - nach Verbesserung von paul)

(Christian != Kerstin)

Der Zeitpunkt spielt keine Rolle. Wenn beide abwesend sind, sind beide Klammern falsch, wenn beide anwesend sind ebenfalls und somit ist Oder nicht erfüllt.

Im Prinzip also nach dem Überprüfen der Anwesenheitstrigger:

var Christian, Kerstin,Dunkel;

on:({id: 'fb-checkpresence.0.familyMembers.Familie.Kerstin.presence', change: "ne"}, function (obj) 
            { 
                 Kerstin= obj.val;
                 lampeHaus();
            });
on:({id: 'fb-checkpresence.0.familyMembers.Familie.Christian.presence', change: "ne"}, function (obj) 
            { 
                 Christian = obj.val;
                 lampeHaus();
            });
schedule({astro: "sunset", shift: -20 }, function () {
           Dunkel=true;
            lampeHaus();
});
schedule({astro: "sunrise", shift: -20 }, function () {
           Dunkel=false;
           lampeHaus();
});

function lampeHaus() {
if(Christian != Kerstin){
       if(Dunkel) setState('zigbee.0.7cb03eaa0a0381c2.state', true); else setState('zigbee.0.7cb03eaa0a0381c2.state', false);
    } else setState('zigbee.0.7cb03eaa0a0381c2.state', false);
}

Darauf sollte sich eigentlich der Code reduzieren lassen, wenn über die Trigger Anwesenheit und den Scheduler die Variablen Christian, Kerstin,Dunkel richtig gesetzt sind. Alle Bedingungen prüft man bei jedem Triggern, egal ob Anwesenheit oder Schedule. Es würde sich also das Ganze in eine Art Unterfunktion zu packen.

Wenn die anderen Lichter - unabhängig von beidseitiger An- und Abwesenheit geschaltet werden, sollte man diese Logik getrennt betrachten.

Den Sonnenaufgang hast Du auch nicht berücksichtigt.

[paul53]

@mickym sagte: XOR Verknüpfung:

Einfacher:

if(Christian != Kerstin)

[mickym]

@paul53 sagte in Lampe an der Haustüre und Abwesenheit:

@mickym sagte: XOR Verknüpfung:

Einfacher:

if(Christian != Kerstin)

OK - überzeugt.

[mickym]

Im Prinzip geht es darum, dass Du bei komplexeren Aktionen die Trigger streng trennst.

In den ersten beiden Triggern (also Anwesenheitstriggern) kommen Aktionen, die grundsätzlich für jede einzelne Person gelten.
In den Schedule Triggern nur die Aktionen, wenn dieser wahr ist. Also Aktion wenn es Dunkel ist aber unabhängig von anderen Dingen.

Dann kann man sauber verschiedene Szenarien trennen, mit den Kombinationen.

Statt lampeHaus, könnte die Funktion auch lauten:

nurEinerdaUndDunkel()

Und da hinein packt man dann alle Aktionen für dieses Szenario.

Damit verknotet sich das Hirn nicht so leicht.

[ostseeskipper]

Sorry das ich hier so reinplatze.
heisst man kann in einem JS Script mehrere Trigger so wie hier vorgeschlagen 4 an der Zahl nutzen?

[mickym]

@ostseeskipper

Und grundsätzlich kannst du so viele Trigger in einem JS Modul nutzen, wie du willst. Bei jedem Trigger springt das Teil in den jeweiligen Code.

Zusätzlich kannst in einem Trigger kannst Du auch mehrere IDs angeben (als Regex oder array).

[ostseeskipper]

@mickym
Danke, gut zu wissen dann kann ich ja ein paar Scripte zusammen packen.
Regex ist für mich Hexenwerk da ich es seit Monaten nicht versteh. Ich geh lieber direkt auf Datenpunkte.

Was ist eigentlich Ressourcenschonender. Hab grad aktuell Bewegungsmelder.
Script mit nur einem Trigger auf Bewegung zum Sonnenuntergang einschalten, oder Trigger mit 2 Bedingungen(Bewegung und Tagzeit) ?

[mickym]

@ostseeskipper Nochmal - nach meinem Verständnis richtet sich ein Trigger nicht nach Bedingungen und kann nicht dynamisch ein und ausgeschaltet werden. Man kann nach meinem Verständnis nur innerhalb der Funktion eines Triggers steuern, ob eine Aktion ausgeführt wird oder nicht.

Aber wie gesagt ich bin nicht der JS Spezialist, da ich in NodeRed als Logikmaschine verwende. Vielleicht kann das ja einer der JS Gurus @paul53 oder @OliverIO beantworten - aber wie gesagt ein Trigger gehorcht keinen Bedingungen. Sprich wenn der Code einmal ausgeführt wurde mit dem on (....) , dann bleibt der aktiv. Aber wie gesagt, ich bin in dem Bereich eher auch unsicher, da ich üblicherweise kein JS für meine Logik verwende.

Nach meinem Verständnis muss man bestehende Trigger unsubscriben, um diese zu löschen - das muss man dann in den Code drum rum einbauen - um die Trigger je nach anderen Bedingungen zu aktivieren oder deaktivieren: https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/en/javascript.md#unsubscribe

[OliverIO]

@mickym

Im Rahmen des pattern parameters als Objekt der on Funktion (trigger)
Können schon viele bedingungen angegeben werden.
Das bedeutet, das Iobroker für euch schon vorfiltert ob der callback mit eurer Logik überhaupt aufgerufen wird.
Wenn diese bedingungen geändert werden sollen, dann muss der trigger mit unsubscribe wieder aufgehoben werden und ein neuer trigger eingerichtet werden.
Meiner Meinung nach macht das aber nicht soviel Sinn, da es dann besser ist den trigger ohne bedingungen einzurichten und selbst die Logik zu programmieren, die dann zu einer dynamischen Entscheidung führt welche Aktion tatsächlich ausgeführt werden soll.
Es könnten auch bspw 2 trigger eingerichtet werden die jeweils auf die gegensächlichen bedingungen horcht (einmal bspw ack=True und einmal ack=false)
Die Entscheidung wie das umgesetzt wird würde ich anhand der Menge des Codes abhängig machen. Wir können davon ausgehen, das der Code in Iobroker vielfach bei vielen ausgeführt wird und daher Fehler frühzeitig entdeckt werden.
Eigener Code kann Fehler enthalten die du selbst dann erst finden und beheben musst. Daher sowenig Code wie möglich selbst schreiben.
Die wartbarkeit deines Codes sollte allerdings ebenfalls im Vordergrund stehen. Wenn das was am Ende rauskommt durch euch nicht mehr verstanden wird, dann macht das auch nicht soviel Sinn.

Am besten du machst mal einen Vorschlag und wir schauen drüber und können dich auf verbesserungspotential hinweisen

[mickym]

@oliverio Na ich denke, die Antwort war an den TE gerichtet. Ich dachte mir nur, dass Du als JS Spezialist qualifiziertere Antworten geben kannst als ich.

[mendikant]

@mickym Das XOR Ist allerdings sehr überzeugend...

[mendikant]

@mickym Danke, Du hast es auf das reduziert, was es ist: Ein Logikproblem...
Und ich habe jetzt mehrmals lesen müssen, bis ich es verstanden habe: Der Trigger ist meine Ankunft zuhause.
Das ist auch deswegen sinnvoll, weil ich vielleicht auch Dinge triggern will, wenn ich tagsüber ankomme...
Das lasse ich mal so sacken, und starte mein konzeptionelles Denken nochmal neu...