NEWS
2 Eingänge auswerten und reagieren
-
@mickym
Wie immer, ich versteh den Flow überhaupt nicht weil ich das nicht logisch lesen kann
Deshalb hier mal die gewünschte Funktion als Blockly, was für mich wesentlich einfach im Verständnis ist
Kurze Erklärung dazu.
die 0 und 100 sind bei meinen Rollläden die % für auf =100 und zu =0. Die obejekt ID im Trigger müsste der DP des Lux Sensor sein und bei steuere eben der passende des Rollladen und fertig ist das Ding.Rollladen fährt zwischen 9 und 12 Uhr wenn Lux größer als 40 ist runter und nach 12 Uhr wieder hoch. Das ganze wird jedes mal neu getriggert, wenn die Lichtstärke wechselt, also sofort an die neuen Bedingungen angepasst. Ist es länger als 5 Minuten unter 40, geht er auch hoch. Also wie gewünscht und ich sehe sehr deutlich was jeder einzelne Block wann macht.
-
vielen Dank für Eure Hilfen.
Ich werde mir das nach der Arbeit malansehen und versuchen umzusetzen.
Melde mich dann .....Einen sonnigen Tag
VG
dj-mix -
@jan1 Tja so gehts mir mit Deinem Blockly.
Insbesondere mit dem stop timeout und dann doch wieder timeout.
- Na egal. Natürlich kann @DJ-Mix statt true und false bei den Zeittriggern, auch in der Flowvariable gleich 0 und 100 setzen - das muss nicht true oder false sein.
Das gilt natürlich auch für die Trigger Node.
Bei den Blocklys habe ich ja gar nicht mal so dass Verständnisproblem, aber ich finde leider NIE die Puzzlestückchen die ich brauche.
Um Dein Blockly aber noch mit meinem Flow vergleichbar zu machen - müsstest Du noch sowas wie meine rbe Node dranhängen, die nur dann steuert, wenn sich das Ergebnis der Logik geändert hat.
-
@mickym
der Timeout ist einfach erklärt und das ist das einzige, wo man wissen muss (sollte) wie der läuft
Jeder Block wird ausgeführt, wenn er durch den Trigger Block aktiv wird und wenn das Licht nun schnell wechselt, hast mehrere timeouts gleichzeitig laufen, die sich hoch addieren. Um so was zu vermeiden, stoppt man einfach vorher den betreffenden timeout erst mal (falls einer läuft). Alles im Timeout wird somit erst nach 5 Minuten ausgeführt und wenn dann der Luxwert mittlerweile unterschritten ist, eben gar nicht und genau so soll es ja sein. Ein timeout wird bei Blockly fast immer so verwendet.Wenn man das mit dem Trigger nicht weiß, wundert man sich eben warum die 5 Minuten selten funktionieren
rbe Node ist hier ja anders gelöst, da das mit den FALLS Bedingungen abgefangen wird. Da passiert ja nur was, wenn die erfüllt sind und das ganze eben auch nur wen der Trigger, in dem Fall der LUX DP sich ändert.
Bei Blockly arbeitest bei AUfbau eigentlich recht simpel in dem ein Anfänger am besten laut sagt was er will und zeitgleich genau die Blöcke die er spricht einbaut.
Beispiel:
ich möchte bei bestimmten Lux Werten (Trigger) eine Reaktion wenn eine bestimmte Uhrzeit und Lichtverhältnisse vorhanden sind (FALLS Uhrzeit UND LUX). schon hast das Blockly so wie es oben ist. Das ist für mich sehr einfach und eben logisch. Ich klick einfach das in der Reihenfolge wie ich es sage und es wird schon zu 60% funktionieren. Da man meist bei der Planung etwas außer Acht lässt, muss man das eben danach noch rein basteln, weil das Blockly eben genau das tut was man vorgibt und wenn man was vergisst, das eben in die Hose geht. Die wenigsten Blocklys von mir sind beim ersten Wurf perfekt gewesen, die wachsen bis sie zu 100% das tun was ich will. -
@jan1 Wie gesagt - ich verstehe die Dinger ja einigermaßen - aber ich finde einfach nicht die Puzzleteile.
Vielleicht kannst dem Kollegen ja mal helfen: https://forum.iobroker.net/topic/45435/sensorwert-aus-dp-filtern/2?_=1622442444307
Ich bin einfach nicht mal in der Lage die Teile zu finden, um aus einem Javascript/JSON Objekt einen Eigenschaftswert herauszufiltern.
-
@jan1 Na alles hast mit Deiner Blockly Node nicht abgefangen, was ich mit der rbe Node noch mache.
Wenn einmal 45 Lux und dann 65 Lux kommen, schickst Du 2 mal 100 und ich halt nur einmal.
-
@mickym
Wie man das puzzelt, habe ich oben ergänzt. Für die meisten Anwendungen, brauchst auch nur sehr wenige der Blöcke. In der Regel Trigger, FALLS die Logik Dinger UND/ODER und eben STEUERE um ein DP zu schalten. Das sind die Grundbausteine mit denen der "normale" User schon fast alles schafft was er will und die kannst mit einer Hand aufzählen, also wirklich nix was zu komplex wird.
Wenn Paul seine Blocklys dann vorstellt, ist es was anderes, da er das scheinbar mit der Muttermilch verinnerlicht hat, da verstehe ich teils auch nur BahnhofDas kann man auch noch abfangen, nur warum, da der DP eh schon auf dem Wert steht, passiert nix außer unnötig Traffic. Das kann noch in die FALLS mit rein, also ist schon ..., dann eben nicht
Das ist übrigens ein sehr gutes Beispiel was ich oben geschrieben hatte zum "das Blockly wächst". Die Funktion ist zu 100% richtig vorhanden, aber nicht ganz sauber und schon packt man da noch was rein an das man zu Beginn nicht gedacht hatte.
@DJ-Mix
Das ganze ist keine Aufforderung an Dich Node-Red zu begraben, nur ein Beispiel wie es alternativ geht und da mickym und ich da eben vom Verständnis der einzelnen Umsetzungen doch stark auseinandergehen (wir verstehen uns aber trotzdem), war Dein Wunsch hier ne Gelegenheit das einfach mal zu zeigen. -
@jan1 Ja die rbe Node hätte ich auch weglassen können - war auch nur um den Traffic etwas zu reduzieren.
Wie gesagt die Logik verstehe ich ja - aber ich finde die Teile einfach nicht. Den Trigger - das ist alles kein Problem. Ich kann da ja noch eher eine JS Funktion schreiben. Um eine Javascript Funktion in ein Blockly einzubauen und den Rückgabewert weiter zu verarbeiten - da scheitert es schon. Aber ich will jetzt auch nicht hier den Thread von @DJ-Mix kapern.
Das mit dem Wachsen funktioniert ja in beiden Fällen - wir werden hier einfach nicht auf den gleichen Nenner kommen. Insofern kann man immer nur vom anderen lernen und staunen.
Ich finde das auch sehr gut, was Du gemacht hast.
- Das ist das was ich in dem anderen Thread ja schon mal vorgeschlagen habe: Man implementiert das gleiche Problem mit beiden Tools und dann soll jeder selbst entscheiden, was für ihn logischer und/oder intuitiver ist.
-
@mickym
Müssen wir auch gar nicht, da keiner zu was gezwungen wird und sich raus suchen kann was er wie und mit was erledigt. Dafür ist es ja da, jeder wie er es am einfachsten auf die Reihe bekommt. Ich bin wirklich bemüht mit Node-Red warum zu werden, habe auch ein paar Flow laufen, aber bei mir ist da schnell fertig mit logisch -
@jan1 Sagen wir mal so, wir müssen uns nicht gegenseitig von der Sichtweise des Anderen überzeugen, aber ansonsten finde ich das durchaus gut, was Du gemacht hast. So kann man gerne beide Lösungen einander gegenüberstellen - und da ich Blockly nicht so gut beherrsche, wie Du, ist das doch gut, wenn das gleich der richtige Fachmann macht.
-
@mickym
Fachmann, der war gut. Paul ist da der Spezi, ich schaffe es in der Regel meine eigenen Wünsche zu realisieren ohne groß nachfragen zu müssen, das wars dann aber auch schon. Wobei genau da für mich der Vorteil liegt (je nach vorhandenem Grundwissen). Bei Blockly musste ich fast nichts fragen, bei Node-Red sehr viel.Ich bin eben Elektroniker von Beruf und da liegt mit das Arbeiten mit UND/ODER eben, weil ich das kann ohne drüber nachdenken zu müssen. Die Dinger heißen ja auch nicht zum Spaß Logik Bausteine. Als ich mein Meister gemacht habe, waren in dem Kurs auch Leute die eher von der Starkstromfarktion kamen, die Jungs fanden dann den Digitaltechnik Teil auch nicht logisch und ich konnte mir ein und das andere mal anhören, wenn ich was erkläre, ich soll doch nicht immer sagen, dass das logisch ist
Die waren dann aber klar im Vorteil wenn mal wieder die Berechnung eines Kabels für ein Pumpspeicherwerk anstand, da ich mir eben Unterarm dicke Kabel nicht vorstellen kann. -
@jan1 said in 2 Eingänge auswerten und reagieren:
@mickym
Wie immer, ich versteh den Flow überhaupt nicht weil ich das nicht logisch lesen kann
Deshalb hier mal die gewünschte Funktion als Blockly, was für mich wesentlich einfach im Verständnis ist
Kurze Erklärung dazu.
die 0 und 100 sind bei meinen Rollläden die % für auf =100 und zu =0. Die obejekt ID im Trigger müsste der DP des Lux Sensor sein und bei steuere eben der passende des Rollladen und fertig ist das Ding.Rollladen fährt zwischen 9 und 12 Uhr wenn Lux größer als 40 ist runter und nach 12 Uhr wieder hoch. Das ganze wird jedes mal neu getriggert, wenn die Lichtstärke wechselt, also sofort an die neuen Bedingungen angepasst. Ist es länger als 5 Minuten unter 40, geht er auch hoch. Also wie gewünscht und ich sehe sehr deutlich was jeder einzelne Block wann macht.
Wie kann man in dem Szenario denn verhindern, dass der Trigger außerhalb der Zeit immer wieder neu gesetzt wird
bei Änderung der Lux?VG
dj-Mix
-
@mickym said in 2 Eingänge auswerten und reagieren:
@dj-mix Dann kannst Du das mit Deiner Zeit Node die OFF und ON sendet entweder umstellen auf true und false - oder machst vorher noch eine Übersetzung. Jedenfalls hast Du dann eine Flow Variable validTime, die entweder für das Zeitfenster von 8-12 Uhr auf true, sonst auf false steht.
- Version - finde ich noch eleganter:
Damit brauchst auch keinen LightScheduler mehr als Filter, sondern schaltest den Rollladen direkt nach Zeit, wenn es über 40 Lux hat.
Wichtig bei der Lösung ist, dass in jedem Fall die Switch Node - alle Regeln abarbeitet, damit bei Werten über 40 sowohl der obere, als auch der mittlere Ausgang bedient werden:
Habe es nun so versucht. Hoffe es funktioniert . . .
VG
dj-mix
-
@dj-mix Nun der obere Teil kommt mir bekannt vor und im unteren wirst Du schon wissen was Du tust.
-
@dj-mix
Gar nicht, weil das nicht Sinn des Trigger ist. Man kann das allerdings auch anders aufbauen und mit einem Cron nur in der Zeit arbeiten, was aber den Nachteil hat, dass man nicht schnell auf wechselnde Lichtverhältnisse reagieren kann.
Ein Trigger ist immer scharf, was Sinn dessen ist. Ob dann auch wirklich was passiert, entscheidet die Logik danach, also alles OK. -
@dj-mix said in 2 Eingänge auswerten und reagieren:
@jan1 said in 2 Eingänge auswerten und reagieren:
@mickym
Wie immer, ich versteh den Flow überhaupt nicht weil ich das nicht logisch lesen kann
Deshalb hier mal die gewünschte Funktion als Blockly, was für mich wesentlich einfach im Verständnis ist
Kurze Erklärung dazu.
die 0 und 100 sind bei meinen Rollläden die % für auf =100 und zu =0. Die obejekt ID im Trigger müsste der DP des Lux Sensor sein und bei steuere eben der passende des Rollladen und fertig ist das Ding.Rollladen fährt zwischen 9 und 12 Uhr wenn Lux größer als 40 ist runter und nach 12 Uhr wieder hoch. Das ganze wird jedes mal neu getriggert, wenn die Lichtstärke wechselt, also sofort an die neuen Bedingungen angepasst. Ist es länger als 5 Minuten unter 40, geht er auch hoch. Also wie gewünscht und ich sehe sehr deutlich was jeder einzelne Block wann macht.
Wie kann man in dem Szenario denn verhindern, dass der Trigger außerhalb der Zeit immer wieder neu gesetzt wird
bei Änderung der Lux?VG
dj-Mix
habe noch eine Frage zu deinem Blockly. Ich habe das, um es zu verstehen - nachgebaut. Nun ist es aber so, dass nach
19:00 Uhr das Script nicht beendet ist. Somit gehen die Rollos um z.B. 20:00 Uhr nicht runter?
Oder habe ich da was falsch verstanden?VG
dj-mix -
@dj-mix
Die gehen schon runter, nur wenn sich dann auch gerade noch die Heiligkeit ändertWenn Du die immer um 19 Uhr zu haben willst, dann solltest nicht mit der Heiligkeit arbeiten, sondern mit der Uhrzeit und da nimmst eben ein Cron und machst das separat in einem weiteren Blockly.
Also einfach unten dran ein weitern Trigger mit Zeitplan. -
@mickym
Hallo, habe noch eine Frage, ich habe deine Node nun im Einsatz, was eigentlich auch gut funktioniert.
Zudem habe ich aber den Zeitbereich beschränkt, so dass eigentlich um 19:30 Uhr die Node nicht mehr
aktiv sein sollte, damit um 20:00 Uhr die Rollläden geschlossen werden.
Leider ist da aber irgendwo noch ein Denkfehler meinerseits, denn dei Rollläden werden zwar geschlossen,
aber öffnen dann wieder . . . . ?
Wie kann ich das abstellen? VieleN Dank Vorab
VG
DJ-Mix -
@dj-mix Die Zeitsteuerung - sprich es wird zu gemacht funktioniert ja auch nur, wenn die Helligkeit über 40 ist. Alles andere darunter macht auf oder ausserhalb des Zeitraums von 8-12 macht auf.
Wenn Du neben der Helligkeitssteuerung noch eine Zeitsteuerung dahinter haben willst, dann musst entweder noch eine Flow Variable setzen oder Du benutzt den LightScheduler. In dem Flow sehe ich zumindest nicht, was mit einer zeitlichen Steuerung zu tun hat.Es würde sich vorne ein Filter zu setzen, um die Helligkeitssteuerung ganz ausser Kraft zu setzen und rein auf Zeitsteuerung zu setzen.
-
@mickym
angenommen ich würde gerne noch eine Flow.Variable setzen, die besagt um 19:30 Uhr ist der Flow nicht mehr aktiv.
Wie müsste ich das ganze dann in dem bereits vorhandenen Flow einbauen? Ich habe leider überhaupt keinen Schimmer,
wie man so etwas aufbaut - Sorry das ich dich dafür frage.
VG