NEWS
Lampe an der Haustüre und Abwesenheit
-
@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 sagte in Lampe an der Haustüre und Abwesenheit:
@mickym sagte: XOR Verknüpfung:
Einfacher:
if(Christian != Kerstin)OK - überzeugt. ;)
-
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. ;)
-
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. ;)
Sorry das ich hier so reinplatze.
heisst man kann in einem JS Script mehrere Trigger so wie hier vorgeschlagen 4 an der Zahl nutzen? -
Sorry das ich hier so reinplatze.
heisst man kann in einem JS Script mehrere Trigger so wie hier vorgeschlagen 4 an der Zahl nutzen?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).
-
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).
@mickym :+1:
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 :+1:
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) ?@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
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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
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
-
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
-
@paul53 sagte in Lampe an der Haustüre und Abwesenheit:
@mickym sagte: XOR Verknüpfung:
Einfacher:
if(Christian != Kerstin)OK - überzeugt. ;)
-
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. ;)
@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...
Support us
301
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge