Gelöst: Blockly Oder-Verknüpfung
-
-
@cookiemonster1706 Für beide Datenpunkte ? Und warum als Screenshot gepostet - das ist doch alles text ?
Seis drum - Wenn bei beiden so aussieht dann ist die einfachste Lösung das Umsetzen des Trigger von "wurde geändert" auf "ist grösser als vorher". Dann noch einen Debug-Baustein einbauen, der eine Meldung im Log hinterlässt wenn der Trigger aktiv wird, die Falls abfrage aus dem Trigger heraus nehmen und dann testen
A.
Nachtrag: warum die Falls abfrage heraus nehmen ? Wenn der Trigger nur aktiv wird wenn der aktuelle Wert grösser ist als der vorherige dann wird der nur aktiv wenn einer der beiden DP von geschlossen auf offen wechselt. Sprich dann ist mindestens einer der beiden DP "offen" -
z.B. was die Gasheizung mit deinen Fenstern zu tun hat
@homoran Ist das eine neue Forumsregel, dass man in seinem Beispiel keine Datenpunkte nehmen darf, die man eh auf seinem System hat, sondern zuerst sehen muss, dass man eine Testumgebung mit dem kompletten Datenbaum des ioBroker des Fragestellers einrichten muss?
-
@martinp sagte in Blockly Oder-Verknüpfung:
z.B. was die Gasheizung mit deinen Fenstern zu tun hat
@homoran Ist das eine neue Forumsregel, dass man in seinem Beispiel keine Datenpunkte nehmen darf, die man eh auf seinem System hat, sondern zuerst sehen muss, dass man eine Testumgebung mit dem kompletten Datenbaum des ioBroker des Fragestellers einrichten muss?
Nein - aber etwas erklärender Text hilft denen die das nachvollziehen wollen. Ein Bild sagt zwar mehr als 1000 Worte - aber in dem ganzen Sumpf die relevanten 20 heraussuchen ist Arbeit.
Zu dem Bild selber könnte ich jetzt auch noch was schreiben - das spar ich mir aber - es würde den Thread kapern.
-
@asgothian sagte in Blockly Oder-Verknüpfung:
@cookiemonster1706 Für beide Datenpunkte ? Und warum als Screenshot gepostet - das ist doch alles text ?
Seis drum - Wenn bei beiden so aussieht dann ist die einfachste Lösung das Umsetzen des Trigger von "wurde geändert" auf "ist grösser als vorher".Diese Herangehensweise halte ich für heikel.... Dann wird der Alarm nie gelöscht, wenn er einmal gesetzt wurde
Bei jeder Änderung muss geprüft werden, ob noch ein Fenster offen ist, und der Alarm entsprechend gesetzt werden...
Man könnte natürlich mit zwei Triggern arbeiten. Der eine kümmert sich um das Einschalten des Alarms, der andere um das Ausschalten....
-
@cookiemonster1706 sagte: Oder-Verknüpfung einsetzen muss.
Richtig!
Wenn die Datenpunkte vom Typ "Logikwert" oder vom Typ "Zahl" (0/1) sind, genügt es so:
-
@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 ...
