Gelöst: Blockly Oder-Verknüpfung
-
@martinp sagte in Blockly Oder-Verknüpfung:
Man könnte natürlich mit zwei Triggern arbeiten. Der eine kümmert sich um das Einschalten des Alarms, der andere um das Ausschalten....
genau das würde ich tun. Und dann auf eine Art und Weise bei der ich nicht im Trigger den Wert des DP noch einmal holen muss.
-
@martinp Aber dann bitte ein wenig Text zur Erklärung dazu!
Einfach einen Screenshot ohne erkennbaren Zusammenhang zu posten, hilft dem Fragenden herzlich wenig -
Mit Variablen könnte man den Zugriff auf den Objekt-Baum vermeiden:
Eigentlich finde ich die Blocklys selbsterklärend
Der Trick bei den beiden Triggern ist, dass man beim Abschalten des Alarms vorher den anderen Zustand prüfen muss
-
@martinp sagte in Blockly Oder-Verknüpfung:
Mit Variablen könnte man den Zugriff auf den Objekt-Baum vermeiden:
Eine schöne Lösung für 2 DP. Dann kommt der mit 3, 4, 5 oder auch 20 Fenstern und fragt sich ob es nicht was besseres gibt
Aber wie oben geschrieben - das würde den Thread kapern und die Frage des OP nicht wirklich beantworten
A.
-
@asgothian sagte in Blockly Oder-Verknüpfung:
das würde den Thread kapern und die Frage des OP nicht wirklich beantworten
Nunja, wenn die Hinweise zu einem leichter erweiterbaren Blockly führen, wäre dem Threadersteller vielleicht noch besser geholfen. Aber die Strukturen werden dadurch natürlich unübersichtlicher, Keep ist simple and stupid
-
Hinterm Spoiler mein Universeller Ansatz für n zu prüfende Elemente.
Was je nach Anwendung angepasst werden muss ist die Liste der zu prüfenden Elemente (gerne auch per Selektor), die Bedingung beim Einlesen der Ist-Werte am Anfang. sowie die Bedingung für das "Alarm Setzen" und "löschen". So wie es ist würde es für den OP gehen, und den Alarm setzen wenn mindestens 1 Sensor offen meldet, und löschen wenn keiner mehr offen ist.
Das ganze lohnt aber erst ab 3-5 Sensoren, vorher sind andere Methoden effektiver.
A.
-
Vielen Dank für eure Unterstützung. Es funktioniert.
Ich werde es mir nochmal im Detail anschauen, um es zu opitmieren. -
@cookiemonster1706 sagte in Blockly Oder-Verknüpfung:
Vielen Dank für eure Unterstützung. Es funktioniert.
Dann ändere bitte noch den Threadtitel, indem du "Gelöst:" davorsetzt
-
@asgothian sagte in Blockly Oder-Verknüpfung:
Hinterm Spoiler mein Universeller Ansatz für n zu prüfende Elemente.
Eine Frage zur Effizienz der Implementierung: Die Liste der gesetzten Datenpunkte ändert ja dynamisch ihre Größe - was für Penalties gibt es durch die dadurch verursachte Speicherverwaltung...
Wäre ggfs eine statische Liste, in der man die Zustände ablegt und nachher auf true abfragt effizienter?
Wenn man sich darauf verlassen könnte, dass immer abwechselnd von jedem Datenpunkt True oder False kommt, könnte man ggfs. auch einen einfachen Zähler nutzen...Hereinkommende "Trues" inkrementieren, Hereinkommende "False" dekrementieren...
-
@martinp sagte in Gelöst: Blockly Oder-Verknüpfung:
Wäre ggfs eine statische Liste, in der man die Zustände ablegt und nachher auf true abfragt effizienter?
Wenn man sich darauf verlassen könnte, dass immer abwechselnd von jedem Datenpunkt True oder False kommt, könnte man ggfs. auch einen einfachen Zähler nutzen...
Hereinkommende "Trues" inkrementieren, Hereinkommende "False" dekrementieren...Das mit dem einfachen Zähler setzt voraus das da nichts schief geht. So hatte ich das am Anfang, aber meine Erfahrung damit war eher durchwachsen - der hat sich eigentlich ständig verzählt, so das oft die Meldung nicht zum Zustand gepasst hat. Unglücklicherweise wird das Verzählen eigentlich immer nur in eine Richtung erkannt - Jede Anwendung hat da ihre "Vorzugsrichtung". Im aktuellen Beispiel ist der Fall "es ist alles offen" eher selten, so das ein Verzählen nach oben kaum erkannt wird, aber dazu führt das der Alarm nie zurück gesetzt wird.
Das mit der statischen Liste ist auch so eine Sache - dann hat man statisch mehr Speicher belegt nur um nicht dynamisch zu arbeiten. Man braucht entweder eine Liste von Objekten mit properties oder zwei Listen die Synchron gehalten werden müssen - incl. dem durchgehen durch die Liste um zu ermitteln wieviele denn nun "wahr" und "falsch" zeigen. Wie genau der JS Garbage-Collector arbeitet weiss ich nicht - allerdings gehe ich davon aus das der Speicherplatz beim Austragen eines Elementes nicht sofort sondern mit Verzögerung freigegeben wird. Ich denke der Ansatz bildet da einen brauchbaren Kompromiss.
Natürlich kann man da je nach Situation alles mögliche optimieren - das war aber nie mein Ziel.
Was ich mir geschaffen hab war ein Skript welches ich einfach duplizieren kann, und welches auch dann funktioniert wenn der JS Adapter nicht beim Start alle States abonniert.A.
-
Vielleicht ist das auch ein "fauler" Garbage Collector, der erstmal "abwartet" bis es eng wird, bevor er aufräumt - da könnte es sein, dass so lange auf dem Peak-Stand der Listengröße für offene Fenster verharrt wird, wie der Garbage Collector Ruhig bleibt, und der Speicherplatz auch bei anwachsender Listenlänge noch passt ...
