2 Eingänge auswerten und reagieren
-
@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 -
Also grundsätzlich kommen die Trigger immer an den Anfang.
Ich lasse mal alles triggern - Deine ZeitNodes und die Wetterstation habe ich halt mit Inject Nodes abgebildet.
Da Deine Rollladen bei true geschlossen sind, habe ich die Zeitsteuerung so implementiert, dass diese true ausspuckt, solange der Rolladen geschlossen sein soll, also nachts. Das musst Du halt dann mit Deinen Zeitnodes von OFF und ON entsprechende in true und falls übersetzen.
Diese hat auf jeden Fall Priorität.
Die Logik ist nun folgende, alles Links triggert und muss den switch time-control passieren, der anhand der Zeitkontrolle (Flowvariable: Close) sagt, ob der Rolladen geschlossen bleibt oder werden soll:
Falls Close false ist, also der Rolladen potentiell geöffnet sein kann, übernimmt die Helligkeitssteuerung in der bisherigen Form
Hier wieder alles zum Import:
-
@mickym
SUPER Vielen Dank -
Um ganz sauber zu sein, kannst Du noch eine Filternode (switch) in den false Ast und vor der Prüfung der Helligkeitswerte machen.
Geht zwar auch ohne, aber nachdem nun alles triggern darf - filtert man halt die Booleans aus den Zeittriggern raus.
Alternativ kann man auch die Zeittrigger komplett weglassen, dass nur wieder die Wetterstation triggert. Die Zeitkontrolle funktioniert ja anhand der Flowvariablen.
Also das funktioniert auch - aber halt immer dann wenn die Wetterstation einen Wert liefert:
